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”…
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.
/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…
Part 2: Testing Behaviors is available here
Extracting Duplicate Code with Behaviors
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…
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.
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…
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.
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:
- Lack of static typing that isn’t painfully repetitive (Java)
- 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…
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…
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…
Like many other Atoms, I’ve recently been doing some work with EmberJS. Ember is an awesome web development toolkit with some really killer features. One of my favorite parts of Ember is how easy it is to test. The framework comes bundled with a system testing framework, and its object model makes unit testing a breeze. Combine all that with a great test runner that has CI integration, and you have a really awesome testing ecosystem for your new app.
System Testing with Ember Testing and QUnit
Read more on Testing & Tooling in EmberJS…
Marionette.js is an extension library for Backbone.js that offers many improvements and conveniences to cover common use cases for Backbone. On a recent project, I helped build a large single page application using Marionette.
One thing that Marionette lacks out of the box is a convenient way to manage form lifecycles, including validating and submitting forms with minimal overhead. To address this, I created a generic FormView class that extends Marionette’s ItemView and works with the backbone-validation plugin.
Without further ado, here is the Marionette FormView class I created: Read more on Handling Forms with Marionette.js…
During my most recent project, we made extensive use of formal code reviews. This process drastically increased the quality of code in the project, reduced the ramp-up time of new devs on the project, and facilitated knowledge sharing across the entire team. I also found that it didn’t cause an excessive hit on developer productivity for our project. Read more on The Value of Code Review – Why, When, & How…