Stephen Nimmo

Energy Trading, Risk Management and Software Development

Month: May 2013

Define Your World

I recently finished reading The Dip, a short book by Seth Godin which does a great job explaining how to be successful in the projects in which you choose to engage. The concept is simple.


  1. Anything that you choose to do (project, work, hobby, etc) has a dip, which is the amount of time and effort required to get between the excitement and enthusiasm involved in a new endeavor and the desired end result – also known as the hump.
  2. Everything has a dip but dips are different. Learning to say hello in 5 languages has a dip of maybe an hour or two. Learning to speak 5 languages fluently has a dip of years, possibly decades.
  3. For those things you are seriously interested in engaging in (not hobbies), such as starting a new company or writing a book, you need to be able to prepare for the dip, recognize it when it happens and work through it by either incorporating strategies to be productive through it or shorten it.
  4. If you aren’t willing to go through what’s required to get through the dip, you shouldn’t even bother. Quit now and save yourself the time and effort to focus on something you are willing to get to through the dip on.
  5. You should also strive to be the best in the world in what you do.

Best in the world? Yep. But Seth throws a little curve ball as his definition of the world comes with a big asterisk. Best in the “world” is being best in the world in which you define it. Looking at it from a consumer, let’s say you want a graphic artist to do some logo work for you. You want the best (who doesn’t, amirite?). But there are several problems with attaining the best. The best is usually already busy with other work they find more interesting (availability), their prices are out of your range (accessibility) and some of them you might not even know about. So you can’t have the best, but you can have the best based on the available graphic artists who are available and willing to take what you are willing to pay. These two aspects just cut your pool down about 95% with two simple characteristics.

But using Seth’s logic, this is what you should be focusing on – being the best of the world of the graphic artists who are freelancers, are willing to do things for less than $100/hr and have bandwidth. All of the sudden, the world as you know it becomes much clearer and even attainable. Now, you can take this world construction down to such a sganular level that it becomes absurd. I am the best blogger in the world named Stephen, using WordPress, who is 6’1″, etc. This doesn’t really do much for me. However, being the best blogger in the world doesn’t give me much value either. Instead, I pick a middle ground. I want to be the best software development and product management blogger in the Houston area. While that pool is still pretty deep, it is also something I can strive towards and it’s an attainable target, if I can get past the dip. My dip involves refining my writing style and increasing the value of my offerings. These are very tough things to work on and require some pretty serious commitments. Your world may change as you develop and attain new skillsets or experience. A software developer’s world may go through several phases.

The best at documentation out of the 3 junior developers on the team.

The best at refactoring the persistence layer on the team.

The best developer on the team.

The best developer in my section.

The best developer in my company.


If you have some spare hours this weekend, grab a copy of the book and give it a read, especially if you are like me and have many more projects that you start but don’t finish. Reading the book and understanding the concept isn’t hard. Defining your world is the real dip. Start small. Dream big.

Production-ready standalone REST using Dropwizard

There has been a large movement to REST interfaces because of the shift to new mediums, such as mobile, as well as the overall shift to more client-side, in-browser functionality using HTML5/JS. While the server side processing of views still have their place, more and more users are wanting to see less full request-response interfaces, and more ajax and push functionality in their web applications. This is almost creating a new era of a two tiered architecture, shifting more of the domain and business processes closer to the user and leaving data access and other pluggable functionality on the server. If you squint your eyes, you can see the parallels to the Powerbuilder/stored procedure paradigms but the difference now if these technologies are incredibly scalable.

Thanks to the large movement to open source technology used in the big internet shops (Facebook, Twitter, blah-blah-blah), the lowly developer doesn’t have to look far to grab a good starter kit for building some pretty cool applications. One of the latest ones I found is Dropwizard. Per the website:

“Developed by Yammer to power their JVM-based backend services, Dropwizard pulls together stable, mature libraries from the Java ecosystem into a simple, light-weight package that lets you focus on getting things done. Dropwizard has out-of-the-box support for sophisticated configuration, application metrics, logging, operational tools, and much more, allowing you and your team to ship a production-quality HTTP+JSON web service in the shortest time possible.”

The cool thing about Dropwizard is the fact the services are turned inside out. Instead of the software being embedded in a container, the services usually associated with containers are embedded in the application. It’s a J2SE-based HTTP/JSON/REST framework that doesn’t require the deployment and installation of containers or web servers. The reason it’s cool is scalability part of it. If you want more services, you can horizontally scale on the same machine by simply starting some additional instances.

The other cool thing is that their documentation to get started is damn good. While there are tons of blogs out there that really serve a great need in further refining the existing documentation, Dropwizard needs no help. So I am not going to try to reinvent the wheel here. Go get started:

After doing some development with the platform, here are some observations:

1) It’s really good for REST based services. But if you need to serve up any UI stuff outside of a pure HTML5/JS model, then you are going to have to jump through some hoops to integrate any view technologies into the stack such as JSF. Sure it has some cool capabilities to add assets to the web container to be served up, but once you start going there, there are some hurdles and fine grained knowledge needed to get things to fit right.

2) Security model requires some internal development especially if you want to do something other than Basic HTTP authentication and can get hairy. I tried multiple authentication/authorization models and even tried extending some of the existing Framework classes. While it can be done, it’s not easy.

3) No built in Spring integration and no Java EE CDI stuff. Not hard to initialize and get it into the model.

4) The stack is a best of compilation of some of my favorite things: Jackson, Hibernate Validator, and others. I also got introduced to some new stuff like JDBI. If anything, Dropwizard gets you to possibly take a look at some other ways to do things and perhaps might even change your development stack.

Overall, it’s worth a weekend for the tinkerer and a POC after that at your shop, especially if you are deploying a mobile app with a lot of users.

Go follow the developer @Coda

Couple of Dropwizard links I found helpful:

Putting software inside other software

I’ve lived most of my technical life in a web based application. Because I am a java guy and don’t like Swing development, when I build something, it usually had a web based interface. There are two really great things about web UIs: anyone can use them and they are horizontally scalable.

When you live in web applications, you are also mostly living in application servers. There are so many names and flavors you can get lost really fast. I came to age during the popularization of J2EE and did quite a bit of work on the behemoth platforms like Weblogic and Websphere, which I don’t think anyone can still justify why we used them. Cutting your teeth on EJB 2.0 CMP entity beans is not the most pleasant experience. Couple that with my experience with CORBA before that, and you’ll understand why I love Spring.

Recently I have been diving back into the technology, taking a particularly longer look at JEE technologies. I’ve been using JSF for years but always spring-backed. I’ve taken a liking to the JBoss AS 7 capabilities and even the TomEE server. But the question still begs to be answered: why do we need these bloated application servers anyway?

With REST and simple embeddable web servers such as Jetty, you can get some of the goodness of a J2SE environment and none of the snowflake configurations required by the “standard” app servers. There is even some open source tools at your disposal, most notably Dropwizard, which allows you to have some pretty robust standalone web resources without the containers (well, the containers are still there but they aren’t as instrusive). These platforms do have their drawbacks, requiring some pretty extensive work to handle security and if you need a full blown UI using JSF, it can get painful.

What the industry needs is an easily deployable standalone application model that doesn’t require extensive custom configuration. I need to build an application, deploy it over there, create some network rules and start it. And if I need it to cluster, it can be self aware of it’s clustering environment (Hazelcast has spoiled me). When your application developer is spending more time building plumbing and security rather than domain objects and service layers, it’s a problem. Don’t get me wrong, there are plenty of useful and relavent cases where large application server infrastructure is not only necessary, but can be a strategic advantage in terms of scalability and ease of deployment. I just wish there were more choices.

© 2017 Stephen Nimmo

Theme by Anders NorenUp ↑