Raible Designs

The Art of AngularJS in 2015

I've been tracking statistics on jobs and skills for JavaScript MVC frameworks ever since I Compared JVM Web Frameworks at Devoxx France in 2013. At that time, Backbone was the dominant framework.

Last year, I updated those statistics for a presentation on AngularJS at Denver's Derailed. Angular had a similar amount of jobs as Backbone and a lot of people added it to their LinkedIn profiles. I found that Ember had grown around 300%, Backbone 200% and Angular 1000%!

Before presenting on AngularJS at last night's Denver Open Source Users Group, I updated these statistics once again. The charts below show how the number of jobs for Angular has doubled in the last year, while jobs for Ember and Backbone have fallen slightly. As far as skills, developers learning Ember and Backbone has increased 200%, while skilled Angular folks has risen 400%.

Yes, AngularJS has experienced huge growth in the last couple of years. You might even say it's the Struts of the JavaScript world.

For the presentation I delivered last night, I made a number of improvements over last year's. I added a live coding demo based on my Getting Started with AngularJS tutorial. I used IntelliJ's live templates to make it look easy. However, since the audience was quiet, and some were falling asleep, I skipped over the testing demo.

Core HTML5 Canvas Book Review

I've known David Geary for quite some time, from our original meeting in the blogosphere to speaking on the No Fluff Tour. At first, I had trouble respecting the guy because he was such a JSF Fanboy. However, over the years, he's switched to Ruby on Rails, GWT and now he's all about HTML5. Specifically, HTML5's <canvas> element. When David asked me if I'd like a copy of his lastest book, I jumped at the opportunity.

I received it in the mail shortly before heading to Hawaii this summer. I started reading it by the pool the next day.

I was immediately impressed that the book was printed in color. The first copy I ever saw of my Spring Primer was in color and it really popped. Geary's book does the same and I'm glad the publisher decided the extra cost of printing was worth it. In the preface (and in a recent blog post), David explains how he wrote the book code-first in the Zen tradition, so you can read it without reading. I saw him write somewhere that he spent 2 years, 60 hours per week writing it. It really shows - the sheer amount of code and knowledge in this book is amazing.

Looking back at the Table of Contents, I remember getting overwhelmed early on. Not overwhelmed in that I didn't understand how things were working, but more like "there's too much in here to try and remember it all". I haven't used algebra since high school, and right there on page 53 it says:

To do anything interesting with Canvas, you need a good basic understanding of basic mathematics, especially working with algebraic equations, trigonometry, and vectors.

Reading the book poolside wasn't a huge motivator to refresh my algebraic knowledge, but I did enjoy David's brief 10-page refresher. In Chapter 2 on Drawing, the book dives into the low-level API that canvas offers for drawing rectangles, circles and polygons. It also goes on to show you how to do gradients, patterns and shadows as well as all there is to know about paths, stroking and filling. This is when it hits you that <canvas> is more about JavaScript than HTML. In fact, it's usually only a couple lines of HTML and a whole lotta JavaScript.

In Chapter 3, you learn about text and how to work with fonts and paragraphs. David even spends 10 pages showing you how to implement a Paragraph, complete with positioning the cursor, adding new lines and working with backspace. It really makes you appreciate what HTML offers you with the good ol' <p> and <input type="text">.

Chapter 4 is where you learn about working with images and video, using offscreen canvases and working with a canvas within a canvas. I believe I was back in Colorado when I started reading this chapter. It's also where I succumbed to the fact that this was an excellent reference book and not something I was going to read, learn from and start using the next week. It feels like a book I'll refer back to many times when using <canvas> on a project. The amount of knowledge in the book seems akin to Rod Johnson's J2EE Development without EJB. I remember getting the general gist of Rod's ideas while reading the book, but not knowing how to put them into use. Then the Spring Framework was introduced and everything became clear. As I read Geary's book, I thought the same thing - someone really needs to develop a simpler API for Canvas.

As I read on, through chapters on Animations, Sprites, Physics, Collision Detection and Game Development, it hit me - maybe that's what David is doing!

Throughout the book, David builds a framework for working with Shapes, animating them and finally, for putting them to work in a gaming environment. The Ungame is nice in that it shows you how to use a game engine for building your own games. Then he goes on to show you a Pinball game that looks overly complex, but breaks it down into terms you can understand.

The last chapter is on Mobile development. It explains in detail about the viewport metatag, media queries for CSS and touch events. The section on iOS5 is good, but does make the book seem slightly outdated with iOS6 coming out next week. I'm sure all of the content is still relevant, but it almost seems like labeling it iOS5+ would've been better. In the final pages of the book, you learn how using a canvas that requires typing on a touch device might suck. David shows you how to implement a Virtual Keyboard to handle these situations, since the native keyboard won't pop up unless you're typing into HTML controls like <input> and <textarea>.

I read this book to learn more about Canvas and what it was capable of. I learned all it can do and much, much more. I learned how animations and timing can be different between browsers and how you might need to create a polyfill for requestAnimationFrame for it to work consistently.

More than anything, I recognized that this is one of the few technical books I've read in a long time that's become an instant valuable resource. With other books, the information is often available online. Not so with Geary's book. To me, it seems like the best resource available for learning and using HTML5 Canvas.

Well done, David, well done.

PhoneGap for Hybrid App Development

This afternoon, I attended Brian LeRoux's talk on PhoneGap for Hybrid App Development at Devoxx. You might remember that I tried PhoneGap last week and really enjoyed my experience. Below are my notes from Brian's talk.

PhoneGap is a project for creating native applications using HTML, CSS and JavaScript. PhoneGap started out as a hack. In 2007, Apple shipped the iPhone and Steve Jobs told everyone they should develop webapps. PhoneGap started in 2008 as a lofty summertime hack and gained traction as a concept at Nitobi with Android and Blackberry implementations in the fall. In 2009, people started to pay attention when PhoneGap got rejected by Apple. They added Symbian and webOS support and Sony Ericsson started contributing to the project. They got rejected because all PhoneGap-developed apps were named "PhoneGap". This turned out to be good press for the project and Apple let them in shortly after.

In 2010, IBM began tag-teaming with Nitobi and added 5 developers to the project after meeting them at OSCON. In 2011, RIM started contributing as well as Microsoft. Then Adobe bought the company, so they're obviously contributing.

PhoneGaps Goals: the web is a first class platform, so let people create installable web apps. Their second goal is to cease to exist and get browsers to adopt their model.

PhoneGap is NOT a runtime or a compiler/transpiler. It's not an IDE or predefined framework or proprietary lockin. It's Apache, MIT and BSD licensed to guarantee it's as free as free software gets. You can do whatever you want to do with it. PhoneGap has recently been contributed to the Apache Software Foundation.

The biggest issues with contributing PhoneGap to Apache is renaming the project and source control. I'm not sure why it needs to be renamed, but it's likely that Apache Callback is out. There seems to be some consensus on Apache Cordova. Apache likes SVN and the PhoneGap community currently uses Git. They're trying to find a medium road there, but would prefer to stay on Git.

The PhoneGap technique is colloquially called "the bridge". It's a 3 step process: they instantiate a WebView, then they call JavaScript from native code, then they call native code from JavaScript. Apparently, all device APIs are available via JavaScript in a WebView.

The primary platforms supported are iOS >= 3, Android >= 1.5 and BlackBerry >= 5.x. They also support webOS, Symbian, Samsung Bada and Windows Phone. No mobile dev platform supports as many deploy targets as PhoneGap. Primary contributors are Adobe, IBM, RIM and Microsoft.

Documentation for PhoneGap is available at http://docs.phonegap.com. Device APIs for PhoneGap 1.0 included sensors, data and outputs, which all devices have. Examples of sensors are geolocation and camera. Data examples are the filesystem, contacts and media. Outputs are screens, speakers and the speaker jack. All PhoneGap APIs are plugins, but any native API is permitted.

What about security? Brian recommends looking at the HTML5 Security Cheatsheet. PhoneGap has added a lot of security measures since they've found the native API pretty much opens up everything.

PhoneGap doesn't bundle a UI framework, but they support any JavaScript framework that works in the browser. PhoneGap is just a fancy browser, so your code run in less fancy web browsers too. This means you can develop and test your app in your desktop browser and only use PhoneGap to package and distribute your app.

Competition? PhoneGap has no competition.

PhoneGap/Build is for compiling your apps in the cloud and free for open source projects. The biggest reason they did this is because they couldn't redistribute all the SDKs and it was a pain for developers to download and install SDKs in training classes.

For mobile app development, you should have a singular goal. Do one thing really well if you want to be successful. Great UX happens iteratively. You know that the web works and has been widely successfully cross-platform. It's likely you've already invested in the web. Start by building a mobile web client and use PhoneGap as a progressive enhancement technique.

Shipping and unit testing should be a daily activity. Automate everything so you can have one-click builds (test/dev/release). For web client design, constraints are your ally in the battle against complexity and "clients who are not chill". Phones suck and consume a lot: cpu, ram, bandwidth, battery, network... everything! Start with a benchmark of app performance and monitor that benchmark. If you have tons and tons of features, consider splitting into multiple apps.

Looks can kill: aesthetics that can hurt performance: border-radius, box-shadow and gradients can slow down your apps. Chances are, you really don't need these features. Design your app for your brand, not for the device manufacturer. An app that looks like an iPhone app on Android doesn't give a positive impression.

For JavaScript libraries, start with your problem, not a generic solution like Sencha or jQuery Mobile. Zepto and its older brother XUI are all you need to start. Jo is a fantastic option. Backbone and Spine are worth watching.

For testing, QUnit and Jasmine are pretty popular. For deployment, concat, minify and obfuscate your JavaScript and CSS. Or you can inline everything into the markup to minimize HTTP chatter. Gmail inlines and comments all their JavaScript and then evals it.

From there, Brian recommended leveraging HTML5's AppCache and and using RESTful JSON endpoints for legacy systems. Next, he tried to show us a demo of a photo sharing application. Unfortunately, the Demo Gods were grumpy and Brian couldn't get his computer to recognize his Android phone. He did show us the client code and it's pretty impressive you can use 1 line of code to take a picture on a phone.

The last thing we looked at was debug.phonegap.com. This is an app that's powered by weinre. It lets you enter a line of JavaScript in your client and then remotely debug it in a tool that looks like Chrome's Web Inspector. Very cool stuff if you ask me.

Summary
I really enjoyed learning more about PhoneGap, particularly because Brain emphasized all my web development skills can be used. I don't have to learn Objective-C or Android to develop native apps and I don't even have to install an SDK if I use PhoneGap/Build. Of course, my mobile developer friends might disagree with this approach. In the meantime, I look forward to using PhoneGap to turn my mobile web clients into native apps and finding out if it's really as good as they say it is.

What's your preferred development infrastructure stack?

Over the years, I've used many different source control systems, wikis, bug trackers and continuous integration servers. On many projects, I've been responsible for recommending and helping to install these systems. For the most part, they've often been disparate, meaning there wasn't a whole lot of integration between the various applications. Here's a list of all the different systems I've used:

• Source Control Systems
  • CVS
  • StarTeam
  • Subversion
• Source Viewers
  • FishEye
  • Sventon
  • Trac
  • ViewVC
• Wikis
  • Confluence
  • MediaWiki
  • JSPWiki
  • Trac
• Bug Trackers
  • Bugzilla
  • JIRA
  • StarTeam
  • Trac
• Continuous Integration Servers
  • Bamboo
  • Continuum
  • CruiseControl
  • Hudson
• Mailing Lists / Forums
  • A private Google Group
  • Jive Forums
  • Mailman

I believe all of these applications are useful in supporting an efficient development process. When clients have asked me to help them build this type of infrastructure, I've often asked if they wanted to pay for it or not. If not, I'd recommend Trac (since it has a wiki, source viewer and bug tracker all-in-one) and Hudson. If they were willing to pay, I'd recommend the Atlassian Suite (Confluence, JIRA and Bamboo).

These stacks all seem to work pretty well and the Atlassian Suite certainly works great for AppFuse and other open source projects. However, I recently had the pleasure of working at Chordiant Software where we used Chordiant Mesh to collaborate and develop software. Their Mesh system is powered by Jive Clearspace and provides a wealth of tools for each project, including a dashboard, discussions, documents, notifications and widgets providing status + links to JIRA and Bamboo.

Even though Clearspace's rich text editor caused me some early frustration, I really enjoyed the fact that a solid development infrastructure existed. It made it much easier to collaborate, document and execute our development process. I realize that it's difficult to build and maintain a custom development infrastructure stack. Chordiant had a whole team that developed, enhanced and supported their environment. But that doesn't mean it's impossible and not worth striving for.

I think there's a number of best-of-breed applications you can use to build a sweet development infrastructure stack.

• Source Control: Git
• Source Viewer: FishEye
• Wiki: Jive SBS
• Bug Tracker: JIRA
• Continuous Integration: Hudson

I've only used Git for a few weeks, but I can easily tell it's better than Subversion. I don't think it's easy to convince companies to switch their source control system, so it's probably not worth arguing if you're already using Subversion. I can also envision using Confluence instead of Jive SBS, but then you lose forum support and have to use something like Mailman or Google Groups. JIRA Studio looks close to my dream stack, except it doesn't support Git or a forum + mailing list system.

What is your preferred development infrastructure stack? Why?

The Passionate Programmer by Chad Fowler

Today I'm attending Developer Day in Boulder, Colorado. The opening keynote was done by Chad Fowler and below are my notes from his talk.

Chad recently wrote a book called The Passionate Programmer. It's about Creating a Remarkable Career in Software Development. Why is it important to do this? Because the average adult spends 53% of their time working, so it's really about creating a remarkable life. What is remarkable. For Chad, it was driving around the country in a 1986 Tioga motor home for two months. He worked the whole time and got to enjoy a lot of beautiful scenery along the way. He just returned from "working" in Hawaii for the last two weeks.

One of the things that motivated Chad to take control of his career was The Pragmatic Programmer book. It taught him you should always try work with people that are smarter than you. What we all really strive for is freedom, especially creative freedom. The whole idea of a remarkable career is it's different for everyone. Some folks want to get rich, some want to take a lot of vacation, some want to travel the world.

The process of developing a remarkable career is fairly easy - you just need two things. You have to have the intention and a system for getting it done. Most people do their careers by coincidence, but they don't drive it. In the music world, no one gets into it for the paycheck. Everybody gets into it because they think they're going to be the best. When Chad became a programmer, he thought the same thing - that he wanted to be a rock star.

When you have a plan, it makes hard things easy. A good example of a helpful planning technique is training for a running race. In September, Chad completed the Indian Summer Half Marathon and he used a training program that introduced mileage in a systematic way. Because of this, training never felt difficult. Another system that Chad recommends is the Seinfeld Calender, where you have a calendar that you X the days when you completed your training (or steps toward a goal). An interesting open source version of this is Calendar About Nothing.

One good way to look at your career is to think of yourself as a product. Choose your market, invest in yourself, execute and market your skills. You should hang out with people you want to be like and work with people you want to become. Chad recommends not only learning a new language every year, but also learning a new domain. You should decide if you want to be a generalist or a specialist. Being a specialist does not mean only knowing one thing, it just means you know one thing very well. If you do both, it's the best path towards awesomeness.

The thing that most programmers don't do enough of is practice. CodeKata is an example of how you can practice. Don't just practice programming, understand how your business operates. One of the best ways to do this is learn how to read a balance sheet. Don't be a Partial Person. Don't be someone who says I'm not a UI programmer. Learn how to do it. If you say "I've always wanted to", you should do it (unless it's illegal of course).

Execution is a mindset. The best person is not always the smartest person. People who struggle have to come up with systems to make them stronger. People who get things naturally (fitness, brains, etc.) tend to not keep perfecting their skill. Always think about how much you cost per hour and try to do something you can tell your boss everyday. Another way to execute impressively is to do an 8-hour burn (similar to the 40-hour work week)

The best way to market yourself is to be remarkable. When you do networking events, try to help people. We can all get stuck in the trap of saying I am an X programmer. This happens a lot when you're successful at X. Don't limit yourself by tying yourself to one technology. As a programmer, your job doesn't suck. If what you're doing is not fun, then you're probably doing the wrong thing. Ruthlessly cut out the crap you don't enjoy.

Comparing Web Frameworks Book

A publisher recently sent me an e-mail asking some advice. They received a proposal for a book that compares CakePHP, Symfony, Zend, TurboGears, Django, Struts, RoR. Here's a quote from the proposal:

We would like to compare a couple of frameworks and present their advantages and disadvantages in various applications.

Obviously, that kind of manual would be very useful for readers who are starting their 'adventures' with web applications, as it would facilitate their choosing the best framework for their particular application. The manuscript would offer a comparison of the most popular solutions (CakePHP, Symfony, Zend Framework, TurboGears, Django, Struts, Ruby on Rails) and demonstrate the main differences between each.

Therefore, the target audience would mainly be project managers, responsible for deciding on the technologies to be used for in-house projects, as well as less experienced, web application beginners.

Another purpose of the book would be to present 'good practices' in various frameworks, such as code re-factoring, design patterns and application security. From this point of view, it could become a valuable asset for experienced and learner programmers alike.

Since I got a lot of feedback from my tweet on this subject, I figured I'd ask it here.

What do you think of such a book?

Here's my response:

How do PHP books do these days? Of the list of frameworks (CakePHP, Symfony, Zend Framework, TurboGears, Django, Struts, Ruby on Rails), I think there's interest in Django and Rails, but not so much the others. And Struts sucks, so having that as a comparison is obviously going to make it look bad. I wouldn't buy it, but I'm a Java guy that's mostly interested in web frameworks that make developing SOFEA-based applications easier. In my mind, these are Flex and GWT.

The book I'd like to see would cover developing RESTful backends and SOFEA front-ends. RoR, Grails or Django could be used to develop the backend and Flex, GWT and X could be for the front-end. In reality, this is probably a tough book to write b/c things move so fast. If you decide to do it, I'd keep it short and sweet so you can get it to market and update it quickly.

How To Setup Your Own Software Development Company

This post was originally titled "FTE vs. Contract in this Economy", but it didn't seem to capture the essence of this entry. I wanted to write about why I think contracting is better in this down economy, but I also wanted to write about how you you might go about setting up your own company. Starting a company is relatively easy from a legal standpoint, and hopefully I can provide some resources that'll make it even easier.

First of all, I believe that contracting is better in this economy for a very simple reason:

When you're a contractor, you're prepared to be let go.

There's really nothing like being laid off. It sucks. It often shocks you and makes you depressed. The good part is you usually get a good afternoon's worth of drinking out of it, but that's about it. Severance is cool, but let's face it - you'd much rather be employed.

As a contractor, you're always looking for your next gig. You're prepared for the worst. You're more motivated to learn marketable skills. You're constantly thinking about how you can market yourself better. Writing (blogging, articles, books) is an excellent way to do this and I believe it's rare that FTE are as motivated to do these kinds of things.

Being a contractor forces you to better yourself so you're more marketable.

People's biggest fear of contracting is that they'll have a hard time finding their next gig. In my career, I've rarely had an issue with this. There's always contracts available, it's just a matter of how much you're going to get paid. Yes, I've had to suck-it-up and make $55/hour instead of $125/hour, but that was back in 2003 and $55/hour is still more than I would have made as a FTE.

The other thing that makes me believe contracting is better in this economy is I believe companies are hiring more short-term contractors than employees. I don't know if this is because they consider employees liabilities and contractors expenses, but something about it seems to make the books look better.

So you've decided to take my advice and try your hand at contracting. Should you setup your own Corporation or LLC?

Starting a Company
Yes, you should absolutely start your own company. As a Software Developer, chances are you're going to make enough to put you in the highest tax bracket. If you're a Sole Proprietor (no company), you will pay something like 35% of your income to taxes and you can be sued for everything you own by your clients.

Should you create an LLC or Corporation? I started Raible Designs in May 1998. I started out as an LLC and later converted to an S Corp. For the first few years, I made $30-$55/hour and this seemed to work pretty well. I believe this was similar to having a Sole Proprietorship (because I was the only employee), except that I was protected from lawsuits.

In 2001, I got my first high-paying gig at $90/hour and my Accountant suggested I change to an S Corp to save 10K+ on self-employment tax. I'm certainly not an expert on the different types of business entities, but this path seemed to work well for me. It was $50 to convert from an LLC to an S Corp. I'm not sure if you can go from an S Corp to an LLC. The beauty of an S Corp is the corporation typically gets taxed at 15%, so you can run a lot of things through your business and pay less taxes. Date nights can be business meetings, vacations can be Shareholders Meetings, seasons tickets can be client entertainment and you can write off your car and fuel costs.

There's lots of good resources on the web that describe the different business entity options. My favorite is A List Apart's This Web Business IV: Business Entity Options. Another good resource is How to form an LLC.

The hardest part of starting a new business is coming up with a good name. My advice is to make sure the domain name is available and pick something you like. I chose Raible Designs because I designed web sites at the time. Raible is a pretty unique name, so that's worked well having it as part of my business name. Googlability is important - don't choose a generic name that will make you difficult to find. Potential clients should be able to google your business name and find you easily.

Once you've picked a name, the business establishment part is pretty easy. In Colorado, you can File a Document with the Secretary of State. Their site also allows you to reserve a name if you're not quite ready to make the leap.

You'll also need to get a Federal Employer Identification Number (FEIN) from the IRS. The IRS has a good Starting a Business article and also allows you to Apply for an Employer Identification Number (EIN) Online.

Once you've got all the documents setup, you'll want to create a bank account for your business. I'm currently using Wells Fargo and really like how software-friendly they are. Their online banking is clean and easy to use. They also support QuickBooks for the Mac. They have Payroll Services to allow you to pay your quarterly taxes online as well as setup direct deposit, but I'm not using them.

For payroll, I use PayCycle and have nothing but good things to say about them (see update below). I have the Small Business Package at $42.99 per month. This package allows me to pay myself and employees + up to 5 sub-contractors with direct deposit. It also allows me to pay both Federal and State quarterly taxes online. Of course, if you can also get an Accountant to do this for you.

Having a good Accountant and Financial Advisor (for your retirement plan) will likely be an essential part of your business.. LinkedIn's Service Providers is a good way to find recommended professionals in your area. For example, click here to search for Accountants and then click the change location link in the top right corner to specify your zip code.

Finally, you'll need insurance. The Hartford has a good Small Business package that costs around $500/year. It's liability limits have worked for all of my clients and I'm covered if my laptop ever gets stolen. For Health Insurance, I recommend using eHealthInsurance.com to find a good provider for you. I don't get sick or hurt much, so I typically get a disaster prevention plan with a $5K deductible. For dental insurance, brush your teeth. Vision insurance typically sucks, so I wouldn't buy it. Yes, our health care system in the US needs work and I believe if everyone had a small business, it might get more affordable a lot quicker.

Over the next few days, I'll post some additional advice I've received on retirement plans, deducting a home office, drawing up contracts and how to come up with a good rate. If you're an Independent Software Developer and have any additional advice, I'd love to hear it.

Update: I take back what I said about PayCycle. After having a couple of insufficient funds when re-activating my account in January (they were pulling from the wrong account), they've changed my direct deposit lead-time to 5 days for the next 6 months. This means I forget to create checks on time since their reminder gets sent 2 days before. Time to try Wells Fargo.

Update October 2009: I never left PayCycle and I continue to use them to this day. I'm a satisfied customer, but do believe it still takes too long to make changes to your electronic services setup.

Ajax: The State of the Art with Dion and Ben

This morning, I added Dion and Ben's talk titled Ajax: The State of the Art. Below are my notes from the event.

Ajax started out as a bunch of hacks. It showed that we could take our web interfaces and do a lot more with them. A hack isn't necessarily a bad thing. Often, they turn into something much more elegant over time. The new browsers have many amazing capabilities that we haven't taken advantage of yet. We've seen discussions on Ajax go from how to do XHR to frameworks and how rich and mature they are. Dojo is great for Enterprise Development (packing system, namespaces). jQuery is well-suited for lightweight developers (PHP). Prototype is fantastic for people who do a lot of JavaScript development and take it very seriously.

Today's Ajax landscape is mature, really rich, and really exciting. Today, Dion and Ben are going to talk about technologies they're really excited about for the future.

Canvas
The building blocks of the web are text, boxes and images. With canvas, it really makes a lot more things possible. You can do bitmap rendering and image manipulation. They're showing a slide with Doom and Mario Kart running. Canvas 3D does true 3D rendering. Firefox and Opera have done prototypes of this. Can you do canvas-type things today in a browser? Yes, if you use Flash or Curl. Dion and Ben are excited about canvas over plugins for the following reasons:

• No start-up delay
• Available on mobile devices today
• Rendering fidelity with browser (especially important for typography)
• No bridges necessary (no marshalling/unmarshalling)
• Not a plug-in

The <canvas> tag originally came from Apple's Dashboard. Dashboard's programming model was in HTML and JavaScript. Dashboard is using WebKit under the covers. Today, canvas support exists in every major browser except for IE. The good news is there are Flash and Silverlight bridges to add support to IE. There's also an ActiveX component that wraps the Firefox implementation and allows it to run in IE.

SVG
Dion and Ben aren't that excited about SVG because it's such a huge spec. We've been struggling with the HTML standard for the last 10 years and the thought of another huge spec for the next 10 years isn't that appealing.

Fast JavaScript
Almost all major browsers have a Fast JavaScript implementation. Chrome has V8, Safari has SquirrelFish Extreme, Firefox has TraceMonkey and Opera has Carakan. This is exciting because of industry trends and how companies are trying to reduce computation cycles in data centers. The more computing that can be put on the client, the better. IE doesn't have anything, but Dion and Ben believe they are working on something.

Web Workers
Interface latency is awful for applications. Jakob Nielsen once said:

0.1 second is about the limit for having the user feel that the system is reacting instantaneously. 1.0 second is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay.

Anything that takes longer than a tenth of a second should be pushed to a background thread. Unfortunately, there are no threads in the web. Maybe we can add threads to JavaScript? Brendan Eich has said that "Threads suck" and there's very little chance for threads getting into JavaScript. Gears brought Worker Pools and this is going into HTML 5 as Web Workers. You could also use Java applets to do this. With the latest Java Plugin, many of applets' long-standing issues have been solved.

Desktop Integration
The ability to build desktop apps as web apps is very exciting. There's a few technologies that demonstrate this: Fluid, Mozilla Prism, Adobe AIR, Appcelerator Titanium and Gears. The Palm Pre demonstrates the logical extension of this. The Palm Pre uses the web stack as its developer SDK. It's very cool that web developers don't have to learn anything new to become a Palm developer. Desktop integration is exciting especially if we can access desktop applications like email and address book.

The Ajax frameworks that are out there have done a lot to make web development simpler. However, there's still a lot of pain with CSS and cross-browser issues. What if you took canvas and combined it with a sophisticated grid-based layout in JavaScript?

There's a lot of platforms out there: Microsoft Silverlight, Adobe Flash, Apple Cocoa and Sun's JavaFX. The web often isn't considered a platform. Dion and Ben believe there should be an Open Web Platform. The problem right now is there is no central location to find out how to get stuff done. You have to search and find resources from many different locations. Mozilla is putting it's resources into creating an Open Web Platform. This site will consist of 4 different areas:

• Home
• Documentation (for different frameworks, browsers, quirks)
• Dashboard (state of the open web)
• Roadmap (what's going on)

This is not just Mozilla, it's very much a community effort. This is something that Ben and Dion have been working on. But there's something else they've been working on too. They've been talking about all these cool things, but what about an interesting application to test all these technologies?

Bespin
As they looked at code editors, most of them provide awful user experiences. Bespin is the Editor of Your Dreams and contains the following features:

• Accessible from anywhere - any device in any location
• Simple to use, like Textmate (not heavyweight like Eclipse) - an editor, not an IDE
• Wicked Fast - performance, performance, performance
• Rock-solid real-time collaboration, like SubEthaEdit - it just works
• Integrated command-line, like vi - Fun like Quicksilver, social like Ubiquity
• "Self-hosted" environment, like Emacs - For extreme extensibility, but with JavaScript!

For viewing files, they couldn't bring themselves to use a tree. Instead, they developed a file-browsing interface that looks very much like Apple's Finder. Personally, I like Finder, but wish it had Windows Explorer's path bar that allows you to simply type in the path without mouse clicks. Back to the command line. They've done a lot to make things more discoverable so users can easily find the power of the editor.

Bespin could be used to engage developers more with open source projects. Checking out projects, modifying code and creating patches can be a real pain. Bespin could be used to interface with open source projects in the cloud. You could login, modify code and easily patch/build with the click of a button. One other thing they want to do is to have the server do code-analysis as you're developing.

Is it OK to love a software tool? You must love your software tools. What we do as Software Developers is one of the most difficult jobs on the planet. Programmers, like poets, start with a blank slate and create something from nothing. If you don't love your tools, you'll start resenting what you do. If you don't love your tools, it shows in your work. -- Dave Thomas at RubyConf08

Thunderhead
A GUI Toolkit written with canvas and JavaScript. Allows you to do layouts with very little thought. It's a lab experiment that's in progress, stay tuned for more information.

All users care about is the user interface. Dion and Ben believe there's a key to creating compelling user experiences. It all has to do with managing expectations. It's not that different from how you manage relationships in your life. Expectations for movies and games have changes drastically over the years. What used to be the web (animated gifs and awful web pages) has also changed drastically (video of Apple's online store). What was cool with MapQuest got changed drastically with Google Maps. What we have today isn't the end of the game - expectations will continue to change. However, users have different expectations for software.

Alan Cooper has done some interesting work in this area. The software designer needs to focus in on a user's goals. There are basic things you can apply to all users, for instance "sex sells". An example of this is Delicious Library. This application allows you to keep track of things in your home such as books, movies, music and games. They made $500K in 3 months and made $54K the first day, with no advertising.

The quality of any software is determined by the interaction. If the interaction isn't good, it will poison the entire experience. Donald Norman has a good quote: "Attractive things work better". In society, this is often called "Dress for Success".

The Open Web is hear to stay because it has:

• An Easy Programming Model
• Easy Remoting
• Extensive Customization Vectors (e.g. GreaseMonkey)
• Easy Deployment
• Great Widgets
• Great Visual Effects
• Great Mobile Story
• Desktop Integration
• State-of-the-Art Plug-ins

Bespin is a tech preview that they hope to release next week. Thunderhead will be released at the same time.

Conclusion
This was a great talk and easily the most inspiring of the conference. Dion and Ben always do a great job and the sexiness of their presentation made it all the more appealing.

2008 - A Year in Review

In 2005 and 2006, I did "A Year in Review" entries. 2007 was the year I got divorced, which probably motivated me to write a bit less. This year I'm back and ready to spend the next few hours writing, copying/pasting and linking like a madman. Hope you enjoy!

2008 was the year I traveled the world and developed a true passion for skiing. In January, my good friend Jason Miller moved back to Denver after quitting his job at Bear Stearns in NYC. We spent the first weekend in Nebraska working on Cletus's feedlot. The next week, my car stereo got stolen and I wondered if my bad knee would make it through the ski season (the good news is not only did I ski the rest of the season, but my knee healed itself over the summer).

At the end of January, the kids and I hiked to the top of Green Mountain and Don Brown made Maven not suck. Then I wondered if there was room for both Rails and Grails at a company and quickly learned both.

February started fantastically with a 14" Powder Day at Steamboat. I wondered if there is no "best" web framework and reviewed Grails and Rails books. After spending an awesome weekend in Tahoe, I took the kids on The Ski Train and learned more about Selenium at Google.

This brings us to one of my favorite posts of all time. On February 28th, Jack got a bead stuck in his nose. After taking him to the ER and paying $800, we found out magic recipe for bead removal is to "hold one nostril and give him a CPR-type breath/blow into his mouth". The reason I love the post so much is it's solved the problem for other frantic parents when they Google for "bead stuck in nose". Whenever I get a new comment, it always makes me smile.

March started out with a Powder Day at Whistler. I thoroughly enjoyed the rest of the weekend with good friends Jarvis and Korn Dog. After returning to Denver, I was allowed to blog about building a UI Frameworks Team at LinkedIn and posted my thoughts on Grails vs. Rails.

In mid-March, I achieved an all-Mac family and traveled to Lake Chelan for my sister's birthday. Shortly after, The AppFuse Primer was released. At the end of the month, I attended TSSJS in Vegas and moderated a Web Framework Smackdown.

In April, the LinkedIn Denver office opened and we all celebrated by attending the Rockie's Home Opener. The ski season came to an end and I wrote a howto for configuring Apache with mod_proxy and SSL on OS X. Then I discovered the JavaOne parties and wrote about running Spring MVC Web Applications in OSGi.

April ended with 82°F and May started with snow. I attended JavaOne (or at least the parties), released AppFuse 2.0.2 and figured out how to do extensionless URLs with the UrlRewriteFilter. The kids and I spent an afternoon in Rocky Mountain National Park and I did some coding in my backyard.

On Memorial Day, I enjoyed a liver-wrenching, Rockies-filled weekend with my sister her girlfriend Mya and Mr. Miller. I also contemplated making AppFuse Struts 2-specific.

June started with some mountain bike riding, planning some excellent vacations and getting a dream machine. I rode the annual trip to Big Head Todd at Red Rocks with Matt and Bruce. I took the kids on their first camping trip for Father's Day and had a blast. It took us several hours to find the campsite and my car kept starting all night long. It's sure to be a family tradition from now on.

The next weekend, I attended the American Craft Beer Fest in Boston. To end the month, I embarked upon Raible Road Trip #12 with Abbie, Jack and my Dad.

In July, the bus project began and I posted pictures of the trip to Montana. This year, I hope to spend the whole month of July at the cabin. I bought an iPhone (one of my best technology-related purchases to date). OSCON was fun but the week after wasn't.

August revealed my favorite birthday present. I didn't blog much the rest of the month, revealing why later.

Jack's Birthday Weekend was an outstandingly fun mixture of old friends and good Colorado beer. In September, I went to see the bus at MotorWorks, Abbie lost her first tooth and co-workers and I performance tested Memcached.

What followed was wonderful. Miller and I headed to Oktoberfest for the Best. Vacation. Ever. We still talk about how much fun we had on that vacation. October finished with the Colorado Software Summit and a hunting trip to the cabin.

November was a crazy month. I got laid off and celebrated Abbie's birthday on the same day. Jack got a mohawk and I traveled coast-to-coast in the same week. To close the month, I announced what's next and headed to Costa Rica.

I had a fantastic time in Costa Rica and was impressed to see Abbie is a blue skier shortly after. I did a Dojo/Comet Research Project for a week and enjoyed the location of my newest client last week. A small adventure turned into a scary adventure and I enjoyed telling my stories to fellow Java Enthusiasts in Portland.

Phew! It's been quite a year. For 2009, I'm still hoping for what I tweeted shortly after Costa Rica. I'd like to visit 3 foreign countries, take 3 months of vacation and spend 1 month in Montana. I have technology goals too, but those aren't nearly as much fun to dream about.

Happy New Year!

Oktoberfest: Best. Vacation. Ever.

As mentioned earlier, a good friend (Miller) and I took a vacation to Oktoberfest last week. The flight over was brutal: Denver -> Newark (4 hour layover) -> Paris (2 hour layover) -> Munich. I was pretty disappointed to see "No Service" on my iPhone when we landed in France. This continued in Munich and I quickly decided connectivity wasn't necessary. After a 80 € cab ride from the airport, we arrived at our hotel around 1PM on Monday. We both woke up at 4AM on Sunday to start the journey, so we were pretty beat.

It didn't take us long to decide we had to suck it up and head to "The Tents" at Oktoberfest. We walked the 4 blocks in the rain and quickly ended up in the Armbrustschutzenzelt tent. The crowd was small and we found a table and enjoyed our first Liter.

I won't go into details about how much fun we had during the week, except for these simple stats:

• Made it into The Tents 5 days in a row
• Mostly slept in until 2 or 4PM each day
• No Hangovers (for me at least)

I've uploaded most of the pictures I took to an Oktoberfest 2008 set on Flickr. I would like to thank Peter and friends for being fabulous hosts and showing us a great time on Thursday night. Below is a video I took of what the festivities were like (yes, that is Bon Jovi):

If you ever get a chance to attend Oktoberfest, I highly recommend it.