Jon Smock

For a long time I hated Javascript.  If you started web programming in the 90’s, you know what I mean.  Browser support was spotty at best.  Even later when AJAX hit the scene, I resisted vehemently.

It took me a long time to come around, but now with libraries like prototype, jQuery, and MooTools, Javascript is my friend again.  Now you don’t have to rely on icky things like Flash to accomplish some pretty amazing feats.  Chrome Experiments will blow your mind (intended to be viewed in Google’s Chrome Browser, but Safari 4 is fine, and Firefox does ok).

The push has always been for standards:  sites that degrade gracefully.  If you don’t have Flash, you can’t view a Flash-based site (same goes for Silverlight).  But, if the web developer has done her job, anyone who doesn’t have Javascript-enabled should still have a decent experience navigating your content.

The Old Way

Generally the technique was to put your Javascript in the onlick attribute of anchor tags or the onchange attribute of text inputs.  Like having font tags littering your HTML, this left your markup looking like a jumbled mess, and it was very difficult to change behavior in a uniform way.

<a href=”http://google.com” onclick=”alert(’Big Brother is Google!!!’);”>Go to Big Brother</a>

The New Way

There is a better way.  You can keep all that Javascript out of your markup completely using bindings.  For instance in jQuery I can write this:

$(”a”).bind(”click”, function() { alert(’You have been warned’); });

Put this in a .js file or in the head of your markup, and be done with mixing function and markup (the same way you should be done with mixing style and markup).

Rails 3 Support for Unobtrusive Javascript

While this technique is eloquent and powerful, it is somewhat difficult to abstract away using frameworks such as Rails, so until Rails 3 it was left to the developer to implement it.  This left the developer in a predicament, because the ease of development using standard Rails AJAX (via prototype) methods would have to be sacrificed to obtain truly clean markup.  Rails 3 has found a way to take the best of both worlds, using HTML 5 attributes and binding.  Whether this will degrade gracefully or not is still in question, but it is exciting nonetheless.  Check out the other features coming by watching the core team at RailsConf.

Not that paying bills is fun, but as we’re running the numbers for our upcoming mortgage, I realized there’s a nifty way to pay off your loan in half the time.  It’s not always possible, but if you have some room in the budget, it may be the motivation you need.

Here’s how it works.

1. Calculate your amortization schedule.  You’ll need the starting balance of the loan, the interest rate, and how many months the loan is set across (if you know your payment amount, you can use that in place of one of the other values).
2. Calculate your amortization schedule.  I’d like to write my own, but here’s a simple app to do the job.  This will give you the break-down of every payment.
3. Figure out what your current balance is on the loan, and find that on the schedule.  By finding this number, you’ll be able to tell how close you are to your pay-off date.
4. Finally, look at the very next month’s payment and write down the amount that is going towards principal.  Add that number to this month’s total payment, and you’ll be essentially paying two months for a little more than the price of one.

Ok, that may seem complicated, so I’ll take an example.  Let’s say I started with a $20,000 student loan at 5%.  The loan is spread across 25 years.  Using the amortizer, I know my monthly payment is $116.91 each month.

If my current loan balance is $19,500, I see that I’m about 14 months into my loan.  I can look at the next month’s principal payment amount, which is $35.60, and add that to my total payment.  So my total payment is $152.51.  If I re-calculate this each month and pay that little extra, I’ll have my loan paid off in half the time.

I realize this might get tighter as you get closer to paying it off, but at that point, you’ll have all the motivation you need to knock out that debt.

I’m a perfectionist.  Ok, I’m sometimes late, and my desk at home is atrocious.  But, when it comes to projects I’m a part of, I want things organized perfectly.  I need naming conventions to be consistent, I need things to line up.  Yes, it means I care, and I deliver a better finished product.  It’s also to my detriment at times, since I’ll spend extra time on less important fixes and refactorings.

And if I don’t feel like I can clean it up easily, I resign to redo it from scratch.

Despite the initial appeal of re-doing something from the ground up, exactly the way you want it, exactly the way “it was meant to be done”, this is often an incredible waste.  Why?  Because - if you’ve ever done this, you know - you quickly lose that excitement and realize you’re tackling all the problems at once.

Ward Cunningham called these problems Technical Debt.  The analogy is a great one.  Doing things quickly often means not doing them properly.  This is ok sometimes.  It’s quicker to type your bills into Excel and start keeping a log of expenses.  As more people try to use your log, however, or you try to keep an aggregated log of multiple types of expenses, the whole system breaks down.  Each time you do the “quick fix”, you assume some Technical Debt that at some point you’ll have to pay back.  Eventually you will have to build a Quickbooks project or get signed up with Mint.com.

The longer you wait and the more complicated your project gets, the bigger your Technical Debt balance becomes.  For any Technical Debt, you can either gradually pay it of with regular clean-ups, or you can declare bankruptcy, start afresh and take on the entire project at once.

After years of development, I’m finally learning that gradual clean-up is a better strategy, when possible.  While I might feel like a superhero taking on a big chunk of problems, I ultimately get tired and bored, and I wish I hadn’t bitten off so much.  It’s much better to focus on the smallest possible part of the project and sprint to clean that up.  Once that’s taken care of, the next to smallest piece of the project should be a bit more manageable to undertake.  Sort of like a debt snowball (PDF).

So when is it appropriate to scrap the project and start completely fresh?  I see two situations:

1. It would take far longer to “debt snowball” away all the technical debt of the project.  Warning: make sure you are being completely honest with yourself.  Include all the time it might take to migrate people and data to that new project.
2. The current project is just going in too different a direction than what you need to go.  If you need to use a new technology or everything is organized in a completely wrong way, it might be better to start fresh than try to ease into that new procedure or schema.

Coming from personal experience, while it’s hard to admit sometimes, it’s better to salvage an existing project than embark on a complete rewrite.  I always thank myself in the long run.

Wolfram Alpha launched late Friday night.  What’s notable about WA is that it tries to actually answer your question, not simply find a page to answer it (so it’s an Answer Engine, as opposed to a Search Engine).  Looking at the High Scalability page, WA boasts over 10 trillion pieces of data and over 50,000 formulas.

Check out some sample searches:

• x = 2 + 5 * 8
• phonetic hypothesize
• age of Abraham Lincoln in 1862
• where was Jesus born
• How much wood would a woodchuck chuck…

To calculate all of this, its developers wrote over 5 million lines of Mathematica code.  Dang.  I’ve actually used Mathematica a few times during coursework at Penn State.  The cooler projects involved face recognition and motion tracking.  And, it was really actually pretty easy in Mathematica, so I can’t even imagine what all their doing if they have 5 million lines of code.

But, who cares, right?  The bottom line is whether or not this actually matters.  Well, it does.  Or, it could.

There are two ways to obtain knowledge.  Through a centralized source (like Wikipedia) or through thousands upon millions of tiny “dumb” sources that aggregate into an answer.  The latter is what Kevin Kelly is suggesting:

As Larry Keely of the Doblin Group says, “No one is as smart as everyone.”

Any process, even the bulkiest, most physical process, can be tackled by bottom-up swarm thinking. Take, for example, the delivery of wet cement in the less-than-digital economy of rural northern Mexico. Here Cemex (Cementos Mexicanos) runs a ready-mix cement business that is overwhelming its competitors and attracting worldwide interest. It used to be that getting a load of cement delivered on time to a construction site in the Guadalajara region was close to a miracle. Traffic delays, poor roads, contractors who weren’t ready when they said they would be, all added up to an on-time delivery rate of less than 35%. In response, cement companies tried to enforce rigid advance reservations, which, when things went wrong (as they always did), only made matters worse (”Sorry, we can’t reschedule you until next week.”).

Cemex transformed the cement business by promising to deliver concrete faster than pizza. Using extensive networking technology–GPS real-time location signals from every truck, massive telecommunications throughout the company, and full information available to drivers and dispatchers, with the authority to act on it–the company was able to promise that if your load was more than 10 minutes late, you got a 20% discount.

The future - as today is already - will be all about knowledge. Hopefully it will be shared knowledge, but regardless, the traffickers of knowledge, such as Google, Wolfram, and other players, will reap the rewards. If Wolfram can cut a niche for itself and leverage it further using distributed knowledge, it may just be all the search we’ll need (or at least eliminate things like Wikipedia).

It shocks me how many people I know, who regularly read and participate online, that don’t understand or use some form of RSS reader.  It’s not hard, and it’ll completely change the way you view content online.

An RSS reader, such as Google Reader, can pull the newest content from all the sites you go to regularly, such as news sites, blogs, ecommerce sites such as woot.com - the list goes on.  Trade all that wasted time in your bookmarks (or worse, typing in URLs), wasted time loading graphics and page content.  Trade it for a one stop spot to view and share all the newest information you want.

I highly recommend using Google Reader, though.  I keep track of probably 100-ish sites, and I can do it easily.  It keeps track of what’s new, what I’ve read, and what I’ve tagged/”starred” so I can find it later.  Check out their getting started guide, and you’ll be up and running in no time.

Some of my favorite feeds:

• Seth Godin
• A Fresh Cup
• Joel On Software
• Coding Horror

Until I met my wife, I could have cared less about Bruce Springsteen. I am completely embarrassed to admit that now.

Bruce Springsteen at the BJC in State College

Unbelievable. As they returned to the dugout, I said to my friends, “I guess that’s the end of their first set.” What I didn’t realize was that two hours had just passed. Turns out, as misguided as that was, I was still right in a way, because they came back out and played another solid hour.  Probably the most entertaining three hours of my life.

More unbelievable is combing YouTube for videos of them back in the 70s.  They’re exactly the same - exactly the same.  He’s still jumping on pianos.  The band’s tighter than ever.  And, Clarence is still the Big Man.  After all that time, you’d think it’d be a formula for them, but it’s clear they are still absolutely loving what they do.

If you’re not out there doing what you love, you have to look at Bruce and think there’s something better.  I hope I still love what I’m doing at 59.