Raible Designs

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.

Increasing My Developer Happiness

I've bought into the idea that a happy developer requires a clean, attractive, comfortable workplace that encourages healthy, sustainable productivity. Rich Armstrong of Fog Creek Software explains how they spend $6,174 per developer to make them happy. Shortly after reading this article, I tweeted:

My ideal setup is ~$10K more (MacBook Pro, Mac Pro, two 30s).

While this is my ideal setup, it's not something I actually need. If you've ever worked with two 30" monitors, you might agree. That much screen real estate can be too much, as you have to pan your head side-to-side to take it all in. I've found that a single 30" or 27" is good enough for me. As far as a Mac Pro goes, they can have awesome horsepower when full-loaded, but unless you're doing some serious processing, you probably won't utilize it all.

The last time I bought a new computer was March 2009, when I bought a 15" MacBook Pro with an SSD. I upgraded it to 8 GB RAM a year later and it's hummed along just fine since then. I also had the pleasure of working on a fully-loaded Mac Pro at Time Warner Cable for all of 2010 and a company-provided MacBook Pro at Overstock for most of this year. With my recent move to a new client, it's time to increase my developer happiness. Since I am my own boss, it's easy to get hardware upgrades approved.

My current hardware inventory is as follows:

• A 15" MacBook Pro
• A 30" monitor at home
• A 27" monitor at my office in Downtown Littleton

Since I ride my bike to work everyday, I've been hauling my laptop back and forth on my 8-mile commute. This is getting old quickly. I'd rather have a permanent machine in my office and a laptop for when I travel to clients, the mountain office or to conferences. So here's what I hope to buy in the next week:

• A new 15" MacBook Pro, fastest CPU available
• A fully-loaded 27" iMac for my office

I'll be moving my current 27" monitor to the mountain office. I plan on getting rid of my current MacBook Pro through the Apple Recycling Program. I'm also planning on trying out Apple's 24-month leasing program. I like to get new hardware every two years and it's a better tax deduction, so it seems to make sense.

My only question at this point is should I get Apple's SSD and RAM instead of getting it aftermarket (e.g. via Crucial)? My original plan was to install an aftermarket SSD and 8 GB RAM in the MacBook Pro. For the iMac, I've heard installing an aftermarket SSD isn't an option, but RAM is. I was thinking about getting the SSD + 1 TB drive combo and upgrading the RAM to 8 GB myself. There's a good chance aftermarket is better quality, but I'd also have to pay more vs. having it wrapped up in the total lease price.

Of course, new hardware is only part of developer happiness. A clean, attractive, comfortable workplace is an essential component as well. My home and mountain offices are nice, but my Littleton office needs work. I currently share it with two other developers, Angela and Jim. Over the next couple months, we plan on making a lot of improvements to our daily digs. I'll make sure and take some before and after pictures and blog about how we improve things.

Update: Thanks to everyone for their advice. As I suspected, upgrading RAM and disk aftermarket is the way to go. When I wrote this, I was under the impression that you couldn't upgrade the iMac's disk. Since then, I've discovered OWC's Turnkey Upgrade Program. Using this, I can send them my iMac and get a wicked fast 480 GB SSD, a 2 TB drive, 16 GB of RAM and have it shipped overnight for around $1400. Add in 8 GB RAM and a 480 GB Mercury Extreme 6G SSD for my new MacBook Pro and I'm looking at $2600 (aftermarket) + $5500 (Apple) = $8100. Now I just need to find some external hard drive enclosures for my old drives. Bonus points if I can find one with Thunderbolt support.

I can feel my developer happiness increasing already...

Integrating HTML5 Boilerplate with Scalate and Play

HTML5 Boilerplate is a project that provides a number of basic files to help you build an HTML5 application. At its core, it's an HTML template that puts CSS at the top, JavaScript at the bottom, installs Chrome Frame for IE6 users and leverages Modernizr for legacy browser support. It also includes jQuery with the download. One of the major benefits of HTML5 Boilerplate is it ships with a build system (powered by Ant) that concatenates and minimizes CSS and JS for maximum performance. From html5boilerplate.com:

Boilerplate is not a framework, nor does it prescribe any philosophy of development, it's just got some tricks to get your project off the ground quickly and right-footed.

I like the idea of its build system to minify and gzip, but I'd probably only use it if I was working on a project that uses Ant. Since I'm using it in a Play project, the whole Ant build system doesn't help me. Besides, I prefer something like wro4j. Wro4j allows you to specify a group of files and then it compiles, minimizes and gzips them all on-the-fly. As far as I know, Play doesn't have any support for Servlet Filters, so using wro4j in Play is not trivial.

The good news is Play has a GreenScript module that contains much of the wro4j functionality. However, since I'm using Scalate in my project, this goodness is unavailable to me. In the future, the Scalate Team is considering adding better wro4j, JavaScript and CSS integration. In the meantime, I'm going to pretend I don't care about concatenation and minimization and trundle along without this feature.

To add HTML5 Boilerplate to my Play project, I performed the following steps:

• Downloaded the 2.0 Zipball.
• Copied all the static files to my project. Below are the commands I used (where $boilerplate-download is the expanded download directory and ~/dev/play-more is my project):

  cd $boilerplate-download
  cp 404.html ~/dev/play-more/app/views/errors/404.html
  cp *.png ~/dev/play-more/public/.
  cp crossdomain.xml ~/dev/play-more/public/.
  cp -r css ~/dev/play-more/public/stylesheets/.
  cp favicon.ico ~/dev/play-more/public/.
  cp humans.txt ~/dev/play-more/public/.
  cp -r js/libs ~/dev/play-more/public/javascripts/.
  cp robots.txt ~/dev/play-more/public/.
  

• Copied the index.html to ~/dev/play-more/app/templates/layouts/default.jade and modified it to use Jade syntax. Since I downloaded the comments-heavy version, I modified many of them to be hidden in the final output.

  -@ val body: String 
  -@ var title: String = "Play More"
  -@ var header: String = ""
  -@ var footer: String = ""
  !!! 5
  / paulirish.com/2008/conditional-stylesheets-vs-css-hacks-answer-neither/ 
  <!--[if lt IE 7]> <html class="no-js ie6 oldie" lang="en"> <![endif]-->
  <!--[if IE 7]>    <html class="no-js ie7 oldie" lang="en"> <![endif]-->
  <!--[if IE 8]>    <html class="no-js ie8 oldie" lang="en"> <![endif]-->
  -# Consider adding an manifest.appcache: h5bp.com/d/Offline 
  <!--[if gt IE 8]><!--> <html class="no-js" lang="en"> <!--<![endif]-->
  head
    meta(charset="utf-8")
  
    -# Use the .htaccess and remove these lines to avoid edge case issues. More info: h5bp.com/b/378 
    meta(http-equiv="X-UA-Compatible" content="IE=edge,chrome=1")
  
    title=title
    meta(name="description" content="")
    meta(name="author" content="Matt Raible ~ [email protected]")
  
    -# Mobile viewport optimized: j.mp/bplateviewport 
    meta(name="viewport" content="width=device-width,initial-scale=1")
  
    -# Place favicon.ico and apple-touch-icon.png in the root directory: mathiasbynens.be/notes/touch-icons
  
    -# CSS: implied media=all
    link(rel="stylesheet" href={uri("/public/stylesheets/style.css")})
    -# end CSS
  
    -# More ideas for your <head> here: h5bp.com/d/head-Tips 
    -#
      All JavaScript at the bottom, except for Modernizr / Respond.
      Modernizr enables HTML5 elements & feature detects; Respond is a polyfill for min/max-width CSS3 Media Queries
      For optimal performance, use a custom Modernizr build: www.modernizr.com/download/ 
  
    script(type="text/javascript" src={uri("/public/javascripts/libs/modernizr-2.0.6.min.js")})
  body
    #container
      header = header
      #main(role="main")
        != body
      footer = footer
  
    -# JavaScript at the bottom for fast page loading 
    
    / Grab Google CDN's jQuery, with a protocol relative URL; fall back to local if offline 
    script(type="text/javascript" src="//ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js")
    :javascript
      window.jQuery || document.write('<script src={uri("/public/javascripts/libs/jquery-1.6.2.min.js")}><\/script>')
  
    -# Change UA-XXXXX-X to be your site's ID 
    :javascript
      window._gaq = [['_setAccount','UA-25859875-1'],['_trackPageview'],['_trackPageLoadTime']];
      Modernizr.load({
        load: ('https:' == location.protocol ? '//ssl' : '//www') + '.google-analytics.com/ga.js'
      });
  
    -# Prompt IE 6 users to install Chrome Frame. Remove this if you want to support IE 6. 
    -# http://chromium.org/developers/how-tos/chrome-frame-getting-started 
    /[if lt IE 7]
      script(src="//ajax.googleapis.com/ajax/libs/chrome-frame/1.0.3/CFInstall.min.js")
      :javascript
        window.attachEvent('onload',function(){CFInstall.check({mode:'overlay'})})
          
  != "</html>"
  

• Next, I had to add support for layouts to my homegrown Scalate support. I did this by specifying a layoutStrategy when initializing the TemplateEngine. From play-more/app/controllers/ScalateTemplate.scala:

  engine.classLoader = Play.classloader
  engine.layoutStrategy = new DefaultLayoutStrategy(engine, 
    Play.getFile("/app/templates/layouts/default" + scalateType).getAbsolutePath)
  engine
  

That's it! Now I have HTML5 Boilerplate integrated into my Play/Scalate/Jade application. To set the title and header in my index.jade, I simply added the following lines at the top:

- attributes("title") = "Counting"
- attributes("header") = "HTML5 Rocks!"

CoffeeScript Tip
Yesterday, I mentioned that I was having issues getting CoffeeScript to work with Scalate and that I was going to try and get the in-browser compiler working. First of all, reverting to Scalate 1.4.1 didn't work because there is no CoffeeScript support in 1.4.1. So I stayed with 1.5.2 and used PandaWood's Running CoffeeScript In-Browser Tutorial. I copied coffee-script.js to ~/dev/play-more/public/javascripts/libs and added a reference to it in my default.jade layout:

-# JavaScript at the bottom for fast page loading 
script(type="text/javascript" src={uri("/public/javascripts/libs/coffee-script.js")})

Then I was able to write CoffeeScript in a .jade template using the following syntax:

:plain
  <script type="text/coffeescript">
    alert "hello world"
  </script>

Summary
If you've integrated HTML5 Boilerplate into your Play application, I'd love to hear about it. Now that I have all the infrastructure in place (Jade, CoffeeScript, HTML5 Boilerplate), I'm looking forward to getting some development done. Who knows, maybe I'll even come up with my own Play Un-Features That Really Irk My Inner Geek.

Trying to make CoffeeScript work with Scalate and Play

A few weeks ago, I wrote about integrating Scalate with Play.

The next steps in my Play Scala adventure will be trying to get the CoffeeScript module to work. I also hope to integrate HTML5 Boilerplate with Jade and Scalate Layouts.

Since my last writing, the Scalate Team has created a new branch for Scala 2.8.x (that's compatible with Play) and released 1.5.2. To upgrade my Play application to use this version, I changed my dependencies.yml to have the following:

  - org.fusesource.scalate -> scalate-core 1.5.2-scala_2.8.1:
      transitive: false
  - org.fusesource.scalate -> scalate-util 1.5.2-scala_2.8.1:
      transitive: false

Unfortunately, this release breaks Scalate's CoffeeScript support because it wraps the code with illegal comments. This has been fixed in the latest snapshot, but no new release has been cut. However, even if it did work, it's not quite what I'm looking for. The 1.5.2 release allows for compiling inline CoffeeScript on-the-fly, but I'd rather store my .coffee files external to the page.

To try and figure out how to do this, I sent a message to the Scalate Google Group asking Does Scalate allow for referencing (and compiling) CoffeeScript files like the plugin for Play? My email prompted the Scalate Team to do some modifications that seemed to do exactly what I was looking for.

cd samples/scalate-example 
mvn jetty:run

To try out the improved CoffeeScript support, I checked out the source and fumbled with Git branches for a bit before I got latest version of Scalate to build. Unfortunately, it didn't work because Play doesn't know how to process the .js and .css files.

@67o8fflce 
Application.foo.js action not found 
Action not found 
Action Application.foo.js could not be found. Error raised is 
Controller controllers.Application.foo not found 
play.exceptions.ActionNotFoundException: Action Application.foo.js not 
found 
        at play.mvc.ActionInvoker.getActionMethod(ActionInvoker.java: 
588) 
        at play.mvc.ActionInvoker.resolve(ActionInvoker.java:85) 
        at Invocation.HTTP Request(Play!) 
Caused by: java.lang.Exception: Controller controllers.Application.foo 
not found 
        ... 3 more 
08:20:21,133 ERROR ~

Based on this error, I assumed I needed a Controller to do receive the .js and .css requests and compile them accordingly with Scalate. I changed my Jade template to have the following:

script(src="/assets/foo.js" type="text/javascript") 

Then I added a new route to my Play application:

  GET     /                           Application.index
  GET     /assets/{template}          ScalateResource.process

My ScalateResource.scala class is as follows:

package controllers 

import play.mvc._ 

object ScalateResource extends Controller { 

  def process(args: (Symbol, Any)*) = { 
    var template = params.get("template") 
    // replace .js with .coffee 
    template = template.replace(".js", ".coffee") 
    // replace .css with .scss 
    template = template.replace(".css", ".scss") 
    ScalateTemplate(template).render(); 
  } 
} 

Unfortunately, when I tried to access http://localhost:9000/assets/foo.js, I received the following error:

TemplateException occured : Not a template file extension (md | markdown | ssp | scaml | mustache | jade), you requested: coffee

At this point, I still haven't figured out how to solve this. I can only assume that the reason this works in the example application is because it uses a TemplateEngineFilter that's mapped to /*.

As I see it, I have a few choices if I want to continue using CoffeeScript and Scalate in my application:

1. Revert to an older build of Scalate that uses the in-browser CoffeeScript compiler.
2. Try to get a new version released that fixes the comment bug and use inline CoffeeScript.
3. Keep trying to figure out how to get external files compiled by Scalate.

Obviously, I'd like to do #3 the most, but with the lack of responses from the Scalate group, this seems like the most challenging. Since #1 is the easiest (and I can complete without anyone's help), I'll be going that route for now. With any luck, the 2nd and third solutions will surface as options before my talk in November.

Update Oct 4, 2011: I was able to get external CoffeeScript files working! It was rather simple actually. I just tried the Play CoffeeScript module again, using Scalate's {uri("/path")} helper. For example, in a Jade template:

script(type="text/javascript" src={uri("/public/javascripts/script.coffee")})

This compiles the CoffeeScript file on the server and returns JavaScript. Sweet!

Mahalo Kauai

I've heard great things about Hawaii for most of my life. My Dad was stationed at Barbers Point when he was in the Navy. His sister, my Aunt Mary, was born there. My sister and I sent my parents to Hawaii for their 30th Wedding Anniversary. You can imagine my excitement when Trish sent me an email on January 25th:

It's only 40,000 miles for both of us to fly to Kauai!! I picked the week after Labor Day just for fun :)

My response:

WAHOOOOOO! BOOK IT!!

She booked it that night. For $10.

We left for Kuaui the morning after the disappointing Broncos home opener and a fun sports weekend with Abbie and Jack. Our trip started out great, sneaking into the Red Carpet Club for free at LAX and getting a slew of free drinks from a super-cool flight attendant (Anthony) on our flight from LAX to Kauai.

After landing and marveling at the open-air airport, we picked up our rental Jeep and drove to the north side of the island. A friend recommended we stay at the St. Regis Princeville Resort and we were very impressed when we checked into our room overlooking Hanalei Bay.

The next morning, we vowed to do nothing but relax by the pool. We enjoyed a scrumptious breakfast at the Mekana Terrace, complete with Bloody Mary's. We had to have Bloody's since the St. Regis in NYC claims to have invented them. We spent the rest of the day napping, swimming, sunbathing, snorkeling and sipping on Mai Tai's.

After enjoying a beautiful sunset ...

... we visited the concierge to book some activities for the rest of our trip. We wanted to take things up a notch and enjoy all the cool stuff Kuai had to offer. So we arranged for Stand Up Paddling and the Mailani Dinner Shown on Thursday, golf on Friday, a doorless helicopter ride on Saturday and a kayak trip along the Na Pali coast on Sunday.

We woke up Thursday refreshed and ready to go. Our view out the window was exceptional.

After a delicious room service breakfast in our room, we wandered down to the beach to meet our SUP guide. He warned us that girls were generally better than guys at SUP and we proceeded to prove him correct. Trish never got her hair wet and I had to abandon ship several times.

That afternoon, we headed to the The Kalalau Trail for a hike. Our SUP guide recommended it and said it was "so easy, your grandma could do it". His Grandma must be a lot younger than most, because the trail was not easy, but we certainly enjoyed the challenge.

We were rewarded with some spectular views at Kalalau Beach.

We made it back to the hotel just in time for the dinner show and another marvelous Hanalei sunset.

At the dinner show, we sat with honeymooners from Houston that worked at NASA. Since they both spoke Russian, we had fun discussing Russia, our trips there and how we learned the language. The dinner show was great and they featured quite a few of the top Hula dancers in Hawaii.

The next morning, we grabbed Huevos Rancheros in Princeville and headed to the Makai Golf Club for a one-of-a-kind experience. Not only did they let us bring our full-stocked cooler on the course, but they rented us some fantastic Callaway clubs. We golfed for hours with no one in front, and no one trailing behind.

Trish's photo of the Bougainvillia on the back nine is one of my favorites.

We enjoyed some Blue Hawaii's at the St. Regis afterward, in a cabana that's normally reserved for $1000/day. We snuck in and even got the honeymooner's discount from a hometown waiter.

On Saturday, I booked a tour at the Ahonui Botanical Gardens. The gardens where amazing, built by Bill and Lucinda Robertson. They converted a jungle of 8 acres into an elaborate garden with trees, flowers and plants from around the world. Since you can grow almost anything on The Garden Isle, they planted many exotic fruit trees that we had the pleasure of snacking on throughout our 3-hour tour. About halfway through, Lucinda treated us to an adventure in making and tasting delicious chocolates.

We rushed from the garden tour to the helicopter ride on the other side of the island. The concierge had booked us with Jack Harter Helicopters, because they were the only ones that flew without doors (for better pictures). As soon as we lifted off, I knew it was going to be an experience of a lifetime. We flew over the Waimea Canyon, along the Na Pali Coast, over Hanalei Bay and back into the mountains to the wettest place on earth. It felt like an amusement park ride combined with an IMAX movie. Our pilot was a Hawaii native that knew the whole island and gave us an excellent tour of its features. I cannot recommend this tour enough if you're ever in Kauai.

The next morning, we had to get up early for our kayak trip. We had a wakeup call at 4:30, breakfast via room service arrived at 5 and we were packed and checked out of the hotel at 5:30. We arrived at Na Pali Kayak at 6 and quickly realized we had our work cut out for us. Both Trish and I expected the kayak trip to be like paddling across a lake and didn't know we were in for the Everest of kayaking - a 17-mile journey that would take most of the day.

We borrowed some sea-sickness medication, bought some water from our hosts and got ready for a good challenge. Unfortunately, we couldn't take Trish's camera, and the waterproof camera she bought took mediocre pictures. However, we did get to see two schools of dolphins (one even jumped into the air for us) and a couple turtles along the way. Having to paddle in unison turned out to be great couples therapy too.

We enjoyed lunch on a beach along the coast around 1, took a nap and hopped back in the boats for the last 5 miles. We pulled out around 4 and were on the road by 5 for the 2.5 hour drive back to Hanalei Bay. It was country dark when we arrived. We hopped in the Jeep and drove an hour back across the island to stay at the Sheraton Kauai (the St. Regis was full) for our last night.

At the Sheraton, we had one of their best rooms and enjoyed awesome views and a final relaxing day before heading home.

The Tunnel of Trees on the way to the airport was one last reminder of how beautiful Kauai is.

Mahalo Kauai. You are one of the most breathtaking places I have ever been too. Your views, your waves, your rainbows - all spectacular. Trish and I will be back, you've made an impression on us that will last forever.

If you'd like to see many of the places we visited in a movie, check out Soul Surfer. It takes place in Hanalei Bay and we recognized many of the locations while watching it. For more pictures, see my Shareholders Meeting in Kauai or Trish's magnificent photos.

Oregon, Cape Cod and Fun in Winter Park

I'm proud to say it's been almost a month since my last blog entry. This can only mean one thing → I've been having too much fun to blog. The good news is I finally found time to write about our recent adventures, so grab yourself a tasty beverage and read on.

Within hours of my last blog post, Trish and I hopped on a plane to visit my good friends, Clint and Autumn, in Oregon. We flew into Portland and spent the weekend hiking in Silver Falls and drinking good beer at the Oregon Brewers Festival and Edgefield. Edgefield is one my favorite places on Earth, encapsulating a farm/resort environment with 27 different features. The features range from a soaking pool to a winery to a pool hall to scotch tasting in a shack next to a garden.

The weekend was especially fun since Autumn was pregnant and it was two weeks before the due date of their first child. Broderick Jordan Wilburn Foster was born yesterday and I hear the whole family is doing well.

Trish and I spent the night at Edgefield on Saturday and caught an early flight from Portland to Boston the next morning. Her brother (also named Matt) lives near Boston and we drove our rental Volvo convertible (to fit in with the New Englanders) to his house Sunday night. On the Hertz Bus from the airport met Nigel Parry, a professional photographer. Not just anybody, but someone that's shot pictures of some very famous people. Trish is also a photographer, so they had a long conversation and it inspired her to resign from her sales job last week. Actually, it wasn't that meeting, she's been wanting to be a famous photographer since she was in high school. Now that dream shall happen. She's awesome.

On Monday afternoon, we picked up Abbie and Jack from the Boston airport. They flew up from West Palm Beach on their first unaccompanied minors flight. We drove them to Cape Cod and settled into Trish's parents house near the water. The rest of the week, we had a blast with our friends Chris and Julie and the entire McGinity clan. We boated, grilled, flew down the water slides, played miniature golf and toured Martha's Vineyard. We had a pool party, played some pool and sang our hearts out at karaoke. Trish's brother's kids are the same age as mine, so you couldn't wipe the smiles off our kids' faces, especially when we had the tunes cranked with the top down on the convertible.

For more pictures of this super-fun trip, see Summer Fun in Oregon and Cape Cod part 1 and 2.

After returning from Boston, we had a week without kids and lived it to the fullest with a John Butler Trio concert at Red Rocks and the Winter Park Beer Festival. Trish's friend Joanna and my good friend, "The Professor" joined us for a weekend of mountain biking and sweet mountain views. We even got to hang out with James Ward and his wife Jenny at the beer festival. Sunday, we hiked up the beautiful Columbine Lake Trail. Trish's dog, Sagan (named after Carl) chased sticks and was his crazy self as usual.

We drove back Monday morning to be there for the kids first day of school. They sure start early these days don't they?

I rode my bike 168 miles to and from work throughout the following week. The next weekend, we took the kids up to the Ski Shack for their first time. I hired a guy to make queen-size bunk beds for them, so they had a blast in their new roomy beds. On Saturday, we had a garage sale since the previous owners left a bunch of beds and couches and we didn't need all that furniture. The turnout was great and we got to hang out with Jodi and James, Suzie, and The Lamonts. All of these folks are old friends that just happened to be in the mountains for the weekend. One of Trish's best friends, Chris, has a place less than a mile from us and we had a blast with her on Saturday night. Thanks for the fun memories Chris!

On Sunday, we took the kids the Winter Park Base Area where they have Disneyland in the Mountains as I like to call it. An alpine slide, miniature golf, a maze, a climbing wall and a Chili Cook-Off to keep Daddy happy. We met our good friend Suzie there and had a lot of fun with Chris, Brice and their crazy kids. Enjoying an Avery White Rascal at the Cheeky Monk's happy hour was the perfect way to end the day.

Sunday night, we were graced with the presence of a beautiful sunset.

That pretty much catches you up-to-date with the goings on in my life. As you can tell, it's been a great summer so far. I'm really looking forward to the fall too. Broncos season, a trip to Hawaii, learning new technologies, talking about them at Devoxx and a new gig.

I've decided to leave Overstock because I'm a die-hard Broncos fan and I can't work for a company that supports the Raiders during football season. There's a good chance I'll be back after the season, just in time for The Greatest Snow on Earth.

This weekend, my parents are meeting us in Winter Park for Labor Day weekend. We plan on fishing, hiking, smiling and enjoying each other's company a whole lot. Tomorrow is Jack's birthday. I gotta run ... it's time to go buy a bike, play a little golf, hit the pool and go to the BBQ before tonight's CD Release Party.

How do you get started in programming?

I recently received the email below from someone asking how he might get started in programming. I think this is a popular topic, especially given the current economic situation in the US (unemployment is high, but not in the tech industry). For that reason, I figured I'd post my response here and allow others to chime in with their advice.

I read about you on LinkedIn, forgive my intrusion. Since you seem like an expert in the field of designing websites I wanted to know your thoughts on switching into this field late in life. I am 41 and looking to make the move from an unrelated field (finance) to programming. So far I have learned HTML, CSS and some Javascript. I have taken classes on C and Java. I have made some basic Android phone apps.

What languages do you think I should focus on? What is the fastest way to get up to speed to make a career of it? Classes? Take a entry level job? Study on my own?

Thanks for any insights….

My reply:

It's interesting that you're switching from finance to programming. I did the same thing early on in my career, but I was fortunate enough to do it in college (I have degrees in Russian, International Business and Finance) and therefore able to audit some CS classes before I graduated.

I think the most valuable skills these days are front-end skills (HTML, CSS and JavaScript). If you can combine those skills with the ability to design websites, you'll go along way. I've taken a different approach where I have excellent front-end skills, but also know a lot about the backend.

While it helps to have a Java background these days, the real sweat spot is the JVM and the containers that run on it like Tomcat and Jetty. A lot of Java developers are learning Groovy and Scala, but unfortunately a lot of their documentation/books are targeted towards Java developers.

The fastest way to get up-to-speed on it is to start your own project (if you can't get a company to hire you to do it). I'd suggest creating a webapp that solves a problem that you have, makes your life easier, etc. If you open source it and build a community around it, that's just as good as working for a company as far as experience goes. Combine this with studying on your own and you can likely come up to speed very quickly.

As a programmer, what advice do you have for someone looking to switch careers, or get into our industry fresh out of college?

Installing OpenJDK 7 on OS X

Last week, I scanned an article and saw there was a Java 7 Webinar. At first, I thought Java 7 was released, but soon after realized it was a Developer Preview. Unfortunately, the download page doesn't have support for OS X. Since it took me a bit of work to figure out how to install OpenJDK 7 on OS X (I'm running Snow Leopard 10.6.7), I figured I'd write down how I did it.

I started off by downloading "OpenJDK 1.7 universal (32/64 bits) from Mac OS/X branch" from the openjdk-osx-build project's downloads (direct link). After downloading, I installed the dmg as normal.

function setjdk() { if [ $# -ne 0 ];then export JAVA_HOME=`/usr/libexec/java_home -v $@`; fi; java -version; }

I don't use Java Preferences to set my JDK, instead I use David Blevin's handy setjdk script. To make this script work with JDK 7 on OS X, I had to make one minor change. On line 40, I added "Contents" to the path for JAVA_HOME:

export JAVA_HOME=$vmdir/$ver/Contents/Home

Update Jan 27, 2012: You no longer need to make this change.

From there, I had to setup some symlinks so everything would work as expected:

cd /System/Library/Java/JavaVirtualMachines/
sudo ln -s /Library/Java/JavaVirtualMachines/1.7.0.jdk

sudo ln -s /Library/Java/JavaVirtualMachines/1.7.0u.jdk 1.7.0.jdk

Lastly, I had my JAVA_HOME set to "/System/Library/Frameworks/JavaVM.framework/Home". I like the shorter (and seemingly more common) "/Library/Java/Home", so I set it back to that in my ~/.profile:

export JAVA_HOME=/Library/Java/Home

On my system, /Library/Java/Home had a symlink to /System/Library/Frameworks/JavaVM.framework/Home, so I changed it to the CurrentJDK that Java Preferences and setjdk use.

cd /Library/Java
rm Home
ln -s /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Contents/Home

Then I had to add a symlink for 1.7 in the Versions directory.

cd /System/Library/Frameworks/JavaVM.framework/Versions
sudo ln -s /System/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents 1.7

After making these changes, I was able to switch to JDK 7 easily.

$ setjdk 1.7
Setting this terminal's JDK to 1.7 ... openjdk version "1.7.0-internal"
OpenJDK Runtime Environment (build 1.7.0-internal-b00)
OpenJDK 64-Bit Server VM (build 21.0-b17, mixed mode)

I was also able to switch back to JDK 6.

$ setjdk 1.6
Setting this terminal's JDK to 1.6 ... java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-384, mixed mode)

Maven Issues
Next, I tried using JDK 7 to build AppFuse. I ran into two issues when I tried to do this. The first was caused by the native2ascii plugin, which has been known to cause issues on non-Mac platforms. Adding the following profile seemed to solve the problem.

<profile>
    <activation>
        <jdk>1.7</jdk>
    </activation>
    <build>
        <plugins>
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>native2ascii-maven-plugin</artifactId>
                <dependencies>
                    <dependency>
                      <groupId>com.sun</groupId>
                      <artifactId>tools</artifactId>
                      <version>1.7.0</version>
                      <scope>system</scope>
                      <systemPath>${java.home}/../lib/tools.jar</systemPath>
                    </dependency>
                </dependencies>
            </plugin>
        </plugins>
    </build>
</profile>

The next issue was with Enunciate and its maven-enunciate-cxf-plugin.

[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] com/sun/mirror/apt/AnnotationProcessorFactory
com.sun.mirror.apt.AnnotationProcessorFactory
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.NoClassDefFoundError: com/sun/mirror/apt/AnnotationProcessorFactory

It seemed like adding a profile that included tools.jar would solve this, but it doesn't. When I add the dependency directly to the plugin itself, I get the following error:

warning: The apt tool and its associated API are planned to be
removed in the next major JDK release.  These features have been
superseded by javac and the standardized annotation processing API,
javax.annotation.processing and javax.lang.model.  Users are
recommended to migrate to the annotation processing features of
javac; see the javac man page for more information.
[WARNING] Validation result has errors.
error: [core] java.lang.StackTraceElement: A TypeDefinition must have a public no-arg constructor or be annotated with a factory method.
1 error
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------

Hopefully this article helps you get started with Java 7 on OS X. If you have any additional tips, please leave a comment.

My Java Web Application Security Presentation from Jazoon 2011

Yesterday I delivered my Java Web Application Security talk at Jazoon. The presentation I gave was similar to the one I delivered at Utah JUG, but contains a few more slides about penetration testing and securing REST APIs. I also opted not to embed the screencasts in the presentation on SlideShare since you can click on the links to view them. Lastly, I included a great quote from Erlend Oftedal, who left a great comment on my last post.

"Security is a quality, and as all other quality, it is important that we build it into our apps while we are developing them, not patching it on afterwards like many people do."

If you'd like to download a PDF of this presentation, you can do it from Slideshare or from my presentations page.

Like most conferences in the last year, I brought the lovely Trish McGinity with me. As of today, it's been one year since I saw her switch from a Martini to a Guinness and thought "I need to talk to that girl!" It's been a heckuva a ride ever since and I'm sure the future will be just as much fun. To celebrate, we're going to explore Rhine Falls and have dinner at Greulich. Happy Anniversary Trish!

Hyperproductive JSF 2.0 with Ed Burns at Jazoon

This morning, I attended Ed Burn's Talk on Hyperproductive JSF 2.0 at Jazoon. As you might know, I've been a critic of JSF for many years. However, it is one of the most used Java web frameworks, so I was hoping to learn how it's improved in the latest version. Below are my notes from Ed's presentation.

Ed's Plan for our Time Investment:

1. Define a productive development environment
2. JSF for greenfield and brownfield projects
3. List the top 9 productivity killers with JSF projects and solutions

"I am always doing that which I cannot do, in order that I may learn how to do it." -- Pablo Picasso

Software is an executable representation of knowledge, a byproduct of learning how to solve a problem. Knowledge is something that changes as more information comes in. A productive environment makes it as easy as possible to learn how to solve a problem. Learning is an iterative process. Early iterations don't need to be optimal. Later iterations do ... and they need to be maintainable. First is the hardest. Fast iterations are they key. Spring Roo and Play are examples of frameworks that make the first iteration very fast.

You should use a tool to jumpstart JSF development: copy from an old project, use a Maven archetype or use your IDE. With greenfield development, you don't have to bother learning the byproduct of other people's learning. It's a great opportunity to pad your resume with the latest hot technologies. With brownfield development, it's vitally important to understand the existing solution and hidden assumptions. You're also much more constrained in your technology choices. If you want to change, you'll need to come up with a migration strategy, which can be difficult. JSF works well for both because it's not just a runtime framework, it's also a conceptual framework. You need to understand how your framework handles data conversion, validation, page flow, persistence integration, I18N, L10N, A11Y, Web standards and user friendliness.

Top 9 JSF Productivity Killers:

1. Time wasting deployment step
2. The perils of "there's more than one way to do it"
3. Lengthy and painful developer on-boarding process
4. Misused logging and misunderstood error messages
5. Phantoms
6. Under-utilized developer tools
7. Premature optimization
8. Difficulty in doing TDD
9. Lack of an app framework

Time wasting deployment step
ZeroTurnaround solves this problem with JRebel, but there's other ways to do it. Some of the killers of flow state: 1) one large war file, 2) underutilizing dynamic language features, 3) complex server environment and 4) build process is redoing work unnecessarily. To stop the time wasting deployment step, the most important things you can do are as follows:

• Configure your IDE correctly. In Eclipse, compile directly into WEB-INF/classes and use continuous compilation. With NetBeans, use GlassFish.
• Don't do control-flow programming in XML.

Ed then showed a simple demo that showed how you can use Groovy to create a JSF UI Component. He also mentioned that Groovy can be used to author any JSF artifact. The benefit of this is you can simply edit and save a .groovy file without having to recompile or redeploy. Unfortunately, using Groovy didn't eliminate the XML syntax for pages or the XML for defining UI components.

The perils of "there's more than one way to do it"
JSF is very flexible, but flexibility is, more often than not, abused. There's a lack of convention for common things (e.g. master-detail, JSF concepts like converter, validator, etc.). The best way to fix this is to establish the norms for a project and stick with them. For example, Neil Griffin has a good blog entry for the different kind of managed beans you can create. Develop recommendations like Neil's and use them on all your projects.

Lengthy developer on-boarding process
Stick with standards when possible (at least have a common project description and build system across projects). Be committed to periodic cleanup cycles, including documenting for re-use. Pick one JSF component library and stick with it. Support for mixing and switching component libraries has improved with JSF 2, but it's still recommended you use only one.

Misused logging and misunderstood error messages
JSF is notorious for cryptic error messages and very long stack traces. It's still a problem, but the JSF Team is still working on improving them. Good tip: use the <ui:debug> tag. Its recordStateSize="true" attribute can be especially useful. If you're using PrimeFaces, add trace=true to request URLs.

Phantoms
Phantoms is when running code is not the same as the code you are modifying or wrong version of library gets picked up. You should have the capability to hit breakpoints anywhere in your entire software stack, including core Java sources. This is one of the most useful things about open source software. Solutions to phantoms: 1) put a timestamp on every redeploy and have the timestamp appear in the system log 2) write the running library stack to the system log (each library and version being used) and make it easy to compare one developer's runtime stack with another's 3) consider doing all work in tightly controlled VMs (checkout the VM at the beginning of the day, do your work, commit your changes and throw your VM away at the end of the day).

Under-utilizing developer tools
Make sure everyone has the fastest machines available and as much screen real estate as desired. Hardware is much cheaper than developer time. Another tip is to use Hudson as your butler. It's not just the team CI server. In other words, take advantage of automation wherever you can.

Premature Optimization
Keep in mind the trade-offs between readability and performance. When using frameworks such as JSF, don't try to outsmart the implementation. Rather, use the framework as intended and use open-source contributions to treat performance problems. Example, EL expressions got a lot faster between EE5 and EE6. If you spent time trying to optimize EL expressions, you might've been wasting your time.

Difficulty in doing TDD
Try to figure out why TDD is difficult in your company. For JSF, strongly consider JBoss's JSFUnit. Write your testcases to extend from Cactus ServletTestCase and leverage HtmlUnit (JSFUnit does this for you).

Lack of an app framework
Create common components: login panel, CRUD components, etc. If you don't have an app framework, build one over time.

Conclusion
This was an interesting talk by Ed. The dynamics of the room where a bit interesting. Jazoon is held in a movie theater, much like Devoxx. However, it appears there's a spotlight on the speaker that makes it very difficult to see the audience. I don't remember having this problem at Devoxx. Ed asked the audience quite a few questions, but it seemed he had a lot of difficulty in seeing if folks raised their hands. This made for some periods of awkward silence.

Personally, I was hoping to learn some new whizbang tips about JSF that I was not aware of. Unfortunately, I didn't learn anything new and wasn't that impressed with the Groovy demo.

I think Ed's tips about things outside of JSF were good, especially buying developers good hardware. I've seen many companies, including my current client, skimp on developer hardware and cause developer frustration because of it. I think it's great when companies provide developers top-of-the-line hardware and eliminate frustration over CPU and memory resources. LinkedIn and Time Warner Cable both provide their developers with Mac Pros and MacBook Pros as well as huge monitors. IMO, this is one of the best benefits you can provide your engineers.