Recently Mike Driscoll took a shot across the bow of the LAMP stack in an article called Node.js and the JavaScript Age. Arguing that the LAMP age (2000 to 2009) was about shuttling data back and forth from the database, he asserts that in the JavaScript age

The principal role of the server is to ship an application to the client (Javascript), along with data (JSON), and let the client weave those into a DOM.

Mr. Driscoll envisions a world where the server becomes “dumb” and the client increasingly becomes the brains of the operation. This comes after his team migrated a dashboard application from Django (Python) into node.js (JavaScript). Mr. Driscoll points are compelling. Imagine that after more than a decade of technology specialization we may finally be on the cusp of a fully unified web stack – mongodb as your data store, node.js as your server environment, and JQuery in the browser – based entirely on JavaScript. We could be witnessing the dawn of the JavaScript stack.

The benefits of the JavaScript stack are clear – code libraries shared across a homogenous team of JavaScript developers leading to reduced development and maintenance costs. All of your unit tests in one language! How can it fail?

In reality it’s probably not going to be that simple.

One big hole (pun intended) in Mr. Driscoll’s design is security. Yes, in some applications only 10% of your server-side templates are HTML. But that 10% is the core of your business, the bits of data you can’t expose directly to the client for them to tinker with – things like account numbers and product prices. This might not be critical for internal-facing reporting apps like Mr. Driscoll’s dashboard app but for public-facing dynamic apps like EBay it’s the difference between success or crash and burn.

Furthermore, current web development teams are specialized for a reason. Front end programming has different demands and patterns than does server-side programming, and these are both very different than database design and programming. Startups and smaller teams might have rockstars who operate seamlessly across tiers, but these developers can be hard to find. So even though JavaScript might be a common language across application tiers, the reality is that as your team grows you’ll still need specialized developers to be effective across all three.

Lastly, even though node.js promises performant asynchronous application design, the truth is that many developers face a steep learning curve before they can be effective programming (and debugging) in asynchronous environments. Like Java threading before it, asynchronous programming will likely find its niche solving certain problems but never become mainstream. Or it will be hidden behind so many layers of framework programming as to be nearly unrecognizable and totally unusable.

So LAMP is far from dead. It will persist exactly because it’s a perfectly tuned commodity solution in a market that values commodity solutions (e.g. Google’s famed server farms). It’s the UNIX of the web layer, encouraging extensible designs by nature of its simplicity and interoperability.

Every age has its upstart, and this age is no different. But to win the upstart has to bring more to the table than the established solution, and it remains to be seen whether the JavaScript stack has what it takes to displace the LAMP juggernaut.

In an article I had published in infoTech Spotlight discussing security and the Gawker database hack, I argued that it’s relatively easy to protect your user’s personal data against a database breach. The idea isn’t new – as a matter of fact this particular implementation dates back to 2005, and you can be sure it was known well before then.

Faced with a similar breach, Mt. Gox appears to have performed a little better. Although they originally depended on md5() hashing to secure their passwords (warning: do not do that), they came to their senses and started salting individual passwords much the same way as this article recommends.

Good for them. This is a great case study on how an organization who borked it was able to retrofit their code to protect their users. I applaud them for that effort. It may not have been perfect, but it was likely good enough for users who were smart enough to protect an account on a financial exchange with a half-way decent password.

As an aside, it’s a little disturbing how many of the nerds on the Hacker News don’t understand that not only is it ok to store the salt alongside the encrypted passwords in your database, it’s actually a good idea. Ugh. Another reason why developers should never be trusted to roll their own authentication schemes.

Unfortunately, Mt. Gox’s security lapse has come at a crucial point for Bitcoin. Bitcoin is an interesting economic experiment. I encourage you to read up about it as the official docs can explain it much better than I can here.

While it’s strictly true that Mt. Gox != Bitcoin, at this point in the evolution of the movement few people have the sophistication to understand the difference. So it might not be fair, but it’s still entirely possible that this incident could torpedo the movement. That’s unfortunate for many reasons, but it’s a reality of the world we live in. An upstart economy can’t prevail without trust.

It seems that 8 lines of code may not be enough.

I probably spend way too much time thinking about this, but every time I watch either Episodes 2 or 3 I’m left with the feeling that the key tragic sequences in the series both involve Mace Windu.

The first one is the most obvious. In Episode 3 he had a chance to kill Palpatine straight up but hesitated, leading to his bungee jump out of the Chancellor’s office without a bungee cord after Anakin’s betrayal. Cool cat, but died like a punk really.

The less obvious one is his beheading of Jango Fett in Episode 2. Don’t get me wrong, the Geonosis sequence is probably one of the best fight scenes in the prequels. But if you think about it, Jango was the weak link in all of Palpatine’s plans. There were probably only 3 characters in the whole galaxy that knew the details of Palpatine’s gambit to rule the galaxy by playing both the Republic and the Separatists against the Jedi. The first was Palpatine himself. The second was arguably Dooku, who lead the straw-man Separatist movement until Anakin relieved his shoulders of his head. The last had to be Jango, who was the source of the clones used by Palpatine as well as Dooku’s bodyguard on Geonosis. Capturing instead of killing Jango could have unraveled the whole plot.

But even still, it strikes me as unbelievable that at least Obi-Wan, if not Yoda and Mace, wouldn’t have been able to connect the dots on Jango. Obi-wan confronted him on Kamino and then sees him again on Geonosis. It probably doesn’t take too much brain power to wonder why the guy’s popping up on both sides of the fence.

Something about the Donors Choose Hacking Education contest appealed to me so I started brainstorming ideas. After a eureka moment (more to come on this later), I was determined to dig in and start coding. With all the hubbub about fan favorite Slicehost dissolving into Rackspace in the near future, I thought the time was right to explore other options.

Enter DotCloud. Similar to Heroku, PHP Fog, or even Google App Engine, DotCloud is a platform as a service. Like Heroku and PHP Fog it’s backed by Amazon AWS. Unlike those other platforms though DotCloud is committed to supporting a variety of open source languages, databases, and message buses. Not just Ruby. Not just PHP. Don’t even get me started about some proprietary environment.

Love. It.

You can mix and match these environments to suit your taste. Want a PHP server with a MongoDB backend? No problem. Spin up a PHP instance and a MongoDB instance and then configure your PHP connection settings. Need some memcached? No problem, throw that in as well. All the instance types are specialized but interoperable, usually requiring nothing more than a little config to connect the dots between the components.

I’m thoroughly impressed with DotCloud. For a developer there’s much to like, and maybe a few concerns to express. Here’s where I stand:

The Good

• Easy setup: It’s not an exaggeration to say you can have a site up in minutes.  Their tutorials are clear.  I control the code locally and then push it up to DotCloud when it’s ready. They deploy it automatically for me. Perfect.
• Easy management: I can’t tell you how much time I wasted worrying over minutia in my Slicehost setups.  What Linux flavor and version should I choose?  What ports should I open?  How many user accounts should I create?  Where should I put my web root?  Is my nginx config optimized?  Is the box locked down enough?  Although it was a great learning experience, the fact of the matter is that I’m not and never will be a sysadmin.  I’m a developer.  The good people at DotCloud are (hopefully) competent sysadmins.  Let them worry about it.  Me, I’ll just focus on the code.  Mission accomplished.
• Truly technology agnostic – Here’s my favorite line from the help docs: “Q: Do I need to use Git to use DotCloud? A: No. We want to help all developers – and not all developers use git.” Fuck yea. Makes Heroku seem snobby by comparison (git only). Look, I know what they’re hoping to accomplish isn’t easy. The reason why Heroku is so popular is that it’s made for Ruby geeks by Ruby geeks. It’s not easy to perfect one language or platform, much less multiple ones. And let you mix and match them at will. But that’s where the next point comes in.
• Great tools: They’ve hit the perfect balance between “we’ll handle that” and “you can do that if you need to”. They’ll set up a MySQL instance for you. But if you need to get in there to hack some data, you can do that. You can deploy without needing to ssh into your web box, but you can if you want to. Flexibility is the key here. I was thrilled to find that I could customize my nginx.conf file to clean up my CodeIgniter URLs (removing index.php). Last night I spent about 20 minutes configuring an SMTP instance so it will automatically use a gmail account for relay when I call mail() from my code. And yes, you can set up cron jobs. They even provide an SSL cert if you need it (as long as you use their domain). It seems they’ve thought of everything.
• Command line: Their single command line utility “dotcloud” has everything built into it, but everything makes sense. The commands have become 2nd nature to me after only a few weeks of usage. They nailed it.

The Bad and The Unknown

• Support: I had a problem pushing some files to my instance recently. Being a beta service, I waited about 6 hours before contacting them about it. There was no notice on their site, and my email went unanswered. But eventually the issue did resolve itself. Still, a little scary. I would expect them to be on top of stuff like that.
• Background processes: I’m still not really sure where the best place to run background processes is. I typically like to hack up some Perl to do batch updates and stuff like that. Although I can ssh into the instance and set up cron to run some random Perl script, I don’t have permissions to pull down new modules from CPAN, so I’m SOL to some degree. For now I’m running the background processes on a Slicehost box.
• Pricing: Right now it’s Free (as in Beta). There’s no indication of what the eventual pricing model would look like. My main concern here is that for my small app I’m using 4 separate instances (php, mysql, static, and smtp). A per-instance pricing model is going to kill me.
• Virtual hosts: Related to pricing, I’m not clear how I would set up virtual hosts. On one of my Slicehost slices I’m hosting 3 instances of WordPress and a random other site, all on unique domains all with the same nginx configuration. I’d hate to have to manage 4 separate instances for this.
• Scaling: Everything seems to work nicely in a single-server environment. What’s not clear to me yet is how they will handle horizontal scaling of front end web servers running the same code. I’m confident they’ll figure this out, but hopefully it won’t complicate their architecture too much.
• Performance: Since they’re EC2-backed I’m not as concerned about web server performance. My concern is more about internal network performance, i.e. web server to database. I’m not even sure how to monitor this or what can be done to improve it. If they’ve done their jobs right this shouldn’t be an issue, but it’s likely to come up at some point.
• Monitoring: I haven’t found any built-in tools for system monitoring yet. These would be nice but again, since it’s EC2-backed it’s possible you can use third party tools for this.
• Source Control: It might be nice if they offered a git or mercurial instance type so you can keep your code in the cloud as well. I would consider it but I’m not sure how many others would. Right now I’m using CodebaseHQ, which is a poor man’s version of FogBugz/Kiln.

The Future
I’m becoming more comfortable with the idea of deploying a “real” site on DotCloud. Although I don’t imagine R/GA’s clients selecting it any time soon, it seems ideal for everything from rapid prototyping through early startup. Migration to another platform should be simple because you’re not locked into any proprietary languages or workflows. DotCloud is the next logical step in the evolution begun by Amazon years ago – commoditize what can be commoditized, customize the rest. I’m sold.

Your site just went down. Don’t panic. Think. Could be anything, but you need to start somewhere. Check the database? Check DNS? Scratch that, get out a checklist.

Atul Gawande’s “The Checklist Manifesto: How to Get Things Right” has stormed through popular culture leaving a lot of heads spinning in its wake. The premise is all the more enticing for its simplicity – can something as simple as a checklist reduce common errors and let us focus on the important stuff? Mr. Gawande details the use of checklists in the operating room, where they have slashed complications from surgery more than 30% in some hospitals. That impressive track record is bound to draw attention from leaders across many industries. Reading between the lines I found some important lessons to consider before adopting checklists at your workplace:

1. Checklists Must Become Part of Your Routine

If you rely on yourself to remember to use a checklist you probably won’t. You must change your processes so that checklists are fully integrated. Consider adding it into your production deployment scripts so that you have to work through the list before you can push code. Or consider making it part of your daily scrum so that everyone’s on the same page. Whatever the case, however you manage to do it, you can’t rely on human intervention or it’ll fall out of practice.

2. Checklists Really Matter When Mistakes are Very Costly

Before you go checklist crazy make sure a checklist is the right fit for the type of problem you’re trying to solve. It turns out that the value of a checklist is directly tied to how costly the mistakes it prevents are. A pilot who loses lift at thirty thousand feet doesn’t have a lot of time to debug the situation. While not as life-or-death, running through a simple checklist before restoring a backup might go a long way to ensuring that you don’t clobber your user table for good.

3. Checklists Always Involve At Least 2 Parties

A checklist works best when there’s someone reading from the list (e.g. the copilot or the nurse) and someone else performing the checks (e.g. the pilot or the brain surgeon). It’s kind of like Extreme Programming in that way. So you may consider having your QA team be involved in a pre-launch checklist. Or you may have your tech leads involved in a pre-vacation checklist to ensure all work has been handed over cleanly. Whatever the case, splitting up the work between two people helps focus each on his or her role in the process.

So back to your site. Thanks to your finely tuned checklist you’re reminded to check for recent production pushes on a related but separate project. They didn’t mean to do it, but thankfully the checklist helped you recover quickly. Time to go update your unit tests.

For anyone other than my mother still reading this blog, I’ll be blogging to support R/GA’s new techblog. I’ll point to any posts I author there when I get around to it. Since this blog is all about me, it’s pretty much just a complicated way to bookmark my R/GA posts.

To get it started, here’s a repost of an article R/GA helped me publish through infoTech

This article was originally posted here.

Enjoy!

It seems trite but it’s important to consider how technology enables things in ways that you can’t predict. Back in my TSN days I had an idea for a game that would be played during a sporting event. Since most of fantasy sports takes place before or after the event, it made sense that someone would try to fill that gap.

The problem was that I envisioned it as a web-based game because there was no such thing as an iPhone back then. Turns out a web-based game that you play while watching a sporting event on your television at home isn’t that appealing to people. Especially if it’s a NASCAR game (because at the time there were questions about whether MLB would win the CDM case). But with with the advent of the iPhone that no longer sounds insane. As a matter of fact it kinda sounds interesting again. If you had a very lightweight game mechanic (think predictive questions) and some fun side-effects, you could probably make a decent fantasy game out of just that. Food for thought.

As I mentioned previously I’ve been involved in the Winter 2009 semester of the Founder Institute in NYC. I thought I’d write a little bit about what I’ve learned to help others get the most out of the experience. Some of these are practical, some of these are just things to keep in mind as you progress through the semester. In no particular order….

• You’ll get the most out of it if you have an idea of what you want to do before you start. To its credit, the Institute will accept you if you don’t have an idea, but to some degree I think this is giving people just enough rope to hang themselves given the aggressive nature of the curriculum. The fact of the matter is that those of us who got the most out of the Founder Institute came in already pretty much knowing what we wanted to do and spent a lot of time tuning and focusing it. Yes, the first couple of sessions will be about how to develop an idea, how to research the opportunity, etc. I found the information to be very useful, but more in a “good to know for next time” way. It’s really hard to keep up with the later sessions if you spend the first 3 or 4 weeks vetting 5 different ideas.
• Therefore, getting in is about you as a founder, not your idea. But staying in is about how well you execute on your idea. Don’t forget that you are expected to have an incorporated company with a real business model and a real plan for success at the end of this. It’s not as easy as it looks.
• Actively seek out those who will challenge your assumptions sooner rather than later. It took me a while to realize that those who didn’t want to talk about their idea (including myself) were doing so because they didn’t want to hear the hard truth about what someone else thought. I know it’s not easy to hear. We’ve all convinced ourselves that whatever we’re thinking of doing can’t possibly fail and that anyone who doesn’t see it that way is wasting our time. That’s expected. But keeping it to yourself doesn’t prove anything. You join this program because you want your idea to succeed.
• Sign up for office hours. It’s free advice from people who have done this before and want to help you succeed. If you’re serious about building a business there’s no excuse for passing that opportunity up.
• Keep an open mind at all times. That pain you feel when someone criticizes your idea – that’s called growth. No one’s going to plunk down a bag of cash for a clever idea. At times someone “just won’t get it”. When that happens you can either find a way to convince them or become defiant and disengage. You can probably guess which one will work in your favor long term. Take the feedback (good and bad) and get better.
• That being said, know when to take advice and when to leave it. It’s your company. Don’t ever forget that. It was your company before the Founder Institute. It will be your company after the Founder Institute. If something really matters to you, stand your ground. Realize that you may still be wrong, but at least you learned something valuable.
• Volunteer to be president of your working group. People act like being the president of the group is like getting the plague or something. It’s not that bad. For the most part you’re just organizing meetings and taking notes. Yes, there are some founders who can’t keep up and you have to find a way to motivate them. It can be time consuming in a lot of ways, but it’s good practice and there are a number of upsides that come with the role. I was president for the 2nd and 3rd groups and found it to be valuable.
• Time is short, be ready to work. Kinda goes without saying. There’s not a lot of time in the program and a lot to do. If you’re going to do this right it’ll need to be a priority in your life for 3 or 4 months. Make sure your spouse or significant other understands this as well.
• Network, network, network. Get to know the other founders. Go out for drinks after each session. Find out about their business. Tell them about yours. Organize on LinkedIn. Connect with mentors where appropriate. These people have a stake in making sure you’re successful and you have a stake in making sure they’re successful. A little extra effort will pay off for everyone.
• The working groups can make or break your experience. A good working group can help you in more ways than you expect. A bad working group can really tax your energy. If things aren’t going well in your group, talk to your president. If he or she doesn’t listen talk to your local facilitator. Don’t let it slide. It’s up to you to get as much value as you can out of the experience, and every week counts.
• The mentors are great but aren’t everything. I came in expecting a one-on-one mentorship. It was a bit naive. The mentors are both successful and busy. They are all nice, and all helpful, but don’t expect too much. Honestly I don’t think I connected on a personal level with many of them. Part of it is that none of them really know my space very well, and I can’t really blame them that for that. It might speak more about my company than I want to think about.

Feel free to ask questions in the comments. If appropriate I will contact you directly via the email address you supply. As I’m still participating in the Founder Institute I’ve tried to avoid any conclusive statements. There’s still a lot of time left in this semester and a lot has changed even since my last post.

We recently bought my mother a digital photo frame for her birthday. The product itself was really nice – connect via USB, WiFi, flash cards, etc. Shows pictures, plays movies, plays music. Perfect gift for a tech-savvy mom who has a growing family.

But the real star of the show was actually Picasa. If you don’t know, recent versions of Picasa will actually scan faces in your photos and present them to you so you can provide names. It does the hard work, and you can coach it along by accepting its suggestions or providing a correction. It then indexes your images so that you can find all images with Aunt Sally, or all images with your brother *and* Aunt Sally.

With this it became trivial to preload my mom’s digital photo frame with family photos. Go through the index for reach family member and copy over some memorable shots. Easy and amazing.

I know it’s not new, and I know Google didn’t do it alone, but this seems to me to be a major milestone for the digital era. Wheels were important, and a lot of things can be done with a wheel, but history truly took a turn when someone strapped a motor to 4 of them and made a car. I feel the same way about digital cameras now. Important, but the dawn of facial recognition on the desktop makes this something else. I can only imagine what comes next. I’m sure someone out there has been spending a lot of time on exactly that. I can’t wait to see it.

For the past month I’ve been involved in the Founder’s Institute NYC Winter 2009 program. The program’s aim is to train founders in the art of building a business so they can avoid common missteps and give them a better shot at being successful. There are about 40 founders in the NY session, representing a good cross section of industries and skill sets.

I haven’t written much about it yet because I wasn’t sure what to say. The process of applying and getting accepted was incredibly condensed and emotional (read: delusions of grandeur). As those hopes and dreams slowly adjust back to reality I’m seeing both the good and the bad. It’s mostly good, but not entirely. One thing I struggled with going in was what I expected to get out of it. I spoke to other founders informally about that question and the answers varied widely. My initial impression was that no one really new what to expect. That can be both a challenge and and opportunity.

I’m reserving final word for later – there’s a long time to go and many things could change – but so far I think the experience has been helpful in a number of ways, both intended and unintended. One of the first things Adeo Ressi said was that Founder’s Institute is not going to make or break my business. It will give me some tools that will help, but it’s still up to me. I think that’s very valuable advice and something I have to keep in mind as I go through process.