The whole reason that voter registration is required before you’re allowed to vote is so that the local and state election boards can have a chance to verify your eligibility. If you submit more than one registration, it may cost them a few minutes of work to update or reject your registration records, but it won’t allow you to vote more than once.

So, if it doesn’t let people “vote early and often,” why in the hell would ACORN, as an organization, have such a poor record regarding bad registrations? It’s simple: they require their workers to meet a certain quota in order to get paid. I’ve done a bit of volunteer voter registration, and while it’s easier than many other types of direct-contact political work — fundraising and candidate canvassing are both harder, if only because of their inherent partisan focus — you still have good days and bad days out on turf.

Try to imagine yourself in the following position: you’re a high school or college student trying to make a little money over the summer, while still doing something a bit more proactive than flipping burgers. Furthermore, your meager paycheck is dependent on hitting your quota each and every week, and you’ve heard horror stories of the poor-performing workers who got canned just last month.

Now, imagine you’re two registrations short of your quota for the week. Would you be even a little bit tempted to fake one, or press that nice stranger who insisted they were already registered to do so again, in order to save your job? I suspect that most people, if they’re being honest with themselves, would answer at the very least that they might be at least a little bit tempted. I know that I would, which is part of the reason that I’m not very interested in doing any paid political work — as a volunteer, the temptation to cheat goes away.

(Please note that I’m not trying to defend this sort of behavior as ethical, but it is at least understandable.)

Personally, I think the interesting argument isn’t even about whether ACORN does a good or bad job of supervising their staff, or encouraging the right behaviors. The real debate we should be having is whether paid voter registration does more harm than good. The same question extends to signature-gathering, an especially hot issue in Oregon given the recent flood of bad ballot measures.

I personally haven’t decided one way or the other, but I think that a much more constructive discussion is there, waiting to be had, once we get past the current baseless accusations being leveled at ACORN and its partner groups.

I had surgery to repair my broken ankle this sumer. I also have fairly good health insurance through my employer. So, when the pre-billing statements from the hospital, surgeon, and anasthesiologist started showing up, I didn’t panic, even though the total bill (>$15K) would have been pretty tough for me to pay out-of-pocket.

When all was said and done, and my insurance had been fully invoked, I ended up owing a little under $1500. Seems pretty good, right? 90% coverage is good enough for all but the most expensive medical issues, and even significantly more expensive bills might be manageable under some sort of payment structure.

However, of that more than $13,000 that was “covered,” my insurance company actually only paid about $4000. That’s because they drive down the cost of everything else via contracts held with the hospitals, along with a healthy dose of strong-arming of doctors and specialists. (”If you want us to cover any of your patients, you’re going to have to accept 30 cents on the dollar for this procedure.”)

While that doesn’t directly affect me, it does mean that prices have to be that much higher for everyone without insurance. Without the insurance companies to negotiate on their behalf, they’re stuck paying extra to cover the gap between the real cost of care and what the insurers will pay.

We need a comprehensive Federal health plan that covers everyone if we’re going to have any chance of getting a handle on the cost of health care. Leaving those with the least all on their own to try to negotiate for care is neither fair nor sustainable.

</political-rant>

Generally, both platforms mostly abstract away the underlying UNIX-y system, and heavily sandbox 3rd-party applications to limit their ability to corrupt or expose the user’s data. Android gives users more options to replace or augment core applications, but the underlying sandbox mechanisms remain in place — i.e., an app can’t access your contact list unless you explicitly grant it that privilege at install time.

Also, both platforms rely heavily on code signing. You can’t distribute an iPhone app through the App Store unless it’s been signed with an Apple-issued certificate; The Android OS, on the other hand, allows developers to use the certificate of their choice to sign apps. (Carriers could lock this down further, of course, but there’s been no indication that such a lock will be in place for the G1.)

In terms of the actual toolchain, there are some major differences. While the iPhone uses a simple cross-compiler to build Objective-C projects, the Android tools are designed to support compilation to VM bytecodes, which are then transferred to the mobile device and JIT-ed in place. The XCode/Eclipse distinction is really one of personal preference, and both systems provide first-class support for command-line compilation and packaging, so you could configure Emacs/Vim/TextMate/etc. to handle project build tasks.

I also have the sense (and this is where my lack of access to the full iPhone SDK becomes a problem) that that the iPhone tends to package shared services as Framework libraries (ala OS X) while Android relies on a high-level IPC framework and reusable sub-processes (called Activities) to allow applications to invoke each other to perform common tasks.

Of course, one of the biggest distinctions to my mind is that Android projects can make use of multithreading and background daemons (Services in Android-speak) to handle long-running and GUI-less tasks. The notification APIs provided in the iPhone may cover a lot of asynchronous messaging use cases, but having full use of threads opens  up a lot of other interesting possibilities.

Overall, both platforms offer an interesting environment to work with. iPhone apps are likely to be less inter-dependent, with better protections against any one badly-authored app causing the phone’s performance or battery life to suffer. However, iPhone developers will struggle much more than their Android-targeting-colleagues to find ways to integrate their applications, both due to their inability to coordinate between simultaneously-running threads, and due the the NDA’s restrictions on information-sharing amongst themselves.

We rocked it. Oh yes we did.

You wanna know how lame I am? I didn’t even take this picture. That’s how much I’ve been slacking on the blogging and photographic fronts.

Unfortunately, I’m still chafing a bit at a number of little annoyances:

• The REPL is basically crippled since you can’t define functions. Being forced to think in terms of compilation units (rather than simple expressions) pisses me off.
• Why oh why do I need to explicitly list the module name in my file header if I’m also bound by the restriction that filenames and module names have to be the same? The old Java package/file path ties were always a big annoyance when I was stuck in that environment.
• For a functional language, there’s an awful lot of syntactic vinegar for basic operations like map and fold. I appreciate having a concise syntax for lambdas, but writing fun my_function/2 smells a bit.
• Records (as syntactic sugar for tuples) are a poor substitute for a real type system. Both tutorial and real-world Erlang code I’ve seen is basically full of tagged tuples, which means you get the verbosity of a strongly-typed language without any of the ability of real type checking to catch errors at compilation time.

I want to stick with it long enough to find the real gems underneath all this noise. I mean, if I can sit through extended sessions reading and writing Perl, I should be able to find something to love about Erlang. Furthermore, most of the complaints I make above are inapplicable to mainstream languages — i.e., C and Java dont have an REPL or lambdas, and Ruby and Perl don’t have anything resembling a traditional compiler — not miraculously better.

I definitely think that learning a new language should make you feel a little bit uncomfortable. Unfortunately, right now Erlang leaves me feeling uncomfortable in all the wrong ways: I understand everything that’s going on with the language, and just don’t like it.

I’m going to keep plugging away for at least a little bit longer, though. Next up: reading the source to EJabberD to (hopefully) get a sense for idiomatic language use in a context where its unique features (lightweight concurrency + distributed computing) are a real advantage.

The nicest surprise has actually been just how well Ubuntu worked out of the box. Wireless, video, webcam, and both pointing devices worked right off the bat. One well-documented config tweak later, and I had suspend/resume (and fast, too — just about as good as my MBP). Audio took a bit more work, mainly because Ubuntu distributed an older ALSA snapshot. Once I re-compiled the audio drivers from the latest ALSA release and moved the Ubuntu versions aside, I had loud, clear sound.

I do mean loud, too — the built-in speakers on this thing is significatly louder than my MacBook Pro, or any other X-series ThinkPad I’ve tried (X24, X41, X60). Since music + video are a big part of what I do with a laptop, that’s actually really nice to have.

Overall, this is a machine I can highly recommend. The 1.2 GHz processor and integrated graphics chip should feel poky compared to my year-old but faster-on-paper Mac, but the solid-state disk helps quite a bit, and certain key applications (Firefox in particular) just feel faster under Linux than they do on OS X.

I’m unlikely to work as a proprietary desktop software developer any time soon, given that I haven’t tried to write a desktop GUI application in about five years, but I do appreciate the work that Panic puts into polishing their user experience, and have a great deal of respect for them as a development team. And so, it was extremely refreshing to me to see many of the fears and frustrations I’ve expressed about the iPhone/App Store platform lock-in as an outside being echoed by someone who is working within that ecosystem.

One realization I had early on in my IT career was that almost any two firms could easily become competitors. Given the rate at which a competent team can develop most any class of application on the planet, and the generality of the platforms on which our code runs, it is entirely conceivable that your platform vendor of choice today (or your client buying your tools or OS) could become a direct competitor tomorrow. For that very reason, trusting the future of your business to the continuing benevolence of a vendor is a very risky decision.

Every developer working on applications for the iPhone/iTouch platform is in exactly that precarious position right now. Those innovative applications that drive sales of the platform could easily be incorporated into the next release of the OS, since Apple has more than enough resources to re-implement any 3rd-party app without breaking a sweat. (There is certainly precedent for this: just ask the developers of Watson what it’s like to one-up Apple in the system utility space.) Even worse, truly disruptive applications that offer capabilities beyond Apple’s comfort zone (or that of one or more of their mobile network providers) could find themselves summarily dropped from the App Store, effectively strangling any business the developer hoped to build around the product.

This is, to me at least, an unacceptable bargain, and I’m surprised that so many other developers seem to have no problem with the arrangement. (Have I mentioned how much I can’t wait for Android?)

klass = Foo::Bar
# ...
klass.extend(Some::Module)

This is a programmatic mixin — it adds the methods defined in Some::Module to the class Foo::Bar for the duration of the current Ruby process. It also does so for all instances of Foo::Bar, whether defined in some scope known to the caller of extend or not.

If may not look like it, but this is yet another case of monkeypatching. The only reason you don’t see it being denounced up and down the ‘tubes like, say, overriding method_missing on NilClass is that it’s usually confined to an application or framework-specific class, like ActiveRecord::Base.

Now, I’m all for the judicious use of powerful language constructs like open classes, but they can be a problem for large-scale projects, or those where collaboration between team members is less-than-perfect. The global and persistent scope of a class-level #extend call like the above can cause unexpected side-effects, too.

As an alternative, I humbly propose the use of instance-scoped extensions. In cases where not all instances of a class may need the additional functionality provided by the mixin, try calling #extend on just that instance. It keeps your namespace clean, doesn’t introduce as many potential pitfalls for code in other scopes, and is reversible: just nil your current reference to the object, and re-create it without the mixin.

Here’s an example, cribbed from some refactoring I’m doing of a web service implementation:

def change_password
  token = AuthToken.find(params[:token])
  active_user = Account.find(token.identity)
  password = params[:password]

  raise ArgumentError, "passwords did not match" unless password = params[:confirm_password]

  if token.has_privilege?(:password_reset)
    active_user.extend(PrincipalManagement)
    active_user.change_password(password)
  end

  render :xml => Account.to_xml
end

One reason this is expecially handy for me is that I can re-use the same model core model classes (like Account) in different applications, only some of which may have the privileges necessary to change passwords, delete accounts, etc.

By limiting the mixin to a single model instance within the scope of a single request, I also protect myself from coding errors that might expose dangerous mutators to untrusted callers. Any attempt to call change_password (or a similarly-restricted method) from outside a scope which explicitly included the mixin will raise a MethodNotFound error, without any additional access-control checks on my part.