Hooking up Custom Jersey Servlets in Dropwizard

I’ve been using the Dropwizard Java framework for about a year. It’s a great web application stack for making RESTful service with Java.

I recently ran into a situation where I wanted to add custom servlets to a Dropwizard application. Read more on Hooking up Custom Jersey Servlets in Dropwizard…

Read more on Hooking up Custom Jersey Servlets in Dropwizard…

Answering Client Questions – 5 Alternatives to “I Don’t Know”

I’ve learned a lot of things in my time at Atomic Object, most of them falling into two categories: how to write great software, and how to be a consultant.

One of the most important skills I’ve learned in the latter category is how to always have an answer for a client.

Read more on Answering Client Questions – 5 Alternatives to “I Don’t Know”…

Serving Static Assets with DropWizard

Over the last few months, I’ve had the opportunity to do a lot of work with DropWizard, an awesome Java web framework for developing RESTful web services.

I was recently prototyping a small application, and I wanted to serve static files directly from DropWizard. While this isn’t what DropWizard is primarily designed to do, I didn’t want to go through the process of setting up another web server just to serve static assets for a prototype. While DropWizard has some out-of-the-box support for serving static assets, I found the documentation surrounding it to be incomplete and confusing. It actually took me a couple hours of debugging to figure out how to do exactly what I wanted, So I thought I would document what I learned here.

My end goal was to serve a small single page JavaScript app on the root of my DropWizard application, while having my DropWizard REST endpoints available at /api. The limited documentation around serving assets in DropWizard suggest that setting up an AssetsBundle for / and changing the application context path in your config file should be enough to achieve this, but that did not work for me. I had to do the following steps: Read more on Serving Static Assets with DropWizard…

Marionette.js Behaviors, Part 1: The Basics

Part 2: Testing Behaviors is available here

Marionette is a Javascript application framework built on top of Backbone. It provides great features missing from core Backbone like collection views, subview management, and abstractions for building event driven applications.

Extracting Duplicate Code with Behaviors

Marionette.Behaviors are an abstraction for sharing UI code between different views. They are a recent addition to the Marionette toolbelt (added in version 1.7). Prior to the introduction of behaviors, code sharing between views in Marionette had to be handled at the Javascript language level with inheritance or by delegating to external modules.

Behaviors are designed to be loosely coupled and injectable. A behavior knows about the view it is injected into, but the view does not know the details of the behavior. This helps to keep behaviors abstract and reusable between views. Lets take a look at a couple simple Backbone views and how they could be refactored using Marionette behaviors. Read more on Marionette.js Behaviors, Part 1: The Basics…

My Favorite Emacs Add-Ons

I love Emacs. I’ll take it hands down over vim, Sublime, Atom, and company any day. I thought I would take some time to list some of my favorite bits of Emacs and how I use them in my daily workflow.

1. Magit

Magit is an Emacs interface for git. Beyond that, it’s the best interface for git I have ever used — better than the git CLI or third-party apps like SourceTree. Magit reduces most git commands (and all of their cryptic flags) to a series of one-character shortcuts. It also introduces interactive status and log buffers that are comparable to any other git gui out there (and better than many). The best part is that version control becomes part of my editing workflow and requires no context switching. Overall I find that it massively speeds up and simplifies my git workflow and encourages me to use my VCS to its fullest extent. Read more on My Favorite Emacs Add-Ons…

Running F# Using Mono and Unix

Recently, I’ve been playing with the F# programming language in my free time. One barrier that I ran into was the fact that I don’t have a Windows machine, meaning I had to use the Mono runtime on my Macbook. This presented some challenges that I had to work through.

Why F#?

So, why was I playing with F# in the first place? I had been looking for a language to fix some frustrations that I had with my current toolset:

  1. Lack of static typing (JavaScript, Ruby)
  2. Lack of static typing that isn’t painfully repetitive (Java)
  3. First class support for common functional programming idioms – e.g. immutable by default, option types, pattern matching, etc. (All of the above)

I also wanted to take the opportunity to get some experience with the Microsoft/.NET ecosystem. Since the Microsoft stack is incredibly popular at many companies, including some of our clients, it seemed like a solid bit of knowledge to have. Also, I was excited about the possibility of using the Xamarin stack to create mobile apps with F#. Read more on Running F# Using Mono and Unix…

A Checklist for Great Feature Requirements

My long-time girlfriend works as a Business Analyst for an IT company that does agile development. Recently, she asked me what I (as an engineer) look for in an ideal requirements document for a feature.

This hit home for me because I have seen plenty of poorly-defined features on projects I’ve worked on. Poor requirements usually lead to slower development times and features that are more likely to need rework. As an engineer, I have enough work to do in figuring out the best way to architect and implement a feature without having to frequently halt my work and chase down vague or incomplete requirements.

I did a lot of thinking and came up with a pretty comprehensive checklist of things I’d like to see in every feature request/user story/programming task. Read more on A Checklist for Great Feature Requirements…

Maintaining a Unified Culture at a Consultancy

When you think of tech companies with great cultures, your mind probably jumps to the usual suspects — Google, Facebook, or some swanky new Silicon Valley startup. It’s easy to see why (whether it’s a mini-city of a campus or a small, tight-knit group looking to change the world together) these companies have a lot that makes them unique and appealing. But Atomic has a great culture too.

Keeping such a strong, awesome culture at a consultancy can be a challenge, though. Most Atoms are working on different projects for different client companies. On top of that, each company we work with is (to some degree) asserting its culture onto its associated Atoms. This is great in many ways, because it gives us perspective into different ways of doing things and can give us an influx of new ideas. But the challenging part is keeping our culture unified when we are all subjected to such a diverse range of environments.

So what do we do as Atoms to keep our identity and strong culture alive with each other? The answer is a lot of things. Read more on Maintaining a Unified Culture at a Consultancy…