Blog moving to GitHub

So, I think one reason this blog hasn’t yet been what I want it to be is that it’s really annoying trying to do things like custom JS and syntax highlighting on WordPress. So I’m ditching it. I’ve exported the posts here to Jekyll, so I can post just by writing a post in Markdown or Textile, and pushing to GitHub.

It’s really a great way to blog… all I need is Vim and Git, and I’m ready to go.

This also means no easy-peasy WordPress themes and templates, so the new blog is a little sparse at the moment. But that’s where new posts will live. So go there:

http://duckpunching.github.com/


PAM authentication for Ruby 1.9

Announcement

So, I’m happy to announce the availability of PAM authentication for Ruby 1.9.x, through the rpam-ruby19 gem. A couple of gems had existed for previous ruby versions, but 1.9 broke compatibility with all of those. After looking at the options, I decided that the the rpam gem was the best candidate for an update. It works really well on Linux (tested on Debian and Ubuntu), it’s simple to use, and there’s an authlogic plugin if you want to use rpam in your rails app.

Why?

I ran into a situation where I needed to use an approved “enterprise” authentication solution. My options were limited to Shibboleth, OpenID, SiteMinder, and ActiveDirectory. The first three involved a redirect to an ugly sign-in page; that was a no-go for a mobile app. So I decided to get creative. Using Authlogic + Rpam + Likewise to validate AD credentials created a seamless way to integrate into the environment, while leaving the look-and-feel of everything under my control.

Caveat

Using PAM for web authentication is ONLY a good idea for internal applications. Even then, you have to be careful. But if all potential users of your application are also potential user of your systems (i.e., AD/LDAP entities), it can be a decent solution.

P.S.

If you want the source, or would like to contribute, you can find it on my GitHub. It’s still a work in progress; it really needs tests and documentation. But it works, and might come in handy for someone, so I’m throwing it out there now.


TDD Hiring Practices – How do you evaluate a programmer?

I’ve been thinking a lot about hiring practices. How do you evaluate a potential employee’s programming skills? One popular yet (sometimes) controversial method is the use of coding quizzes. While I like this idea in principle, these quizzes can range from the absurd to the superfluous to the fascinating-yet-bizarre to the absolutely brilliant.

This suggestion is going to be very specific to my own milieu, but I think it can be abstracted easily.

One of my favorite learning experiences ever has to be Ruby Koans. It’s a set of failing unit tests that you have to figure out how to make pass. It’s fantastic, challenging (for the neophyte Rubyist), and enlightening.

I think this paradigm would be applicable to any TDD-oriented (and if you’re not, you should be) shop, because it tests both coding skill and testing proficiency. These aren’t the same thing, but both should be important to any hiring manager.

The other thing that comes to mind is Star Trek. Specifically, the Kobayashi Maru scenario (side note – it’s awesome that my browser and/or WordPress didn’t mark “Kobayashi Maru” as a misspelling).

For those who don’t know, the Kobayashi Maru was a no-win scenario, which Kirk managed to beat (the only time it was ever “won”) by reprogramming the computer. So you can test creative thinking, grace under fire, etc. by making some of the tests bad. If you’re into torturing applicants. It’s just an idea, not necessarily a good one, but if you’re a high-pressure shop, you might want to gauge that sort of thing.

This could happen on-site, or be sent to the applicant with a 24-hour window to submit the results.

Here’s how I think the protocol for this kind of test should go though:

  1. Timeboxed – You have a finite amount of time to complete this. It doesn’t have to be perfect, you don’t necessarily have to pass every test, we want to see how you think, how you prioritize problems to get the best results in the time allotted.
  2. Real-world – You’re not restricted as to resources. You can use Google, Stack Overflow, GitHub, whatever you want. In the real world, we try to see if we’re working on a solved problem before reinventing the wheel. I’m less interested in what you know than in whether you know how to find the answers to new problems efficiently.
  3. Honest – Be up-front about the problem. If the tests should be regarded as the source of all truth, say so. If the tests might be flawed, tell them. If you’re trying to test their ability to make that distinction, be honest. Tell them you’ll answer any questions they have unless you think it will bias the results. You want your programmers to have as much information as possible about the project you’ve just handed them, and you want them to be able to ask you the right questions about it. If they can do a better job by gathering information from the project manager, that’s a good thing.
I’ll disclaim this post by saying hiring practices aren’t part of my job. But I’ve experienced varying practices from employers and potential employers, and some of them seemed sensible, some seemed ridiculous, and some seemed like the people looking for a programmer didn’t even know what they were looking for.
I’m curious to see how various shops do this. How do you evaluate potential new hires? Do you quiz programmers? How?

(Programming) Language Wars

So, given my blatant Rubyism, why did I link this video? Well, the first reason, is that it’s funny as hell, and really well written. Even the Ruby-bashing is hilarious… and any community needs to be able to laugh at itself. Sure, Ruby is kinda the faux-hawked hipster of programming languages at the moment. It’s also popular and in the spotlight because it’s FRICKIN’ AWESOME!!!

What I think is more telling, though, is the way this video presents the arguments of the stalwart defenders of PHP, who are usually the first-line Ruby haters. The number-0 argument I typically here in defense of PHP is along the lines of, “more large-scale, successful web projects are built on PHP than any other stack.”

Really? That’s what you’re going to lead with?

More (lines of) large-scale, successful, production code in the world right now is written in COBOL than virtually any other single language.

So by the same argument, COBOL is the BEST language for application development, right?

The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense.  ~ Edsgar Dijkstra

Okay, Dijkstra had a gift for hyperbole, but I don’t think you could make the argument that COBOL has any place in the modern computing world beyond the maintenance of billions of lines of legacy code already in the wild.

I’m not equating PHP with COBOL, nor am I suggesting PHP doesn’t have its place. It actually has two places. PHP is great iff:

  1. You’re maintaining a large, legacy codebase written in PHP, or
  2. Your employer/client/whatever has mandated that you use a certain PHP framework for the project.

Now, my personal inclination to case (2) is that it’s time to find a new employer/client/whatever. But that’s just me. I had a point when I started writing this, and ended up kvetching about PHP… it’s like a lot of conversations I have.

The topic I was ostensibly leading up to was that of language wars, or more generally, any of the Holy Wars geeks get up to. Like the Deep Magic, the Holy Wars began in the Elder Days. The canonical Holy Wars are such esoterica as big-endian vs. little-endian, Unix vs. VMS, Apple vs. Microsoft, Vi vs. Emacs, and so on. But you can really substitute [my favorite language] vs. [your favorite language], and so on. Some of this is just geek personality flaws traits shining through, making a choice of text editor seem like a life-or-death decision. On the other hand, I think there’s something else going on here. When you see true vehemence from the community surrounding an established, accepted language/framework/environment toward a plucky little upstart, a number of things might be happening:

  1. The old guard are threatened by something about the plucky little upstart, be it market share, mindshare, or something else.
  2. The old guard are jealous of the people who get to work with the plucky little upstart, and would rather bitch than upgrade their skillset and move on.
  3. The plucky little upstart is actually a complete crock, but for some reason nobody notices and/or cares.

The attitude of (some) PHP coders toward Ruby is reminiscent of how people thought of Linux in the late 90′s. It’s cute and all, but not for real-world, mission-critical applications. Real Unix came from Sun or IBM (guh!) or SCO. And this was also when Microsoft was making their ungodly encroachment into the datacenter.

One of my favorite (like, saved to my favorites on Twitter!) tweets ever comes from David Heinemeier Hansson, the creator of Rails:

Tweet from DHH

There’s always that. If I may be permitted to switch Holy Wars for the moment: IT professionals who don’t actually like computers LOVE Windows on the server for this reason, in my opinion. First, it’s brainless system administration. Secondly, it’s constant system administration. Sure, you can do everything through a GUI, but secondly, you’re doing it all damn day. So you need an admin for every few servers you add to your infrastructure. compare this to Unix/Linux servers, where uptime is measured in years rather than days (hours?), and although configuration requires, um, I don’t know, expertise or competence or something, one admin can take care of 50, 100 servers, natch.

I kinda feel like there might be some similar ill-will coming from the PHP camp toward Ruby. I don’t mean to defame PHP coders as a group. There are some excellent programmers working in PHP. But at the same time, I look at blog posts like Where Did All The PHP Programmers Go?, and it makes me think… the bulk of the PHP code I’ve encountered in my life is of truly dismal quality. Like, Visual Basic spaghetti-code bad. It’s painful. Again, there’s good stuff out there… but it’s hard to find. With Ruby, on the other hand, I haven’t seen much truly bad code. I spend a lot of time clicking around Ruby projects on GitHub, and most of the code I find is pretty decent. Good, even. I don’t think ruby programmers are inherently better coders, but I do think that a language like Ruby makes it easier to follow good design principles, and harder to implement truly bogus crocks. whereas PHP lends itself immensely to bogus crocks (variable variables, anyone?)

This isn’t meant to be an objective comparison of programming languages. More of an extension of my previous thoughts on why I love Ruby so much, expanding more into the area of languages you really couldn’t pay me to work in, in this day and age. And thinking about why. If you feel strongly about languages (whether you’re a Rubyist or a PHP die-hard or none of the above), please tell me why in the comments.


Italian Retardedness, Google, and the Open Web

Google Loses Autocomplete Defamation Case

The above story, from slashdot.org, just reinforces my already solidified opinion that the world is ruled by stupid.  This belief is fairly common to those of us who work in IT; it’s reaffirmed each and every damn day.

If you’re unfamiliar with the story, here’s the /. summary:

Google has been found liable in an Italian court for defamatory comments made against an anonymous plaintiff — the complainant’s name, when googled, elicited autocomplete suggestions that translate as ‘con man’ and ‘fraud.’ Google was found not to qualify for EU ‘safe harbour’ protection because the autocomplete suggestions were deemed to be Google’s own creation, and not something merely passing through its systems.

Riiiiight… here’s the problem, though: Google’s autocomplete suggestions are essentially user-generated content. If people commonly search for your name along with the terms ‘con-man’ and ‘fraud’, those are going to show up in autocomplete. That’s how the (excellent) algorithm works. The bigger problem comes down to this: in most (civilized) countries, courts have held that blogs are not responsible for the content of user-generated content, i.e., comments, etc. Copyright infringement is one thing, but short of a DMCA takedown notice, if someone comments on your blog that “Bill O’Reilly is Hitler’s lovechild,” that opinion is owned by the commenter, not the blogger. This ruling is essentially making (in Italy) user-generated content the responsibility of the site operator. OK, a search algorithm is not a blog. And I don’t know the specifics of the case. And IANAL. But this much is clear:

  1. Italian courts are offensive to the notion of justice. Far be it from me to defend the way the United States does anything, but I think most people will agree that any civilized notion of justice affords the accused the right to challenge the accuser to his/her face. Otherwise, we get secret military tribunals, Gitmo, and… oh, wait, I’m just defending the way the US used to do things. I feel better.
  2. An algorithm is not an act of volition. Libel should require intent, or at least gross negligence.
  3. Italy is fucking with my lulz. Srsly, have you seen some of the funny crap that comes up with autocomplete on Google search? I work in IT. I need my autocomplete-me’s on failblog.org to get through the day. If frivolous, retarded lawsuits like this eff that up, I’m going to blow a damn gasket.
  4. Fuck Italy. When China wanted to mess up Google’s mojo, they just shut down their China operation. If I were Larry Page right now, I would immediately shut down google.it and tell the Italian courts to suck it. If Egypt and Libya have proven anything, nothing pisses off a populace like fucking with their interwebz. Maybe the Italian people will revolt, hang the judges from the highest rafter, and institute a slightly less-retarded government. Here’s hoping.

Yes, this post has been over the top, hyperbolic, even. But really, Italy? Defamation by autocomplete? I hope Google removes ever .it entry from their free DNS service, shuts down google.it, and sends your tech sector back to 1997. Because this is some fucked up shit.


BbWorld Transact

So, for those of you who don’t know, I work in the ID Card Services Systems team at Johns Hopkins University. Most of my (paid) development work involves creating a custom, (mostly) Ruby on Rails web interface to the Blackboard Transact transaction processing system. It’s pretty interesting work, adapting Rails/ActiveRecord to this proprietary database format to do all the things we want it to do. Sometimes it’s frustrating, especially with dealing with importing data from other departments’ maddening stovepipe systems, but, all in all, pretty rewarding. And then it all got exciting.

Last week, our team went to the BbWorld Transact conference at the Talking Stick Resort in Scottsdale, Arizona. Not only was it great fun to head out to the Southwestern desert in March, escaping the Mid-Atlantic doldrums, but it was a truly exciting and invigorating experience.

Sure, we were giving a presentation on the web app I’ve developing for the past seven months or so (read: 9,383,094 years of ASP development or 87 years of PHP development, subjective time), and that was pretty damn exciting. So was the response. People were crowding the table at our session collecting our business cards, hoping we could get permission to put this code up on GitHub (I hope so, too).

But what’s got me the most pumped was my experiences of the conference itself. Starting with a keynote from Bridgeworks, LLC, about “millenials” and the desire for connectedness, the conference delved into a new commitment to openness and transparency from Blackboard, which, as a developer, gets me psyched. There’s nothing like support from the vendor supplying the system you’re developing against.

We had some great meetings with the Transact product development team, as well as Sony‘s FeliCa team, and I haven’t been so excited about the code I’m getting (paid) to write in a long time. Already, we have proof-of-concept code in the works to do Twitter tweets and Foursquare check-ins via card swipes.

The coding is only going ot get sexier from here on out.


Why I love Ruby (part 2)

II was going to write a second installment, but I think DHH has said it all for me…


B’more on Rails

So I’ve been meaning to do it for a while, and tonight I finally made it to a B’more on Rails meetup. Damn, was it worthwhile. Jeff Casimir of Jumpstart Lab gave a presentation entitled “Fat Models Aren’t Enough,” and damn if it didn’t change my opinion about the ActiveRecord scope method… and give me some awesome refactoring ideas.

One of the best funny-because-it’s-true moments of the evening was this quote in big letters on the screen:

I don’t know how much more emphasized step 1 of refactoring could be: don’t touch anything that doesn’t have coverage. Otherwise, you’re not refactoring; you’re just changing shit.

It’s a quote from this blog post, which I highly recommend. (Thanks to Jeff for tweeting me the URL while I was writing this post.)

Anyhow, It’s late, and I can’t possibly recap Jeff’s great presentation (my notes are in the other room, and I’m lazy), but if you missed it, you’re in luck: he’ll be presenting on this topic at this year’s RailsConf, May 16-19 right here in Baltimore. Definitely check it out.


Why I love Ruby (Part 1)

So, it occurred to me that so far, my posts (both of them) have been pretty negative. So I thought today, instead of ranting about something I detest, I’d rave about something I love. And that something is Ruby. I looooove Ruby. I got into Ruby because of the Rails web application framework, but my love of Ruby goes so far beyond Rails. Let’s start with a quote from Yukihiro Matsumoto (Matz), the creator of Ruby:

For me, the purpose of life is, at least partly, to have joy. Programmers often feel joy when they can concentrate on the creative side of programming, so Ruby is designed to make programmers happy.

Ruby definitely brings the joy. Oh, does it ever bring joy. Have you ever coded in something like PHP or C++, and felt like you were fighting the language to accomplish your task? This common phenomenon is absolutely absurd. Tools should make the job easier. This bears repeating:

TOOLS SHOULD MAKE THE JOB EASIER!!!

I like tools that make the job easier. This is why I only use Unix-like operating systems, because they have many small, convenient tools that make life infinitely easier. I’ve never understood how people could assert that Unix (or Linux, etc.) isn’t user-friendly. It’s the most user-friendly OS that has ever existed… it’s just selective about who its friends are. But, back to Ruby.

Ruby knows exactly who its friends are: programmers. It’s the most programmer-friendly language I’ve ever worked with. It’s designed from the ground up to operate on the Principle of Least Surprise. What this means is that the irritating gap between what you want the computer to do and what you actually told it to do becomes a lot narrower.

Ruby was also developed slowly, and thoughtfully, from the ground up, using the best-of-the-best from multiple programming paradigms, and from the best-of-breed languages from each of those paradigms:

  • Smalltalk: Smalltalk was the first object-oriented programming language, invented by Alan Kay at Xerox PARC in the late ’70′s and early ’80′s. Ruby draws its pure-OO object model from the language that started it all, and this adds to the joy of object-oriented programmers.
  • Lisp: Probably the first full-fledged functional programming language, Lisp has a storied history of use in academia and the AI community. From Lisp, Ruby inherits its concepts of closures, lambda functions, and tail call optimization, which make it possible to do very function-oriented things in this pure-OO language… I won’t go into the guts of why tail-recursive functions are a Good Thing, or why closures add to programmer joy… but the guy who said “Ruby is like Lisp, but with syntax” wasn’t wrong.
  • Perl: Ruby has less of the Perl-paradigm than it has of the paradigms of Smalltalk and Lisp, but it shares much of the Perl-nature. Ruby has powerful text-processing and regex capabilities which were non-existent before Perl (don’t even bring up sed and awk). It also borrows some rather random things from Perl; Gems follow the CPAN paradigm to a degree, Ruby can handle shell one-liners much like Perl, and Ruby is actually great at most of the system administration tasks that Perl started to make easier in the late ’80′s. Procedural Ruby scripts even tend to look a bit like Perl scripts, but maybe that’s just because so many of them are written by old Perl hackers.

So, Ruby took the best concepts from the best of the best, and worked them into a masterpiece of language design. Compare the evolution of something awful like, oh, I don’t know, PHP.  Jeff Atwood of Coding Horror and Stack Overflow fame puts it rather well:

From what I’ve seen of it, PHP isn’t so much a language as a random collection of arbitrary stuff, a virtual explosion at the keyword and function factory. Bear in mind this is coming from a guy who was weaned on BASIC, a language that gets about as much respect as Rodney Dangerfield. So I am not unfamiliar with the genre.

PHP first emerged as a subset of Perl for embedding code inside of HTML, mostly. Think about that for a minute. Now think about Unobtrusive JavaScript, and the whole thrust of behavioral separation, getting the code OUT of the markup. Surely, we now realize that PHP was misguided from its inception? But this is beside the point. What PHP should demonstrate is that a programming language should evolve programmatically, not organically. PHP was never planned, it was just vomited upon the world as a mass of kludges and spaghetti code.

The development of Ruby was the polar opposite of this. Ruby was planned, designed for the sake of programmer joy. And programmer joy is, IMHO, derived from a few core experiences. I don’t claim this to be a comprehensive list, but some of those include:

  • Not having to re-invent the wheel every damn day: Ruby makes it a breeze to write re-usable code. If you find yourself violating the DRY principle while coding in Ruby, you’re doin’ it wrong.
  • Avoiding repetitive, unnecessary keystrokes: repetitive-stress injuries are an occupational hazard. If a language reduces the number of keystrokes you’re having to enter by an order of magnitude, that’s a Good Thing.
  • Principle of Least Surprise: I mentioned this earlier. Ruby’s core libraries follow class and method naming conventions fairly rigidly, so you know that a method anding in ? is going to return a boolean, and a method ending in ! is going to modify the object in-place. And this principle has been followed quite closely by gem (library) authors. So I know if I call @variable.foo?, it’s going to return true, false, or possibly nil, but not a String or Float or anything else.

This post has outgrown my intentions for it, and there are so many more resons to love Ruby, that I’m going to have to continue this later… look for Part Two soon.


    Of Kids and Computers

    Something I was reading tonight reminded me of my experiences of what has come to be called “educational technology,” or, basically, computers in schools.

    I was educated in the glorious Baltimore County Public Schools, and computers were a major part of my academic career from the beginning. I think it was in the third grade, when I started getting called to the office on a weekly basis… not because I was in trouble, but because the office LaserWriter was damaged (well, was succumbing to luser error) and no one actually employed by the school could “fix” it.

    My mother was a teacher in the glorious BCPS, so I had more direct involvement with their EdTech department than most students. I knew the admin passwords for most of the software and the “AtEase” interface for Macintosh computers that kept kids out of the OS internals.

    One of the most telling moments came in the 8th grade. I was in the library working on an assignment, and was moving my print jobs to the front of the queue, as was my wont. This involved no passwords or privilege escalation, it was available to any competent user. A new librarian came over and scolded me, saying that the Mac Print Manager was “not for you to use.” I glared, and instantly told the head librarian, also one of the school’s EdTech liaisons… she gave the new librarian quite the dressing-down, right in front of me, telling her basically, “let him do what he likes, or he won’t fix our computers and we’ll have to wait three weeks for someone from the Board of Ed.”

    This was my first experience with the idea that being a geek was something powerful. Sure, I knew I could create new worlds and new vistas of experience through programming but this… I had an ability that other people both valued, and kinda feared. This was power.

    But want I want to get at, is that much like the beancounters who are allowed to make technical decisions in most businesses, most of the people who make technical decisions in education are retarded monkeys. Case in point:

    Toward the end of my K-12 academic career, the glorious BCPS made the shift from Macintosh computers to Windows boxen. I will point out that this was roughly around 2000. Why is this significant? Because up until 2000, the Macintosh was useless to anyone who really wanted to understand anything about computers. At least with a PC, you could drop down to a DOS shell and do something relevant. The Mac had no CLI. But then, there was hope. Apple, fighting for its life, brought back Steve Jobs, the Golden Boy, and bought NeXT, with its UNIX OS, and used NeXTStep as the basis of Macintosh OS X. Now, I’d been using Linux since about 1995 or 1996. This was great news. I thought that now, kids everywhere would be learning how to use a POSIX-compliant OS. Then my mother, the teacher, told me she had bought herself a Dell because they were moving everything to Windows XP boxen.

    FACEPALM.

    Apparently, Apple’s financial troubles, and the pressures of parents who wanted their kids to learn ‘real-world’ computers, had created a new customer base for Microsoft: our local school system. It didn’t matter that this was as retarded as fuck, or that the cracks in Microsoft’s ‘emperor’s new clothes’ pseudo-superiority had begun to show… no, some beancounters had made a technical decisions again. And down that road lies madness.

    This isn’t really a rant; just a story. Perhaps a morality play. Beancounters should be allowed to make technical decisions when hell freezes the fuck over. And on that note, one of the best sources of catharsis for harried techies:  The Bastard Operator From Hell Archive


    Follow

    Get every new post delivered to your Inbox.