Jeremy Kahn's Dev Blog

As I write this, I’m on a big blue jet, and it’s flying me from my old life in Chicago to my new life in California. I don’t yet have a place to live out there, but I’m going to get an apartment in San Francisco as soon as I can find the right place.

I’m 25, and I’ve lived in Chicago my whole life. I was born there, I was raised there, and I went to college there. And now I’m leaving it all behind, and I have no idea if I’m ever coming back. I had a great job as a Web Developer at a corporate communications agency. I had wonderful friends, and a generally happy life. So why am I moving? The impetus for the change is that I got an incredible job working for YouTube, and I’d be crazy to pass it up. YouTube is owned by Google, and Google has been my dream company to work at for years. I’ll be a Web Developer there, just as I was in Chicago. It’s the perfect fit.

However, that’s not the only reason for the change.

It’s hard.

Packing up your life and leaving everything you know is not easy to do. However, that’s actually one of the things that made my decision to move really easy. A common theme I’ve noticed over the last few years is that doing the hardest of all possible options usually reaps the most rewards. Obviously you have to use your head when weighing options – coming to work naked just to make it more difficult to not get fired is obviously a terrible idea. I’m talking about those scenarios where you have multiple clear options, and one has more risk than the others. Voluntarily choosing the most difficult option will likely pay the most dividends in the future if you stick it out.

Moving to California is way harder than staying in my comfort zone in Chicago. So California it is.

I’m going to be surrounded be the brightest geeks in the industry.

I need to be around smart people. In fact, I need to be around people who are significantly smarter than myself. I need to be wrong, but more importantly I need someone that I respect to tell me why I’m wrong. Only when somebody can tell my why I’m wrong will I gain valuable insight. This is very true for working in the tech industry, but it is a universal concept.

I’m going to work for a Google company. Google is known – notorious, even – for employing some of the smartest people in the world. They employ the creator of Python. At a point, I believe they employed some of the creators of UNIX. They employ, obviously, Larry Page and Sergey Brin. Google has very smart people working for them. While they may lack the name recognition, YouTube has some brilliant folks working for them as well. And now, I am going to be working alongside these geniuses and learning from them on a daily basis.

At a higher level, California’s Bay Area is home to the biggest names in technology, including Apple, Facebook, HP, and about a million tech startups. These companies are each full of dozens, hundreds, or even thousands of brilliant people. Even better is the intermixing of these companies. Apple employees have friends at Google, and those Google friends know people at Facebook. The startups (at least the ones who aren’t in direct competition) are usually pretty social with one another. They share notes, hang out at the same coffee shops, and talk about ideas and collaborate. The Bay Area is the absolute best place to be young and working in the tech world.

It’s an adventure.

Leaving it all behind… starting a new life in an unfamiliar place… rubbing elbows with people you’ve only read about on the internet… It’s the stuff that movies are made of, what’s not to love? This is the adventure of a lifetime, and I can’t wait to see what living in San Francisco is like. There is nothing that will be boring and familiar, only new and exciting. New experiences, and new people, and a new city.

So, I’m effectively closing the first chapter of my life and starting on the second. I won’t forget where I came from, or the people I knew back in Chicago, but somehow I feel that moving right on top of Silicon Valley is what I was meant to do all along.

Some time ago, I ran across this article: How to Handle IE6: Aggressive Graceful Degradation, by Jonathan Christopher. What I took away from the article: We shouldn’t be killing ourselves to provide the same featuresets for IE6 as we do for modern browsers. I completely agree with this notion. The biggest challenge of front-end web development is supporting so many browsers with extremely varied capabilities. This is nothing new, and there have been a ton of solutions and approaches developed over the years to mitigate this.

In many cases, the secret to these solutions is to have fallback functionality for advanced features. This is the idea behind Graceful Degradation. Another solution is to provide a “shim,” a piece of code that is usually a very clever hack to make older browsers look or act kinda-sorta modern (such as DD_belatedPNG). These are all wonderful ways to make our website backwards compatible. However, these shims often come at a significant usability or performance cost. They also take more time for developers to implement.

For this article, I am mainly referring to CSS3′s advanced styling capabilities, and not functionality.

Going back to Jonathan’s article, he suggests we stop providing so many fallbacks for IE6. IE6 doesn’t support drop shadows, so don’t provide the hack fix for it. My question is, why support similar shims and fallbacks for IE7 and 8?

Your immediate answer to that might be something like, “Because it’s our responsibility as web developers. We can provide a similar experience for IE7 and 8 with a little extra effort, so we should.” Well… I question that. Why are there people on IE7 and 8, when IE9 and non-IE browsers are available? Here’s a quick list of reasons, off the top of my head:

• They are not tech-savvy and don’t know how to upgrade.
• They are afraid of upgrading.
• They are stuck in their ways and don’t want to bother upgrading.
• They actually like IE, and can’t upgrade to IE9 because they are on an older version of Windows.
• They are in some kind of environment that doesn’t allow them to upgrade or change their browser (such as a corporate environment).
• They have some kind of accessibility issue that requires them to use IE6/7/8.

There are more reasons than this, but these are the big ones. I contend that the majority of people who fall into these buckets don’t care about your design as much as you do. They are unaffected by your rounded corners, and they do not notice your subtle gradients. You are making more work for yourself in the name of users who are completely indifferent. More importantly, you are making your code and logic branches more complex and difficult to maintain. I think we can start to aggressively degrade the experience for IE7 and 8. Building on Jonathan’s idea of Aggressive Degradation, I think it’s time to push for Really Aggressive Degradation, or RAD for short. Because I think it’s a pretty rad idea.

If your users really valued design, they would not be on IE6/7/8.

Now, don’t get me wrong. Users on any browser that is in use today, including IE6 and above, deserve a working and accessible experience. They should be able to get to all of the same content that a Chrome user can; it is our job to provide it. If we cannot provide that, we have failed as developers. I am merely suggesting that, for situations where CSS3 would save a considerable amount of development time, we only provide the CSS3 solution with only a very basic, functional solution for browsers that don’t support it. Let’s stop wasting time with hacking a Chrome-like experience into IE6/7/8.

Or just suggest Chrome Frame to users. That works too.

One of the big commotions in the tech world right now is Microsoft’s shift to HTML5 and JavaScript as a development platform.  Whether or not this implicitly obsoletes other technologies (Silverlight, WPF, etc.) remains to be seen.  In either case, this news is pissing off the Microsoft loyalists, but is great news for the rapidly growing community of web app developers.  Being a supporter of open web technologies, I think this shift to HTML5 is great.  JavaScript is really good at many things, and I think that bringing it closer to the OS will make developer’s lives a lot easier.  One thing that I’ve always found the language to be really good at is how it handles asynchronous events.

Excuse me while I go fetch my Captain Obvious hat.

One thing that I always found kind of ugly with .NET development is how it handles events.  Here’s a simple example of how to bind a button click.  More to my point, here’s a terrifying example of how to bind to a system event.  When working with events in the browser and JavaScript, binding to a button click is pretty much the same as binding to a more “significant” browser event, such as DOMContentLoaded.  Imagine, for a moment, if binding to OS system events (like system wake/sleep, or starting/ending of a network connection) was just as easy.  Here’s some pseudo jQuery code for binding to the “SessionSwitch” event:

This might be a bit of an oversimplification of what the API could be, but I don’t see why it would need to be much more complex than this.  I think that Microsoft’s transition to HTML5 for a development platform is brilliant, I just hope they have the foresight to capitalize on the risk they are taking.

With the recent announcement of Apple’s new iCloud service, it is clearer than ever that the way we use the web is going to be more cloud-centric in the future. The benefits of using cloud-based apps and services are compelling – universally accessible data, endless storage, automatic saving, versioned backups, etc. Without even a hint of sarcasm, I think this is the way that computers and the web should work.

The thing that concerns me, however, is users’ ability to keep up with the technology. Apple’s vision is for the cloud to be transparent and “just work.” In fact, this is Apple’s philosophy for just about every product they make. This is the concept that gives Apple products such mass appeal, they are so simple that everyone and their grandmother can use it. In other words, users should never have to understand the complexities behind technology in order to take advantage of it.

I think that this transparency is going to introduce a whole slew of unforeseen consequences on the world. Why the world? Because everyone copies Apple’s successful products, and iCloud is a product that is going to succeed. Before the push to reduce everything to dumb terminals that access the cloud, our computers and devices were essentially isolated little data receptacles. If you lose your laptop, it would be devastating. Your email and bank account info is exposed, and all of your data is gone, if it wasn’t backed up. In other words, don’t freaking lose your computer Your life is in that box. While it seems passe in 2011, having only a few devices with total access to all of an individual’s data leaves relatively few ways to completely steal their digital existence.

What Apple (iCloud) and Google (Chromebook) want to do is put your laptop wherever your username and password is. This introduces a lot of obvious security threats, but what’s interesting is that now the goal is to make this invisible to users. They want our grandmothers to guard themselves behind the infallible security (cough cough) of a password. But how many people are going to actually understand the implications of this? And how many actual users have a password that’s secure? It’s hard enough to educate non-geeks on the importance of using common sense and discretion with the web, because non-geeks don’t really care. They just want their internets. Apple’s vision is to make people care even less about how or why things work, and to give them more internets. Yeah yeah yeah, you can prattle on all day about how users have a responsibility to be smart and educated users, but you know what? It’s never gonna happen. Only geeks are responsible and prudent users of the web, and we are vastly outnumbered by the non-geeks.

Case studies: Ed and Cristina

Ed is a 50-something baby boomer, an old friend of my family. Ed doesn’t understand computers. He uses the web and loves to check his Yahoo! mail and YouTube, but he doesn’t actually have the slightest clue as to what’s going on with his Dell, other than what he sees on the screen. The only reason he uses Google Chrome is because I told him that Internet Explorer is a virus, and he believed me. Quite literally, he doesn’t understand the difference between his desktop, the browser, Google, or the sites he goes to. He doesn’t see where the computer ends and the internet begins, or where Google ends and the sites it led him to begin. I’ve tried to make explain it to him for years, but Ed is as non-geek as they come. He’s just never going to get it.

Cristina, my brother’s 21 year old girlfriend, is a smart girl. However, she uses Internet Explorer 8 and refuses to change. I’ve explained to her again and again the benefits of other browsers, but you know what? She doesn’t care. IE8 is what she’s used to, and none of my nerdy mumbo jumbo is going to change her.

What do Ed and Cristina have in common? They are non-geeks. They are set in their ways. They cannot be educated on technology, and it’s not because they are unintelligent – it’s because they don’t care. They will never care. It’s these non-geeks that Apple wants to foist the burden of cloud computing upon. If Apple has its way, Ed and Cristina will, at some point, be transparently pushed onto cloud. And you know what non-geeks use as their password? “password123,” or something similar. “password123″ is the only thing that is going to protect them from complete identity theft, and it’s probably scribbled on a Post-It note in plain view on their desks at work.

I’m not trying to nay-say the cloud. I think it brings a whole world of benefits, and has a lot to offer. I just think that there’s another problem we need to solve first – making it so that people who don’t care about security don’t have to care about security. It’s the transparency of security concerns that we need to focus on, not the transparency of data access.

Lately, I’ve been changing my coding habits to use configuration objects whenever possible in my code.  In plain english, a configuration object is an object that you pass in as a formal parameter, instead of a list of separate parameters.  This is useful for a number of reasons:

• It makes your code more flexible
• It is more semantic (easier to read)
• It makes your code cleaner

This what a typical function definition and call looks like, with a laundry list of paramters:

And this is a significantly nicer looking definition and call with a configuration object:

If APIs like jQuery’s are any indication, this also seems to be the modern, preferred way of writing JavaScript. However, not all functions are written this way for one reason or another. In many cases it’s just a style preference, but there are situations where having to supply a list of formal parameters can be a burden. Let’s say we want to use jQuery’s super-useful $.extend() method, but we don’t know how many objects we are going to be passing into it – the amount can vary.  $.extend() can take any number of objects to merge into the target object, but they must be specified as separate formal parameters, not an array.

To account for this, we could have a whole bunch of logic that would mitigate this situation – or, we can model the configuration object approach and use Function.apply() to pass the formal parameters. Function.apply(), like Function.call(), is used to modify the value of the this keyword inside of a function – the only difference is that function.apply() accepts an array that will be passed into the function as the list of formal parameters.

An array is pretty straightforward to construct and modify, much easier than accounting for an unknown amount of formal parameters. Let’s take a rudimentary example of how we might call $.extend() with an unknown amount of objects to merge in, without function.apply():

This works, but it’s kind of ugly. And, depending on the function that we are calling, it might be inefficient, because it is getting called and running all of the function’s logic each time through the loop. If the function can accept all of those parameters at once as separate formal parameters, we should supply them as such. Here’s a better way of doing it that doesn’t involve calling $.extend() repeatedly:

The last line effectively makes this call:

The trick is to pass the method’s namespace ($, in this case) as the first parameter to Function.apply(), because we don’t want to change the context of the method. We now have control over the potentially dynamic list of formal parameters, and we can easily feed the $.extend() method any number of formal parameters we want.

Counter to my last post, I think it’s a waste of my time to do practice projects endlessly.  Great ideas must not be kept on the backburner!  I know what I need to make, and making todo apps and coding exercises – while valuable – simply isn’t the best use of my time.  So today, I started a Github repo for the project that will ideally consume my life and make me antisocial for at least the next five years.  It’s called Animatr.

The goal of the Animatr project is to create an animation authoring environment for the HTML 5 canvas. This idea has been brewing in my head for some time, and it’s a problem that currently does not have a solution. It’s also a problem that I am very excited to develop a solution for.  In the interest of open source, I’ll be making all documentation and progress public.

Wish me luck.

Anybody who knows me knows that I love to work on personal projects outside of work.  My projects are usually inspired from some spur-of-the-moment interest of mine; in the past I’ve made PHP blogging software, an HTML 5 Canvas library in JavaScript, and even the occasional game or two.  But lately I’ve had a dearth of inspiration, and I’m not entirely sure why.  At first I thought that it was simply due to lack of free time.  However, I don’t have much less free time than I did about a year ago, so that’s not why.  I think this all started about a month and a half ago, shortly before I went to the jQuery Conference in Boston (you can see my writeup here).  Normally an event like that would fill me with pep and gusto, but it actually had the opposite effect.

I guess I got it in my head that everybody else in the JavaScript/Web development/open source community had already thought of so many great ideas and implemented them, that I simply can’t make an impact.  Programming is simply problem solving, and unless you find a problem that interests you, you’re not going to spend time on actually developing a solution.  Additionally, if the problem you’re interested in has already been solved, then there isn’t much of a reason to spend time to reinvent the wheel.  In the past, that didn’t bother me.  I just made stuff because I thought it was fun.  I still find it fun, but at this point in my life, that’s not enough reason to devote countless hours to something.  There needs to be some higher level goal.

What I’ve learned recently, especially from my ongoing experiences at Jupiter, is that I don’t yet have enough software development experience to recognize the problems that need to be solved.  I’m not just going to get a devine flash of inspiration from thin air.  The only way that I’m going to make something that people actually care about is by working with more software projects.  Client work is a fantastic way to gain this experience, but that can’t be the only thing I do with my days – I need some kind of creative coding outlet that gives me control over development.  But, I also want to learn new tools and patterns.

JavaScriptMVC is truly a great framework.  I’m not just saying that as an employee of the company that develops it; it really, truly is a great project that solves a problem that nobody else is solving as well (organizing large web apps in a maintainable way).  I dare you to check out Controller and not love it.  I want to use JavaScriptMVC for more projects, because it makes things easier and speeds development.  Recently at work we realized that we need an internal todo application, and that none of the myriad of existing solutions precisely fit our needs.  So, I am starting developing on my own todo application, which you can keep tabs on here.  Does the world need another todo application?  Not really, but that’s not the problem I’m trying to solve.  I want more experience with developing flexible, fast web apps the right way – I’m tired of hacking things together and just being happy that it works.  I want the code to kick ass.  I also want to see a wider range of projects than just my client work.  I think that if I have my hands in a wider variety of projects, I’ll be able to recognize the recurring development challenges more effectively and figure what problems need to be solved.  I also want an excuse to learn Ruby on Rails, which is what will power the backend of the app.

Also, I plan to use JavaScriptMVC and the design patterns I am currently practicing for my master plan.  But what that is, I’m not going to discuss just yet.  You’ll just have to wait and see.  :)

I recently wrote a rather lengthy blog post on Jupiter’s site about DOM events. Hopefully I’ll have more chances to blog for Jupiter in the future. Head on over to learn the nitty gritty details of the DOM!

I got a lot of help from @justinbmeyer and @brianmoschel for the article.  Thanks, guys!

Doing open source the right way

Today was interesting.  My FTP application of choice on the Mac is Cyberduck, which is free and open source.  Cyberduck has served me well over the years, but recent updates seem to have diminished the reliability and usability of the application.  It’s usually very minor things that are intermittent, and maybe it’s just me, but they’ve hampered my enjoyment of the app.  Today I fired up Cyberduck and was greeted with a prompt to update, so I did.  When the updated application restarted, two things annoyed me:  I now had two FTP browser windows where before I was used to just one, and each window had a poorly placed “donate” button, which was distracting.  I have no problem with developers nagging me gently for money, but when it’s done in a really annoying way, I’m inclined to stop using the application entirely.  My frustration caused me to tweet about it.

Within moments, @davidkocher – the lead developer of Cyberduck - tweeted me directly and asked what was wrong.  He also requested that I fill out a bug report.  I was very impressed with his attentiveness and obvious dedication to the Cyberduck project, that I filled out a support ticket as he asked.  This a great example of the right way to run an open source project.  Oftentimes, you’ll have users (like me, in this case) who will just sit and stew with how unhappy they are with software.  With things like Twitter, it’s easier than ever to find and reach out to users.  It hadn’t even occurred to me to fill out a bug report, but I’m going to make a point of doing so with open source apps I use from now on.

It’s worth mentioning that this same scenario occurred with JavaScriptMVC, which my company, Jupiter, started and maintains.  Someone on Twitter had a complaint about the software (I can’t find the tweet), and my boss (and JavaScriptMVC co-author) @justinbmeyer immediately responded to get to the root of the problem.  The initial tweet wasn’t even directed at anyone!  The dialog led a long and helpful discussion the JavaScriptMVC Google Group, and the project is going to be improved because of it.

If you are an open source software user and you have a complaint, let the developers know.  They want to hear why you don’t like their software so that they can make it better.  If it’s broken, fill out a bug report.  Community interaction is the lifeblood of open source, and it makes it a lot of fun as well.

I was talking shop with my friend Ross yesterday (http://github.com/draggor), and we got onto the subject of development environments.  For the last month I’ve been working on primarily one project for Jupiter, and although it is based entirely on cross platform technologies (JavaScript, Java, and Flash), I’ve been doing 100% of the work in a Windows 7 virtual machine, with 1GB of RAM allocated to the guest OS.  The physical machine is a MacBook Pro with 4GB of RAM.  Considering the project’s requirements and specifications, I could have just as easily done all the work in OS X, with access to all of my computer’s resources.  Ross was bewildered as to why I would restrict myself to a virtual machine, as it’s a considerably more cumbersome way to work.

I explained:  I don’t ever want to be in a position where I’m wasting hours or days trying to resolve some problem that never would have come up if I had just used the same development environment as the rest of the team.

Granted, if I was really gung-ho about this, I’d go all the way and install Windows in a partition and dual boot my Mac.  For a number of reasons, I don’t like dual-booting, and a virtual machine does the trick for projects that are not graphically intensive.  However, I’m still making a sacrifice in the way that I prefer to code, and I think that it’s important to do so.  Different projects require different development environments, and making sure you’re on the same page as everyone else prevents a lot of unnecessary stress.

When you are working for a client, your job is to get the best job done as quickly as is reasonable, and if that means using an OS or an IDE that isn’t your cup of tea, you just have to deal.  The tools you love the most will always be there when it comes time to work on your personal projects.