« September 2005 | Main | November 2005 »
October 27, 2005
Oh mighty Solaris!
Well today I joined in a group that was finishing up the Solaris 10 install on a little box in ITC 008. Mike and Shaun were fighting with VI (vi ?) trying to modify a text file so that we could more appropriately use the OS to do what we want to do.
I was a little late to this little party because I have been invited to the OUR (Housing & Dining) Staff meetings which are ALSO on thursday mornings - from like 9am till 10ish. So those every other week meetings occasionally conflict with my now-standard thursday 930am-11something UCS staff meetings.
But it's all OK - I can make it work.
So after watching a short portion of the modification of this text file (which was an OS file I'm guessing), we rebooted and could not login.
TRAVIS TO THE RESCUE.
He taught us all something about logging into a slightly-hosed Unix machine ( that I probably won't remember ) but included in it a little lesson about physical security. It was like watching a good cartoon. It's funny, exciting, action-packed.... but there's a lesson to be learned. A little something about real life that you and I can learn from those muscle-laden, gun-blazing, trash-talking superheroes we all know and love ( it's OK if your cartoons are plush, soft-speaking, carrot-eating jokesters).
Anyway, as we were doing all of this to eventually install Oracle 10g, and get it up into test, we finished this step relatively close to a meeting I had scheduled, so decided to adjourn.
But I can't wait to get 10g going. So much new stuff, and we need to see if some of our existing applications will be compatible with the new DB platform. Basically we are going to start catching up, which makes me excited.
wOOt.
Posted by ellism at 9:35 PM | Comments (0)
October 25, 2005
Sophos
In my last blog, I said "...the only constant is change...". Well that's sure true today.
Our mighty and gentle giant Sophos has been much less of a pain than many other Antivirus products that we've used in the past.
Today we finally got to see the meaner side of Sophos. Before I continue:
DISCLAIMER: The following information is AT PRESENT a matter of opinion as it has not been conclusively tested to the point of fact.
So bascially Sophos, it appears, seems to be disabling the ability of some residents to surf the web. In many cases IM programs, Sophos update and other web-oriented programs work, but neither IE nor FF will download and view a webpage.
John Rushing had received about 5 calls over the period of 20 minutes and we knew something was up. Upon further investigation it was found that 90% + of machines exibiting this functionality (and the total number of affected machines is unknown - we've received probably about 50 calls, although reports of entire communities being offline have been reported) could be 'reconnected' by disabling Sophos Services.
In most cases re-enabling the Sophos services did not re-disconnect the computer from the ability to surf. So as we continue to gather evidence and sort through the myriad reports, we only know Sophos seems to be the root of the problem. But it's a computer, so who knows?
More to come on the not-so-criminal investigation of the Surf-Killing Sophos...
Is it Sophos? OR something far more sinister...like falling buttered toast taped to cats?
Inquiring minds want to know...
Please click here if you want pictures and can brave German.
Posted by ellism at 12:03 AM | Comments (0)
October 21, 2005
Software Life Cycle (and Philosophy)
I recently returned from a trip to Hawaii (my wife and I went to a wedding) to find out that one of my software programs had crashed during a critical time. Luckily for me, enough WORKING 'duplicate' reports existed for the data to be extrapolated from the DB and sent to the appropriate department.
However it forces me to pause and reflect. Selah.
Everyone with a CS degree should have learned about the Software Life Cycle. It's an interesting model that can be viewed in many ways. Basically very few programs are ever written, tested, modified, released and then never touched again. As the only constant is change, and this truth extends not only through our personal lives but into the working world as well - I'm given pause to consider the Software Life Cycle.
Things change. Let's face it, but what is the best practice for things like software that can change both quickly and significantly. It turns out that my programmatic issue was a DATA issue (compounded by another system recently upgraded unfortunately producing slower access times). But as a Software Engineer (SE) I should be able to deal with that. Or should I?
Who's job is it to maintain the QA of 'the code'? Is it my job as the SE to guarantee (which is a dirty word with computers...) that NO MATTER what comes my way the code should be able to stand? Is it the job of the DB engineer to structure the DB in such a way so that many things are not possible - thereby eliminating many 'required' checks and error conditions, etc...
I'm not going to propose 'the answer' or an answer at all.
Users want stability...and consistency. The SE wants to be able to efficiently generate code to meet the users' demands. Is there a responsibility by the SE to train the users to use the program correctly, thereby again eliminating much 'required' error checking, etc...
As a SE I don't want to bloat my code with 400,000 checks and re-checks to make sure that every possible condition that CAN exist will be dealt with. That creates as much as 2-3 times as much code - which itself can be buggy. Is it alright that when a users does something REALLY unintuitive and totally against what the program is supposed to do that they get an ugly error message and have to contact me? Is it alright that when someone else's system has data integrity problems that it can create ugly error screens for my users?
Should the users have to put up with that?
Should we (the SE's) always have to make sure that even when things go wrong that the user gets sweet and clean messages and everything's still pretty and happy? Should I be expected to have programs that never crash (or at least crash hard) ?
Well fortunately I have great users and my programs don't crash often. Users understand that program do occasionally crash. Not everything can be considered beforehand. Sure it's my job as the SE to keep them from crashing frequently. But with an average of 5 minutes to fix most problems, where is the line?
Where is the line?
Posted by ellism at 8:39 PM | Comments (0)
October 20, 2005
Professional Development
In a sweeping move of policy, the priority of our professional development has taken three T-Rex sized footsteps forward.
If in the eventuality that we don't end up having a staff meeting (for 1 of X reasons) we are to use that time, 930-11am thursday mornings, for professional development.
Public response: Positive.
You ever said "I'll do that when I get around to it...". Yeah. Well this lovely new idea allows (nay, requires, nay - empowers) us to utilize time that has already been hacked from our schedules like thick jungle grass cut with a dull machete.
So for all those projects that we've been putting off and putting off, and well avoiding or trying to forget (or just putting off) - mostly cuz we have too many 'fires to put out' - now we can use some pre-dedicated time to get those done. But now! It doesn't stop there... we should also being learning new things that many of us don't feel the freedom to "stop" and take the time to do. Like learning something new (heaven forbid).
Anyway, the 2nd SUPER reason for this is that other people are ALSO free, and so cross-training can happen, as well as learning from folks that know a bunch but are usually to busy/whatever to be able to teach (like Travis). I think this is the best idea yet since the pool table and Joe's blendmaster Fridays.
Posted by ellism at 9:27 PM | Comments (1)
October 5, 2005
Test Blog
This is a test blog to see if a person can write a blog 'today' and say it was written 'last week'.
Posted by ellism at 12:54 AM | Comments (1)
Decode( );
Well I feel that I've been very accomodating to the technically-impaired (so far as my past blogs are concerned). Time to brake the mold.
I spent the last 2-3 days fighting with the SQL function DECODE();
It's a jolly old boy with lots o' potential.
The thing that I love about PL/SQL is that I can use the power and flexiblity of the procedural language (such as control structures [i.e. if, else, end if, for loop ...] and compilation) while still having EASY and quick access to the Database.
Now although I can embed SQL & HTML into the PL/SQL (and Javascript into the HTML), the SQL itself has it's own set of rules. For instance, you can't say "if this, then that, else if this, then that, else if this, then that, etc....". So sometimes you have to make really long loopy code or multiple procedures to make up for this limitation.
Well today I have gained some most-excellent experience with the SQL function DECODE(); Decode() is the closest thing we have to 'if' logic, so it CAN be very powerful.
Decode looks like this:
DECODE ( [variable],
[possibility #1], 'return value for #1',
[possibility #2]', 'return value for #2',
[possibility #3]', 'return value for #3',
[possibility #4]', 'return value for #4',
[default if none of the above is found]
)
Do take care to substitute appropriate values and remove all: [ ] '
Nerdy, eh?
Anyway, so the cool thing about this is that we USED to make multiple procedures/duplicate LOTS of code if we wanted to ... let's say ... order the results on different stuff (and we use a passed in variable to tell us what).
So, instead of two procedures like:
procedure print1 is
begin
for a in (select * from boots order by color) loop
htp.print(a.boot||'\n');
end loop;
end print1;
procedure print2 is
begin
for a in (select * from boots order by size) loop
htp.print(a.boot||'\n');
end loop;
end print2;
... now we can make one procedure:
procedure print (porder varchar2) is
begin
for a in (select * from boots
order by decode(porder,
color, boot_color,
size, boot_size,
price
)
) loop
htp.print(a.boot||'\n');
end loop;
end print;
[I indented it, but HTML isn't that smart, so it looks ugly, sorry.]
So, you pass porder into the procedure. It the value is 'color', then decode() returns boot_color and the list gets sorted by that. If the value is 'size', then book_size is returned and used for the order by. However, if porder is neither color, nor size, then decode() returns price and the data is ordered by that. Clean, reasonably easy, fact.
This is obviously a dumb example because of the many technical issues - however I hope you understand the point. Basically this code gives us the ability to order the same cursor by whatever the heck you want to order by.
I've utilized this ability in RW2 (Redwolf v2). On the large reports, you have the ability to sort by firstname, lastname or location (ascending or descending). This 'dynamic order by' also allowed me to consolidate 2-5 reporting procedures down to 1 or 2 - thereby simplifying the maintenance of my code, and standardizing the report format(s).
There are some darn tricky things about the decode statement, and you can utilize multiple ordered decode's for some interesting and useful results. Please come ask if you have questions about DECODE(); It can be used in a WHERE clause and therefore it's relevance to SQL is hugely increased.
PL/SQL - it's code! Hurray code!
Posted by ellism at 12:19 AM | Comments (1)
October 1, 2005
IT'S DONE!
Stage 1 of the new WOU Online Housing Application is working.
It still needs a bit of tidying up, but all of the functionality is working. That means a lot to me. My deadline for this project is October 1st, and as it is currently Sept 30, I am a very VERY happy guy.
We implemented the anonymous registration but we were getting errors when the system was attempting to email registrants their login info. After many calls to many locations, we finally got a functional, but buggy solution. After a bit of luck (or divine inspiration) we added a line of code that solved everything else.
So, a bit of testing added to some minor changes, gives the University it's first online Housing Application - and it'll go live less than 5 days late! That's progress as far as I'm concerned.
On a side note, I've been updating security cameras lately as well. It's a painful, irritating process (especially when it rains), but things are in much better shape now that I've had time to dedicated to them again. NSW (new student week) took so much time to prep for, some things got neglected (such as security cameras).
Well it's been a succesful week, and thank goodness for that!
Posted by ellism at 2:18 AM | Comments (0)