Month: February 2006

iCalendar timezones…

lpaulriddle

I took another look at time zone data in iCalendar, to see if I could include time zone info in my downloaded Oracle Calendar data. This isn’t a super high priority thing, as the only thing that it affects is how my Palm displays my meetings. The meetings are displayed correctly, but they include a UTC time identifier at the end. Not a huge deal, but if I can get rid of it easily, it’d be a win.

A quick Google search on “vtimezone” turns this helpful page up. Based on the info therein, I was able to craft a working VTIMEZONE section for US-Eastern, that includes daylight savings rules for both pre-2006 and post-2006. To wit:

BEGIN:VTIMEZONE
TZID:US-Eastern
LAST-MODIFIED:20060101T000000Z
BEGIN:STANDARD
DTSTART:19671029T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10;UNTIL=20061029T070000Z
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
END:STANDARD
BEGIN:STANDARD
DTSTART:20071104T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=11
TZOFFSETFROM:-0400 TZOFFSETTO:-0500
TZNAME:EST
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19870405T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=20060402T070000Z
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
END:DAYLIGHT
BEGIN:DAYLIGHT
DTSTART:20070311T020000
RRULE:FREQ=YEARLY;BYDAY=2SU;BYMONTH=3
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
END:VTIMEZONE

Now, this is great, but the problem remains that all of the times I pull out of Oracle Calendar are in UTC. So I guess if I want to take advantage of this, I’ll need to manually convert all of these times from UTC to US-Eastern. This seems like too much work for too little gain, so I’m just going to leave it the way it is.

Love those non-cash donations..

lpaulriddle

Well, being that it’s tax time again, I just have to say how much I love giving our old junk away to charity. Lately, our favorite charity for this kind of thing is Vietnam Veterans of America. This is just such a win-win for all parties involved, that I can’t say enough about it. Consider:

  1. We get rid of stuff we don’t need any more, that was cluttering up the house.
  2. We get a tax deduction for it.
  3. It’s easier than having a yard sale or selling on EBay.
  4. The stuff goes to a good cause.

For this past year’s donations, I tried out H&R Block’s DeductionPro software, which includes a large built-in database of valuations for various items. The only reason I tried it was because they threw it in for free with my purchase of TaxCut, but I have to say I like it. It simplifies the record-keeping process and keeps a running tally of the total deduction amount. If it stays free, I’ll certainly continue to use it. If not, I’ll weigh the benefits of using it vs. using a spreadsheet or somesuch. We’ll see.

An important part of this is picking the right charity. The cause itself is important, of course, but the charity also needs to be reliable. When you go to the trouble of scheduling a pick-up and dragging the stuff outside, you want them to show up and take the stuff. After a couple bad experiences with other charities, we’ve found VVA to be very good in this department.

Again.. can’t say enough about this.. get rid of junk, help a good cause, get tax writeoff. It doesn’t get any better.

More on VNC

lpaulriddle

Well, it’s been a little over a month since I first played around with VNC, and now I wonder how I got along without it. Mostly, I use it to access my Linux box in the basement office. For awhile I grabbed its main X11 display using the XFree86 VNC module. This works OK, but it’s still slow. Then, I tried starting a dedicated VNC server on the Linux box (it opens a new virtual X11 screen on localhost:1), and the performance difference is like night and day. It’s so fast that sometimes I forget that I’m working on a remote desktop. It’s even fast when I access it from the Mac over the wireless.

The only issue with this setup is access from the Linux desktop itself. I have to open up a VNC client to access the desktop running on the same machine, and I have to remember to start apps that I’ll be accessing remotely (gnucash, etc) inside the VNC server. This seems a little inefficient/redundant, but it’s a worthwhile tradeoff considering the performance is so much better. Plus, I can re-enable direct rendering on the native X desktop now if I want.

The hassle^H^H^H^H^H^Hlegacy of PINs at UMBC

lpaulriddle

So, we have this new campus portal at UMBC. And for the most part, the launch has gone pretty well. As part of this whole thing, we’re rethinking some of our old, outdated business processes and changing the way they work under the new portal. One of these is the PIN (Personal ID Number). Waaaaay back in 1996 when UMBC first launched web-based course registration, we required all students to enter a 4-digit PIN to log in. There was also a service where students could register by phone, that used the same PIN. Flash forward to 2006. We’re now using a campus-wide single signon system, the telephone registration system is gone, and we’ve done away with PINs as part of the login process. So, since students aren’t using them any more, we can just get rid of PINs altogether, right? Wrong. Problem is, we’re still using our old, crusty HP3000 mainframe as system of record for registration, so when we do online course registration, we have to play by the HP3000’s rules. The HP3000 is still running circa-1996 registration code (written in Cobol), and PINs are so deeply embedded into that code, that there’s no way we’re ever getting rid of them as long as the HP is around. We can rework things so that all the PIN stuff is handled behind-the-scenes, and users never see them or even know they exist, but on the back end, they’re still going to be there.

Now.. the HP3000 stores everybody’s PIN in a database table. But initially, that table is not populated until a user accesses the system for the first time. Then, the HP figures out an initial PIN for the user, and uses that to populate the PIN table. It then sets a flag that the user’s PIN needs to be changed. The HP will then refuse to do anything on behalf of that user, until they change their PIN. The mandatory PIN change happens when the user logs into myUMBC. With the old version of myUMBC, they would see the mandatory PIN change screen immediately after logging in, at which point they’d need to change the PIN before doing anything else in myUMBC. But again, this behavior is a relic of the days when most activities in myUMBC centered around the HP. It also prevents certain users (people who lack the appropriate data that the HP needs to generate the initial PIN) from using myUMBC at all. If we’re going to move forward, we need to get rid of this behavior.

The first step towards this goal, was to eliminate the mandatory PIN change check on initial login. Now keep in mind that we have to submit an initial PIN change request for every student, before they can do anything that involves the HP. So, I’m now doing the mandatory PIN change only when the user requests a function that uses the HP. So rather than seeing it when they first log in, they see it when they try to register for the first time. A small but significant step.

This works great, except it broke the online student parking registration app. Student Parking Registration has the distinction of being the only external (not part of the monolithic legacy myUMBC code) app that talks directly to the HP. If a student goes to this app before changing their PIN, the HP will refuse the parking registration request and the app will fail silently. Yep, this was a fun one to debug. It’s still broken, until I figure out the best way to fix it.