Joshua Go

Up until now, the JavaScript I've written has typically been in pursuit of a bigger goal. This means that I worked around language quirks on the spot and moved on. I never stopped to consider the nitty gritty details of the language for commitment to long-term memory, because I wanted to get a working end product. Recently, someone asked me about the best way to check for undefined JavaScript variables. I found myself at a loss, which was alarming to me since doing these kinds of checks is immensely important, practical, and a frequent fact of everyday programming no matter what programming language you're using. The fact of the matter is that most of the time, I know where my variables are coming from. Something like this would work: var x; if (x) x.some_method(); else alert("we can't use x"); In the vast majority of cases where I had to perform a null check, I knew that the variable was declared somewhere because it was of my own maki

Sometimes there are good but non-obvious reasons for keeping the status quo. Competing interests may have, over time, been balanced and counter-balanced to form a functioning ecosystem. And as with any ecosystem, reducing the functioning whole into its constituent parts in the foolish pursuit of extracting isolated benefits is an intractable problem. Other times, the status quo represents a deeply flawed system, fundamentally broken at the core. Such a system is characterized by people in power whose actions are driven primarily by the overriding interest in preserving their own favorable position, to the recurring detriment of the less favored. The tough part is looking at a situation and making the call as to which one of these models applies. In some cases, the status quo may be made up of both a well-balanced system with benefits to all, as well as a rotten portion entrenched for no good reason but the preservation of the holders of power. Fixing what's broken is a separate pro

Through my entire time as a student, I never used Cliffs Notes or SparkNotes in place of assigned reading. I made it a point to read every book I was supposed to, down to the last word. The trouble for me was that everyone else who resorted to these "study guides" knew enough about the real books to do well in their classes. From the perspective of efficiently using my time to reach the objective of a good-enough, basic understanding for writing essays, discussing the books in class, and impressing teachers, I lost out. I remember one book in particular. Crime and Punishment really broke a lot of people, many of whom were like me and had, up until then, insisted on reading the book and not the summary booklet. But I was determined. I was hellbent on savoring that book and milking it for all it was worth — calculus, biology, and economics be damned. As expected, I ended up with the same general recollection of the book's contents as the more reasonable folks who resorte

Often, you want to look for a particular pattern within a string. Let's say you know that you want to look for the string "revenue" inside a given string. function match_string_for_revenue(string_for_searching) { return string_for_searching.match(/revenue/gi); } var our_string = "We are looking for ReVeNuE."; alert( match_string_for_revenue(our_string) ); You can store the pattern as a regular expression in its own JavaScript variable, which makes your code more readable and its intention better known. function match_string_for_revenue(string_for_searching) { var pattern_to_look_for = /revenue/gi; return string_for_searching.match(pattern_to_look_for); } var our_string = "We are looking for ReVeNuE."; alert( match_string_for_revenue(our_string) ); But what if you want to generalize this matching and be able to search for any given pattern? Can you make it vary based on a parameter given, instead of keeping it in the code? /* NOT GOING TO WO

By and large, the received wisdom when it comes to configurability and flexible settings for web applications is that more is better. Making something configurable frees up the engineer from having to make mundane (but necessary) changes that can be left to other people. It's desirable to change the state of software without having to rebuild or redeploy the code. There are a lot of obvious benefits to making software configurable, and these benefits are plain to all. What I'm going to focus on here are the costs of configurability, based on my experience and observations over five years of writing web applications full-time. These costs apply to other kinds of software beyond the realm of web applications. I just choose to limit the scope of discussion to web apps because these costs manifest themselves the most when there's a fast development cycle and rapid iteration. The following is intended to be a comprehensive, itemized breakdown of the costs of making an applicati

So why, in 2009, in a world of RIA frameworks, web-based applications, and a wide variety of blogging engines to choose from, would I write a desktop application in Java targeted exclusively for one company's proprietary blog platform? First of all, it was tempting to write this as an Adobe AIR application. It would have fit my requirement that it be cross-platform and run as a desktop application, but I've never written anything with Adobe development tools before. Given the limited time I had on weekends to work on it, I wanted to get something written as quickly as possible rather than spending all my time learning a new platform. With Java, I could just hit the ground running, and it was just a matter of referencing the Swing-specific documentation. It boiled down to what was expedient and familiar because it would allow me to build something quickly. With respect to the issue of making this application web-based, the main point is that I didn't want to start up a br