Archive for December, 2008

jQuery thoughts

December 23, 2008 Leave a comment

So my project for the last … *checks FTP logs * … 6 months has been a PHP-over-MySQL web interface for accessing the MySQL data and doing all kinds of representative statistics and generally taking a lot of raw data and compressing it in to useful information. Hmm; I guess that’s basically “Business Intelligence” in a nutshell.

So anyways, over the months, I’ve done a lot of revamping, including taking a strictly HTML-based set of form selectors into the unfamiliar waters of AJAX. Overall, it has been pretty good: JavaScript is a (purposely) very C-like language, which means that it works, syntactically, very similar to Java, C, etc. It has wacky functions and weird ways of doing some things — getElementById, I’m looking at you! — but it maps pretty easily on to previous knowledge.

So, in this context, expanding to use AJAX was just a matter of learning to use the JavaScript faculties for such things. They are, admittedly, pretty primitive, but there is something very pedagogical about reinventing the AJAX wheel by writing your own code to craft and send each asynchronous request.

But it all seemed very 1999: surely people don’t accomplish huge projects in JavaScript. So I decided I would take a look at what was purported to be the best JavaScript library at mixing simplicity and functionality with terseness: jQuery.

The problem with terseness is that it’s a two-edged sword. As a programmer, I almost always err on the side of verbosity. Code should, generally, document itself, which means it has to be relatively plain in its operation.

So this philosophy has come into sharp relief running up against jQuery. What am I talking about? Here’s some jQuery code:

 $(document).ready(function() {
   $("#reset").click(function() {
     $("form").each(function() {

That says that, when the document finishes loading, get all the page elements with the “#reset” id, and bind each’s .click to reset the form that it is a member of. Okay, problem one that I’m finding with jQuery: there is next to no assignment. From what I have seen (which isn’t a lot, so bear with me), you never set an item’s .click() operation by saying = bar(), you set it by calling

Read in the mindset of C-style syntax, that looks like you’re calling foo‘s .click() on bar(). But, whatever. It has its own code style: that’s cool. Get used to it.

The idea, I assume, is to make everything effectively fit on one line, logically. The above snippet is 7 lines, with 4 semi-colons, but it’s all nesting. That is, programmatically, one line. Which means you could shoe-horn that whole thing in to an onclick on a JavaScript element, or some such.

If you haven’t figured out the problem with this mindset yet, here you go:

$(document).ready(function() {
   $('#faq').find('dd').hide().end().find('dt').click(function() {

Notice the extreme chaining of functions one on to another in there? Each one does something, but all the statements are stuck on the same line. And then we reach that .end() call, which basically says, “We’re done here”. Its a way to put two discrete statements on the same line. It’s an in-line semi-colon. I’m utterly baffled why the code can’t be split up on to two lines as follows:

$(document).ready(function() {
   $('#faq').find('dt').click(function() {

I mean, it’s two discrete code operations that just so happen to operate on the same item. The only thing I can reckon is that by splitting the statement among two lines, you save having to look up $('#faq') twice because neither JavaScript nor jQuery can cache a pointer to the object. Okay, fine.

It’s still client-side scripting code that will have a rather minimal overhead in doing the look-up twice and increase readability immensely, at least to this beginning jQuerier.

I hope that in my studies, I come across some kind of enlightening revelation as to why this design is encouraged from the first moments you touch jQuery. Maybe there’s a good reason. But from where I’m sitting, it just seems like the developers lost their footing on the slippery slope of extreme terseness and began to value packing everything on to one line over maintainability.

They must not be paid by the line.

Categories: Uncategorized

Ironically, this is a short post

December 17, 2008 Leave a comment

After the IDPA matches at the local range, folks will regularly retire to a local eatery for dinner and conversation, which often turns into some interesting topics.

After December’s match, one of the Safety Officers, David, advocated for a thesis that there is an interesting trend in society towards the sound-byte, a symbol of overcompressing information in to a very concise expression of events. The analogy that was brought up was football: a single football play is like a news show sound-byte. It doesn’t tell any kind of story, and by itself is interesting and exciting, but doesn’t really inform you of how the game went.

I’m not really doing the conversation justice, but it eventually meandered over to the fact that baseball used to be America’s Pastime: a sport that takes precisely as long as it takes. No timers, shortened games, or ties. Both teams play all day, until one wins. This was put up in contrast to what seems the most popular sport these days, football. (If you don’t believe me, compare the festivities around the Super Bowl to those for the World Series.)

So where’s this all going? Well, a few days ago, my dad reported on an idiotic attempted protest on Facebook:

Administrators don’t care about what we think !
But what will happen if we all decide to stay off of facebook for 1 day !

Please invite all your friends in this group so that we could really make an happening on December 15th!

There seems to be a common thread here: trying to compress something that took as long as it took (a strike, a sit-in, other types of real protest) and compress it down in to something that’s limited in time and scope (a one-day boycott) and hoping that the magic of living in the future will make the results equivalent.

Nazzo fast, guido.

Categories: Uncategorized

More like “cluster-duck typing”

December 15, 2008 Leave a comment

This post about Python from Ted Dziuba about how it can make him uneasy has really hit home with me.

In my C/Python class, a lot of people moaned about why they had to learn Python (more vehemently than why they had to learn Differential Equations), and would bring up the flaws of Python. Out of this, I came to realize that Python’s desirable features are, in part, its syntactic sugar. Things like list comprehensions and the ease of using for loops, as well as the built-in data structures: lists, tuples, dictionaries, and sets.

But I find that what doesn’t particularly attract me, and actually makes me nervous as it does Ted, is Python’s “Duck Typing“:

In computer programming, duck typing is a style of dynamic typing in which an object’s current set of methods and properties determines the valid semantics, rather than its inheritance from a particular class. The name of the concept refers to the duck test, attributed to James Whitcomb Riley, which may be phrased as follows:

If it walks like a duck and quacks like a duck, I would call it a duck.

So, basically, it doesn’t matter whether an object actually is a duck, you just treat it like a duck and hope that you’re right. This sounds pretty sketchy to me, and Ted points out the potential pitfalls in his post, but what really gets me is the preemptive defense of the technique in the summary paragraph of the Wikipedia article:

Users of statically typed languages new to dynamically typed languages may want to add such static, (before run-time), type checks which defeats duck typing, constraining the language’s dynamism.

“Constraining dynamism”? ‘Scuse me, but what the fuck is that supposed to mean? Of course, it seems to be a sort of high-minded way of calling the statically-typed language users uneducated rubes who don’t understand the “dynamism” and need to put down their strongly-typed stone knives and well-structured bearskins and step into the warm, enveloping folds of Duck Typing. Or, something.

But, whatever. So you treat your objects like what you want them to be, and then you just deal with it when the situation arises that you didn’t get what you expected. And how do you do that? That’s right, exceptions.


Easier to ask for forgiveness than permission. This common Python coding style assumes the existence of valid keys or attributes and catches exceptions if the assumption proves false. This clean and fast style is characterized by the presence of many try and except statements.

That’s right: you put your code in a “try:” block, and then put “except:” blocks after it to catch any exceptions or errors that might arise during the try block. How it is “cleaner and faster” to test for error conditions after executing the code instead of testing whether your input will cause an error condition is not clear to me. But I digress.

This is all making kind of sense until right about here when it breaks down: how do you tell what exceptions or errors your code might throw? In Python, there is no enforced way of determining this.

If you’re lucky, the guy on the project before you documented all the possible errors and exceptions in a nice descriptive comment at the top of the function. If you’re unlucky, the fresh-out-of-school kid who thinks Python is a pretty rad take on Java (the language of Computer Science) whose code throws a ShitJustGotRealException because he wasn’t sure exactly what might be the cause. Shit can get super-real when you treat ints like tuples, bro.

This is where the “asking for forgiveness” breaks down: if you don’t know what you did wrong, how can you ask to be forgiven? Short answer, you can’t. You just have to apologize for everything and go do something else.

And the guys at Python seem to know this is a problem: they implemented a tiny slice of a solution in their recent major 3.0, backwards-compatibility-shattering release, but all that it essentially does is give more room for the coder to add comments. It doesn’t add any kind of explicit type-checking and it sure won’t correct you if you start trying to treat a long like a String. After all, you expected a long, right?

Categories: Uncategorized

Learning to Learn

December 8, 2008 3 comments

I was riding the bus back from my first exam today when I began mentally transcribing the guitar part of a song I was listening to, a song on my Zune that I’ve heard countless times — but never quite like this before. But that song’s not what this is about.

It’s about the fact that I noticed that I could tell the subtle differences between chords. Not quite enough to be able to name them at will, but enough to get a good guess of the rhythm pattern of this particular song. Somewhere along the way, in the year and a half since I first picked up my guitar, I picked up that ability, as well as a decent sense of being to tune a guitar by ear.

Now, this is notable because when I first began, I had no idea how to do these things. Heck, when I first got my guitar, it was, obviously, out of tune. But with only a cheap tuner and no instructions, I had no idea how to go about tuning it. At the time, the abbreviation of EADGBE was just gibberish to me. So I just fretted chords on this out of tune guitar and played them.

“Is this what music sounds like? It doesn’t sound that great, but who am I to say what is and isn’t musical?”

I had no real basis of comparison, no reference frame to place the guitar in to. Music, or at least, music theory and the idea of harmonious notes, was a more or less foreign concept to me. So, given this lacuna, I wondered if I would ever be able to learn to do simple musical tasks like playing basic songs by ear and tuning a guitar by ear.

This was actually a pretty big worry for me: I wondered if my fertile learning period of childhood had been passed up without ever introducing the language of music to my mind —

Err, sorry about that. “Back in Black” came on the radio and I was compelled to play along.

Where was I? Right: being unable to learn the language of music so to speak.

My real worry was that it was Too Late. Was this old dog too old to learn some new tricks? After all, my parents never enrolled me in any music classes or instrument lessons to teach me the basics when I was young and my brain was more of an information sponge than it is today.

Well, sure, it’s easy to blame them, but on reflection, I find that it’s an excuse instead of a justification. My paternal grandparents made sure to send their three kids to music lessons of various types, and only one of them ended up sticking with it. I don’t say this as a way of shaming anyone, but instead to point out that unless you really want to learn to play, even the best music teacher can’t really help.

And that’s when I realized that my parents hadn’t failed me: they didn’t just give me the fish, they taught me to fish. The drive to explore, learn, and grok music, and any other topic that interests me is what I got instead of a book of songs with gold stars awarded for successfully played music pieces.

Categories: Uncategorized