Graham's diary
|
Internal borders [Computing] I've had this idea in my head for some time that the way people run IT organisations is wrong: they're too fragmented into subject-specific areas. Then the DevOps guys came along and started trying to encourage developers to work with ops people, which is a start. But I'm not satisfied with dev-ops collaboration; I want ops-ops collaboration and I had a good old rant to the Build Doctor about it over an ale or two. Kris Buytaert followed up with a blog post describing some of the tensions he sees. Splitting your operations people up into teams of DBAs, Systems Administrators, Network Engineers, Storage Engineers and all the other ops disciplines is probably causing you pain. You probably don't even know that it's sickness; you probably just think the symptoms are part of everyday life in IT: glacial progress on projects and issue resolution and a lack of interest in the business goals. The first symptom is that to get some things done seems to require enormous willpower and dedication. These are simple things that require work by multiple teams. There's a delay while the task crosses the internal borders between each team and they try to understand the request. There are times when people forget what the process is and it doesn't get routed correctly to the next team in the chain. It's unlikely that any of the teams have the inclination or the understanding to test that what the customer wants has actually been done. What they test is that their tiny piece has been done. It seems as if every time things cross internal borders between teams there's a latency cost while you wait for them to do their thing. There's also a cost of doing business with your colleagues, something familiar to anyone who has been asked to fill out numerous mandatory fields in a form to request that someone sitting within feet of you make a relatively insignificant change. The more team boundaries you cross, the more these delays and costs mount up. The second symptom is that operational issues can take a long time to resolve. In my experience this is particularly true of performance problems. Maybe your users are complaining about some report taking minutes to complete and you pass the ticket onto your application support people and they say, no, there's nothing wrong with the application, maybe it's the database? So the problem baton is passed to the DBAs and they have a look at the database, declare that the database is OK and ask the network guys to have a look. The network guys mutter about 5% utilisation or something and say the network is fine and they pass it to the sys admins, who mutter something about 20% CPU usage and say everything is fine. And now, probably a day or two later, you have a bunch of technical people who have checked their personal fiefdoms are fine and a bunch of angry users who are still have reports that take too long to run. Of course, all these experts could be right, but it doesn't matter, because optimising the network, the databases, the storage or the servers in isolation is absolutely useless. The report could be running slow because there's an extra few milliseconds of latency between the server and the database and the report does 10,000 database queries, which return a lot of data and the milliseconds add up to a long delay. Unless someone sits down and works out what is going on, while understanding the whole technology stack, your users are going to have to put up with it. The third symptom is that none of your operations staff seem to actually care what the business wants to achieve. The human mind is odd. As soon as you put people in discipline-specific teams you seem to be sending them a subtle message that their job is not to meet business needs, but to look after some arbitrary technical resource. Don't, therefore, be surprised if the DBAs care more about databases than the business goals. By putting them into the "DBA team" you're telling them that their job is to look after databases. By implication, the business goals are secondary. Putting people into a bunch of specialist teams doesn't seem to be the right way to do things. There has to be a better way. | |||
|
This could be a problem with the server's configuration [Computing]
| |||
|
Let the code speak for itself [Computing]
# Enterprise class names! It has come to our attention that some people
# think the names of the Beautiful Soup parser classes are too silly
# and "unprofessional" for use in enterprise screen-scraping. We feel
# your pain! For such-minded folk, the Beautiful Soup Consortium And
# All-Night Kosher Bakery recommends renaming this file to
# "RobustParser.py" (or, in cases of extreme enterprisiness,
# "RobustParserBeanInterface.class") and using the following
# enterprise-friendly class aliases:
class RobustXMLParser(BeautifulStoneSoup):
pass
class RobustHTMLParser(BeautifulSoup):
pass
class RobustWackAssHTMLParser(ICantBelieveItsBeautifulSoup):
pass
class RobustInsanelyWackAssHTMLParser(MinimalSoup):
pass
class SimplifyingSOAPParser(BeautifulSOAP):
pass
[Whitespace added for clarity] | |||
|
Seconds since UNIX epoch in Oracle [Computing] I have recently been asked how, using Oracle it would be possible to calculate the number of seconds since the UNIX epoch at midnight today in the current timezone, which is British time, currently BST (+01:00). We have a commercial application which stores timestamps in "UNIX time": the number of seconds since the UNIX epoch (00:00 on 01/01/1970). We need to manipulate this data to stop this commercial software making naive decisions which affect our revenue. So, within Oracle how do we find out how many seconds there were since the UNIX epoch at midnight today? Unfortunately Oracle DATETIME datatypes have no concept of timezone or daylight saving time, so asking something like this:
SELECT to_date('01-AUG-2007','DD-MON-YYYY') - to_date('01-JAN-1970','DD-MON-YYYY') "days since epoch"
FROM dual;
days since epoch
----------------
13726
gives you the right answer in one sense, in that there were 13726 days in that period, but the wrong answer if you want to know how many 24-hour periods there were. 1st August 2007 00:00 BST is actually 31st July 2007 23:00 GMT, so really there were 13725.958 24 hour periods in that time.
Happily Oracle do provide the TIMESTAMP WITH TIMEZONE datatype which knows all about time zones and daylight saving. Firstly you need to tell Oracle which time zone you are in: >alter session set time_zone='Europe/London'; Session altered.Then you'll find that time deltas across daylight saving changes will start working as you want them to:
SELECT current_timestamp - to_timestamp_tz('01-JAN-1970 00:00','DD-MON-YYYY TZH:TZM') delta,
to_char(current_timestamp,'HH24:MI:SS TZH:TZM') now
FROM dual;
DELTA NOW
------------------------------ -----------------------------
+000013726 19:58:33.200125000 20:58:33 +01:00
Putting it all together with the use of the extract function, we have this:
set serveroutput on
ALTER SESSION SET TIME_ZONE='Europe/London';
DECLARE
days INTEGER;
hours INTEGER;
unixmidnight INTEGER;
BEGIN
days := EXTRACT(DAY FROM(TRUNC(CURRENT_TIMESTAMP, 'DD') -
TO_TIMESTAMP_TZ('01-JAN-1970 00:00','DD-MON-YYYY TZH:TZM')) DAY TO SECOND);
hours := EXTRACT(HOUR FROM(TRUNC(CURRENT_TIMESTAMP, 'DD') -
TO_TIMESTAMP_TZ('01-JAN-1970 00:00','DD-MON-YYYY TZH:TZM')) DAY TO SECOND);
unixmidnight := days * 24 * 60 * 60 + hours * 60 * 60;
DBMS_OUTPUT.PUT_LINE(TO_CHAR(unixmidnight)
|| ' seconds since unix epoch at midnight today in London');
END;
/
Session altered.
1185922800 seconds since unix epoch at midnight today in London
PL/SQL procedure successfully completed.
It's hardly elegant, but it might save someone some work. | |||
|
Netscreen Security Manager on Ubuntu Edgy [Computing]
UpdatesDave Burke emailed to tell me that this technique worked for him, but does not enable you to run the NSM installer. Here's the method I settled on:
| |||
|
All words and images on these pages are © Graham Bleach, 1998-2007 unless otherwise stated.