Jason Famularo

Medium-depth thoughts on programming

Page 2

Checking out from LinkedIn

My newest co-worker challenged recruiters to step up their game. He’s found a job he likes (and I’m biased, so I’ll just nod and smile) that provides some of the challenges he is looking for. Perhaps my co-worker attracts a higher quality of recruiter than I, but I’ve not had any luck with unsolicited contact from recruiters.

For most of this year, I’ve had an active disdain for LinkedIn. I’m not in the market for a job, have not indicated I’m looking, and don’t desire to be contacted about new opportunities. And yet, the LinkedIn messages, invites, and contact keeps coming.

Let me interrupt this rant with a self-reality check: I’ve been very fortunate during my career in regards to finding the right job at the right time. I can’t take all the credit. Some will say I’ve been lucky, some will say I’ve been blessed. Both groups are probably right. If my situation was different, and I was...

Continue reading →

Integration, always last

It’s likely that your application doesn’t live in a vacuum by itself. At a minimum, it either sends or receives data to or from another application. More likely, it sends and receives information from multiple sources. You’re app is just a cog in a larger series of cogs, that makes up some grand vision of some master stakeholder or CIO somewhere. You aren’t the most important cog, but without you, or any one cog, none of it works.

Why is it then, that the development team waits until the end of the project to actually interface with these outside systems? The one thing you can’t control are the things that are outside your control. Yet, system after system, app after app, integration is an afterthought, a lower priority. And time after time, the team barely squeaks by or is burned by an external system that can’t move at the speed of your crunch time.

(As an aside, external payment...

Continue reading →


Recently, I’ve been dogged by a Subversion issue (and generally dogged by Subversion — Mercurial and Git are my new friends) that stumped me on and off for a few weeks. The dreaded error was a “Checksum mismatch”. Essentially, the file downloaded from the server didn’t have the content expected. It had been modified.

For those interested, the post that finally led to the fix is here:


The cause of the problem was that to the web server that served the files had stripping out “non-essential” content from HTML and JavaScript files, namely comments. For end users, that’s great. Less bytes to download? Awesome, we saved an e-tree! But for a developer working on that particular file, those comments are (arguably) valuable. And required if you want to fetch a valid copy from...

Continue reading →

Task switching isn’t always bad

There is an (admittedly small) upside to working on something in small bursts. While there is a huge cost to task switching, a regularly scheduled task that doesn’t last long can be productive. Here’s how:

If the task has a relatively low switching cost — something you know well, or something that doesn’t take long to get setup/back into — the time in between sessions gives you time to think (if only unintentionally) about the task, and the upcoming session. Occasionally, you’ll find that you’ll be surprisingly efficient at that task, having had some time to think about things in interim.

Even if you only have a small amount of time, it can be efficient, on the right task.

View →

Running a JavaScript function when subscribed events stop occurring

Maybe this is well-known to the JavaScript coding community — below is a simple technique I’ve found that runs a block of JavaScript when subscribed events stop firing. Full disclosure, I stole this from Hugoware. If he stole it from someone else… ;)

Use Case

A user is entering text into a text box. The user stops typing for a period of time, tabs or clicks out of the text box, or is otherwise done using the text box. When the user is done, server side validation is done (such as checking for uniqueness of a username on a sign-up form).


Attach a set of events to the text box that capture when the user is making a change, or leaving the text box. Every time the event fires, create a function that contains the functionality you want, to be fired on a timeout. If the event is fired again, cancel the existing function.

In code (using jQuery 1.7 syntax):

var timeout;

Continue reading →

Location known, but still lost

A started a new job in late 2010. At first, it seemed like something that was too good to be true at the time. It had a lot of awesome perks (to me, in no particular order):

  • Wasn’t consulting
  • Was a product/service owned by the company and slowly built upon
  • Had a software team and manager that believed in a lot of those software principles you read about, but never truly see at your job (confession: we’re not perfect, but we strive to always improve)
  • Was a telecommute job with very little travel
  • Used the technology and practices I wanted to use

I’m not here to recruit (although at the moment we are hiring) you, but to share a set of experiences that had me baffled until recently.

Whenever I start a new job (or project, as it often is in consulting), there is a period of time where I know absolutely nothing about the software you are writing and the business behind it. After a few...

Continue reading →

Patching vs. merging

One of those “fun” activities developers look forward to is merging code from one branch to another. The scenario I personal use most is merging changes from the trunk back to the branch that is about to be released.

For the last few releases I’ve deviated from my normal usage of the built-in merging capabilities of (Tortoise)SVN. Instead, I’ve made a patch of my changes just before I’ve checked them in (to either trunk or the branch, wherever I’m working). I then apply the patch to the other.

The upside is it’s a lot easier and generates less mess. Perhaps I merge to infrequently and forget the “best” way, or run into troubles because SVN is, well, SVN. The downside is I lose the context of the merge. Nothing ties to the commits together (arguably, I could commit at the top-level of the repository, but I’m not currently setup to do that).

Is this good, bad, or just preference? I’m...

Continue reading →

How reading user reviews and triaging software defects are similar

User reviews saved e-commerce — the power of the Internet buying masses, crowd-sourced into a win-win situation for both retailers and consumers (B2C!).

The above is a lie (and also hard to read, filled with terrible e-buzzwords).

User reviews are difficult to parse, give a false sense of security to the buyer, and are one of the many profit-extraction tools that retailers employ. How many times have you seen a 4 or more star review (out of 5) end up being a complete dud? How about a poorly review app on your phone actually being quite good (Amazon app store, I’m looking at you).

I’ve finally gotten to a point where I feel comfortable parsing the reviews and discerning (potentially) valuable information. I try to end up with one of the following (mind-blowing) generalizations:

  1. This product is worth purchasing
  2. This product is not worth purchasing
  3. Not enough information is available...

Continue reading →

Inbox One, the pragmatic approach

The Getting Things Done methodology encourages behavior such as Inbox Zero, the concept of dealing with all the items in your inbox and keeping a zero count. In previous jobs, I’ve tried to do this, and struggled at times, having as many as 1000 items. Even when triaging my inbox regularly, I’d still end up with 50 items that needed some sort of attention.

Lately, I’ve been using Gmail for personal and work email, and have found a balance that isn’t as stringent as inbox zero, but eliminates most of the mail. I call it Inbox One, as in one page of email. At any given time, I have at most enough email to fit on one page. As soon as it gets larger than a page (or I get a downturn in work), I clean it out as much as I can.

Currently, I have 3 items in my work inbox (up 50% from this morning, oh no!) and 10 items in my personal email inbox. Only 1 of those 13 items need attention today.


Continue reading →

The importance of releasing

An “old” adage in development is “release early, release often”. This is a form of iterative development which allows for lack of functionality initially, and additional function in short releases afterwards. It’s helpful, because it gets your site in front of real people, quickly.

I recently tried this approach with machine2date and SharedBetween.Us

machine2date is a site that focuses on one thing, converting “computery” dates into dates people recognize. If you do JSON or XML in your development, dates like “\/Date(1240718400000)\/” don’t mean much to anyone but a Unix time programmer (it’s ticks since January 1st, 1970 at midnight.)

SharedBetween.Us started out as something that was much simpler than what it is today. It’s a simple task list that can be easily shared between users. It was originally “SharedLists”, but the domain was taken, so I lazily renamed it to its current...

Continue reading →