Geeks on the spotlight: James Ward
I'm James Ward, a Developer Evangelist at Heroku where I help Java developers learn how to deploy their apps on the cloud.
Favourite Open Source project? Play Framework
Preferred technologieS? Java & Scala
Hardware that you use? Thinkpad T420s
Software that you use? Ubuntu Linux
Type of music (or band) to listen to while coding? Birds Chirping
You have been a Developer Evangelist for quite a long time, starting at Macromedia/Adobe and now at Heroku. What do you like most about being a Developer Evangelist?
In my job as a Developer Evangelist I get to meet awesome developers all over the world and learn tons of new things from them. I really enjoy showing them new cool technologies like Play Framework and Heroku. It's very rewarding for me to see developers successfully learn and use something new.
What is one of your latest accomplishments as a software engineer that you are most proud of?
Lately I've been experimenting with browser-based apps built with an architecture similar to Client/Server. I've been building the client-side using a smattering of popular browser technologies including JavaScript, jQuery, Twitter Bootstrap, and CoffeeScript. On the server-side I've been building stateless JSON services with lightweight and non-blocking HTTP frameworks like JAX-RS + Grizzly, Play Framework, and BlueEyes (a Netty-based, Scala web service library).
As a result of these experiments I realized that we need to be managing our client-side library dependencies just like we have been doing with Java libraries. This led me to begin creating JAR wrappers around JavaScript and CSS libraries. To support this I created the WebJars project (http://webjars.github.com) as a central place to collect these web library JAR wrappers. The libraries are in a Maven repository so anyone can consume them from a compatible build tool. Luckily most web frameworks can serve static resources directly from JAR files so it is super easy to specify a web library as a dependency and then add a reference to it from a web page.
As we use more and more client-side libraries to build modern web applications it becomes increasingly important to explicitly manage those dependencies and their inter/transitive dependencies. The new WebJars project is an important part in helping developers successfully move towards modern web and mobile application architectures. For more information about WebJars, check out my blog announcement.
Heroku advocates for containerless deployment, something not so common in the Java classic architecture. Why? What are the main advantages of it?
The ‘containerless’ approach has been used for a long time by some Java developers and is the way most non-Java web technologies work. The concept of deploying an app into a monolithic container is being replaced by lighter-weight, more partitioned approaches where HTTP handling is not external, but is something an application just does. The containerless approach ensures there is better consistency between environments since everything needed to run the application is completely self-contained. The HTTP handling library should be a dependency just like the persistence library. This helps us avoid the "it works for me" situation that many of us have experienced and creates better consistency between development and production environments.
Heroku has embraced the containerless approach with Java because Heroku doesn't dictate, or even provide, an application server. You can run anything on Heroku so you need to bring your own application server / HTTP handling library with you. This provides developers with maximum flexibility for their apps and ensures that apps remain completely portable without having to implement any proprietary APIs.
The easiest way to include your application server and bring it with you is to specify the server as a dependency of the application itself. If you are doing things the containerless way, then this is already taken care of. Yet if you still want WAR packaging and a container then you can simply specify Jetty Runner or Webapp Runner (for Tomcat) as a dependency of your app. Whether you go containerless or not, you can run your Java apps on Heroku.
Where would you recommend to use a container and why?
Now that I've been successfully using the containerless approach via the Play Framework, Jetty, Grizzly, and BlueEyes for almost a year, I can't see myself going back. I've yet to encounter something I don't like about the containerless approach. With containerless the setup, debugging, dev/prod consistency, startup time, composability, and simplicity are all better. Yet large organizations have people dedicated to managing and tuning application servers. This makes the containerless approach harder to implement but this will change as we shift more towards DevOps, Continuous Delivery, and the Cloud.
Heroku supports Spring, Tapestry and Play Framework, can you name one thing that you like from each of them?
I'm a fan of the new Spring Data stuff that is happening around NoSQL and Graph databases. Simplifying polyglot persistence makes it possible for us to get away from the current model where all data must fit into a relational model. Using polyglot persistence through Heroku add-ons is simple because there are add-ons for all sorts of different data stores like Neo4j, MongoDB, Redis, and Cassandra.
Tapestry has always been dear to my heart. I have always preferred building UIs through a component model rather than templating and Tapestry was one of the first to enable that in Java web apps. I also like Howard's vision for an end-to-end development approach that includes client-side JavaScript as part of the application, rather than as a separate thing.
Play Framework's simplicity is really attractive. Declarative routes, not hiding HTTP, and type safety for everything make the development experience fun and productive.
In the last year Heroku added Clojure, Java, Python and Django, Scala, and Groovy and Grails support. How do you prioritize what's next? Can you disclose the next one?
With the introduction of Heroku's ‘Cedar’ stack last Spring, developers can truly run anything on Heroku. The platform is open for anyone to create or modify a build pack. Heroku has provided a handful of out-of-the-box build packs like Play, SBT, and Maven. You can find the source code for all of the build packs on the http://github.com/heroku site. This openness not only differentiates Heroku, but fosters trust and collaboration with the community. What's next? Whatever you want!
Heroku is also building a massive ecosystem of cloud service providers through the Heroku Add-ons. If you go to http://addons.heroku.com you will see a giant list of service providers for everything from log management and web performance monitoring like New Relic, to several NoSQL data stores like Redis, CouchDB and MongoDB and real-time push services like Pusher. This ecosystem allows developers to focus on what is core to their application and let someone else handle the management and scalability of everything else.
Check out James Ward profile on Masterbranch. Don't you have an account yet? Sign up here!