Book Review: High Performance JavaScript (Part 1)

Posted on September 8, 2010 by Derek

When I saw Nicholas C. Zakas blog that he was writing a new book on JavaScript performance techniques, I instantly went to pre-order it as I hoped it would be another top-notch book from Zakas & Yahoo! Press. Having partially read through High Performance JavaScript by now, I wasn’t let down.

Since JavaScript is such an expressive language, there are dozens of different ways to do the same thing. Some of them good, some mediocre, and a lot of them bad. It’s amazing how much awful JS info is on the web, all leftover from the dark ages of JS (’96 – ’05). Up until this point, we haven’t had an authoritative source on the topic of how to write JavaScript that performs well, both in and out of the browser. Sure we’re had great books about web performance (High Performance Web Sites is my favorite), but we haven’t had anything specific to JavaScript. Now we do.

Nicholas is widely known as one of the best minds in the JavaScript world today. He joined Yahoo! in 2006 as a front end engineer and has been working on one of the most trafficked pages on the interwebs, the Yahoo! home page. His blog (nczonline.net) is a treasure trove of information on all things JavaScript & web performance. Some recent gems include Interviewing the front-end engineer & Writing maintainable code. It goes without saying that he knows his stuff when it comes to JavaScript & performance. As his books and blog posts have shown, he’s also a very skilled technical writer, keeping topics fresh, concise, & relevant.

I’m writing this as I read along, so the verbosity of this post is due to me taking reference notes on interesting things as I go.

Chapter 1: Loading & Execution

Nick doesn’t waste any time getting into what the reader wants, fresh tips! Right away we begin to learn the specifics of how browsers react depending on where & how you include your JS. There are many ways that work, but few ways that work well.

Specifically:

  • Why is it important to put your <script> includes just above the closing </body> tag?
  • What is the browser doing while loading those external files?
  • Why should you put all your in-page JS code above your CSS includes? (A: If you put it after a </link> tag referencing an external stylesheet, the browser will block execution while waiting for that stylesheet to download)
  • How you can use the defer attribute in <script> tags to delay non-essential execution of code.
  • A thorough look at dynamic script loading to import & execute your JS without blocking the browser.
  • An overview of some of the common JS loaders used today (YUI3, LazyLoader, & LABjs).

While much of the content in this chapter contains common knowledge among experienced developers, it is important knowledge to cover as it serves as the foundation for the rest of the book. Don’t worry, we’ll get more advanced.

Chapter 2: Data Access

Here’s where the sexy parts come into play; diagrams, graphs, and benchmarks! This second chapter is where you’ll learn about how exactly the JS engine accesses data depending on how you store it. The steepest learning curve within JavaScript for beginning developers is understanding variable scope. This is the first time I’ve ever come across an explanation of JavaScript’s [[Scope]] property, now all the scoping & speed issues make perfect sense!

Major topics covered in this chapter:

  • Why do global variables perform so slowly?
  • Why creating data as local variables as opposed to object properties is 10%-50% faster (depending on the browser).
  • Why is it a good idea to create local instances of global variables?
  • Why with, try/catch, and eval are bad ideas from a performance perspective. (A: they augment the scope by inserting themselves first on the tree)
  • What truly happens under the hood when a variable is found to be undefined?
  • Closure scope and why they can cause memory leaks.
  • How prototype’s work and performance issues related to traversing up the prototype chain.
  • Why is it bad to use deeply nested object members (i.e. foo.bar.baz.bop())?

There were so many “Ah hah! I get it now!” moments in this chapter for me that it alone was worth the price of the book. It took me about 5x as long as it should have to get through this chapter because I was too busy playing with Firebug as I began to learn some of these concepts.

Chapter 3: DOM Scripting

This book contains a few guest author chapters, and this is one of them. In this chapter we learn about DOM scripting by another Yahoo, Stoyan Stefanov.

Many web developers don’t understanding what exactly “DOM scripting” is, even though they likely do it on a daily basis. Many could tell you what the acronym stands for and that it represents the structure of an (X)HTML/XML document, but most don’t know that it also represents the API part of how you interact with the document. When you are using document.getElementById(“foobar”) or myelement.style.color = “blue”, you are utilizing a DOM API function accessible via JavaScript, but it has nothing to do with the ECMAScript (aka: JavaScript) standard.

This chapter is chalk-full of great best practices & overviews of DOM principles. The first thing we learn is that accessing the DOM is so slow because we’re crossing the bridge between JavaScript and native browser code. Jumping between the two is expensive, and should be kept to a minimum. There are a lot of tricks & tips that are very under-utilized by most developers when DOM scripting.

For example:

  • Using the non-standard innerhtml is way faster than creating nodes via the native document.createElement() method.
  • When looping through a NodeCollection you should cache the length of the node in a local variable because it’s own length property is very slow.
  • Iterating through nextSibling() can be 100x faster than using childNodes()

This chapter also goes into a detailed explanation of what repaint & reflow are, when they occur, and how understanding them will improve your application performance. The realization I had after reading the R&R explanation is we do stupid stuff all the time simply because we don’t understand how the browser renders and updates our pages. You know how you’ve always heard using margin-left & margin-right as separate styles is a bad idea? Well, here you find out why. Oh, and did you know there was a cssText property you can use to batch your CSS modifications? I didn’t.

As JS libraries get more & more popular, knowledge of good DOM scripting is becoming increasingly rare. Take event delegation for example. Many developers just presume jQuery’s live() or YUI3′s delegate() methods are just magic. They’re far from it, and are actually easy to understand concepts. When interviewing candidates for front end jobs at Yahoo!, this is one of the primary concepts we expect candidates to understand. They may have never used it, but the good ones will figure it out as they are whiteboarding and we walk them through the challenges.

JS libraries are awesome, but it’s because they abstract out the cross-browser differences & fix a flawed language, not because they allow you to forget what it actually going on under the hood.

Chapter 4: Algorithms & Flow Control

Chapter 4 kicks off with a quick overview of the 4 different types of loops in JavaScript (while, do-while, for, for-in). The first 3 have equivalent performance, but for-in is the one to watch out for and should only be used when iterating an unknown number of elements (i.e. object properties). We then learn about important concepts like length caching and various other optimization techniques focused on reducing the number of operations per iteration.

Next up are conditionals, such as if-else and switch. We learn when it is appropriate to use each one, and when they can be ditched for a much faster method, like using arrays as lookup tables.

Finally we come to the topic of recursion. We skip the basics of “What is recursion” and jump straight into browser limitations with call stacks and advanced recursion topics such as memoization to cut out the fat in your stack.

Since the majority of our time spent coding is inside of loops, conditionals, and (if we really want to optimize) recursion, this chapter has great, basic information on efficient shortcuts that will set you apart from the other developers on your team. Techniques learned in this chapter extend beyond the scope of JavaScript and can be used in just about every other programming language.

Chapter 5: Strings and Regular Expressions

Another guest author chapter, this time by regex guru Steve Levithan

Along with loops, another very common task in JavaScript is string manipulation, most commonly one by concatenation or regular expressions, so it makes sense to have a whole chapter to itself.

When most people start out with JS, their concatenation method is likely var str = “foo”; str = str + “bar”; //str = “foobar”, then they discover the += operator and it becomes var str = “foo”; str += “bar”; //str = “foobar”. It turns out that one of those is more efficient when it comes to memory usage, and it happens to not be the latter. This chapter provides some memory allocation table diagrams to explain the difference and how different browsers perform that operation. It should also be noted that another alternate method of concatenation, ['foo','bar'].join(”); is the preferred method in IE 6 & 7, so that should be considered depending on your userbase.

The second half of this chapter covers regular expressions, which usually make me cringe. I have no problem writing them, but they’re an absolute nightmare to maintain sometimes. Douglas Crockford has a saying, “If a regular expression is longer than 2 inches, find another method.” I couldn’t agree more.

In Part 2 of this review, I’ll look at the remaining five chapters of this book:

  • Chapter 6: Responsive Interfaces
  • Chapter 7: Ajax
  • Chapter 8: Programming Practices
  • Chapter 9: Building and Deploying high performance JavaScript applications
  • Chapter 10: Tools

If you like what you’ve seen so far, go buy it!

Posted in Web Development | Leave a comment

Return to Sunnyvale

Posted on April 23, 2010 by Derek

So right now I’m sitting in a booth on the Yahoo! campus, the same booth where I set a goal 20 months ago that one day I’d work for Yahoo! and….

[Wavy distorted omg we're going into a flashback. Begin narration]

My first experience on the Yahoo campus was for Y! HackDay 2008. I remember coming to the campus, being totally lost, and overwhelmed, almost like your first day of High School or College. I wasn’t an employee or anything. I was just a dumb programmer who wanted a taste of what Silicon Valley was really like. Seriously, I come from the startup world in Kansas City, I was in absolute awe of the place. This is where the Internet happens. Holy shit.

I came to HackDay armed with an idea for a hack to build, but was totally unable to focus, so I just sat around, tweeting, talking, and having fun. The music, the hacks, the food, the beer. I was totally awestruck when I talked to someone who worked at Yahoo!, especially the ones working on products I had used. I knew at that moment this was a place I’d always strive to work at. I knew I just *had* to work here, and be the person on the other end of that conversation.

Through the course of that weekend, I met a recruiter who for one reason or another took interest in my skills and said he’d follow up with me. I didn’t expect he would and he was just being nice. A couple weeks later I got a call from him stating he was interested in setting up an interview. I was shocked. “Ok, yeah, umm.. sure, anytime” I was so nervous before that first call. I reviewed just about every book I owned on programming, and I own a lot. I got the call and was speaking with an engineering manager who started asking me all sorts of questions about web development. In retrospect, I totally bombed it, and knew it. Rejected.

Down, but not out, I was focused, I knew it was attainable, but I just needed more time. So, over the next year I did just about everything I could to get my skills up to the level they needed to be for another crack at an interview, always keeping that original interview experience in mind. I had a blueprint. A plan.

A year later I got an email… “I’m back at Yahoo! Want another interview?” It was the original recruiter. “Yeah, absolutely.” The only goal I had this time was getting further than the first. I wouldn’t be totally bummed out if I didn’t get the job, but I at least wanted an on-site interview, just as validation I was making progress. Off I went, studying my ass off for about a week straight, so focused on the lone objective of nailing that phone-screen. The phone rang, and we started chatting. These questions were totally different from the first time. But that’s ok, I knew them. Apparently I did well, and I got an on-site.

The on-site (at the Santa Monica office) went well, and I got an offer. It was a big step leaving Kansas City, but one that I’d always regret if I stayed. So off I went, off to sunny SoCal. I started at the Santa Monica office working with the Entertainment team in November. Due to some mix-ups, I never did make it up here to Sunnyvale for training & orientation. Beyond that, there was never much need for me to be up here in person as we have tele-conferencing equipment galore, and these virtual meetings are in our DNA because we have offices around the country, and around the world.

So 5 months go by and I finally get up here for my first time. I’m actually glad I didn’t get up here before. I get to experience my first day at Yahoo, twice. I knew it was going to be weird, a good weird, and I knew that first time I came here was going to start flashing back. So here I am, sitting in the same booth, sipping my (free) mocha cappucino, admiring the courtyard, the weather, and the conversations going on around me. This is awesome. I have somewhere to be right now. But, nope…

If you haven’t set goals for yourself, do it. Set big ones. Set life-changing ones. When you achieve those, set higher ones, and just keep rolling. If you don’t have goals, find them. I stumbled across this one because I saw a tweet about HackDay, thought it sounded fun, and stepped on a plane to fly out here almost 2 years ago. Random. Lucky… Bold.

It’s feelings like this that you wish you could just bottle up and relive whenever you want.

So, I guess that’s the reason I’m writing this. A 30 minute slice of awesomeness, carved into this blog.

Posted in Career, Yahoo | Tagged , , | 3 Comments

My Birthday Gift to Twitter – I Quit

Posted on March 21, 2010 by Derek

As Twttr (sic) celebrates its 4th birthday, I figure it’s as good of time as any to blog about something I’ve been thinking for a while.  No, don’t worry, I’m not going to quit tweeting, but I will quit competing.

Twitter engineer Alex Payne sent out a prophetic tweet last month. In this message to the Twittersphere, he basically says that Twitter.com is going to be so badass and feature-rich that you’ll soon rethink your need for 3rd party Twitter clients. This caused an uproar in the developer community as many (over-reacting) people took his comments to mean Twitter was going to try & kill off the alternative clients. @Al3x and the rest of Twitter HQ went into damage control mode to explain that Twitter wasn’t attacking alternative clients and that they were still supportive of the developer community. Hugs all around, right? No. I think most people saw the writing on the wall at that point.

I know I have. So, after 2 years of developing my own Twitter clients, I’ve decided that I’m finally throwing in the towel.  Twitter has built a great web app, so there’s little need for me to continue. There’s part of me that is sad, but mostly I’m really happy for Twitter.  Also, I’m relieved as I can now focus on something else.

A little background… It wasn’t up until recently that Twitter’s own web client (Twitter.com) lacked most of the features that I wanted, so I was forced to build them on my own. I began building Tweenky almost 2 years ago and the goal was simple… create a Twitter web client that had the following features:
A) A friendly Ajax interface
B) Integrated searching
C) Groups
D) Saved searches
E) Fixed the @reply problem where replies were not visible to your replies feed unless it started with “@username”
F) Had other basic shortcut features (like retweet links)

When it was ready in the summer of ’08, I released it to the wild with the help of TechCrunch and other tech blogs, who all praised its set of features. I’m not going to claim I was the only one working on such features. Most of them were just obvious extensions to how people really wanted to use the Twitter service. They would have been implemented by Twitter themselves had the service been stable enough to add feature development resources. It’s funny to think that between 2006 and 2009 Twitter.com remained largely unchanged. Why? Because they were generating too many failwhales and fixing those was the #1 priority.

By 2009, the engineering team had rebuilt Twitter into a stable platform and they were finally able to let the front-end developers loose and start working on features. First came some ajaxy goodness, then integrated searching the replies/mentions fix. Later in the year they added Lists and the Retweet feature. At that point, I noticed Tweenky started to become less & less useful. Others did too and the userbase started to decrease.

Enter 2010… The front-end team is beginning to crank out features & tweaks at a fast pace. So far this year we’ve seen hovercards, location dectection, and integrated maps. It’s finally at the point where the speed of innovative features is out-pacing what the developer community will be able to keep up with. There are still some major clients, such as Tweetie (on the desktop) that haven’t even integrated Lists yet. I’m not going to attempt to work on the hovercards or integrated maps, not because I can’t do them, but because what’s the point? I’ve actually begun using the Twitter.com web client more than my own client because it simply lacks essential features. Sure I can add them, but once I’ve completed that, the larger-than-1-person-front-end team at Twitter will have rolled out a couple more slick features, and I will always be playing catch-up.

So here’s the point of this post… I’m done. From here on out I suspect the majority of my Twitter time will be spent on the Twitter.com web client. Don’t take this the wrong way, I’m actually really happy for Twitter and the awesome front-end/UX team they’ve assembled (which includes a number of ex-Yahoo’s =D ). They’ve implemented most of the “must-have” features that 3rd party developers have been working on for years. This is a good thing because those features are now available to the majority of the Twitter userbase instead of a small portion. I suspect over the course of 2010 and beyond, the pace that we see new features will continue to increase, and with every new release, more & more 3rd party developers will cease working on their own clients. This will be a bitter pill for some in the developer community to swallow but the side-effect is they’ll be spending less time on simple, basic features that Twitter.com should have, and instead hopefully on innovative non-client apps or things completly unrelated to Twitter.

I’m happy with this direction. The main reason I’ve developed Twitter clients is to geek around and gain experience in areas I feel my knowledge is lacking. I’ve never approached my client development as “OMG, I have to get as many people as possible to use this thing so I can make money and/or sell it!” I’ve never attempted to monetize my work. I’ve just approached it as there’s a certain user experience I want to have with Twitter, and if anyone else wants to join the fun, cool. No? That’s cool too. Work hard and good things will come.  Having converted the original Tweenky client from mostly PHP to all JavaScript, I’ve been able to gain valuable experience with jQuery, YUI3, & JS in general. To me, that is satisfying enough. All the JS, REST API, and scaling knowledge I gained through this process is one of the reasons I now have a job at Yahoo.

So what’s next? I dunno. If I’m spending X less hours per week trying to replace Twitter.com, I can now spend X hours working on something else. I’ll most certainly work on some non-client Twitter apps, but I’m hoping to spend the majority of my time on non-related Twitter projects. Maybe some much needed Node.js hacking? Maybe some WebOS apps? Hmmm… Stay tuned.

P.S. Tweenky has always been an open-source project. You can find the source code on GitHub. You can also find Tweenky’s cousin “Tweetanium” (a YUI3 rewrite) on GitHub as well.

Posted in Unsorted | Tagged , | Leave a comment

Node-YQL

Posted on March 6, 2010 by Derek

The more I play around with Node.js, the more I love server-side JavaScript. Once you get over the weirdness of writing JavaScript outside of the browser, it feels very natural. And the bonus is that it is blazing fast.

Also, as I’ve been playing around with YQL (Yahoo Query Language) more lately, I realized I wanted to be able to access YQL data from within my Node app. So, I created a node-yql module.

Now you can do something like…

YQL.get("SELECT * FROM weather.forecast WHERE location=90066", function(response) {
 
	var location  = response.query.results.channel.location,
	    condition = response.query.results.channel.item.condition;
 
	sys.puts("The current temperature in " + location.city + " is " + condition.temp + " degrees");
});
// Output: The current temperature in Los Angeles is 57 degrees
Posted in Web Development | Tagged , , | 2 Comments

jsFiddle: A JavaScript playground

Posted on February 25, 2010 by Derek

Ajaxian had a story yesterday about a brand-new JavaScript playground called jsFiddle. A write and execute web-based JavaScript IDE is nothing new, but this is much, much more than that.

The real power of jsFiddle is that you have the option to include any of the most popular JS libraries, including; Mootools, jQuery, Prototype, YUI2.8, YUI3, Glow, Vanilla, Dojo, Processing.js, & ExtJS. This feature gives anyone the ability to try out any of these libraries without going through the task of downloading, extracting, and coded up some examples. With a few mouse-clicks you can view example snippets from any of the major JS libraries, and start editing them to see how they work.

As if that wasn’t enough, jsFiddle also includes social features that give you the ability to write a snippet, save it, and share the URL. As I was hanging out in various JavaScript IRC chatrooms tonight, I continually found myself using jsFiddle to code up snippets to answer questions. In the past, everyone would always just use Pastebin.com, but that lacks any interactive features. Now you can use jsFiddle as a replacement to Pastebin for any JS, HTML, or CSS snippets and the user will have the ability to actually edit, execute, and view the output.

As icing on the cake, you can take your snippets, copy the embed code, and paste them anywhere. Here’s a snippet that I was able to code up in about 15 minutes (writing this blog post took longer than that!) to demonstrate the power of YUI3, YQL, and the Twitter API. In this iframe, you’ll find all the JS, CSS, and HTML you need to create a simple little Twitter widget.

In all, this is an amazing product that I’ll likely find myself using on a daily basis.

Posted in Web Development | Tagged , | 3 Comments

Crockford on JavaScript: Part 1

Posted on February 21, 2010 by Derek

I just finished watching Part 1 of Douglas Crockford’s ongoing lecture series on JavaScript, and it’s fascinating stuff. A must watch for any programmer. Even if you don’t code in JS, it’s worth watching simply because this first part is all about the history of programming. (video of talk is below)

As web developers, we spend anywhere from a little bit of our time to the majority of it coding in JavaScript, but few know the history behind the language. I’m not talking about just reading the Wikipedia article and knowing that it was created by Brenden Eich at Netscape in ’95, I’m talking about the history of where the ideas behind the language came from and everything that influenced it. Like most every language, JavaScript’s syntax and style didn’t appear out of nowhere, it was influenced by a number of different languages, and those influencers were in turn also influenced by a slew of languages.

It’s easy for those of us that started programming with C (or anything after) to just look at it as the “Alpha” language and ignore everything that happened before it, but that’s missing a lot of really important history, that we, as professionals, should know. It’s like a politician in the United States just ignoring everything that happened before 1776. Learn from the mistakes of the past and spot the trends going forward and pave the best path. Crockford shows us snippets of languages that were created in the 60′s and 70′, dissects them, and explains why certain people thought they were good ideas at the time. It’s amazing to think that there was a time before modules or functions, or before we had figured out the best way to format a for loop. The history of programming languages is littered with a ton of bad ideas, but occasional brilliant ideas. Those brilliant ideas are what get refined, and lay the foundation in the next generation of languages.

Finally, one concept he goes back to over and over that I found really interesting is that programmers are a very stubborn breed. We all know this. There’s little point to all our flame wars on which language or framework is better, and most of it comes from either insecurity or ignorance. He says it takes a long time for us to evolve, and he’s right. It’s not because new ideas aren’t coming along all the time, but it’s because the adoption of new ideas only take place at each generation shift, when the “old” thinkers get replaced those with few preconceived notions. The world didn’t wake up one day and realize that GOTO statements were bad, it’s that those who supported GOTO and argued for it for a decade finally retired. Out with the old, in with the new. That’s evolution.

Anyways, I could go on and on about all the “Ah hah!” moments in this talk, but you really need to watch it for yourself. I’ll probably chime in again after part 2, which I’m probably going to watch right now. I’m excited. It’s like a sequel. “Ooo! What happens now?!”

Also, here’s the “Mother of all Demos” video he mentions about halfway through.

Posted in Unsorted | Tagged , , | 1 Comment

Amazon and Lala: What could have been

Posted on January 22, 2010 by Derek
lala.jpeg

It’s now been about 6 weeks since Apple bought Lala and I’ve spent some time reflecting on the acquisition. When I first heard the news, it sounded like a good fit. After-all, Lala is essentially a web-based version iTunes and has some great technology powering it. It makes sense that Apple would want to buy the next best thing and get some great engineers in the process. However, I didn’t think at the time that Apple’s strategy would become so clear, so soon. Apple’s acquisitions usually take years to come to fruition. Not this time though. TechCrunch recently reported that Apple is planning on transforming iTunes into a cloud-based iTunes.com service, and Lala’s technology is the quickest way to do that. (“Apple’s Secret Cloud Strategy And Why Lala Is Critical“).

Seeing the immediate impact Lala’s technology can have, I began to think about who else was in the bidding war for Lala? Most reports say there were multiple companies interested, so you have to assume the a few of the typical parties were involved; Google, Amazon, Microsoft, Yahoo, AOL, Facebook, & MySpace. Only a couple of those companies stand out as a great fit, Amazon & MySpace. Right now MySpace has too many problems to deal with, so that leaves just one likely suitor… Amazon.

Amazon’s entry into the digital music download space has been game-changing. Prior to Amazon.com/mp3, music lovers had no where to go to purchase non-DRM’d MP3s. We were stuck in the world of buying CDs to rip, buying DRM’d tracks from iTunes, or of course… pirating music. When Amazon came into the market in 2008, their impact was immediately felt as prices began to drop and DRM began to die. This opened the floodgates to other services who also began selling non-DRM’d MP3s, and music streaming became a sustainable business model. Without Amazon’s entry, I suspect little would have changed over the past 2 years. Having competition for Apple is vitally important to the evolution of the media industry. Apple is an amazingly innovative company, but like most companies, they grow content & less innovative without anyone breathing down their back.

As painless as Amazon has tried to make the downloading process when you purchase tracks from their MP3 store, it is still not as smooth and elegant as iTunes. To add insult to injury, once the download is complete, Amazon’s user experience is then transfered over to iTunes (for most users) where the user must import the purchased files to begin listening. Amazon clearly needs to do something about this. Transferring a customer into your rival’s product at the end of the transaction process is a giant flaw in product design. They need to provide their customers a way to stay in an Amazon environment throughout the Purchase->Download->Listen->Manage cycle. This is where their acquisition of Lala would have been perfect.

Had Amazon bought Lala, they would have obtained the engineering team that is hands-down the best at building a web-based media manager. After integrating Amazon MP3 with Lala, they could then integrate the Amazon Video & Kindle management interfaces into the Lala-based manager. Beyond music, video, and books, Amazon could then begin to expand into other areas, perhaps buy a company like Roku and make their streaming video experience end-to-end Amazon as well. We could have had a real competitor to iTunes. Sadly though, Amazon dropped the ball with Lala, especially since the acquisition only cost Apple $17 million. That’s nothing for a company that just spent over a billion dollars to purchase Zappos.

We’re clearly approaching a time where our music devices are going to have constant wireless broadband connections. You won’t have to worry about locally storing music, it can all be hosted in the cloud and streamed to you on demand. This isn’t a brand new concept, but the timing is right for it to finally become mainstream. If Apple is successful in transforming iTunes into iTunes.com, unchallenged, they will likely be able to declare “game over” with music delivery in the US.

Hopefully Amazon sees the writing on the wall and steps up their game to provide a challenge. Is Spotify our only hope?

Posted in Music, Technology | Tagged , , | Leave a comment

On: Programmable Twitter Clients

Posted on November 30, 2009 by Derek

Loic Lemuer (CEO of Seesmic) recently announced at Microsoft’s Developer Conference that he’ll be releasing a new version of Seesmic that supports plugins. This is huge for developers, as well as users.

Up until now the Twitter developer ecosystem has been very closed. Sure the Twitter APIs are as open as possible, but all the clients out there are largely closed platforms. There are a few exceptions, including Spaz and Tweenky (my client) which are open-source. It is great to have a starting point (aside from raw libraries) that gives developers a place to start with when building a Twitter application. With Seesmic Desktop invading Windows with a programmable version that you can write plugins for, this is a huge step that hopefully will push other developers/companies towards the same model.

When I launched Tweenky about 18 months ago, I hadn’t event thought about making it programmable, but pretty quickly afterwards I realized the potential it could have if it were programmable, and so I began a rewrite, and coded it in 99% JavaScript with two plugins out of the box, Twitter and Identi.ca. I had plans for other plugins (Facebook), but the problem with developing a platform, and not just an application, is that it takes a loooot of time. For one guy working in his spare time, it just wasn’t going to be possible to abstract out a platform and develop a community around it. So, I started with another rewrite and only focused support for Twitter. I still think it was the right move given the limited amount of time I can spend developing it.

What I’m really waiting for is an easy way for Twitter developers to monetize their applications. We’ve all seen what the Apple has accomplished with the App Store and the ecosystem they created overnight. While most iPhone developers have made very little, others have won the lottery and struck it rich. While Twitter (the company) has been very supportive of the developer community, they should really look at giving it a push and figuring out a way to monetarily reward Twitter developers. Nothing gets developers going like a big, fat, diamond crusted carrot dangling in front of their noses. Afterall, Twitter wouldn’t be Twitter if it weren’t for the developers. The various clients are what made the service usable for the hard-core Twitter users that create most of the valuable content.

P.S. You can still view the programmable version at beta.tweenky.com.

Posted in Social Media, Technology, Web Development | Tagged , | Leave a comment

Last Day

Posted on November 21, 2009 by Derek

It’s my last day at Catholic Content. It’s been a great 3 year ride and is certainly going out with a bang. When we started planning for NCYC 2009 (National Catholic Youth Conference) 18 months ago, I never would have guessed it would be my last weekend. But here I am, working behind the scenes with the production crew to stream the event out to thousands of people around the world. The fun part? I’ve never done live event streaming before, so it’s been a hectic, but adventurous weekend. In a way, it’s almost a culmination of the last three years. Lots of stuff I’ve never done before, but having a blast learning.

Coming into this job as the lead developer for MyCatholicVoice.com, I had zero experience running a project the size of where we have taken this. I had never built a web server this size from scratch (software-wise). But along the way, I’ve had to tackle hundreds, or heck… likely thousands of problems along the way, and I’ve learned something at every step. It’s been such an incredible learning experience as I’ve gained a bit of knowledge about so many different areas. These new skills include everything from cloud computing, systems architecture, to Linux administration, all the way to the front-end with JavaScript libraries. Then of course, that middle layer of PHP where my skills and knowledge have improved an unmeasurable amount.

When I started my career after graduation 5 years ago, I had a gameplan, a very iterative gameplan:

  • Step 1: Get a job, anything.
  • Step 2: Find a web development job, maybe it would be something that I wasn’t thrilled about or didn’t pay well, but it was at least enough to get me in the door as a programmer.
  • Step 3: Find a job that paid a decent amount, but didn’t have to be a project I was passionate about.
  • Step 4: Now that everything else is taken care of, find a project I was passionate about.

Beyond those 4 steps, I wasn’t sure exactly what came next. Perhaps it was starting my own company? Maybe moving out to the west coast? Maybe it wasn’t even in web development? In fact, mid-step 3, I considered changing careers because my job was just so unfulfilling. I enjoy cooking, so maybe Culinary school? Then I remembered I don’t like anything outside 10 foods, so nevermind that. I loved doing 3D animations in high school, but never pursued it because I can’t draw. So… I stuck it out and realized it was just my job, not my career choice, that was unsatisfying. Boom. Reenergized.

Well, tomorrow is the transition between from Step 4 to Step 5. This year I realized the next step for me was going to be moving to LA, SF, or Seattle. I needed to get to a tech hub where there were thousands of jobs, with companies large & small. But, there was also something from this last step that I was missing, that “passionate about the project” part. While I’m incredibly proud of the platform we’ve built at MyCatholicVoice, I’ve never been able to have much of a connection with our users. Why? I’m a non-Catholic working on a Catholic project. While I think the purpose of the project is a noble one and I agree with bringing “web 2.0″ to the Catholic church, it ultimately doesn’t effect me faith-wise. That’s a little bit of a bummer sometimes. I want to be a user of the product, as well as a developer.

Well, enter Yahoo. Talking about being a user of a product… Y! is one of the oldest services I still use from my first days on the internet in the mid-90s. Check out my last post for all the reasons I’m thrilled to have this opportunity.

So, what’s after what’s next? Hmmm….

Posted in Career | 1 Comment

Onward and Upward

Posted on November 13, 2009 by Derek
yahoo_purple_small.GIF

When I attended Yahoo’s HackDay ’08 at their Sunnyvale headquarters, I was so impressed with the people, the event, the technology, and the culture at Yahoo, that I made working for Yahoo one of my career goals. Well, it came a little sooner than I expected, and I’m thrilled to say that starting Nov 23rd, 2009, I can scratch “A career with Yahoo” off my bucket list.

Why Yahoo?

There are a number of reasons why Yahoo is so appealing to me at this point in my career.

The Scale: As a developer, there is a lot of satisfaction in knowing that millions of people are happily using your products. With billions of pageviews per day across the Yahoo network of sites, there are only a handful of companies that can offer similar challenges as Yahoo (Google, Facebook, Microsoft, and maybe a few others). At Yahoo, I expect to learn what it takes to code and assemble massively scalable web applications. Not many developers get a chance to work on products this large, and it is certainly an opportunity I find invaluable.

The Collective: Yahoo employs roughly 15,000 people, and thousands of those are software engineers working on some of the largest products used on the web. I’m confident that whatever problems I may run into on a daily basis, there is someone at Yahoo that has the knowledge to help me out. I can name dozens of current and former Yahoo employees that have inspired me in one way or another during my career, and I’m sure I’ll meet dozens more.

The Products: Yahoo certainly has its fair-share of best of breed products on the internet. The jewels are of course the Yahoo portal, Yahoo Mail, and Flickr. Beyond that, there are some other very successful products throughout the years, including; Yahoo Games, GeoCities, Messenger, Music, Movies, News, and Sports. All of which I’ve used extensively at one point or another. My first Yahoo account I created when I was 15, and I am now 28. There’s certainly a sense of pride and satisfaction knowing that I’ve been a happy customer of my future employer for 13 years.

The Culture: Yahoo puts an enormous amount of resources into their Developer Network and open-source technologies. As an advocate of open-source software, it’s a thrill to know I’m working for a company that values it as much as I do. It’s a shame that some of the neatest tools Yahoo has to offer are still unknown or unused by many developers (YQL, Pipes, & YUI), and I will certainly do my best to evangelize the incredible tools Yahoo has offered to the community.

The Location: Having lived in/near Kansas City my whole life, I love it here, but between October and March sometimes you wish you could take a vacation to Hell just so you can warm up a little bit. I’ve been to Southern California probably a dozen times throughout my life, and it doesn’t take more than a few minutes of the ocean breeze, the palm trees, and the sunshine before you don’t want to ever leave.

Since I signed the paperwork and this whole thing became a reality, it has certainly taken a while to sink in. I still don’t think it has fully sunk in, and even after my going away party this weekend, boarding that flight to LA on the 22nd, it still may even take sitting down at my desk before I finally realize what just happened. So needless to say, I’m thrilled with the opportunity Yahoo has presented, and during my time there I will do my best to ensure it is as rewarding for them as it is for me.

Finally, I wanted to thank Fred & Mary Kay Fosnacht for sharing their dream with me over the last 3 years. Working for Catholic Content has been an amazing experience and certainly has been life-changing. I can safely say that my career wouldn’t have been the same without their confidence and encouragement and I will always be grateful for the opportunities they’ve given me.

Onward and upward.

Posted in Career | 3 Comments