There’s a whole lot we just don’t know

This article from David Polack is fascinating. (via another interesting article from Jeff Moore about OOP, PHP, and futuring).

Written back in October 2006, after RubyConf – it talks about the language VM’s under development for Ruby – and well, it’s not all that positive on the future of Ruby for depolyment (which of course makes big enterprise-oriented shops with large development staffs doing things like payroll nervous).

Did I say it was fascinating? So are the comments. This is a space that most of in the ranks of small shops are nowhere near – in fact it’s usually over our heads most days (maybe every day, usually the small shops are just dealing with people that want some checkbox to move from one side of the screen to the other, or doing the web application support equivalent of helping someone “print from Word”). I’ve been more than a little bemused recently with all the mentions of JRuby (like why the heck do I care whether Ruby compiled to bytecode and executed by a JVM). I get the implications when I stop and think about for a bit, but I don’t really care.

It’s damn sure completely off the radar for the folks that use tools produced by the languages like ruby, or java, or php, or haskell, or whatever language you want to pick. I absolutely know that watching this kind of stuff is not understood one whit by a lot of the people in “technology.”

Anyway, I recommend reading it, not because you’ll care, but it does impact the future of the tools we all use. And it will show you a little, of just how broad this area called “IT” really is.

I like ruby as a language a lot. I like it better for my systems purposes than perl, and php. From a web development perspective – I think it’s a wash vis-a-vis the language itself – though I enjoy ruby more than I enjoyed php. Rails was/is a big deal – and sure makes a lot of what I’ve done with PHP before a lot easier to do (at first, and then it’s just good old programming sweat after the first few days) Maybe it’s not any better or worse than something like Django (but I certainly like ruby better than what little python I’ve done) but it’s better than anything PHP had (though I’m completely ignorant with any current PHP frameworks).

I don’t particularly care about enterprise computing either. I’m not sure that the enterprise IT space ever actually helps anybody do anything interesting (but it does make sure they get paid, which is pretty damn important). But the enterprise drives a lot of things and it will be a interesting 2 or 3 years watching all this shake out. What else don’t we know that will come up and impact our business?

Almost, but not quite, completely off-topic

Articles like this one from the ADC reference library (I subscribe to the feed) – make me so completely happy that I’m not doing desktop programming anymore (I never have done it on the Macintosh, Win32 was enough).

If you receive this return value from AuthorizationCreateFromExternalForm it means that the AuthorizationRef from which the AuthorizationExternalForm was created is no longer valid. Typically this is because the process associated with that AuthorizationRef has quit.

wow, I just fell asleep at the keyboard. (for my estimated 6.5 readers, it’s not safe to wake up yet from my last post)

Checking the angles

I’m not sure if the systems background that I have or that I am a perfectionist or that I’m just flat-out pedantic – but one of the things I’ve noticed in my approach to creating code that I haven’t seen in people that I’ve worked with that have come up through the developer (not support, not IT/systems) ranks is that I’m far more likely to do two things. One, I’m far more likely to clean up after myself. I’ll remove unused code blocks and/or re-factor as I go, and if I find a better/different way (or pending deprecation) of doing something – I go back and clean up/change most or all the places that aren’t using the new way to be consistent Two, I seem far more likely to mentally consider more of the input edge cases and handle them.

Maybe it’s just the style of those that I’ve been around – or maybe it’s endemic – I don’t know. Maybe I have a systems mentality and a development training that come of age in the functional and waterfall years (but thank heavens those are over). But even with current developer discussions that tend toward design patterns, talk about unit testing, code coverage, which are certainly good and useful things – when not used as a trendy buzzword – nothing seems to beat old-fashioned coding sweat. Good variable names, the occasional comment, cleaning up after oneself, and sanity checking input.

Anyway, I’m just reminded of this today, possibly out of guilt. I recently combined a bunch of shell scripts that were handling my apache log analysis process for the 30+ vhosts we have into two vhosts. The shell scripts were working perfectly fine, but were heavily dependent on hard-coded strings and were a bear to extend (in the current “Don’t Repeat Yourself” mantra of the Rails crowd – they were like a needle on a scratched 33 1/3rd LP on a 78 rpm roundtable). I did a relatively straight port for round one, with some useful loops, and then after I left out a few calls to awstats that broke daily stats – I went back and cleaned it up some more and added parameters to deal with dates. I split things out into a few methods to make it cleaner – and of course had to rename all the variables because they were no longer semantically valid.

One of the things the scripts do is during awstats report production – they create convenience symlinks for the html reports for the “currentmonth” and “currentyear” and “yesterday” – which is slightly better than having to walk web directories for year/month and year/month/day (I’m using index walking for report browsing – it probably needs a front end app to ease browsing, but other priorities first). Well, those symlinks assume the natural scheduled running of the application. It runs early in the morning – based on the logs and data generated up through “yesterday”. However, when you pass dates in to re-run reports if necessary (a very rare thing that’s not likely to occur again for months) – generating those symlinks is worthless if the date you gave the script is not the “currentmonth” or the “currentyear” or “yesterday”

So of course, I had to add code to check for that. Pedantic isn’t it? Especially for something that rarely, if ever, will occur again – so what if the symlinks are temporarily broken until I run the standard process again (either scheduled or by hand). But date comparisons I added.

The guilt that I have, of course, happens on the first of the month. Given that the scheduled job that runs on the first of the month – and only processes yesterday’s data (the last day of the prior month) – well that invalidates the semantic meaning of “currentmonth” (or “currentyear” for Jan 1). Before I didn’t bother – I just created the symlinks even though “currentmonth” really means “lastmonth” on the 1st.

But code that I added keeps the symlink from being created if the month of “yesterday” doesn’t equal the month of “today”. Oh well.

Of course, it also prevents removal of the previous symlink. So in the end its a wash 😉

This story brought to you by the number 3 and the word “anal”


postscript:

While I was writing this, I looked at my code to double-check when the symlinks would get created. In order to create date-based directory names in places – I end up doing:

reportday = timevalue.day reportmonth = timevalue.month reportyear = timevalue.year

(I do need the distinct values for those things as opposed to doing to producing a yyyy/mm/dd string)

My month comparison code just copied that model – and so I was doing:

# is currentmonth? todaytime = Time.now todaymonth = todaytime.month todayyear = todaytime.year reportmonthdate = Date.parse("#{reportyear}/#{reportmonth}/01") todaymonthdate = Date.parse("#{todayyear}/#{todaymonth}/01") iscurrentmonth = (reportmonthdate == todaymonthdate) Totally inefficient right? While writing this article I ended up re-factoring it 🙂 ` # is currentmonth? reportmonthdate = Date.parse(“#{reportyear}/#{reportmonth}/01”) todaymonthdate = Date.parse(“#{Date.today.year}/#{Date.today.month}/01”) iscurrentmonth = (reportmonthdate == todaymonthdate) `

(which could be collapsed to one line – but the above is slightly more readable to me)

Goodbye conventional wisdom

For years, it’s been the conventional wisdom in userid/password based authentication systems that the system provide the same error message for an invalid userid and/or invalid password. The idea being that you don’t want to let on to the “bad guys” that they guessed a valid userid and then proceed to repeatedly try passwords with the valid userid.

Well poppycock.

I watch the logs. And it turns out that while I’d really, really love for people to learn how to remember not one, but a combination of two, not-random strings, they often don’t. Or do, just the wrong combination for that particular tool.

userid/password authentication schemes are already bad from a security perspective – it’s not like obfuscating the result of mistyping a not-random string improves upon that much at all, and by golly, it should would save the users some time “did I mistype my password? did I forgot my password? WHAT DO YOU MEAN INVALID ID?”

So from now on, goodbye conventional wisdom, I’m actually going to start telling people in every uid/pass dialog I write which string they got wrong.