Mike Knepper

Polyglot Influences in Python

One of my favorite aspects of working in different languages on various client projects is seeing how concepts learned in one paradigm bleed into others. My latest professional work is written in Python, but I find myself using many strategies that I’ve picked up from working in other languages. This post surveys some of the influences my past experience has had on the way I write Python today. I should note that the other languages mentioned here are definitely not the original sources of these concepts; rather, they’re simply where I personally first or most often encountered them.

Types of Types in Elm

I’ve recently been working on a project in Elm, and it has been a blast.

Framework Seams

I recently created an open source plugin for Jekyll, the Ruby static site generator. Jekyll LilyPond Converter (henceforth JLC; source, RubyGems) converts specified code snippets in Markdown blog posts to music images using LilyPond. (A small demo exists here.) The project was just complex enough to warrant using a pattern I often use on larger projects, as well as bite me with a sneaky, related “gotcha”, both of which are worth reviewing and sharing. This pattern relates to a concept I call a “seam” that I find myself carefully considering more and more in all the software I write.

Demoing jekyll-lilypond-converter

Below this sentence in the raw markdown file is a standard code block marked as lilypond, containing a C major chord.

Keeping Third-Party Swift Dependencies Testable

When adding a third-party library to a project, I typically find plenty of examples of how to use the library in a dead-simple, script-like way, but not how to properly integrate it into a larger system. In particular, it can be unclear how to use the library in a way that doesn’t sacrifice testability. In this post I will walk through adding Alamofire, an HTTP networking library, to a Swift project in a way that keeps business logic and behavior easily testable.

Moving Towards Continuous Delivery

Continuous Delivery is a hot concept in the software industry these days, but can often seem like an impossible goal. “How could our system ever do that?” ask the developers working on legacy systems. While there are often several technical hurdles to overcome, practicing Continuous Delivery can also require significant cultural changes. In this post I’ll describe some of the key exercises and processes we used at one of our clients to begin moving towards a culture of Continuous Delivery.

Keeping Laravel Controllers Clean with Form Requests

I’ve recently been working in PHP and have been very impressed by the Laravel web framework. At first, having only heard horror stories of massive if/else statements and SQL queries in HTML views, I wondered if writing clean PHP code would even be possible. But while PHP certainly has many “gotchas,” one can still use it to write well-organized, testable software. Furthermore, Laravel in particular is an excellent, modern MVC framework, offering a logical directory structure out of the box without being too dictatorial about where your code should go. Laravel will feel quite familiar to Rails or Django developers, but it also provides a few unique and valuable tools. Perhaps my favorite of these are Form Requests, which provide a great way to keep your controllers clean and concise.

Baking a Cake with Rails

In my last post, I cautioned against hastily reacting to the abundance of talks and blog posts describing migrations away from Rails monoliths. A preliminary question I didn’t address is: why are there so many of these stories in the first place? Most authors and speakers explain that upon reaching a certain scale, their Rails monoliths became difficult to maintain, but why is that? There are many potential explanations, but in this post I argue one major reason this is so common is that Rails strongly encourages organizing code into horizontal layers at the expense of vertical slices.

The Hidden Costs of Leaving a Monolith

Have you read any blog posts about splitting a Rails monolith into microservices? Or listened to a podcast or watched a talk? Odds are you’ve come across at least one, because they’re everywhere.

Optimizing Ruby Thread Pools

More threads are not always better.

Handling Exceptions with Middleware in Clojure

My team was recently tasked with developing a few HTTP endpoints in our Clojure service to be used by a separate UI. The requirements included a few POST endpoints to allow users to create new records in our Postgres database. In this post I will walk through the evolution of this feature to demonstrate a pattern for handling exceptions using middleware.

Refactoring Legacy Code

The past couple weeks, I’ve spent a lot of my free time refactoring a Rails application I wrote prior to joining 8th Light. Much of that time has been spent shaking my head and asking myself what in the world I was thinking at the time.

The Dangers of Ruby Gems

When you use a gem, you are choosing to rely on someone else's code rather than your own. You are trading control for convenience. Sometimes this trade works out splendidly, but other times it leads to far more trouble than it's worth.

Maintaining Readability When Refactoring

Significant refactors can be slick and impressive in the git diff, but it’s important not to get carried away.

commit 1985bttf1955

If you’ve ever needed to look back on when some change was made in a project, you probably went to the git commit history, which provides an objective narrative of the project’s development. Well, unless you get that Flux Capacitor fluxing and hit 88 miles per hour with these git commands.

RVM to rbenv

I recently switched from RVM to rbenv for managing Ruby versions. Here’s why, and how.

More on the Presenter Pattern

Here I describe a nice adjustment to the Presenter Pattern as I explained it in a recent post. This update makes the views even more readable.

Stubbing Authentication and Authorization in Controller Specs

Controllers are powerful and complicated objects that easily accumulate responsibilities. Even when following the classic Rails convention of “Skinny Controllers, Fat Models”, controllers still have a lot to handle. One extremely important responsibility is checking user authentication and authorization. The typical way to handle these two critical aspects of a web application in Rails is through the use of before_action or before_filter statements. These are called before specified actions in the controller and are capable of redirecting users before they reach those actions. For example:

The Presenter Pattern in Rails

Before joining 8th Light, I built several web applications in Rails. This experience proved invaluable when joining the Footprints team, as I’m already familiar with things like the directory layout/structure and flow of events in the framework. However, 8th Light values several design patterns that break Rails convention, and consequently my experience on the Footprints team has been quite eye-opening and is leading me towards a different approach to building web apps with Rails. One such pattern that is quite simple but very valuable is the use of “presenter” objects in view templates.

First Steps in Footprints

This week I joined the Footprints team. Footprints is an internal application 8th Light uses to track applicants from our website to our apprenticeship program. I’ll be working on this team for the next several weeks, and will surely have several blog posts related to the journey, beginning with this one.

Java Interfaces Are Awesome

My two favorite things about Java are interfaces and (on the good days) the certainty of static typing. This post provides an example of how interfaces are useful in testing.

Testing Multi-threading in Junit

My last post was about implementing threading and concurrent processing in my Java server. This post demonstrates how I’m testing that functionality with Junit.

Threading in Java

A primer on working with threads in Java.

Sever/Application Relay

My Java server has been dramatically simplified this week. As I’ve alluded to in previous posts, the server is now simply responsible for accepting requests and sending responses. Everything regarding parsing the details of the request and generating the appropriate data for a response has been stripped from the server and moved into a completely separate external application. Here’s how it all works.

Nixing the ExceptionHandler

A few posts ago, I described the ExceptionHandler class in my Java server, which I thought was pretty clever. Well, it has been removed. Here’s why.

Server Boundaries

As the development of my Java server continues, I wonder: what exactly should it be doing?

Strings vs. Bytes

One of my tasks this week was to make my server capable of serving up image files. Ultimately this isn’t too difficult a thing to do, but it did require me revising my understanding about a fundamental aspect of how a server works.

Exception Handling

Yesterday I built an ExceptionHandler object to, well, handle exceptions in my Java server. In this post I will explore the purpose of the ExceptionHandler, how it works, and the benefits of custom exceptions.

Reactions to "Simple Made Easy"

Rich Hickey is the creator of Clojure. In 2011, he gave a talk entitled “Simple Made Easy,” which you can watch here. I strongly recommend this talk to any programmer, but especially those interested in Clojure specifically. I found myself agreeing with a lot of what Rich says, but also questioning a few points as well.

Curl-y Q&A

I’ve begun working on my Java server–another classic 8th Light apprenticeship project. This adventure will likely spark several blog posts, beginning with this one: a quick primer on the bash command curl. This command often shows up in the context of downloading and installing software from the internet, and frequently looks like the most intimidating and scary method of doing so. It’s definitely a powerful tool, but can also be used very simply to provide basic, but critical, information. I’ve found it especially useful while building my server.

Speclj with-redefs and should-invoke

Speclj is a Clojure testing framework very similar to Ruby’s RSpec. Its most basic component is (should= x x)–this function forms the backbone of my test suite, covering nearly all my unit tests much like expect(x).to eq(x) tends to do in my RSpec tests. However, I do have a few more complicated namespaces for which should= by itself is insufficient. I will walk through two more complicated test cases here.

Work in the Present

One of my tasks this week is to remove a feature from my Clojure Tic-Tac-Toe app. This requirement, along with some other work I’ve started this week, has me thinking about working in the present.

Refactoring Clojure TTT

This week was spent focused on my Clojure Tic-Tac-Toe app. While some of my work involved adding new features (play again option, custom player tokens, etc.) the primary objective was refactoring for clarity and simplicity. Here are some lessons and tips from the experience.

Response to DHH

DHH, the inventor of Ruby on Rails, published a blog post this morning in which he criticizes TDD, unit testing, and (vaguely) several software design principles. This is my response.

Iteration Planning Meetings

During my novice apprenticeship, my iteration planning meetings (IPMs) with Rylan typically consisted of some code review, conversation, and high-level scoping out of tasks for the following week. As a resident apprentice, however, our IPMs are becoming more formal and will increasingly resemble the IPMs the craftsmen have with our clients. IPMs are crucial for consultancies like 8th Light—they are the primary interactions between the two parties working together, not to mention being directly concerned with the always-important issues of time and money. As someone who has always valued honest, transparent communication, I look forward to developing my ability to explicitly define and describe my work, and estimate its value, over the course of my residency at 8th Light. Here are some thoughts about keeping IPMs productive and valuable for both sides.

To Clojure, From Ruby XOXOXOX

Last week I started building Tic-Tac-Toe in Clojure. I had done some katas in Clojure a couple weeks prior, but this was my first major project in Clojure, and indeed in any functional language. At the outset I had no idea where to begin—I felt disoriented not having objects and wondered how I’d ever be able to pause and do something like check for a winner on the board, for example. Doesn’t the board need to have some state that I manipulate over the course of the game? However, thanks to a few tips from some other apprentices and recalling lessons from my Ruby TTT, I made progress very quickly, and already have a working game (albeit against a simple AI).

Handrolling Mocks in Java

In my last post, I briefly mentioned the Strategy Pattern, which makes switching between different implementations (or “strategies”) trivial. In my Tic Tac Toe game, for example, the Strategy Pattern allows me to easy change a generic Player object from, say, a Human to an Unbeatable Computer. The Strategy Pattern is itself a demonstration of the Open/Closed Principle, which states that objects should be open for extension but closed for modification. Excellent! But, if an object is open for extension presumably indefinitely, how do we test it?

Depth and Direction

I’ve been reading a lot this week about the SOLID principles and various design patterns in object-oriented programming, and find myself often thinking about the concepts of depth and direction. Understanding “where” different classes exist and the directions of their dependencies is crucial to designing applications cleanly.

MiniMax Lessons and Reminders

Creating a Tic-Tac-Toe game that implements the MiniMax algorithm is something of a rite of passage at 8th Light. It has been without question the most difficult thing I’ve worked on as an apprentice, and frankly I’m still not 100% certain my current solution is sufficient, but I have at least made some progress and my tests are passing. Along the way I’ve learned and remembered several important lessons to help the process.

Vim

When I began my apprenticeship a little over a month ago, I decided to use Vim exclusively whenever I was working on 8th Light projects. I still used Sublime Text 2 on Tuesdays and Thursdays at WireHarbor, but gradually I got more and more comfortable with Vim. Earlier this week, I arrived at 1871 and fired up the WireHarbor code in… Vim. It appears the end of Sublime Text 2 is nigh. Here are some thoughts from a recent convert.

Chairman of the Board

This week I used Sinatra to add a web interface to my Ruby bank. Sinatra is a DSL for building web applications with Ruby, and in a way can be thought of as a “web framework,” though it is far more lightweight and flexible than Rails.

Single Responsibility Principle

As my Ruby bank develops into a more mature application, Rylan and I continually discuss the Single Responsibility Principle. This design principle seems fairly self explanatory, but I’ve found it subtly tricky to follow while building my bank app, particularly with regards to defining what constitutes a “single” responsibility. That said, it has been worth the effort and occasional headache.

Repository Design Pattern

Last week I studied and began implementing the Repository Design Pattern in a Ruby application. The RDP involves placing a layer of abstraction between data storage and the rest of the app, which ultimately provides more flexibility with regards to how you want to store your data.

Welcome to the Gilded Rose

I recently began working on the Gilded Rose Kata in Ruby. This is a fairly famous exercise originally written in C# but translated into several different languages*. Unlike the other katas I’ve worked on so far, the Gilded Rose Kata begins with pre-existing code, and is primarily an exercise in refactoring.

Katas

Today was my first “official” day as a novice apprentice at 8th Light. After spending some time setting up vim to my liking, I started working on my first code katas. I had heard about code katas before, especially in relation to 8th Light, but I had never tried one, nor did I ever really understand their purpose until today.

Ruby De-Railed

An early challenge in my apprenticeship at 8th Light is going to be weaning myself off of Rails and becoming more comfortable working in pure Ruby.

GitHub Pages and Jekyll

I’m very excited to be launching this newest version of my personal Internet corner on GitHub Pages. I thought I’d provide a brief history of how I got here and why I think this solution is the best for me.