Although I agree that everything in his version is a good idea, I disagree with the formulation as an ethical guideline for programmers. Simply put, the principles of Agile are brilliant. But they hardly deserve mention in a list of ethics, and – I would contend – detract from the list.
I’ve read a lot recently about how hard it is to recruit programmers in today’s market. Personally, I think it’s all hogwash.
There are plenty of great programmers out there, but companies aren’t actually looking for them. What they really want is a plug-n-play solution, a programmer who knows what they need him/her to know, who can churn out code and build software solutions.
The problem is that engineering is an art and a discipline, and you can’t just expect to hire someone and have them show up batteries included. A company that refuses to train its coders is a company that won’t find enough people to meet its needs.
Recently, a new member of our team asked me (and other coworkers) to list 3 things a junior developer should accomplish within their first 3 months on the job. Being at the end of my first year on the job, it was an excellent opportunity for reflection on what I have learned during this year which was most useful.
After some thinking, I came up with 3 concrete goals, emblematic of 3 big-picture objectives which should be guiding lights for the new developer.
Here are my picks:
- Be reasonably comfortable with TDD
- Write good commit/PR messages
- Present at a team hangout
These might seem like arbitrary goals, so they deserve some explanation.
So I built this thing…
Here’s the problem we were having at work. We have a bunch of microservices
which communicate with each other via HTTP. Since they’re passing around raw
data, and the shape often changes, we decided quite some time ago to use classes
OpenStruct, that magical schema-free class, as a data container.
The problem is,
OpenStruct is also ridiculously slow…
Note: Part III assumes familiarity with the idea of feature flags, and their practical implementation using the rollout gem. For the theoretical background, see Part I. For more info about rollout, see Part II.
You have feature flags in your application, letting you turn off calls to external services as necessary. How can we make this happen automatically?
Note: Part II assumes familiarity with the idea of feature flags. For the theoretical background, see Part I.
Alright, you’re convinced that feature flags are a necessary tool for your app. Let’s discuss a gem, created by the late James Golick, which make the process of feature flagging as simple as could be.
What are Feature Flags?
Glad you asked!
Feature flags, also known as “feature flippers,” “feature toggles,” and more, are a way to simply turn bits of code on and off in a live, running application.
While we won’t get into too many of the details in this post, here’s a simple way to think about it. Let’s say you run a bowling alley. Most of the time, it’s a straightforward establishment – lanes, balls, scoring computers, shoes… you get the idea. However, every Tuesday night you turn over the place, and now it’s Cosmic Bowling night! You’re blasting music, shining blacklights, the disco ball is spinning… it’s a different world. How are you going to carry out this operation?
On the Vitals Choice team, we have divided our product into a number of apps. Each of those apps has one running instance per environment , and we have several environments. So as you might imagine, making sure updated code gets propagated through all those places at the right time can be quite the task. Luckily, we have a Hubot instance which does most of the heavy lifting, but even issuing all the Hubot commands for every single app makes you wonder: shouldn’t there be a way to automate this better?
Considering the problem, I realized that callbacks were the way to go. Hubot comes with an evented system, which we could utilize to force Hubot to only launch one app at a time. Here’s what I came up with, and what I learned along the way.
Recently at work, I spent over a day trying to get one failing test to pass. I tried everything in the code, but no dice. Finally, I realized that the problem wasn’t with my code – it was with the way Capybara works. I want to save you the time I lost, so let’s get to it.
Capybara, to quote its creator Jonas Nicklas, “is ridiculously good at waiting for content.” It knows that when it’s told to find something on the page, or click a link, and it’s not there, don’t sweat it – just keep trying until a default timeout (
Capybara.default_wait_time) is hit. When, and only when, that timeout is hit, Capybara will give you an
This works great for most use cases. However, sometimes it just isn’t enough. Let’s illustrate with a real-world example.
Ruby provides a number of options for non-instance-specific variables – class variables (of the form:
@@var), constants (in all caps:
VAR), and class instance variables (
@var). Which one to use depends on the use case, and to some degree on personal preference. Let’s explore this a bit.
Constants are meant to be – well, constant. This is not technically enforced in Ruby; if you redefine a constant during program execution, it will display a warning, but not actually raise an error. However, the semantic idea of a constant is that it should be defined once and not touched again. Variables, on the other hand, are variable. They record a particular state that is likely to be redefined at some future point in time.
Now let’s examine some use cases and see where things start to get tricky. To make things fun, let’s go to the zoo!