Web Development, Ruby on Rails, Open Source
+Welcome to the BoochTek blog. BoochTek, LLC is a small web development company, based in St. Louis, Missouri. We specialize in Ruby on Rails, jQuery (JavaScript), and PHP.
+This bog will be a place where we can share some of our experiences in web development, Open Source, programming, and technology in general.
+Web Development, Ruby on Rails, Open Source
+Welcome to the BoochTek blog. BoochTek, LLC is a small web development company, based in St. Louis, Missouri. We specialize in Ruby on Rails, jQuery (JavaScript), and PHP.
+This bog will be a place where we can share some of our experiences in web development, Open Source, programming, and technology in general.
+Web Development, Ruby on Rails, Open Source
+Here’s a relatively simple way to rename a bunch of files from the command line. It uses sed within a command substitution to compute the new names from the old names.
In this example, we’re renaming files that start with “ABC” to start with “XYZ” instead:
+ for i in ABC*; do mv $i $(echo $i | sed -e s/^ABC/XYZ/); done
+You’ll have to use shell globbing (wildcards) in the first part, to determine which files will be the source of the renaming, and regular expressions in the second part to translate the old names into the new names.
+It’s a good idea to use echo in place of mv before running this, to see what the results will be, so you don’t make a mistake.
Depending on the situation, you may need to adapt this for your particular needs. For example, if you have too many files to rename, you would need to use xargs. Or sed might not be up for the task of transforming the names that you want. Or you might need to use find to find files within a hierarchy. As with any UNIX idiom, there are hundreds of variations on the theme.
Web Development, Ruby on Rails, Open Source
+Here’s a relatively simple way to rename a bunch of files from the command line. It uses sed within a command substitution to compute the new names from the old names.
In this example, we’re renaming files that start with “ABC” to start with “XYZ” instead:
+ for i in ABC*; do mv $i $(echo $i | sed -e s/^ABC/XYZ/); done
+You’ll have to use shell globbing (wildcards) in the first part, to determine which files will be the source of the renaming, and regular expressions in the second part to translate the old names into the new names.
+It’s a good idea to use echo in place of mv before running this, to see what the results will be, so you don’t make a mistake.
Depending on the situation, you may need to adapt this for your particular needs. For example, if you have too many files to rename, you would need to use xargs. Or sed might not be up for the task of transforming the names that you want. Or you might need to use find to find files within a hierarchy. As with any UNIX idiom, there are hundreds of variations on the theme.
Web Development, Ruby on Rails, Open Source
+I’ve been more interested in programming patterns lately, partly due to the Ruby community’s recent interest — especially the Ruby Rogue podcast’s love affair with “Smalltalk Best Practice Patterns”.
+I consider most of the patterns in “Smalltalk Best Practice Patterns” to be patterns “in the small” — things that are typically employed on a single line or method. The Gang Of Four patterns are more medium sized, dealing with methods and classes. The PEAA book covers architectural-scale patterns. I suppose “The Pragmatic Programmer” and similar books could (should!) be considered to be very general patterns, mostly about the practice of programming.
+One type of pattern that I have not seen discussed much is debugging patterns. I’m not exactly sure why that is; probably just our general concentration on designing the program code itself. There are definitely testing patterns. But I can’t think of anything that I’ve seen that covers debugging patterns. A quick search on the Internet doesn’t turn up too much.
+Anyway, a co-worker (Helena) and I were debugging recently, and were having trouble figuring out where a certain method on a certain object was being called. We came up with a really cool solution. We immediately called it a grenade, because its entire purpose is to blow up (raise an exception) and display a backtrace to show us the caller of the method that we’re looking for.
+Here’s our implementation in Ruby:
+
+module Grenade
+ def method_under_investigation(*)
+ raise "method_under_investigation called"
+ end
+end
+
+class Xyz
+ ...
+ def xyz
+ object_under_investigation.extend(Grenade)
+ end
+ ...
+endI’m sure we could wrap that in some more semantic sugar, even going as far as making it look something like this:
+
+class Xyz
+ ...
+ def xyz
+ object_under_investigation.blow_up_when_method_called(:method_under_investigation)
+ end
+ ...
+end
+I’m not sure that would really be worth it though, unless we were to add it to some sort of library.
+So that’s our contribution to the (small) list of debugging patterns.
+Amos and I got in a heated discussion recently on whether we should write a single line comment to better explain some code. (The code in question was Amos’s very elegant solution to testing whether a job got sent to Resque.)
+Amos doesn’t believe in writing comments much at all. He thinks that if you’re writing a comment, it means that you’re doing something wrong, and that you probably need to write the code more clearly.
+I agree with that, to a point. First off, it’s not necessary to write perfect code. If you can change a class or method name to better describe what you’re doing (and more importantly, why you’re doing it) then you should definitely do so. But it’s not always worth refactoring until you get every “why” answered. More importantly, I don’t think it’s even possible to capture everything in the code that is worth capturing. For example, why did you choose this implementation, as opposed to another that might be more obvious or common?
+After our argument, I came up with a good rule of thumb (or “pattern”):
++Write comments for your (future) self.1
In other words, if your comment will help you to understand the code more quickly when you look at it in the future, then it’s a valid comment. It also means that you can assume that the reader has about as much general programming knowledge as you currently do. (Your future self will have more general knowledge, but possibly less specific knowledge of the lines of code in question. And because of this, your current solution might not make as much sense in the future. You might know of a better solution in the future, but you’ll have to know all the constraints that you had when you originally wrote the code.)
+This is not to say that you should not write comments in clear English, that others can understand. The comment is written for a future maintainer. That may be you (which is why the rule works well), or it may be someone else. The rule is more about when to write a comment, and what level of competence you should assume of the reader.
+1 Perhaps it should be “Write comments TO your (future) self”.
+Web Development, Ruby on Rails, Open Source
+Amos and I got in a heated discussion recently on whether we should write a single line comment to better explain some code. (The code in question was Amos’s very elegant solution to testing whether a job got sent to Resque.)
+Amos doesn’t believe in writing comments much at all. He thinks that if you’re writing a comment, it means that you’re doing something wrong, and that you probably need to write the code more clearly.
+I agree with that, to a point. First off, it’s not necessary to write perfect code. If you can change a class or method name to better describe what you’re doing (and more importantly, why you’re doing it) then you should definitely do so. But it’s not always worth refactoring until you get every “why” answered. More importantly, I don’t think it’s even possible to capture everything in the code that is worth capturing. For example, why did you choose this implementation, as opposed to another that might be more obvious or common?
+After our argument, I came up with a good rule of thumb (or “pattern”):
++Write comments for your (future) self.1
In other words, if your comment will help you to understand the code more quickly when you look at it in the future, then it’s a valid comment. It also means that you can assume that the reader has about as much general programming knowledge as you currently do. (Your future self will have more general knowledge, but possibly less specific knowledge of the lines of code in question. And because of this, your current solution might not make as much sense in the future. You might know of a better solution in the future, but you’ll have to know all the constraints that you had when you originally wrote the code.)
+This is not to say that you should not write comments in clear English, that others can understand. The comment is written for a future maintainer. That may be you (which is why the rule works well), or it may be someone else. The rule is more about when to write a comment, and what level of competence you should assume of the reader.
+1 Perhaps it should be “Write comments TO your (future) self”.
+Web Development, Ruby on Rails, Open Source
+I’ve been more interested in programming patterns lately, partly due to the Ruby community’s recent interest — especially the Ruby Rogue podcast’s love affair with “Smalltalk Best Practice Patterns”.
+I consider most of the patterns in “Smalltalk Best Practice Patterns” to be patterns “in the small” — things that are typically employed on a single line or method. The Gang Of Four patterns are more medium sized, dealing with methods and classes. The PEAA book covers architectural-scale patterns. I suppose “The Pragmatic Programmer” and similar books could (should!) be considered to be very general patterns, mostly about the practice of programming.
+One type of pattern that I have not seen discussed much is debugging patterns. I’m not exactly sure why that is; probably just our general concentration on designing the program code itself. There are definitely testing patterns. But I can’t think of anything that I’ve seen that covers debugging patterns. A quick search on the Internet doesn’t turn up too much.
+Anyway, a co-worker (Helena) and I were debugging recently, and were having trouble figuring out where a certain method on a certain object was being called. We came up with a really cool solution. We immediately called it a grenade, because its entire purpose is to blow up (raise an exception) and display a backtrace to show us the caller of the method that we’re looking for.
+Here’s our implementation in Ruby:
+
+module Grenade
+ def method_under_investigation(*)
+ raise "method_under_investigation called"
+ end
+end
+
+class Xyz
+ ...
+ def xyz
+ object_under_investigation.extend(Grenade)
+ end
+ ...
+endI’m sure we could wrap that in some more semantic sugar, even going as far as making it look something like this:
+
+class Xyz
+ ...
+ def xyz
+ object_under_investigation.blow_up_when_method_called(:method_under_investigation)
+ end
+ ...
+end
+I’m not sure that would really be worth it though, unless we were to add it to some sort of library.
+So that’s our contribution to the (small) list of debugging patterns.
+Web Development, Ruby on Rails, Open Source
+I’ve been using Python at work for the past few months. I learned Python back in the early 2000s, but never used it for any large projects. I learned Ruby in late 2005, and it quickly became my language of choice for most cases.
+So while I still prefer Ruby, and will likely use Ruby more in the future than Python, I wanted to assess the strengths and weaknesses of Python in relation to Ruby. Perhaps some of the lessons could be applied when writing Ruby, and it could help to decide when to use each. Also, I’m interested in programming language design, and wanted to document pros and cons in that light.
+Where Python Sucks (As Compared to Ruby)
++
Web Development, Ruby on Rails, Open Source
+I’ve been using Python at work for the past few months. I learned Python back in the early 2000s, but never used it for any large projects. I learned Ruby in late 2005, and it quickly became my language of choice for most cases.
+So while I still prefer Ruby, and will likely use Ruby more in the future than Python, I wanted to assess the strengths and weaknesses of Python in relation to Ruby. Perhaps some of the lessons could be applied when writing Ruby, and it could help to decide when to use each. Also, I’m interested in programming language design, and wanted to document pros and cons in that light.
+Where Python Sucks (As Compared to Ruby)
++
Web Development, Ruby on Rails, Open Source
+It’s challenging to test Rails custom validators.
+I recently had to write a validator to require that an entered date is before or after a specified date.
+It didn’t seem like writing the validator would be too difficult – I’ve written custom validators before, and date comparisons aren’t all that tricky. But when it came time to write the tests, I ran into several issues. And since I always try to follow TDD / test-first, I was blocked before I even began.
+The biggest issue was the ActiveModel::EachValidator#validates_each API. It’s definitely not a well-designed API. You write your validator as a subclass, overriding validates_each. The method takes a model object, the name of the attribute of the model being tested, and the value of that attribute. You can also get the options passed to the custom validator via the options method. To perform a validation, you have to update the model’s errors hash.
The big flaw in the API is that instead of returning a result, you have to update the model. This needlessly couples the model and the validator. And it violates the Single Responsibility Principle — it has to determine validity of the field, and it has to update the errors hash of the model. This is not conducive to testing. Testing this method requires testing that the side-effect has taken place in the collaborator (model), which means it’s not really a unit test any more.
So to make it easier to unit test the validator, I broke the coupling by breaking it into 2 pieces, one for each responsibility. I moved the responsibility for determining validity to a separate method, which I called errors_for. It returns a hash of the errors found. This simplified the validates_each method to simply take the result of errors_for and update the errors hash of the model:
def validate_each(record, attribute_name, attribute_value) + record.errors[attribute_name].concat(errors_for(attribute_value, options)) +end+
This made it much easier to unit test the errors_for method. This method doesn’t even need to know about the model — only about the value of the attribute we’re trying to validate. We simply pass in the attribute’s value and the options.
So we could write the tests without even pulling in ActiveRecord or any models:
+describe DateValidator do
+ let(:validator) { DateValidator.new(attributes: :attribute_name) }
+ let(:errors) { validator.errors_for(attribute_value, validation_options) }
+
+ describe 'when attribute value is NOT a valid date' do
+ let(:attribute_value) { 'not a valid date' }
+ it { errors.must_include 'is not a valid date' }
+ end
+
+ describe 'when attribute value IS a valid date' do
+ let(:attribute_value) { Date.parse('2013-12-11') }
+ it { errors.must_be :empty? }
+ end
+end
+And the errors_for method looked something like this:
def errors_for(attribute_value, options) + unless attribute_value.is_a?(Date) + return [options.fetch(:message, "is not a valid date")] + end + [] +end+
Integration testing can also be a bit of a challenge. I recommend following the example from this Stack Overflow answer. Basically, create a minimal model object that contains the field and the validation. Then test that the model behaves like you expect with different values and validations.
+Today I was informed that I’ve been impeding progress on our team.
+This was somewhat shocking, since I feel like I’m always pushing
+forward to make our team and myself better.
Like most anyone, my initial reaction to criticism was defensiveness.
+I don’t handle criticism well. (You might find that hard to believe,
+after reading the rest of this post. Maybe it’s just the confrontation
+part I don’t handle well.) Thankfully the blow was softened somewhat,
+because the person providing the criticism didn’t tell me directly —
+they told Amos, a trusted colleague of mine. Amos then passed it on to
+me. I’m grateful for that — this is the best way for me to have received
+that criticism.
What I did next is the astonishing thing. I swallowed my pride for a
+minute. Not an easy thing for me to do, for all the usual reasons, and
+more. I decided to address the problem head on. If someone was telling
+someone else that I was causing some sort of a problem, then even that
+perception was a problem that I needed to address. So I decided to hold
+a retrospective for myself. Retrospectives are the way Agile teams address
+problems and improve how they work. If it would work for a team, I figured
+it should work for an individual.
I’d held retrospectives by myself before. Before I even knew about
+retrospectives, I’d taken some time to assess how I had done things
+on a couple of projects I had worked on as an independent contractor. But
+those were about technical decisions I had made and processes I had
+followed. This one would be different. This one was about a personal
+shortcoming, an action of mine that had caused some harm. This one
+involved feelings and emotions.
So I asked Amos to facilitate my one-person retro. We’d both done a lot
+of retrospectives, but neither one of us had done anything like this before.
+We had a bit of trouble getting started. We didn’t have any details
+about why the anonymous person felt the way he felt. So it was hard
+to address something that nebulous. So I asked Amos if he could follow
+up with the person. Luckily, the person was online and able to respond
+in real time.
So we talked things through some. We went on some tangents. We made some
+progress — things that I could write down as take-aways and action items.
+We got off-topic again, and then came back to it. Then Amos decided to
+play The Why Game. This worked amazingly well. It helped me to find the
+root reasons why I was holding back change. Basically I’m afraid of
+failure. Going deeper, we looked into why I’m afraid of failure. This
+line of inquiry was particularly effective. Hopefully it’ll be enough for
+me to stop being an impediment to change. Here are my notes / take-aways:
At first, I thought that I’d never heard of anyone doing anything like
+this. But then I recalled that I’d heard about somewhere that everyone
+does this, with their whole team. That would be hard. I’d have to
+trust everyone in the room.
But I would recommend this for anyone that can pull it off. It’s hard,
+but it has a large payoff. Just like a team retrospective, it feels good
+making this kind of breakthrough, and knowing that just spending that
+little amount of time has made me a better person. (Mine took about an hour.)
+I think the hardest part is finding someone (or a group of people) you
+trust to be your facilitator.
I’ve decided to call this thing an introspective. A retrospective is
+about looking back. This is about looking inward. I’d be interested to
+find out who is doing this kind of thing. Does it have a commonly accepted
+name? How does it work? What techniques work best? If you’ve got any answers or ideas, please comment below, or tweet me @CraigBuchek.
So thank you to that anonymous person. Your way of addressing this was
+probably more effective than you could have imagined that it might be.
+I hope that this exercise will help me make the changes required, to make
+me a better person, and help the team become the best that we can be.
Amos has written up his thoughts on the introspective.
+I’ve been using GNU/Linux since 1994, starting with a Slackware 2.2 CD-ROM I ordered from the back of a magazine. I’ve been heavily involved in my local GNU/Linux community since 1999, and I give frequent presentations at various groups. I’ve made some small contributions to several Open Source projects.
+But I don’t feel like I’ve done enough to contribute to the wider community. So this year, I’m going to resolve to step up my contributions, and do more.
+I was lucky enough this past year to find someone interested in helping to run the St. Louis GNU/Linux Users Group (STLLUG). I’ve been running the group so long that I’ve somewhat stagnated. It’s great to find someone who will bring a fresh energy and new ideas. Thanks, Andrew!
+Mostly freed from the more general administrative tasks (mostly planning meeting topics and speakers), I’m hoping to find the time to work on a few projects. First, I want to overhaul the web site. It needs a new look, as well as an easier way to update it. I’m planning to implement some sort of CMS — possibly WordPress or Octopress, or at the very least, a git repo to manage updates.
+I installed WordPress a long time ago, but I haven’t published many posts. I’ve got a few drafts in various stages. So this year I’m going to actually get the blog going, and hopefully post about once a week. I’ll be sharing things I learn on the Internet, as well as some of the things I learn from my experiences with various technologies and techniques.
+There are a few items I’ve been meaning to work on and contribute. I’d like to finally get around to them:
+I’ve been working on a few Ruby gems. I’d like to get them to a state where they’re useful to more people. These include:
+I enjoyed building a quick Rails app during last year’s Rails Rumble, even if it doesn’t turn out to be useful or make any money. I’d like to create a few small apps again this year, either in Rails or Apache Cordova. I’ve got some ideas — we’ll see how if they turn into anything useful or worth selling.
+Last year, I started joining the This Agile Life podcast. I enjoy it. I’m hoping to continue with that, and possibly doing some podcasting about Ruby and Rails.
+I’m going to attempt to give a presentation at a conference. I often give presentations at local groups, but haven’t addressed a larger audience. I’ve got a few ideas rattling around, and will see if I can turn them into presentations worthy of a larger conference.
+What’s your Open Source resolution?
+Web Development, Ruby on Rails, Open Source
+I’ve been using GNU/Linux since 1994, starting with a Slackware 2.2 CD-ROM I ordered from the back of a magazine. I’ve been heavily involved in my local GNU/Linux community since 1999, and I give frequent presentations at various groups. I’ve made some small contributions to several Open Source projects.
+But I don’t feel like I’ve done enough to contribute to the wider community. So this year, I’m going to resolve to step up my contributions, and do more.
+I was lucky enough this past year to find someone interested in helping to run the St. Louis GNU/Linux Users Group (STLLUG). I’ve been running the group so long that I’ve somewhat stagnated. It’s great to find someone who will bring a fresh energy and new ideas. Thanks, Andrew!
+Mostly freed from the more general administrative tasks (mostly planning meeting topics and speakers), I’m hoping to find the time to work on a few projects. First, I want to overhaul the web site. It needs a new look, as well as an easier way to update it. I’m planning to implement some sort of CMS — possibly WordPress or Octopress, or at the very least, a git repo to manage updates.
+I installed WordPress a long time ago, but I haven’t published many posts. I’ve got a few drafts in various stages. So this year I’m going to actually get the blog going, and hopefully post about once a week. I’ll be sharing things I learn on the Internet, as well as some of the things I learn from my experiences with various technologies and techniques.
+There are a few items I’ve been meaning to work on and contribute. I’d like to finally get around to them:
+I’ve been working on a few Ruby gems. I’d like to get them to a state where they’re useful to more people. These include:
+I enjoyed building a quick Rails app during last year’s Rails Rumble, even if it doesn’t turn out to be useful or make any money. I’d like to create a few small apps again this year, either in Rails or Apache Cordova. I’ve got some ideas — we’ll see how if they turn into anything useful or worth selling.
+Last year, I started joining the This Agile Life podcast. I enjoy it. I’m hoping to continue with that, and possibly doing some podcasting about Ruby and Rails.
+I’m going to attempt to give a presentation at a conference. I often give presentations at local groups, but haven’t addressed a larger audience. I’ve got a few ideas rattling around, and will see if I can turn them into presentations worthy of a larger conference.
+What’s your Open Source resolution?
+Web Development, Ruby on Rails, Open Source
+Today I was informed that I’ve been impeding progress on our team.
+This was somewhat shocking, since I feel like I’m always pushing
+forward to make our team and myself better.
Like most anyone, my initial reaction to criticism was defensiveness.
+I don’t handle criticism well. (You might find that hard to believe,
+after reading the rest of this post. Maybe it’s just the confrontation
+part I don’t handle well.) Thankfully the blow was softened somewhat,
+because the person providing the criticism didn’t tell me directly —
+they told Amos, a trusted colleague of mine. Amos then passed it on to
+me. I’m grateful for that — this is the best way for me to have received
+that criticism.
What I did next is the astonishing thing. I swallowed my pride for a
+minute. Not an easy thing for me to do, for all the usual reasons, and
+more. I decided to address the problem head on. If someone was telling
+someone else that I was causing some sort of a problem, then even that
+perception was a problem that I needed to address. So I decided to hold
+a retrospective for myself. Retrospectives are the way Agile teams address
+problems and improve how they work. If it would work for a team, I figured
+it should work for an individual.
I’d held retrospectives by myself before. Before I even knew about
+retrospectives, I’d taken some time to assess how I had done things
+on a couple of projects I had worked on as an independent contractor. But
+those were about technical decisions I had made and processes I had
+followed. This one would be different. This one was about a personal
+shortcoming, an action of mine that had caused some harm. This one
+involved feelings and emotions.
So I asked Amos to facilitate my one-person retro. We’d both done a lot
+of retrospectives, but neither one of us had done anything like this before.
+We had a bit of trouble getting started. We didn’t have any details
+about why the anonymous person felt the way he felt. So it was hard
+to address something that nebulous. So I asked Amos if he could follow
+up with the person. Luckily, the person was online and able to respond
+in real time.
So we talked things through some. We went on some tangents. We made some
+progress — things that I could write down as take-aways and action items.
+We got off-topic again, and then came back to it. Then Amos decided to
+play The Why Game. This worked amazingly well. It helped me to find the
+root reasons why I was holding back change. Basically I’m afraid of
+failure. Going deeper, we looked into why I’m afraid of failure. This
+line of inquiry was particularly effective. Hopefully it’ll be enough for
+me to stop being an impediment to change. Here are my notes / take-aways:
At first, I thought that I’d never heard of anyone doing anything like
+this. But then I recalled that I’d heard about somewhere that everyone
+does this, with their whole team. That would be hard. I’d have to
+trust everyone in the room.
But I would recommend this for anyone that can pull it off. It’s hard,
+but it has a large payoff. Just like a team retrospective, it feels good
+making this kind of breakthrough, and knowing that just spending that
+little amount of time has made me a better person. (Mine took about an hour.)
+I think the hardest part is finding someone (or a group of people) you
+trust to be your facilitator.
I’ve decided to call this thing an introspective. A retrospective is
+about looking back. This is about looking inward. I’d be interested to
+find out who is doing this kind of thing. Does it have a commonly accepted
+name? How does it work? What techniques work best? If you’ve got any answers or ideas, please comment below, or tweet me @CraigBuchek.
So thank you to that anonymous person. Your way of addressing this was
+probably more effective than you could have imagined that it might be.
+I hope that this exercise will help me make the changes required, to make
+me a better person, and help the team become the best that we can be.
Amos has written up his thoughts on the introspective.
+Web Development, Ruby on Rails, Open Source
+It’s challenging to test Rails custom validators.
+I recently had to write a validator to require that an entered date is before or after a specified date.
+It didn’t seem like writing the validator would be too difficult – I’ve written custom validators before, and date comparisons aren’t all that tricky. But when it came time to write the tests, I ran into several issues. And since I always try to follow TDD / test-first, I was blocked before I even began.
+The biggest issue was the ActiveModel::EachValidator#validates_each API. It’s definitely not a well-designed API. You write your validator as a subclass, overriding validates_each. The method takes a model object, the name of the attribute of the model being tested, and the value of that attribute. You can also get the options passed to the custom validator via the options method. To perform a validation, you have to update the model’s errors hash.
The big flaw in the API is that instead of returning a result, you have to update the model. This needlessly couples the model and the validator. And it violates the Single Responsibility Principle — it has to determine validity of the field, and it has to update the errors hash of the model. This is not conducive to testing. Testing this method requires testing that the side-effect has taken place in the collaborator (model), which means it’s not really a unit test any more.
So to make it easier to unit test the validator, I broke the coupling by breaking it into 2 pieces, one for each responsibility. I moved the responsibility for determining validity to a separate method, which I called errors_for. It returns a hash of the errors found. This simplified the validates_each method to simply take the result of errors_for and update the errors hash of the model:
def validate_each(record, attribute_name, attribute_value) + record.errors[attribute_name].concat(errors_for(attribute_value, options)) +end+
This made it much easier to unit test the errors_for method. This method doesn’t even need to know about the model — only about the value of the attribute we’re trying to validate. We simply pass in the attribute’s value and the options.
So we could write the tests without even pulling in ActiveRecord or any models:
+describe DateValidator do
+ let(:validator) { DateValidator.new(attributes: :attribute_name) }
+ let(:errors) { validator.errors_for(attribute_value, validation_options) }
+
+ describe 'when attribute value is NOT a valid date' do
+ let(:attribute_value) { 'not a valid date' }
+ it { errors.must_include 'is not a valid date' }
+ end
+
+ describe 'when attribute value IS a valid date' do
+ let(:attribute_value) { Date.parse('2013-12-11') }
+ it { errors.must_be :empty? }
+ end
+end
+And the errors_for method looked something like this:
def errors_for(attribute_value, options) + unless attribute_value.is_a?(Date) + return [options.fetch(:message, "is not a valid date")] + end + [] +end+
Integration testing can also be a bit of a challenge. I recommend following the example from this Stack Overflow answer. Basically, create a minimal model object that contains the field and the validation. Then test that the model behaves like you expect with different values and validations.
+Web Development, Ruby on Rails, Open Source
+I’m considering buying a chording keyer. A keyer is a 1-handed text input device. Chording means that you can hit more than 1 key at a time. I’ve been interested in these for a long time actually. They’ve been popular in the wearable computing (“cyborg”) field, but never caught on anywhere else. I’ve always thought that 1-handed chording keyer would be a great input device to use with a cell phone. It’d be even better with a heads-up display like the Google Glass.
+There are quite a few chording keyers available. It doesn’t appear that any will meet exactly what I’m really looking for, but I might take the leap anyway. It should be a hand-held device. I really want a Bluetooth device, so I can use it with a computer, phone, or tablet. Below are the ones I’m considering.
+The Twiddler has been around quite a while, as probably the main commercially available keyer for wearable computing. There was a time that it was unavailable, but there’s a new version available from HandyKey now. It’s $200 ($220 Canadian), and comes in only USB.
+The Twiddler looks like a small TV remote. The current version (2.1) has 4 thumb keys, a thumb joystick (for mouse), and 12 small finger keys. It has good community support, including an alternate chord layout.
+In10did has been trying to bring out a few variations of their devices. The Decatxt looks like a pack of cigarettes, with 8 keys on the front and 2 thumb keys. It can be used with 1 or 2 hands. All letters can be typed with 1 finger or 1 thumb and 1 finger.
+The Decatxt has USB and Bluetooth models, but I’m unable to find pricing or a way to buy one. It looks like there have been no updates for over a year, so I’m concerned that this is going to be vaporware.
+The CyKey is based on the Microwriter, which goes back to the early 1980s. The Microwriter was a desktop-based device, but it looks like the CyKey might be able to be used as a hand-held device. It has 9 buttons on the face, arranged in 3 groups of 3 buttons.
+The CyKey is $125 (£75) and works over InfraRed connected to USB. A Bluetooth model is supposedly in the works.
+The EkaPad is like a cross between the Decatxt and the Twiddler. It has 12 buttons on the face, but no thumb keys. It’s got a nice well-thought-out design that looks quite ergonomic.
+The EkaPad is $150, available in USB only. A desktop holder is available to hold it upright, or it can be used hand-held.
+The FrogPad is meant to be used on a flat surface only. It looks kind of like a third of a laptop keyboard. It’s got 15 regular keys and 5 modifier keys. Only 1 key and 1 modifier can be chorded. Right-handed and left-handed models are available, with USB connectivity.
+The FrogPad2 was recently announced, replacing the original FrogPad. It switches to standard desktop-style keys, and adds some more keys along the top. It supports USB On-the-Go and Bluetooth. I’m not really interested in this model with its regular keys, but it doesn’t appear that the original version is being made any longer. The new models are priced at $200. I believe the old models were $150.
+The Chordite looks the most promising, but it’s only a concept with some DIY prototypes. It’s a hand-held device, with 2 buttons on each of the 4 fingers — one activated by the distal phalanx and the other by the middle phalanx. This initially sounds like it would be difficult to press 2 different buttons with 1 finger, but I think the way they’re positioned would make it actually work really well.
+The septambic keyer is another DIY concept, hand-built and used by wearable computing folks. It’s fitted to your palm, and you squeeze your fingers toward a fist to activate the buttons. There’s one button for each of the 4 fingers, and 3 for the thumb.
+The Clove 2 is a Bluetooth-enabled glove with 5 buttons — 1 for each finger. It’s another do-it-yourself project.
+I found an interesting project called ASETNIOP that allows chording on a standard Qwerty keyboard. (Assuming the keyboard supports multi-key roll-over well enough. Most keyboards should work.) It’s got a really nice online interactive tutorial. You basically chord with the 8 home-row keys, plus the spacebar.
+For Android, a program called GKOS for Android uses multi-touch with 1 or 2 button presses. The buttons are different sizes, depending on their frequency. I like this concept, but I don’t think the implementation is quite ready for production.
+I also found an app for iOS called Nintype that is a combination between Swype and a chording keyer.
+I think I’m going to try the Twiddler. If I find the concept to be a good one, hopefully I’ll build myself a Chordite (or have someone build one for me).
+I’m also going to play with implementing some of the ideas from ASETNIOP, using KeyRemap4MacBook.
+I created a Ruby gem recently, called includable-activerecord. It’s pretty small, but I thought I might explain why I created it, and discuss its implementation.
+When you use ActiveRecord, you normally include it in your model like this:
+class User < ActiveRecord::Base + # ... +end+
Your User class is inheriting from the ActiveRecord::Base class. This is class-based inheritance, also called “classical” inheritance. (That’s “classical” as in “class”, not as a synonym for “traditional”.) Class-based inheritance represents an “is-a” relationship. So we’re saying that a user is an ActiveRecord base. Another way to say this is that User is a subclass of ActiveRecord::Base.
+
+There are a few problems with this. First, what is a “base”? The name was chosen because it’s a base class. But just like we don’t give factory classes names like UserFactory (at least not in Ruby), we shouldn’t name base classes Base.
I suppose that we’re trying to say that this is an ActiveRecord model. That sounds fine at first glance — this is our model for users. But what if we also want to say that a user is a person? Ruby doesn’t allow inheriting from multiple classes. Now we have to choose whether to inherit from ActiveRecord::Base or Person. Person makes more sense, because it fills the “is-a” rule better. Class inheritance is intended for a hierarchical “is-a” relationship, such as “a user is a person”, or “a circle is a shape”. But since ActiveRecord::Base is a base class, we have to use it as our base class.
We could work around this problem by subclassing Person from ActiveRecord::Base and then subclassing User from Person. That’s fine if Person is also a model that we store in the database. But if that’s not the case, then we have a problem.
Mixins
+Ruby provides another way of implementing inheritance — mixins. We often don’t think of this as an inheritance model, but it really is. When we include a module, that module gets added to the class’s ancestor chain. We can mix in as many modules as we want.
+Mixins indicate more of an “acts like” relationship than an “is-a” relationship. It’s for shared behavior between classes that don’t have a hierarchical relationship. For example, when we mix in the Enumerable module, we’re saying that we want our class to act like other classes that include Enumerable. That sounds more like what we want ActiveRecord to be. We want our user model to behave like other ActiveRecord models, in the way that they can persist to a database.
But ActiveRecord doesn’t support that. Almost all the other Ruby ORMs do; as we’ve shown above, this is for good reasons.
+So I decided to see if I could implement the equivalent of the ActiveRecord::Base class as a module that could be mixed into model classes. I decided to call my mixin module ActiveRecord::Model, because classes that mix it in will behave as ActiveRecord models.
It turns out that ActiveRecord::Base is a pretty complex class. It includes and extends a lot of other modules. Luckily, as of ActiveRecord 4.0, that’s all the code it includes.
The module only defines a single class method, included. This is one of Ruby’s many hook methods. It gets called when the module in question gets included in another module, and receives that other model as its argument. All we need to have this method do is to include everything that ActiveRecord::Base includes, and extend everything that ActiveRecord::Base extends. Ruby provides a method that’s defined on all classes, called included_modules, which we can use to get the list of everything that’s included in ActiveRecord::Base. Unfortunately, there’s no equivalent list of extended_modules. But a quick search on Stack Overflow found an implementation of extended_modules that we could use.
So with a bit of magic (i.e. hooks and meta-programming), we can get the lists of constituent modules from the ActiveRecord::Base class, and include them in our ActiveRecord::Model module.
So with all that, we can now include the includable-activerecord gem and mix it in, with all the advantages that provides:
+class User + include ActiveRecord::Model + # ... +end+
It was exciting to be able to make this work. Since I wrote it as a proof of concept, I haven’t written any tests yet. But it seems to be working just fine. The main thing I really need to look into is making sure that plugins that extend ActiveRecord::Base from their own code will still work. I’m pretty sure this will work out of the box, because the ActiveRecord::Model.included doesn’t run until the model class is loaded, and that happens after those plugins have initialized themselves.
I facilitated our team retrospective this morning. I felt like we made a little forward progress, but not as much as I would have liked. But it really brought one thing to the forefront of my thoughts today — empathy gained through communication.
+We have a pretty large team by Agile standards — we had 20 people in our retro: 16 developers, 3 QA folks, and 1 manager. Out of those, only about 5 or 6 speak up regularly. I recently sent out a survey to the team, trying to get feedback on how we could improve our retros. A couple of the questions tried to get a feel for why people aren’t speaking up more. Only about half the people responded, and the answers didn’t really answer my question as well as I had hoped.
+So on Amos‘s suggestion, we did the Safety Check exercise. We got a good set of answers to why people don’t feel safe. About half of the answers were about the fear of looking stupid in front of other people. About half of those mentioned the manager — they’re worried they might get in trouble for what they say. We talked some about fear and how it’s more often than not misplaced. And that the worst consequences are usually not as bad as you might think. But then we got to the crux of the problem — there’s not enough trust amongst the team, and especially between the team members and the manager.
+About half of our team is new (within the past 6 months) — including the manager. While the developers have made some good progress building trust amongst each other, we haven’t had as much time with the manager to build trust between him and the rest of the team. So the lack of trust isn’t at all surprising.
+Honestly, I already knew we had trust issues, and wanted to address them, but needed a way to lead the team to that same realization. With this exercise driving out the issue, we were then able to have a conversation about trust. The conversation was pretty good. We got more voices to contribute than probably any other topic we’d previously covered. (I was disappointed that the manager kept quiet though. I later found that he was trying to mitigate people’s fears by keeping quiet, but I urged him to contribute more in the future.)
+But one point really stood out in my mind — a point of view that I hadn’t previously thought much about. Lauren, one of our QA analysts, pointed out that most human communication is non-verbal. We give tons of cues via body language, facial expressions, eye contact, tone of voice, even posture. I don’t recall if Lauren said it explicitly, but she pointed out that these cues build empathy between the speakers. She encouraged us to use more voice chat and video chat, as opposed to IRC text chat, because it would create more empathy between the people communicating, which would lead to more trust.
+I spent most of the rest of the day talking to people on the phone or via Google Hangouts voice. And every single time, I consciously noticed that I was gaining empathy for the person I was speaking with. I assume (and hope) that that’s working both ways. I suppose that it’s always been happening, but I never really noticed it.
+I’ve heard a lot of talk about empathy among Agile practitioners lately. It’s been mentioned on the Ruby Rogues podcast, and Angela Harms has been preaching it for years. I already understood how important it is. But until today, I didn’t really feel it happening.
+So if you’re looking to build trust with someone, spend some time talking with them. Preferably in person, but if that’s not possible, seriously consider video or voice modes of communication, instead of sending an email or an instant message.
++
I’m considering moving away from WordPress, for a couple reasons:
+Now that I’m starting to actually blog consistently, it makes sense to change. But before I move to something different, I want to be sure that I find all the features that I need. This post is my thought process about what I want.
+I’ve been playing with Jekyll lately, using it to generate a simple static site that can be updated easily. It’s pretty nice, and pretty easy to use. Something based on Jekyll would work well. The trickiest part will be figuring out how to manage comments. Or maybe I’ll just have to learn to live more minimally.
+Octopress is the obvious candidate. It fits most of my needs and wants. Most likely I’ll write my own commenting engine and add it to my Octopress template.
+The only other candidate that I’ve found is Ghost. It’s written in JavaScript and runs on Node. I don’t find Node to be that compelling, but the templates look great, and it’s designed for coding blogs.
+I’ll probably take a quick look at Droplets, too. It’s written in PHP, but seems to fit my other requirements.
+Unfortunately, that seems to be all there is in this space. Maybe I need to investigate more. Or maybe Octopress just has the static blog generation marked cornered. Either way, I’ll probably change my blogging software in the next month or two. Wish me luck!
++
Web Development, Ruby on Rails, Open Source
+I’m considering moving away from WordPress, for a couple reasons:
+Now that I’m starting to actually blog consistently, it makes sense to change. But before I move to something different, I want to be sure that I find all the features that I need. This post is my thought process about what I want.
+I’ve been playing with Jekyll lately, using it to generate a simple static site that can be updated easily. It’s pretty nice, and pretty easy to use. Something based on Jekyll would work well. The trickiest part will be figuring out how to manage comments. Or maybe I’ll just have to learn to live more minimally.
+Octopress is the obvious candidate. It fits most of my needs and wants. Most likely I’ll write my own commenting engine and add it to my Octopress template.
+The only other candidate that I’ve found is Ghost. It’s written in JavaScript and runs on Node. I don’t find Node to be that compelling, but the templates look great, and it’s designed for coding blogs.
+I’ll probably take a quick look at Droplets, too. It’s written in PHP, but seems to fit my other requirements.
+Unfortunately, that seems to be all there is in this space. Maybe I need to investigate more. Or maybe Octopress just has the static blog generation marked cornered. Either way, I’ll probably change my blogging software in the next month or two. Wish me luck!
++
Web Development, Ruby on Rails, Open Source
+I facilitated our team retrospective this morning. I felt like we made a little forward progress, but not as much as I would have liked. But it really brought one thing to the forefront of my thoughts today — empathy gained through communication.
+We have a pretty large team by Agile standards — we had 20 people in our retro: 16 developers, 3 QA folks, and 1 manager. Out of those, only about 5 or 6 speak up regularly. I recently sent out a survey to the team, trying to get feedback on how we could improve our retros. A couple of the questions tried to get a feel for why people aren’t speaking up more. Only about half the people responded, and the answers didn’t really answer my question as well as I had hoped.
+So on Amos‘s suggestion, we did the Safety Check exercise. We got a good set of answers to why people don’t feel safe. About half of the answers were about the fear of looking stupid in front of other people. About half of those mentioned the manager — they’re worried they might get in trouble for what they say. We talked some about fear and how it’s more often than not misplaced. And that the worst consequences are usually not as bad as you might think. But then we got to the crux of the problem — there’s not enough trust amongst the team, and especially between the team members and the manager.
+About half of our team is new (within the past 6 months) — including the manager. While the developers have made some good progress building trust amongst each other, we haven’t had as much time with the manager to build trust between him and the rest of the team. So the lack of trust isn’t at all surprising.
+Honestly, I already knew we had trust issues, and wanted to address them, but needed a way to lead the team to that same realization. With this exercise driving out the issue, we were then able to have a conversation about trust. The conversation was pretty good. We got more voices to contribute than probably any other topic we’d previously covered. (I was disappointed that the manager kept quiet though. I later found that he was trying to mitigate people’s fears by keeping quiet, but I urged him to contribute more in the future.)
+But one point really stood out in my mind — a point of view that I hadn’t previously thought much about. Lauren, one of our QA analysts, pointed out that most human communication is non-verbal. We give tons of cues via body language, facial expressions, eye contact, tone of voice, even posture. I don’t recall if Lauren said it explicitly, but she pointed out that these cues build empathy between the speakers. She encouraged us to use more voice chat and video chat, as opposed to IRC text chat, because it would create more empathy between the people communicating, which would lead to more trust.
+I spent most of the rest of the day talking to people on the phone or via Google Hangouts voice. And every single time, I consciously noticed that I was gaining empathy for the person I was speaking with. I assume (and hope) that that’s working both ways. I suppose that it’s always been happening, but I never really noticed it.
+I’ve heard a lot of talk about empathy among Agile practitioners lately. It’s been mentioned on the Ruby Rogues podcast, and Angela Harms has been preaching it for years. I already understood how important it is. But until today, I didn’t really feel it happening.
+So if you’re looking to build trust with someone, spend some time talking with them. Preferably in person, but if that’s not possible, seriously consider video or voice modes of communication, instead of sending an email or an instant message.
++
Web Development, Ruby on Rails, Open Source
+I created a Ruby gem recently, called includable-activerecord. It’s pretty small, but I thought I might explain why I created it, and discuss its implementation.
+When you use ActiveRecord, you normally include it in your model like this:
+class User < ActiveRecord::Base + # ... +end+
Your User class is inheriting from the ActiveRecord::Base class. This is class-based inheritance, also called “classical” inheritance. (That’s “classical” as in “class”, not as a synonym for “traditional”.) Class-based inheritance represents an “is-a” relationship. So we’re saying that a user is an ActiveRecord base. Another way to say this is that User is a subclass of ActiveRecord::Base.
+
+There are a few problems with this. First, what is a “base”? The name was chosen because it’s a base class. But just like we don’t give factory classes names like UserFactory (at least not in Ruby), we shouldn’t name base classes Base.
I suppose that we’re trying to say that this is an ActiveRecord model. That sounds fine at first glance — this is our model for users. But what if we also want to say that a user is a person? Ruby doesn’t allow inheriting from multiple classes. Now we have to choose whether to inherit from ActiveRecord::Base or Person. Person makes more sense, because it fills the “is-a” rule better. Class inheritance is intended for a hierarchical “is-a” relationship, such as “a user is a person”, or “a circle is a shape”. But since ActiveRecord::Base is a base class, we have to use it as our base class.
We could work around this problem by subclassing Person from ActiveRecord::Base and then subclassing User from Person. That’s fine if Person is also a model that we store in the database. But if that’s not the case, then we have a problem.
Mixins
+Ruby provides another way of implementing inheritance — mixins. We often don’t think of this as an inheritance model, but it really is. When we include a module, that module gets added to the class’s ancestor chain. We can mix in as many modules as we want.
+Mixins indicate more of an “acts like” relationship than an “is-a” relationship. It’s for shared behavior between classes that don’t have a hierarchical relationship. For example, when we mix in the Enumerable module, we’re saying that we want our class to act like other classes that include Enumerable. That sounds more like what we want ActiveRecord to be. We want our user model to behave like other ActiveRecord models, in the way that they can persist to a database.
But ActiveRecord doesn’t support that. Almost all the other Ruby ORMs do; as we’ve shown above, this is for good reasons.
+So I decided to see if I could implement the equivalent of the ActiveRecord::Base class as a module that could be mixed into model classes. I decided to call my mixin module ActiveRecord::Model, because classes that mix it in will behave as ActiveRecord models.
It turns out that ActiveRecord::Base is a pretty complex class. It includes and extends a lot of other modules. Luckily, as of ActiveRecord 4.0, that’s all the code it includes.
The module only defines a single class method, included. This is one of Ruby’s many hook methods. It gets called when the module in question gets included in another module, and receives that other model as its argument. All we need to have this method do is to include everything that ActiveRecord::Base includes, and extend everything that ActiveRecord::Base extends. Ruby provides a method that’s defined on all classes, called included_modules, which we can use to get the list of everything that’s included in ActiveRecord::Base. Unfortunately, there’s no equivalent list of extended_modules. But a quick search on Stack Overflow found an implementation of extended_modules that we could use.
So with a bit of magic (i.e. hooks and meta-programming), we can get the lists of constituent modules from the ActiveRecord::Base class, and include them in our ActiveRecord::Model module.
So with all that, we can now include the includable-activerecord gem and mix it in, with all the advantages that provides:
+class User + include ActiveRecord::Model + # ... +end+
It was exciting to be able to make this work. Since I wrote it as a proof of concept, I haven’t written any tests yet. But it seems to be working just fine. The main thing I really need to look into is making sure that plugins that extend ActiveRecord::Base from their own code will still work. I’m pretty sure this will work out of the box, because the ActiveRecord::Model.included doesn’t run until the model class is loaded, and that happens after those plugins have initialized themselves.
Web Development, Ruby on Rails, Open Source
+I’m considering buying a chording keyer. A keyer is a 1-handed text input device. Chording means that you can hit more than 1 key at a time. I’ve been interested in these for a long time actually. They’ve been popular in the wearable computing (“cyborg”) field, but never caught on anywhere else. I’ve always thought that 1-handed chording keyer would be a great input device to use with a cell phone. It’d be even better with a heads-up display like the Google Glass.
+There are quite a few chording keyers available. It doesn’t appear that any will meet exactly what I’m really looking for, but I might take the leap anyway. It should be a hand-held device. I really want a Bluetooth device, so I can use it with a computer, phone, or tablet. Below are the ones I’m considering.
+The Twiddler has been around quite a while, as probably the main commercially available keyer for wearable computing. There was a time that it was unavailable, but there’s a new version available from HandyKey now. It’s $200 ($220 Canadian), and comes in only USB.
+The Twiddler looks like a small TV remote. The current version (2.1) has 4 thumb keys, a thumb joystick (for mouse), and 12 small finger keys. It has good community support, including an alternate chord layout.
+In10did has been trying to bring out a few variations of their devices. The Decatxt looks like a pack of cigarettes, with 8 keys on the front and 2 thumb keys. It can be used with 1 or 2 hands. All letters can be typed with 1 finger or 1 thumb and 1 finger.
+The Decatxt has USB and Bluetooth models, but I’m unable to find pricing or a way to buy one. It looks like there have been no updates for over a year, so I’m concerned that this is going to be vaporware.
+The CyKey is based on the Microwriter, which goes back to the early 1980s. The Microwriter was a desktop-based device, but it looks like the CyKey might be able to be used as a hand-held device. It has 9 buttons on the face, arranged in 3 groups of 3 buttons.
+The CyKey is $125 (£75) and works over InfraRed connected to USB. A Bluetooth model is supposedly in the works.
+The EkaPad is like a cross between the Decatxt and the Twiddler. It has 12 buttons on the face, but no thumb keys. It’s got a nice well-thought-out design that looks quite ergonomic.
+The EkaPad is $150, available in USB only. A desktop holder is available to hold it upright, or it can be used hand-held.
+The FrogPad is meant to be used on a flat surface only. It looks kind of like a third of a laptop keyboard. It’s got 15 regular keys and 5 modifier keys. Only 1 key and 1 modifier can be chorded. Right-handed and left-handed models are available, with USB connectivity.
+The FrogPad2 was recently announced, replacing the original FrogPad. It switches to standard desktop-style keys, and adds some more keys along the top. It supports USB On-the-Go and Bluetooth. I’m not really interested in this model with its regular keys, but it doesn’t appear that the original version is being made any longer. The new models are priced at $200. I believe the old models were $150.
+The Chordite looks the most promising, but it’s only a concept with some DIY prototypes. It’s a hand-held device, with 2 buttons on each of the 4 fingers — one activated by the distal phalanx and the other by the middle phalanx. This initially sounds like it would be difficult to press 2 different buttons with 1 finger, but I think the way they’re positioned would make it actually work really well.
+The septambic keyer is another DIY concept, hand-built and used by wearable computing folks. It’s fitted to your palm, and you squeeze your fingers toward a fist to activate the buttons. There’s one button for each of the 4 fingers, and 3 for the thumb.
+The Clove 2 is a Bluetooth-enabled glove with 5 buttons — 1 for each finger. It’s another do-it-yourself project.
+I found an interesting project called ASETNIOP that allows chording on a standard Qwerty keyboard. (Assuming the keyboard supports multi-key roll-over well enough. Most keyboards should work.) It’s got a really nice online interactive tutorial. You basically chord with the 8 home-row keys, plus the spacebar.
+For Android, a program called GKOS for Android uses multi-touch with 1 or 2 button presses. The buttons are different sizes, depending on their frequency. I like this concept, but I don’t think the implementation is quite ready for production.
+I also found an app for iOS called Nintype that is a combination between Swype and a chording keyer.
+I think I’m going to try the Twiddler. If I find the concept to be a good one, hopefully I’ll build myself a Chordite (or have someone build one for me).
+I’m also going to play with implementing some of the ideas from ASETNIOP, using KeyRemap4MacBook.
+Frogpad2 failed recently (see https://www.facebook.com/profile.php?id=105714169451329), but there is another possibility using freeware: http://www.autohotkey.com/ and scripts (easy adaptable!?):
+half querty: http://www.autohotkey.com/board/topic/1257-half-qwerty-one-handed-typing/
+frogpad: https://github.com/clarkm/dupepad/blob/master/frogpad.ahk
+Will be trying soon…
The In10did DecaTxt is available on eBay and Amazon now. I ordered one recently and had it shipped over from the USA, which was a bit expensive when customs fees are added. It arrived yesterday morning and I plugged it in after arriving home from work. Sadly, it appears to do nothing whatsoever. Not sure if this model is DOA (but surely they test them?), or what. If I can get it to work, or get a replacement shipped, I’ll try to record my WPM with the device every day for a couple of weeks, to see where the improvement curve starts to taper off.
+Update: It works just fine! Actually the problem was that my laptop only supports Bluetooth 3.0, but at least 4.0 is needed. It also wasn’t discoverable by my phone because Android 4.3 or newer is needed. Tested it on a newer phone and on my work PC and it connected straight away. Looking forward to trying it on an Android tablet and measuring my speed over a few weeks.
+I’m glad you were able to get the DecaTxt connected and working. We are planning for a second version with micro USB rather than mini and a few software changes like being able to shut off the Bluetooth antenna. I’d love to get your feedback if you would email me and offer suggestions.
+Thanks,
+Wayne
Web Development, Ruby on Rails, Open Source
+I’ve decided to design and implement my own programming language, and call it Brilliant.
+I’ve been interested in programming languages and linguistics almost as long as I’ve been using computers. I’ve long thought that if I ever go back to college, it’s likely that I’ll concentrate on programming languages as a specialty.
+My recent discovery and involvement with the Crystal programming language has gotten me excited about new language ideas. It’s also helped me realize that implementing a language myself is feasible, and that there’s no better time to start than now.
+For now, the Brilliant implementation doesn’t let you do much more than “Hello World”. But you gotta start somewhere. So this article isn’t really “Introducing Brilliant” so much as the start of a series of articles on its design and implementation.
+I wanted to use a PEG (parsing expression grammar) parser for several reasons. For one, they seem to have gained a lot of popularity in the past few years. Also, PEGs cannot be ambiguous, which can solve a few difficult problems, such as the “dangling else“. Perhaps my favorite feature of PEG grammars is that you don’t need a separate tokenizer (lexer). This provides a nice advantage in that we can use keywords like “class” as variables, as long as they’re not used in a place where the keyword would make sense.
So knowing that I wanted to use a PEG, I had to find a PEG parser. I kind of wanted to use ANTLR, which has been a leading parser for many years. But the PEG seems to be new to version 4, and I couldn’t find any Ruby bindings for version 4. Treetop seems to be the most popular parser for Ruby, but I found the EBNF format that Rattler uses to be more to my taste. I think the fact that it’s newer also gives it a few advantages, having had a chance to learn some lessons from Treetop.
+I thought about using the Rubinius VM, but decided to go with LLVM, mainly since it has slightly better docs for Ruby, and because it’s what Crystal uses. Also, it’s pretty easy to get it to compile to a binary executable or run in a JIT. In the future, I might consider switching to the Rubinius VM, the Erlang VM, or the Perl 6 VM (Parrot). But for now, I like the idea of being able to compile to a binary and easily interface with C, just like Crystal.
+My main goal is to have fun playing around with language ideas.
+I’ve found a really great language in Ruby, so I’ll be using it as a starting point. But Ruby does have its faults. In some ways, I want to answer the question “what would Ruby look like if we designed it today?”.
+But I also want to explore other ideas. What if objects defaulted to immutable? What if functions and methods were assumed to be pure by default? Might it be possible to infer the purity of a function or method? (If so, we could automatically memoize them.) Can we make creating an actor as easy as creating an object?
+I’ll also be looking at ideas from other programming languages. Could we get some of the benefits of Haskell’s purity without having to do somersaults to do IO? Could we mix Python’s indentation style scoping with brace style or begin/end style? Could we integrate Icon’s ideas about success and failure (goal-directed execution)? What interesting features can we pull from Ada, Io, CoffeeScript, Crystal, Rubinius, Perl 6, etc.?
+
I’m not so much as interested in cutting-edge features, as in features that can be easily used by the average programmer. More importantly, I’m interested in how features interact with each other, so they fit well together to create a whole that’s greater than the sum of the parts.
+I wanted to name my programming language “Fermat”. I’ve long been intrigued by Fermat’s Last Theorem, and Fermat’s Little Theorem is important in number theory. Unfortunately, there’s already a computer algebra system with that name.
+So I decided to find a name in the same vein as “Ruby” and “Crystal”. I looked at the Wikipedia page for “gemstones” for some inspiration. A lot of the names of gemstones are already taken. I considered some obscure gemstones, but saw the word “brilliant” and thought it was decent. It’s not the name of another gemstone, but still evokes some similarity to Ruby and Crystal.
+So that’s the name for now. Perhaps I’ll decide to change it at some point in the future, but I needed a name for the project, as well as a file extension for source code files. I chose “bril” for that. I suppose “br” would be a better choice. Perhaps I’ll change that before the next article in this series.
I hope to work on Brilliant every once in a while. I expect it’ll take a couple years before it’s really very useful.
+When I do add a major feature, I’ll be certain to blog about it. I’ve got tons of ideas strewn about in various files. It would be great to get them organized and published —and even better to get them implemented.
+I don’t believe that estimation should be part of any Agile practice.
+One of our managers recently mentioned that we hadn’t met the “contract” that we had “committed” to in our last iteration. This was complete nonsense, because A) we hadn’t made any such commitments, and B) we completed many more story points than the previous iterations (and without inflating story points).
+
But her language made me come to several realizations. First and foremost, estimates are contracts. Sure, they’re not supposed to be treated as commitments, but they almost always are. And what does the Agile Manifesto say about this? It says that we should value customer collaboration over contract negotiation, and responding to change over following a plan. So it’s pretty clear that treating estimates as commitments is completely counter to the Agile values.
+Why does this matter? What benefits do the Agile values bring us? I think the biggest benefit they bring is changing the way that we work, so that we can better deliver value to our customers. Without Agile, we’d just keep working the way we’ve always done things. And that didn’t seem to be working out so well. If we follow the Agile values and principles, at least we’ll have a fighting chance of improving our ability to deliver value.
+Ask yourself — have you ever seen a software development project that was on time and on budget? Where the estimates were spot-on? Of course not. For one, we’re terrible at estimating. For another, our plans change — either from external factors, or from what we learn as we go.
+To me, Agile is also about facing reality — and embracing it. It realizes that we’re terrible at estimating. It realizes that plans change. Most Agile methodologies have some tricks to counteract Hofstadter’s law. Generally, we use relative story points instead of hours, and then use an empirical factor to convert points to hours.
+When this works, it is better than any other estimation I’ve ever seen. But it doesn’t work very often. People have trouble with relative estimation. How do you set the basis for what a point means without relating it to actual hours? Affinity estimation could work, but then you have to remember what the basis was. We’ve got a large distributed team, and when we tried this, we couldn’t all remember what the basis was.
+Since we couldn’t get affinity estimation to work, we tried changing to perfect hours (only powers of 2). But then people thought of them as time. When we took longer than the estimate on an individual story, managers and team members thought we were taking longer than we should have. So our estimates ended up causing problems.
+Managers want estimates so that they can have predictability. They want to know when new features will be available. Is there a better way to get what we need?
+I believe there’s a better way — prioritization. If you work on the most important thing first, then the most important thing will get done first. We should always be working on the next most important thing.
+What if there’s more than 1 thing that’s most important? Then you’ve failed. You’ve failed at logic if you can’t understand that only 1 thing can be most important. You’ve failed at prioritizing the customers’ needs. You’ve failed at project management.
+1. Why can’t you just tell us how long it will really take?
+Because we don’t know. Because we can’t know. This is the first time we’ve ever implemented the functionality you’ve asked for. If we’d done it before, we’d just use that existing code. As Glenn Vanderburg pointed out in his excellent talk on Software Engineering, we’re not building software, we’re architecting it.
+2. But we have to tell our customers what to expect.
+Why? Is the product so bad that you can’t keep customers around without leading them on with future enhancements? And why do customers need exact dates? A general roadmap telling them what the priorities for upcoming features should be sufficient.
+3. But we have to have messaging about new features.
+OK. Then send out that messaging once the feature has made it to Staging. Or even after it’s been rolled out to Production.
+4. But we’ve promised these new features to the customers by this date.
+Ah, so you’ve made promises to the customer that you don’t have control over. Have you ever heard of “under-promise and over-deliver”? That’s how you create happy customers. Yet you’ve done just the opposite, haven’t you? And then you want to blame someone else.
+Risk
+Estimates are risk. But the risk doesn’t come at the end, when the estimates are shown to be incorrect. The risk was in asking for the estimates in the first place, and placing trust in them. Don’t do it. Don’t promise things that you can’t be sure of.
+Embrace this reality. Embrace this uncertainty. Always focus on what’s most important. That’s how you make customers happy.
+There’s a tweet that I saw recently, with some simple advice for novice programmers:
++Slow down.
This is probably good advice for most programmers. Our team recently noticed that every time we try to rush things, we make mistakes. And the mistakes end up costing us more time than if we had just done things at our normal pace. Slowing down ensures that you do things right, and when you do things right, you end up with a higher-quality product.
+There are 2 types of code quality: internal and external. External code quality can be measured by how many bugs have been reported by customers. Internal code quality is harder to measure, but it mainly deals with the ability to change the code. When your internal quality is low, you’ve got lots of technical debt, and it’s harder to make changes.
+So when you try to write code quickly, code quality decreases, leading to a code base that takes more time to make changes to. Conversely, when you slow down, your code quality improves, and it becomes easier to make changes more quickly. So when writing code, slowing down in the short run leads to a speed-up in the long run.
+But writing code isn’t the only place where we try to speed up. On an Agile team, we’re always trying to improve the way we work — especially at the beginning stages of an Agile transformation. So we’re eager to make changes in our processes. But I’d urge you to slow down here as well.
+My colleague Amos and I frequently argue over pair switching. It’s funny, because we agree on everything except for 1 small detail. We both think pair switching is very important, to ensure that team members see more of what’s going on, to bring more ideas to each story, to prevent knowledge silos, and to encourage team ownership. Where we disagree is how long an ideal pairing session should last. I think pairs should switch every 2 hours, and he thinks 1 hour is ideal. I’ve seen teams reach the 1 hour pairing sessions successfully. But usually not without some pain and even often failing at the first attempt.
+There’s nothing inherently wrong with failing. But if you fail at something, you’re not likely to try again. After all, you should learn from your failures, right?
+So if you want your team to do something, you probably don’t want them to fail at it. If they fail, they won’t want to try a second time. That’s just human nature, and learning from failure. While you might think that they failed because they weren’t ready for the change yet, they’ll most likely think that they failed because this particular change won’t work for their situation. And they probably won’t know what to change when trying again, so they won’t try again.
+I’ve seen this over and over. Back when Linux was up-and-coming, when a consultant pushed a company into using Linux before they were ready for it, and it didn’t work out, that company was cautious about trying again. So instead of being on the leading edge of using Linux, or even the middle of the pack, they ended up more toward the trailing edge. Had they not been pushed, they would have gotten more benefit in the long run.
+So my advice in process improvement is the same as in programming: slow down. Take small steps toward what you think is the ideal. Make a small change, see how it works out, and adjust. As long as you’re still moving in the right direction, I believe you’ll move faster by taking small steps than by trying to make big leaps.
+Most of us don’t write very readable shell scripts. There are plenty of things we could do better, but today I want to talk about one in particular — burying the lede.
+The term “burying the lede” comes from the field of journalism. Here’s the Wiktionary definition:
++To begin a story with details of secondary importance to the reader while postponing more essential points or facts.
Like a good news article, code should tell a story. And the story should start with what’s most important. In the case of code, the most important information is the high-level functionality — a succinct summary of what the program does. In other words, write (and organize) the code top-down, as opposed to bottom-up.
+Unfortunately, shell script doesn’t make this easy. Due to the way shell scripts are interpreted, you can’t call a function until after you’ve defined it. This leads to most of us structuring our code like this:
+function do_something { ... }
+function do_something_else { ... }
+
+do_something
+do_something_else
+The problem with this is that the function definitions will likely take quite a few lines, and we won’t see what the top-level functionality is until we reach the end of the script.
+I’d like to propose a standard way to structure shell scripts to mitigate this issue. (I’m really only talking about shell scripts that have function definitions within them.) I’m sure I’ve seen a few scripts do this, but it’s not very common at all.
+My proposal is simple:
+function main {
+ do_something
+ do_something_else
+}
+function do_something { ... }
+function do_something_else { ... }
+
+main
+This structure lets us start with the lede. We describe the top-level functionality right away. Only then do we get to the secondary details. The name main makes it pretty clear that it contains the top-level functionality.
I’ve recently started writing my shell code like this, and I’m happy with the results. I’ve also started to use some other programming techniques in my shell scripts to improve readability: better naming, extracting more methods, and moving helper methods into separate files. It feels good to treat shell scripts like real code instead of just some stuff I’ve hacked together.
+PS. The WordPress theme I’m currently using (Twenty Eleven) also buries the lede — I can barely even see the title of the blog post on my screen without scrolling. I’m going to have to change that soon.
+I recently decided to start using Emacs again. I used it extensively from the early 1990s until the early 2000s. I pretty much stopped using it when I had a sysadmin job with no Emacs on the servers, and no ability to install it. With the rising popularity of tmux and tmate for remote pairing, and my dislike for vim’s modes, I decided to try going back to Emacs in the terminal.
+One thing I really want in a text editor is good cursor key support. Shifted cursor keys
+should select text, and Control+left and right should move by words. (Apple HIG says to use Option+left and right to move by words; most apps on Mac OS X seem to support both.) Things have worked this way on almost every text editor on every OS I’ve used — Amiga, DOS, Windows, NeXT, Mac, Motif, Gnome, KDE. It’s a part of the CUA standard that’s been in common usage on everything since the mid-1980s.
Enabling cursor keys in Emacs was pretty easy. I’ve decided to use Prelude to make getting started with Emacs easy. Emacs comes with the cursor keys enabled, but Prelude disables them. Undoing Prelude’s change is pretty easy:
+(setq prelude-guru nil)+
Trying to make shifted cursor keys work is where the trouble began. They work in the GUI version of Emacs, but not from the terminal. It turns out that the Mac Terminal doesn’t distinguish between cursor keys and shifted cursor keys in its default configuration. So I had to figure out how to configure key bindings in Terminal.
+That’s easy enough — they’re in the preferences. But what should I set them to? This took a lot of research. Terminal emulation and ANSI code sequences are obscure, complex, and inconsistent. I eventually found the info I needed. For starters, Shift+Right, Shift+Left, Shift+Home, and Shift+End are defined in the terminfo. The rest I was able to piece together from various sources around the Internet.
+I’m also trying to script my Mac configuration. So instead of manually adding all the keybindings in the Terminal preferences pane, I decided to write a script. Mac OS X does a decent job of allowing you to change preferences from the command line. For example, to always show the tab bar:
+defaults write -app Terminal ShowTabBar 1+
Easy enough, except for a couple problems. First, I had to figure out the obscure syntax used in the preferences for key codes. I was able to piece these together with some more Internet research. But the really big problem is that the keyboard bindings are 2 levels deep within a “dictionary” (hash map). And the defaults command doesn’t handle that. There are some obscure utilities that handle nested preferences, but they don’t work well with the preferences caching in Mac OS X 10.9 — a problem I ran into while testing.
So now I’m writing a utility in Python that does what the defaults command does, but that will handle nested dictionaries.
There’s a term for this process of having to solve one issue before you can solve another, and the issues get several layers deep. It’s called yak shaving.
+Here’s another good example:
+
I’m sure this will be the first of many posts about me yak shaving.
+Web Development, Ruby on Rails, Open Source
+I recently decided to start using Emacs again. I used it extensively from the early 1990s until the early 2000s. I pretty much stopped using it when I had a sysadmin job with no Emacs on the servers, and no ability to install it. With the rising popularity of tmux and tmate for remote pairing, and my dislike for vim’s modes, I decided to try going back to Emacs in the terminal.
+One thing I really want in a text editor is good cursor key support. Shifted cursor keys
+should select text, and Control+left and right should move by words. (Apple HIG says to use Option+left and right to move by words; most apps on Mac OS X seem to support both.) Things have worked this way on almost every text editor on every OS I’ve used — Amiga, DOS, Windows, NeXT, Mac, Motif, Gnome, KDE. It’s a part of the CUA standard that’s been in common usage on everything since the mid-1980s.
Enabling cursor keys in Emacs was pretty easy. I’ve decided to use Prelude to make getting started with Emacs easy. Emacs comes with the cursor keys enabled, but Prelude disables them. Undoing Prelude’s change is pretty easy:
+(setq prelude-guru nil)+
Trying to make shifted cursor keys work is where the trouble began. They work in the GUI version of Emacs, but not from the terminal. It turns out that the Mac Terminal doesn’t distinguish between cursor keys and shifted cursor keys in its default configuration. So I had to figure out how to configure key bindings in Terminal.
+That’s easy enough — they’re in the preferences. But what should I set them to? This took a lot of research. Terminal emulation and ANSI code sequences are obscure, complex, and inconsistent. I eventually found the info I needed. For starters, Shift+Right, Shift+Left, Shift+Home, and Shift+End are defined in the terminfo. The rest I was able to piece together from various sources around the Internet.
+I’m also trying to script my Mac configuration. So instead of manually adding all the keybindings in the Terminal preferences pane, I decided to write a script. Mac OS X does a decent job of allowing you to change preferences from the command line. For example, to always show the tab bar:
+defaults write -app Terminal ShowTabBar 1+
Easy enough, except for a couple problems. First, I had to figure out the obscure syntax used in the preferences for key codes. I was able to piece these together with some more Internet research. But the really big problem is that the keyboard bindings are 2 levels deep within a “dictionary” (hash map). And the defaults command doesn’t handle that. There are some obscure utilities that handle nested preferences, but they don’t work well with the preferences caching in Mac OS X 10.9 — a problem I ran into while testing.
So now I’m writing a utility in Python that does what the defaults command does, but that will handle nested dictionaries.
There’s a term for this process of having to solve one issue before you can solve another, and the issues get several layers deep. It’s called yak shaving.
+Here’s another good example:
+
I’m sure this will be the first of many posts about me yak shaving.
+Web Development, Ruby on Rails, Open Source
+Most of us don’t write very readable shell scripts. There are plenty of things we could do better, but today I want to talk about one in particular — burying the lede.
+The term “burying the lede” comes from the field of journalism. Here’s the Wiktionary definition:
++To begin a story with details of secondary importance to the reader while postponing more essential points or facts.
Like a good news article, code should tell a story. And the story should start with what’s most important. In the case of code, the most important information is the high-level functionality — a succinct summary of what the program does. In other words, write (and organize) the code top-down, as opposed to bottom-up.
+Unfortunately, shell script doesn’t make this easy. Due to the way shell scripts are interpreted, you can’t call a function until after you’ve defined it. This leads to most of us structuring our code like this:
+function do_something { ... }
+function do_something_else { ... }
+
+do_something
+do_something_else
+The problem with this is that the function definitions will likely take quite a few lines, and we won’t see what the top-level functionality is until we reach the end of the script.
+I’d like to propose a standard way to structure shell scripts to mitigate this issue. (I’m really only talking about shell scripts that have function definitions within them.) I’m sure I’ve seen a few scripts do this, but it’s not very common at all.
+My proposal is simple:
+function main {
+ do_something
+ do_something_else
+}
+function do_something { ... }
+function do_something_else { ... }
+
+main
+This structure lets us start with the lede. We describe the top-level functionality right away. Only then do we get to the secondary details. The name main makes it pretty clear that it contains the top-level functionality.
I’ve recently started writing my shell code like this, and I’m happy with the results. I’ve also started to use some other programming techniques in my shell scripts to improve readability: better naming, extracting more methods, and moving helper methods into separate files. It feels good to treat shell scripts like real code instead of just some stuff I’ve hacked together.
+PS. The WordPress theme I’m currently using (Twenty Eleven) also buries the lede — I can barely even see the title of the blog post on my screen without scrolling. I’m going to have to change that soon.
+Web Development, Ruby on Rails, Open Source
+There’s a tweet that I saw recently, with some simple advice for novice programmers:
++Slow down.
This is probably good advice for most programmers. Our team recently noticed that every time we try to rush things, we make mistakes. And the mistakes end up costing us more time than if we had just done things at our normal pace. Slowing down ensures that you do things right, and when you do things right, you end up with a higher-quality product.
+There are 2 types of code quality: internal and external. External code quality can be measured by how many bugs have been reported by customers. Internal code quality is harder to measure, but it mainly deals with the ability to change the code. When your internal quality is low, you’ve got lots of technical debt, and it’s harder to make changes.
+So when you try to write code quickly, code quality decreases, leading to a code base that takes more time to make changes to. Conversely, when you slow down, your code quality improves, and it becomes easier to make changes more quickly. So when writing code, slowing down in the short run leads to a speed-up in the long run.
+But writing code isn’t the only place where we try to speed up. On an Agile team, we’re always trying to improve the way we work — especially at the beginning stages of an Agile transformation. So we’re eager to make changes in our processes. But I’d urge you to slow down here as well.
+My colleague Amos and I frequently argue over pair switching. It’s funny, because we agree on everything except for 1 small detail. We both think pair switching is very important, to ensure that team members see more of what’s going on, to bring more ideas to each story, to prevent knowledge silos, and to encourage team ownership. Where we disagree is how long an ideal pairing session should last. I think pairs should switch every 2 hours, and he thinks 1 hour is ideal. I’ve seen teams reach the 1 hour pairing sessions successfully. But usually not without some pain and even often failing at the first attempt.
+There’s nothing inherently wrong with failing. But if you fail at something, you’re not likely to try again. After all, you should learn from your failures, right?
+So if you want your team to do something, you probably don’t want them to fail at it. If they fail, they won’t want to try a second time. That’s just human nature, and learning from failure. While you might think that they failed because they weren’t ready for the change yet, they’ll most likely think that they failed because this particular change won’t work for their situation. And they probably won’t know what to change when trying again, so they won’t try again.
+I’ve seen this over and over. Back when Linux was up-and-coming, when a consultant pushed a company into using Linux before they were ready for it, and it didn’t work out, that company was cautious about trying again. So instead of being on the leading edge of using Linux, or even the middle of the pack, they ended up more toward the trailing edge. Had they not been pushed, they would have gotten more benefit in the long run.
+So my advice in process improvement is the same as in programming: slow down. Take small steps toward what you think is the ideal. Make a small change, see how it works out, and adjust. As long as you’re still moving in the right direction, I believe you’ll move faster by taking small steps than by trying to make big leaps.
+Web Development, Ruby on Rails, Open Source
+I don’t believe that estimation should be part of any Agile practice.
+One of our managers recently mentioned that we hadn’t met the “contract” that we had “committed” to in our last iteration. This was complete nonsense, because A) we hadn’t made any such commitments, and B) we completed many more story points than the previous iterations (and without inflating story points).
+
But her language made me come to several realizations. First and foremost, estimates are contracts. Sure, they’re not supposed to be treated as commitments, but they almost always are. And what does the Agile Manifesto say about this? It says that we should value customer collaboration over contract negotiation, and responding to change over following a plan. So it’s pretty clear that treating estimates as commitments is completely counter to the Agile values.
+Why does this matter? What benefits do the Agile values bring us? I think the biggest benefit they bring is changing the way that we work, so that we can better deliver value to our customers. Without Agile, we’d just keep working the way we’ve always done things. And that didn’t seem to be working out so well. If we follow the Agile values and principles, at least we’ll have a fighting chance of improving our ability to deliver value.
+Ask yourself — have you ever seen a software development project that was on time and on budget? Where the estimates were spot-on? Of course not. For one, we’re terrible at estimating. For another, our plans change — either from external factors, or from what we learn as we go.
+To me, Agile is also about facing reality — and embracing it. It realizes that we’re terrible at estimating. It realizes that plans change. Most Agile methodologies have some tricks to counteract Hofstadter’s law. Generally, we use relative story points instead of hours, and then use an empirical factor to convert points to hours.
+When this works, it is better than any other estimation I’ve ever seen. But it doesn’t work very often. People have trouble with relative estimation. How do you set the basis for what a point means without relating it to actual hours? Affinity estimation could work, but then you have to remember what the basis was. We’ve got a large distributed team, and when we tried this, we couldn’t all remember what the basis was.
+Since we couldn’t get affinity estimation to work, we tried changing to perfect hours (only powers of 2). But then people thought of them as time. When we took longer than the estimate on an individual story, managers and team members thought we were taking longer than we should have. So our estimates ended up causing problems.
+Managers want estimates so that they can have predictability. They want to know when new features will be available. Is there a better way to get what we need?
+I believe there’s a better way — prioritization. If you work on the most important thing first, then the most important thing will get done first. We should always be working on the next most important thing.
+What if there’s more than 1 thing that’s most important? Then you’ve failed. You’ve failed at logic if you can’t understand that only 1 thing can be most important. You’ve failed at prioritizing the customers’ needs. You’ve failed at project management.
+1. Why can’t you just tell us how long it will really take?
+Because we don’t know. Because we can’t know. This is the first time we’ve ever implemented the functionality you’ve asked for. If we’d done it before, we’d just use that existing code. As Glenn Vanderburg pointed out in his excellent talk on Software Engineering, we’re not building software, we’re architecting it.
+2. But we have to tell our customers what to expect.
+Why? Is the product so bad that you can’t keep customers around without leading them on with future enhancements? And why do customers need exact dates? A general roadmap telling them what the priorities for upcoming features should be sufficient.
+3. But we have to have messaging about new features.
+OK. Then send out that messaging once the feature has made it to Staging. Or even after it’s been rolled out to Production.
+4. But we’ve promised these new features to the customers by this date.
+Ah, so you’ve made promises to the customer that you don’t have control over. Have you ever heard of “under-promise and over-deliver”? That’s how you create happy customers. Yet you’ve done just the opposite, haven’t you? And then you want to blame someone else.
+Risk
+Estimates are risk. But the risk doesn’t come at the end, when the estimates are shown to be incorrect. The risk was in asking for the estimates in the first place, and placing trust in them. Don’t do it. Don’t promise things that you can’t be sure of.
+Embrace this reality. Embrace this uncertainty. Always focus on what’s most important. That’s how you make customers happy.
+As soon as estimation, sizing or velocity becomes a requirement outside of the team, the process is broken.
+If a team uses these internally as a tool for planning how much work they will accept, I have no problem with that – but they should look for opportunities to reduce the time spent on the numbers aspect of planning.
+Teams should question what the manager actually needs, rather than blindly exposing planning numbers.
+2. But we have to tell our customers what to expect.
+Why? Is the product so bad that you can’t keep customers around without leading them on with future enhancements? And why do customers need exact dates?
A lot of cases when you have to make brand new feature faster than your competitor or you have to meet deadline with other external things (like releasing iOS8, whatever). Or just an example when you are expecting a house will be done before winter comes so you can live in there, but workers didn’t finish it in time. Would you like to have no promises on deadline and make a decisions on each day of life? I don’t think so. Agile is for business, and if doesn’t make a things enhancing income – it doesn’t work.
+What if there’s more than 1 thing that’s most important? Then you’ve failed.
+If you have only one type of customers and one main functionality of the product – then you are right; But when product have several brunches, a lot of functionalities for several customers segment that should be delivered in one time – you can’t concentrate on one thing. Otherwise, your business fails.
+I do understand why Agile can’t answer on question When? But it still doesn’t help with making a business in brutal, full of competitors world J.
+Web Development, Ruby on Rails, Open Source
+I’ve decided to design and implement my own programming language, and call it Brilliant.
+I’ve been interested in programming languages and linguistics almost as long as I’ve been using computers. I’ve long thought that if I ever go back to college, it’s likely that I’ll concentrate on programming languages as a specialty.
+My recent discovery and involvement with the Crystal programming language has gotten me excited about new language ideas. It’s also helped me realize that implementing a language myself is feasible, and that there’s no better time to start than now.
+For now, the Brilliant implementation doesn’t let you do much more than “Hello World”. But you gotta start somewhere. So this article isn’t really “Introducing Brilliant” so much as the start of a series of articles on its design and implementation.
+I wanted to use a PEG (parsing expression grammar) parser for several reasons. For one, they seem to have gained a lot of popularity in the past few years. Also, PEGs cannot be ambiguous, which can solve a few difficult problems, such as the “dangling else“. Perhaps my favorite feature of PEG grammars is that you don’t need a separate tokenizer (lexer). This provides a nice advantage in that we can use keywords like “class” as variables, as long as they’re not used in a place where the keyword would make sense.
So knowing that I wanted to use a PEG, I had to find a PEG parser. I kind of wanted to use ANTLR, which has been a leading parser for many years. But the PEG seems to be new to version 4, and I couldn’t find any Ruby bindings for version 4. Treetop seems to be the most popular parser for Ruby, but I found the EBNF format that Rattler uses to be more to my taste. I think the fact that it’s newer also gives it a few advantages, having had a chance to learn some lessons from Treetop.
+I thought about using the Rubinius VM, but decided to go with LLVM, mainly since it has slightly better docs for Ruby, and because it’s what Crystal uses. Also, it’s pretty easy to get it to compile to a binary executable or run in a JIT. In the future, I might consider switching to the Rubinius VM, the Erlang VM, or the Perl 6 VM (Parrot). But for now, I like the idea of being able to compile to a binary and easily interface with C, just like Crystal.
+My main goal is to have fun playing around with language ideas.
+I’ve found a really great language in Ruby, so I’ll be using it as a starting point. But Ruby does have its faults. In some ways, I want to answer the question “what would Ruby look like if we designed it today?”.
+But I also want to explore other ideas. What if objects defaulted to immutable? What if functions and methods were assumed to be pure by default? Might it be possible to infer the purity of a function or method? (If so, we could automatically memoize them.) Can we make creating an actor as easy as creating an object?
+I’ll also be looking at ideas from other programming languages. Could we get some of the benefits of Haskell’s purity without having to do somersaults to do IO? Could we mix Python’s indentation style scoping with brace style or begin/end style? Could we integrate Icon’s ideas about success and failure (goal-directed execution)? What interesting features can we pull from Ada, Io, CoffeeScript, Crystal, Rubinius, Perl 6, etc.?
+
I’m not so much as interested in cutting-edge features, as in features that can be easily used by the average programmer. More importantly, I’m interested in how features interact with each other, so they fit well together to create a whole that’s greater than the sum of the parts.
+I wanted to name my programming language “Fermat”. I’ve long been intrigued by Fermat’s Last Theorem, and Fermat’s Little Theorem is important in number theory. Unfortunately, there’s already a computer algebra system with that name.
+So I decided to find a name in the same vein as “Ruby” and “Crystal”. I looked at the Wikipedia page for “gemstones” for some inspiration. A lot of the names of gemstones are already taken. I considered some obscure gemstones, but saw the word “brilliant” and thought it was decent. It’s not the name of another gemstone, but still evokes some similarity to Ruby and Crystal.
+So that’s the name for now. Perhaps I’ll decide to change it at some point in the future, but I needed a name for the project, as well as a file extension for source code files. I chose “bril” for that. I suppose “br” would be a better choice. Perhaps I’ll change that before the next article in this series.
I hope to work on Brilliant every once in a while. I expect it’ll take a couple years before it’s really very useful.
+When I do add a major feature, I’ll be certain to blog about it. I’ve got tons of ideas strewn about in various files. It would be great to get them organized and published —and even better to get them implemented.
+Cool! Creating a programming language is very fun and you learn a lot in the process. It can sometimes be frustrating and very challenging. The most important thing is to never give up. I’m really curious about the syntax and semantic you have in mind. Good luck!
+Web Development, Ruby on Rails, Open Source
+I’ve run across a pattern in Ruby lately that I really like. It solves some problems that I’ve struggled with for several years. Let me start with the problems.
+Let’s say you want to include an ORM in a model class, and want to tell it what database table to use. Typically, you’d do this:
+class User + include MyORM::Model + table 'people' +end+
But that table call is more like an option to the module inclusion than anything else. So what we’d really like is something like this:
class User + include MyORM::Model, table: 'people' +end+
But that’s not valid Ruby; include doesn’t let you pass anything other than a module.
So when I was learning about Virtus, I noticed that its example of how to include it is a bit different than the standard Ruby idiomatic include:
class User + include Virtus.model +end+
At first glance, it reads like the first example. But on closer inspection and consideration, it’s quite a bit different. Where MyORM::Model is a constant that refers to a module, Virtus.model is a method call. So there’s a method named model in the Virtus module. That method returns another module — which is exactly what’s needed in order to include it into our model class.
The easiest way to implement Virtus.model would be this:
module Virtus + def model + ::Virtus::Model + end +end + +module Virtus::Model + # ... +end+
If Virtus.model doesn’t need to take any arguments, that’s perfectly fine. In fact, I’ve started to use this implementation of the pattern for modules that don’t need parameters.
Because Virtus.model is a method, we can also call it with options:
class User + include Virtus.model(constructor: false, mass_assignment: false) +end+
We could even pass a block. But how do we process those options? There are a few different ways. However we do it, we have to be sure to return a module. And we can create modules in a few different ways.
+Virtus uses the builder pattern. It takes the parameters passed in and builds a module dynamically. By that, I mean that it calls Module.new and then adds methods to that module. It does this by mixing in other modules, but it could do it by dynamically defining methods as well.
I’ve never seen this pattern in any other language. It’s obviously only possible because we can dynamically create modules.
+The use of this idiom seems to be catching on a bit in the Ruby community. I’ve started using it myself, and will be adding it to my Includable::ActiveRecord gem soon.
++
+
Web Development, Ruby on Rails, Open Source
+I’ve run across a pattern in Ruby lately that I really like. It solves some problems that I’ve struggled with for several years. Let me start with the problems.
+Let’s say you want to include an ORM in a model class, and want to tell it what database table to use. Typically, you’d do this:
+class User + include MyORM::Model + table 'people' +end+
But that table call is more like an option to the module inclusion than anything else. So what we’d really like is something like this:
class User + include MyORM::Model, table: 'people' +end+
But that’s not valid Ruby; include doesn’t let you pass anything other than a module.
So when I was learning about Virtus, I noticed that its example of how to include it is a bit different than the standard Ruby idiomatic include:
class User + include Virtus.model +end+
At first glance, it reads like the first example. But on closer inspection and consideration, it’s quite a bit different. Where MyORM::Model is a constant that refers to a module, Virtus.model is a method call. So there’s a method named model in the Virtus module. That method returns another module — which is exactly what’s needed in order to include it into our model class.
The easiest way to implement Virtus.model would be this:
module Virtus + def model + ::Virtus::Model + end +end + +module Virtus::Model + # ... +end+
If Virtus.model doesn’t need to take any arguments, that’s perfectly fine. In fact, I’ve started to use this implementation of the pattern for modules that don’t need parameters.
Because Virtus.model is a method, we can also call it with options:
class User + include Virtus.model(constructor: false, mass_assignment: false) +end+
We could even pass a block. But how do we process those options? There are a few different ways. However we do it, we have to be sure to return a module. And we can create modules in a few different ways.
+Virtus uses the builder pattern. It takes the parameters passed in and builds a module dynamically. By that, I mean that it calls Module.new and then adds methods to that module. It does this by mixing in other modules, but it could do it by dynamically defining methods as well.
I’ve never seen this pattern in any other language. It’s obviously only possible because we can dynamically create modules.
+The use of this idiom seems to be catching on a bit in the Ruby community. I’ve started using it myself, and will be adding it to my Includable::ActiveRecord gem soon.
++
+
I think it would be interesting to try using a block as the config to your include. Make a capitalized method that returns a module. Then you could pass a block with curly braces to that method.
+class User
+ include MyORM::Model {
+ table "people"
+ }
+end
+
+ I seem to have forgotten to mention that this is related to the Factory pattern. In fact, I think it’s a special case of the Factory pattern.
+I thought I was using this pattern on the following code, but realized that it’s just the Factory pattern:
++module Preserves + def self.repository(*options, &block) + repository = Repository.new(*options) + repository.instance_eval(&block) + repository + end +end + +UserRepository = Preserves.repository(model: User) do +end ++ +
+
+
+
+
+
+ I’ve run across a pattern in Ruby lately that I really like. It solves some problems that I’ve struggled with for several years. Let me start with the problems.
+Let’s say you want to include an ORM in a model class, and want to tell it what database table to use. Typically, you’d do this:
+class User + include MyORM::Model + table 'people' +end+
But that table call is more like an option to the module inclusion than anything else. So what we’d really like is something like this:
class User + include MyORM::Model, table: 'people' +end+
But that’s not valid Ruby; include doesn’t let you pass anything other than a module.
So when I was learning about Virtus, I noticed that its example of how to include it is a bit different than the standard Ruby idiomatic include:
class User + include Virtus.model +end+
At first glance, it reads like the first example. But on closer inspection and consideration, it’s quite a bit different. Where MyORM::Model is a constant that refers to a module, Virtus.model is a method call. So there’s a method named model in the Virtus module. That method returns another module — which is exactly what’s needed in order to include it into our model class.
The easiest way to implement Virtus.model would be this:
module Virtus + def model + ::Virtus::Model + end +end + +module Virtus::Model + # ... +end+
If Virtus.model doesn’t need to take any arguments, that’s perfectly fine. In fact, I’ve started to use this implementation of the pattern for modules that don’t need parameters.
Because Virtus.model is a method, we can also call it with options:
class User + include Virtus.model(constructor: false, mass_assignment: false) +end+
We could even pass a block. But how do we process those options? There are a few different ways. However we do it, we have to be sure to return a module. And we can create modules in a few different ways.
+Virtus uses the builder pattern. It takes the parameters passed in and builds a module dynamically. By that, I mean that it calls Module.new and then adds methods to that module. It does this by mixing in other modules, but it could do it by dynamically defining methods as well.
I’ve never seen this pattern in any other language. It’s obviously only possible because we can dynamically create modules.
+The use of this idiom seems to be catching on a bit in the Ruby community. I’ve started using it myself, and will be adding it to my Includable::ActiveRecord gem soon.
++
+
I think it would be interesting to try using a block as the config to your include. Make a capitalized method that returns a module. Then you could pass a block with curly braces to that method.
+
+class User
+ include MyORM::Model {
+ table "people"
+ }
+end
+
I thought I was using this pattern on the following code, but realized that it’s just the Factory pattern:
+
+
+module Preserves
+ def self.repository(*options, &block)
+ repository = Repository.new(*options)
+ repository.instance_eval(&block)
+ repository
+ end
+end
+
+UserRepository = Preserves.repository(model: User) do
+end
+
+
+class User
+ include MyORM::Model {
+ table "people"
+ }
+end
+
+
+
+
+
+
+ I’ve run across a pattern in Ruby lately that I really like. It solves some problems that I’ve struggled with for several years. Let me start with the problems.
+Let’s say you want to include an ORM in a model class, and want to tell it what database table to use. Typically, you’d do this:
+class User + include MyORM::Model + table 'people' +end+
But that table call is more like an option to the module inclusion than anything else. So what we’d really like is something like this:
class User + include MyORM::Model, table: 'people' +end+
But that’s not valid Ruby; include doesn’t let you pass anything other than a module.
So when I was learning about Virtus, I noticed that its example of how to include it is a bit different than the standard Ruby idiomatic include:
class User + include Virtus.model +end+
At first glance, it reads like the first example. But on closer inspection and consideration, it’s quite a bit different. Where MyORM::Model is a constant that refers to a module, Virtus.model is a method call. So there’s a method named model in the Virtus module. That method returns another module — which is exactly what’s needed in order to include it into our model class.
The easiest way to implement Virtus.model would be this:
module Virtus + def model + ::Virtus::Model + end +end + +module Virtus::Model + # ... +end+
If Virtus.model doesn’t need to take any arguments, that’s perfectly fine. In fact, I’ve started to use this implementation of the pattern for modules that don’t need parameters.
Because Virtus.model is a method, we can also call it with options:
class User + include Virtus.model(constructor: false, mass_assignment: false) +end+
We could even pass a block. But how do we process those options? There are a few different ways. However we do it, we have to be sure to return a module. And we can create modules in a few different ways.
+Virtus uses the builder pattern. It takes the parameters passed in and builds a module dynamically. By that, I mean that it calls Module.new and then adds methods to that module. It does this by mixing in other modules, but it could do it by dynamically defining methods as well.
I’ve never seen this pattern in any other language. It’s obviously only possible because we can dynamically create modules.
+The use of this idiom seems to be catching on a bit in the Ruby community. I’ve started using it myself, and will be adding it to my Includable::ActiveRecord gem soon.
++
+
I think it would be interesting to try using a block as the config to your include. Make a capitalized method that returns a module. Then you could pass a block with curly braces to that method.
+
+class User
+ include MyORM::Model {
+ table "people"
+ }
+end
+
+
+
+
+
+
+ I’ve run across a pattern in Ruby lately that I really like. It solves some problems that I’ve struggled with for several years. Let me start with the problems.
+Let’s say you want to include an ORM in a model class, and want to tell it what database table to use. Typically, you’d do this:
+class User + include MyORM::Model + table 'people' +end+
But that table call is more like an option to the module inclusion than anything else. So what we’d really like is something like this:
class User + include MyORM::Model, table: 'people' +end+
But that’s not valid Ruby; include doesn’t let you pass anything other than a module.
So when I was learning about Virtus, I noticed that its example of how to include it is a bit different than the standard Ruby idiomatic include:
class User + include Virtus.model +end+
At first glance, it reads like the first example. But on closer inspection and consideration, it’s quite a bit different. Where MyORM::Model is a constant that refers to a module, Virtus.model is a method call. So there’s a method named model in the Virtus module. That method returns another module — which is exactly what’s needed in order to include it into our model class.
The easiest way to implement Virtus.model would be this:
module Virtus + def model + ::Virtus::Model + end +end + +module Virtus::Model + # ... +end+
If Virtus.model doesn’t need to take any arguments, that’s perfectly fine. In fact, I’ve started to use this implementation of the pattern for modules that don’t need parameters.
Because Virtus.model is a method, we can also call it with options:
class User + include Virtus.model(constructor: false, mass_assignment: false) +end+
We could even pass a block. But how do we process those options? There are a few different ways. However we do it, we have to be sure to return a module. And we can create modules in a few different ways.
+Virtus uses the builder pattern. It takes the parameters passed in and builds a module dynamically. By that, I mean that it calls Module.new and then adds methods to that module. It does this by mixing in other modules, but it could do it by dynamically defining methods as well.
I’ve never seen this pattern in any other language. It’s obviously only possible because we can dynamically create modules.
+The use of this idiom seems to be catching on a bit in the Ruby community. I’ve started using it myself, and will be adding it to my Includable::ActiveRecord gem soon.
++
+
I think it would be interesting to try using a block as the config to your include. Make a capitalized method that returns a module. Then you could pass a block with curly braces to that method.
+
+class User
+ include MyORM::Model {
+ table "people"
+ }
+end
+
Web Development, Ruby on Rails, Open Source
+I went to RailsConf this year, and the very first talk was a keynote by David Heinemeier Hansson (DHH), the creator of Ruby on Rails. The TL;DR of his talk was “TDD rarely has value”. He followed up with a blog post the next day, titled “TDD is dead. Long live testing.“, and 2 more posts. I think this line of thought is terribly misguided, and causing more harm than good. This article is my response.
+First, I would like to address the good points of the talk. He said that programming is pseudoscience, and that people want to tell us that there’s a secret to being a better programmer. But what it really takes is working hard — reading a lot of code, writing a lot of code, and rewriting a lot of code. He’s right. And I also agree with him that you should forget about patterns for a while when learning to code. Beginners try to throw patterns at a problem instead of letting the patterns emerge where they’re supposed to.
+I don’t completely agree that programming is a pseudoscience. In some ways it is, but I think it’s more of a craft. It’s a craft, because there’s a lot of science involved, but there’s also an art to doing it well. And like any craft, you’re always working to get better. So to respond to DHH’s stance that “software is more like poetry than physics”, I think it falls
+somewhere in between.
With regard to the software engineering practices we use, there really isn’t much science available, mostly because it’s a soft science. That is, it’s really hard to isolate a single variable when comparing code between projects. And nobody has the time or money to write the same code so many times that the differences would be statistically significant.
+So we don’t have much science on TDD. But we do have some. Here’s a collection of several: StudiesOfTestDrivenDevelopment. And here’s one that explicitly looks are the difference between test-first and test-last: Does Test-Driven Development Really Improve Software Design Quality? What do these tell us? They tell us that TDD costs us about 10-30% in short-term productivity; reduces bugs by 30-90%, and decreases code complexity by about 30%. As Code Complete tells us (in section 20.5, with studies to back it up), improving quality reduces development costs. So, like most Agile practices, this is a case where spending a bit more time in the short term leads to time savings in the long term.
+The more important lesson in the talk was that you have to do what works best for you and your situation. If TDD doesn’t give better results, then either find out how to make it give better results, or stop using it. As we often say in the Agile world, Agile doesn’t mean that you can stop using your brain. While I think TDD is appropriate in most situations, there are cases where it’s not worth the additional up-front cost. If the most important thing for your project is time-to-market, then not testing might be the right decision for you.
+To me, TDD provides a bunch of benefits. First and foremost, TDD is a design discipline. It ensures that I think about how my code will be used before I think about how to implement it. This is very powerful in ensuring that the code is well-written from the perspective of other code using it.
+Tested code provides confidence to be able to make changes without breaking things. If we write tests after the code, we’re less likely to write them. Tests written after the code also tend to test the implementation instead of the desired functionality. What we really want is tests written as a specification. With tests as a specification, we can come back later and understand why code was written. Without tests, or with poor tests, we can’t understand why the code is there; if we want to rewrite it, we don’t have the confidence that we’re not missing something. Writing tests first also ensures that we only write the code that is needed to implement the required functionality.
+I’m not sure why DHH hasn’t “gotten” TDD. I’m not sure if it’s because he’s a better coder than average, or if he just thinks in a different way than most of us. I think it’s partly because he doesn’t understand TDD, which he admitted might be the case. And I think he’s conflating TDD and unit testing.
+DHH is influential in the developer community, especially those newer to Ruby and Rails. People listen to what he has to say. I was happy to see almost every other speaker made fun of DHH’s ideas, and most of the crowd knew better. But there will be a lot of others who will hear DHH, respect his opinions, and not give TDD the try that it deserves. And that’s sad, because it will lead to an overall reduction in code quality in the world.
+Here are some other people’s thoughts on the matter:
++
Web Development, Ruby on Rails, Open Source
+I went to RailsConf this year, and the very first talk was a keynote by David Heinemeier Hansson (DHH), the creator of Ruby on Rails. The TL;DR of his talk was “TDD rarely has value”. He followed up with a blog post the next day, titled “TDD is dead. Long live testing.“, and 2 more posts. I think this line of thought is terribly misguided, and causing more harm than good. This article is my response.
+First, I would like to address the good points of the talk. He said that programming is pseudoscience, and that people want to tell us that there’s a secret to being a better programmer. But what it really takes is working hard — reading a lot of code, writing a lot of code, and rewriting a lot of code. He’s right. And I also agree with him that you should forget about patterns for a while when learning to code. Beginners try to throw patterns at a problem instead of letting the patterns emerge where they’re supposed to.
+I don’t completely agree that programming is a pseudoscience. In some ways it is, but I think it’s more of a craft. It’s a craft, because there’s a lot of science involved, but there’s also an art to doing it well. And like any craft, you’re always working to get better. So to respond to DHH’s stance that “software is more like poetry than physics”, I think it falls
+somewhere in between.
With regard to the software engineering practices we use, there really isn’t much science available, mostly because it’s a soft science. That is, it’s really hard to isolate a single variable when comparing code between projects. And nobody has the time or money to write the same code so many times that the differences would be statistically significant.
+So we don’t have much science on TDD. But we do have some. Here’s a collection of several: StudiesOfTestDrivenDevelopment. And here’s one that explicitly looks are the difference between test-first and test-last: Does Test-Driven Development Really Improve Software Design Quality? What do these tell us? They tell us that TDD costs us about 10-30% in short-term productivity; reduces bugs by 30-90%, and decreases code complexity by about 30%. As Code Complete tells us (in section 20.5, with studies to back it up), improving quality reduces development costs. So, like most Agile practices, this is a case where spending a bit more time in the short term leads to time savings in the long term.
+The more important lesson in the talk was that you have to do what works best for you and your situation. If TDD doesn’t give better results, then either find out how to make it give better results, or stop using it. As we often say in the Agile world, Agile doesn’t mean that you can stop using your brain. While I think TDD is appropriate in most situations, there are cases where it’s not worth the additional up-front cost. If the most important thing for your project is time-to-market, then not testing might be the right decision for you.
+To me, TDD provides a bunch of benefits. First and foremost, TDD is a design discipline. It ensures that I think about how my code will be used before I think about how to implement it. This is very powerful in ensuring that the code is well-written from the perspective of other code using it.
+Tested code provides confidence to be able to make changes without breaking things. If we write tests after the code, we’re less likely to write them. Tests written after the code also tend to test the implementation instead of the desired functionality. What we really want is tests written as a specification. With tests as a specification, we can come back later and understand why code was written. Without tests, or with poor tests, we can’t understand why the code is there; if we want to rewrite it, we don’t have the confidence that we’re not missing something. Writing tests first also ensures that we only write the code that is needed to implement the required functionality.
+I’m not sure why DHH hasn’t “gotten” TDD. I’m not sure if it’s because he’s a better coder than average, or if he just thinks in a different way than most of us. I think it’s partly because he doesn’t understand TDD, which he admitted might be the case. And I think he’s conflating TDD and unit testing.
+DHH is influential in the developer community, especially those newer to Ruby and Rails. People listen to what he has to say. I was happy to see almost every other speaker made fun of DHH’s ideas, and most of the crowd knew better. But there will be a lot of others who will hear DHH, respect his opinions, and not give TDD the try that it deserves. And that’s sad, because it will lead to an overall reduction in code quality in the world.
+Here are some other people’s thoughts on the matter:
++
Web Development, Ruby on Rails, Open Source
+I’ve had a long love-hate relationship with Rails. I love the MVC framework and how it’s improved our speed of writing web apps. But I’ve never really been completely happy with it. I don’t generally agree with most of its opinions. I prefer models that follow the Data Mapper pattern, not the Active Record pattern. This includes separating the persistence layer from the models’ business logic. I prefer Slim or HAML to ERB. I prefer RSpec to Test::Unit or MiniTest. When Merb hit the scene, I was ready to make the jump, until Merb merged with Rails.
+So inspired by PJ Hagerty’s recent article on alternative Ruby web frameworks, I started thinking about how I’d write a replacement for Rails. I’d definitely keep the basic MVC framework. But I’d also want to implement a more hexagonal architecture.
+I started sketching out what this would look like, but I ended up starting with a Rails controller and finding the simplest way to make it hexagonal. I really don’t like callbacks, because they make tracing program execution difficult. But I didn’t see any other alternative. I found a simple pub/sub Ruby library called Wisper. It literally has only publish, subscribe, and on methods. (You use on to register single callbacks via blocks, and subscribe to register an object with method names corresponding to the callback names.)
The trick was figuring out how to break the controller into 2 pieces. What finally helped me was to find the single responsibilities of the 2 pieces. The Rails controller would remain in charge of managing the web interface, but would delegate to the other piece to handle any application-specific business logic. I decided to re-watch Uncle Bob Martin’s “Architecture The Lost Years” talk, which was the first time I was introduced to the ideas of Hexagonal Architecture. (He doesn’t name the architecture in the talk, but later calls it Clean Architecture.) He does a decent job of explaining how to break these 2 pieces apart. He used the term “interactor” in that talk, so I decided to go with that. He said that Jacobsen calls it a Control Object in Object Oriented Software Engineering, but that’s too close to Rails’s “controller”.
+So here’s an example of what I ended up with:
+class OrderController < ApplicationController
+ def index
+ interactor.on(:display) { |orders| render orders }
+ interactor.list
+ end
+
+ def show
+ interactor.on(:display) { |order| render order }
+ interactor.on(:not_found) { |order_id| render status: 404 }
+ interactor.get(params[:id])
+ end
+
+private
+
+ def interactor
+ @interactor ||= OrderInteractor.new
+ end
+end
+require "wisper" +require "order" + +class OrderInteractor + include Wisper.publisher + + def list + orders = Order.all + publish(:display, orders) + end + + def get(id) + order = Order.find(id) + publish(:display, order) + rescue ActiveRecord::RecordNotFound + publish(:not_found, id) + end +end+
I do have a few problems with this solution though. I’m not a fan of the name “interactor” for the business logic. I thought about calling it OrderOperator, or maybe OrderOperations, because it’s really a collection of operations. Perhaps it would be better to separate each operation into a separate class. Trailblazer does it that way. And for more complicated business logic, I would do that too, using the Method Object pattern. But like a Rails controller, there’s a lot in common among all the operations. I feel like a separate class for each operation for each would create too many coupled classes.
I’m also uncomfortable with the fact that the controller is delegating almost everything to the interactor. I guess this is OK, but it feels like there’s too little left when every line starts with interactor. I suppose extracting things some more would help mitigate this concern I’ll likely write a small gem to perform that extraction. I expect that that will allow a typical controller to be written in only a few lines. And maybe the same for the interactor side.
With the business logic extracted out of the controller, it was really easy for me to write a command-line version of the app. As Uncle Bob says, “the web is not particularly important to your application.”
+I’ve put the code for this example on GitHub: https://github.com/boochtek/hexagonal-rails. I’ll likely experiment with it some more over the next few weeks and months.
+January kept me pretty busy, so I’m a little late to this. But better late than never. And as an Agile practitioner, I don’t think personal retrospectives should be limited to one time of year.
+Last year I wrote a blog entry listing my goals for 2014. As far as New Year’s resolutions go, I was relatively successful — about 50% of my goals accomplished. Unfortunately, my Open Source contributions weren’t as strong as I had hoped; while I released some of my own work, I didn’t do much else. I did increase my blogging; getting in on a weekly blogging pact helped immensely. I also increased my participation on the This Agile Life podcast to a level that I’m happy with. But the accomplishment I’m most proud of was giving a presentation at RubyConf.
+I’d like to keep things rolling from last year, but crank up a few things. My plans are quite ambitious, so I don’t expect to get everything done by any means. But I think by setting the bar high, I’ll end up with a lot I can be proud of.
+Late last year, I took the jump into independent consulting. So far, I’ve really enjoyed it, and I’m booked up through April. My wife graduates in May, so we’ve got the possibility of moving if that makes sense. So I’ll be looking for consulting projects in town, but I’ll also be looking at jobs in San Francisco and Chicago. The possibilities are exciting, and I’ll be taking my time to find something just right.
+I was incredibly nervous leading up to my RubyConf presentation. Part of that was just the common fear of public speaking. For me, that only kicks in at around 100 people, and this audience was around 250. I think another reason was that I chose a really ambitious topic, and I kept finding more that I wanted to talk about, but wasn’t prepared for. But I think I did a pretty good job presenting an advanced topic. And I was so pumped by the sense of accomplishment as soon as I finished. So I’m hoping to do it more. I’ve already submitted a couple proposals, and plan to submit several more.
+I believe that blogging is important for me to get my thoughts down — for myself and to share with others. I was really successful last year when I had a partner to keep me honest, via a pact. So I’ve started up another pact this year, which will hopefully ensure I’ll keep things going. I’ve got a really long backlog of topics, so as long as I keep at it, I’ll have plenty to write about.
+I also want to move away from WordPress to a static system — probably Middleman. I’ve got 2 major problems with WordPress. First, I no longer trust its security, nor the security of any application written in PHP. Second, it generates HTML every time someone requests a page, instead of when the content is updated. I find that to be a waste of resources, and problematic from a security standpoint. The main problem with moving to a static blogging system is that I really want to allow comments, pingbacks, and tweetbacks. So I’ll have to find a way to integrate those.
+Last year I started thinking about programming language design, and started implementing a language tentatively called Brilliant. I’ve done a lot more thinking on the topic, and have a lot of notes. But I haven’t implemented much more yet. This year, I’d like to get my thoughts more organized, and write a series of blog posts on various aspects of language design. The most interesting part seems to be the trade-offs involved in the ways that various language features interact. So I’d like to make some progress on the language implementation, but more importantly, I’d like to get a lot of my design ideas written down.
+I’m also going to spend a lot of time learning a bunch more programming languages, so I have a better understanding of possible features, combinations of features, and their interactions. I’ve already start with Elixir, Clojure, and Racket. I’m hoping to also look at OCaml, Factor, and Haskell. I’ll probably also take a look at the 2 “Seven Languages in Seven Weeks” books.
+I think people often have trouble getting started with Agile. I started on a book last year, and got down quite a lot of good ideas. But I realized that I’m going to have a hard time organizing all those ideas into something coherent. Still, I’d like to try to get something out there that lets people get started with Agile. My idea is to present a toolbox of practices to get started with and build on that foundation over time with additional practices. Sort of a playbook on how to get started over the first 6 to 12 months and be successful. I want to make some progress on the book, at least enough to decide whether it’s worth the effort to finish it and self-publish it.
++
Web Development, Ruby on Rails, Open Source
+January kept me pretty busy, so I’m a little late to this. But better late than never. And as an Agile practitioner, I don’t think personal retrospectives should be limited to one time of year.
+Last year I wrote a blog entry listing my goals for 2014. As far as New Year’s resolutions go, I was relatively successful — about 50% of my goals accomplished. Unfortunately, my Open Source contributions weren’t as strong as I had hoped; while I released some of my own work, I didn’t do much else. I did increase my blogging; getting in on a weekly blogging pact helped immensely. I also increased my participation on the This Agile Life podcast to a level that I’m happy with. But the accomplishment I’m most proud of was giving a presentation at RubyConf.
+I’d like to keep things rolling from last year, but crank up a few things. My plans are quite ambitious, so I don’t expect to get everything done by any means. But I think by setting the bar high, I’ll end up with a lot I can be proud of.
+Late last year, I took the jump into independent consulting. So far, I’ve really enjoyed it, and I’m booked up through April. My wife graduates in May, so we’ve got the possibility of moving if that makes sense. So I’ll be looking for consulting projects in town, but I’ll also be looking at jobs in San Francisco and Chicago. The possibilities are exciting, and I’ll be taking my time to find something just right.
+I was incredibly nervous leading up to my RubyConf presentation. Part of that was just the common fear of public speaking. For me, that only kicks in at around 100 people, and this audience was around 250. I think another reason was that I chose a really ambitious topic, and I kept finding more that I wanted to talk about, but wasn’t prepared for. But I think I did a pretty good job presenting an advanced topic. And I was so pumped by the sense of accomplishment as soon as I finished. So I’m hoping to do it more. I’ve already submitted a couple proposals, and plan to submit several more.
+I believe that blogging is important for me to get my thoughts down — for myself and to share with others. I was really successful last year when I had a partner to keep me honest, via a pact. So I’ve started up another pact this year, which will hopefully ensure I’ll keep things going. I’ve got a really long backlog of topics, so as long as I keep at it, I’ll have plenty to write about.
+I also want to move away from WordPress to a static system — probably Middleman. I’ve got 2 major problems with WordPress. First, I no longer trust its security, nor the security of any application written in PHP. Second, it generates HTML every time someone requests a page, instead of when the content is updated. I find that to be a waste of resources, and problematic from a security standpoint. The main problem with moving to a static blogging system is that I really want to allow comments, pingbacks, and tweetbacks. So I’ll have to find a way to integrate those.
+Last year I started thinking about programming language design, and started implementing a language tentatively called Brilliant. I’ve done a lot more thinking on the topic, and have a lot of notes. But I haven’t implemented much more yet. This year, I’d like to get my thoughts more organized, and write a series of blog posts on various aspects of language design. The most interesting part seems to be the trade-offs involved in the ways that various language features interact. So I’d like to make some progress on the language implementation, but more importantly, I’d like to get a lot of my design ideas written down.
+I’m also going to spend a lot of time learning a bunch more programming languages, so I have a better understanding of possible features, combinations of features, and their interactions. I’ve already start with Elixir, Clojure, and Racket. I’m hoping to also look at OCaml, Factor, and Haskell. I’ll probably also take a look at the 2 “Seven Languages in Seven Weeks” books.
+I think people often have trouble getting started with Agile. I started on a book last year, and got down quite a lot of good ideas. But I realized that I’m going to have a hard time organizing all those ideas into something coherent. Still, I’d like to try to get something out there that lets people get started with Agile. My idea is to present a toolbox of practices to get started with and build on that foundation over time with additional practices. Sort of a playbook on how to get started over the first 6 to 12 months and be successful. I want to make some progress on the book, at least enough to decide whether it’s worth the effort to finish it and self-publish it.
++
Web Development, Ruby on Rails, Open Source
+I’ve had a long love-hate relationship with Rails. I love the MVC framework and how it’s improved our speed of writing web apps. But I’ve never really been completely happy with it. I don’t generally agree with most of its opinions. I prefer models that follow the Data Mapper pattern, not the Active Record pattern. This includes separating the persistence layer from the models’ business logic. I prefer Slim or HAML to ERB. I prefer RSpec to Test::Unit or MiniTest. When Merb hit the scene, I was ready to make the jump, until Merb merged with Rails.
+So inspired by PJ Hagerty’s recent article on alternative Ruby web frameworks, I started thinking about how I’d write a replacement for Rails. I’d definitely keep the basic MVC framework. But I’d also want to implement a more hexagonal architecture.
+I started sketching out what this would look like, but I ended up starting with a Rails controller and finding the simplest way to make it hexagonal. I really don’t like callbacks, because they make tracing program execution difficult. But I didn’t see any other alternative. I found a simple pub/sub Ruby library called Wisper. It literally has only publish, subscribe, and on methods. (You use on to register single callbacks via blocks, and subscribe to register an object with method names corresponding to the callback names.)
The trick was figuring out how to break the controller into 2 pieces. What finally helped me was to find the single responsibilities of the 2 pieces. The Rails controller would remain in charge of managing the web interface, but would delegate to the other piece to handle any application-specific business logic. I decided to re-watch Uncle Bob Martin’s “Architecture The Lost Years” talk, which was the first time I was introduced to the ideas of Hexagonal Architecture. (He doesn’t name the architecture in the talk, but later calls it Clean Architecture.) He does a decent job of explaining how to break these 2 pieces apart. He used the term “interactor” in that talk, so I decided to go with that. He said that Jacobsen calls it a Control Object in Object Oriented Software Engineering, but that’s too close to Rails’s “controller”.
+So here’s an example of what I ended up with:
+class OrderController < ApplicationController
+ def index
+ interactor.on(:display) { |orders| render orders }
+ interactor.list
+ end
+
+ def show
+ interactor.on(:display) { |order| render order }
+ interactor.on(:not_found) { |order_id| render status: 404 }
+ interactor.get(params[:id])
+ end
+
+private
+
+ def interactor
+ @interactor ||= OrderInteractor.new
+ end
+end
+require "wisper" +require "order" + +class OrderInteractor + include Wisper.publisher + + def list + orders = Order.all + publish(:display, orders) + end + + def get(id) + order = Order.find(id) + publish(:display, order) + rescue ActiveRecord::RecordNotFound + publish(:not_found, id) + end +end+
I do have a few problems with this solution though. I’m not a fan of the name “interactor” for the business logic. I thought about calling it OrderOperator, or maybe OrderOperations, because it’s really a collection of operations. Perhaps it would be better to separate each operation into a separate class. Trailblazer does it that way. And for more complicated business logic, I would do that too, using the Method Object pattern. But like a Rails controller, there’s a lot in common among all the operations. I feel like a separate class for each operation for each would create too many coupled classes.
I’m also uncomfortable with the fact that the controller is delegating almost everything to the interactor. I guess this is OK, but it feels like there’s too little left when every line starts with interactor. I suppose extracting things some more would help mitigate this concern I’ll likely write a small gem to perform that extraction. I expect that that will allow a typical controller to be written in only a few lines. And maybe the same for the interactor side.
With the business logic extracted out of the controller, it was really easy for me to write a command-line version of the app. As Uncle Bob says, “the web is not particularly important to your application.”
+I’ve put the code for this example on GitHub: https://github.com/boochtek/hexagonal-rails. I’ll likely experiment with it some more over the next few weeks and months.
+Web Development, Ruby on Rails, Open Source
+I frequently participate in a podcast called This Agile Life. Recently, a listener asked how much time Agile teams should spend on self improvement. I said 10% to 25%, leaning towards 15% to 20% for most teams. That comes to at least one hour per day, and maybe even more than one day per week.
+I’m including personal self improvement and team retrospectives in this self-improvement time. This can be as simple as configuring your IDE to make you more efficient, learning to use a tool better, or following up on action items from a retro.
+That may seem like a lot of time “wasted”. But I think I can justify the cost of all that time.
+The purpose of spending time on team or self-improvement — the whole point — is to increase our performance and our efficiency. How much improvement can we expect? Can we improve by 1% each week? That doesn’t sound too unreasonable. I think that’s an achievable goal for almost any team, at least on average.
+Spending 20% of your time to gain 1% doesn’t seem like it’s worth it — until you consider the long term. With compound interest, you’ll be 67% more efficient by the end of a year.1 At that point, you’ll be able to get things done in 59% of the time — saving 41% of the time required at the beginning of the year.2 The following years will show even more progress, as compared to when you started. If 10x programmers exist, continuous improvement is apparently the way to get there.
+So there’s a pretty good return on investment, even with a small amount of improvement each week. You’ll be significantly more efficient.
+But efficiency isn’t really what you should aim for. You should aim for effectiveness. You can be efficient in creating the wrong thing. Part of improving should be ensuring that you’re not just building things right, but that you’re building the right things. Build what the customer really needs. Find ways to ask the right questions.
+Most importantly, find ways to keep improving. It would be a waste of time not to.
+ +Web Development, Ruby on Rails, Open Source
+I frequently participate in a podcast called This Agile Life. Recently, a listener asked how much time Agile teams should spend on self improvement. I said 10% to 25%, leaning towards 15% to 20% for most teams. That comes to at least one hour per day, and maybe even more than one day per week.
+I’m including personal self improvement and team retrospectives in this self-improvement time. This can be as simple as configuring your IDE to make you more efficient, learning to use a tool better, or following up on action items from a retro.
+That may seem like a lot of time “wasted”. But I think I can justify the cost of all that time.
+The purpose of spending time on team or self-improvement — the whole point — is to increase our performance and our efficiency. How much improvement can we expect? Can we improve by 1% each week? That doesn’t sound too unreasonable. I think that’s an achievable goal for almost any team, at least on average.
+Spending 20% of your time to gain 1% doesn’t seem like it’s worth it — until you consider the long term. With compound interest, you’ll be 67% more efficient by the end of a year.1 At that point, you’ll be able to get things done in 59% of the time — saving 41% of the time required at the beginning of the year.2 The following years will show even more progress, as compared to when you started. If 10x programmers exist, continuous improvement is apparently the way to get there.
+So there’s a pretty good return on investment, even with a small amount of improvement each week. You’ll be significantly more efficient.
+But efficiency isn’t really what you should aim for. You should aim for effectiveness. You can be efficient in creating the wrong thing. Part of improving should be ensuring that you’re not just building things right, but that you’re building the right things. Build what the customer really needs. Find ways to ask the right questions.
+Most importantly, find ways to keep improving. It would be a waste of time not to.
+ +Web Development, Ruby on Rails, Open Source
+The Agile Manifesto was written in 2001, as a way to explain the common values amongst several “light-weight” software development methodologies that had come about. The term “Agile” was chosen as a shorthand for those commonalities.
+Once “Agile” started to show success, we started to see many people use the term to market their products and services, whether or not they really believed in the values and principles of the Agile Manifesto. It’s gotten to the point where some of us don’t see much value in using the term “Agile” any more. Even some of those involved in creating the manifesto have suggested new terms. Dave Thomas suggests “Agility” and Andy Hunt has started working on something called GROWS. Personally, I’m considering going back to the term “Extreme Programming”, even though I’ve incorporated ideas from other Agile methodologies.
+It recently occurred to me that Agile, when done “right”, is closely aligned with the happiness of the team members. This is really interesting, because it aligns the interests of the employees and the business — a win-win situation. My next thought was that maybe the next step after “Agile” will be a focus on happiness and motivation.
+I’ve recently been thinking about personal motivation lately, in the context of team practices. According to Daniel Pink’s book Drive, people are motivated by autonomy, mastery, and purpose. I personally add a fourth that can sometimes trump the other three: identity. And of course, happiness can also be motivating — both in the attempt to achieve happiness and in just being happy. (I suspect that happiness is more of a parallel to motivation than a cause though.)
+There are a couple different ways that happiness can be achieved at work. The traditional way is for work to be a means to an end. In this view, the purpose of your job is to provide the money to live your life (outside of work) the way that you want to live it. There’s nothing wrong with this way of thinking. But for the lucky few, we can work on something that makes us happy in and of itself. That’s generally done by finding a job doing something that we enjoy.
+But perhaps that’s thinking about things the wrong way. For one, plenty of people who have gone that route are still unhappy at work. I think a lot of that has to do more with the context surrounding the work than the work itself. Maybe you’ve got a lousy manager. Maybe you don’t like the people you work with. Maybe the tools you have to work with are bad. Maybe the processes add a lot of unnecessary tedium.
+So maybe we need to find ways to be happier at work. Most of the Agile practices seem to make team members happy. For example, replacing a light-weight process for a heavier process always makes me happy. And I typically leave retrospectives in a good mood. So that’s a good starting point. But we should see if we can take the idea further. If we take employee happiness as a core value, where can we go? What kind of practices would we want to add? Please share any ideas in the comments below.
+On a recent episode (78) of This Agile Life, my fellow hosts talked about when to do Test-Driven Development (TDD). They all said that you should always do TDD — at least for anything that will go into production; there’s an exception for experimenting or “spiking”.
+I wasn’t on that episode, but later commented on the topic. (Episode 83 — which wasn’t really all that great.) My take was slightly different. I said that you should do TDD only when the benefits outweigh the costs. Unfortunately, we usually greatly underestimate the benefits. And the costs often seem high at first, because it takes some time to get good at writing automated tests. Not to mention that both the costs and the benefits are usually hard to measure.
+What is the cost of writing automated tests? I’ve asked this question before and recorded the answers (inasmuch as we have them) in a previous blog entry. TDD costs us about 10-30% in short-term productivity. The benefit that they found was a reduction in bugs by 30-90%, and a decrease in code complexity by about 30%.
+But what about when the costs are higher than the normal 10 to 30 percent? One good example of this is when there’s no test framework for the situation you’re testing. This might be a new language or framework that you’re working with. More likely it’s a complex API that you have to mock out. So that could increase the cost of automated testing so as to outweigh the benefits — especially on a short project. I could imagine situations where the cost of writing the mocks could eat up more than the project itself.
+Another case where we might consider skipping testing is when we’re more concerned about time to market than quality. This is almost always a mistake. Your code will almost always last longer than you expect. (Remember Y2K?) And if the code lasts longer than you expect, that means you’ll have to deal with bugs that whole time. But we have to work with the information we have at the time we make our decisions. And sometimes that might tell us that time to market is more important than anything.
+One final case I can imagine is when a true expert is coding something that they’re very familiar with. I could picture someone like Uncle Bob writing code (in a language that he’s familiar with) without tests just as effectively as I could write code with tests.
+But these situations should not be common; they’re edge cases. In almost all real-world cases, TDD is the right thing to do. Don’t forget, TDD is also a design discipline — it helps you design a better API. So keep doing TDD. But as with any practice, don’t do it blindly without considering why we’re doing it. Make sure you understand the costs, and whether the benefits outweigh the costs.
+I ran into some former colleagues recently, from a company where I had worked to help transform the team to be more Agile. They’ve gone through some reorganization and management changes recently. One of the guys said that their team culture has helped them maintain quality in the face of those changes. This struck me as odd, since I had considered the work I had done there as somewhat of a disappointment. While I felt I had made a small dent, I didn’t feel like I’d made a true Agile transformation. Much of what I had taught didn’t seem to “stick”.
+Later that night I thought about why my opinion of the team and his opinion were so different. There are a lot of reasons why an Agile “transformation” could fail. It could be due to lack of support from management. Or even worse, not getting the team members to buy into the ideas — usually due to fear of change. But while those had some effect in this case, they weren’t really the main issues. Now that I’ve had some time and some distance from that team, I’ve gained some clarity on what the real issues were.
+I think the reason that I think this transformation was a failure was due to the continued pace of change that true Agile requires. Basically the team experienced “change fatigue”, where everything keeps changing and you feel like you can never catch your breath. But the more interesting thing is how our perceptions differed. He seemed to think that the transformation was a success — they’re doing things better than they used to. I view it as more of a failure, because they basically stopped improving — at least at the pace that I was hoping for.
+I think this difference in mindset is pretty fundamental. My view of Agile involves continuous improvement — always inspecting and adapting our processes. I suppose that means that my preferred flavor of Agile is “Kaizen“. But other people don’t see improvement and change as a constant — they see each change as a means to an end. I’m starting to realize that neither viewpoint is objectively correct. Maybe they’re both fine viewpoints to have. Maybe I shouldn’t be so hard on myself and view that engagement as a failure, especially if my teammates view it as a success. Maybe perfection is the enemy of the good. And maybe I need to learn to be happy with “good enough”.
++
Web Development, Ruby on Rails, Open Source
+I ran into some former colleagues recently, from a company where I had worked to help transform the team to be more Agile. They’ve gone through some reorganization and management changes recently. One of the guys said that their team culture has helped them maintain quality in the face of those changes. This struck me as odd, since I had considered the work I had done there as somewhat of a disappointment. While I felt I had made a small dent, I didn’t feel like I’d made a true Agile transformation. Much of what I had taught didn’t seem to “stick”.
+Later that night I thought about why my opinion of the team and his opinion were so different. There are a lot of reasons why an Agile “transformation” could fail. It could be due to lack of support from management. Or even worse, not getting the team members to buy into the ideas — usually due to fear of change. But while those had some effect in this case, they weren’t really the main issues. Now that I’ve had some time and some distance from that team, I’ve gained some clarity on what the real issues were.
+I think the reason that I think this transformation was a failure was due to the continued pace of change that true Agile requires. Basically the team experienced “change fatigue”, where everything keeps changing and you feel like you can never catch your breath. But the more interesting thing is how our perceptions differed. He seemed to think that the transformation was a success — they’re doing things better than they used to. I view it as more of a failure, because they basically stopped improving — at least at the pace that I was hoping for.
+I think this difference in mindset is pretty fundamental. My view of Agile involves continuous improvement — always inspecting and adapting our processes. I suppose that means that my preferred flavor of Agile is “Kaizen“. But other people don’t see improvement and change as a constant — they see each change as a means to an end. I’m starting to realize that neither viewpoint is objectively correct. Maybe they’re both fine viewpoints to have. Maybe I shouldn’t be so hard on myself and view that engagement as a failure, especially if my teammates view it as a success. Maybe perfection is the enemy of the good. And maybe I need to learn to be happy with “good enough”.
++
Web Development, Ruby on Rails, Open Source
+On a recent episode (78) of This Agile Life, my fellow hosts talked about when to do Test-Driven Development (TDD). They all said that you should always do TDD — at least for anything that will go into production; there’s an exception for experimenting or “spiking”.
+I wasn’t on that episode, but later commented on the topic. (Episode 83 — which wasn’t really all that great.) My take was slightly different. I said that you should do TDD only when the benefits outweigh the costs. Unfortunately, we usually greatly underestimate the benefits. And the costs often seem high at first, because it takes some time to get good at writing automated tests. Not to mention that both the costs and the benefits are usually hard to measure.
+What is the cost of writing automated tests? I’ve asked this question before and recorded the answers (inasmuch as we have them) in a previous blog entry. TDD costs us about 10-30% in short-term productivity. The benefit that they found was a reduction in bugs by 30-90%, and a decrease in code complexity by about 30%.
+But what about when the costs are higher than the normal 10 to 30 percent? One good example of this is when there’s no test framework for the situation you’re testing. This might be a new language or framework that you’re working with. More likely it’s a complex API that you have to mock out. So that could increase the cost of automated testing so as to outweigh the benefits — especially on a short project. I could imagine situations where the cost of writing the mocks could eat up more than the project itself.
+Another case where we might consider skipping testing is when we’re more concerned about time to market than quality. This is almost always a mistake. Your code will almost always last longer than you expect. (Remember Y2K?) And if the code lasts longer than you expect, that means you’ll have to deal with bugs that whole time. But we have to work with the information we have at the time we make our decisions. And sometimes that might tell us that time to market is more important than anything.
+One final case I can imagine is when a true expert is coding something that they’re very familiar with. I could picture someone like Uncle Bob writing code (in a language that he’s familiar with) without tests just as effectively as I could write code with tests.
+But these situations should not be common; they’re edge cases. In almost all real-world cases, TDD is the right thing to do. Don’t forget, TDD is also a design discipline — it helps you design a better API. So keep doing TDD. But as with any practice, don’t do it blindly without considering why we’re doing it. Make sure you understand the costs, and whether the benefits outweigh the costs.
+I think it’s important for people to realize that TDD is *really* hard when you’re first learning how to just code in general. In that case, I think it’s useful to let people spike out something and figure out how to do it and then redo it test first. I’ve always had a hard time when people will tell me to do it test-first, and I’m sitting there thinking that I don’t even know how to do it without tests much less test-first. Luckily, I stuck with it, but I know a lot of beginners who got burnt out on that.
+Applying TDD in Your Company is **More Important than Ever**!
+This methodology will increase your product’s quality and will allow you (after a while) to deliver features faster.
Here is why –
+http://dennis-nerush.blogspot.co.il/2015/11/applying-tdd-in-your-company-is-more.html
Web Development, Ruby on Rails, Open Source
+The Agile Manifesto was written in 2001, as a way to explain the common values amongst several “light-weight” software development methodologies that had come about. The term “Agile” was chosen as a shorthand for those commonalities.
+Once “Agile” started to show success, we started to see many people use the term to market their products and services, whether or not they really believed in the values and principles of the Agile Manifesto. It’s gotten to the point where some of us don’t see much value in using the term “Agile” any more. Even some of those involved in creating the manifesto have suggested new terms. Dave Thomas suggests “Agility” and Andy Hunt has started working on something called GROWS. Personally, I’m considering going back to the term “Extreme Programming”, even though I’ve incorporated ideas from other Agile methodologies.
+It recently occurred to me that Agile, when done “right”, is closely aligned with the happiness of the team members. This is really interesting, because it aligns the interests of the employees and the business — a win-win situation. My next thought was that maybe the next step after “Agile” will be a focus on happiness and motivation.
+I’ve recently been thinking about personal motivation lately, in the context of team practices. According to Daniel Pink’s book Drive, people are motivated by autonomy, mastery, and purpose. I personally add a fourth that can sometimes trump the other three: identity. And of course, happiness can also be motivating — both in the attempt to achieve happiness and in just being happy. (I suspect that happiness is more of a parallel to motivation than a cause though.)
+There are a couple different ways that happiness can be achieved at work. The traditional way is for work to be a means to an end. In this view, the purpose of your job is to provide the money to live your life (outside of work) the way that you want to live it. There’s nothing wrong with this way of thinking. But for the lucky few, we can work on something that makes us happy in and of itself. That’s generally done by finding a job doing something that we enjoy.
+But perhaps that’s thinking about things the wrong way. For one, plenty of people who have gone that route are still unhappy at work. I think a lot of that has to do more with the context surrounding the work than the work itself. Maybe you’ve got a lousy manager. Maybe you don’t like the people you work with. Maybe the tools you have to work with are bad. Maybe the processes add a lot of unnecessary tedium.
+So maybe we need to find ways to be happier at work. Most of the Agile practices seem to make team members happy. For example, replacing a light-weight process for a heavier process always makes me happy. And I typically leave retrospectives in a good mood. So that’s a good starting point. But we should see if we can take the idea further. If we take employee happiness as a core value, where can we go? What kind of practices would we want to add? Please share any ideas in the comments below.
+Web Development, Ruby on Rails, Open Source
+I’ve been working on application architectures based on Uncle Bob’s Ruby Midwest talk, following the hexagonal architectural pattern. I posted an article a couple months ago showing a way that works fairly well in Rails, and some accompanying Rails example code. But there was one thing I wasn’t quite happy with.
+The problem is that we used callbacks (actually, a publish/subscribe mechanism) in a situation where they don’t seem to quite fit:
+ def show
+ interactor.on(:display) { |order| render order }
+ interactor.on(:not_found) { |order_id| render status: 404 }
+ interactor.get(params[:id])
+ end
+What we really want is to respond in different ways, depending on the result of the call to interactor.get(). There’s no good reason to define the responses before the call. It makes a lot more sense to define the responses after the call, because they’ll happen after the call. I’d much prefer that the code be written in the order that it will be run.
I discussed this problem with my friend and colleague, Amos King. We came up with a better solution, which puts things back in the right order:
+ def show
+ interactor.get(params[:id]) do |on|
+ on.display { |order| render order }
+ on.not_found { |order_id| render status: 404 }
+ end
+ end
+He even wrote a small library to do this, which he called Riposte. I’m not sure what to call this pattern, but it seems to work pretty well in this situation. I suppose that they’re still technically callbacks, because they’re passed in in the block that’s passed in to the call to interactor.get(). But due to the magic of Ruby blocks, we get to put them in the order they should be.
Riposte also gives you the option of using the response object directly, instead of passing a block:
+ def show
+ on = interactor.get(params[:id])
+ on.display { |order| render order }
+ on.not_found { |order_id| render status: 404 }
+ end
+This shows that it’s just returning an object, with the twist that the response object has methods that take blocks. The nested blocks variant is really the same thing, except that it’s yielding to the response object instead of returning it.
+I’ve decide that is the pattern I’d like to use for interactions and their callers within Ruby hexagonal architecture.
+I’ve started working on my own framework in Ruby in the past couple days. It’s built upon my recent work at understanding Uncle Bob’s Ruby Midwest 2011 talk, and his article on Clean Architecture, and the resulting hexagonal architecture (AKA ports and adapters).
+Somehow my research in that vein led me to Gary Bernhardt’s Boundaries talk. I’ve read a lot about the talk, and knew about the idea of “functional core / imperative shell”. And I’ve worked with a lot of similar ideas lately. But I believe this is the first time that I actually watched the whole video.
+Even after having read a lot about similar ideas, it was pretty mind-expanding. Gary’s really good at presenting these kinds of ideas in a simple way.
+OOP as usually taught includes encapsulation of data together with behavior, with mutable objects. Functional programming separates data and behavior, with mostly immutable data. From experience, encapsulating data and behavior together seems helpful. But experience also shows that immutability is useful. So it would be good to have both of those together. This is something I’ve been thinking for a few years — how best do we get both?
+Gary calls the combination “FauxO”. Logic and data are still combined, but there’s no mutation. Anywhere OOP would normally have mutation would just generate a new object. There’s no language restriction involved in enforcing immutability — just discipline.
+But without mutability, it’s hard to do IO and maintain state. So Gary’s solution is to encapsulate as much as possible into an immutable (functional or FauxO) core, and around that, use an imperative (traditional OOP) shell. The functional core contains the bulk of the logic, and the imperative shell is a glue layer that handles the real world, including disk, network, and other I/O.
+The result of this is that the shell has fewer paths, but more dependencies. The core contains no dependencies, but encapsulates the different logic paths. So we’re encapsulating dependencies on one side, and business logic on the other side. Or put another way, the way to figure out the separation is by doing as much as you can without mutation, and then encapsulating the mutation separately.
+I love how this naturally breaks things up, so that the core is all testable with unit tests, and the imperative shell is tested with integration tests. And since the shell has few or no logic paths, you get the testing pyramid, with more unit tests and fewer integration tests. The whole thing ends up being quite beautiful. Tests end up being very fast without any extra effort — not even stubbing or mocking. This tells us that things have been decomposed very well — an elegant design.
+Gary makes the case that immutable objects can be treated as values, and passed across boundaries. Even process boundaries. This is something I’ve noticed as I’ve been working on my own Uncle Bob style hexagonal framework, but nobody in that camp ever mentioned that — they prefer DTOs or something more like hashes. I’m completely against hashes, because of the “stringly-typed” problem. And I don’t see much advantage in a DTO if I’ve got an immutable object; I’d be basically copying the object to an almost identical object. And I’d be losing any laziness possible for derived values within the original immutable object.
+It’s striking to me how Gary’s image of an imperative shell around a functional core, plus Net, Disk, and State outside of the shell mirror’s Uncle Bob’s concentric circles. Uncle Bob has entities in the middle, surrounded by use cases, surrounded by Web, DB, and UI.
+Another advantage that Gary shows is that breaking things up this way allows easy concurrency. In his example, he shows using the actor model — either just using threads and queues, or an actor library (or language feature).
+After several years of thinking about the architectural issues seen in most large Rails apps, I’m starting to come to an understanding of how to combine all these ideas and come up with an architecture that will work better.
++
Web Development, Ruby on Rails, Open Source
+I’ve started working on my own framework in Ruby in the past couple days. It’s built upon my recent work at understanding Uncle Bob’s Ruby Midwest 2011 talk, and his article on Clean Architecture, and the resulting hexagonal architecture (AKA ports and adapters).
+Somehow my research in that vein led me to Gary Bernhardt’s Boundaries talk. I’ve read a lot about the talk, and knew about the idea of “functional core / imperative shell”. And I’ve worked with a lot of similar ideas lately. But I believe this is the first time that I actually watched the whole video.
+Even after having read a lot about similar ideas, it was pretty mind-expanding. Gary’s really good at presenting these kinds of ideas in a simple way.
+OOP as usually taught includes encapsulation of data together with behavior, with mutable objects. Functional programming separates data and behavior, with mostly immutable data. From experience, encapsulating data and behavior together seems helpful. But experience also shows that immutability is useful. So it would be good to have both of those together. This is something I’ve been thinking for a few years — how best do we get both?
+Gary calls the combination “FauxO”. Logic and data are still combined, but there’s no mutation. Anywhere OOP would normally have mutation would just generate a new object. There’s no language restriction involved in enforcing immutability — just discipline.
+But without mutability, it’s hard to do IO and maintain state. So Gary’s solution is to encapsulate as much as possible into an immutable (functional or FauxO) core, and around that, use an imperative (traditional OOP) shell. The functional core contains the bulk of the logic, and the imperative shell is a glue layer that handles the real world, including disk, network, and other I/O.
+The result of this is that the shell has fewer paths, but more dependencies. The core contains no dependencies, but encapsulates the different logic paths. So we’re encapsulating dependencies on one side, and business logic on the other side. Or put another way, the way to figure out the separation is by doing as much as you can without mutation, and then encapsulating the mutation separately.
+I love how this naturally breaks things up, so that the core is all testable with unit tests, and the imperative shell is tested with integration tests. And since the shell has few or no logic paths, you get the testing pyramid, with more unit tests and fewer integration tests. The whole thing ends up being quite beautiful. Tests end up being very fast without any extra effort — not even stubbing or mocking. This tells us that things have been decomposed very well — an elegant design.
+Gary makes the case that immutable objects can be treated as values, and passed across boundaries. Even process boundaries. This is something I’ve noticed as I’ve been working on my own Uncle Bob style hexagonal framework, but nobody in that camp ever mentioned that — they prefer DTOs or something more like hashes. I’m completely against hashes, because of the “stringly-typed” problem. And I don’t see much advantage in a DTO if I’ve got an immutable object; I’d be basically copying the object to an almost identical object. And I’d be losing any laziness possible for derived values within the original immutable object.
+It’s striking to me how Gary’s image of an imperative shell around a functional core, plus Net, Disk, and State outside of the shell mirror’s Uncle Bob’s concentric circles. Uncle Bob has entities in the middle, surrounded by use cases, surrounded by Web, DB, and UI.
+Another advantage that Gary shows is that breaking things up this way allows easy concurrency. In his example, he shows using the actor model — either just using threads and queues, or an actor library (or language feature).
+After several years of thinking about the architectural issues seen in most large Rails apps, I’m starting to come to an understanding of how to combine all these ideas and come up with an architecture that will work better.
++
Web Development, Ruby on Rails, Open Source
+I’ve been working on application architectures based on Uncle Bob’s Ruby Midwest talk, following the hexagonal architectural pattern. I posted an article a couple months ago showing a way that works fairly well in Rails, and some accompanying Rails example code. But there was one thing I wasn’t quite happy with.
+The problem is that we used callbacks (actually, a publish/subscribe mechanism) in a situation where they don’t seem to quite fit:
+ def show
+ interactor.on(:display) { |order| render order }
+ interactor.on(:not_found) { |order_id| render status: 404 }
+ interactor.get(params[:id])
+ end
+What we really want is to respond in different ways, depending on the result of the call to interactor.get(). There’s no good reason to define the responses before the call. It makes a lot more sense to define the responses after the call, because they’ll happen after the call. I’d much prefer that the code be written in the order that it will be run.
I discussed this problem with my friend and colleague, Amos King. We came up with a better solution, which puts things back in the right order:
+ def show
+ interactor.get(params[:id]) do |on|
+ on.display { |order| render order }
+ on.not_found { |order_id| render status: 404 }
+ end
+ end
+He even wrote a small library to do this, which he called Riposte. I’m not sure what to call this pattern, but it seems to work pretty well in this situation. I suppose that they’re still technically callbacks, because they’re passed in in the block that’s passed in to the call to interactor.get(). But due to the magic of Ruby blocks, we get to put them in the order they should be.
Riposte also gives you the option of using the response object directly, instead of passing a block:
+ def show
+ on = interactor.get(params[:id])
+ on.display { |order| render order }
+ on.not_found { |order_id| render status: 404 }
+ end
+This shows that it’s just returning an object, with the twist that the response object has methods that take blocks. The nested blocks variant is really the same thing, except that it’s yielding to the response object instead of returning it.
+I’ve decide that is the pattern I’d like to use for interactions and their callers within Ruby hexagonal architecture.
+Web Development, Ruby on Rails, Open Source
+It all started with an email about a WebInspect report. It listed a buffer overflow, which we had marked as a false positive. I read the WebInspect report carefully, and found a note at the bottom that said you could test manually to confirm whether it was a false positive or not. Unfortunately, the manual test listed had a few problems. First, it jammed the lines together, without the proper line-breaks. Second, it assumed the site was using HTTP, not HTTPS, so used telnet. Third, it was testing against a page that didn’t exist, giving a 404. Keeping those in mind, I tried the manual test using the openssl s_client command:
openssl s_client -quiet -connect mysite.example.com:443 +POST /login HTTP/1.1 +Host: mysite.example.com +Transfer-Encoding: chunked + +c00000000+
The test terminated immediately. The report said that this meant that the server was vulnerable to a buffer overflow and arbitrary code execution.
+At first, we thought this was caused by Apache or Tomcat, or possibly the application code. But the reported vulnerability was an Apache CVE from 2002 (CVE-2002-0392), fixed by vendors long ago. After a while, we realized that if we hit the servers directly, we did not get the indication of a vulnerability. If we hit the site through the F5 VIP, we saw the immediate termination of the connection. The issue is with handling of HTTP chunked encoding. Nginx had a similar issue in 2013 (CVE-2013-2028).
+So we turned our attention to the F5 load balancers. We were able to confirm that other sites using F5 load balancers were exhibiting the same behavior. We also confirmed that WebInspect run against the servers directly did not show the issue (even as a false positive). We reported the issue to F5, and they are looking into it.
+I’m disclosing this publicly now for a few reasons. First, I’m not a security researcher, and almost nobody follows my blog — especially people looking for security issues that could be exploited. Second, I’ve not developed a payload, so I have no idea whether this is exploitable. But at this point, it’s merely a potential vulnerability. I’m not sure I’ll even spend the time to research and create a payload to prove the vulnerability. If I do, I’ll be more careful with the disclosure.
++
Web Development, Ruby on Rails, Open Source
+It all started with an email about a WebInspect report. It listed a buffer overflow, which we had marked as a false positive. I read the WebInspect report carefully, and found a note at the bottom that said you could test manually to confirm whether it was a false positive or not. Unfortunately, the manual test listed had a few problems. First, it jammed the lines together, without the proper line-breaks. Second, it assumed the site was using HTTP, not HTTPS, so used telnet. Third, it was testing against a page that didn’t exist, giving a 404. Keeping those in mind, I tried the manual test using the openssl s_client command:
openssl s_client -quiet -connect mysite.example.com:443 +POST /login HTTP/1.1 +Host: mysite.example.com +Transfer-Encoding: chunked + +c00000000+
The test terminated immediately. The report said that this meant that the server was vulnerable to a buffer overflow and arbitrary code execution.
+At first, we thought this was caused by Apache or Tomcat, or possibly the application code. But the reported vulnerability was an Apache CVE from 2002 (CVE-2002-0392), fixed by vendors long ago. After a while, we realized that if we hit the servers directly, we did not get the indication of a vulnerability. If we hit the site through the F5 VIP, we saw the immediate termination of the connection. The issue is with handling of HTTP chunked encoding. Nginx had a similar issue in 2013 (CVE-2013-2028).
+So we turned our attention to the F5 load balancers. We were able to confirm that other sites using F5 load balancers were exhibiting the same behavior. We also confirmed that WebInspect run against the servers directly did not show the issue (even as a false positive). We reported the issue to F5, and they are looking into it.
+I’m disclosing this publicly now for a few reasons. First, I’m not a security researcher, and almost nobody follows my blog — especially people looking for security issues that could be exploited. Second, I’ve not developed a payload, so I have no idea whether this is exploitable. But at this point, it’s merely a potential vulnerability. I’m not sure I’ll even spend the time to research and create a payload to prove the vulnerability. If I do, I’ll be more careful with the disclosure.
++
Web Development, Ruby on Rails, Open Source
+I’m a big proponent of Agile (mostly XP; I’m mostly anti-Scrum) and I’ve contributed some to the #noestimates “movement”.
+I don’t really mean that nobody should ever estimate anything. I mean that I’ve never seen useful (fine-grained) estimates anywhere. Here are some of the problems with estimates that I’ve seen frequently:
+I’ll note that most of these pit management against the team, instead of working together toward a common cause. Most of the practices also lead to seriously demoralizing the team. And most of the time, the estimates aren’t really even taken into account very much.
+My advice is to first understand the value of a project before you consider estimating the costs. The estimation at this point will be very rough, so make sure that you have a very wide margin between the expected value and the rough estimate of the cost. If you’re pretty certain of the expected value, I’d probably want to make sure I could still be profitable even if it took 3 or 4 times as long to complete as the rough estimate. And if there’s uncertainty in the expected value, much more.
+Another way to mitigate the risk of throwing money at something that’s not going to have positive ROI is to reduce the feedback loop. Order the work so that the tasks are ranked in order of value to the customer. (Realistically, you’ll have dependencies of tasks to worry about, and should consider effort involved too.) So work on the most valuable feature first — get that out into production as soon as possible. Once that’s done, you can assess if your ROI is positive or not. Keep iterating in this fashion, working on the features that will provide the most value first. Keep assessing your ROI, and stop when the ROI is no longer worth it, compared to other projects the team could be working on.
+At a fine-grained level, if you’re using story points, I’d ask you to do the math to see if just counting the stories would be as effective at predicting how much will be done over time as using the story points. If so, you can save the time the team spends on estimating stories. I’d still recommend spending time talking about stories so that everyone has a shared understanding of what needs to be done, and to break stories up into a smaller, more manageable size — with one acceptance criteria per story. Also take a look to see if empirical average cycle time (how long it takes a single story to move from start to finish) might provide you the predictive power just as well as estimates. (I.e. is it bandwidth or latency that really provides the predictive power you’re looking for?)
+And don’t forget Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.
+While creating a web page isn’t too difficult, there are a lot of moving parts involved in creating an effective website. We’ve written up this checklist as a guide for anyone who has decided that they need a website.
+This list is for a basic static website. A web application will require significantly more effort. We’re working on a separate checklist for web apps.
+You’ll probably want your own domain name.
+You’ll need to have someone take care of the servers that tell the world what server addresses your domain name corresponds to.
+You’ll need servers to host your web site on. There are a lot of options available, from virtual hosts (a Linux server where you control everything) to application-specific services.
+Designing and developing the site can vary from picking an existing template and adding content, to developing a full web application.
+What other services do you need, besides just the web site?
+Over the lifetime of the site, you’ll likely pay more in maintenance costs than the upfront costs.
++
Web Development, Ruby on Rails, Open Source
+While creating a web page isn’t too difficult, there are a lot of moving parts involved in creating an effective website. We’ve written up this checklist as a guide for anyone who has decided that they need a website.
+This list is for a basic static website. A web application will require significantly more effort. We’re working on a separate checklist for web apps.
+You’ll probably want your own domain name.
+You’ll need to have someone take care of the servers that tell the world what server addresses your domain name corresponds to.
+You’ll need servers to host your web site on. There are a lot of options available, from virtual hosts (a Linux server where you control everything) to application-specific services.
+Designing and developing the site can vary from picking an existing template and adding content, to developing a full web application.
+What other services do you need, besides just the web site?
+Over the lifetime of the site, you’ll likely pay more in maintenance costs than the upfront costs.
++
Web Development, Ruby on Rails, Open Source
+I’m a big proponent of Agile (mostly XP; I’m mostly anti-Scrum) and I’ve contributed some to the #noestimates “movement”.
+I don’t really mean that nobody should ever estimate anything. I mean that I’ve never seen useful (fine-grained) estimates anywhere. Here are some of the problems with estimates that I’ve seen frequently:
+I’ll note that most of these pit management against the team, instead of working together toward a common cause. Most of the practices also lead to seriously demoralizing the team. And most of the time, the estimates aren’t really even taken into account very much.
+My advice is to first understand the value of a project before you consider estimating the costs. The estimation at this point will be very rough, so make sure that you have a very wide margin between the expected value and the rough estimate of the cost. If you’re pretty certain of the expected value, I’d probably want to make sure I could still be profitable even if it took 3 or 4 times as long to complete as the rough estimate. And if there’s uncertainty in the expected value, much more.
+Another way to mitigate the risk of throwing money at something that’s not going to have positive ROI is to reduce the feedback loop. Order the work so that the tasks are ranked in order of value to the customer. (Realistically, you’ll have dependencies of tasks to worry about, and should consider effort involved too.) So work on the most valuable feature first — get that out into production as soon as possible. Once that’s done, you can assess if your ROI is positive or not. Keep iterating in this fashion, working on the features that will provide the most value first. Keep assessing your ROI, and stop when the ROI is no longer worth it, compared to other projects the team could be working on.
+At a fine-grained level, if you’re using story points, I’d ask you to do the math to see if just counting the stories would be as effective at predicting how much will be done over time as using the story points. If so, you can save the time the team spends on estimating stories. I’d still recommend spending time talking about stories so that everyone has a shared understanding of what needs to be done, and to break stories up into a smaller, more manageable size — with one acceptance criteria per story. Also take a look to see if empirical average cycle time (how long it takes a single story to move from start to finish) might provide you the predictive power just as well as estimates. (I.e. is it bandwidth or latency that really provides the predictive power you’re looking for?)
+And don’t forget Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.
+Web Development, Ruby on Rails, Open Source
+I’m wrapping up my current consulting gig at Mercy in December, and starting a new gig at CenturyLink. I’m a software developer, but that’s only a part of what I do. What I really do is join a team and help them improve the way they work — both their processes and their technical skills.
+I think this is a key differentiator for me as a consultant. Most consultants (and Agile coaches) come in and tell people what to do. I don’t like to just tell people what to do. I’d much prefer to work side-by-side with them, getting a better understanding of what their challenges are. Once I have a better understanding of the challenges, I’m able to better brainstorm some ideas to try. Then we can experiment to see what will work and what won’t.
+Instead of telling people what to do, I show them how. Most people learn better from seeing than from hearing. They also learn better if you explain how and why, not just what. So showing them how to do something is more effective than telling them. By showing and doing, you can also set a good example. This is especially important when collaboration is a large part of what needs to be improved.
+I’ve found that this style of consulting is more highly respected by everyone. I build trust with developers by working closely with them. Managers like to keep me around once they see how effective these methods can be, so the gigs I take on tend to last relatively long.
+The biggest problem I have is explaining how this works. I don’t really know what to put on my résumé. Sometimes I call myself an Agile practitioner, and sometimes an Agile player/coach. But those aren’t terribly satisfying descriptions. I’m considering actually putting “I help teams improve the way they work — both their processes and their technical skills” on the résumé. But that seems awkward, and misses the show versus tell part. I’d be open to any suggestions.
++
I facilitated a retrospective today; it was one of the best retros I’ve ever been involved with. I figured out what activities I wanted to do earlier in the morning. They were really quite simple. I wanted to focus on happiness.
+I started with two questions that I’ve used with teams before, to some success (although not so successful for one particular team). The first question I asked was “How happy are you at work?” I had them put a rating from 0 to 10, with 0 meaning they should have quit last week, and 10 meaning they couldn’t imaging being happier at work.
+The answers were mostly 7s and 8s, with a 5 and a 9. The average came to 7.5, which is pretty good. The 5 concerns me a bit, especially that it’s 2 points lower than anyone else’s answer.
+The next question I asked was “How effective do you think the teams is?”. Again, from 0 to 10, with 0 meaning they can’t accomplish anything, and 10 meaning you couldn’t imagine a more effective team.
+When I ask both of these questions, the scores are always highly correlated. If your team isn’t doing good work, it’ll make you unhappy. And if you are unhappy, you’re less likely to do your best work. This team was no different; the 5 and 9 became a 6 and a 10, and most of the 7s became 8s, for an average of just under 8.
+The next question I asked was “What makes you happy at work?”. The answers were mostly about the teamwork and teammates. This went quicker than I expected. At this point, I was worried the retro would only last a little more than 30 minutes.
+The final question I asked was “What would make you happier at work?”. This was the real pay-off. We spent about half an hour just talking about the things that would make us happier, and what we could do to improve our happiness. We came up with 10 potential action items. I usually limit teams to trying 3 or 4 action items, but most of the items are quite small, so we’re going to try 6 of them. One is just observing another team’s standup meetings, to see how they’re using their time effectively.
+Everyone went away feeling that this was a really good retro. It felt good to focus on happiness. Happiness is something I’ve been talking a lot about on the This Agile Life podcast, and it felt good to take some action on it. I’ve done “positive-only” retros before, but this one felt even better than that, by specifically targeting happiness and how we can achieve it.
+I’m surprised that I haven’t gotten this story down in print before. It’s something I’ve mentioned many times — including a few times on the podcast. It’s a great story about the power of retrospectives, and it’s a great story about the power of a blameless post-mortem.
+I don’t recall all the specifics at this point. It was about 5 years ago. I’d just noticed that Arun had made some sort of mistake. That’s fine, people make mistakes. The thing that was different about his mistake was that I had made the same mistake about a week prior. And Amos had made the same mistake about a week before that.
+Noticing a pattern of mistakes, Amos and I called an impromptu retrospective. We gathered all the developers into a conference room. We explained the problem that we were running into. At first, Arun was defensive. That’s understandable; he thought we were there to come down on him, to lay blame. But we made it clear that we weren’t focusing on him. We admitted that we had also made the same mistake recently. We weren’t there to lay blame; we were there to figure out how our team could stop making the mistake. It took Arun a few minutes to get over the defensiveness.
+With the defensiveness out of the way, we could focus on the issue at hand. We were able to figure out the root cause of us all making the mistake. (I don’t know if we played the “5 whys” game, but I’m sure we effectively did something similar.) And with that, we were able to change our process, so that nobody else would make the same mistake again.
+There are 2 important points to this story. First, you don’t have to wait until a scheduled retrospective to hold a retrospective. This one was impromptu, and it’s the best one we ever had. We saw a problem, addressed it, and found a solution in less than an hour. Had we waited until the end of the week, we would have forgotten some of the details, and wouldn’t have been as effective at solving the problem. Second, when addressing problems, take your ego out of the equation. If you’re in a position of authority, take the blame — but never place blame. Focus on what’s important — solving the problem.
+And don’t forget the Retrospective Prime Directive:
++Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
+
Web Development, Ruby on Rails, Open Source
+I’m surprised that I haven’t gotten this story down in print before. It’s something I’ve mentioned many times — including a few times on the podcast. It’s a great story about the power of retrospectives, and it’s a great story about the power of a blameless post-mortem.
+I don’t recall all the specifics at this point. It was about 5 years ago. I’d just noticed that Arun had made some sort of mistake. That’s fine, people make mistakes. The thing that was different about his mistake was that I had made the same mistake about a week prior. And Amos had made the same mistake about a week before that.
+Noticing a pattern of mistakes, Amos and I called an impromptu retrospective. We gathered all the developers into a conference room. We explained the problem that we were running into. At first, Arun was defensive. That’s understandable; he thought we were there to come down on him, to lay blame. But we made it clear that we weren’t focusing on him. We admitted that we had also made the same mistake recently. We weren’t there to lay blame; we were there to figure out how our team could stop making the mistake. It took Arun a few minutes to get over the defensiveness.
+With the defensiveness out of the way, we could focus on the issue at hand. We were able to figure out the root cause of us all making the mistake. (I don’t know if we played the “5 whys” game, but I’m sure we effectively did something similar.) And with that, we were able to change our process, so that nobody else would make the same mistake again.
+There are 2 important points to this story. First, you don’t have to wait until a scheduled retrospective to hold a retrospective. This one was impromptu, and it’s the best one we ever had. We saw a problem, addressed it, and found a solution in less than an hour. Had we waited until the end of the week, we would have forgotten some of the details, and wouldn’t have been as effective at solving the problem. Second, when addressing problems, take your ego out of the equation. If you’re in a position of authority, take the blame — but never place blame. Focus on what’s important — solving the problem.
+And don’t forget the Retrospective Prime Directive:
++Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
+
Web Development, Ruby on Rails, Open Source
+I facilitated a retrospective today; it was one of the best retros I’ve ever been involved with. I figured out what activities I wanted to do earlier in the morning. They were really quite simple. I wanted to focus on happiness.
+I started with two questions that I’ve used with teams before, to some success (although not so successful for one particular team). The first question I asked was “How happy are you at work?” I had them put a rating from 0 to 10, with 0 meaning they should have quit last week, and 10 meaning they couldn’t imaging being happier at work.
+The answers were mostly 7s and 8s, with a 5 and a 9. The average came to 7.5, which is pretty good. The 5 concerns me a bit, especially that it’s 2 points lower than anyone else’s answer.
+The next question I asked was “How effective do you think the teams is?”. Again, from 0 to 10, with 0 meaning they can’t accomplish anything, and 10 meaning you couldn’t imagine a more effective team.
+When I ask both of these questions, the scores are always highly correlated. If your team isn’t doing good work, it’ll make you unhappy. And if you are unhappy, you’re less likely to do your best work. This team was no different; the 5 and 9 became a 6 and a 10, and most of the 7s became 8s, for an average of just under 8.
+The next question I asked was “What makes you happy at work?”. The answers were mostly about the teamwork and teammates. This went quicker than I expected. At this point, I was worried the retro would only last a little more than 30 minutes.
+The final question I asked was “What would make you happier at work?”. This was the real pay-off. We spent about half an hour just talking about the things that would make us happier, and what we could do to improve our happiness. We came up with 10 potential action items. I usually limit teams to trying 3 or 4 action items, but most of the items are quite small, so we’re going to try 6 of them. One is just observing another team’s standup meetings, to see how they’re using their time effectively.
+Everyone went away feeling that this was a really good retro. It felt good to focus on happiness. Happiness is something I’ve been talking a lot about on the This Agile Life podcast, and it felt good to take some action on it. I’ve done “positive-only” retros before, but this one felt even better than that, by specifically targeting happiness and how we can achieve it.
+Web Development, Ruby on Rails, Open Source
+I’m wrapping up my current consulting gig at Mercy in December, and starting a new gig at CenturyLink. I’m a software developer, but that’s only a part of what I do. What I really do is join a team and help them improve the way they work — both their processes and their technical skills.
+I think this is a key differentiator for me as a consultant. Most consultants (and Agile coaches) come in and tell people what to do. I don’t like to just tell people what to do. I’d much prefer to work side-by-side with them, getting a better understanding of what their challenges are. Once I have a better understanding of the challenges, I’m able to better brainstorm some ideas to try. Then we can experiment to see what will work and what won’t.
+Instead of telling people what to do, I show them how. Most people learn better from seeing than from hearing. They also learn better if you explain how and why, not just what. So showing them how to do something is more effective than telling them. By showing and doing, you can also set a good example. This is especially important when collaboration is a large part of what needs to be improved.
+I’ve found that this style of consulting is more highly respected by everyone. I build trust with developers by working closely with them. Managers like to keep me around once they see how effective these methods can be, so the gigs I take on tend to last relatively long.
+The biggest problem I have is explaining how this works. I don’t really know what to put on my résumé. Sometimes I call myself an Agile practitioner, and sometimes an Agile player/coach. But those aren’t terribly satisfying descriptions. I’m considering actually putting “I help teams improve the way they work — both their processes and their technical skills” on the résumé. But that seems awkward, and misses the show versus tell part. I’d be open to any suggestions.
++
Web Development, Ruby on Rails, Open Source
+It’s that time of year again — time for a retrospective on how I did on my goals for the year. I had 5 main goals for 2015:
+I got pretty lucky on this one. My main contract with Mercy got extended several times. Amos and I must have been doing a good job of keeping the customer happy. We even made it through a couple rounds of layoffs. I’m wrapping up the gig at Mercy now. I’m working one day a week there, as the project winds down.
+I also started a new gig this month at CenturyLink. I’m working on a cloud development team. Our current project involves selling WordPress as a service. The manager had been courting me for most of the year. I’m excited about my new role; I’ll be writing about it in a blog post soon.
+I set a goal in 2014 to give my first conference talk. I accomplished that, giving an ambitious talk at RubyConf. I enjoyed having done that, and vowed to do more conference speaking.
+I gave 3 conference talks in 2015. I gave a workshop on HTTP at RailsConf. I talked about immutable infrastructure at Madison+ Ruby. At RubyConf, I gave a talk on a micro-ORM I wrote. I also gave a lightning talk about Agile estimation (#noestimates).
+I was an alternate speaker at Windy City Rails, but did not give my talk on Alternatives to ActiveRecord. I also went to Strange Loop, mainly to see several friends and acquaintances speak.
+I wrote 24 blog articles this year. That’s about one every other week. What really kept me going was participating in a writing pact. When the pact was going, I had a 75% blogging rate. That’s pretty good.
+I’m not so sure about the quality of my blog writing though. I know that practicing writing is supposed to make you better. I know I wrote some really good articles over the past year, but I think I also wrote some articles that weren’t very good. I think sometimes the deadline has caused more harm than good. I’m not really sure what to do about that; perhaps just pushing on is the right answer.
+I’ve taken a lot of notes on the design of my programming language. Any time I learn something interesting about another language, or come up with another idea, I write it down.
+But I haven’t worked on the implementation. (I last worked on the implementation in 2014.) I should be experimenting with some ideas, implementing them to see how they work out. I’ve even kicked around the idea of starting with a Forth variant, just to get something working quickly.
+I haven’t written any articles on my ideas this year either. My notes are pretty extensive, and it would be good to write some articles to help get my thoughts straight.
+I’ve got some things to say about Agile, and want to write a book to express those ideas. I’ve made a start — I’ve got the chapters outlines, and have started on a few chapters. But I haven’t made as much progress as I’d like to. I shared what I’ve got with Amos, and he showed some interest in pairing with me on the writing. Hopefully we’ll work on it together in 2016 and publish it.
+There were a few other accomplishments that weren’t explicitly on my list, but I’d like to call attention to.
+I’ve continued participating on the This Agile Life podcast. I was in 12 of the 33 episodes that were recorded in 2015. I hope to participate in more in 2016. We’re considering scheduling a standard recording night each week, which might help us record more regularly.
+I recently took over as maintainer of Virtus, a library to declare attributes for Ruby model classes. I haven’t done a lot yet, since I’ve been busy with travel, vacation, and holidays. But I hope to catch up with all the pending pull requests and issues in the next month or so.
+The accomplishment I’m most proud of is mentoring for the Roy Clay Sr. Tech Impact program. This is a program begun as a result of the Ferguson protest movement. We’re helping teach kids (from 14 to 25) web design and development. My personal goal was to give these kids an opportunity that they would not have otherwise had. But it turned out that some of them have actually started a business building web sites for small companies. I’m so proud of the progress they’ve made in such a short time; it’s a challenging program.
+I’m pretty happy with my accomplishments this year. I made at least some progress on each of the goals I set. I’ve been thinking about my goals for next year; I’ll write that as a separate blog article next week.
+I’ve always been someone who faces my fears.
+I have a moderate case of arachnophobia. I don’t run away when I see a spider, but it creeps my out when one is crawling on me. When I was in college, I decided to buy a tarantula to attempt to get over my irrational fear of spiders. I thought I’d be able to get more comfortable with the tarantula over time, eventually to the point of letting it crawl on my arm. It didn’t work. Although I did find that my fear of tarantulas is rational — I got a terrible case of hives just from touching the urticating hairs that fell off into its water sponge.
+Last week, I was on vacation in Mexico. One of the excursions we took involved jumping in the water a lot. I’m not a strong swimmer — mostly because I have a hard time closing my nose; I hold my nose when I jump in. We zip-lined into the water a lot. At one point, there was a cliff to dive into the water from. It was about 15 feet above the water. It didn’t look so far down before jumping. But it felt like a really long way down the first time I jumped from it. It was pretty scary for me. So I did it a second time. There wasn’t any peer pressure to jump a second time. I literally jumped a second time specifically because I was scared.
+Fear is a weird thing. Fear is there to protect us. But it’s there to protect us from the dangers of the African savannah. Most of the things our fears protect us from don’t exist in our everyday modern lives. So maybe we should work to gain a better understanding of how our fears work, to figure out when to pay attention to them and when to ignore them.
+Fortunately, our brain has a good mechanism to help us do this. Our brains basically have 2 main processing systems. The first one is for quick reactions. This one involves things that are nearly reflexes. Fear is in this system. The second system is our analytical reasoning system. This system takes longer to process, but is able to take on more information.
+Whenever the situation allows us time for both systems to work, we need to listen to them both. We need to listen to our fears, because they’re there for a reason. But that reason might not pertain to our situation. So we need to realize that, and let the slow analytical system determine if we should ignore our fears.
+If we don’t allow both systems to work, we’re not taking full advantage of our brains; we’re not taking full advantage of the situations that life is presenting to us.
+I’ve been on vacation the past week, in Cozumel, Mexico. One day, we went on an excursion called Xenotes. A cenote (say-NO-tay) is a sinkhole filled with fresh water. (The “X” is to give it a more Mayan-sounding trademarkable name.) We had a lot of fun swimming, kayaking, and zip-lining. A bilingual tour guide led our group, which consisted of people from across the US and South America, of various ages and physical abilities.
+Our tour guide was a lot of fun. He made jokes, told us about the cenotes, and led us in the activities. But he also encouraged us. When someone was scared to do something, he was supportive. He told us that it was okay, and we could do it. But we also felt like it was OK to fail, if we really couldn’t. It really felt like his encouragement was literally creating courage.
+What was really neat was that despite the language barrier, everyone else was also supportive and encouraging. Everyone cheered with encouragement before someone would attempt something difficult. And we’d cheer especially loud once someone accomplished something that was difficult for their abilities.
+It was an awesome feeling to feel so supported. It made me feel like I was in a safe place, where I could try new things that were a little past my comfort zone. I was able to do the zip-line upside-down. I jumped off a 15-foot cliff into the water. I even jumped off the cliff a second time, even though I was a little scared.
+Back at the resort, we played some volleyball in the pool. It was a similar situation, with players of varying ages and abilities. Again, we tried to help the weaker players feel comfortable so they could improve without feeling judged or self-conscious. It helped everyone have a good time. It made everything more fun to be in such a supportive environment, whether I was in a position as one of the more skilled (volleyball), or one of the less skilled (jumping or zip-lining into the water). We were all able to accomplish more, with less effort.
+These experiences provide a good lesson that can be applied in a lot of places. Such a supportive environment would help any relationship, and any team. I’ve been on a couple really good software development teams, but I don’t think any of them have been as supportive as these two groups of strangers.
+I’ve decided that this should be one of my goals as a team leader. I want to create an encouraging environment for the whole team. I want to make sure that everyone is comfortable enough that they feel like they can try things that are difficult, even if they might fail (as long as nobody gets hurt).
+If a group of strangers can do this, so can your team. So can you and your significant others. We need to work every day to make sure that we’re supporting each other. It’s the best way to get everyone to achieve more.
+I got my first computer in 1984. It was a Commodore 64. I had to do extra chores and save up my allowance to buy it. I was 13.
+Back then, Sears and other retail stores had Commodore 64 computers out on display. Whenever I went to the store, I’d write a short BASIC program and leave it running on the display computers:
+10 PRINT "CRAIG IS GREAT!" +20 GOTO 10+
Hey, I was a 13-year-old kid. Later, I got a little more sophisticated. I’d change the background color instead. I still remember the POKE address:
+10 FOR I=0 TO 255 +20 POKE 53281, I +30 NEXT I +40 GOTO 10 +RUN+
This was fast enough to change the background color every few scan lines, creating a flashing scrolling effect.
+Later, I learned 6502 assembly language. I translated the BASIC program into assembler, and memorized the bytes to type in at the store. In assembly language, the background color would change several times per scan line. The effect was kind of psychedelic.
+All that happened in the mid-1980s.
+Fast-forward to about 2000 or so. I was telling the above story after a St. Louis LUG meeting. I explained how I had memorized the 10 or 12 bytes of machine code, and would leave the program running with its psychedelic effect.
+After thinking about it for a bit, I thought that 10 or 12 bytes seemed too much. It actually bothered me — I couldn’t fall asleep when I got home. I got up and found my old 6502 manuals. I figured out how to write the code in 7 bytes. I installed the Vice C64 emulator on my Linux desktop, and tested my code. It worked as expected. (The emulator was already clock-cycle perfect by then.) Here’s the assembly code:
+INX ; $E8 ; 232 +STX $D021 ; $8E $21 $D0 ; 142 33 208 ; $D021 = 53281 +JMP $C000 ; $4C $00 $C0 ; 76 0 192 ; $C000 = 49152+
Here’s the BASIC program to store that program in memory and run it:
+10 FOR N=49152 TO 49152+6: READ Q : POKE N, Q : NEXT +20 DATA 232, 142, 33, 208, 76, 0, 192 +30 SYS 49152 +RUN+
The moral of the story is that you can optimize even a 10-byte program, 15 years after the last time it was used. So don’t tell me that your program can’t be improved, no matter how small it is.
+PS. I rewrote the code above while writing this article in 2015, about 15 years after the last time I rewrote it. And I again downloaded Vice to test it, this time on Mac OS X.
+Web Development, Ruby on Rails, Open Source
+I got my first computer in 1984. It was a Commodore 64. I had to do extra chores and save up my allowance to buy it. I was 13.
+Back then, Sears and other retail stores had Commodore 64 computers out on display. Whenever I went to the store, I’d write a short BASIC program and leave it running on the display computers:
+10 PRINT "CRAIG IS GREAT!" +20 GOTO 10+
Hey, I was a 13-year-old kid. Later, I got a little more sophisticated. I’d change the background color instead. I still remember the POKE address:
+10 FOR I=0 TO 255 +20 POKE 53281, I +30 NEXT I +40 GOTO 10 +RUN+
This was fast enough to change the background color every few scan lines, creating a flashing scrolling effect.
+Later, I learned 6502 assembly language. I translated the BASIC program into assembler, and memorized the bytes to type in at the store. In assembly language, the background color would change several times per scan line. The effect was kind of psychedelic.
+All that happened in the mid-1980s.
+Fast-forward to about 2000 or so. I was telling the above story after a St. Louis LUG meeting. I explained how I had memorized the 10 or 12 bytes of machine code, and would leave the program running with its psychedelic effect.
+After thinking about it for a bit, I thought that 10 or 12 bytes seemed too much. It actually bothered me — I couldn’t fall asleep when I got home. I got up and found my old 6502 manuals. I figured out how to write the code in 7 bytes. I installed the Vice C64 emulator on my Linux desktop, and tested my code. It worked as expected. (The emulator was already clock-cycle perfect by then.) Here’s the assembly code:
+INX ; $E8 ; 232 +STX $D021 ; $8E $21 $D0 ; 142 33 208 ; $D021 = 53281 +JMP $C000 ; $4C $00 $C0 ; 76 0 192 ; $C000 = 49152+
Here’s the BASIC program to store that program in memory and run it:
+10 FOR N=49152 TO 49152+6: READ Q : POKE N, Q : NEXT +20 DATA 232, 142, 33, 208, 76, 0, 192 +30 SYS 49152 +RUN+
The moral of the story is that you can optimize even a 10-byte program, 15 years after the last time it was used. So don’t tell me that your program can’t be improved, no matter how small it is.
+PS. I rewrote the code above while writing this article in 2015, about 15 years after the last time I rewrote it. And I again downloaded Vice to test it, this time on Mac OS X.
+Web Development, Ruby on Rails, Open Source
+I’ve been on vacation the past week, in Cozumel, Mexico. One day, we went on an excursion called Xenotes. A cenote (say-NO-tay) is a sinkhole filled with fresh water. (The “X” is to give it a more Mayan-sounding trademarkable name.) We had a lot of fun swimming, kayaking, and zip-lining. A bilingual tour guide led our group, which consisted of people from across the US and South America, of various ages and physical abilities.
+Our tour guide was a lot of fun. He made jokes, told us about the cenotes, and led us in the activities. But he also encouraged us. When someone was scared to do something, he was supportive. He told us that it was okay, and we could do it. But we also felt like it was OK to fail, if we really couldn’t. It really felt like his encouragement was literally creating courage.
+What was really neat was that despite the language barrier, everyone else was also supportive and encouraging. Everyone cheered with encouragement before someone would attempt something difficult. And we’d cheer especially loud once someone accomplished something that was difficult for their abilities.
+It was an awesome feeling to feel so supported. It made me feel like I was in a safe place, where I could try new things that were a little past my comfort zone. I was able to do the zip-line upside-down. I jumped off a 15-foot cliff into the water. I even jumped off the cliff a second time, even though I was a little scared.
+Back at the resort, we played some volleyball in the pool. It was a similar situation, with players of varying ages and abilities. Again, we tried to help the weaker players feel comfortable so they could improve without feeling judged or self-conscious. It helped everyone have a good time. It made everything more fun to be in such a supportive environment, whether I was in a position as one of the more skilled (volleyball), or one of the less skilled (jumping or zip-lining into the water). We were all able to accomplish more, with less effort.
+These experiences provide a good lesson that can be applied in a lot of places. Such a supportive environment would help any relationship, and any team. I’ve been on a couple really good software development teams, but I don’t think any of them have been as supportive as these two groups of strangers.
+I’ve decided that this should be one of my goals as a team leader. I want to create an encouraging environment for the whole team. I want to make sure that everyone is comfortable enough that they feel like they can try things that are difficult, even if they might fail (as long as nobody gets hurt).
+If a group of strangers can do this, so can your team. So can you and your significant others. We need to work every day to make sure that we’re supporting each other. It’s the best way to get everyone to achieve more.
+Web Development, Ruby on Rails, Open Source
+I’ve always been someone who faces my fears.
+I have a moderate case of arachnophobia. I don’t run away when I see a spider, but it creeps my out when one is crawling on me. When I was in college, I decided to buy a tarantula to attempt to get over my irrational fear of spiders. I thought I’d be able to get more comfortable with the tarantula over time, eventually to the point of letting it crawl on my arm. It didn’t work. Although I did find that my fear of tarantulas is rational — I got a terrible case of hives just from touching the urticating hairs that fell off into its water sponge.
+Last week, I was on vacation in Mexico. One of the excursions we took involved jumping in the water a lot. I’m not a strong swimmer — mostly because I have a hard time closing my nose; I hold my nose when I jump in. We zip-lined into the water a lot. At one point, there was a cliff to dive into the water from. It was about 15 feet above the water. It didn’t look so far down before jumping. But it felt like a really long way down the first time I jumped from it. It was pretty scary for me. So I did it a second time. There wasn’t any peer pressure to jump a second time. I literally jumped a second time specifically because I was scared.
+Fear is a weird thing. Fear is there to protect us. But it’s there to protect us from the dangers of the African savannah. Most of the things our fears protect us from don’t exist in our everyday modern lives. So maybe we should work to gain a better understanding of how our fears work, to figure out when to pay attention to them and when to ignore them.
+Fortunately, our brain has a good mechanism to help us do this. Our brains basically have 2 main processing systems. The first one is for quick reactions. This one involves things that are nearly reflexes. Fear is in this system. The second system is our analytical reasoning system. This system takes longer to process, but is able to take on more information.
+Whenever the situation allows us time for both systems to work, we need to listen to them both. We need to listen to our fears, because they’re there for a reason. But that reason might not pertain to our situation. So we need to realize that, and let the slow analytical system determine if we should ignore our fears.
+If we don’t allow both systems to work, we’re not taking full advantage of our brains; we’re not taking full advantage of the situations that life is presenting to us.
+Web Development, Ruby on Rails, Open Source
+It’s that time of year again — time for a retrospective on how I did on my goals for the year. I had 5 main goals for 2015:
+I got pretty lucky on this one. My main contract with Mercy got extended several times. Amos and I must have been doing a good job of keeping the customer happy. We even made it through a couple rounds of layoffs. I’m wrapping up the gig at Mercy now. I’m working one day a week there, as the project winds down.
+I also started a new gig this month at CenturyLink. I’m working on a cloud development team. Our current project involves selling WordPress as a service. The manager had been courting me for most of the year. I’m excited about my new role; I’ll be writing about it in a blog post soon.
+I set a goal in 2014 to give my first conference talk. I accomplished that, giving an ambitious talk at RubyConf. I enjoyed having done that, and vowed to do more conference speaking.
+I gave 3 conference talks in 2015. I gave a workshop on HTTP at RailsConf. I talked about immutable infrastructure at Madison+ Ruby. At RubyConf, I gave a talk on a micro-ORM I wrote. I also gave a lightning talk about Agile estimation (#noestimates).
+I was an alternate speaker at Windy City Rails, but did not give my talk on Alternatives to ActiveRecord. I also went to Strange Loop, mainly to see several friends and acquaintances speak.
+I wrote 24 blog articles this year. That’s about one every other week. What really kept me going was participating in a writing pact. When the pact was going, I had a 75% blogging rate. That’s pretty good.
+I’m not so sure about the quality of my blog writing though. I know that practicing writing is supposed to make you better. I know I wrote some really good articles over the past year, but I think I also wrote some articles that weren’t very good. I think sometimes the deadline has caused more harm than good. I’m not really sure what to do about that; perhaps just pushing on is the right answer.
+I’ve taken a lot of notes on the design of my programming language. Any time I learn something interesting about another language, or come up with another idea, I write it down.
+But I haven’t worked on the implementation. (I last worked on the implementation in 2014.) I should be experimenting with some ideas, implementing them to see how they work out. I’ve even kicked around the idea of starting with a Forth variant, just to get something working quickly.
+I haven’t written any articles on my ideas this year either. My notes are pretty extensive, and it would be good to write some articles to help get my thoughts straight.
+I’ve got some things to say about Agile, and want to write a book to express those ideas. I’ve made a start — I’ve got the chapters outlines, and have started on a few chapters. But I haven’t made as much progress as I’d like to. I shared what I’ve got with Amos, and he showed some interest in pairing with me on the writing. Hopefully we’ll work on it together in 2016 and publish it.
+There were a few other accomplishments that weren’t explicitly on my list, but I’d like to call attention to.
+I’ve continued participating on the This Agile Life podcast. I was in 12 of the 33 episodes that were recorded in 2015. I hope to participate in more in 2016. We’re considering scheduling a standard recording night each week, which might help us record more regularly.
+I recently took over as maintainer of Virtus, a library to declare attributes for Ruby model classes. I haven’t done a lot yet, since I’ve been busy with travel, vacation, and holidays. But I hope to catch up with all the pending pull requests and issues in the next month or so.
+The accomplishment I’m most proud of is mentoring for the Roy Clay Sr. Tech Impact program. This is a program begun as a result of the Ferguson protest movement. We’re helping teach kids (from 14 to 25) web design and development. My personal goal was to give these kids an opportunity that they would not have otherwise had. But it turned out that some of them have actually started a business building web sites for small companies. I’m so proud of the progress they’ve made in such a short time; it’s a challenging program.
+I’m pretty happy with my accomplishments this year. I made at least some progress on each of the goals I set. I’ve been thinking about my goals for next year; I’ll write that as a separate blog article next week.
+Web Development, Ruby on Rails, Open Source
+I’ve written up a list of career-related resolutions the past few years. I’ve been pretty successful meeting those goals, so I’m going to continue the tradition.
+I want to increase the Open Source code I write this year. That’s basically everything I write that’s not directly related to work.
+I took over maintenance of Virtus late last year, but haven’t done a good job at finding the time for that. That’s probably more responding to issues on GitHub and merging pull requests. But eventually, I’ll likely add some features and do some refactoring.
+My goal is to work on 6 apps and libraries this year. That’s a pretty aggressive goal, but I want to focus on both learning new things and building some simple but useful things. Think MVP — focus on getting a lot of bang for not too much effort.
+I want to work on a new Rails app, to familiarize myself with Rails 5. I want to get some experience with some more modern gems. I also want to see if I can use some new techniques with a Rails app, especially things that might help us get closer to a hexagonal architecture. I’m also hoping to work with some different web frameworks — maybe Lotus, Rodakase, Trailblazer, or Phoenix. Or maybe one of the Crystal web frameworks.
+I also want to work on a couple Elm apps. I started the STL Elm group as an excuse to learn the language. I’d like to work on a Twitter client, that might eventually turn into a more general reading app. Beyond Twitter, it would keep track of things I want to read. The other Elm app I’d like to write is a game, based on the old Space Taxi game I loved to play on the Commodore 64.
+I wrote a micro-ORM last year called Ruby Preserves. I’ve started converting that from working with raw SQL to sitting atop the awesome Sequel gem. The simplicity is still there so far, and basing it on Sequel has so far gone easier than I expected. But I haven’t figured out how to do relationships (JOINs) yet; that will be the real test.
+I’m pretty happy with my 2015 conference experience. I want to keep my conference level about the same. I don’t really want to commit to more talks than I gave last year. Conference presentations take a lot of time and energy to write and practice.
+I’m planning to go to RailsConf, RubyConf, and Strange Loop. I’m hoping to give a talk at each of those, if I can. But I’ll probably attend all of them even if I’m not speaking. I’m also submitting a talk to Agile 2016. I’m unlikely to go to any other conferences, and even more unlikely to give more than 4 conference talks.
+I really want to finish my Effective Agile book this year. I’m going to try to pull Amos in to pair with me on it occasionally, to move it forward. If I’m able to get it done, I’d also like to maybe write a book on Elm.
+I actually want to do less blogging this year. Well, sort of. I want to put coding and book writing ahead of blogging. If that means less blogging, I’m okay with that. So my goal for blogging is more like every other week. And when I do write a blog article, I’d rather it be related to some code I’m working on, something that I could use in my book, or some more in-depth thoughts about programming language design.
+The contract I recently started at CenturyLink Cloud is open-ended, so I’ll likely be there for the entire year. I’m enjoying it so far; it’s a challenge, but I think I can make a significant impact. However, I’m really interested in moving to San Francisco in 2017. So I’m going to work on preparing for that in several ways.
+I’m going to resurrect my LinkedIn account. I’ve neglected it for a few years now. I’ll make sure everything is up to date, and make some connections I’ve been putting off. I also want to reclaim my Stack Exchange and Hacker News accounts.
+I’m going to pay a an expert to help me revamp my résumé. I think it’s pretty decent, but it could use some freshening up. I want it to stand out. I want to do a better job of explaining what I really do — which is to join a team to help them improve their processes and their technical skills.
+I’ll also need to clean up all my web sites, so they look nice when people come to take a look at them. This includes my personal site, consulting business site, wiki, and blogs. I should also upgrade my server to the latest version of Debian, and use Ansible and some other tools to provision it using the principles of Infrastructure as Code.
+I held a retrospective with my new team last week. The team includes 2 senior developers, 2 junior developers, a product owner, and a product analyst. I’ve joined the team as an engineering manager, which I think of more as a team lead with an elevated title. Being new to this group, I wanted a way to understand their values. What motivates them? What common values do we share that we can leverage to move forward in the same direction?
+I started out with a pretty simple question: “What do you value (in regards to what we’re building); what are you willing to fight for?” I asked them each to write down several values and then put them on the board before looking at everyone else’s answers. I also asked each person to rank their values in order of importance.
+It turned out that my question was a little vague. Some people thought about the question in terms of the end result, and some in terms of the process of creating the software. In some ways that was a bit of a problem, because the different interpretations led people in different directions. But in other ways, not pushing them in any particular direction got more varied answers, exposing how they think about the project and the product.
+My list (in order) was Effectiveness (doing the right thing), Quality (doing things right the first time), Happiness, Purpose, and Teamwork. In retrospect, I should have put Happiness first. If I’m not happy at work, I don’t really want to be there, and need to move on. (Sometimes I can trade some happiness at work for more happiness at home, but I’m definitely a person that needs to be happy at work.) The other values serve to improve my happiness, but the happiness is more important.
+My own issue ranking my values turned out to be a problem with the ranking in general. Should they be ranked in importance of the necessity of the value as an outcome, or in importance of the necessity to focus on the value? I think the former is what I was looking for, but even I wasn’t clear on that when I began the exercise.
+After everyone put their values up on the board, we read them off. Then I asked the team to choose several values that we share as a team. We pulled them off the individual members’ lists, and put them in the team list. Then I asked each person to come up and rank those values, then explain why they had ordered them that way, especially when they ordered them significantly different than the last person. I was hoping to come to some convergence of the rank over time, so we could document our values in rank order. That didn’t happen. But the discussion was illuminating to me and to everyone on the team.
+I think the most interesting part about the lack of convergence was the difference between the developers and the product guys. The product guys definitely viewed the values more in terms of outcomes than the process. That makes sense — they’re not as intimately involved in the process of building the product.
+We were able to converge on the top priority though: Will the user buy the product? This was a combination of a couple different values that we merged together. This included the end user experience as well as making sure the team would continue to have a reason for existing. The rest of the values we left unordered: Teamwork (cohesiveness), Data driven decisions, Team ownership, Simplicity, Effectiveness, Maintainability / Supportability, Quality, Automation, and Performance. I think that’s a pretty decent list.
+As a couple teammates pointed out, those values are probably in part a reflection of this current point in time. If I asked the same question some other time, under different conditions and team dynamics, the answers would probably change a bit. And we’d probably come up with other answers if asked again, just due to randomness of the way we think about these things.
+But I don’t think I’d do this activity a second time with the team. It was really about understanding our motivations — both our own, and those of our teammates. I found it effective in that way, and also in helping the team to think about our culture and how we can work to shape it to help us all push in the same direction.
+There are a few caveats. When I asked for feedback on the exercise, one teammate pointed out that it wouldn’t work if people weren’t honest about their values, and they answered with what they thought management or their teammates wanted to hear. I don’t think that was an issue with this group, but it’s something to keep in mind.
+The other major thing I’d do is to make it clear up front that I’m not looking for any action items from this activity; it’s more about understanding each other and ourselves. And next time, I’ll work to clarify how to rank the values.
+I would recommend this activity for a new team, or when the makeup of the team is changing in some significant way. I wish there was a way to help a team converge on the ranking of their values, but I suppose I should be happy that agreeing on the set of important values went pretty quickly. And the diversity of ideas and opinions is probably a blessing that I should be embracing — the more ideas we have, the wider the variety of solutions we can imagine.
+Web Development, Ruby on Rails, Open Source
+I held a retrospective with my new team last week. The team includes 2 senior developers, 2 junior developers, a product owner, and a product analyst. I’ve joined the team as an engineering manager, which I think of more as a team lead with an elevated title. Being new to this group, I wanted a way to understand their values. What motivates them? What common values do we share that we can leverage to move forward in the same direction?
+I started out with a pretty simple question: “What do you value (in regards to what we’re building); what are you willing to fight for?” I asked them each to write down several values and then put them on the board before looking at everyone else’s answers. I also asked each person to rank their values in order of importance.
+It turned out that my question was a little vague. Some people thought about the question in terms of the end result, and some in terms of the process of creating the software. In some ways that was a bit of a problem, because the different interpretations led people in different directions. But in other ways, not pushing them in any particular direction got more varied answers, exposing how they think about the project and the product.
+My list (in order) was Effectiveness (doing the right thing), Quality (doing things right the first time), Happiness, Purpose, and Teamwork. In retrospect, I should have put Happiness first. If I’m not happy at work, I don’t really want to be there, and need to move on. (Sometimes I can trade some happiness at work for more happiness at home, but I’m definitely a person that needs to be happy at work.) The other values serve to improve my happiness, but the happiness is more important.
+My own issue ranking my values turned out to be a problem with the ranking in general. Should they be ranked in importance of the necessity of the value as an outcome, or in importance of the necessity to focus on the value? I think the former is what I was looking for, but even I wasn’t clear on that when I began the exercise.
+After everyone put their values up on the board, we read them off. Then I asked the team to choose several values that we share as a team. We pulled them off the individual members’ lists, and put them in the team list. Then I asked each person to come up and rank those values, then explain why they had ordered them that way, especially when they ordered them significantly different than the last person. I was hoping to come to some convergence of the rank over time, so we could document our values in rank order. That didn’t happen. But the discussion was illuminating to me and to everyone on the team.
+I think the most interesting part about the lack of convergence was the difference between the developers and the product guys. The product guys definitely viewed the values more in terms of outcomes than the process. That makes sense — they’re not as intimately involved in the process of building the product.
+We were able to converge on the top priority though: Will the user buy the product? This was a combination of a couple different values that we merged together. This included the end user experience as well as making sure the team would continue to have a reason for existing. The rest of the values we left unordered: Teamwork (cohesiveness), Data driven decisions, Team ownership, Simplicity, Effectiveness, Maintainability / Supportability, Quality, Automation, and Performance. I think that’s a pretty decent list.
+As a couple teammates pointed out, those values are probably in part a reflection of this current point in time. If I asked the same question some other time, under different conditions and team dynamics, the answers would probably change a bit. And we’d probably come up with other answers if asked again, just due to randomness of the way we think about these things.
+But I don’t think I’d do this activity a second time with the team. It was really about understanding our motivations — both our own, and those of our teammates. I found it effective in that way, and also in helping the team to think about our culture and how we can work to shape it to help us all push in the same direction.
+There are a few caveats. When I asked for feedback on the exercise, one teammate pointed out that it wouldn’t work if people weren’t honest about their values, and they answered with what they thought management or their teammates wanted to hear. I don’t think that was an issue with this group, but it’s something to keep in mind.
+The other major thing I’d do is to make it clear up front that I’m not looking for any action items from this activity; it’s more about understanding each other and ourselves. And next time, I’ll work to clarify how to rank the values.
+I would recommend this activity for a new team, or when the makeup of the team is changing in some significant way. I wish there was a way to help a team converge on the ranking of their values, but I suppose I should be happy that agreeing on the set of important values went pretty quickly. And the diversity of ideas and opinions is probably a blessing that I should be embracing — the more ideas we have, the wider the variety of solutions we can imagine.
+Web Development, Ruby on Rails, Open Source
+I’ve written up a list of career-related resolutions the past few years. I’ve been pretty successful meeting those goals, so I’m going to continue the tradition.
+I want to increase the Open Source code I write this year. That’s basically everything I write that’s not directly related to work.
+I took over maintenance of Virtus late last year, but haven’t done a good job at finding the time for that. That’s probably more responding to issues on GitHub and merging pull requests. But eventually, I’ll likely add some features and do some refactoring.
+My goal is to work on 6 apps and libraries this year. That’s a pretty aggressive goal, but I want to focus on both learning new things and building some simple but useful things. Think MVP — focus on getting a lot of bang for not too much effort.
+I want to work on a new Rails app, to familiarize myself with Rails 5. I want to get some experience with some more modern gems. I also want to see if I can use some new techniques with a Rails app, especially things that might help us get closer to a hexagonal architecture. I’m also hoping to work with some different web frameworks — maybe Lotus, Rodakase, Trailblazer, or Phoenix. Or maybe one of the Crystal web frameworks.
+I also want to work on a couple Elm apps. I started the STL Elm group as an excuse to learn the language. I’d like to work on a Twitter client, that might eventually turn into a more general reading app. Beyond Twitter, it would keep track of things I want to read. The other Elm app I’d like to write is a game, based on the old Space Taxi game I loved to play on the Commodore 64.
+I wrote a micro-ORM last year called Ruby Preserves. I’ve started converting that from working with raw SQL to sitting atop the awesome Sequel gem. The simplicity is still there so far, and basing it on Sequel has so far gone easier than I expected. But I haven’t figured out how to do relationships (JOINs) yet; that will be the real test.
+I’m pretty happy with my 2015 conference experience. I want to keep my conference level about the same. I don’t really want to commit to more talks than I gave last year. Conference presentations take a lot of time and energy to write and practice.
+I’m planning to go to RailsConf, RubyConf, and Strange Loop. I’m hoping to give a talk at each of those, if I can. But I’ll probably attend all of them even if I’m not speaking. I’m also submitting a talk to Agile 2016. I’m unlikely to go to any other conferences, and even more unlikely to give more than 4 conference talks.
+I really want to finish my Effective Agile book this year. I’m going to try to pull Amos in to pair with me on it occasionally, to move it forward. If I’m able to get it done, I’d also like to maybe write a book on Elm.
+I actually want to do less blogging this year. Well, sort of. I want to put coding and book writing ahead of blogging. If that means less blogging, I’m okay with that. So my goal for blogging is more like every other week. And when I do write a blog article, I’d rather it be related to some code I’m working on, something that I could use in my book, or some more in-depth thoughts about programming language design.
+The contract I recently started at CenturyLink Cloud is open-ended, so I’ll likely be there for the entire year. I’m enjoying it so far; it’s a challenge, but I think I can make a significant impact. However, I’m really interested in moving to San Francisco in 2017. So I’m going to work on preparing for that in several ways.
+I’m going to resurrect my LinkedIn account. I’ve neglected it for a few years now. I’ll make sure everything is up to date, and make some connections I’ve been putting off. I also want to reclaim my Stack Exchange and Hacker News accounts.
+I’m going to pay a an expert to help me revamp my résumé. I think it’s pretty decent, but it could use some freshening up. I want it to stand out. I want to do a better job of explaining what I really do — which is to join a team to help them improve their processes and their technical skills.
+I’ll also need to clean up all my web sites, so they look nice when people come to take a look at them. This includes my personal site, consulting business site, wiki, and blogs. I should also upgrade my server to the latest version of Debian, and use Ansible and some other tools to provision it using the principles of Infrastructure as Code.
+Web Development, Ruby on Rails, Open Source
+I recently attended an Open Space hosted at work. I’d never been to an Open Space, and didn’t know what to expect. We’d been told that this was a workshop to help Engineering Managers (my role), Product Owners, and Product Analysts find better ways of working together. But due to the way an Open Space works, it evolved into something completely different — and better.
+We’d brought in Diana Larsen to facilitate the Open Space. Diana is a stalwart of the Agile community, focusing on how people and teams interact. She literally (co-)wrote the book on Agile retrospectives. Diana was also kind enough to be our guest at an Agile LINC meetup later in the evening.
+The morning started off with all the participants sitting in chairs arranged in a circle. Diana rang a chime, a nice soothing tone that literally set the tone for the day. (Most people didn’t seem to like it, but I thought it had its purpose.) It also acted as a call to gather in the meeting space. She then walked around the inside of the circle as she explained what was going to happen.
+The idea behind Open Spaces came with the realization that at a conference, the “hallway track” (ad hoc discussions in the hallways) was often more valuable than the scheduled talks. So they figured out a way to capture that experience. There are only a few rules:
+Once Diana set the scene and explained the rules, people came up and presented ideas for topics. If you proposed a topic, you chose a time and location on the topic board. At that time, you’d facilitate a discussion on that topic. The format was really conducive to discussions. There was no preparation, so discussions were from the heart — lots of people felt that they could contribute.
+Being new to the company (only 2 months), I got a lot out of the workshop, beyond the content itself. I got to get to know several more people. I’d even say I made a few friends. Having open discussions, we found that many of the teams were having the same issues. This made it easy for me to talk to other people.
+All-in-all, I found the Open Space to be extremely conducive to discussions aimed at identifying issues, brainstorming solutions, and planning action items. I felt like we made great strides in addressing some of the biggest problems our organization is currently facing.
+Web Development, Ruby on Rails, Open Source
+I recently attended an Open Space hosted at work. I’d never been to an Open Space, and didn’t know what to expect. We’d been told that this was a workshop to help Engineering Managers (my role), Product Owners, and Product Analysts find better ways of working together. But due to the way an Open Space works, it evolved into something completely different — and better.
+We’d brought in Diana Larsen to facilitate the Open Space. Diana is a stalwart of the Agile community, focusing on how people and teams interact. She literally (co-)wrote the book on Agile retrospectives. Diana was also kind enough to be our guest at an Agile LINC meetup later in the evening.
+The morning started off with all the participants sitting in chairs arranged in a circle. Diana rang a chime, a nice soothing tone that literally set the tone for the day. (Most people didn’t seem to like it, but I thought it had its purpose.) It also acted as a call to gather in the meeting space. She then walked around the inside of the circle as she explained what was going to happen.
+The idea behind Open Spaces came with the realization that at a conference, the “hallway track” (ad hoc discussions in the hallways) was often more valuable than the scheduled talks. So they figured out a way to capture that experience. There are only a few rules:
+Once Diana set the scene and explained the rules, people came up and presented ideas for topics. If you proposed a topic, you chose a time and location on the topic board. At that time, you’d facilitate a discussion on that topic. The format was really conducive to discussions. There was no preparation, so discussions were from the heart — lots of people felt that they could contribute.
+Being new to the company (only 2 months), I got a lot out of the workshop, beyond the content itself. I got to get to know several more people. I’d even say I made a few friends. Having open discussions, we found that many of the teams were having the same issues. This made it easy for me to talk to other people.
+All-in-all, I found the Open Space to be extremely conducive to discussions aimed at identifying issues, brainstorming solutions, and planning action items. I felt like we made great strides in addressing some of the biggest problems our organization is currently facing.
+Web Development, Ruby on Rails, Open Source
+Not too long ago, I was asked during a job interview “how do you convince your teammates that you’re right?” I answered with probably the most surprising answer: “I don’t.”
+It’s taken me years to realize that being right isn’t terribly important. Especially when there’s more than one right answer — which there usually is. It’s more important to work as a team. It’s more important to be respected and to have respect for others.
+A few weeks after that interview, I was pair programming with the person who had asked me the question. We’re both senior developers, so we both have a lot of experience and opinions based on that experience. We were writing a shell script, and we both had an idea in mind about how to write the code. I let him proceed with his idea. It was a pretty good idea; probably better than mine. But we paired very effectively. I’d let him finish some code, and I’d find a way to make it better. Then he’d find a way to make my code better. What we ended up with was so much better than my original idea, and his original idea as well. I commented on this, and he agreed. We left that pairing session feeling the high of having accomplished something rare — two very experience programmers coming up with better code than we could have imagined going in.
+I like to think of writing code as a path towards a destination. The destination is good code that does what it’s supposed to, is readable (intention revealing), is concise, and is well-factored so as to be easy to change in the future. But there are many paths to that destination. Especially when pair programming, the code gets refined as ideas are shared, getting you closer and closer to that destination. Sometimes the different paths end up with the same code; sometimes they end up with different code. But if the code does its job well (according to those criteria), it doesn’t really matter what code you ended up with.
+Thinking back to the original question, I think the answer is a little more nuanced. (I’m pretty sure I followed up with an explanation, but I don’t recall the details.) It truly doesn’t matter in a lot of cases. If there are different paths that lead to the same destination, and they’re all roughly equal, then my rule works. It can also work even if the first path you try (a “wrong” path) doesn’t work out, as long as it’s easy enough to try a different path. I find that the majority of day-to-day coding fits these conditions.
+But there are some places where it’s costly to get things wrong the first time. In these cases, it’s worth spending some time thinking about and discussing the alternatives before getting started. Software architecture is the big one that comes to mind. In general, weighing the pros and cons of each option and applying previous experience works best.
+So next time you think about trying to convince someone you’re right, fight the urge. Instead, let them show you what they’re thinking. They just might surprise you. And more importantly, you might surprise yourself.
+Web Development, Ruby on Rails, Open Source
+Not too long ago, I was asked during a job interview “how do you convince your teammates that you’re right?” I answered with probably the most surprising answer: “I don’t.”
+It’s taken me years to realize that being right isn’t terribly important. Especially when there’s more than one right answer — which there usually is. It’s more important to work as a team. It’s more important to be respected and to have respect for others.
+A few weeks after that interview, I was pair programming with the person who had asked me the question. We’re both senior developers, so we both have a lot of experience and opinions based on that experience. We were writing a shell script, and we both had an idea in mind about how to write the code. I let him proceed with his idea. It was a pretty good idea; probably better than mine. But we paired very effectively. I’d let him finish some code, and I’d find a way to make it better. Then he’d find a way to make my code better. What we ended up with was so much better than my original idea, and his original idea as well. I commented on this, and he agreed. We left that pairing session feeling the high of having accomplished something rare — two very experience programmers coming up with better code than we could have imagined going in.
+I like to think of writing code as a path towards a destination. The destination is good code that does what it’s supposed to, is readable (intention revealing), is concise, and is well-factored so as to be easy to change in the future. But there are many paths to that destination. Especially when pair programming, the code gets refined as ideas are shared, getting you closer and closer to that destination. Sometimes the different paths end up with the same code; sometimes they end up with different code. But if the code does its job well (according to those criteria), it doesn’t really matter what code you ended up with.
+Thinking back to the original question, I think the answer is a little more nuanced. (I’m pretty sure I followed up with an explanation, but I don’t recall the details.) It truly doesn’t matter in a lot of cases. If there are different paths that lead to the same destination, and they’re all roughly equal, then my rule works. It can also work even if the first path you try (a “wrong” path) doesn’t work out, as long as it’s easy enough to try a different path. I find that the majority of day-to-day coding fits these conditions.
+But there are some places where it’s costly to get things wrong the first time. In these cases, it’s worth spending some time thinking about and discussing the alternatives before getting started. Software architecture is the big one that comes to mind. In general, weighing the pros and cons of each option and applying previous experience works best.
+So next time you think about trying to convince someone you’re right, fight the urge. Instead, let them show you what they’re thinking. They just might surprise you. And more importantly, you might surprise yourself.
+Hello, I have read your ideas about the Brilliant Programming Language.
+I was wondering if you had made any progress with it? It seems like a language I would enjoy working with.
+Best of luck.
+Web Development, Ruby on Rails, Open Source
+BoochTek, LLC is a small web development company, based in St. Louis, Missouri. We specialize in Ruby, Ruby on Rails, Rails rescue projects, Agile methodologies, JavaScript, and HTML 5. We also do GNU/Linux system administration and network security.
+Web Development, Ruby on Rails, Open Source
+Not too long ago, I was asked during a job interview “how do you convince your teammates that you’re right?” I answered with probably the most surprising answer: “I don’t.”
+It’s taken me years to realize that being right isn’t terribly important. Especially when there’s more than one right answer — which there usually is. It’s more important to work as a team. It’s more important to be respected and to have respect for others.
+A few weeks after that interview, I was pair programming with the person who had asked me the question. We’re both senior developers, so we both have a lot of experience and opinions based on that experience. We were writing a shell script, and we both had an idea in mind about how to write the code. I let him proceed with his idea. It was a pretty good idea; probably better than mine. But we paired very effectively. I’d let him finish some code, and I’d find a way to make it better. Then he’d find a way to make my code better. What we ended up with was so much better than my original idea, and his original idea as well. I commented on this, and he agreed. We left that pairing session feeling the high of having accomplished something rare — two very experience programmers coming up with better code than we could have imagined going in.
+I like to think of writing code as a path towards a destination. The destination is good code that does what it’s supposed to, is readable (intention revealing), is concise, and is well-factored so as to be easy to change in the future. But there are many paths to that destination. Especially when pair programming, the code gets refined as ideas are shared, getting you closer and closer to that destination. Sometimes the different paths end up with the same code; sometimes they end up with different code. But if the code does its job well (according to those criteria), it doesn’t really matter what code you ended up with.
+Thinking back to the original question, I think the answer is a little more nuanced. (I’m pretty sure I followed up with an explanation, but I don’t recall the details.) It truly doesn’t matter in a lot of cases. If there are different paths that lead to the same destination, and they’re all roughly equal, then my rule works. It can also work even if the first path you try (a “wrong” path) doesn’t work out, as long as it’s easy enough to try a different path. I find that the majority of day-to-day coding fits these conditions.
+But there are some places where it’s costly to get things wrong the first time. In these cases, it’s worth spending some time thinking about and discussing the alternatives before getting started. Software architecture is the big one that comes to mind. In general, weighing the pros and cons of each option and applying previous experience works best.
+So next time you think about trying to convince someone you’re right, fight the urge. Instead, let them show you what they’re thinking. They just might surprise you. And more importantly, you might surprise yourself.
+I recently attended an Open Space hosted at work. I’d never been to an Open Space, and didn’t know what to expect. We’d been told that this was a workshop to help Engineering Managers (my role), Product Owners, and Product Analysts find better ways of working together. But due to the way an Open Space works, it evolved into something completely different — and better.
+We’d brought in Diana Larsen to facilitate the Open Space. Diana is a stalwart of the Agile community, focusing on how people and teams interact. She literally (co-)wrote the book on Agile retrospectives. Diana was also kind enough to be our guest at an Agile LINC meetup later in the evening.
+The morning started off with all the participants sitting in chairs arranged in a circle. Diana rang a chime, a nice soothing tone that literally set the tone for the day. (Most people didn’t seem to like it, but I thought it had its purpose.) It also acted as a call to gather in the meeting space. She then walked around the inside of the circle as she explained what was going to happen.
+The idea behind Open Spaces came with the realization that at a conference, the “hallway track” (ad hoc discussions in the hallways) was often more valuable than the scheduled talks. So they figured out a way to capture that experience. There are only a few rules:
+Once Diana set the scene and explained the rules, people came up and presented ideas for topics. If you proposed a topic, you chose a time and location on the topic board. At that time, you’d facilitate a discussion on that topic. The format was really conducive to discussions. There was no preparation, so discussions were from the heart — lots of people felt that they could contribute.
+Being new to the company (only 2 months), I got a lot out of the workshop, beyond the content itself. I got to get to know several more people. I’d even say I made a few friends. Having open discussions, we found that many of the teams were having the same issues. This made it easy for me to talk to other people.
+All-in-all, I found the Open Space to be extremely conducive to discussions aimed at identifying issues, brainstorming solutions, and planning action items. I felt like we made great strides in addressing some of the biggest problems our organization is currently facing.
+I’ve written up a list of career-related resolutions the past few years. I’ve been pretty successful meeting those goals, so I’m going to continue the tradition.
+I want to increase the Open Source code I write this year. That’s basically everything I write that’s not directly related to work.
+I took over maintenance of Virtus late last year, but haven’t done a good job at finding the time for that. That’s probably more responding to issues on GitHub and merging pull requests. But eventually, I’ll likely add some features and do some refactoring.
+My goal is to work on 6 apps and libraries this year. That’s a pretty aggressive goal, but I want to focus on both learning new things and building some simple but useful things. Think MVP — focus on getting a lot of bang for not too much effort.
+I want to work on a new Rails app, to familiarize myself with Rails 5. I want to get some experience with some more modern gems. I also want to see if I can use some new techniques with a Rails app, especially things that might help us get closer to a hexagonal architecture. I’m also hoping to work with some different web frameworks — maybe Lotus, Rodakase, Trailblazer, or Phoenix. Or maybe one of the Crystal web frameworks.
+I also want to work on a couple Elm apps. I started the STL Elm group as an excuse to learn the language. I’d like to work on a Twitter client, that might eventually turn into a more general reading app. Beyond Twitter, it would keep track of things I want to read. The other Elm app I’d like to write is a game, based on the old Space Taxi game I loved to play on the Commodore 64.
+I wrote a micro-ORM last year called Ruby Preserves. I’ve started converting that from working with raw SQL to sitting atop the awesome Sequel gem. The simplicity is still there so far, and basing it on Sequel has so far gone easier than I expected. But I haven’t figured out how to do relationships (JOINs) yet; that will be the real test.
+I’m pretty happy with my 2015 conference experience. I want to keep my conference level about the same. I don’t really want to commit to more talks than I gave last year. Conference presentations take a lot of time and energy to write and practice.
+I’m planning to go to RailsConf, RubyConf, and Strange Loop. I’m hoping to give a talk at each of those, if I can. But I’ll probably attend all of them even if I’m not speaking. I’m also submitting a talk to Agile 2016. I’m unlikely to go to any other conferences, and even more unlikely to give more than 4 conference talks.
+I really want to finish my Effective Agile book this year. I’m going to try to pull Amos in to pair with me on it occasionally, to move it forward. If I’m able to get it done, I’d also like to maybe write a book on Elm.
+I actually want to do less blogging this year. Well, sort of. I want to put coding and book writing ahead of blogging. If that means less blogging, I’m okay with that. So my goal for blogging is more like every other week. And when I do write a blog article, I’d rather it be related to some code I’m working on, something that I could use in my book, or some more in-depth thoughts about programming language design.
+The contract I recently started at CenturyLink Cloud is open-ended, so I’ll likely be there for the entire year. I’m enjoying it so far; it’s a challenge, but I think I can make a significant impact. However, I’m really interested in moving to San Francisco in 2017. So I’m going to work on preparing for that in several ways.
+I’m going to resurrect my LinkedIn account. I’ve neglected it for a few years now. I’ll make sure everything is up to date, and make some connections I’ve been putting off. I also want to reclaim my Stack Exchange and Hacker News accounts.
+I’m going to pay a an expert to help me revamp my résumé. I think it’s pretty decent, but it could use some freshening up. I want it to stand out. I want to do a better job of explaining what I really do — which is to join a team to help them improve their processes and their technical skills.
+I’ll also need to clean up all my web sites, so they look nice when people come to take a look at them. This includes my personal site, consulting business site, wiki, and blogs. I should also upgrade my server to the latest version of Debian, and use Ansible and some other tools to provision it using the principles of Infrastructure as Code.
+I held a retrospective with my new team last week. The team includes 2 senior developers, 2 junior developers, a product owner, and a product analyst. I’ve joined the team as an engineering manager, which I think of more as a team lead with an elevated title. Being new to this group, I wanted a way to understand their values. What motivates them? What common values do we share that we can leverage to move forward in the same direction?
+I started out with a pretty simple question: “What do you value (in regards to what we’re building); what are you willing to fight for?” I asked them each to write down several values and then put them on the board before looking at everyone else’s answers. I also asked each person to rank their values in order of importance.
+It turned out that my question was a little vague. Some people thought about the question in terms of the end result, and some in terms of the process of creating the software. In some ways that was a bit of a problem, because the different interpretations led people in different directions. But in other ways, not pushing them in any particular direction got more varied answers, exposing how they think about the project and the product.
+My list (in order) was Effectiveness (doing the right thing), Quality (doing things right the first time), Happiness, Purpose, and Teamwork. In retrospect, I should have put Happiness first. If I’m not happy at work, I don’t really want to be there, and need to move on. (Sometimes I can trade some happiness at work for more happiness at home, but I’m definitely a person that needs to be happy at work.) The other values serve to improve my happiness, but the happiness is more important.
+My own issue ranking my values turned out to be a problem with the ranking in general. Should they be ranked in importance of the necessity of the value as an outcome, or in importance of the necessity to focus on the value? I think the former is what I was looking for, but even I wasn’t clear on that when I began the exercise.
+After everyone put their values up on the board, we read them off. Then I asked the team to choose several values that we share as a team. We pulled them off the individual members’ lists, and put them in the team list. Then I asked each person to come up and rank those values, then explain why they had ordered them that way, especially when they ordered them significantly different than the last person. I was hoping to come to some convergence of the rank over time, so we could document our values in rank order. That didn’t happen. But the discussion was illuminating to me and to everyone on the team.
+I think the most interesting part about the lack of convergence was the difference between the developers and the product guys. The product guys definitely viewed the values more in terms of outcomes than the process. That makes sense — they’re not as intimately involved in the process of building the product.
+We were able to converge on the top priority though: Will the user buy the product? This was a combination of a couple different values that we merged together. This included the end user experience as well as making sure the team would continue to have a reason for existing. The rest of the values we left unordered: Teamwork (cohesiveness), Data driven decisions, Team ownership, Simplicity, Effectiveness, Maintainability / Supportability, Quality, Automation, and Performance. I think that’s a pretty decent list.
+As a couple teammates pointed out, those values are probably in part a reflection of this current point in time. If I asked the same question some other time, under different conditions and team dynamics, the answers would probably change a bit. And we’d probably come up with other answers if asked again, just due to randomness of the way we think about these things.
+But I don’t think I’d do this activity a second time with the team. It was really about understanding our motivations — both our own, and those of our teammates. I found it effective in that way, and also in helping the team to think about our culture and how we can work to shape it to help us all push in the same direction.
+There are a few caveats. When I asked for feedback on the exercise, one teammate pointed out that it wouldn’t work if people weren’t honest about their values, and they answered with what they thought management or their teammates wanted to hear. I don’t think that was an issue with this group, but it’s something to keep in mind.
+The other major thing I’d do is to make it clear up front that I’m not looking for any action items from this activity; it’s more about understanding each other and ourselves. And next time, I’ll work to clarify how to rank the values.
+I would recommend this activity for a new team, or when the makeup of the team is changing in some significant way. I wish there was a way to help a team converge on the ranking of their values, but I suppose I should be happy that agreeing on the set of important values went pretty quickly. And the diversity of ideas and opinions is probably a blessing that I should be embracing — the more ideas we have, the wider the variety of solutions we can imagine.
+It’s that time of year again — time for a retrospective on how I did on my goals for the year. I had 5 main goals for 2015:
+I got pretty lucky on this one. My main contract with Mercy got extended several times. Amos and I must have been doing a good job of keeping the customer happy. We even made it through a couple rounds of layoffs. I’m wrapping up the gig at Mercy now. I’m working one day a week there, as the project winds down.
+I also started a new gig this month at CenturyLink. I’m working on a cloud development team. Our current project involves selling WordPress as a service. The manager had been courting me for most of the year. I’m excited about my new role; I’ll be writing about it in a blog post soon.
+I set a goal in 2014 to give my first conference talk. I accomplished that, giving an ambitious talk at RubyConf. I enjoyed having done that, and vowed to do more conference speaking.
+I gave 3 conference talks in 2015. I gave a workshop on HTTP at RailsConf. I talked about immutable infrastructure at Madison+ Ruby. At RubyConf, I gave a talk on a micro-ORM I wrote. I also gave a lightning talk about Agile estimation (#noestimates).
+I was an alternate speaker at Windy City Rails, but did not give my talk on Alternatives to ActiveRecord. I also went to Strange Loop, mainly to see several friends and acquaintances speak.
+I wrote 24 blog articles this year. That’s about one every other week. What really kept me going was participating in a writing pact. When the pact was going, I had a 75% blogging rate. That’s pretty good.
+I’m not so sure about the quality of my blog writing though. I know that practicing writing is supposed to make you better. I know I wrote some really good articles over the past year, but I think I also wrote some articles that weren’t very good. I think sometimes the deadline has caused more harm than good. I’m not really sure what to do about that; perhaps just pushing on is the right answer.
+I’ve taken a lot of notes on the design of my programming language. Any time I learn something interesting about another language, or come up with another idea, I write it down.
+But I haven’t worked on the implementation. (I last worked on the implementation in 2014.) I should be experimenting with some ideas, implementing them to see how they work out. I’ve even kicked around the idea of starting with a Forth variant, just to get something working quickly.
+I haven’t written any articles on my ideas this year either. My notes are pretty extensive, and it would be good to write some articles to help get my thoughts straight.
+I’ve got some things to say about Agile, and want to write a book to express those ideas. I’ve made a start — I’ve got the chapters outlines, and have started on a few chapters. But I haven’t made as much progress as I’d like to. I shared what I’ve got with Amos, and he showed some interest in pairing with me on the writing. Hopefully we’ll work on it together in 2016 and publish it.
+There were a few other accomplishments that weren’t explicitly on my list, but I’d like to call attention to.
+I’ve continued participating on the This Agile Life podcast. I was in 12 of the 33 episodes that were recorded in 2015. I hope to participate in more in 2016. We’re considering scheduling a standard recording night each week, which might help us record more regularly.
+I recently took over as maintainer of Virtus, a library to declare attributes for Ruby model classes. I haven’t done a lot yet, since I’ve been busy with travel, vacation, and holidays. But I hope to catch up with all the pending pull requests and issues in the next month or so.
+The accomplishment I’m most proud of is mentoring for the Roy Clay Sr. Tech Impact program. This is a program begun as a result of the Ferguson protest movement. We’re helping teach kids (from 14 to 25) web design and development. My personal goal was to give these kids an opportunity that they would not have otherwise had. But it turned out that some of them have actually started a business building web sites for small companies. I’m so proud of the progress they’ve made in such a short time; it’s a challenging program.
+I’m pretty happy with my accomplishments this year. I made at least some progress on each of the goals I set. I’ve been thinking about my goals for next year; I’ll write that as a separate blog article next week.
+I’ve always been someone who faces my fears.
+I have a moderate case of arachnophobia. I don’t run away when I see a spider, but it creeps my out when one is crawling on me. When I was in college, I decided to buy a tarantula to attempt to get over my irrational fear of spiders. I thought I’d be able to get more comfortable with the tarantula over time, eventually to the point of letting it crawl on my arm. It didn’t work. Although I did find that my fear of tarantulas is rational — I got a terrible case of hives just from touching the urticating hairs that fell off into its water sponge.
+Last week, I was on vacation in Mexico. One of the excursions we took involved jumping in the water a lot. I’m not a strong swimmer — mostly because I have a hard time closing my nose; I hold my nose when I jump in. We zip-lined into the water a lot. At one point, there was a cliff to dive into the water from. It was about 15 feet above the water. It didn’t look so far down before jumping. But it felt like a really long way down the first time I jumped from it. It was pretty scary for me. So I did it a second time. There wasn’t any peer pressure to jump a second time. I literally jumped a second time specifically because I was scared.
+Fear is a weird thing. Fear is there to protect us. But it’s there to protect us from the dangers of the African savannah. Most of the things our fears protect us from don’t exist in our everyday modern lives. So maybe we should work to gain a better understanding of how our fears work, to figure out when to pay attention to them and when to ignore them.
+Fortunately, our brain has a good mechanism to help us do this. Our brains basically have 2 main processing systems. The first one is for quick reactions. This one involves things that are nearly reflexes. Fear is in this system. The second system is our analytical reasoning system. This system takes longer to process, but is able to take on more information.
+Whenever the situation allows us time for both systems to work, we need to listen to them both. We need to listen to our fears, because they’re there for a reason. But that reason might not pertain to our situation. So we need to realize that, and let the slow analytical system determine if we should ignore our fears.
+If we don’t allow both systems to work, we’re not taking full advantage of our brains; we’re not taking full advantage of the situations that life is presenting to us.
+I’ve been on vacation the past week, in Cozumel, Mexico. One day, we went on an excursion called Xenotes. A cenote (say-NO-tay) is a sinkhole filled with fresh water. (The “X” is to give it a more Mayan-sounding trademarkable name.) We had a lot of fun swimming, kayaking, and zip-lining. A bilingual tour guide led our group, which consisted of people from across the US and South America, of various ages and physical abilities.
+Our tour guide was a lot of fun. He made jokes, told us about the cenotes, and led us in the activities. But he also encouraged us. When someone was scared to do something, he was supportive. He told us that it was okay, and we could do it. But we also felt like it was OK to fail, if we really couldn’t. It really felt like his encouragement was literally creating courage.
+What was really neat was that despite the language barrier, everyone else was also supportive and encouraging. Everyone cheered with encouragement before someone would attempt something difficult. And we’d cheer especially loud once someone accomplished something that was difficult for their abilities.
+It was an awesome feeling to feel so supported. It made me feel like I was in a safe place, where I could try new things that were a little past my comfort zone. I was able to do the zip-line upside-down. I jumped off a 15-foot cliff into the water. I even jumped off the cliff a second time, even though I was a little scared.
+Back at the resort, we played some volleyball in the pool. It was a similar situation, with players of varying ages and abilities. Again, we tried to help the weaker players feel comfortable so they could improve without feeling judged or self-conscious. It helped everyone have a good time. It made everything more fun to be in such a supportive environment, whether I was in a position as one of the more skilled (volleyball), or one of the less skilled (jumping or zip-lining into the water). We were all able to accomplish more, with less effort.
+These experiences provide a good lesson that can be applied in a lot of places. Such a supportive environment would help any relationship, and any team. I’ve been on a couple really good software development teams, but I don’t think any of them have been as supportive as these two groups of strangers.
+I’ve decided that this should be one of my goals as a team leader. I want to create an encouraging environment for the whole team. I want to make sure that everyone is comfortable enough that they feel like they can try things that are difficult, even if they might fail (as long as nobody gets hurt).
+If a group of strangers can do this, so can your team. So can you and your significant others. We need to work every day to make sure that we’re supporting each other. It’s the best way to get everyone to achieve more.
+I got my first computer in 1984. It was a Commodore 64. I had to do extra chores and save up my allowance to buy it. I was 13.
+Back then, Sears and other retail stores had Commodore 64 computers out on display. Whenever I went to the store, I’d write a short BASIC program and leave it running on the display computers:
+10 PRINT "CRAIG IS GREAT!" +20 GOTO 10+
Hey, I was a 13-year-old kid. Later, I got a little more sophisticated. I’d change the background color instead. I still remember the POKE address:
+10 FOR I=0 TO 255 +20 POKE 53281, I +30 NEXT I +40 GOTO 10 +RUN+
This was fast enough to change the background color every few scan lines, creating a flashing scrolling effect.
+Later, I learned 6502 assembly language. I translated the BASIC program into assembler, and memorized the bytes to type in at the store. In assembly language, the background color would change several times per scan line. The effect was kind of psychedelic.
+All that happened in the mid-1980s.
+Fast-forward to about 2000 or so. I was telling the above story after a St. Louis LUG meeting. I explained how I had memorized the 10 or 12 bytes of machine code, and would leave the program running with its psychedelic effect.
+After thinking about it for a bit, I thought that 10 or 12 bytes seemed too much. It actually bothered me — I couldn’t fall asleep when I got home. I got up and found my old 6502 manuals. I figured out how to write the code in 7 bytes. I installed the Vice C64 emulator on my Linux desktop, and tested my code. It worked as expected. (The emulator was already clock-cycle perfect by then.) Here’s the assembly code:
+INX ; $E8 ; 232 +STX $D021 ; $8E $21 $D0 ; 142 33 208 ; $D021 = 53281 +JMP $C000 ; $4C $00 $C0 ; 76 0 192 ; $C000 = 49152+
Here’s the BASIC program to store that program in memory and run it:
+10 FOR N=49152 TO 49152+6: READ Q : POKE N, Q : NEXT +20 DATA 232, 142, 33, 208, 76, 0, 192 +30 SYS 49152 +RUN+
The moral of the story is that you can optimize even a 10-byte program, 15 years after the last time it was used. So don’t tell me that your program can’t be improved, no matter how small it is.
+PS. I rewrote the code above while writing this article in 2015, about 15 years after the last time I rewrote it. And I again downloaded Vice to test it, this time on Mac OS X.
+I’m wrapping up my current consulting gig at Mercy in December, and starting a new gig at CenturyLink. I’m a software developer, but that’s only a part of what I do. What I really do is join a team and help them improve the way they work — both their processes and their technical skills.
+I think this is a key differentiator for me as a consultant. Most consultants (and Agile coaches) come in and tell people what to do. I don’t like to just tell people what to do. I’d much prefer to work side-by-side with them, getting a better understanding of what their challenges are. Once I have a better understanding of the challenges, I’m able to better brainstorm some ideas to try. Then we can experiment to see what will work and what won’t.
+Instead of telling people what to do, I show them how. Most people learn better from seeing than from hearing. They also learn better if you explain how and why, not just what. So showing them how to do something is more effective than telling them. By showing and doing, you can also set a good example. This is especially important when collaboration is a large part of what needs to be improved.
+I’ve found that this style of consulting is more highly respected by everyone. I build trust with developers by working closely with them. Managers like to keep me around once they see how effective these methods can be, so the gigs I take on tend to last relatively long.
+The biggest problem I have is explaining how this works. I don’t really know what to put on my résumé. Sometimes I call myself an Agile practitioner, and sometimes an Agile player/coach. But those aren’t terribly satisfying descriptions. I’m considering actually putting “I help teams improve the way they work — both their processes and their technical skills” on the résumé. But that seems awkward, and misses the show versus tell part. I’d be open to any suggestions.
++
I facilitated a retrospective today; it was one of the best retros I’ve ever been involved with. I figured out what activities I wanted to do earlier in the morning. They were really quite simple. I wanted to focus on happiness.
+I started with two questions that I’ve used with teams before, to some success (although not so successful for one particular team). The first question I asked was “How happy are you at work?” I had them put a rating from 0 to 10, with 0 meaning they should have quit last week, and 10 meaning they couldn’t imaging being happier at work.
+The answers were mostly 7s and 8s, with a 5 and a 9. The average came to 7.5, which is pretty good. The 5 concerns me a bit, especially that it’s 2 points lower than anyone else’s answer.
+The next question I asked was “How effective do you think the teams is?”. Again, from 0 to 10, with 0 meaning they can’t accomplish anything, and 10 meaning you couldn’t imagine a more effective team.
+When I ask both of these questions, the scores are always highly correlated. If your team isn’t doing good work, it’ll make you unhappy. And if you are unhappy, you’re less likely to do your best work. This team was no different; the 5 and 9 became a 6 and a 10, and most of the 7s became 8s, for an average of just under 8.
+The next question I asked was “What makes you happy at work?”. The answers were mostly about the teamwork and teammates. This went quicker than I expected. At this point, I was worried the retro would only last a little more than 30 minutes.
+The final question I asked was “What would make you happier at work?”. This was the real pay-off. We spent about half an hour just talking about the things that would make us happier, and what we could do to improve our happiness. We came up with 10 potential action items. I usually limit teams to trying 3 or 4 action items, but most of the items are quite small, so we’re going to try 6 of them. One is just observing another team’s standup meetings, to see how they’re using their time effectively.
+Everyone went away feeling that this was a really good retro. It felt good to focus on happiness. Happiness is something I’ve been talking a lot about on the This Agile Life podcast, and it felt good to take some action on it. I’ve done “positive-only” retros before, but this one felt even better than that, by specifically targeting happiness and how we can achieve it.
+It’s taken me years to realize that being right isn’t terribly important. Especially when there’s more than one right answer — which there usually is. It’s more important to work as a team. It’s more important to be respected and to have respect for others.
+A few weeks after that interview, I was pair programming with the person who had asked me the question. We’re both senior developers, so we both have a lot of experience and opinions based on that experience. We were writing a shell script, and we both had an idea in mind about how to write the code. I let him proceed with his idea. It was a pretty good idea; probably better than mine. But we paired very effectively. I’d let him finish some code, and I’d find a way to make it better. Then he’d find a way to make my code better. What we ended up with was so much better than my original idea, and his original idea as well. I commented on this, and he agreed. We left that pairing session feeling the high of having accomplished something rare — two very experience programmers coming up with better code than we could have imagined going in.
+I like to think of writing code as a path towards a destination. The destination is good code that does what it’s supposed to, is readable (intention revealing), is concise, and is well-factored so as to be easy to change in the future. But there are many paths to that destination. Especially when pair programming, the code gets refined as ideas are shared, getting you closer and closer to that destination. Sometimes the different paths end up with the same code; sometimes they end up with different code. But if the code does its job well (according to those criteria), it doesn’t really matter what code you ended up with.
+Thinking back to the original question, I think the answer is a little more nuanced. (I’m pretty sure I followed up with an explanation, but I don’t recall the details.) It truly doesn’t matter in a lot of cases. If there are different paths that lead to the same destination, and they’re all roughly equal, then my rule works. It can also work even if the first path you try (a “wrong” path) doesn’t work out, as long as it’s easy enough to try a different path. I find that the majority of day-to-day coding fits these conditions.
+But there are some places where it’s costly to get things wrong the first time. In these cases, it’s worth spending some time thinking about and discussing the alternatives before getting started. Software architecture is the big one that comes to mind. In general, weighing the pros and cons of each option and applying previous experience works best.
+So next time you think about trying to convince someone you’re right, fight the urge. Instead, let them show you what they’re thinking. They just might surprise you. And more importantly, you might surprise yourself.
+]]>We’d brought in Diana Larsen to facilitate the Open Space. Diana is a stalwart of the Agile community, focusing on how people and teams interact. She literally (co-)wrote the book on Agile retrospectives. Diana was also kind enough to be our guest at an Agile LINC meetup later in the evening.
+The morning started off with all the participants sitting in chairs arranged in a circle. Diana rang a chime, a nice soothing tone that literally set the tone for the day. (Most people didn’t seem to like it, but I thought it had its purpose.) It also acted as a call to gather in the meeting space. She then walked around the inside of the circle as she explained what was going to happen.
+The idea behind Open Spaces came with the realization that at a conference, the “hallway track” (ad hoc discussions in the hallways) was often more valuable than the scheduled talks. So they figured out a way to capture that experience. There are only a few rules:
+Once Diana set the scene and explained the rules, people came up and presented ideas for topics. If you proposed a topic, you chose a time and location on the topic board. At that time, you’d facilitate a discussion on that topic. The format was really conducive to discussions. There was no preparation, so discussions were from the heart — lots of people felt that they could contribute.
+Being new to the company (only 2 months), I got a lot out of the workshop, beyond the content itself. I got to get to know several more people. I’d even say I made a few friends. Having open discussions, we found that many of the teams were having the same issues. This made it easy for me to talk to other people.
+All-in-all, I found the Open Space to be extremely conducive to discussions aimed at identifying issues, brainstorming solutions, and planning action items. I felt like we made great strides in addressing some of the biggest problems our organization is currently facing.
+]]>I want to increase the Open Source code I write this year. That’s basically everything I write that’s not directly related to work.
+I took over maintenance of Virtus late last year, but haven’t done a good job at finding the time for that. That’s probably more responding to issues on GitHub and merging pull requests. But eventually, I’ll likely add some features and do some refactoring.
+My goal is to work on 6 apps and libraries this year. That’s a pretty aggressive goal, but I want to focus on both learning new things and building some simple but useful things. Think MVP — focus on getting a lot of bang for not too much effort.
+I want to work on a new Rails app, to familiarize myself with Rails 5. I want to get some experience with some more modern gems. I also want to see if I can use some new techniques with a Rails app, especially things that might help us get closer to a hexagonal architecture. I’m also hoping to work with some different web frameworks — maybe Lotus, Rodakase, Trailblazer, or Phoenix. Or maybe one of the Crystal web frameworks.
+I also want to work on a couple Elm apps. I started the STL Elm group as an excuse to learn the language. I’d like to work on a Twitter client, that might eventually turn into a more general reading app. Beyond Twitter, it would keep track of things I want to read. The other Elm app I’d like to write is a game, based on the old Space Taxi game I loved to play on the Commodore 64.
+I wrote a micro-ORM last year called Ruby Preserves. I’ve started converting that from working with raw SQL to sitting atop the awesome Sequel gem. The simplicity is still there so far, and basing it on Sequel has so far gone easier than I expected. But I haven’t figured out how to do relationships (JOINs) yet; that will be the real test.
+I’m pretty happy with my 2015 conference experience. I want to keep my conference level about the same. I don’t really want to commit to more talks than I gave last year. Conference presentations take a lot of time and energy to write and practice.
+I’m planning to go to RailsConf, RubyConf, and Strange Loop. I’m hoping to give a talk at each of those, if I can. But I’ll probably attend all of them even if I’m not speaking. I’m also submitting a talk to Agile 2016. I’m unlikely to go to any other conferences, and even more unlikely to give more than 4 conference talks.
+I really want to finish my Effective Agile book this year. I’m going to try to pull Amos in to pair with me on it occasionally, to move it forward. If I’m able to get it done, I’d also like to maybe write a book on Elm.
+I actually want to do less blogging this year. Well, sort of. I want to put coding and book writing ahead of blogging. If that means less blogging, I’m okay with that. So my goal for blogging is more like every other week. And when I do write a blog article, I’d rather it be related to some code I’m working on, something that I could use in my book, or some more in-depth thoughts about programming language design.
+The contract I recently started at CenturyLink Cloud is open-ended, so I’ll likely be there for the entire year. I’m enjoying it so far; it’s a challenge, but I think I can make a significant impact. However, I’m really interested in moving to San Francisco in 2017. So I’m going to work on preparing for that in several ways.
+I’m going to resurrect my LinkedIn account. I’ve neglected it for a few years now. I’ll make sure everything is up to date, and make some connections I’ve been putting off. I also want to reclaim my Stack Exchange and Hacker News accounts.
+I’m going to pay a an expert to help me revamp my résumé. I think it’s pretty decent, but it could use some freshening up. I want it to stand out. I want to do a better job of explaining what I really do — which is to join a team to help them improve their processes and their technical skills.
+I’ll also need to clean up all my web sites, so they look nice when people come to take a look at them. This includes my personal site, consulting business site, wiki, and blogs. I should also upgrade my server to the latest version of Debian, and use Ansible and some other tools to provision it using the principles of Infrastructure as Code.
+]]>I started out with a pretty simple question: “What do you value (in regards to what we’re building); what are you willing to fight for?” I asked them each to write down several values and then put them on the board before looking at everyone else’s answers. I also asked each person to rank their values in order of importance.
+It turned out that my question was a little vague. Some people thought about the question in terms of the end result, and some in terms of the process of creating the software. In some ways that was a bit of a problem, because the different interpretations led people in different directions. But in other ways, not pushing them in any particular direction got more varied answers, exposing how they think about the project and the product.
+My list (in order) was Effectiveness (doing the right thing), Quality (doing things right the first time), Happiness, Purpose, and Teamwork. In retrospect, I should have put Happiness first. If I’m not happy at work, I don’t really want to be there, and need to move on. (Sometimes I can trade some happiness at work for more happiness at home, but I’m definitely a person that needs to be happy at work.) The other values serve to improve my happiness, but the happiness is more important.
+My own issue ranking my values turned out to be a problem with the ranking in general. Should they be ranked in importance of the necessity of the value as an outcome, or in importance of the necessity to focus on the value? I think the former is what I was looking for, but even I wasn’t clear on that when I began the exercise.
+After everyone put their values up on the board, we read them off. Then I asked the team to choose several values that we share as a team. We pulled them off the individual members’ lists, and put them in the team list. Then I asked each person to come up and rank those values, then explain why they had ordered them that way, especially when they ordered them significantly different than the last person. I was hoping to come to some convergence of the rank over time, so we could document our values in rank order. That didn’t happen. But the discussion was illuminating to me and to everyone on the team.
+I think the most interesting part about the lack of convergence was the difference between the developers and the product guys. The product guys definitely viewed the values more in terms of outcomes than the process. That makes sense — they’re not as intimately involved in the process of building the product.
+We were able to converge on the top priority though: Will the user buy the product? This was a combination of a couple different values that we merged together. This included the end user experience as well as making sure the team would continue to have a reason for existing. The rest of the values we left unordered: Teamwork (cohesiveness), Data driven decisions, Team ownership, Simplicity, Effectiveness, Maintainability / Supportability, Quality, Automation, and Performance. I think that’s a pretty decent list.
+As a couple teammates pointed out, those values are probably in part a reflection of this current point in time. If I asked the same question some other time, under different conditions and team dynamics, the answers would probably change a bit. And we’d probably come up with other answers if asked again, just due to randomness of the way we think about these things.
+But I don’t think I’d do this activity a second time with the team. It was really about understanding our motivations — both our own, and those of our teammates. I found it effective in that way, and also in helping the team to think about our culture and how we can work to shape it to help us all push in the same direction.
+There are a few caveats. When I asked for feedback on the exercise, one teammate pointed out that it wouldn’t work if people weren’t honest about their values, and they answered with what they thought management or their teammates wanted to hear. I don’t think that was an issue with this group, but it’s something to keep in mind.
+The other major thing I’d do is to make it clear up front that I’m not looking for any action items from this activity; it’s more about understanding each other and ourselves. And next time, I’ll work to clarify how to rank the values.
+I would recommend this activity for a new team, or when the makeup of the team is changing in some significant way. I wish there was a way to help a team converge on the ranking of their values, but I suppose I should be happy that agreeing on the set of important values went pretty quickly. And the diversity of ideas and opinions is probably a blessing that I should be embracing — the more ideas we have, the wider the variety of solutions we can imagine.
+]]>I got pretty lucky on this one. My main contract with Mercy got extended several times. Amos and I must have been doing a good job of keeping the customer happy. We even made it through a couple rounds of layoffs. I’m wrapping up the gig at Mercy now. I’m working one day a week there, as the project winds down.
+I also started a new gig this month at CenturyLink. I’m working on a cloud development team. Our current project involves selling WordPress as a service. The manager had been courting me for most of the year. I’m excited about my new role; I’ll be writing about it in a blog post soon.
+I set a goal in 2014 to give my first conference talk. I accomplished that, giving an ambitious talk at RubyConf. I enjoyed having done that, and vowed to do more conference speaking.
+I gave 3 conference talks in 2015. I gave a workshop on HTTP at RailsConf. I talked about immutable infrastructure at Madison+ Ruby. At RubyConf, I gave a talk on a micro-ORM I wrote. I also gave a lightning talk about Agile estimation (#noestimates).
+I was an alternate speaker at Windy City Rails, but did not give my talk on Alternatives to ActiveRecord. I also went to Strange Loop, mainly to see several friends and acquaintances speak.
+I wrote 24 blog articles this year. That’s about one every other week. What really kept me going was participating in a writing pact. When the pact was going, I had a 75% blogging rate. That’s pretty good.
+I’m not so sure about the quality of my blog writing though. I know that practicing writing is supposed to make you better. I know I wrote some really good articles over the past year, but I think I also wrote some articles that weren’t very good. I think sometimes the deadline has caused more harm than good. I’m not really sure what to do about that; perhaps just pushing on is the right answer.
+I’ve taken a lot of notes on the design of my programming language. Any time I learn something interesting about another language, or come up with another idea, I write it down.
+But I haven’t worked on the implementation. (I last worked on the implementation in 2014.) I should be experimenting with some ideas, implementing them to see how they work out. I’ve even kicked around the idea of starting with a Forth variant, just to get something working quickly.
+I haven’t written any articles on my ideas this year either. My notes are pretty extensive, and it would be good to write some articles to help get my thoughts straight.
+I’ve got some things to say about Agile, and want to write a book to express those ideas. I’ve made a start — I’ve got the chapters outlines, and have started on a few chapters. But I haven’t made as much progress as I’d like to. I shared what I’ve got with Amos, and he showed some interest in pairing with me on the writing. Hopefully we’ll work on it together in 2016 and publish it.
+There were a few other accomplishments that weren’t explicitly on my list, but I’d like to call attention to.
+I’ve continued participating on the This Agile Life podcast. I was in 12 of the 33 episodes that were recorded in 2015. I hope to participate in more in 2016. We’re considering scheduling a standard recording night each week, which might help us record more regularly.
+I recently took over as maintainer of Virtus, a library to declare attributes for Ruby model classes. I haven’t done a lot yet, since I’ve been busy with travel, vacation, and holidays. But I hope to catch up with all the pending pull requests and issues in the next month or so.
+The accomplishment I’m most proud of is mentoring for the Roy Clay Sr. Tech Impact program. This is a program begun as a result of the Ferguson protest movement. We’re helping teach kids (from 14 to 25) web design and development. My personal goal was to give these kids an opportunity that they would not have otherwise had. But it turned out that some of them have actually started a business building web sites for small companies. I’m so proud of the progress they’ve made in such a short time; it’s a challenging program.
+I’m pretty happy with my accomplishments this year. I made at least some progress on each of the goals I set. I’ve been thinking about my goals for next year; I’ll write that as a separate blog article next week.
+]]>I have a moderate case of arachnophobia. I don’t run away when I see a spider, but it creeps my out when one is crawling on me. When I was in college, I decided to buy a tarantula to attempt to get over my irrational fear of spiders. I thought I’d be able to get more comfortable with the tarantula over time, eventually to the point of letting it crawl on my arm. It didn’t work. Although I did find that my fear of tarantulas is rational — I got a terrible case of hives just from touching the urticating hairs that fell off into its water sponge.
+Last week, I was on vacation in Mexico. One of the excursions we took involved jumping in the water a lot. I’m not a strong swimmer — mostly because I have a hard time closing my nose; I hold my nose when I jump in. We zip-lined into the water a lot. At one point, there was a cliff to dive into the water from. It was about 15 feet above the water. It didn’t look so far down before jumping. But it felt like a really long way down the first time I jumped from it. It was pretty scary for me. So I did it a second time. There wasn’t any peer pressure to jump a second time. I literally jumped a second time specifically because I was scared.
+Fear is a weird thing. Fear is there to protect us. But it’s there to protect us from the dangers of the African savannah. Most of the things our fears protect us from don’t exist in our everyday modern lives. So maybe we should work to gain a better understanding of how our fears work, to figure out when to pay attention to them and when to ignore them.
+Fortunately, our brain has a good mechanism to help us do this. Our brains basically have 2 main processing systems. The first one is for quick reactions. This one involves things that are nearly reflexes. Fear is in this system. The second system is our analytical reasoning system. This system takes longer to process, but is able to take on more information.
+Whenever the situation allows us time for both systems to work, we need to listen to them both. We need to listen to our fears, because they’re there for a reason. But that reason might not pertain to our situation. So we need to realize that, and let the slow analytical system determine if we should ignore our fears.
+If we don’t allow both systems to work, we’re not taking full advantage of our brains; we’re not taking full advantage of the situations that life is presenting to us.
+]]>Our tour guide was a lot of fun. He made jokes, told us about the cenotes, and led us in the activities. But he also encouraged us. When someone was scared to do something, he was supportive. He told us that it was okay, and we could do it. But we also felt like it was OK to fail, if we really couldn’t. It really felt like his encouragement was literally creating courage.
+What was really neat was that despite the language barrier, everyone else was also supportive and encouraging. Everyone cheered with encouragement before someone would attempt something difficult. And we’d cheer especially loud once someone accomplished something that was difficult for their abilities.
+It was an awesome feeling to feel so supported. It made me feel like I was in a safe place, where I could try new things that were a little past my comfort zone. I was able to do the zip-line upside-down. I jumped off a 15-foot cliff into the water. I even jumped off the cliff a second time, even though I was a little scared.
+Back at the resort, we played some volleyball in the pool. It was a similar situation, with players of varying ages and abilities. Again, we tried to help the weaker players feel comfortable so they could improve without feeling judged or self-conscious. It helped everyone have a good time. It made everything more fun to be in such a supportive environment, whether I was in a position as one of the more skilled (volleyball), or one of the less skilled (jumping or zip-lining into the water). We were all able to accomplish more, with less effort.
+These experiences provide a good lesson that can be applied in a lot of places. Such a supportive environment would help any relationship, and any team. I’ve been on a couple really good software development teams, but I don’t think any of them have been as supportive as these two groups of strangers.
+I’ve decided that this should be one of my goals as a team leader. I want to create an encouraging environment for the whole team. I want to make sure that everyone is comfortable enough that they feel like they can try things that are difficult, even if they might fail (as long as nobody gets hurt).
+If a group of strangers can do this, so can your team. So can you and your significant others. We need to work every day to make sure that we’re supporting each other. It’s the best way to get everyone to achieve more.
+]]>Back then, Sears and other retail stores had Commodore 64 computers out on display. Whenever I went to the store, I’d write a short BASIC program and leave it running on the display computers:
+10 PRINT "CRAIG IS GREAT!" +20 GOTO 10+
Hey, I was a 13-year-old kid. Later, I got a little more sophisticated. I’d change the background color instead. I still remember the POKE address:
+10 FOR I=0 TO 255 +20 POKE 53281, I +30 NEXT I +40 GOTO 10 +RUN+
This was fast enough to change the background color every few scan lines, creating a flashing scrolling effect.
+Later, I learned 6502 assembly language. I translated the BASIC program into assembler, and memorized the bytes to type in at the store. In assembly language, the background color would change several times per scan line. The effect was kind of psychedelic.
+All that happened in the mid-1980s.
+Fast-forward to about 2000 or so. I was telling the above story after a St. Louis LUG meeting. I explained how I had memorized the 10 or 12 bytes of machine code, and would leave the program running with its psychedelic effect.
+After thinking about it for a bit, I thought that 10 or 12 bytes seemed too much. It actually bothered me — I couldn’t fall asleep when I got home. I got up and found my old 6502 manuals. I figured out how to write the code in 7 bytes. I installed the Vice C64 emulator on my Linux desktop, and tested my code. It worked as expected. (The emulator was already clock-cycle perfect by then.) Here’s the assembly code:
+INX ; $E8 ; 232 +STX $D021 ; $8E $21 $D0 ; 142 33 208 ; $D021 = 53281 +JMP $C000 ; $4C $00 $C0 ; 76 0 192 ; $C000 = 49152+
Here’s the BASIC program to store that program in memory and run it:
+10 FOR N=49152 TO 49152+6: READ Q : POKE N, Q : NEXT +20 DATA 232, 142, 33, 208, 76, 0, 192 +30 SYS 49152 +RUN+
The moral of the story is that you can optimize even a 10-byte program, 15 years after the last time it was used. So don’t tell me that your program can’t be improved, no matter how small it is.
+PS. I rewrote the code above while writing this article in 2015, about 15 years after the last time I rewrote it. And I again downloaded Vice to test it, this time on Mac OS X.
+]]>I think this is a key differentiator for me as a consultant. Most consultants (and Agile coaches) come in and tell people what to do. I don’t like to just tell people what to do. I’d much prefer to work side-by-side with them, getting a better understanding of what their challenges are. Once I have a better understanding of the challenges, I’m able to better brainstorm some ideas to try. Then we can experiment to see what will work and what won’t.
+Instead of telling people what to do, I show them how. Most people learn better from seeing than from hearing. They also learn better if you explain how and why, not just what. So showing them how to do something is more effective than telling them. By showing and doing, you can also set a good example. This is especially important when collaboration is a large part of what needs to be improved.
+I’ve found that this style of consulting is more highly respected by everyone. I build trust with developers by working closely with them. Managers like to keep me around once they see how effective these methods can be, so the gigs I take on tend to last relatively long.
+The biggest problem I have is explaining how this works. I don’t really know what to put on my résumé. Sometimes I call myself an Agile practitioner, and sometimes an Agile player/coach. But those aren’t terribly satisfying descriptions. I’m considering actually putting “I help teams improve the way they work — both their processes and their technical skills” on the résumé. But that seems awkward, and misses the show versus tell part. I’d be open to any suggestions.
++]]>
I started with two questions that I’ve used with teams before, to some success (although not so successful for one particular team). The first question I asked was “How happy are you at work?” I had them put a rating from 0 to 10, with 0 meaning they should have quit last week, and 10 meaning they couldn’t imaging being happier at work.
+The answers were mostly 7s and 8s, with a 5 and a 9. The average came to 7.5, which is pretty good. The 5 concerns me a bit, especially that it’s 2 points lower than anyone else’s answer.
+The next question I asked was “How effective do you think the teams is?”. Again, from 0 to 10, with 0 meaning they can’t accomplish anything, and 10 meaning you couldn’t imagine a more effective team.
+When I ask both of these questions, the scores are always highly correlated. If your team isn’t doing good work, it’ll make you unhappy. And if you are unhappy, you’re less likely to do your best work. This team was no different; the 5 and 9 became a 6 and a 10, and most of the 7s became 8s, for an average of just under 8.
+The next question I asked was “What makes you happy at work?”. The answers were mostly about the teamwork and teammates. This went quicker than I expected. At this point, I was worried the retro would only last a little more than 30 minutes.
+The final question I asked was “What would make you happier at work?”. This was the real pay-off. We spent about half an hour just talking about the things that would make us happier, and what we could do to improve our happiness. We came up with 10 potential action items. I usually limit teams to trying 3 or 4 action items, but most of the items are quite small, so we’re going to try 6 of them. One is just observing another team’s standup meetings, to see how they’re using their time effectively.
+Everyone went away feeling that this was a really good retro. It felt good to focus on happiness. Happiness is something I’ve been talking a lot about on the This Agile Life podcast, and it felt good to take some action on it. I’ve done “positive-only” retros before, but this one felt even better than that, by specifically targeting happiness and how we can achieve it.
+]]>Web Development, Ruby on Rails, Open Source
+I’m surprised that I haven’t gotten this story down in print before. It’s something I’ve mentioned many times — including a few times on the podcast. It’s a great story about the power of retrospectives, and it’s a great story about the power of a blameless post-mortem.
+I don’t recall all the specifics at this point. It was about 5 years ago. I’d just noticed that Arun had made some sort of mistake. That’s fine, people make mistakes. The thing that was different about his mistake was that I had made the same mistake about a week prior. And Amos had made the same mistake about a week before that.
+Noticing a pattern of mistakes, Amos and I called an impromptu retrospective. We gathered all the developers into a conference room. We explained the problem that we were running into. At first, Arun was defensive. That’s understandable; he thought we were there to come down on him, to lay blame. But we made it clear that we weren’t focusing on him. We admitted that we had also made the same mistake recently. We weren’t there to lay blame; we were there to figure out how our team could stop making the mistake. It took Arun a few minutes to get over the defensiveness.
+With the defensiveness out of the way, we could focus on the issue at hand. We were able to figure out the root cause of us all making the mistake. (I don’t know if we played the “5 whys” game, but I’m sure we effectively did something similar.) And with that, we were able to change our process, so that nobody else would make the same mistake again.
+There are 2 important points to this story. First, you don’t have to wait until a scheduled retrospective to hold a retrospective. This one was impromptu, and it’s the best one we ever had. We saw a problem, addressed it, and found a solution in less than an hour. Had we waited until the end of the week, we would have forgotten some of the details, and wouldn’t have been as effective at solving the problem. Second, when addressing problems, take your ego out of the equation. If you’re in a position of authority, take the blame — but never place blame. Focus on what’s important — solving the problem.
+And don’t forget the Retrospective Prime Directive:
++Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
+
I’m a big proponent of Agile (mostly XP; I’m mostly anti-Scrum) and I’ve contributed some to the #noestimates “movement”.
+I don’t really mean that nobody should ever estimate anything. I mean that I’ve never seen useful (fine-grained) estimates anywhere. Here are some of the problems with estimates that I’ve seen frequently:
+I’ll note that most of these pit management against the team, instead of working together toward a common cause. Most of the practices also lead to seriously demoralizing the team. And most of the time, the estimates aren’t really even taken into account very much.
+My advice is to first understand the value of a project before you consider estimating the costs. The estimation at this point will be very rough, so make sure that you have a very wide margin between the expected value and the rough estimate of the cost. If you’re pretty certain of the expected value, I’d probably want to make sure I could still be profitable even if it took 3 or 4 times as long to complete as the rough estimate. And if there’s uncertainty in the expected value, much more.
+Another way to mitigate the risk of throwing money at something that’s not going to have positive ROI is to reduce the feedback loop. Order the work so that the tasks are ranked in order of value to the customer. (Realistically, you’ll have dependencies of tasks to worry about, and should consider effort involved too.) So work on the most valuable feature first — get that out into production as soon as possible. Once that’s done, you can assess if your ROI is positive or not. Keep iterating in this fashion, working on the features that will provide the most value first. Keep assessing your ROI, and stop when the ROI is no longer worth it, compared to other projects the team could be working on.
+At a fine-grained level, if you’re using story points, I’d ask you to do the math to see if just counting the stories would be as effective at predicting how much will be done over time as using the story points. If so, you can save the time the team spends on estimating stories. I’d still recommend spending time talking about stories so that everyone has a shared understanding of what needs to be done, and to break stories up into a smaller, more manageable size — with one acceptance criteria per story. Also take a look to see if empirical average cycle time (how long it takes a single story to move from start to finish) might provide you the predictive power just as well as estimates. (I.e. is it bandwidth or latency that really provides the predictive power you’re looking for?)
+And don’t forget Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.
+While creating a web page isn’t too difficult, there are a lot of moving parts involved in creating an effective website. We’ve written up this checklist as a guide for anyone who has decided that they need a website.
+This list is for a basic static website. A web application will require significantly more effort. We’re working on a separate checklist for web apps.
+You’ll probably want your own domain name.
+You’ll need to have someone take care of the servers that tell the world what server addresses your domain name corresponds to.
+You’ll need servers to host your web site on. There are a lot of options available, from virtual hosts (a Linux server where you control everything) to application-specific services.
+Designing and developing the site can vary from picking an existing template and adding content, to developing a full web application.
+What other services do you need, besides just the web site?
+Over the lifetime of the site, you’ll likely pay more in maintenance costs than the upfront costs.
++
It all started with an email about a WebInspect report. It listed a buffer overflow, which we had marked as a false positive. I read the WebInspect report carefully, and found a note at the bottom that said you could test manually to confirm whether it was a false positive or not. Unfortunately, the manual test listed had a few problems. First, it jammed the lines together, without the proper line-breaks. Second, it assumed the site was using HTTP, not HTTPS, so used telnet. Third, it was testing against a page that didn’t exist, giving a 404. Keeping those in mind, I tried the manual test using the openssl s_client command:
openssl s_client -quiet -connect mysite.example.com:443 +POST /login HTTP/1.1 +Host: mysite.example.com +Transfer-Encoding: chunked + +c00000000+
The test terminated immediately. The report said that this meant that the server was vulnerable to a buffer overflow and arbitrary code execution.
+At first, we thought this was caused by Apache or Tomcat, or possibly the application code. But the reported vulnerability was an Apache CVE from 2002 (CVE-2002-0392), fixed by vendors long ago. After a while, we realized that if we hit the servers directly, we did not get the indication of a vulnerability. If we hit the site through the F5 VIP, we saw the immediate termination of the connection. The issue is with handling of HTTP chunked encoding. Nginx had a similar issue in 2013 (CVE-2013-2028).
+So we turned our attention to the F5 load balancers. We were able to confirm that other sites using F5 load balancers were exhibiting the same behavior. We also confirmed that WebInspect run against the servers directly did not show the issue (even as a false positive). We reported the issue to F5, and they are looking into it.
+I’m disclosing this publicly now for a few reasons. First, I’m not a security researcher, and almost nobody follows my blog — especially people looking for security issues that could be exploited. Second, I’ve not developed a payload, so I have no idea whether this is exploitable. But at this point, it’s merely a potential vulnerability. I’m not sure I’ll even spend the time to research and create a payload to prove the vulnerability. If I do, I’ll be more careful with the disclosure.
++
I’ve been working on application architectures based on Uncle Bob’s Ruby Midwest talk, following the hexagonal architectural pattern. I posted an article a couple months ago showing a way that works fairly well in Rails, and some accompanying Rails example code. But there was one thing I wasn’t quite happy with.
+The problem is that we used callbacks (actually, a publish/subscribe mechanism) in a situation where they don’t seem to quite fit:
+ def show
+ interactor.on(:display) { |order| render order }
+ interactor.on(:not_found) { |order_id| render status: 404 }
+ interactor.get(params[:id])
+ end
+What we really want is to respond in different ways, depending on the result of the call to interactor.get(). There’s no good reason to define the responses before the call. It makes a lot more sense to define the responses after the call, because they’ll happen after the call. I’d much prefer that the code be written in the order that it will be run.
I discussed this problem with my friend and colleague, Amos King. We came up with a better solution, which puts things back in the right order:
+ def show
+ interactor.get(params[:id]) do |on|
+ on.display { |order| render order }
+ on.not_found { |order_id| render status: 404 }
+ end
+ end
+He even wrote a small library to do this, which he called Riposte. I’m not sure what to call this pattern, but it seems to work pretty well in this situation. I suppose that they’re still technically callbacks, because they’re passed in in the block that’s passed in to the call to interactor.get(). But due to the magic of Ruby blocks, we get to put them in the order they should be.
Riposte also gives you the option of using the response object directly, instead of passing a block:
+ def show
+ on = interactor.get(params[:id])
+ on.display { |order| render order }
+ on.not_found { |order_id| render status: 404 }
+ end
+This shows that it’s just returning an object, with the twist that the response object has methods that take blocks. The nested blocks variant is really the same thing, except that it’s yielding to the response object instead of returning it.
+I’ve decide that is the pattern I’d like to use for interactions and their callers within Ruby hexagonal architecture.
+I’ve started working on my own framework in Ruby in the past couple days. It’s built upon my recent work at understanding Uncle Bob’s Ruby Midwest 2011 talk, and his article on Clean Architecture, and the resulting hexagonal architecture (AKA ports and adapters).
+Somehow my research in that vein led me to Gary Bernhardt’s Boundaries talk. I’ve read a lot about the talk, and knew about the idea of “functional core / imperative shell”. And I’ve worked with a lot of similar ideas lately. But I believe this is the first time that I actually watched the whole video.
+Even after having read a lot about similar ideas, it was pretty mind-expanding. Gary’s really good at presenting these kinds of ideas in a simple way.
+OOP as usually taught includes encapsulation of data together with behavior, with mutable objects. Functional programming separates data and behavior, with mostly immutable data. From experience, encapsulating data and behavior together seems helpful. But experience also shows that immutability is useful. So it would be good to have both of those together. This is something I’ve been thinking for a few years — how best do we get both?
+Gary calls the combination “FauxO”. Logic and data are still combined, but there’s no mutation. Anywhere OOP would normally have mutation would just generate a new object. There’s no language restriction involved in enforcing immutability — just discipline.
+But without mutability, it’s hard to do IO and maintain state. So Gary’s solution is to encapsulate as much as possible into an immutable (functional or FauxO) core, and around that, use an imperative (traditional OOP) shell. The functional core contains the bulk of the logic, and the imperative shell is a glue layer that handles the real world, including disk, network, and other I/O.
+The result of this is that the shell has fewer paths, but more dependencies. The core contains no dependencies, but encapsulates the different logic paths. So we’re encapsulating dependencies on one side, and business logic on the other side. Or put another way, the way to figure out the separation is by doing as much as you can without mutation, and then encapsulating the mutation separately.
+I love how this naturally breaks things up, so that the core is all testable with unit tests, and the imperative shell is tested with integration tests. And since the shell has few or no logic paths, you get the testing pyramid, with more unit tests and fewer integration tests. The whole thing ends up being quite beautiful. Tests end up being very fast without any extra effort — not even stubbing or mocking. This tells us that things have been decomposed very well — an elegant design.
+Gary makes the case that immutable objects can be treated as values, and passed across boundaries. Even process boundaries. This is something I’ve noticed as I’ve been working on my own Uncle Bob style hexagonal framework, but nobody in that camp ever mentioned that — they prefer DTOs or something more like hashes. I’m completely against hashes, because of the “stringly-typed” problem. And I don’t see much advantage in a DTO if I’ve got an immutable object; I’d be basically copying the object to an almost identical object. And I’d be losing any laziness possible for derived values within the original immutable object.
+It’s striking to me how Gary’s image of an imperative shell around a functional core, plus Net, Disk, and State outside of the shell mirror’s Uncle Bob’s concentric circles. Uncle Bob has entities in the middle, surrounded by use cases, surrounded by Web, DB, and UI.
+Another advantage that Gary shows is that breaking things up this way allows easy concurrency. In his example, he shows using the actor model — either just using threads and queues, or an actor library (or language feature).
+After several years of thinking about the architectural issues seen in most large Rails apps, I’m starting to come to an understanding of how to combine all these ideas and come up with an architecture that will work better.
++
The Agile Manifesto was written in 2001, as a way to explain the common values amongst several “light-weight” software development methodologies that had come about. The term “Agile” was chosen as a shorthand for those commonalities.
+Once “Agile” started to show success, we started to see many people use the term to market their products and services, whether or not they really believed in the values and principles of the Agile Manifesto. It’s gotten to the point where some of us don’t see much value in using the term “Agile” any more. Even some of those involved in creating the manifesto have suggested new terms. Dave Thomas suggests “Agility” and Andy Hunt has started working on something called GROWS. Personally, I’m considering going back to the term “Extreme Programming”, even though I’ve incorporated ideas from other Agile methodologies.
+It recently occurred to me that Agile, when done “right”, is closely aligned with the happiness of the team members. This is really interesting, because it aligns the interests of the employees and the business — a win-win situation. My next thought was that maybe the next step after “Agile” will be a focus on happiness and motivation.
+I’ve recently been thinking about personal motivation lately, in the context of team practices. According to Daniel Pink’s book Drive, people are motivated by autonomy, mastery, and purpose. I personally add a fourth that can sometimes trump the other three: identity. And of course, happiness can also be motivating — both in the attempt to achieve happiness and in just being happy. (I suspect that happiness is more of a parallel to motivation than a cause though.)
+There are a couple different ways that happiness can be achieved at work. The traditional way is for work to be a means to an end. In this view, the purpose of your job is to provide the money to live your life (outside of work) the way that you want to live it. There’s nothing wrong with this way of thinking. But for the lucky few, we can work on something that makes us happy in and of itself. That’s generally done by finding a job doing something that we enjoy.
+But perhaps that’s thinking about things the wrong way. For one, plenty of people who have gone that route are still unhappy at work. I think a lot of that has to do more with the context surrounding the work than the work itself. Maybe you’ve got a lousy manager. Maybe you don’t like the people you work with. Maybe the tools you have to work with are bad. Maybe the processes add a lot of unnecessary tedium.
+So maybe we need to find ways to be happier at work. Most of the Agile practices seem to make team members happy. For example, replacing a light-weight process for a heavier process always makes me happy. And I typically leave retrospectives in a good mood. So that’s a good starting point. But we should see if we can take the idea further. If we take employee happiness as a core value, where can we go? What kind of practices would we want to add? Please share any ideas in the comments below.
+On a recent episode (78) of This Agile Life, my fellow hosts talked about when to do Test-Driven Development (TDD). They all said that you should always do TDD — at least for anything that will go into production; there’s an exception for experimenting or “spiking”.
+I wasn’t on that episode, but later commented on the topic. (Episode 83 — which wasn’t really all that great.) My take was slightly different. I said that you should do TDD only when the benefits outweigh the costs. Unfortunately, we usually greatly underestimate the benefits. And the costs often seem high at first, because it takes some time to get good at writing automated tests. Not to mention that both the costs and the benefits are usually hard to measure.
+What is the cost of writing automated tests? I’ve asked this question before and recorded the answers (inasmuch as we have them) in a previous blog entry. TDD costs us about 10-30% in short-term productivity. The benefit that they found was a reduction in bugs by 30-90%, and a decrease in code complexity by about 30%.
+But what about when the costs are higher than the normal 10 to 30 percent? One good example of this is when there’s no test framework for the situation you’re testing. This might be a new language or framework that you’re working with. More likely it’s a complex API that you have to mock out. So that could increase the cost of automated testing so as to outweigh the benefits — especially on a short project. I could imagine situations where the cost of writing the mocks could eat up more than the project itself.
+Another case where we might consider skipping testing is when we’re more concerned about time to market than quality. This is almost always a mistake. Your code will almost always last longer than you expect. (Remember Y2K?) And if the code lasts longer than you expect, that means you’ll have to deal with bugs that whole time. But we have to work with the information we have at the time we make our decisions. And sometimes that might tell us that time to market is more important than anything.
+One final case I can imagine is when a true expert is coding something that they’re very familiar with. I could picture someone like Uncle Bob writing code (in a language that he’s familiar with) without tests just as effectively as I could write code with tests.
+But these situations should not be common; they’re edge cases. In almost all real-world cases, TDD is the right thing to do. Don’t forget, TDD is also a design discipline — it helps you design a better API. So keep doing TDD. But as with any practice, don’t do it blindly without considering why we’re doing it. Make sure you understand the costs, and whether the benefits outweigh the costs.
+I ran into some former colleagues recently, from a company where I had worked to help transform the team to be more Agile. They’ve gone through some reorganization and management changes recently. One of the guys said that their team culture has helped them maintain quality in the face of those changes. This struck me as odd, since I had considered the work I had done there as somewhat of a disappointment. While I felt I had made a small dent, I didn’t feel like I’d made a true Agile transformation. Much of what I had taught didn’t seem to “stick”.
+Later that night I thought about why my opinion of the team and his opinion were so different. There are a lot of reasons why an Agile “transformation” could fail. It could be due to lack of support from management. Or even worse, not getting the team members to buy into the ideas — usually due to fear of change. But while those had some effect in this case, they weren’t really the main issues. Now that I’ve had some time and some distance from that team, I’ve gained some clarity on what the real issues were.
+I think the reason that I think this transformation was a failure was due to the continued pace of change that true Agile requires. Basically the team experienced “change fatigue”, where everything keeps changing and you feel like you can never catch your breath. But the more interesting thing is how our perceptions differed. He seemed to think that the transformation was a success — they’re doing things better than they used to. I view it as more of a failure, because they basically stopped improving — at least at the pace that I was hoping for.
+I think this difference in mindset is pretty fundamental. My view of Agile involves continuous improvement — always inspecting and adapting our processes. I suppose that means that my preferred flavor of Agile is “Kaizen“. But other people don’t see improvement and change as a constant — they see each change as a means to an end. I’m starting to realize that neither viewpoint is objectively correct. Maybe they’re both fine viewpoints to have. Maybe I shouldn’t be so hard on myself and view that engagement as a failure, especially if my teammates view it as a success. Maybe perfection is the enemy of the good. And maybe I need to learn to be happy with “good enough”.
++
I frequently participate in a podcast called This Agile Life. Recently, a listener asked how much time Agile teams should spend on self improvement. I said 10% to 25%, leaning towards 15% to 20% for most teams. That comes to at least one hour per day, and maybe even more than one day per week.
+I’m including personal self improvement and team retrospectives in this self-improvement time. This can be as simple as configuring your IDE to make you more efficient, learning to use a tool better, or following up on action items from a retro.
+That may seem like a lot of time “wasted”. But I think I can justify the cost of all that time.
+The purpose of spending time on team or self-improvement — the whole point — is to increase our performance and our efficiency. How much improvement can we expect? Can we improve by 1% each week? That doesn’t sound too unreasonable. I think that’s an achievable goal for almost any team, at least on average.
+Spending 20% of your time to gain 1% doesn’t seem like it’s worth it — until you consider the long term. With compound interest, you’ll be 67% more efficient by the end of a year.1 At that point, you’ll be able to get things done in 59% of the time — saving 41% of the time required at the beginning of the year.2 The following years will show even more progress, as compared to when you started. If 10x programmers exist, continuous improvement is apparently the way to get there.
+So there’s a pretty good return on investment, even with a small amount of improvement each week. You’ll be significantly more efficient.
+But efficiency isn’t really what you should aim for. You should aim for effectiveness. You can be efficient in creating the wrong thing. Part of improving should be ensuring that you’re not just building things right, but that you’re building the right things. Build what the customer really needs. Find ways to ask the right questions.
+Most importantly, find ways to keep improving. It would be a waste of time not to.
+ +Web Development, Ruby on Rails, Open Source
+I created a Ruby gem recently, called includable-activerecord. It’s pretty small, but I thought I might explain why I created it, and discuss its implementation.
+When you use ActiveRecord, you normally include it in your model like this:
+class User < ActiveRecord::Base + # ... +end+
Your User class is inheriting from the ActiveRecord::Base class. This is class-based inheritance, also called “classical” inheritance. (That’s “classical” as in “class”, not as a synonym for “traditional”.) Class-based inheritance represents an “is-a” relationship. So we’re saying that a user is an ActiveRecord base. Another way to say this is that User is a subclass of ActiveRecord::Base.
+
+There are a few problems with this. First, what is a “base”? The name was chosen because it’s a base class. But just like we don’t give factory classes names like UserFactory (at least not in Ruby), we shouldn’t name base classes Base.
I suppose that we’re trying to say that this is an ActiveRecord model. That sounds fine at first glance — this is our model for users. But what if we also want to say that a user is a person? Ruby doesn’t allow inheriting from multiple classes. Now we have to choose whether to inherit from ActiveRecord::Base or Person. Person makes more sense, because it fills the “is-a” rule better. Class inheritance is intended for a hierarchical “is-a” relationship, such as “a user is a person”, or “a circle is a shape”. But since ActiveRecord::Base is a base class, we have to use it as our base class.
We could work around this problem by subclassing Person from ActiveRecord::Base and then subclassing User from Person. That’s fine if Person is also a model that we store in the database. But if that’s not the case, then we have a problem.
Mixins
+Ruby provides another way of implementing inheritance — mixins. We often don’t think of this as an inheritance model, but it really is. When we include a module, that module gets added to the class’s ancestor chain. We can mix in as many modules as we want.
+Mixins indicate more of an “acts like” relationship than an “is-a” relationship. It’s for shared behavior between classes that don’t have a hierarchical relationship. For example, when we mix in the Enumerable module, we’re saying that we want our class to act like other classes that include Enumerable. That sounds more like what we want ActiveRecord to be. We want our user model to behave like other ActiveRecord models, in the way that they can persist to a database.
But ActiveRecord doesn’t support that. Almost all the other Ruby ORMs do; as we’ve shown above, this is for good reasons.
+So I decided to see if I could implement the equivalent of the ActiveRecord::Base class as a module that could be mixed into model classes. I decided to call my mixin module ActiveRecord::Model, because classes that mix it in will behave as ActiveRecord models.
It turns out that ActiveRecord::Base is a pretty complex class. It includes and extends a lot of other modules. Luckily, as of ActiveRecord 4.0, that’s all the code it includes.
The module only defines a single class method, included. This is one of Ruby’s many hook methods. It gets called when the module in question gets included in another module, and receives that other model as its argument. All we need to have this method do is to include everything that ActiveRecord::Base includes, and extend everything that ActiveRecord::Base extends. Ruby provides a method that’s defined on all classes, called included_modules, which we can use to get the list of everything that’s included in ActiveRecord::Base. Unfortunately, there’s no equivalent list of extended_modules. But a quick search on Stack Overflow found an implementation of extended_modules that we could use.
So with a bit of magic (i.e. hooks and meta-programming), we can get the lists of constituent modules from the ActiveRecord::Base class, and include them in our ActiveRecord::Model module.
So with all that, we can now include the includable-activerecord gem and mix it in, with all the advantages that provides:
+class User + include ActiveRecord::Model + # ... +end+
It was exciting to be able to make this work. Since I wrote it as a proof of concept, I haven’t written any tests yet. But it seems to be working just fine. The main thing I really need to look into is making sure that plugins that extend ActiveRecord::Base from their own code will still work. I’m pretty sure this will work out of the box, because the ActiveRecord::Model.included doesn’t run until the model class is loaded, and that happens after those plugins have initialized themselves.
I facilitated our team retrospective this morning. I felt like we made a little forward progress, but not as much as I would have liked. But it really brought one thing to the forefront of my thoughts today — empathy gained through communication.
+We have a pretty large team by Agile standards — we had 20 people in our retro: 16 developers, 3 QA folks, and 1 manager. Out of those, only about 5 or 6 speak up regularly. I recently sent out a survey to the team, trying to get feedback on how we could improve our retros. A couple of the questions tried to get a feel for why people aren’t speaking up more. Only about half the people responded, and the answers didn’t really answer my question as well as I had hoped.
+So on Amos‘s suggestion, we did the Safety Check exercise. We got a good set of answers to why people don’t feel safe. About half of the answers were about the fear of looking stupid in front of other people. About half of those mentioned the manager — they’re worried they might get in trouble for what they say. We talked some about fear and how it’s more often than not misplaced. And that the worst consequences are usually not as bad as you might think. But then we got to the crux of the problem — there’s not enough trust amongst the team, and especially between the team members and the manager.
+About half of our team is new (within the past 6 months) — including the manager. While the developers have made some good progress building trust amongst each other, we haven’t had as much time with the manager to build trust between him and the rest of the team. So the lack of trust isn’t at all surprising.
+Honestly, I already knew we had trust issues, and wanted to address them, but needed a way to lead the team to that same realization. With this exercise driving out the issue, we were then able to have a conversation about trust. The conversation was pretty good. We got more voices to contribute than probably any other topic we’d previously covered. (I was disappointed that the manager kept quiet though. I later found that he was trying to mitigate people’s fears by keeping quiet, but I urged him to contribute more in the future.)
+But one point really stood out in my mind — a point of view that I hadn’t previously thought much about. Lauren, one of our QA analysts, pointed out that most human communication is non-verbal. We give tons of cues via body language, facial expressions, eye contact, tone of voice, even posture. I don’t recall if Lauren said it explicitly, but she pointed out that these cues build empathy between the speakers. She encouraged us to use more voice chat and video chat, as opposed to IRC text chat, because it would create more empathy between the people communicating, which would lead to more trust.
+I spent most of the rest of the day talking to people on the phone or via Google Hangouts voice. And every single time, I consciously noticed that I was gaining empathy for the person I was speaking with. I assume (and hope) that that’s working both ways. I suppose that it’s always been happening, but I never really noticed it.
+I’ve heard a lot of talk about empathy among Agile practitioners lately. It’s been mentioned on the Ruby Rogues podcast, and Angela Harms has been preaching it for years. I already understood how important it is. But until today, I didn’t really feel it happening.
+So if you’re looking to build trust with someone, spend some time talking with them. Preferably in person, but if that’s not possible, seriously consider video or voice modes of communication, instead of sending an email or an instant message.
++
I’m considering moving away from WordPress, for a couple reasons:
+Now that I’m starting to actually blog consistently, it makes sense to change. But before I move to something different, I want to be sure that I find all the features that I need. This post is my thought process about what I want.
+I’ve been playing with Jekyll lately, using it to generate a simple static site that can be updated easily. It’s pretty nice, and pretty easy to use. Something based on Jekyll would work well. The trickiest part will be figuring out how to manage comments. Or maybe I’ll just have to learn to live more minimally.
+Octopress is the obvious candidate. It fits most of my needs and wants. Most likely I’ll write my own commenting engine and add it to my Octopress template.
+The only other candidate that I’ve found is Ghost. It’s written in JavaScript and runs on Node. I don’t find Node to be that compelling, but the templates look great, and it’s designed for coding blogs.
+I’ll probably take a quick look at Droplets, too. It’s written in PHP, but seems to fit my other requirements.
+Unfortunately, that seems to be all there is in this space. Maybe I need to investigate more. Or maybe Octopress just has the static blog generation marked cornered. Either way, I’ll probably change my blogging software in the next month or two. Wish me luck!
++
It’s challenging to test Rails custom validators.
+I recently had to write a validator to require that an entered date is before or after a specified date.
+It didn’t seem like writing the validator would be too difficult – I’ve written custom validators before, and date comparisons aren’t all that tricky. But when it came time to write the tests, I ran into several issues. And since I always try to follow TDD / test-first, I was blocked before I even began.
+The biggest issue was the ActiveModel::EachValidator#validates_each API. It’s definitely not a well-designed API. You write your validator as a subclass, overriding validates_each. The method takes a model object, the name of the attribute of the model being tested, and the value of that attribute. You can also get the options passed to the custom validator via the options method. To perform a validation, you have to update the model’s errors hash.
The big flaw in the API is that instead of returning a result, you have to update the model. This needlessly couples the model and the validator. And it violates the Single Responsibility Principle — it has to determine validity of the field, and it has to update the errors hash of the model. This is not conducive to testing. Testing this method requires testing that the side-effect has taken place in the collaborator (model), which means it’s not really a unit test any more.
So to make it easier to unit test the validator, I broke the coupling by breaking it into 2 pieces, one for each responsibility. I moved the responsibility for determining validity to a separate method, which I called errors_for. It returns a hash of the errors found. This simplified the validates_each method to simply take the result of errors_for and update the errors hash of the model:
def validate_each(record, attribute_name, attribute_value) + record.errors[attribute_name].concat(errors_for(attribute_value, options)) +end+
This made it much easier to unit test the errors_for method. This method doesn’t even need to know about the model — only about the value of the attribute we’re trying to validate. We simply pass in the attribute’s value and the options.
So we could write the tests without even pulling in ActiveRecord or any models:
+describe DateValidator do
+ let(:validator) { DateValidator.new(attributes: :attribute_name) }
+ let(:errors) { validator.errors_for(attribute_value, validation_options) }
+
+ describe 'when attribute value is NOT a valid date' do
+ let(:attribute_value) { 'not a valid date' }
+ it { errors.must_include 'is not a valid date' }
+ end
+
+ describe 'when attribute value IS a valid date' do
+ let(:attribute_value) { Date.parse('2013-12-11') }
+ it { errors.must_be :empty? }
+ end
+end
+And the errors_for method looked something like this:
def errors_for(attribute_value, options) + unless attribute_value.is_a?(Date) + return [options.fetch(:message, "is not a valid date")] + end + [] +end+
Integration testing can also be a bit of a challenge. I recommend following the example from this Stack Overflow answer. Basically, create a minimal model object that contains the field and the validation. Then test that the model behaves like you expect with different values and validations.
+Today I was informed that I’ve been impeding progress on our team.
+This was somewhat shocking, since I feel like I’m always pushing
+forward to make our team and myself better.
Like most anyone, my initial reaction to criticism was defensiveness.
+I don’t handle criticism well. (You might find that hard to believe,
+after reading the rest of this post. Maybe it’s just the confrontation
+part I don’t handle well.) Thankfully the blow was softened somewhat,
+because the person providing the criticism didn’t tell me directly —
+they told Amos, a trusted colleague of mine. Amos then passed it on to
+me. I’m grateful for that — this is the best way for me to have received
+that criticism.
What I did next is the astonishing thing. I swallowed my pride for a
+minute. Not an easy thing for me to do, for all the usual reasons, and
+more. I decided to address the problem head on. If someone was telling
+someone else that I was causing some sort of a problem, then even that
+perception was a problem that I needed to address. So I decided to hold
+a retrospective for myself. Retrospectives are the way Agile teams address
+problems and improve how they work. If it would work for a team, I figured
+it should work for an individual.
I’d held retrospectives by myself before. Before I even knew about
+retrospectives, I’d taken some time to assess how I had done things
+on a couple of projects I had worked on as an independent contractor. But
+those were about technical decisions I had made and processes I had
+followed. This one would be different. This one was about a personal
+shortcoming, an action of mine that had caused some harm. This one
+involved feelings and emotions.
So I asked Amos to facilitate my one-person retro. We’d both done a lot
+of retrospectives, but neither one of us had done anything like this before.
+We had a bit of trouble getting started. We didn’t have any details
+about why the anonymous person felt the way he felt. So it was hard
+to address something that nebulous. So I asked Amos if he could follow
+up with the person. Luckily, the person was online and able to respond
+in real time.
So we talked things through some. We went on some tangents. We made some
+progress — things that I could write down as take-aways and action items.
+We got off-topic again, and then came back to it. Then Amos decided to
+play The Why Game. This worked amazingly well. It helped me to find the
+root reasons why I was holding back change. Basically I’m afraid of
+failure. Going deeper, we looked into why I’m afraid of failure. This
+line of inquiry was particularly effective. Hopefully it’ll be enough for
+me to stop being an impediment to change. Here are my notes / take-aways:
At first, I thought that I’d never heard of anyone doing anything like
+this. But then I recalled that I’d heard about somewhere that everyone
+does this, with their whole team. That would be hard. I’d have to
+trust everyone in the room.
But I would recommend this for anyone that can pull it off. It’s hard,
+but it has a large payoff. Just like a team retrospective, it feels good
+making this kind of breakthrough, and knowing that just spending that
+little amount of time has made me a better person. (Mine took about an hour.)
+I think the hardest part is finding someone (or a group of people) you
+trust to be your facilitator.
I’ve decided to call this thing an introspective. A retrospective is
+about looking back. This is about looking inward. I’d be interested to
+find out who is doing this kind of thing. Does it have a commonly accepted
+name? How does it work? What techniques work best? If you’ve got any answers or ideas, please comment below, or tweet me @CraigBuchek.
So thank you to that anonymous person. Your way of addressing this was
+probably more effective than you could have imagined that it might be.
+I hope that this exercise will help me make the changes required, to make
+me a better person, and help the team become the best that we can be.
Amos has written up his thoughts on the introspective.
+I’ve been using GNU/Linux since 1994, starting with a Slackware 2.2 CD-ROM I ordered from the back of a magazine. I’ve been heavily involved in my local GNU/Linux community since 1999, and I give frequent presentations at various groups. I’ve made some small contributions to several Open Source projects.
+But I don’t feel like I’ve done enough to contribute to the wider community. So this year, I’m going to resolve to step up my contributions, and do more.
+I was lucky enough this past year to find someone interested in helping to run the St. Louis GNU/Linux Users Group (STLLUG). I’ve been running the group so long that I’ve somewhat stagnated. It’s great to find someone who will bring a fresh energy and new ideas. Thanks, Andrew!
+Mostly freed from the more general administrative tasks (mostly planning meeting topics and speakers), I’m hoping to find the time to work on a few projects. First, I want to overhaul the web site. It needs a new look, as well as an easier way to update it. I’m planning to implement some sort of CMS — possibly WordPress or Octopress, or at the very least, a git repo to manage updates.
+I installed WordPress a long time ago, but I haven’t published many posts. I’ve got a few drafts in various stages. So this year I’m going to actually get the blog going, and hopefully post about once a week. I’ll be sharing things I learn on the Internet, as well as some of the things I learn from my experiences with various technologies and techniques.
+There are a few items I’ve been meaning to work on and contribute. I’d like to finally get around to them:
+I’ve been working on a few Ruby gems. I’d like to get them to a state where they’re useful to more people. These include:
+I enjoyed building a quick Rails app during last year’s Rails Rumble, even if it doesn’t turn out to be useful or make any money. I’d like to create a few small apps again this year, either in Rails or Apache Cordova. I’ve got some ideas — we’ll see how if they turn into anything useful or worth selling.
+Last year, I started joining the This Agile Life podcast. I enjoy it. I’m hoping to continue with that, and possibly doing some podcasting about Ruby and Rails.
+I’m going to attempt to give a presentation at a conference. I often give presentations at local groups, but haven’t addressed a larger audience. I’ve got a few ideas rattling around, and will see if I can turn them into presentations worthy of a larger conference.
+What’s your Open Source resolution?
+I’ve been using Python at work for the past few months. I learned Python back in the early 2000s, but never used it for any large projects. I learned Ruby in late 2005, and it quickly became my language of choice for most cases.
+So while I still prefer Ruby, and will likely use Ruby more in the future than Python, I wanted to assess the strengths and weaknesses of Python in relation to Ruby. Perhaps some of the lessons could be applied when writing Ruby, and it could help to decide when to use each. Also, I’m interested in programming language design, and wanted to document pros and cons in that light.
+Where Python Sucks (As Compared to Ruby)
++
I’ve been more interested in programming patterns lately, partly due to the Ruby community’s recent interest — especially the Ruby Rogue podcast’s love affair with “Smalltalk Best Practice Patterns”.
+I consider most of the patterns in “Smalltalk Best Practice Patterns” to be patterns “in the small” — things that are typically employed on a single line or method. The Gang Of Four patterns are more medium sized, dealing with methods and classes. The PEAA book covers architectural-scale patterns. I suppose “The Pragmatic Programmer” and similar books could (should!) be considered to be very general patterns, mostly about the practice of programming.
+One type of pattern that I have not seen discussed much is debugging patterns. I’m not exactly sure why that is; probably just our general concentration on designing the program code itself. There are definitely testing patterns. But I can’t think of anything that I’ve seen that covers debugging patterns. A quick search on the Internet doesn’t turn up too much.
+Anyway, a co-worker (Helena) and I were debugging recently, and were having trouble figuring out where a certain method on a certain object was being called. We came up with a really cool solution. We immediately called it a grenade, because its entire purpose is to blow up (raise an exception) and display a backtrace to show us the caller of the method that we’re looking for.
+Here’s our implementation in Ruby:
+
+module Grenade
+ def method_under_investigation(*)
+ raise "method_under_investigation called"
+ end
+end
+
+class Xyz
+ ...
+ def xyz
+ object_under_investigation.extend(Grenade)
+ end
+ ...
+endI’m sure we could wrap that in some more semantic sugar, even going as far as making it look something like this:
+
+class Xyz
+ ...
+ def xyz
+ object_under_investigation.blow_up_when_method_called(:method_under_investigation)
+ end
+ ...
+end
+I’m not sure that would really be worth it though, unless we were to add it to some sort of library.
+So that’s our contribution to the (small) list of debugging patterns.
+Amos and I got in a heated discussion recently on whether we should write a single line comment to better explain some code. (The code in question was Amos’s very elegant solution to testing whether a job got sent to Resque.)
+Amos doesn’t believe in writing comments much at all. He thinks that if you’re writing a comment, it means that you’re doing something wrong, and that you probably need to write the code more clearly.
+I agree with that, to a point. First off, it’s not necessary to write perfect code. If you can change a class or method name to better describe what you’re doing (and more importantly, why you’re doing it) then you should definitely do so. But it’s not always worth refactoring until you get every “why” answered. More importantly, I don’t think it’s even possible to capture everything in the code that is worth capturing. For example, why did you choose this implementation, as opposed to another that might be more obvious or common?
+After our argument, I came up with a good rule of thumb (or “pattern”):
++Write comments for your (future) self.1
In other words, if your comment will help you to understand the code more quickly when you look at it in the future, then it’s a valid comment. It also means that you can assume that the reader has about as much general programming knowledge as you currently do. (Your future self will have more general knowledge, but possibly less specific knowledge of the lines of code in question. And because of this, your current solution might not make as much sense in the future. You might know of a better solution in the future, but you’ll have to know all the constraints that you had when you originally wrote the code.)
+This is not to say that you should not write comments in clear English, that others can understand. The comment is written for a future maintainer. That may be you (which is why the rule works well), or it may be someone else. The rule is more about when to write a comment, and what level of competence you should assume of the reader.
+1 Perhaps it should be “Write comments TO your (future) self”.
+Here’s a relatively simple way to rename a bunch of files from the command line. It uses sed within a command substitution to compute the new names from the old names.
In this example, we’re renaming files that start with “ABC” to start with “XYZ” instead:
+ for i in ABC*; do mv $i $(echo $i | sed -e s/^ABC/XYZ/); done
+You’ll have to use shell globbing (wildcards) in the first part, to determine which files will be the source of the renaming, and regular expressions in the second part to translate the old names into the new names.
+It’s a good idea to use echo in place of mv before running this, to see what the results will be, so you don’t make a mistake.
Depending on the situation, you may need to adapt this for your particular needs. For example, if you have too many files to rename, you would need to use xargs. Or sed might not be up for the task of transforming the names that you want. Or you might need to use find to find files within a hierarchy. As with any UNIX idiom, there are hundreds of variations on the theme.
Web Development, Ruby on Rails, Open Source
+Welcome to the BoochTek blog. BoochTek, LLC is a small web development company, based in St. Louis, Missouri. We specialize in Ruby on Rails, jQuery (JavaScript), and PHP.
+This bog will be a place where we can share some of our experiences in web development, Open Source, programming, and technology in general.
+Web Development, Ruby on Rails, Open Source
+Not too long ago, I was asked during a job interview “how do you convince your teammates that you’re right?” I answered with probably the most surprising answer: “I don’t.”
+It’s taken me years to realize that being right isn’t terribly important. Especially when there’s more than one right answer — which there usually is. It’s more important to work as a team. It’s more important to be respected and to have respect for others.
+A few weeks after that interview, I was pair programming with the person who had asked me the question. We’re both senior developers, so we both have a lot of experience and opinions based on that experience. We were writing a shell script, and we both had an idea in mind about how to write the code. I let him proceed with his idea. It was a pretty good idea; probably better than mine. But we paired very effectively. I’d let him finish some code, and I’d find a way to make it better. Then he’d find a way to make my code better. What we ended up with was so much better than my original idea, and his original idea as well. I commented on this, and he agreed. We left that pairing session feeling the high of having accomplished something rare — two very experience programmers coming up with better code than we could have imagined going in.
+I like to think of writing code as a path towards a destination. The destination is good code that does what it’s supposed to, is readable (intention revealing), is concise, and is well-factored so as to be easy to change in the future. But there are many paths to that destination. Especially when pair programming, the code gets refined as ideas are shared, getting you closer and closer to that destination. Sometimes the different paths end up with the same code; sometimes they end up with different code. But if the code does its job well (according to those criteria), it doesn’t really matter what code you ended up with.
+Thinking back to the original question, I think the answer is a little more nuanced. (I’m pretty sure I followed up with an explanation, but I don’t recall the details.) It truly doesn’t matter in a lot of cases. If there are different paths that lead to the same destination, and they’re all roughly equal, then my rule works. It can also work even if the first path you try (a “wrong” path) doesn’t work out, as long as it’s easy enough to try a different path. I find that the majority of day-to-day coding fits these conditions.
+But there are some places where it’s costly to get things wrong the first time. In these cases, it’s worth spending some time thinking about and discussing the alternatives before getting started. Software architecture is the big one that comes to mind. In general, weighing the pros and cons of each option and applying previous experience works best.
+So next time you think about trying to convince someone you’re right, fight the urge. Instead, let them show you what they’re thinking. They just might surprise you. And more importantly, you might surprise yourself.
+I recently attended an Open Space hosted at work. I’d never been to an Open Space, and didn’t know what to expect. We’d been told that this was a workshop to help Engineering Managers (my role), Product Owners, and Product Analysts find better ways of working together. But due to the way an Open Space works, it evolved into something completely different — and better.
+We’d brought in Diana Larsen to facilitate the Open Space. Diana is a stalwart of the Agile community, focusing on how people and teams interact. She literally (co-)wrote the book on Agile retrospectives. Diana was also kind enough to be our guest at an Agile LINC meetup later in the evening.
+The morning started off with all the participants sitting in chairs arranged in a circle. Diana rang a chime, a nice soothing tone that literally set the tone for the day. (Most people didn’t seem to like it, but I thought it had its purpose.) It also acted as a call to gather in the meeting space. She then walked around the inside of the circle as she explained what was going to happen.
+The idea behind Open Spaces came with the realization that at a conference, the “hallway track” (ad hoc discussions in the hallways) was often more valuable than the scheduled talks. So they figured out a way to capture that experience. There are only a few rules:
+Once Diana set the scene and explained the rules, people came up and presented ideas for topics. If you proposed a topic, you chose a time and location on the topic board. At that time, you’d facilitate a discussion on that topic. The format was really conducive to discussions. There was no preparation, so discussions were from the heart — lots of people felt that they could contribute.
+Being new to the company (only 2 months), I got a lot out of the workshop, beyond the content itself. I got to get to know several more people. I’d even say I made a few friends. Having open discussions, we found that many of the teams were having the same issues. This made it easy for me to talk to other people.
+All-in-all, I found the Open Space to be extremely conducive to discussions aimed at identifying issues, brainstorming solutions, and planning action items. I felt like we made great strides in addressing some of the biggest problems our organization is currently facing.
+I held a retrospective with my new team last week. The team includes 2 senior developers, 2 junior developers, a product owner, and a product analyst. I’ve joined the team as an engineering manager, which I think of more as a team lead with an elevated title. Being new to this group, I wanted a way to understand their values. What motivates them? What common values do we share that we can leverage to move forward in the same direction?
+I started out with a pretty simple question: “What do you value (in regards to what we’re building); what are you willing to fight for?” I asked them each to write down several values and then put them on the board before looking at everyone else’s answers. I also asked each person to rank their values in order of importance.
+It turned out that my question was a little vague. Some people thought about the question in terms of the end result, and some in terms of the process of creating the software. In some ways that was a bit of a problem, because the different interpretations led people in different directions. But in other ways, not pushing them in any particular direction got more varied answers, exposing how they think about the project and the product.
+My list (in order) was Effectiveness (doing the right thing), Quality (doing things right the first time), Happiness, Purpose, and Teamwork. In retrospect, I should have put Happiness first. If I’m not happy at work, I don’t really want to be there, and need to move on. (Sometimes I can trade some happiness at work for more happiness at home, but I’m definitely a person that needs to be happy at work.) The other values serve to improve my happiness, but the happiness is more important.
+My own issue ranking my values turned out to be a problem with the ranking in general. Should they be ranked in importance of the necessity of the value as an outcome, or in importance of the necessity to focus on the value? I think the former is what I was looking for, but even I wasn’t clear on that when I began the exercise.
+After everyone put their values up on the board, we read them off. Then I asked the team to choose several values that we share as a team. We pulled them off the individual members’ lists, and put them in the team list. Then I asked each person to come up and rank those values, then explain why they had ordered them that way, especially when they ordered them significantly different than the last person. I was hoping to come to some convergence of the rank over time, so we could document our values in rank order. That didn’t happen. But the discussion was illuminating to me and to everyone on the team.
+I think the most interesting part about the lack of convergence was the difference between the developers and the product guys. The product guys definitely viewed the values more in terms of outcomes than the process. That makes sense — they’re not as intimately involved in the process of building the product.
+We were able to converge on the top priority though: Will the user buy the product? This was a combination of a couple different values that we merged together. This included the end user experience as well as making sure the team would continue to have a reason for existing. The rest of the values we left unordered: Teamwork (cohesiveness), Data driven decisions, Team ownership, Simplicity, Effectiveness, Maintainability / Supportability, Quality, Automation, and Performance. I think that’s a pretty decent list.
+As a couple teammates pointed out, those values are probably in part a reflection of this current point in time. If I asked the same question some other time, under different conditions and team dynamics, the answers would probably change a bit. And we’d probably come up with other answers if asked again, just due to randomness of the way we think about these things.
+But I don’t think I’d do this activity a second time with the team. It was really about understanding our motivations — both our own, and those of our teammates. I found it effective in that way, and also in helping the team to think about our culture and how we can work to shape it to help us all push in the same direction.
+There are a few caveats. When I asked for feedback on the exercise, one teammate pointed out that it wouldn’t work if people weren’t honest about their values, and they answered with what they thought management or their teammates wanted to hear. I don’t think that was an issue with this group, but it’s something to keep in mind.
+The other major thing I’d do is to make it clear up front that I’m not looking for any action items from this activity; it’s more about understanding each other and ourselves. And next time, I’ll work to clarify how to rank the values.
+I would recommend this activity for a new team, or when the makeup of the team is changing in some significant way. I wish there was a way to help a team converge on the ranking of their values, but I suppose I should be happy that agreeing on the set of important values went pretty quickly. And the diversity of ideas and opinions is probably a blessing that I should be embracing — the more ideas we have, the wider the variety of solutions we can imagine.
+It’s that time of year again — time for a retrospective on how I did on my goals for the year. I had 5 main goals for 2015:
+I got pretty lucky on this one. My main contract with Mercy got extended several times. Amos and I must have been doing a good job of keeping the customer happy. We even made it through a couple rounds of layoffs. I’m wrapping up the gig at Mercy now. I’m working one day a week there, as the project winds down.
+I also started a new gig this month at CenturyLink. I’m working on a cloud development team. Our current project involves selling WordPress as a service. The manager had been courting me for most of the year. I’m excited about my new role; I’ll be writing about it in a blog post soon.
+I set a goal in 2014 to give my first conference talk. I accomplished that, giving an ambitious talk at RubyConf. I enjoyed having done that, and vowed to do more conference speaking.
+I gave 3 conference talks in 2015. I gave a workshop on HTTP at RailsConf. I talked about immutable infrastructure at Madison+ Ruby. At RubyConf, I gave a talk on a micro-ORM I wrote. I also gave a lightning talk about Agile estimation (#noestimates).
+I was an alternate speaker at Windy City Rails, but did not give my talk on Alternatives to ActiveRecord. I also went to Strange Loop, mainly to see several friends and acquaintances speak.
+I wrote 24 blog articles this year. That’s about one every other week. What really kept me going was participating in a writing pact. When the pact was going, I had a 75% blogging rate. That’s pretty good.
+I’m not so sure about the quality of my blog writing though. I know that practicing writing is supposed to make you better. I know I wrote some really good articles over the past year, but I think I also wrote some articles that weren’t very good. I think sometimes the deadline has caused more harm than good. I’m not really sure what to do about that; perhaps just pushing on is the right answer.
+I’ve taken a lot of notes on the design of my programming language. Any time I learn something interesting about another language, or come up with another idea, I write it down.
+But I haven’t worked on the implementation. (I last worked on the implementation in 2014.) I should be experimenting with some ideas, implementing them to see how they work out. I’ve even kicked around the idea of starting with a Forth variant, just to get something working quickly.
+I haven’t written any articles on my ideas this year either. My notes are pretty extensive, and it would be good to write some articles to help get my thoughts straight.
+I’ve got some things to say about Agile, and want to write a book to express those ideas. I’ve made a start — I’ve got the chapters outlines, and have started on a few chapters. But I haven’t made as much progress as I’d like to. I shared what I’ve got with Amos, and he showed some interest in pairing with me on the writing. Hopefully we’ll work on it together in 2016 and publish it.
+There were a few other accomplishments that weren’t explicitly on my list, but I’d like to call attention to.
+I’ve continued participating on the This Agile Life podcast. I was in 12 of the 33 episodes that were recorded in 2015. I hope to participate in more in 2016. We’re considering scheduling a standard recording night each week, which might help us record more regularly.
+I recently took over as maintainer of Virtus, a library to declare attributes for Ruby model classes. I haven’t done a lot yet, since I’ve been busy with travel, vacation, and holidays. But I hope to catch up with all the pending pull requests and issues in the next month or so.
+The accomplishment I’m most proud of is mentoring for the Roy Clay Sr. Tech Impact program. This is a program begun as a result of the Ferguson protest movement. We’re helping teach kids (from 14 to 25) web design and development. My personal goal was to give these kids an opportunity that they would not have otherwise had. But it turned out that some of them have actually started a business building web sites for small companies. I’m so proud of the progress they’ve made in such a short time; it’s a challenging program.
+I’m pretty happy with my accomplishments this year. I made at least some progress on each of the goals I set. I’ve been thinking about my goals for next year; I’ll write that as a separate blog article next week.
+I’ve always been someone who faces my fears.
+I have a moderate case of arachnophobia. I don’t run away when I see a spider, but it creeps my out when one is crawling on me. When I was in college, I decided to buy a tarantula to attempt to get over my irrational fear of spiders. I thought I’d be able to get more comfortable with the tarantula over time, eventually to the point of letting it crawl on my arm. It didn’t work. Although I did find that my fear of tarantulas is rational — I got a terrible case of hives just from touching the urticating hairs that fell off into its water sponge.
+Last week, I was on vacation in Mexico. One of the excursions we took involved jumping in the water a lot. I’m not a strong swimmer — mostly because I have a hard time closing my nose; I hold my nose when I jump in. We zip-lined into the water a lot. At one point, there was a cliff to dive into the water from. It was about 15 feet above the water. It didn’t look so far down before jumping. But it felt like a really long way down the first time I jumped from it. It was pretty scary for me. So I did it a second time. There wasn’t any peer pressure to jump a second time. I literally jumped a second time specifically because I was scared.
+Fear is a weird thing. Fear is there to protect us. But it’s there to protect us from the dangers of the African savannah. Most of the things our fears protect us from don’t exist in our everyday modern lives. So maybe we should work to gain a better understanding of how our fears work, to figure out when to pay attention to them and when to ignore them.
+Fortunately, our brain has a good mechanism to help us do this. Our brains basically have 2 main processing systems. The first one is for quick reactions. This one involves things that are nearly reflexes. Fear is in this system. The second system is our analytical reasoning system. This system takes longer to process, but is able to take on more information.
+Whenever the situation allows us time for both systems to work, we need to listen to them both. We need to listen to our fears, because they’re there for a reason. But that reason might not pertain to our situation. So we need to realize that, and let the slow analytical system determine if we should ignore our fears.
+If we don’t allow both systems to work, we’re not taking full advantage of our brains; we’re not taking full advantage of the situations that life is presenting to us.
+I’ve been on vacation the past week, in Cozumel, Mexico. One day, we went on an excursion called Xenotes. A cenote (say-NO-tay) is a sinkhole filled with fresh water. (The “X” is to give it a more Mayan-sounding trademarkable name.) We had a lot of fun swimming, kayaking, and zip-lining. A bilingual tour guide led our group, which consisted of people from across the US and South America, of various ages and physical abilities.
+Our tour guide was a lot of fun. He made jokes, told us about the cenotes, and led us in the activities. But he also encouraged us. When someone was scared to do something, he was supportive. He told us that it was okay, and we could do it. But we also felt like it was OK to fail, if we really couldn’t. It really felt like his encouragement was literally creating courage.
+What was really neat was that despite the language barrier, everyone else was also supportive and encouraging. Everyone cheered with encouragement before someone would attempt something difficult. And we’d cheer especially loud once someone accomplished something that was difficult for their abilities.
+It was an awesome feeling to feel so supported. It made me feel like I was in a safe place, where I could try new things that were a little past my comfort zone. I was able to do the zip-line upside-down. I jumped off a 15-foot cliff into the water. I even jumped off the cliff a second time, even though I was a little scared.
+Back at the resort, we played some volleyball in the pool. It was a similar situation, with players of varying ages and abilities. Again, we tried to help the weaker players feel comfortable so they could improve without feeling judged or self-conscious. It helped everyone have a good time. It made everything more fun to be in such a supportive environment, whether I was in a position as one of the more skilled (volleyball), or one of the less skilled (jumping or zip-lining into the water). We were all able to accomplish more, with less effort.
+These experiences provide a good lesson that can be applied in a lot of places. Such a supportive environment would help any relationship, and any team. I’ve been on a couple really good software development teams, but I don’t think any of them have been as supportive as these two groups of strangers.
+I’ve decided that this should be one of my goals as a team leader. I want to create an encouraging environment for the whole team. I want to make sure that everyone is comfortable enough that they feel like they can try things that are difficult, even if they might fail (as long as nobody gets hurt).
+If a group of strangers can do this, so can your team. So can you and your significant others. We need to work every day to make sure that we’re supporting each other. It’s the best way to get everyone to achieve more.
+I’m wrapping up my current consulting gig at Mercy in December, and starting a new gig at CenturyLink. I’m a software developer, but that’s only a part of what I do. What I really do is join a team and help them improve the way they work — both their processes and their technical skills.
+I think this is a key differentiator for me as a consultant. Most consultants (and Agile coaches) come in and tell people what to do. I don’t like to just tell people what to do. I’d much prefer to work side-by-side with them, getting a better understanding of what their challenges are. Once I have a better understanding of the challenges, I’m able to better brainstorm some ideas to try. Then we can experiment to see what will work and what won’t.
+Instead of telling people what to do, I show them how. Most people learn better from seeing than from hearing. They also learn better if you explain how and why, not just what. So showing them how to do something is more effective than telling them. By showing and doing, you can also set a good example. This is especially important when collaboration is a large part of what needs to be improved.
+I’ve found that this style of consulting is more highly respected by everyone. I build trust with developers by working closely with them. Managers like to keep me around once they see how effective these methods can be, so the gigs I take on tend to last relatively long.
+The biggest problem I have is explaining how this works. I don’t really know what to put on my résumé. Sometimes I call myself an Agile practitioner, and sometimes an Agile player/coach. But those aren’t terribly satisfying descriptions. I’m considering actually putting “I help teams improve the way they work — both their processes and their technical skills” on the résumé. But that seems awkward, and misses the show versus tell part. I’d be open to any suggestions.
++
I facilitated a retrospective today; it was one of the best retros I’ve ever been involved with. I figured out what activities I wanted to do earlier in the morning. They were really quite simple. I wanted to focus on happiness.
+I started with two questions that I’ve used with teams before, to some success (although not so successful for one particular team). The first question I asked was “How happy are you at work?” I had them put a rating from 0 to 10, with 0 meaning they should have quit last week, and 10 meaning they couldn’t imaging being happier at work.
+The answers were mostly 7s and 8s, with a 5 and a 9. The average came to 7.5, which is pretty good. The 5 concerns me a bit, especially that it’s 2 points lower than anyone else’s answer.
+The next question I asked was “How effective do you think the teams is?”. Again, from 0 to 10, with 0 meaning they can’t accomplish anything, and 10 meaning you couldn’t imagine a more effective team.
+When I ask both of these questions, the scores are always highly correlated. If your team isn’t doing good work, it’ll make you unhappy. And if you are unhappy, you’re less likely to do your best work. This team was no different; the 5 and 9 became a 6 and a 10, and most of the 7s became 8s, for an average of just under 8.
+The next question I asked was “What makes you happy at work?”. The answers were mostly about the teamwork and teammates. This went quicker than I expected. At this point, I was worried the retro would only last a little more than 30 minutes.
+The final question I asked was “What would make you happier at work?”. This was the real pay-off. We spent about half an hour just talking about the things that would make us happier, and what we could do to improve our happiness. We came up with 10 potential action items. I usually limit teams to trying 3 or 4 action items, but most of the items are quite small, so we’re going to try 6 of them. One is just observing another team’s standup meetings, to see how they’re using their time effectively.
+Everyone went away feeling that this was a really good retro. It felt good to focus on happiness. Happiness is something I’ve been talking a lot about on the This Agile Life podcast, and it felt good to take some action on it. I’ve done “positive-only” retros before, but this one felt even better than that, by specifically targeting happiness and how we can achieve it.
+I’m surprised that I haven’t gotten this story down in print before. It’s something I’ve mentioned many times — including a few times on the podcast. It’s a great story about the power of retrospectives, and it’s a great story about the power of a blameless post-mortem.
+I don’t recall all the specifics at this point. It was about 5 years ago. I’d just noticed that Arun had made some sort of mistake. That’s fine, people make mistakes. The thing that was different about his mistake was that I had made the same mistake about a week prior. And Amos had made the same mistake about a week before that.
+Noticing a pattern of mistakes, Amos and I called an impromptu retrospective. We gathered all the developers into a conference room. We explained the problem that we were running into. At first, Arun was defensive. That’s understandable; he thought we were there to come down on him, to lay blame. But we made it clear that we weren’t focusing on him. We admitted that we had also made the same mistake recently. We weren’t there to lay blame; we were there to figure out how our team could stop making the mistake. It took Arun a few minutes to get over the defensiveness.
+With the defensiveness out of the way, we could focus on the issue at hand. We were able to figure out the root cause of us all making the mistake. (I don’t know if we played the “5 whys” game, but I’m sure we effectively did something similar.) And with that, we were able to change our process, so that nobody else would make the same mistake again.
+There are 2 important points to this story. First, you don’t have to wait until a scheduled retrospective to hold a retrospective. This one was impromptu, and it’s the best one we ever had. We saw a problem, addressed it, and found a solution in less than an hour. Had we waited until the end of the week, we would have forgotten some of the details, and wouldn’t have been as effective at solving the problem. Second, when addressing problems, take your ego out of the equation. If you’re in a position of authority, take the blame — but never place blame. Focus on what’s important — solving the problem.
+And don’t forget the Retrospective Prime Directive:
++Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
+
I’m a big proponent of Agile (mostly XP; I’m mostly anti-Scrum) and I’ve contributed some to the #noestimates “movement”.
+I don’t really mean that nobody should ever estimate anything. I mean that I’ve never seen useful (fine-grained) estimates anywhere. Here are some of the problems with estimates that I’ve seen frequently:
+I’ll note that most of these pit management against the team, instead of working together toward a common cause. Most of the practices also lead to seriously demoralizing the team. And most of the time, the estimates aren’t really even taken into account very much.
+My advice is to first understand the value of a project before you consider estimating the costs. The estimation at this point will be very rough, so make sure that you have a very wide margin between the expected value and the rough estimate of the cost. If you’re pretty certain of the expected value, I’d probably want to make sure I could still be profitable even if it took 3 or 4 times as long to complete as the rough estimate. And if there’s uncertainty in the expected value, much more.
+Another way to mitigate the risk of throwing money at something that’s not going to have positive ROI is to reduce the feedback loop. Order the work so that the tasks are ranked in order of value to the customer. (Realistically, you’ll have dependencies of tasks to worry about, and should consider effort involved too.) So work on the most valuable feature first — get that out into production as soon as possible. Once that’s done, you can assess if your ROI is positive or not. Keep iterating in this fashion, working on the features that will provide the most value first. Keep assessing your ROI, and stop when the ROI is no longer worth it, compared to other projects the team could be working on.
+At a fine-grained level, if you’re using story points, I’d ask you to do the math to see if just counting the stories would be as effective at predicting how much will be done over time as using the story points. If so, you can save the time the team spends on estimating stories. I’d still recommend spending time talking about stories so that everyone has a shared understanding of what needs to be done, and to break stories up into a smaller, more manageable size — with one acceptance criteria per story. Also take a look to see if empirical average cycle time (how long it takes a single story to move from start to finish) might provide you the predictive power just as well as estimates. (I.e. is it bandwidth or latency that really provides the predictive power you’re looking for?)
+And don’t forget Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.
+Web Development, Ruby on Rails, Open Source
+Not too long ago, I was asked during a job interview “how do you convince your teammates that you’re right?” I answered with probably the most surprising answer: “I don’t.”
+It’s taken me years to realize that being right isn’t terribly important. Especially when there’s more than one right answer — which there usually is. It’s more important to work as a team. It’s more important to be respected and to have respect for others.
+A few weeks after that interview, I was pair programming with the person who had asked me the question. We’re both senior developers, so we both have a lot of experience and opinions based on that experience. We were writing a shell script, and we both had an idea in mind about how to write the code. I let him proceed with his idea. It was a pretty good idea; probably better than mine. But we paired very effectively. I’d let him finish some code, and I’d find a way to make it better. Then he’d find a way to make my code better. What we ended up with was so much better than my original idea, and his original idea as well. I commented on this, and he agreed. We left that pairing session feeling the high of having accomplished something rare — two very experience programmers coming up with better code than we could have imagined going in.
+I like to think of writing code as a path towards a destination. The destination is good code that does what it’s supposed to, is readable (intention revealing), is concise, and is well-factored so as to be easy to change in the future. But there are many paths to that destination. Especially when pair programming, the code gets refined as ideas are shared, getting you closer and closer to that destination. Sometimes the different paths end up with the same code; sometimes they end up with different code. But if the code does its job well (according to those criteria), it doesn’t really matter what code you ended up with.
+Thinking back to the original question, I think the answer is a little more nuanced. (I’m pretty sure I followed up with an explanation, but I don’t recall the details.) It truly doesn’t matter in a lot of cases. If there are different paths that lead to the same destination, and they’re all roughly equal, then my rule works. It can also work even if the first path you try (a “wrong” path) doesn’t work out, as long as it’s easy enough to try a different path. I find that the majority of day-to-day coding fits these conditions.
+But there are some places where it’s costly to get things wrong the first time. In these cases, it’s worth spending some time thinking about and discussing the alternatives before getting started. Software architecture is the big one that comes to mind. In general, weighing the pros and cons of each option and applying previous experience works best.
+So next time you think about trying to convince someone you’re right, fight the urge. Instead, let them show you what they’re thinking. They just might surprise you. And more importantly, you might surprise yourself.
+Web Development, Ruby on Rails, Open Source
+I’m a big proponent of Agile (mostly XP; I’m mostly anti-Scrum) and I’ve contributed some to the #noestimates “movement”.
+I don’t really mean that nobody should ever estimate anything. I mean that I’ve never seen useful (fine-grained) estimates anywhere. Here are some of the problems with estimates that I’ve seen frequently:
+I’ll note that most of these pit management against the team, instead of working together toward a common cause. Most of the practices also lead to seriously demoralizing the team. And most of the time, the estimates aren’t really even taken into account very much.
+My advice is to first understand the value of a project before you consider estimating the costs. The estimation at this point will be very rough, so make sure that you have a very wide margin between the expected value and the rough estimate of the cost. If you’re pretty certain of the expected value, I’d probably want to make sure I could still be profitable even if it took 3 or 4 times as long to complete as the rough estimate. And if there’s uncertainty in the expected value, much more.
+Another way to mitigate the risk of throwing money at something that’s not going to have positive ROI is to reduce the feedback loop. Order the work so that the tasks are ranked in order of value to the customer. (Realistically, you’ll have dependencies of tasks to worry about, and should consider effort involved too.) So work on the most valuable feature first — get that out into production as soon as possible. Once that’s done, you can assess if your ROI is positive or not. Keep iterating in this fashion, working on the features that will provide the most value first. Keep assessing your ROI, and stop when the ROI is no longer worth it, compared to other projects the team could be working on.
+At a fine-grained level, if you’re using story points, I’d ask you to do the math to see if just counting the stories would be as effective at predicting how much will be done over time as using the story points. If so, you can save the time the team spends on estimating stories. I’d still recommend spending time talking about stories so that everyone has a shared understanding of what needs to be done, and to break stories up into a smaller, more manageable size — with one acceptance criteria per story. Also take a look to see if empirical average cycle time (how long it takes a single story to move from start to finish) might provide you the predictive power just as well as estimates. (I.e. is it bandwidth or latency that really provides the predictive power you’re looking for?)
+And don’t forget Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.
+I don’t believe that estimation should be part of any Agile practice.
+One of our managers recently mentioned that we hadn’t met the “contract” that we had “committed” to in our last iteration. This was complete nonsense, because A) we hadn’t made any such commitments, and B) we completed many more story points than the previous iterations (and without inflating story points).
+
But her language made me come to several realizations. First and foremost, estimates are contracts. Sure, they’re not supposed to be treated as commitments, but they almost always are. And what does the Agile Manifesto say about this? It says that we should value customer collaboration over contract negotiation, and responding to change over following a plan. So it’s pretty clear that treating estimates as commitments is completely counter to the Agile values.
+Why does this matter? What benefits do the Agile values bring us? I think the biggest benefit they bring is changing the way that we work, so that we can better deliver value to our customers. Without Agile, we’d just keep working the way we’ve always done things. And that didn’t seem to be working out so well. If we follow the Agile values and principles, at least we’ll have a fighting chance of improving our ability to deliver value.
+Ask yourself — have you ever seen a software development project that was on time and on budget? Where the estimates were spot-on? Of course not. For one, we’re terrible at estimating. For another, our plans change — either from external factors, or from what we learn as we go.
+To me, Agile is also about facing reality — and embracing it. It realizes that we’re terrible at estimating. It realizes that plans change. Most Agile methodologies have some tricks to counteract Hofstadter’s law. Generally, we use relative story points instead of hours, and then use an empirical factor to convert points to hours.
+When this works, it is better than any other estimation I’ve ever seen. But it doesn’t work very often. People have trouble with relative estimation. How do you set the basis for what a point means without relating it to actual hours? Affinity estimation could work, but then you have to remember what the basis was. We’ve got a large distributed team, and when we tried this, we couldn’t all remember what the basis was.
+Since we couldn’t get affinity estimation to work, we tried changing to perfect hours (only powers of 2). But then people thought of them as time. When we took longer than the estimate on an individual story, managers and team members thought we were taking longer than we should have. So our estimates ended up causing problems.
+Managers want estimates so that they can have predictability. They want to know when new features will be available. Is there a better way to get what we need?
+I believe there’s a better way — prioritization. If you work on the most important thing first, then the most important thing will get done first. We should always be working on the next most important thing.
+What if there’s more than 1 thing that’s most important? Then you’ve failed. You’ve failed at logic if you can’t understand that only 1 thing can be most important. You’ve failed at prioritizing the customers’ needs. You’ve failed at project management.
+1. Why can’t you just tell us how long it will really take?
+Because we don’t know. Because we can’t know. This is the first time we’ve ever implemented the functionality you’ve asked for. If we’d done it before, we’d just use that existing code. As Glenn Vanderburg pointed out in his excellent talk on Software Engineering, we’re not building software, we’re architecting it.
+2. But we have to tell our customers what to expect.
+Why? Is the product so bad that you can’t keep customers around without leading them on with future enhancements? And why do customers need exact dates? A general roadmap telling them what the priorities for upcoming features should be sufficient.
+3. But we have to have messaging about new features.
+OK. Then send out that messaging once the feature has made it to Staging. Or even after it’s been rolled out to Production.
+4. But we’ve promised these new features to the customers by this date.
+Ah, so you’ve made promises to the customer that you don’t have control over. Have you ever heard of “under-promise and over-deliver”? That’s how you create happy customers. Yet you’ve done just the opposite, haven’t you? And then you want to blame someone else.
+Risk
+Estimates are risk. But the risk doesn’t come at the end, when the estimates are shown to be incorrect. The risk was in asking for the estimates in the first place, and placing trust in them. Don’t do it. Don’t promise things that you can’t be sure of.
+Embrace this reality. Embrace this uncertainty. Always focus on what’s most important. That’s how you make customers happy.
+I’m a big proponent of Agile (mostly XP; I’m mostly anti-Scrum) and I’ve contributed some to the #noestimates “movement”.
+I don’t really mean that nobody should ever estimate anything. I mean that I’ve never seen useful (fine-grained) estimates anywhere. Here are some of the problems with estimates that I’ve seen frequently:
+I’ll note that most of these pit management against the team, instead of working together toward a common cause. Most of the practices also lead to seriously demoralizing the team. And most of the time, the estimates aren’t really even taken into account very much.
+My advice is to first understand the value of a project before you consider estimating the costs. The estimation at this point will be very rough, so make sure that you have a very wide margin between the expected value and the rough estimate of the cost. If you’re pretty certain of the expected value, I’d probably want to make sure I could still be profitable even if it took 3 or 4 times as long to complete as the rough estimate. And if there’s uncertainty in the expected value, much more.
+Another way to mitigate the risk of throwing money at something that’s not going to have positive ROI is to reduce the feedback loop. Order the work so that the tasks are ranked in order of value to the customer. (Realistically, you’ll have dependencies of tasks to worry about, and should consider effort involved too.) So work on the most valuable feature first — get that out into production as soon as possible. Once that’s done, you can assess if your ROI is positive or not. Keep iterating in this fashion, working on the features that will provide the most value first. Keep assessing your ROI, and stop when the ROI is no longer worth it, compared to other projects the team could be working on.
+At a fine-grained level, if you’re using story points, I’d ask you to do the math to see if just counting the stories would be as effective at predicting how much will be done over time as using the story points. If so, you can save the time the team spends on estimating stories. I’d still recommend spending time talking about stories so that everyone has a shared understanding of what needs to be done, and to break stories up into a smaller, more manageable size — with one acceptance criteria per story. Also take a look to see if empirical average cycle time (how long it takes a single story to move from start to finish) might provide you the predictive power just as well as estimates. (I.e. is it bandwidth or latency that really provides the predictive power you’re looking for?)
+And don’t forget Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.
+One of our managers recently mentioned that we hadn’t met the “contract” that we had “committed” to in our last iteration. This was complete nonsense, because A) we hadn’t made any such commitments, and B) we completed many more story points than the previous iterations (and without inflating story points).
+
But her language made me come to several realizations. First and foremost, estimates are contracts. Sure, they’re not supposed to be treated as commitments, but they almost always are. And what does the Agile Manifesto say about this? It says that we should value customer collaboration over contract negotiation, and responding to change over following a plan. So it’s pretty clear that treating estimates as commitments is completely counter to the Agile values.
+Why does this matter? What benefits do the Agile values bring us? I think the biggest benefit they bring is changing the way that we work, so that we can better deliver value to our customers. Without Agile, we’d just keep working the way we’ve always done things. And that didn’t seem to be working out so well. If we follow the Agile values and principles, at least we’ll have a fighting chance of improving our ability to deliver value.
+Ask yourself — have you ever seen a software development project that was on time and on budget? Where the estimates were spot-on? Of course not. For one, we’re terrible at estimating. For another, our plans change — either from external factors, or from what we learn as we go.
+To me, Agile is also about facing reality — and embracing it. It realizes that we’re terrible at estimating. It realizes that plans change. Most Agile methodologies have some tricks to counteract Hofstadter’s law. Generally, we use relative story points instead of hours, and then use an empirical factor to convert points to hours.
+When this works, it is better than any other estimation I’ve ever seen. But it doesn’t work very often. People have trouble with relative estimation. How do you set the basis for what a point means without relating it to actual hours? Affinity estimation could work, but then you have to remember what the basis was. We’ve got a large distributed team, and when we tried this, we couldn’t all remember what the basis was.
+Since we couldn’t get affinity estimation to work, we tried changing to perfect hours (only powers of 2). But then people thought of them as time. When we took longer than the estimate on an individual story, managers and team members thought we were taking longer than we should have. So our estimates ended up causing problems.
+Managers want estimates so that they can have predictability. They want to know when new features will be available. Is there a better way to get what we need?
+I believe there’s a better way — prioritization. If you work on the most important thing first, then the most important thing will get done first. We should always be working on the next most important thing.
+What if there’s more than 1 thing that’s most important? Then you’ve failed. You’ve failed at logic if you can’t understand that only 1 thing can be most important. You’ve failed at prioritizing the customers’ needs. You’ve failed at project management.
+1. Why can’t you just tell us how long it will really take?
+Because we don’t know. Because we can’t know. This is the first time we’ve ever implemented the functionality you’ve asked for. If we’d done it before, we’d just use that existing code. As Glenn Vanderburg pointed out in his excellent talk on Software Engineering, we’re not building software, we’re architecting it.
+2. But we have to tell our customers what to expect.
+Why? Is the product so bad that you can’t keep customers around without leading them on with future enhancements? And why do customers need exact dates? A general roadmap telling them what the priorities for upcoming features should be sufficient.
+3. But we have to have messaging about new features.
+OK. Then send out that messaging once the feature has made it to Staging. Or even after it’s been rolled out to Production.
+4. But we’ve promised these new features to the customers by this date.
+Ah, so you’ve made promises to the customer that you don’t have control over. Have you ever heard of “under-promise and over-deliver”? That’s how you create happy customers. Yet you’ve done just the opposite, haven’t you? And then you want to blame someone else.
+Risk
+Estimates are risk. But the risk doesn’t come at the end, when the estimates are shown to be incorrect. The risk was in asking for the estimates in the first place, and placing trust in them. Don’t do it. Don’t promise things that you can’t be sure of.
+Embrace this reality. Embrace this uncertainty. Always focus on what’s most important. That’s how you make customers happy.
+]]>It’s taken me years to realize that being right isn’t terribly important. Especially when there’s more than one right answer — which there usually is. It’s more important to work as a team. It’s more important to be respected and to have respect for others.
+A few weeks after that interview, I was pair programming with the person who had asked me the question. We’re both senior developers, so we both have a lot of experience and opinions based on that experience. We were writing a shell script, and we both had an idea in mind about how to write the code. I let him proceed with his idea. It was a pretty good idea; probably better than mine. But we paired very effectively. I’d let him finish some code, and I’d find a way to make it better. Then he’d find a way to make my code better. What we ended up with was so much better than my original idea, and his original idea as well. I commented on this, and he agreed. We left that pairing session feeling the high of having accomplished something rare — two very experience programmers coming up with better code than we could have imagined going in.
+I like to think of writing code as a path towards a destination. The destination is good code that does what it’s supposed to, is readable (intention revealing), is concise, and is well-factored so as to be easy to change in the future. But there are many paths to that destination. Especially when pair programming, the code gets refined as ideas are shared, getting you closer and closer to that destination. Sometimes the different paths end up with the same code; sometimes they end up with different code. But if the code does its job well (according to those criteria), it doesn’t really matter what code you ended up with.
+Thinking back to the original question, I think the answer is a little more nuanced. (I’m pretty sure I followed up with an explanation, but I don’t recall the details.) It truly doesn’t matter in a lot of cases. If there are different paths that lead to the same destination, and they’re all roughly equal, then my rule works. It can also work even if the first path you try (a “wrong” path) doesn’t work out, as long as it’s easy enough to try a different path. I find that the majority of day-to-day coding fits these conditions.
+But there are some places where it’s costly to get things wrong the first time. In these cases, it’s worth spending some time thinking about and discussing the alternatives before getting started. Software architecture is the big one that comes to mind. In general, weighing the pros and cons of each option and applying previous experience works best.
+So next time you think about trying to convince someone you’re right, fight the urge. Instead, let them show you what they’re thinking. They just might surprise you. And more importantly, you might surprise yourself.
+]]>We’d brought in Diana Larsen to facilitate the Open Space. Diana is a stalwart of the Agile community, focusing on how people and teams interact. She literally (co-)wrote the book on Agile retrospectives. Diana was also kind enough to be our guest at an Agile LINC meetup later in the evening.
+The morning started off with all the participants sitting in chairs arranged in a circle. Diana rang a chime, a nice soothing tone that literally set the tone for the day. (Most people didn’t seem to like it, but I thought it had its purpose.) It also acted as a call to gather in the meeting space. She then walked around the inside of the circle as she explained what was going to happen.
+The idea behind Open Spaces came with the realization that at a conference, the “hallway track” (ad hoc discussions in the hallways) was often more valuable than the scheduled talks. So they figured out a way to capture that experience. There are only a few rules:
+Once Diana set the scene and explained the rules, people came up and presented ideas for topics. If you proposed a topic, you chose a time and location on the topic board. At that time, you’d facilitate a discussion on that topic. The format was really conducive to discussions. There was no preparation, so discussions were from the heart — lots of people felt that they could contribute.
+Being new to the company (only 2 months), I got a lot out of the workshop, beyond the content itself. I got to get to know several more people. I’d even say I made a few friends. Having open discussions, we found that many of the teams were having the same issues. This made it easy for me to talk to other people.
+All-in-all, I found the Open Space to be extremely conducive to discussions aimed at identifying issues, brainstorming solutions, and planning action items. I felt like we made great strides in addressing some of the biggest problems our organization is currently facing.
+]]>I started out with a pretty simple question: “What do you value (in regards to what we’re building); what are you willing to fight for?” I asked them each to write down several values and then put them on the board before looking at everyone else’s answers. I also asked each person to rank their values in order of importance.
+It turned out that my question was a little vague. Some people thought about the question in terms of the end result, and some in terms of the process of creating the software. In some ways that was a bit of a problem, because the different interpretations led people in different directions. But in other ways, not pushing them in any particular direction got more varied answers, exposing how they think about the project and the product.
+My list (in order) was Effectiveness (doing the right thing), Quality (doing things right the first time), Happiness, Purpose, and Teamwork. In retrospect, I should have put Happiness first. If I’m not happy at work, I don’t really want to be there, and need to move on. (Sometimes I can trade some happiness at work for more happiness at home, but I’m definitely a person that needs to be happy at work.) The other values serve to improve my happiness, but the happiness is more important.
+My own issue ranking my values turned out to be a problem with the ranking in general. Should they be ranked in importance of the necessity of the value as an outcome, or in importance of the necessity to focus on the value? I think the former is what I was looking for, but even I wasn’t clear on that when I began the exercise.
+After everyone put their values up on the board, we read them off. Then I asked the team to choose several values that we share as a team. We pulled them off the individual members’ lists, and put them in the team list. Then I asked each person to come up and rank those values, then explain why they had ordered them that way, especially when they ordered them significantly different than the last person. I was hoping to come to some convergence of the rank over time, so we could document our values in rank order. That didn’t happen. But the discussion was illuminating to me and to everyone on the team.
+I think the most interesting part about the lack of convergence was the difference between the developers and the product guys. The product guys definitely viewed the values more in terms of outcomes than the process. That makes sense — they’re not as intimately involved in the process of building the product.
+We were able to converge on the top priority though: Will the user buy the product? This was a combination of a couple different values that we merged together. This included the end user experience as well as making sure the team would continue to have a reason for existing. The rest of the values we left unordered: Teamwork (cohesiveness), Data driven decisions, Team ownership, Simplicity, Effectiveness, Maintainability / Supportability, Quality, Automation, and Performance. I think that’s a pretty decent list.
+As a couple teammates pointed out, those values are probably in part a reflection of this current point in time. If I asked the same question some other time, under different conditions and team dynamics, the answers would probably change a bit. And we’d probably come up with other answers if asked again, just due to randomness of the way we think about these things.
+But I don’t think I’d do this activity a second time with the team. It was really about understanding our motivations — both our own, and those of our teammates. I found it effective in that way, and also in helping the team to think about our culture and how we can work to shape it to help us all push in the same direction.
+There are a few caveats. When I asked for feedback on the exercise, one teammate pointed out that it wouldn’t work if people weren’t honest about their values, and they answered with what they thought management or their teammates wanted to hear. I don’t think that was an issue with this group, but it’s something to keep in mind.
+The other major thing I’d do is to make it clear up front that I’m not looking for any action items from this activity; it’s more about understanding each other and ourselves. And next time, I’ll work to clarify how to rank the values.
+I would recommend this activity for a new team, or when the makeup of the team is changing in some significant way. I wish there was a way to help a team converge on the ranking of their values, but I suppose I should be happy that agreeing on the set of important values went pretty quickly. And the diversity of ideas and opinions is probably a blessing that I should be embracing — the more ideas we have, the wider the variety of solutions we can imagine.
+]]>I got pretty lucky on this one. My main contract with Mercy got extended several times. Amos and I must have been doing a good job of keeping the customer happy. We even made it through a couple rounds of layoffs. I’m wrapping up the gig at Mercy now. I’m working one day a week there, as the project winds down.
+I also started a new gig this month at CenturyLink. I’m working on a cloud development team. Our current project involves selling WordPress as a service. The manager had been courting me for most of the year. I’m excited about my new role; I’ll be writing about it in a blog post soon.
+I set a goal in 2014 to give my first conference talk. I accomplished that, giving an ambitious talk at RubyConf. I enjoyed having done that, and vowed to do more conference speaking.
+I gave 3 conference talks in 2015. I gave a workshop on HTTP at RailsConf. I talked about immutable infrastructure at Madison+ Ruby. At RubyConf, I gave a talk on a micro-ORM I wrote. I also gave a lightning talk about Agile estimation (#noestimates).
+I was an alternate speaker at Windy City Rails, but did not give my talk on Alternatives to ActiveRecord. I also went to Strange Loop, mainly to see several friends and acquaintances speak.
+I wrote 24 blog articles this year. That’s about one every other week. What really kept me going was participating in a writing pact. When the pact was going, I had a 75% blogging rate. That’s pretty good.
+I’m not so sure about the quality of my blog writing though. I know that practicing writing is supposed to make you better. I know I wrote some really good articles over the past year, but I think I also wrote some articles that weren’t very good. I think sometimes the deadline has caused more harm than good. I’m not really sure what to do about that; perhaps just pushing on is the right answer.
+I’ve taken a lot of notes on the design of my programming language. Any time I learn something interesting about another language, or come up with another idea, I write it down.
+But I haven’t worked on the implementation. (I last worked on the implementation in 2014.) I should be experimenting with some ideas, implementing them to see how they work out. I’ve even kicked around the idea of starting with a Forth variant, just to get something working quickly.
+I haven’t written any articles on my ideas this year either. My notes are pretty extensive, and it would be good to write some articles to help get my thoughts straight.
+I’ve got some things to say about Agile, and want to write a book to express those ideas. I’ve made a start — I’ve got the chapters outlines, and have started on a few chapters. But I haven’t made as much progress as I’d like to. I shared what I’ve got with Amos, and he showed some interest in pairing with me on the writing. Hopefully we’ll work on it together in 2016 and publish it.
+There were a few other accomplishments that weren’t explicitly on my list, but I’d like to call attention to.
+I’ve continued participating on the This Agile Life podcast. I was in 12 of the 33 episodes that were recorded in 2015. I hope to participate in more in 2016. We’re considering scheduling a standard recording night each week, which might help us record more regularly.
+I recently took over as maintainer of Virtus, a library to declare attributes for Ruby model classes. I haven’t done a lot yet, since I’ve been busy with travel, vacation, and holidays. But I hope to catch up with all the pending pull requests and issues in the next month or so.
+The accomplishment I’m most proud of is mentoring for the Roy Clay Sr. Tech Impact program. This is a program begun as a result of the Ferguson protest movement. We’re helping teach kids (from 14 to 25) web design and development. My personal goal was to give these kids an opportunity that they would not have otherwise had. But it turned out that some of them have actually started a business building web sites for small companies. I’m so proud of the progress they’ve made in such a short time; it’s a challenging program.
+I’m pretty happy with my accomplishments this year. I made at least some progress on each of the goals I set. I’ve been thinking about my goals for next year; I’ll write that as a separate blog article next week.
+]]>I have a moderate case of arachnophobia. I don’t run away when I see a spider, but it creeps my out when one is crawling on me. When I was in college, I decided to buy a tarantula to attempt to get over my irrational fear of spiders. I thought I’d be able to get more comfortable with the tarantula over time, eventually to the point of letting it crawl on my arm. It didn’t work. Although I did find that my fear of tarantulas is rational — I got a terrible case of hives just from touching the urticating hairs that fell off into its water sponge.
+Last week, I was on vacation in Mexico. One of the excursions we took involved jumping in the water a lot. I’m not a strong swimmer — mostly because I have a hard time closing my nose; I hold my nose when I jump in. We zip-lined into the water a lot. At one point, there was a cliff to dive into the water from. It was about 15 feet above the water. It didn’t look so far down before jumping. But it felt like a really long way down the first time I jumped from it. It was pretty scary for me. So I did it a second time. There wasn’t any peer pressure to jump a second time. I literally jumped a second time specifically because I was scared.
+Fear is a weird thing. Fear is there to protect us. But it’s there to protect us from the dangers of the African savannah. Most of the things our fears protect us from don’t exist in our everyday modern lives. So maybe we should work to gain a better understanding of how our fears work, to figure out when to pay attention to them and when to ignore them.
+Fortunately, our brain has a good mechanism to help us do this. Our brains basically have 2 main processing systems. The first one is for quick reactions. This one involves things that are nearly reflexes. Fear is in this system. The second system is our analytical reasoning system. This system takes longer to process, but is able to take on more information.
+Whenever the situation allows us time for both systems to work, we need to listen to them both. We need to listen to our fears, because they’re there for a reason. But that reason might not pertain to our situation. So we need to realize that, and let the slow analytical system determine if we should ignore our fears.
+If we don’t allow both systems to work, we’re not taking full advantage of our brains; we’re not taking full advantage of the situations that life is presenting to us.
+]]>Our tour guide was a lot of fun. He made jokes, told us about the cenotes, and led us in the activities. But he also encouraged us. When someone was scared to do something, he was supportive. He told us that it was okay, and we could do it. But we also felt like it was OK to fail, if we really couldn’t. It really felt like his encouragement was literally creating courage.
+What was really neat was that despite the language barrier, everyone else was also supportive and encouraging. Everyone cheered with encouragement before someone would attempt something difficult. And we’d cheer especially loud once someone accomplished something that was difficult for their abilities.
+It was an awesome feeling to feel so supported. It made me feel like I was in a safe place, where I could try new things that were a little past my comfort zone. I was able to do the zip-line upside-down. I jumped off a 15-foot cliff into the water. I even jumped off the cliff a second time, even though I was a little scared.
+Back at the resort, we played some volleyball in the pool. It was a similar situation, with players of varying ages and abilities. Again, we tried to help the weaker players feel comfortable so they could improve without feeling judged or self-conscious. It helped everyone have a good time. It made everything more fun to be in such a supportive environment, whether I was in a position as one of the more skilled (volleyball), or one of the less skilled (jumping or zip-lining into the water). We were all able to accomplish more, with less effort.
+These experiences provide a good lesson that can be applied in a lot of places. Such a supportive environment would help any relationship, and any team. I’ve been on a couple really good software development teams, but I don’t think any of them have been as supportive as these two groups of strangers.
+I’ve decided that this should be one of my goals as a team leader. I want to create an encouraging environment for the whole team. I want to make sure that everyone is comfortable enough that they feel like they can try things that are difficult, even if they might fail (as long as nobody gets hurt).
+If a group of strangers can do this, so can your team. So can you and your significant others. We need to work every day to make sure that we’re supporting each other. It’s the best way to get everyone to achieve more.
+]]>I think this is a key differentiator for me as a consultant. Most consultants (and Agile coaches) come in and tell people what to do. I don’t like to just tell people what to do. I’d much prefer to work side-by-side with them, getting a better understanding of what their challenges are. Once I have a better understanding of the challenges, I’m able to better brainstorm some ideas to try. Then we can experiment to see what will work and what won’t.
+Instead of telling people what to do, I show them how. Most people learn better from seeing than from hearing. They also learn better if you explain how and why, not just what. So showing them how to do something is more effective than telling them. By showing and doing, you can also set a good example. This is especially important when collaboration is a large part of what needs to be improved.
+I’ve found that this style of consulting is more highly respected by everyone. I build trust with developers by working closely with them. Managers like to keep me around once they see how effective these methods can be, so the gigs I take on tend to last relatively long.
+The biggest problem I have is explaining how this works. I don’t really know what to put on my résumé. Sometimes I call myself an Agile practitioner, and sometimes an Agile player/coach. But those aren’t terribly satisfying descriptions. I’m considering actually putting “I help teams improve the way they work — both their processes and their technical skills” on the résumé. But that seems awkward, and misses the show versus tell part. I’d be open to any suggestions.
++]]>
I started with two questions that I’ve used with teams before, to some success (although not so successful for one particular team). The first question I asked was “How happy are you at work?” I had them put a rating from 0 to 10, with 0 meaning they should have quit last week, and 10 meaning they couldn’t imaging being happier at work.
+The answers were mostly 7s and 8s, with a 5 and a 9. The average came to 7.5, which is pretty good. The 5 concerns me a bit, especially that it’s 2 points lower than anyone else’s answer.
+The next question I asked was “How effective do you think the teams is?”. Again, from 0 to 10, with 0 meaning they can’t accomplish anything, and 10 meaning you couldn’t imagine a more effective team.
+When I ask both of these questions, the scores are always highly correlated. If your team isn’t doing good work, it’ll make you unhappy. And if you are unhappy, you’re less likely to do your best work. This team was no different; the 5 and 9 became a 6 and a 10, and most of the 7s became 8s, for an average of just under 8.
+The next question I asked was “What makes you happy at work?”. The answers were mostly about the teamwork and teammates. This went quicker than I expected. At this point, I was worried the retro would only last a little more than 30 minutes.
+The final question I asked was “What would make you happier at work?”. This was the real pay-off. We spent about half an hour just talking about the things that would make us happier, and what we could do to improve our happiness. We came up with 10 potential action items. I usually limit teams to trying 3 or 4 action items, but most of the items are quite small, so we’re going to try 6 of them. One is just observing another team’s standup meetings, to see how they’re using their time effectively.
+Everyone went away feeling that this was a really good retro. It felt good to focus on happiness. Happiness is something I’ve been talking a lot about on the This Agile Life podcast, and it felt good to take some action on it. I’ve done “positive-only” retros before, but this one felt even better than that, by specifically targeting happiness and how we can achieve it.
+]]>I don’t recall all the specifics at this point. It was about 5 years ago. I’d just noticed that Arun had made some sort of mistake. That’s fine, people make mistakes. The thing that was different about his mistake was that I had made the same mistake about a week prior. And Amos had made the same mistake about a week before that.
+Noticing a pattern of mistakes, Amos and I called an impromptu retrospective. We gathered all the developers into a conference room. We explained the problem that we were running into. At first, Arun was defensive. That’s understandable; he thought we were there to come down on him, to lay blame. But we made it clear that we weren’t focusing on him. We admitted that we had also made the same mistake recently. We weren’t there to lay blame; we were there to figure out how our team could stop making the mistake. It took Arun a few minutes to get over the defensiveness.
+With the defensiveness out of the way, we could focus on the issue at hand. We were able to figure out the root cause of us all making the mistake. (I don’t know if we played the “5 whys” game, but I’m sure we effectively did something similar.) And with that, we were able to change our process, so that nobody else would make the same mistake again.
+There are 2 important points to this story. First, you don’t have to wait until a scheduled retrospective to hold a retrospective. This one was impromptu, and it’s the best one we ever had. We saw a problem, addressed it, and found a solution in less than an hour. Had we waited until the end of the week, we would have forgotten some of the details, and wouldn’t have been as effective at solving the problem. Second, when addressing problems, take your ego out of the equation. If you’re in a position of authority, take the blame — but never place blame. Focus on what’s important — solving the problem.
+And don’t forget the Retrospective Prime Directive:
++Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
+]]>
I’m a big proponent of Agile (mostly XP; I’m mostly anti-Scrum) and I’ve contributed some to the #noestimates “movement”.
+I don’t really mean that nobody should ever estimate anything. I mean that I’ve never seen useful (fine-grained) estimates anywhere. Here are some of the problems with estimates that I’ve seen frequently:
+I’ll note that most of these pit management against the team, instead of working together toward a common cause. Most of the practices also lead to seriously demoralizing the team. And most of the time, the estimates aren’t really even taken into account very much.
+My advice is to first understand the value of a project before you consider estimating the costs. The estimation at this point will be very rough, so make sure that you have a very wide margin between the expected value and the rough estimate of the cost. If you’re pretty certain of the expected value, I’d probably want to make sure I could still be profitable even if it took 3 or 4 times as long to complete as the rough estimate. And if there’s uncertainty in the expected value, much more.
+Another way to mitigate the risk of throwing money at something that’s not going to have positive ROI is to reduce the feedback loop. Order the work so that the tasks are ranked in order of value to the customer. (Realistically, you’ll have dependencies of tasks to worry about, and should consider effort involved too.) So work on the most valuable feature first — get that out into production as soon as possible. Once that’s done, you can assess if your ROI is positive or not. Keep iterating in this fashion, working on the features that will provide the most value first. Keep assessing your ROI, and stop when the ROI is no longer worth it, compared to other projects the team could be working on.
+At a fine-grained level, if you’re using story points, I’d ask you to do the math to see if just counting the stories would be as effective at predicting how much will be done over time as using the story points. If so, you can save the time the team spends on estimating stories. I’d still recommend spending time talking about stories so that everyone has a shared understanding of what needs to be done, and to break stories up into a smaller, more manageable size — with one acceptance criteria per story. Also take a look to see if empirical average cycle time (how long it takes a single story to move from start to finish) might provide you the predictive power just as well as estimates. (I.e. is it bandwidth or latency that really provides the predictive power you’re looking for?)
+And don’t forget Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.
+Web Development, Ruby on Rails, Open Source
+The Agile Manifesto was written in 2001, as a way to explain the common values amongst several “light-weight” software development methodologies that had come about. The term “Agile” was chosen as a shorthand for those commonalities.
+Once “Agile” started to show success, we started to see many people use the term to market their products and services, whether or not they really believed in the values and principles of the Agile Manifesto. It’s gotten to the point where some of us don’t see much value in using the term “Agile” any more. Even some of those involved in creating the manifesto have suggested new terms. Dave Thomas suggests “Agility” and Andy Hunt has started working on something called GROWS. Personally, I’m considering going back to the term “Extreme Programming”, even though I’ve incorporated ideas from other Agile methodologies.
+It recently occurred to me that Agile, when done “right”, is closely aligned with the happiness of the team members. This is really interesting, because it aligns the interests of the employees and the business — a win-win situation. My next thought was that maybe the next step after “Agile” will be a focus on happiness and motivation.
+I’ve recently been thinking about personal motivation lately, in the context of team practices. According to Daniel Pink’s book Drive, people are motivated by autonomy, mastery, and purpose. I personally add a fourth that can sometimes trump the other three: identity. And of course, happiness can also be motivating — both in the attempt to achieve happiness and in just being happy. (I suspect that happiness is more of a parallel to motivation than a cause though.)
+There are a couple different ways that happiness can be achieved at work. The traditional way is for work to be a means to an end. In this view, the purpose of your job is to provide the money to live your life (outside of work) the way that you want to live it. There’s nothing wrong with this way of thinking. But for the lucky few, we can work on something that makes us happy in and of itself. That’s generally done by finding a job doing something that we enjoy.
+But perhaps that’s thinking about things the wrong way. For one, plenty of people who have gone that route are still unhappy at work. I think a lot of that has to do more with the context surrounding the work than the work itself. Maybe you’ve got a lousy manager. Maybe you don’t like the people you work with. Maybe the tools you have to work with are bad. Maybe the processes add a lot of unnecessary tedium.
+So maybe we need to find ways to be happier at work. Most of the Agile practices seem to make team members happy. For example, replacing a light-weight process for a heavier process always makes me happy. And I typically leave retrospectives in a good mood. So that’s a good starting point. But we should see if we can take the idea further. If we take employee happiness as a core value, where can we go? What kind of practices would we want to add? Please share any ideas in the comments below.
+On a recent episode (78) of This Agile Life, my fellow hosts talked about when to do Test-Driven Development (TDD). They all said that you should always do TDD — at least for anything that will go into production; there’s an exception for experimenting or “spiking”.
+I wasn’t on that episode, but later commented on the topic. (Episode 83 — which wasn’t really all that great.) My take was slightly different. I said that you should do TDD only when the benefits outweigh the costs. Unfortunately, we usually greatly underestimate the benefits. And the costs often seem high at first, because it takes some time to get good at writing automated tests. Not to mention that both the costs and the benefits are usually hard to measure.
+What is the cost of writing automated tests? I’ve asked this question before and recorded the answers (inasmuch as we have them) in a previous blog entry. TDD costs us about 10-30% in short-term productivity. The benefit that they found was a reduction in bugs by 30-90%, and a decrease in code complexity by about 30%.
+But what about when the costs are higher than the normal 10 to 30 percent? One good example of this is when there’s no test framework for the situation you’re testing. This might be a new language or framework that you’re working with. More likely it’s a complex API that you have to mock out. So that could increase the cost of automated testing so as to outweigh the benefits — especially on a short project. I could imagine situations where the cost of writing the mocks could eat up more than the project itself.
+Another case where we might consider skipping testing is when we’re more concerned about time to market than quality. This is almost always a mistake. Your code will almost always last longer than you expect. (Remember Y2K?) And if the code lasts longer than you expect, that means you’ll have to deal with bugs that whole time. But we have to work with the information we have at the time we make our decisions. And sometimes that might tell us that time to market is more important than anything.
+One final case I can imagine is when a true expert is coding something that they’re very familiar with. I could picture someone like Uncle Bob writing code (in a language that he’s familiar with) without tests just as effectively as I could write code with tests.
+But these situations should not be common; they’re edge cases. In almost all real-world cases, TDD is the right thing to do. Don’t forget, TDD is also a design discipline — it helps you design a better API. So keep doing TDD. But as with any practice, don’t do it blindly without considering why we’re doing it. Make sure you understand the costs, and whether the benefits outweigh the costs.
+I ran into some former colleagues recently, from a company where I had worked to help transform the team to be more Agile. They’ve gone through some reorganization and management changes recently. One of the guys said that their team culture has helped them maintain quality in the face of those changes. This struck me as odd, since I had considered the work I had done there as somewhat of a disappointment. While I felt I had made a small dent, I didn’t feel like I’d made a true Agile transformation. Much of what I had taught didn’t seem to “stick”.
+Later that night I thought about why my opinion of the team and his opinion were so different. There are a lot of reasons why an Agile “transformation” could fail. It could be due to lack of support from management. Or even worse, not getting the team members to buy into the ideas — usually due to fear of change. But while those had some effect in this case, they weren’t really the main issues. Now that I’ve had some time and some distance from that team, I’ve gained some clarity on what the real issues were.
+I think the reason that I think this transformation was a failure was due to the continued pace of change that true Agile requires. Basically the team experienced “change fatigue”, where everything keeps changing and you feel like you can never catch your breath. But the more interesting thing is how our perceptions differed. He seemed to think that the transformation was a success — they’re doing things better than they used to. I view it as more of a failure, because they basically stopped improving — at least at the pace that I was hoping for.
+I think this difference in mindset is pretty fundamental. My view of Agile involves continuous improvement — always inspecting and adapting our processes. I suppose that means that my preferred flavor of Agile is “Kaizen“. But other people don’t see improvement and change as a constant — they see each change as a means to an end. I’m starting to realize that neither viewpoint is objectively correct. Maybe they’re both fine viewpoints to have. Maybe I shouldn’t be so hard on myself and view that engagement as a failure, especially if my teammates view it as a success. Maybe perfection is the enemy of the good. And maybe I need to learn to be happy with “good enough”.
++
I frequently participate in a podcast called This Agile Life. Recently, a listener asked how much time Agile teams should spend on self improvement. I said 10% to 25%, leaning towards 15% to 20% for most teams. That comes to at least one hour per day, and maybe even more than one day per week.
+I’m including personal self improvement and team retrospectives in this self-improvement time. This can be as simple as configuring your IDE to make you more efficient, learning to use a tool better, or following up on action items from a retro.
+That may seem like a lot of time “wasted”. But I think I can justify the cost of all that time.
+The purpose of spending time on team or self-improvement — the whole point — is to increase our performance and our efficiency. How much improvement can we expect? Can we improve by 1% each week? That doesn’t sound too unreasonable. I think that’s an achievable goal for almost any team, at least on average.
+Spending 20% of your time to gain 1% doesn’t seem like it’s worth it — until you consider the long term. With compound interest, you’ll be 67% more efficient by the end of a year.1 At that point, you’ll be able to get things done in 59% of the time — saving 41% of the time required at the beginning of the year.2 The following years will show even more progress, as compared to when you started. If 10x programmers exist, continuous improvement is apparently the way to get there.
+So there’s a pretty good return on investment, even with a small amount of improvement each week. You’ll be significantly more efficient.
+But efficiency isn’t really what you should aim for. You should aim for effectiveness. You can be efficient in creating the wrong thing. Part of improving should be ensuring that you’re not just building things right, but that you’re building the right things. Build what the customer really needs. Find ways to ask the right questions.
+Most importantly, find ways to keep improving. It would be a waste of time not to.
+ +January kept me pretty busy, so I’m a little late to this. But better late than never. And as an Agile practitioner, I don’t think personal retrospectives should be limited to one time of year.
+Last year I wrote a blog entry listing my goals for 2014. As far as New Year’s resolutions go, I was relatively successful — about 50% of my goals accomplished. Unfortunately, my Open Source contributions weren’t as strong as I had hoped; while I released some of my own work, I didn’t do much else. I did increase my blogging; getting in on a weekly blogging pact helped immensely. I also increased my participation on the This Agile Life podcast to a level that I’m happy with. But the accomplishment I’m most proud of was giving a presentation at RubyConf.
+I’d like to keep things rolling from last year, but crank up a few things. My plans are quite ambitious, so I don’t expect to get everything done by any means. But I think by setting the bar high, I’ll end up with a lot I can be proud of.
+Late last year, I took the jump into independent consulting. So far, I’ve really enjoyed it, and I’m booked up through April. My wife graduates in May, so we’ve got the possibility of moving if that makes sense. So I’ll be looking for consulting projects in town, but I’ll also be looking at jobs in San Francisco and Chicago. The possibilities are exciting, and I’ll be taking my time to find something just right.
+I was incredibly nervous leading up to my RubyConf presentation. Part of that was just the common fear of public speaking. For me, that only kicks in at around 100 people, and this audience was around 250. I think another reason was that I chose a really ambitious topic, and I kept finding more that I wanted to talk about, but wasn’t prepared for. But I think I did a pretty good job presenting an advanced topic. And I was so pumped by the sense of accomplishment as soon as I finished. So I’m hoping to do it more. I’ve already submitted a couple proposals, and plan to submit several more.
+I believe that blogging is important for me to get my thoughts down — for myself and to share with others. I was really successful last year when I had a partner to keep me honest, via a pact. So I’ve started up another pact this year, which will hopefully ensure I’ll keep things going. I’ve got a really long backlog of topics, so as long as I keep at it, I’ll have plenty to write about.
+I also want to move away from WordPress to a static system — probably Middleman. I’ve got 2 major problems with WordPress. First, I no longer trust its security, nor the security of any application written in PHP. Second, it generates HTML every time someone requests a page, instead of when the content is updated. I find that to be a waste of resources, and problematic from a security standpoint. The main problem with moving to a static blogging system is that I really want to allow comments, pingbacks, and tweetbacks. So I’ll have to find a way to integrate those.
+Last year I started thinking about programming language design, and started implementing a language tentatively called Brilliant. I’ve done a lot more thinking on the topic, and have a lot of notes. But I haven’t implemented much more yet. This year, I’d like to get my thoughts more organized, and write a series of blog posts on various aspects of language design. The most interesting part seems to be the trade-offs involved in the ways that various language features interact. So I’d like to make some progress on the language implementation, but more importantly, I’d like to get a lot of my design ideas written down.
+I’m also going to spend a lot of time learning a bunch more programming languages, so I have a better understanding of possible features, combinations of features, and their interactions. I’ve already start with Elixir, Clojure, and Racket. I’m hoping to also look at OCaml, Factor, and Haskell. I’ll probably also take a look at the 2 “Seven Languages in Seven Weeks” books.
+I think people often have trouble getting started with Agile. I started on a book last year, and got down quite a lot of good ideas. But I realized that I’m going to have a hard time organizing all those ideas into something coherent. Still, I’d like to try to get something out there that lets people get started with Agile. My idea is to present a toolbox of practices to get started with and build on that foundation over time with additional practices. Sort of a playbook on how to get started over the first 6 to 12 months and be successful. I want to make some progress on the book, at least enough to decide whether it’s worth the effort to finish it and self-publish it.
++
I went to RailsConf this year, and the very first talk was a keynote by David Heinemeier Hansson (DHH), the creator of Ruby on Rails. The TL;DR of his talk was “TDD rarely has value”. He followed up with a blog post the next day, titled “TDD is dead. Long live testing.“, and 2 more posts. I think this line of thought is terribly misguided, and causing more harm than good. This article is my response.
+First, I would like to address the good points of the talk. He said that programming is pseudoscience, and that people want to tell us that there’s a secret to being a better programmer. But what it really takes is working hard — reading a lot of code, writing a lot of code, and rewriting a lot of code. He’s right. And I also agree with him that you should forget about patterns for a while when learning to code. Beginners try to throw patterns at a problem instead of letting the patterns emerge where they’re supposed to.
+I don’t completely agree that programming is a pseudoscience. In some ways it is, but I think it’s more of a craft. It’s a craft, because there’s a lot of science involved, but there’s also an art to doing it well. And like any craft, you’re always working to get better. So to respond to DHH’s stance that “software is more like poetry than physics”, I think it falls
+somewhere in between.
With regard to the software engineering practices we use, there really isn’t much science available, mostly because it’s a soft science. That is, it’s really hard to isolate a single variable when comparing code between projects. And nobody has the time or money to write the same code so many times that the differences would be statistically significant.
+So we don’t have much science on TDD. But we do have some. Here’s a collection of several: StudiesOfTestDrivenDevelopment. And here’s one that explicitly looks are the difference between test-first and test-last: Does Test-Driven Development Really Improve Software Design Quality? What do these tell us? They tell us that TDD costs us about 10-30% in short-term productivity; reduces bugs by 30-90%, and decreases code complexity by about 30%. As Code Complete tells us (in section 20.5, with studies to back it up), improving quality reduces development costs. So, like most Agile practices, this is a case where spending a bit more time in the short term leads to time savings in the long term.
+The more important lesson in the talk was that you have to do what works best for you and your situation. If TDD doesn’t give better results, then either find out how to make it give better results, or stop using it. As we often say in the Agile world, Agile doesn’t mean that you can stop using your brain. While I think TDD is appropriate in most situations, there are cases where it’s not worth the additional up-front cost. If the most important thing for your project is time-to-market, then not testing might be the right decision for you.
+To me, TDD provides a bunch of benefits. First and foremost, TDD is a design discipline. It ensures that I think about how my code will be used before I think about how to implement it. This is very powerful in ensuring that the code is well-written from the perspective of other code using it.
+Tested code provides confidence to be able to make changes without breaking things. If we write tests after the code, we’re less likely to write them. Tests written after the code also tend to test the implementation instead of the desired functionality. What we really want is tests written as a specification. With tests as a specification, we can come back later and understand why code was written. Without tests, or with poor tests, we can’t understand why the code is there; if we want to rewrite it, we don’t have the confidence that we’re not missing something. Writing tests first also ensures that we only write the code that is needed to implement the required functionality.
+I’m not sure why DHH hasn’t “gotten” TDD. I’m not sure if it’s because he’s a better coder than average, or if he just thinks in a different way than most of us. I think it’s partly because he doesn’t understand TDD, which he admitted might be the case. And I think he’s conflating TDD and unit testing.
+DHH is influential in the developer community, especially those newer to Ruby and Rails. People listen to what he has to say. I was happy to see almost every other speaker made fun of DHH’s ideas, and most of the crowd knew better. But there will be a lot of others who will hear DHH, respect his opinions, and not give TDD the try that it deserves. And that’s sad, because it will lead to an overall reduction in code quality in the world.
+Here are some other people’s thoughts on the matter:
++
I don’t believe that estimation should be part of any Agile practice.
+One of our managers recently mentioned that we hadn’t met the “contract” that we had “committed” to in our last iteration. This was complete nonsense, because A) we hadn’t made any such commitments, and B) we completed many more story points than the previous iterations (and without inflating story points).
+
But her language made me come to several realizations. First and foremost, estimates are contracts. Sure, they’re not supposed to be treated as commitments, but they almost always are. And what does the Agile Manifesto say about this? It says that we should value customer collaboration over contract negotiation, and responding to change over following a plan. So it’s pretty clear that treating estimates as commitments is completely counter to the Agile values.
+Why does this matter? What benefits do the Agile values bring us? I think the biggest benefit they bring is changing the way that we work, so that we can better deliver value to our customers. Without Agile, we’d just keep working the way we’ve always done things. And that didn’t seem to be working out so well. If we follow the Agile values and principles, at least we’ll have a fighting chance of improving our ability to deliver value.
+Ask yourself — have you ever seen a software development project that was on time and on budget? Where the estimates were spot-on? Of course not. For one, we’re terrible at estimating. For another, our plans change — either from external factors, or from what we learn as we go.
+To me, Agile is also about facing reality — and embracing it. It realizes that we’re terrible at estimating. It realizes that plans change. Most Agile methodologies have some tricks to counteract Hofstadter’s law. Generally, we use relative story points instead of hours, and then use an empirical factor to convert points to hours.
+When this works, it is better than any other estimation I’ve ever seen. But it doesn’t work very often. People have trouble with relative estimation. How do you set the basis for what a point means without relating it to actual hours? Affinity estimation could work, but then you have to remember what the basis was. We’ve got a large distributed team, and when we tried this, we couldn’t all remember what the basis was.
+Since we couldn’t get affinity estimation to work, we tried changing to perfect hours (only powers of 2). But then people thought of them as time. When we took longer than the estimate on an individual story, managers and team members thought we were taking longer than we should have. So our estimates ended up causing problems.
+Managers want estimates so that they can have predictability. They want to know when new features will be available. Is there a better way to get what we need?
+I believe there’s a better way — prioritization. If you work on the most important thing first, then the most important thing will get done first. We should always be working on the next most important thing.
+What if there’s more than 1 thing that’s most important? Then you’ve failed. You’ve failed at logic if you can’t understand that only 1 thing can be most important. You’ve failed at prioritizing the customers’ needs. You’ve failed at project management.
+1. Why can’t you just tell us how long it will really take?
+Because we don’t know. Because we can’t know. This is the first time we’ve ever implemented the functionality you’ve asked for. If we’d done it before, we’d just use that existing code. As Glenn Vanderburg pointed out in his excellent talk on Software Engineering, we’re not building software, we’re architecting it.
+2. But we have to tell our customers what to expect.
+Why? Is the product so bad that you can’t keep customers around without leading them on with future enhancements? And why do customers need exact dates? A general roadmap telling them what the priorities for upcoming features should be sufficient.
+3. But we have to have messaging about new features.
+OK. Then send out that messaging once the feature has made it to Staging. Or even after it’s been rolled out to Production.
+4. But we’ve promised these new features to the customers by this date.
+Ah, so you’ve made promises to the customer that you don’t have control over. Have you ever heard of “under-promise and over-deliver”? That’s how you create happy customers. Yet you’ve done just the opposite, haven’t you? And then you want to blame someone else.
+Risk
+Estimates are risk. But the risk doesn’t come at the end, when the estimates are shown to be incorrect. The risk was in asking for the estimates in the first place, and placing trust in them. Don’t do it. Don’t promise things that you can’t be sure of.
+Embrace this reality. Embrace this uncertainty. Always focus on what’s most important. That’s how you make customers happy.
+There’s a tweet that I saw recently, with some simple advice for novice programmers:
++Slow down.
This is probably good advice for most programmers. Our team recently noticed that every time we try to rush things, we make mistakes. And the mistakes end up costing us more time than if we had just done things at our normal pace. Slowing down ensures that you do things right, and when you do things right, you end up with a higher-quality product.
+There are 2 types of code quality: internal and external. External code quality can be measured by how many bugs have been reported by customers. Internal code quality is harder to measure, but it mainly deals with the ability to change the code. When your internal quality is low, you’ve got lots of technical debt, and it’s harder to make changes.
+So when you try to write code quickly, code quality decreases, leading to a code base that takes more time to make changes to. Conversely, when you slow down, your code quality improves, and it becomes easier to make changes more quickly. So when writing code, slowing down in the short run leads to a speed-up in the long run.
+But writing code isn’t the only place where we try to speed up. On an Agile team, we’re always trying to improve the way we work — especially at the beginning stages of an Agile transformation. So we’re eager to make changes in our processes. But I’d urge you to slow down here as well.
+My colleague Amos and I frequently argue over pair switching. It’s funny, because we agree on everything except for 1 small detail. We both think pair switching is very important, to ensure that team members see more of what’s going on, to bring more ideas to each story, to prevent knowledge silos, and to encourage team ownership. Where we disagree is how long an ideal pairing session should last. I think pairs should switch every 2 hours, and he thinks 1 hour is ideal. I’ve seen teams reach the 1 hour pairing sessions successfully. But usually not without some pain and even often failing at the first attempt.
+There’s nothing inherently wrong with failing. But if you fail at something, you’re not likely to try again. After all, you should learn from your failures, right?
+So if you want your team to do something, you probably don’t want them to fail at it. If they fail, they won’t want to try a second time. That’s just human nature, and learning from failure. While you might think that they failed because they weren’t ready for the change yet, they’ll most likely think that they failed because this particular change won’t work for their situation. And they probably won’t know what to change when trying again, so they won’t try again.
+I’ve seen this over and over. Back when Linux was up-and-coming, when a consultant pushed a company into using Linux before they were ready for it, and it didn’t work out, that company was cautious about trying again. So instead of being on the leading edge of using Linux, or even the middle of the pack, they ended up more toward the trailing edge. Had they not been pushed, they would have gotten more benefit in the long run.
+So my advice in process improvement is the same as in programming: slow down. Take small steps toward what you think is the ideal. Make a small change, see how it works out, and adjust. As long as you’re still moving in the right direction, I believe you’ll move faster by taking small steps than by trying to make big leaps.
+I facilitated our team retrospective this morning. I felt like we made a little forward progress, but not as much as I would have liked. But it really brought one thing to the forefront of my thoughts today — empathy gained through communication.
+We have a pretty large team by Agile standards — we had 20 people in our retro: 16 developers, 3 QA folks, and 1 manager. Out of those, only about 5 or 6 speak up regularly. I recently sent out a survey to the team, trying to get feedback on how we could improve our retros. A couple of the questions tried to get a feel for why people aren’t speaking up more. Only about half the people responded, and the answers didn’t really answer my question as well as I had hoped.
+So on Amos‘s suggestion, we did the Safety Check exercise. We got a good set of answers to why people don’t feel safe. About half of the answers were about the fear of looking stupid in front of other people. About half of those mentioned the manager — they’re worried they might get in trouble for what they say. We talked some about fear and how it’s more often than not misplaced. And that the worst consequences are usually not as bad as you might think. But then we got to the crux of the problem — there’s not enough trust amongst the team, and especially between the team members and the manager.
+About half of our team is new (within the past 6 months) — including the manager. While the developers have made some good progress building trust amongst each other, we haven’t had as much time with the manager to build trust between him and the rest of the team. So the lack of trust isn’t at all surprising.
+Honestly, I already knew we had trust issues, and wanted to address them, but needed a way to lead the team to that same realization. With this exercise driving out the issue, we were then able to have a conversation about trust. The conversation was pretty good. We got more voices to contribute than probably any other topic we’d previously covered. (I was disappointed that the manager kept quiet though. I later found that he was trying to mitigate people’s fears by keeping quiet, but I urged him to contribute more in the future.)
+But one point really stood out in my mind — a point of view that I hadn’t previously thought much about. Lauren, one of our QA analysts, pointed out that most human communication is non-verbal. We give tons of cues via body language, facial expressions, eye contact, tone of voice, even posture. I don’t recall if Lauren said it explicitly, but she pointed out that these cues build empathy between the speakers. She encouraged us to use more voice chat and video chat, as opposed to IRC text chat, because it would create more empathy between the people communicating, which would lead to more trust.
+I spent most of the rest of the day talking to people on the phone or via Google Hangouts voice. And every single time, I consciously noticed that I was gaining empathy for the person I was speaking with. I assume (and hope) that that’s working both ways. I suppose that it’s always been happening, but I never really noticed it.
+I’ve heard a lot of talk about empathy among Agile practitioners lately. It’s been mentioned on the Ruby Rogues podcast, and Angela Harms has been preaching it for years. I already understood how important it is. But until today, I didn’t really feel it happening.
+So if you’re looking to build trust with someone, spend some time talking with them. Preferably in person, but if that’s not possible, seriously consider video or voice modes of communication, instead of sending an email or an instant message.
++
It’s challenging to test Rails custom validators.
+I recently had to write a validator to require that an entered date is before or after a specified date.
+It didn’t seem like writing the validator would be too difficult – I’ve written custom validators before, and date comparisons aren’t all that tricky. But when it came time to write the tests, I ran into several issues. And since I always try to follow TDD / test-first, I was blocked before I even began.
+The biggest issue was the ActiveModel::EachValidator#validates_each API. It’s definitely not a well-designed API. You write your validator as a subclass, overriding validates_each. The method takes a model object, the name of the attribute of the model being tested, and the value of that attribute. You can also get the options passed to the custom validator via the options method. To perform a validation, you have to update the model’s errors hash.
The big flaw in the API is that instead of returning a result, you have to update the model. This needlessly couples the model and the validator. And it violates the Single Responsibility Principle — it has to determine validity of the field, and it has to update the errors hash of the model. This is not conducive to testing. Testing this method requires testing that the side-effect has taken place in the collaborator (model), which means it’s not really a unit test any more.
So to make it easier to unit test the validator, I broke the coupling by breaking it into 2 pieces, one for each responsibility. I moved the responsibility for determining validity to a separate method, which I called errors_for. It returns a hash of the errors found. This simplified the validates_each method to simply take the result of errors_for and update the errors hash of the model:
def validate_each(record, attribute_name, attribute_value) + record.errors[attribute_name].concat(errors_for(attribute_value, options)) +end+
This made it much easier to unit test the errors_for method. This method doesn’t even need to know about the model — only about the value of the attribute we’re trying to validate. We simply pass in the attribute’s value and the options.
So we could write the tests without even pulling in ActiveRecord or any models:
+describe DateValidator do
+ let(:validator) { DateValidator.new(attributes: :attribute_name) }
+ let(:errors) { validator.errors_for(attribute_value, validation_options) }
+
+ describe 'when attribute value is NOT a valid date' do
+ let(:attribute_value) { 'not a valid date' }
+ it { errors.must_include 'is not a valid date' }
+ end
+
+ describe 'when attribute value IS a valid date' do
+ let(:attribute_value) { Date.parse('2013-12-11') }
+ it { errors.must_be :empty? }
+ end
+end
+And the errors_for method looked something like this:
def errors_for(attribute_value, options) + unless attribute_value.is_a?(Date) + return [options.fetch(:message, "is not a valid date")] + end + [] +end+
Integration testing can also be a bit of a challenge. I recommend following the example from this Stack Overflow answer. Basically, create a minimal model object that contains the field and the validation. Then test that the model behaves like you expect with different values and validations.
+Web Development, Ruby on Rails, Open Source
+Today I was informed that I’ve been impeding progress on our team.
+This was somewhat shocking, since I feel like I’m always pushing
+forward to make our team and myself better.
Like most anyone, my initial reaction to criticism was defensiveness.
+I don’t handle criticism well. (You might find that hard to believe,
+after reading the rest of this post. Maybe it’s just the confrontation
+part I don’t handle well.) Thankfully the blow was softened somewhat,
+because the person providing the criticism didn’t tell me directly —
+they told Amos, a trusted colleague of mine. Amos then passed it on to
+me. I’m grateful for that — this is the best way for me to have received
+that criticism.
What I did next is the astonishing thing. I swallowed my pride for a
+minute. Not an easy thing for me to do, for all the usual reasons, and
+more. I decided to address the problem head on. If someone was telling
+someone else that I was causing some sort of a problem, then even that
+perception was a problem that I needed to address. So I decided to hold
+a retrospective for myself. Retrospectives are the way Agile teams address
+problems and improve how they work. If it would work for a team, I figured
+it should work for an individual.
I’d held retrospectives by myself before. Before I even knew about
+retrospectives, I’d taken some time to assess how I had done things
+on a couple of projects I had worked on as an independent contractor. But
+those were about technical decisions I had made and processes I had
+followed. This one would be different. This one was about a personal
+shortcoming, an action of mine that had caused some harm. This one
+involved feelings and emotions.
So I asked Amos to facilitate my one-person retro. We’d both done a lot
+of retrospectives, but neither one of us had done anything like this before.
+We had a bit of trouble getting started. We didn’t have any details
+about why the anonymous person felt the way he felt. So it was hard
+to address something that nebulous. So I asked Amos if he could follow
+up with the person. Luckily, the person was online and able to respond
+in real time.
So we talked things through some. We went on some tangents. We made some
+progress — things that I could write down as take-aways and action items.
+We got off-topic again, and then came back to it. Then Amos decided to
+play The Why Game. This worked amazingly well. It helped me to find the
+root reasons why I was holding back change. Basically I’m afraid of
+failure. Going deeper, we looked into why I’m afraid of failure. This
+line of inquiry was particularly effective. Hopefully it’ll be enough for
+me to stop being an impediment to change. Here are my notes / take-aways:
At first, I thought that I’d never heard of anyone doing anything like
+this. But then I recalled that I’d heard about somewhere that everyone
+does this, with their whole team. That would be hard. I’d have to
+trust everyone in the room.
But I would recommend this for anyone that can pull it off. It’s hard,
+but it has a large payoff. Just like a team retrospective, it feels good
+making this kind of breakthrough, and knowing that just spending that
+little amount of time has made me a better person. (Mine took about an hour.)
+I think the hardest part is finding someone (or a group of people) you
+trust to be your facilitator.
I’ve decided to call this thing an introspective. A retrospective is
+about looking back. This is about looking inward. I’d be interested to
+find out who is doing this kind of thing. Does it have a commonly accepted
+name? How does it work? What techniques work best? If you’ve got any answers or ideas, please comment below, or tweet me @CraigBuchek.
So thank you to that anonymous person. Your way of addressing this was
+probably more effective than you could have imagined that it might be.
+I hope that this exercise will help me make the changes required, to make
+me a better person, and help the team become the best that we can be.
Amos has written up his thoughts on the introspective.
+Web Development, Ruby on Rails, Open Source
+I held a retrospective with my new team last week. The team includes 2 senior developers, 2 junior developers, a product owner, and a product analyst. I’ve joined the team as an engineering manager, which I think of more as a team lead with an elevated title. Being new to this group, I wanted a way to understand their values. What motivates them? What common values do we share that we can leverage to move forward in the same direction?
+I started out with a pretty simple question: “What do you value (in regards to what we’re building); what are you willing to fight for?” I asked them each to write down several values and then put them on the board before looking at everyone else’s answers. I also asked each person to rank their values in order of importance.
+It turned out that my question was a little vague. Some people thought about the question in terms of the end result, and some in terms of the process of creating the software. In some ways that was a bit of a problem, because the different interpretations led people in different directions. But in other ways, not pushing them in any particular direction got more varied answers, exposing how they think about the project and the product.
+My list (in order) was Effectiveness (doing the right thing), Quality (doing things right the first time), Happiness, Purpose, and Teamwork. In retrospect, I should have put Happiness first. If I’m not happy at work, I don’t really want to be there, and need to move on. (Sometimes I can trade some happiness at work for more happiness at home, but I’m definitely a person that needs to be happy at work.) The other values serve to improve my happiness, but the happiness is more important.
+My own issue ranking my values turned out to be a problem with the ranking in general. Should they be ranked in importance of the necessity of the value as an outcome, or in importance of the necessity to focus on the value? I think the former is what I was looking for, but even I wasn’t clear on that when I began the exercise.
+After everyone put their values up on the board, we read them off. Then I asked the team to choose several values that we share as a team. We pulled them off the individual members’ lists, and put them in the team list. Then I asked each person to come up and rank those values, then explain why they had ordered them that way, especially when they ordered them significantly different than the last person. I was hoping to come to some convergence of the rank over time, so we could document our values in rank order. That didn’t happen. But the discussion was illuminating to me and to everyone on the team.
+I think the most interesting part about the lack of convergence was the difference between the developers and the product guys. The product guys definitely viewed the values more in terms of outcomes than the process. That makes sense — they’re not as intimately involved in the process of building the product.
+We were able to converge on the top priority though: Will the user buy the product? This was a combination of a couple different values that we merged together. This included the end user experience as well as making sure the team would continue to have a reason for existing. The rest of the values we left unordered: Teamwork (cohesiveness), Data driven decisions, Team ownership, Simplicity, Effectiveness, Maintainability / Supportability, Quality, Automation, and Performance. I think that’s a pretty decent list.
+As a couple teammates pointed out, those values are probably in part a reflection of this current point in time. If I asked the same question some other time, under different conditions and team dynamics, the answers would probably change a bit. And we’d probably come up with other answers if asked again, just due to randomness of the way we think about these things.
+But I don’t think I’d do this activity a second time with the team. It was really about understanding our motivations — both our own, and those of our teammates. I found it effective in that way, and also in helping the team to think about our culture and how we can work to shape it to help us all push in the same direction.
+There are a few caveats. When I asked for feedback on the exercise, one teammate pointed out that it wouldn’t work if people weren’t honest about their values, and they answered with what they thought management or their teammates wanted to hear. I don’t think that was an issue with this group, but it’s something to keep in mind.
+The other major thing I’d do is to make it clear up front that I’m not looking for any action items from this activity; it’s more about understanding each other and ourselves. And next time, I’ll work to clarify how to rank the values.
+I would recommend this activity for a new team, or when the makeup of the team is changing in some significant way. I wish there was a way to help a team converge on the ranking of their values, but I suppose I should be happy that agreeing on the set of important values went pretty quickly. And the diversity of ideas and opinions is probably a blessing that I should be embracing — the more ideas we have, the wider the variety of solutions we can imagine.
+It’s that time of year again — time for a retrospective on how I did on my goals for the year. I had 5 main goals for 2015:
+I got pretty lucky on this one. My main contract with Mercy got extended several times. Amos and I must have been doing a good job of keeping the customer happy. We even made it through a couple rounds of layoffs. I’m wrapping up the gig at Mercy now. I’m working one day a week there, as the project winds down.
+I also started a new gig this month at CenturyLink. I’m working on a cloud development team. Our current project involves selling WordPress as a service. The manager had been courting me for most of the year. I’m excited about my new role; I’ll be writing about it in a blog post soon.
+I set a goal in 2014 to give my first conference talk. I accomplished that, giving an ambitious talk at RubyConf. I enjoyed having done that, and vowed to do more conference speaking.
+I gave 3 conference talks in 2015. I gave a workshop on HTTP at RailsConf. I talked about immutable infrastructure at Madison+ Ruby. At RubyConf, I gave a talk on a micro-ORM I wrote. I also gave a lightning talk about Agile estimation (#noestimates).
+I was an alternate speaker at Windy City Rails, but did not give my talk on Alternatives to ActiveRecord. I also went to Strange Loop, mainly to see several friends and acquaintances speak.
+I wrote 24 blog articles this year. That’s about one every other week. What really kept me going was participating in a writing pact. When the pact was going, I had a 75% blogging rate. That’s pretty good.
+I’m not so sure about the quality of my blog writing though. I know that practicing writing is supposed to make you better. I know I wrote some really good articles over the past year, but I think I also wrote some articles that weren’t very good. I think sometimes the deadline has caused more harm than good. I’m not really sure what to do about that; perhaps just pushing on is the right answer.
+I’ve taken a lot of notes on the design of my programming language. Any time I learn something interesting about another language, or come up with another idea, I write it down.
+But I haven’t worked on the implementation. (I last worked on the implementation in 2014.) I should be experimenting with some ideas, implementing them to see how they work out. I’ve even kicked around the idea of starting with a Forth variant, just to get something working quickly.
+I haven’t written any articles on my ideas this year either. My notes are pretty extensive, and it would be good to write some articles to help get my thoughts straight.
+I’ve got some things to say about Agile, and want to write a book to express those ideas. I’ve made a start — I’ve got the chapters outlines, and have started on a few chapters. But I haven’t made as much progress as I’d like to. I shared what I’ve got with Amos, and he showed some interest in pairing with me on the writing. Hopefully we’ll work on it together in 2016 and publish it.
+There were a few other accomplishments that weren’t explicitly on my list, but I’d like to call attention to.
+I’ve continued participating on the This Agile Life podcast. I was in 12 of the 33 episodes that were recorded in 2015. I hope to participate in more in 2016. We’re considering scheduling a standard recording night each week, which might help us record more regularly.
+I recently took over as maintainer of Virtus, a library to declare attributes for Ruby model classes. I haven’t done a lot yet, since I’ve been busy with travel, vacation, and holidays. But I hope to catch up with all the pending pull requests and issues in the next month or so.
+The accomplishment I’m most proud of is mentoring for the Roy Clay Sr. Tech Impact program. This is a program begun as a result of the Ferguson protest movement. We’re helping teach kids (from 14 to 25) web design and development. My personal goal was to give these kids an opportunity that they would not have otherwise had. But it turned out that some of them have actually started a business building web sites for small companies. I’m so proud of the progress they’ve made in such a short time; it’s a challenging program.
+I’m pretty happy with my accomplishments this year. I made at least some progress on each of the goals I set. I’ve been thinking about my goals for next year; I’ll write that as a separate blog article next week.
+I facilitated a retrospective today; it was one of the best retros I’ve ever been involved with. I figured out what activities I wanted to do earlier in the morning. They were really quite simple. I wanted to focus on happiness.
+I started with two questions that I’ve used with teams before, to some success (although not so successful for one particular team). The first question I asked was “How happy are you at work?” I had them put a rating from 0 to 10, with 0 meaning they should have quit last week, and 10 meaning they couldn’t imaging being happier at work.
+The answers were mostly 7s and 8s, with a 5 and a 9. The average came to 7.5, which is pretty good. The 5 concerns me a bit, especially that it’s 2 points lower than anyone else’s answer.
+The next question I asked was “How effective do you think the teams is?”. Again, from 0 to 10, with 0 meaning they can’t accomplish anything, and 10 meaning you couldn’t imagine a more effective team.
+When I ask both of these questions, the scores are always highly correlated. If your team isn’t doing good work, it’ll make you unhappy. And if you are unhappy, you’re less likely to do your best work. This team was no different; the 5 and 9 became a 6 and a 10, and most of the 7s became 8s, for an average of just under 8.
+The next question I asked was “What makes you happy at work?”. The answers were mostly about the teamwork and teammates. This went quicker than I expected. At this point, I was worried the retro would only last a little more than 30 minutes.
+The final question I asked was “What would make you happier at work?”. This was the real pay-off. We spent about half an hour just talking about the things that would make us happier, and what we could do to improve our happiness. We came up with 10 potential action items. I usually limit teams to trying 3 or 4 action items, but most of the items are quite small, so we’re going to try 6 of them. One is just observing another team’s standup meetings, to see how they’re using their time effectively.
+Everyone went away feeling that this was a really good retro. It felt good to focus on happiness. Happiness is something I’ve been talking a lot about on the This Agile Life podcast, and it felt good to take some action on it. I’ve done “positive-only” retros before, but this one felt even better than that, by specifically targeting happiness and how we can achieve it.
+I’m surprised that I haven’t gotten this story down in print before. It’s something I’ve mentioned many times — including a few times on the podcast. It’s a great story about the power of retrospectives, and it’s a great story about the power of a blameless post-mortem.
+I don’t recall all the specifics at this point. It was about 5 years ago. I’d just noticed that Arun had made some sort of mistake. That’s fine, people make mistakes. The thing that was different about his mistake was that I had made the same mistake about a week prior. And Amos had made the same mistake about a week before that.
+Noticing a pattern of mistakes, Amos and I called an impromptu retrospective. We gathered all the developers into a conference room. We explained the problem that we were running into. At first, Arun was defensive. That’s understandable; he thought we were there to come down on him, to lay blame. But we made it clear that we weren’t focusing on him. We admitted that we had also made the same mistake recently. We weren’t there to lay blame; we were there to figure out how our team could stop making the mistake. It took Arun a few minutes to get over the defensiveness.
+With the defensiveness out of the way, we could focus on the issue at hand. We were able to figure out the root cause of us all making the mistake. (I don’t know if we played the “5 whys” game, but I’m sure we effectively did something similar.) And with that, we were able to change our process, so that nobody else would make the same mistake again.
+There are 2 important points to this story. First, you don’t have to wait until a scheduled retrospective to hold a retrospective. This one was impromptu, and it’s the best one we ever had. We saw a problem, addressed it, and found a solution in less than an hour. Had we waited until the end of the week, we would have forgotten some of the details, and wouldn’t have been as effective at solving the problem. Second, when addressing problems, take your ego out of the equation. If you’re in a position of authority, take the blame — but never place blame. Focus on what’s important — solving the problem.
+And don’t forget the Retrospective Prime Directive:
++Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
+
I started out with a pretty simple question: “What do you value (in regards to what we’re building); what are you willing to fight for?” I asked them each to write down several values and then put them on the board before looking at everyone else’s answers. I also asked each person to rank their values in order of importance.
+It turned out that my question was a little vague. Some people thought about the question in terms of the end result, and some in terms of the process of creating the software. In some ways that was a bit of a problem, because the different interpretations led people in different directions. But in other ways, not pushing them in any particular direction got more varied answers, exposing how they think about the project and the product.
+My list (in order) was Effectiveness (doing the right thing), Quality (doing things right the first time), Happiness, Purpose, and Teamwork. In retrospect, I should have put Happiness first. If I’m not happy at work, I don’t really want to be there, and need to move on. (Sometimes I can trade some happiness at work for more happiness at home, but I’m definitely a person that needs to be happy at work.) The other values serve to improve my happiness, but the happiness is more important.
+My own issue ranking my values turned out to be a problem with the ranking in general. Should they be ranked in importance of the necessity of the value as an outcome, or in importance of the necessity to focus on the value? I think the former is what I was looking for, but even I wasn’t clear on that when I began the exercise.
+After everyone put their values up on the board, we read them off. Then I asked the team to choose several values that we share as a team. We pulled them off the individual members’ lists, and put them in the team list. Then I asked each person to come up and rank those values, then explain why they had ordered them that way, especially when they ordered them significantly different than the last person. I was hoping to come to some convergence of the rank over time, so we could document our values in rank order. That didn’t happen. But the discussion was illuminating to me and to everyone on the team.
+I think the most interesting part about the lack of convergence was the difference between the developers and the product guys. The product guys definitely viewed the values more in terms of outcomes than the process. That makes sense — they’re not as intimately involved in the process of building the product.
+We were able to converge on the top priority though: Will the user buy the product? This was a combination of a couple different values that we merged together. This included the end user experience as well as making sure the team would continue to have a reason for existing. The rest of the values we left unordered: Teamwork (cohesiveness), Data driven decisions, Team ownership, Simplicity, Effectiveness, Maintainability / Supportability, Quality, Automation, and Performance. I think that’s a pretty decent list.
+As a couple teammates pointed out, those values are probably in part a reflection of this current point in time. If I asked the same question some other time, under different conditions and team dynamics, the answers would probably change a bit. And we’d probably come up with other answers if asked again, just due to randomness of the way we think about these things.
+But I don’t think I’d do this activity a second time with the team. It was really about understanding our motivations — both our own, and those of our teammates. I found it effective in that way, and also in helping the team to think about our culture and how we can work to shape it to help us all push in the same direction.
+There are a few caveats. When I asked for feedback on the exercise, one teammate pointed out that it wouldn’t work if people weren’t honest about their values, and they answered with what they thought management or their teammates wanted to hear. I don’t think that was an issue with this group, but it’s something to keep in mind.
+The other major thing I’d do is to make it clear up front that I’m not looking for any action items from this activity; it’s more about understanding each other and ourselves. And next time, I’ll work to clarify how to rank the values.
+I would recommend this activity for a new team, or when the makeup of the team is changing in some significant way. I wish there was a way to help a team converge on the ranking of their values, but I suppose I should be happy that agreeing on the set of important values went pretty quickly. And the diversity of ideas and opinions is probably a blessing that I should be embracing — the more ideas we have, the wider the variety of solutions we can imagine.
+]]>I got pretty lucky on this one. My main contract with Mercy got extended several times. Amos and I must have been doing a good job of keeping the customer happy. We even made it through a couple rounds of layoffs. I’m wrapping up the gig at Mercy now. I’m working one day a week there, as the project winds down.
+I also started a new gig this month at CenturyLink. I’m working on a cloud development team. Our current project involves selling WordPress as a service. The manager had been courting me for most of the year. I’m excited about my new role; I’ll be writing about it in a blog post soon.
+I set a goal in 2014 to give my first conference talk. I accomplished that, giving an ambitious talk at RubyConf. I enjoyed having done that, and vowed to do more conference speaking.
+I gave 3 conference talks in 2015. I gave a workshop on HTTP at RailsConf. I talked about immutable infrastructure at Madison+ Ruby. At RubyConf, I gave a talk on a micro-ORM I wrote. I also gave a lightning talk about Agile estimation (#noestimates).
+I was an alternate speaker at Windy City Rails, but did not give my talk on Alternatives to ActiveRecord. I also went to Strange Loop, mainly to see several friends and acquaintances speak.
+I wrote 24 blog articles this year. That’s about one every other week. What really kept me going was participating in a writing pact. When the pact was going, I had a 75% blogging rate. That’s pretty good.
+I’m not so sure about the quality of my blog writing though. I know that practicing writing is supposed to make you better. I know I wrote some really good articles over the past year, but I think I also wrote some articles that weren’t very good. I think sometimes the deadline has caused more harm than good. I’m not really sure what to do about that; perhaps just pushing on is the right answer.
+I’ve taken a lot of notes on the design of my programming language. Any time I learn something interesting about another language, or come up with another idea, I write it down.
+But I haven’t worked on the implementation. (I last worked on the implementation in 2014.) I should be experimenting with some ideas, implementing them to see how they work out. I’ve even kicked around the idea of starting with a Forth variant, just to get something working quickly.
+I haven’t written any articles on my ideas this year either. My notes are pretty extensive, and it would be good to write some articles to help get my thoughts straight.
+I’ve got some things to say about Agile, and want to write a book to express those ideas. I’ve made a start — I’ve got the chapters outlines, and have started on a few chapters. But I haven’t made as much progress as I’d like to. I shared what I’ve got with Amos, and he showed some interest in pairing with me on the writing. Hopefully we’ll work on it together in 2016 and publish it.
+There were a few other accomplishments that weren’t explicitly on my list, but I’d like to call attention to.
+I’ve continued participating on the This Agile Life podcast. I was in 12 of the 33 episodes that were recorded in 2015. I hope to participate in more in 2016. We’re considering scheduling a standard recording night each week, which might help us record more regularly.
+I recently took over as maintainer of Virtus, a library to declare attributes for Ruby model classes. I haven’t done a lot yet, since I’ve been busy with travel, vacation, and holidays. But I hope to catch up with all the pending pull requests and issues in the next month or so.
+The accomplishment I’m most proud of is mentoring for the Roy Clay Sr. Tech Impact program. This is a program begun as a result of the Ferguson protest movement. We’re helping teach kids (from 14 to 25) web design and development. My personal goal was to give these kids an opportunity that they would not have otherwise had. But it turned out that some of them have actually started a business building web sites for small companies. I’m so proud of the progress they’ve made in such a short time; it’s a challenging program.
+I’m pretty happy with my accomplishments this year. I made at least some progress on each of the goals I set. I’ve been thinking about my goals for next year; I’ll write that as a separate blog article next week.
+]]>I started with two questions that I’ve used with teams before, to some success (although not so successful for one particular team). The first question I asked was “How happy are you at work?” I had them put a rating from 0 to 10, with 0 meaning they should have quit last week, and 10 meaning they couldn’t imaging being happier at work.
+The answers were mostly 7s and 8s, with a 5 and a 9. The average came to 7.5, which is pretty good. The 5 concerns me a bit, especially that it’s 2 points lower than anyone else’s answer.
+The next question I asked was “How effective do you think the teams is?”. Again, from 0 to 10, with 0 meaning they can’t accomplish anything, and 10 meaning you couldn’t imagine a more effective team.
+When I ask both of these questions, the scores are always highly correlated. If your team isn’t doing good work, it’ll make you unhappy. And if you are unhappy, you’re less likely to do your best work. This team was no different; the 5 and 9 became a 6 and a 10, and most of the 7s became 8s, for an average of just under 8.
+The next question I asked was “What makes you happy at work?”. The answers were mostly about the teamwork and teammates. This went quicker than I expected. At this point, I was worried the retro would only last a little more than 30 minutes.
+The final question I asked was “What would make you happier at work?”. This was the real pay-off. We spent about half an hour just talking about the things that would make us happier, and what we could do to improve our happiness. We came up with 10 potential action items. I usually limit teams to trying 3 or 4 action items, but most of the items are quite small, so we’re going to try 6 of them. One is just observing another team’s standup meetings, to see how they’re using their time effectively.
+Everyone went away feeling that this was a really good retro. It felt good to focus on happiness. Happiness is something I’ve been talking a lot about on the This Agile Life podcast, and it felt good to take some action on it. I’ve done “positive-only” retros before, but this one felt even better than that, by specifically targeting happiness and how we can achieve it.
+]]>I don’t recall all the specifics at this point. It was about 5 years ago. I’d just noticed that Arun had made some sort of mistake. That’s fine, people make mistakes. The thing that was different about his mistake was that I had made the same mistake about a week prior. And Amos had made the same mistake about a week before that.
+Noticing a pattern of mistakes, Amos and I called an impromptu retrospective. We gathered all the developers into a conference room. We explained the problem that we were running into. At first, Arun was defensive. That’s understandable; he thought we were there to come down on him, to lay blame. But we made it clear that we weren’t focusing on him. We admitted that we had also made the same mistake recently. We weren’t there to lay blame; we were there to figure out how our team could stop making the mistake. It took Arun a few minutes to get over the defensiveness.
+With the defensiveness out of the way, we could focus on the issue at hand. We were able to figure out the root cause of us all making the mistake. (I don’t know if we played the “5 whys” game, but I’m sure we effectively did something similar.) And with that, we were able to change our process, so that nobody else would make the same mistake again.
+There are 2 important points to this story. First, you don’t have to wait until a scheduled retrospective to hold a retrospective. This one was impromptu, and it’s the best one we ever had. We saw a problem, addressed it, and found a solution in less than an hour. Had we waited until the end of the week, we would have forgotten some of the details, and wouldn’t have been as effective at solving the problem. Second, when addressing problems, take your ego out of the equation. If you’re in a position of authority, take the blame — but never place blame. Focus on what’s important — solving the problem.
+And don’t forget the Retrospective Prime Directive:
++Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
+]]>
Web Development, Ruby on Rails, Open Source
+On a recent episode (78) of This Agile Life, my fellow hosts talked about when to do Test-Driven Development (TDD). They all said that you should always do TDD — at least for anything that will go into production; there’s an exception for experimenting or “spiking”.
+I wasn’t on that episode, but later commented on the topic. (Episode 83 — which wasn’t really all that great.) My take was slightly different. I said that you should do TDD only when the benefits outweigh the costs. Unfortunately, we usually greatly underestimate the benefits. And the costs often seem high at first, because it takes some time to get good at writing automated tests. Not to mention that both the costs and the benefits are usually hard to measure.
+What is the cost of writing automated tests? I’ve asked this question before and recorded the answers (inasmuch as we have them) in a previous blog entry. TDD costs us about 10-30% in short-term productivity. The benefit that they found was a reduction in bugs by 30-90%, and a decrease in code complexity by about 30%.
+But what about when the costs are higher than the normal 10 to 30 percent? One good example of this is when there’s no test framework for the situation you’re testing. This might be a new language or framework that you’re working with. More likely it’s a complex API that you have to mock out. So that could increase the cost of automated testing so as to outweigh the benefits — especially on a short project. I could imagine situations where the cost of writing the mocks could eat up more than the project itself.
+Another case where we might consider skipping testing is when we’re more concerned about time to market than quality. This is almost always a mistake. Your code will almost always last longer than you expect. (Remember Y2K?) And if the code lasts longer than you expect, that means you’ll have to deal with bugs that whole time. But we have to work with the information we have at the time we make our decisions. And sometimes that might tell us that time to market is more important than anything.
+One final case I can imagine is when a true expert is coding something that they’re very familiar with. I could picture someone like Uncle Bob writing code (in a language that he’s familiar with) without tests just as effectively as I could write code with tests.
+But these situations should not be common; they’re edge cases. In almost all real-world cases, TDD is the right thing to do. Don’t forget, TDD is also a design discipline — it helps you design a better API. So keep doing TDD. But as with any practice, don’t do it blindly without considering why we’re doing it. Make sure you understand the costs, and whether the benefits outweigh the costs.
+I went to RailsConf this year, and the very first talk was a keynote by David Heinemeier Hansson (DHH), the creator of Ruby on Rails. The TL;DR of his talk was “TDD rarely has value”. He followed up with a blog post the next day, titled “TDD is dead. Long live testing.“, and 2 more posts. I think this line of thought is terribly misguided, and causing more harm than good. This article is my response.
+First, I would like to address the good points of the talk. He said that programming is pseudoscience, and that people want to tell us that there’s a secret to being a better programmer. But what it really takes is working hard — reading a lot of code, writing a lot of code, and rewriting a lot of code. He’s right. And I also agree with him that you should forget about patterns for a while when learning to code. Beginners try to throw patterns at a problem instead of letting the patterns emerge where they’re supposed to.
+I don’t completely agree that programming is a pseudoscience. In some ways it is, but I think it’s more of a craft. It’s a craft, because there’s a lot of science involved, but there’s also an art to doing it well. And like any craft, you’re always working to get better. So to respond to DHH’s stance that “software is more like poetry than physics”, I think it falls
+somewhere in between.
With regard to the software engineering practices we use, there really isn’t much science available, mostly because it’s a soft science. That is, it’s really hard to isolate a single variable when comparing code between projects. And nobody has the time or money to write the same code so many times that the differences would be statistically significant.
+So we don’t have much science on TDD. But we do have some. Here’s a collection of several: StudiesOfTestDrivenDevelopment. And here’s one that explicitly looks are the difference between test-first and test-last: Does Test-Driven Development Really Improve Software Design Quality? What do these tell us? They tell us that TDD costs us about 10-30% in short-term productivity; reduces bugs by 30-90%, and decreases code complexity by about 30%. As Code Complete tells us (in section 20.5, with studies to back it up), improving quality reduces development costs. So, like most Agile practices, this is a case where spending a bit more time in the short term leads to time savings in the long term.
+The more important lesson in the talk was that you have to do what works best for you and your situation. If TDD doesn’t give better results, then either find out how to make it give better results, or stop using it. As we often say in the Agile world, Agile doesn’t mean that you can stop using your brain. While I think TDD is appropriate in most situations, there are cases where it’s not worth the additional up-front cost. If the most important thing for your project is time-to-market, then not testing might be the right decision for you.
+To me, TDD provides a bunch of benefits. First and foremost, TDD is a design discipline. It ensures that I think about how my code will be used before I think about how to implement it. This is very powerful in ensuring that the code is well-written from the perspective of other code using it.
+Tested code provides confidence to be able to make changes without breaking things. If we write tests after the code, we’re less likely to write them. Tests written after the code also tend to test the implementation instead of the desired functionality. What we really want is tests written as a specification. With tests as a specification, we can come back later and understand why code was written. Without tests, or with poor tests, we can’t understand why the code is there; if we want to rewrite it, we don’t have the confidence that we’re not missing something. Writing tests first also ensures that we only write the code that is needed to implement the required functionality.
+I’m not sure why DHH hasn’t “gotten” TDD. I’m not sure if it’s because he’s a better coder than average, or if he just thinks in a different way than most of us. I think it’s partly because he doesn’t understand TDD, which he admitted might be the case. And I think he’s conflating TDD and unit testing.
+DHH is influential in the developer community, especially those newer to Ruby and Rails. People listen to what he has to say. I was happy to see almost every other speaker made fun of DHH’s ideas, and most of the crowd knew better. But there will be a lot of others who will hear DHH, respect his opinions, and not give TDD the try that it deserves. And that’s sad, because it will lead to an overall reduction in code quality in the world.
+Here are some other people’s thoughts on the matter:
++
It’s challenging to test Rails custom validators.
+I recently had to write a validator to require that an entered date is before or after a specified date.
+It didn’t seem like writing the validator would be too difficult – I’ve written custom validators before, and date comparisons aren’t all that tricky. But when it came time to write the tests, I ran into several issues. And since I always try to follow TDD / test-first, I was blocked before I even began.
+The biggest issue was the ActiveModel::EachValidator#validates_each API. It’s definitely not a well-designed API. You write your validator as a subclass, overriding validates_each. The method takes a model object, the name of the attribute of the model being tested, and the value of that attribute. You can also get the options passed to the custom validator via the options method. To perform a validation, you have to update the model’s errors hash.
The big flaw in the API is that instead of returning a result, you have to update the model. This needlessly couples the model and the validator. And it violates the Single Responsibility Principle — it has to determine validity of the field, and it has to update the errors hash of the model. This is not conducive to testing. Testing this method requires testing that the side-effect has taken place in the collaborator (model), which means it’s not really a unit test any more.
So to make it easier to unit test the validator, I broke the coupling by breaking it into 2 pieces, one for each responsibility. I moved the responsibility for determining validity to a separate method, which I called errors_for. It returns a hash of the errors found. This simplified the validates_each method to simply take the result of errors_for and update the errors hash of the model:
def validate_each(record, attribute_name, attribute_value) + record.errors[attribute_name].concat(errors_for(attribute_value, options)) +end+
This made it much easier to unit test the errors_for method. This method doesn’t even need to know about the model — only about the value of the attribute we’re trying to validate. We simply pass in the attribute’s value and the options.
So we could write the tests without even pulling in ActiveRecord or any models:
+describe DateValidator do
+ let(:validator) { DateValidator.new(attributes: :attribute_name) }
+ let(:errors) { validator.errors_for(attribute_value, validation_options) }
+
+ describe 'when attribute value is NOT a valid date' do
+ let(:attribute_value) { 'not a valid date' }
+ it { errors.must_include 'is not a valid date' }
+ end
+
+ describe 'when attribute value IS a valid date' do
+ let(:attribute_value) { Date.parse('2013-12-11') }
+ it { errors.must_be :empty? }
+ end
+end
+And the errors_for method looked something like this:
def errors_for(attribute_value, options) + unless attribute_value.is_a?(Date) + return [options.fetch(:message, "is not a valid date")] + end + [] +end+
Integration testing can also be a bit of a challenge. I recommend following the example from this Stack Overflow answer. Basically, create a minimal model object that contains the field and the validation. Then test that the model behaves like you expect with different values and validations.
+I wasn’t on that episode, but later commented on the topic. (Episode 83 — which wasn’t really all that great.) My take was slightly different. I said that you should do TDD only when the benefits outweigh the costs. Unfortunately, we usually greatly underestimate the benefits. And the costs often seem high at first, because it takes some time to get good at writing automated tests. Not to mention that both the costs and the benefits are usually hard to measure.
+What is the cost of writing automated tests? I’ve asked this question before and recorded the answers (inasmuch as we have them) in a previous blog entry. TDD costs us about 10-30% in short-term productivity. The benefit that they found was a reduction in bugs by 30-90%, and a decrease in code complexity by about 30%.
+But what about when the costs are higher than the normal 10 to 30 percent? One good example of this is when there’s no test framework for the situation you’re testing. This might be a new language or framework that you’re working with. More likely it’s a complex API that you have to mock out. So that could increase the cost of automated testing so as to outweigh the benefits — especially on a short project. I could imagine situations where the cost of writing the mocks could eat up more than the project itself.
+Another case where we might consider skipping testing is when we’re more concerned about time to market than quality. This is almost always a mistake. Your code will almost always last longer than you expect. (Remember Y2K?) And if the code lasts longer than you expect, that means you’ll have to deal with bugs that whole time. But we have to work with the information we have at the time we make our decisions. And sometimes that might tell us that time to market is more important than anything.
+One final case I can imagine is when a true expert is coding something that they’re very familiar with. I could picture someone like Uncle Bob writing code (in a language that he’s familiar with) without tests just as effectively as I could write code with tests.
+But these situations should not be common; they’re edge cases. In almost all real-world cases, TDD is the right thing to do. Don’t forget, TDD is also a design discipline — it helps you design a better API. So keep doing TDD. But as with any practice, don’t do it blindly without considering why we’re doing it. Make sure you understand the costs, and whether the benefits outweigh the costs.
+]]>First, I would like to address the good points of the talk. He said that programming is pseudoscience, and that people want to tell us that there’s a secret to being a better programmer. But what it really takes is working hard — reading a lot of code, writing a lot of code, and rewriting a lot of code. He’s right. And I also agree with him that you should forget about patterns for a while when learning to code. Beginners try to throw patterns at a problem instead of letting the patterns emerge where they’re supposed to.
+I don’t completely agree that programming is a pseudoscience. In some ways it is, but I think it’s more of a craft. It’s a craft, because there’s a lot of science involved, but there’s also an art to doing it well. And like any craft, you’re always working to get better. So to respond to DHH’s stance that “software is more like poetry than physics”, I think it falls
+somewhere in between.
With regard to the software engineering practices we use, there really isn’t much science available, mostly because it’s a soft science. That is, it’s really hard to isolate a single variable when comparing code between projects. And nobody has the time or money to write the same code so many times that the differences would be statistically significant.
+So we don’t have much science on TDD. But we do have some. Here’s a collection of several: StudiesOfTestDrivenDevelopment. And here’s one that explicitly looks are the difference between test-first and test-last: Does Test-Driven Development Really Improve Software Design Quality? What do these tell us? They tell us that TDD costs us about 10-30% in short-term productivity; reduces bugs by 30-90%, and decreases code complexity by about 30%. As Code Complete tells us (in section 20.5, with studies to back it up), improving quality reduces development costs. So, like most Agile practices, this is a case where spending a bit more time in the short term leads to time savings in the long term.
+The more important lesson in the talk was that you have to do what works best for you and your situation. If TDD doesn’t give better results, then either find out how to make it give better results, or stop using it. As we often say in the Agile world, Agile doesn’t mean that you can stop using your brain. While I think TDD is appropriate in most situations, there are cases where it’s not worth the additional up-front cost. If the most important thing for your project is time-to-market, then not testing might be the right decision for you.
+To me, TDD provides a bunch of benefits. First and foremost, TDD is a design discipline. It ensures that I think about how my code will be used before I think about how to implement it. This is very powerful in ensuring that the code is well-written from the perspective of other code using it.
+Tested code provides confidence to be able to make changes without breaking things. If we write tests after the code, we’re less likely to write them. Tests written after the code also tend to test the implementation instead of the desired functionality. What we really want is tests written as a specification. With tests as a specification, we can come back later and understand why code was written. Without tests, or with poor tests, we can’t understand why the code is there; if we want to rewrite it, we don’t have the confidence that we’re not missing something. Writing tests first also ensures that we only write the code that is needed to implement the required functionality.
+I’m not sure why DHH hasn’t “gotten” TDD. I’m not sure if it’s because he’s a better coder than average, or if he just thinks in a different way than most of us. I think it’s partly because he doesn’t understand TDD, which he admitted might be the case. And I think he’s conflating TDD and unit testing.
+DHH is influential in the developer community, especially those newer to Ruby and Rails. People listen to what he has to say. I was happy to see almost every other speaker made fun of DHH’s ideas, and most of the crowd knew better. But there will be a lot of others who will hear DHH, respect his opinions, and not give TDD the try that it deserves. And that’s sad, because it will lead to an overall reduction in code quality in the world.
+Here are some other people’s thoughts on the matter:
++]]>
I recently had to write a validator to require that an entered date is before or after a specified date.
+It didn’t seem like writing the validator would be too difficult – I’ve written custom validators before, and date comparisons aren’t all that tricky. But when it came time to write the tests, I ran into several issues. And since I always try to follow TDD / test-first, I was blocked before I even began.
+The biggest issue was the ActiveModel::EachValidator#validates_each API. It’s definitely not a well-designed API. You write your validator as a subclass, overriding validates_each. The method takes a model object, the name of the attribute of the model being tested, and the value of that attribute. You can also get the options passed to the custom validator via the options method. To perform a validation, you have to update the model’s errors hash.
The big flaw in the API is that instead of returning a result, you have to update the model. This needlessly couples the model and the validator. And it violates the Single Responsibility Principle — it has to determine validity of the field, and it has to update the errors hash of the model. This is not conducive to testing. Testing this method requires testing that the side-effect has taken place in the collaborator (model), which means it’s not really a unit test any more.
So to make it easier to unit test the validator, I broke the coupling by breaking it into 2 pieces, one for each responsibility. I moved the responsibility for determining validity to a separate method, which I called errors_for. It returns a hash of the errors found. This simplified the validates_each method to simply take the result of errors_for and update the errors hash of the model:
def validate_each(record, attribute_name, attribute_value) + record.errors[attribute_name].concat(errors_for(attribute_value, options)) +end+
This made it much easier to unit test the errors_for method. This method doesn’t even need to know about the model — only about the value of the attribute we’re trying to validate. We simply pass in the attribute’s value and the options.
So we could write the tests without even pulling in ActiveRecord or any models:
+describe DateValidator do
+ let(:validator) { DateValidator.new(attributes: :attribute_name) }
+ let(:errors) { validator.errors_for(attribute_value, validation_options) }
+
+ describe 'when attribute value is NOT a valid date' do
+ let(:attribute_value) { 'not a valid date' }
+ it { errors.must_include 'is not a valid date' }
+ end
+
+ describe 'when attribute value IS a valid date' do
+ let(:attribute_value) { Date.parse('2013-12-11') }
+ it { errors.must_be :empty? }
+ end
+end
+And the errors_for method looked something like this:
def errors_for(attribute_value, options) + unless attribute_value.is_a?(Date) + return [options.fetch(:message, "is not a valid date")] + end + [] +end+
Integration testing can also be a bit of a challenge. I recommend following the example from this Stack Overflow answer. Basically, create a minimal model object that contains the field and the validation. Then test that the model behaves like you expect with different values and validations.
+]]>Web Development, Ruby on Rails, Open Source
+It’s that time of year again — time for a retrospective on how I did on my goals for the year. I had 5 main goals for 2015:
+I got pretty lucky on this one. My main contract with Mercy got extended several times. Amos and I must have been doing a good job of keeping the customer happy. We even made it through a couple rounds of layoffs. I’m wrapping up the gig at Mercy now. I’m working one day a week there, as the project winds down.
+I also started a new gig this month at CenturyLink. I’m working on a cloud development team. Our current project involves selling WordPress as a service. The manager had been courting me for most of the year. I’m excited about my new role; I’ll be writing about it in a blog post soon.
+I set a goal in 2014 to give my first conference talk. I accomplished that, giving an ambitious talk at RubyConf. I enjoyed having done that, and vowed to do more conference speaking.
+I gave 3 conference talks in 2015. I gave a workshop on HTTP at RailsConf. I talked about immutable infrastructure at Madison+ Ruby. At RubyConf, I gave a talk on a micro-ORM I wrote. I also gave a lightning talk about Agile estimation (#noestimates).
+I was an alternate speaker at Windy City Rails, but did not give my talk on Alternatives to ActiveRecord. I also went to Strange Loop, mainly to see several friends and acquaintances speak.
+I wrote 24 blog articles this year. That’s about one every other week. What really kept me going was participating in a writing pact. When the pact was going, I had a 75% blogging rate. That’s pretty good.
+I’m not so sure about the quality of my blog writing though. I know that practicing writing is supposed to make you better. I know I wrote some really good articles over the past year, but I think I also wrote some articles that weren’t very good. I think sometimes the deadline has caused more harm than good. I’m not really sure what to do about that; perhaps just pushing on is the right answer.
+I’ve taken a lot of notes on the design of my programming language. Any time I learn something interesting about another language, or come up with another idea, I write it down.
+But I haven’t worked on the implementation. (I last worked on the implementation in 2014.) I should be experimenting with some ideas, implementing them to see how they work out. I’ve even kicked around the idea of starting with a Forth variant, just to get something working quickly.
+I haven’t written any articles on my ideas this year either. My notes are pretty extensive, and it would be good to write some articles to help get my thoughts straight.
+I’ve got some things to say about Agile, and want to write a book to express those ideas. I’ve made a start — I’ve got the chapters outlines, and have started on a few chapters. But I haven’t made as much progress as I’d like to. I shared what I’ve got with Amos, and he showed some interest in pairing with me on the writing. Hopefully we’ll work on it together in 2016 and publish it.
+There were a few other accomplishments that weren’t explicitly on my list, but I’d like to call attention to.
+I’ve continued participating on the This Agile Life podcast. I was in 12 of the 33 episodes that were recorded in 2015. I hope to participate in more in 2016. We’re considering scheduling a standard recording night each week, which might help us record more regularly.
+I recently took over as maintainer of Virtus, a library to declare attributes for Ruby model classes. I haven’t done a lot yet, since I’ve been busy with travel, vacation, and holidays. But I hope to catch up with all the pending pull requests and issues in the next month or so.
+The accomplishment I’m most proud of is mentoring for the Roy Clay Sr. Tech Impact program. This is a program begun as a result of the Ferguson protest movement. We’re helping teach kids (from 14 to 25) web design and development. My personal goal was to give these kids an opportunity that they would not have otherwise had. But it turned out that some of them have actually started a business building web sites for small companies. I’m so proud of the progress they’ve made in such a short time; it’s a challenging program.
+I’m pretty happy with my accomplishments this year. I made at least some progress on each of the goals I set. I’ve been thinking about my goals for next year; I’ll write that as a separate blog article next week.
+January kept me pretty busy, so I’m a little late to this. But better late than never. And as an Agile practitioner, I don’t think personal retrospectives should be limited to one time of year.
+Last year I wrote a blog entry listing my goals for 2014. As far as New Year’s resolutions go, I was relatively successful — about 50% of my goals accomplished. Unfortunately, my Open Source contributions weren’t as strong as I had hoped; while I released some of my own work, I didn’t do much else. I did increase my blogging; getting in on a weekly blogging pact helped immensely. I also increased my participation on the This Agile Life podcast to a level that I’m happy with. But the accomplishment I’m most proud of was giving a presentation at RubyConf.
+I’d like to keep things rolling from last year, but crank up a few things. My plans are quite ambitious, so I don’t expect to get everything done by any means. But I think by setting the bar high, I’ll end up with a lot I can be proud of.
+Late last year, I took the jump into independent consulting. So far, I’ve really enjoyed it, and I’m booked up through April. My wife graduates in May, so we’ve got the possibility of moving if that makes sense. So I’ll be looking for consulting projects in town, but I’ll also be looking at jobs in San Francisco and Chicago. The possibilities are exciting, and I’ll be taking my time to find something just right.
+I was incredibly nervous leading up to my RubyConf presentation. Part of that was just the common fear of public speaking. For me, that only kicks in at around 100 people, and this audience was around 250. I think another reason was that I chose a really ambitious topic, and I kept finding more that I wanted to talk about, but wasn’t prepared for. But I think I did a pretty good job presenting an advanced topic. And I was so pumped by the sense of accomplishment as soon as I finished. So I’m hoping to do it more. I’ve already submitted a couple proposals, and plan to submit several more.
+I believe that blogging is important for me to get my thoughts down — for myself and to share with others. I was really successful last year when I had a partner to keep me honest, via a pact. So I’ve started up another pact this year, which will hopefully ensure I’ll keep things going. I’ve got a really long backlog of topics, so as long as I keep at it, I’ll have plenty to write about.
+I also want to move away from WordPress to a static system — probably Middleman. I’ve got 2 major problems with WordPress. First, I no longer trust its security, nor the security of any application written in PHP. Second, it generates HTML every time someone requests a page, instead of when the content is updated. I find that to be a waste of resources, and problematic from a security standpoint. The main problem with moving to a static blogging system is that I really want to allow comments, pingbacks, and tweetbacks. So I’ll have to find a way to integrate those.
+Last year I started thinking about programming language design, and started implementing a language tentatively called Brilliant. I’ve done a lot more thinking on the topic, and have a lot of notes. But I haven’t implemented much more yet. This year, I’d like to get my thoughts more organized, and write a series of blog posts on various aspects of language design. The most interesting part seems to be the trade-offs involved in the ways that various language features interact. So I’d like to make some progress on the language implementation, but more importantly, I’d like to get a lot of my design ideas written down.
+I’m also going to spend a lot of time learning a bunch more programming languages, so I have a better understanding of possible features, combinations of features, and their interactions. I’ve already start with Elixir, Clojure, and Racket. I’m hoping to also look at OCaml, Factor, and Haskell. I’ll probably also take a look at the 2 “Seven Languages in Seven Weeks” books.
+I think people often have trouble getting started with Agile. I started on a book last year, and got down quite a lot of good ideas. But I realized that I’m going to have a hard time organizing all those ideas into something coherent. Still, I’d like to try to get something out there that lets people get started with Agile. My idea is to present a toolbox of practices to get started with and build on that foundation over time with additional practices. Sort of a playbook on how to get started over the first 6 to 12 months and be successful. I want to make some progress on the book, at least enough to decide whether it’s worth the effort to finish it and self-publish it.
++
I’m considering moving away from WordPress, for a couple reasons:
+Now that I’m starting to actually blog consistently, it makes sense to change. But before I move to something different, I want to be sure that I find all the features that I need. This post is my thought process about what I want.
+I’ve been playing with Jekyll lately, using it to generate a simple static site that can be updated easily. It’s pretty nice, and pretty easy to use. Something based on Jekyll would work well. The trickiest part will be figuring out how to manage comments. Or maybe I’ll just have to learn to live more minimally.
+Octopress is the obvious candidate. It fits most of my needs and wants. Most likely I’ll write my own commenting engine and add it to my Octopress template.
+The only other candidate that I’ve found is Ghost. It’s written in JavaScript and runs on Node. I don’t find Node to be that compelling, but the templates look great, and it’s designed for coding blogs.
+I’ll probably take a quick look at Droplets, too. It’s written in PHP, but seems to fit my other requirements.
+Unfortunately, that seems to be all there is in this space. Maybe I need to investigate more. Or maybe Octopress just has the static blog generation marked cornered. Either way, I’ll probably change my blogging software in the next month or two. Wish me luck!
++
Welcome to the BoochTek blog. BoochTek, LLC is a small web development company, based in St. Louis, Missouri. We specialize in Ruby on Rails, jQuery (JavaScript), and PHP.
+This bog will be a place where we can share some of our experiences in web development, Open Source, programming, and technology in general.
+I got pretty lucky on this one. My main contract with Mercy got extended several times. Amos and I must have been doing a good job of keeping the customer happy. We even made it through a couple rounds of layoffs. I’m wrapping up the gig at Mercy now. I’m working one day a week there, as the project winds down.
+I also started a new gig this month at CenturyLink. I’m working on a cloud development team. Our current project involves selling WordPress as a service. The manager had been courting me for most of the year. I’m excited about my new role; I’ll be writing about it in a blog post soon.
+I set a goal in 2014 to give my first conference talk. I accomplished that, giving an ambitious talk at RubyConf. I enjoyed having done that, and vowed to do more conference speaking.
+I gave 3 conference talks in 2015. I gave a workshop on HTTP at RailsConf. I talked about immutable infrastructure at Madison+ Ruby. At RubyConf, I gave a talk on a micro-ORM I wrote. I also gave a lightning talk about Agile estimation (#noestimates).
+I was an alternate speaker at Windy City Rails, but did not give my talk on Alternatives to ActiveRecord. I also went to Strange Loop, mainly to see several friends and acquaintances speak.
+I wrote 24 blog articles this year. That’s about one every other week. What really kept me going was participating in a writing pact. When the pact was going, I had a 75% blogging rate. That’s pretty good.
+I’m not so sure about the quality of my blog writing though. I know that practicing writing is supposed to make you better. I know I wrote some really good articles over the past year, but I think I also wrote some articles that weren’t very good. I think sometimes the deadline has caused more harm than good. I’m not really sure what to do about that; perhaps just pushing on is the right answer.
+I’ve taken a lot of notes on the design of my programming language. Any time I learn something interesting about another language, or come up with another idea, I write it down.
+But I haven’t worked on the implementation. (I last worked on the implementation in 2014.) I should be experimenting with some ideas, implementing them to see how they work out. I’ve even kicked around the idea of starting with a Forth variant, just to get something working quickly.
+I haven’t written any articles on my ideas this year either. My notes are pretty extensive, and it would be good to write some articles to help get my thoughts straight.
+I’ve got some things to say about Agile, and want to write a book to express those ideas. I’ve made a start — I’ve got the chapters outlines, and have started on a few chapters. But I haven’t made as much progress as I’d like to. I shared what I’ve got with Amos, and he showed some interest in pairing with me on the writing. Hopefully we’ll work on it together in 2016 and publish it.
+There were a few other accomplishments that weren’t explicitly on my list, but I’d like to call attention to.
+I’ve continued participating on the This Agile Life podcast. I was in 12 of the 33 episodes that were recorded in 2015. I hope to participate in more in 2016. We’re considering scheduling a standard recording night each week, which might help us record more regularly.
+I recently took over as maintainer of Virtus, a library to declare attributes for Ruby model classes. I haven’t done a lot yet, since I’ve been busy with travel, vacation, and holidays. But I hope to catch up with all the pending pull requests and issues in the next month or so.
+The accomplishment I’m most proud of is mentoring for the Roy Clay Sr. Tech Impact program. This is a program begun as a result of the Ferguson protest movement. We’re helping teach kids (from 14 to 25) web design and development. My personal goal was to give these kids an opportunity that they would not have otherwise had. But it turned out that some of them have actually started a business building web sites for small companies. I’m so proud of the progress they’ve made in such a short time; it’s a challenging program.
+I’m pretty happy with my accomplishments this year. I made at least some progress on each of the goals I set. I’ve been thinking about my goals for next year; I’ll write that as a separate blog article next week.
+]]>Last year I wrote a blog entry listing my goals for 2014. As far as New Year’s resolutions go, I was relatively successful — about 50% of my goals accomplished. Unfortunately, my Open Source contributions weren’t as strong as I had hoped; while I released some of my own work, I didn’t do much else. I did increase my blogging; getting in on a weekly blogging pact helped immensely. I also increased my participation on the This Agile Life podcast to a level that I’m happy with. But the accomplishment I’m most proud of was giving a presentation at RubyConf.
+I’d like to keep things rolling from last year, but crank up a few things. My plans are quite ambitious, so I don’t expect to get everything done by any means. But I think by setting the bar high, I’ll end up with a lot I can be proud of.
+Late last year, I took the jump into independent consulting. So far, I’ve really enjoyed it, and I’m booked up through April. My wife graduates in May, so we’ve got the possibility of moving if that makes sense. So I’ll be looking for consulting projects in town, but I’ll also be looking at jobs in San Francisco and Chicago. The possibilities are exciting, and I’ll be taking my time to find something just right.
+I was incredibly nervous leading up to my RubyConf presentation. Part of that was just the common fear of public speaking. For me, that only kicks in at around 100 people, and this audience was around 250. I think another reason was that I chose a really ambitious topic, and I kept finding more that I wanted to talk about, but wasn’t prepared for. But I think I did a pretty good job presenting an advanced topic. And I was so pumped by the sense of accomplishment as soon as I finished. So I’m hoping to do it more. I’ve already submitted a couple proposals, and plan to submit several more.
+I believe that blogging is important for me to get my thoughts down — for myself and to share with others. I was really successful last year when I had a partner to keep me honest, via a pact. So I’ve started up another pact this year, which will hopefully ensure I’ll keep things going. I’ve got a really long backlog of topics, so as long as I keep at it, I’ll have plenty to write about.
+I also want to move away from WordPress to a static system — probably Middleman. I’ve got 2 major problems with WordPress. First, I no longer trust its security, nor the security of any application written in PHP. Second, it generates HTML every time someone requests a page, instead of when the content is updated. I find that to be a waste of resources, and problematic from a security standpoint. The main problem with moving to a static blogging system is that I really want to allow comments, pingbacks, and tweetbacks. So I’ll have to find a way to integrate those.
+Last year I started thinking about programming language design, and started implementing a language tentatively called Brilliant. I’ve done a lot more thinking on the topic, and have a lot of notes. But I haven’t implemented much more yet. This year, I’d like to get my thoughts more organized, and write a series of blog posts on various aspects of language design. The most interesting part seems to be the trade-offs involved in the ways that various language features interact. So I’d like to make some progress on the language implementation, but more importantly, I’d like to get a lot of my design ideas written down.
+I’m also going to spend a lot of time learning a bunch more programming languages, so I have a better understanding of possible features, combinations of features, and their interactions. I’ve already start with Elixir, Clojure, and Racket. I’m hoping to also look at OCaml, Factor, and Haskell. I’ll probably also take a look at the 2 “Seven Languages in Seven Weeks” books.
+I think people often have trouble getting started with Agile. I started on a book last year, and got down quite a lot of good ideas. But I realized that I’m going to have a hard time organizing all those ideas into something coherent. Still, I’d like to try to get something out there that lets people get started with Agile. My idea is to present a toolbox of practices to get started with and build on that foundation over time with additional practices. Sort of a playbook on how to get started over the first 6 to 12 months and be successful. I want to make some progress on the book, at least enough to decide whether it’s worth the effort to finish it and self-publish it.
++]]>
Now that I’m starting to actually blog consistently, it makes sense to change. But before I move to something different, I want to be sure that I find all the features that I need. This post is my thought process about what I want.
+I’ve been playing with Jekyll lately, using it to generate a simple static site that can be updated easily. It’s pretty nice, and pretty easy to use. Something based on Jekyll would work well. The trickiest part will be figuring out how to manage comments. Or maybe I’ll just have to learn to live more minimally.
+Octopress is the obvious candidate. It fits most of my needs and wants. Most likely I’ll write my own commenting engine and add it to my Octopress template.
+The only other candidate that I’ve found is Ghost. It’s written in JavaScript and runs on Node. I don’t find Node to be that compelling, but the templates look great, and it’s designed for coding blogs.
+I’ll probably take a quick look at Droplets, too. It’s written in PHP, but seems to fit my other requirements.
+Unfortunately, that seems to be all there is in this space. Maybe I need to investigate more. Or maybe Octopress just has the static blog generation marked cornered. Either way, I’ll probably change my blogging software in the next month or two. Wish me luck!
++]]>
This bog will be a place where we can share some of our experiences in web development, Open Source, programming, and technology in general.
+]]>Web Development, Ruby on Rails, Open Source
+I’m considering buying a chording keyer. A keyer is a 1-handed text input device. Chording means that you can hit more than 1 key at a time. I’ve been interested in these for a long time actually. They’ve been popular in the wearable computing (“cyborg”) field, but never caught on anywhere else. I’ve always thought that 1-handed chording keyer would be a great input device to use with a cell phone. It’d be even better with a heads-up display like the Google Glass.
+There are quite a few chording keyers available. It doesn’t appear that any will meet exactly what I’m really looking for, but I might take the leap anyway. It should be a hand-held device. I really want a Bluetooth device, so I can use it with a computer, phone, or tablet. Below are the ones I’m considering.
+The Twiddler has been around quite a while, as probably the main commercially available keyer for wearable computing. There was a time that it was unavailable, but there’s a new version available from HandyKey now. It’s $200 ($220 Canadian), and comes in only USB.
+The Twiddler looks like a small TV remote. The current version (2.1) has 4 thumb keys, a thumb joystick (for mouse), and 12 small finger keys. It has good community support, including an alternate chord layout.
+In10did has been trying to bring out a few variations of their devices. The Decatxt looks like a pack of cigarettes, with 8 keys on the front and 2 thumb keys. It can be used with 1 or 2 hands. All letters can be typed with 1 finger or 1 thumb and 1 finger.
+The Decatxt has USB and Bluetooth models, but I’m unable to find pricing or a way to buy one. It looks like there have been no updates for over a year, so I’m concerned that this is going to be vaporware.
+The CyKey is based on the Microwriter, which goes back to the early 1980s. The Microwriter was a desktop-based device, but it looks like the CyKey might be able to be used as a hand-held device. It has 9 buttons on the face, arranged in 3 groups of 3 buttons.
+The CyKey is $125 (£75) and works over InfraRed connected to USB. A Bluetooth model is supposedly in the works.
+The EkaPad is like a cross between the Decatxt and the Twiddler. It has 12 buttons on the face, but no thumb keys. It’s got a nice well-thought-out design that looks quite ergonomic.
+The EkaPad is $150, available in USB only. A desktop holder is available to hold it upright, or it can be used hand-held.
+The FrogPad is meant to be used on a flat surface only. It looks kind of like a third of a laptop keyboard. It’s got 15 regular keys and 5 modifier keys. Only 1 key and 1 modifier can be chorded. Right-handed and left-handed models are available, with USB connectivity.
+The FrogPad2 was recently announced, replacing the original FrogPad. It switches to standard desktop-style keys, and adds some more keys along the top. It supports USB On-the-Go and Bluetooth. I’m not really interested in this model with its regular keys, but it doesn’t appear that the original version is being made any longer. The new models are priced at $200. I believe the old models were $150.
+The Chordite looks the most promising, but it’s only a concept with some DIY prototypes. It’s a hand-held device, with 2 buttons on each of the 4 fingers — one activated by the distal phalanx and the other by the middle phalanx. This initially sounds like it would be difficult to press 2 different buttons with 1 finger, but I think the way they’re positioned would make it actually work really well.
+The septambic keyer is another DIY concept, hand-built and used by wearable computing folks. It’s fitted to your palm, and you squeeze your fingers toward a fist to activate the buttons. There’s one button for each of the 4 fingers, and 3 for the thumb.
+The Clove 2 is a Bluetooth-enabled glove with 5 buttons — 1 for each finger. It’s another do-it-yourself project.
+I found an interesting project called ASETNIOP that allows chording on a standard Qwerty keyboard. (Assuming the keyboard supports multi-key roll-over well enough. Most keyboards should work.) It’s got a really nice online interactive tutorial. You basically chord with the 8 home-row keys, plus the spacebar.
+For Android, a program called GKOS for Android uses multi-touch with 1 or 2 button presses. The buttons are different sizes, depending on their frequency. I like this concept, but I don’t think the implementation is quite ready for production.
+I also found an app for iOS called Nintype that is a combination between Swype and a chording keyer.
+I think I’m going to try the Twiddler. If I find the concept to be a good one, hopefully I’ll build myself a Chordite (or have someone build one for me).
+I’m also going to play with implementing some of the ideas from ASETNIOP, using KeyRemap4MacBook.
+There are quite a few chording keyers available. It doesn’t appear that any will meet exactly what I’m really looking for, but I might take the leap anyway. It should be a hand-held device. I really want a Bluetooth device, so I can use it with a computer, phone, or tablet. Below are the ones I’m considering.
+The Twiddler has been around quite a while, as probably the main commercially available keyer for wearable computing. There was a time that it was unavailable, but there’s a new version available from HandyKey now. It’s $200 ($220 Canadian), and comes in only USB.
+The Twiddler looks like a small TV remote. The current version (2.1) has 4 thumb keys, a thumb joystick (for mouse), and 12 small finger keys. It has good community support, including an alternate chord layout.
+In10did has been trying to bring out a few variations of their devices. The Decatxt looks like a pack of cigarettes, with 8 keys on the front and 2 thumb keys. It can be used with 1 or 2 hands. All letters can be typed with 1 finger or 1 thumb and 1 finger.
+The Decatxt has USB and Bluetooth models, but I’m unable to find pricing or a way to buy one. It looks like there have been no updates for over a year, so I’m concerned that this is going to be vaporware.
+The CyKey is based on the Microwriter, which goes back to the early 1980s. The Microwriter was a desktop-based device, but it looks like the CyKey might be able to be used as a hand-held device. It has 9 buttons on the face, arranged in 3 groups of 3 buttons.
+The CyKey is $125 (£75) and works over InfraRed connected to USB. A Bluetooth model is supposedly in the works.
+The EkaPad is like a cross between the Decatxt and the Twiddler. It has 12 buttons on the face, but no thumb keys. It’s got a nice well-thought-out design that looks quite ergonomic.
+The EkaPad is $150, available in USB only. A desktop holder is available to hold it upright, or it can be used hand-held.
+The FrogPad is meant to be used on a flat surface only. It looks kind of like a third of a laptop keyboard. It’s got 15 regular keys and 5 modifier keys. Only 1 key and 1 modifier can be chorded. Right-handed and left-handed models are available, with USB connectivity.
+The FrogPad2 was recently announced, replacing the original FrogPad. It switches to standard desktop-style keys, and adds some more keys along the top. It supports USB On-the-Go and Bluetooth. I’m not really interested in this model with its regular keys, but it doesn’t appear that the original version is being made any longer. The new models are priced at $200. I believe the old models were $150.
+The Chordite looks the most promising, but it’s only a concept with some DIY prototypes. It’s a hand-held device, with 2 buttons on each of the 4 fingers — one activated by the distal phalanx and the other by the middle phalanx. This initially sounds like it would be difficult to press 2 different buttons with 1 finger, but I think the way they’re positioned would make it actually work really well.
+The septambic keyer is another DIY concept, hand-built and used by wearable computing folks. It’s fitted to your palm, and you squeeze your fingers toward a fist to activate the buttons. There’s one button for each of the 4 fingers, and 3 for the thumb.
+The Clove 2 is a Bluetooth-enabled glove with 5 buttons — 1 for each finger. It’s another do-it-yourself project.
+I found an interesting project called ASETNIOP that allows chording on a standard Qwerty keyboard. (Assuming the keyboard supports multi-key roll-over well enough. Most keyboards should work.) It’s got a really nice online interactive tutorial. You basically chord with the 8 home-row keys, plus the spacebar.
+For Android, a program called GKOS for Android uses multi-touch with 1 or 2 button presses. The buttons are different sizes, depending on their frequency. I like this concept, but I don’t think the implementation is quite ready for production.
+I also found an app for iOS called Nintype that is a combination between Swype and a chording keyer.
+I think I’m going to try the Twiddler. If I find the concept to be a good one, hopefully I’ll build myself a Chordite (or have someone build one for me).
+I’m also going to play with implementing some of the ideas from ASETNIOP, using KeyRemap4MacBook.
+]]>Web Development, Ruby on Rails, Open Source
+Most of us don’t write very readable shell scripts. There are plenty of things we could do better, but today I want to talk about one in particular — burying the lede.
+The term “burying the lede” comes from the field of journalism. Here’s the Wiktionary definition:
++To begin a story with details of secondary importance to the reader while postponing more essential points or facts.
Like a good news article, code should tell a story. And the story should start with what’s most important. In the case of code, the most important information is the high-level functionality — a succinct summary of what the program does. In other words, write (and organize) the code top-down, as opposed to bottom-up.
+Unfortunately, shell script doesn’t make this easy. Due to the way shell scripts are interpreted, you can’t call a function until after you’ve defined it. This leads to most of us structuring our code like this:
+function do_something { ... }
+function do_something_else { ... }
+
+do_something
+do_something_else
+The problem with this is that the function definitions will likely take quite a few lines, and we won’t see what the top-level functionality is until we reach the end of the script.
+I’d like to propose a standard way to structure shell scripts to mitigate this issue. (I’m really only talking about shell scripts that have function definitions within them.) I’m sure I’ve seen a few scripts do this, but it’s not very common at all.
+My proposal is simple:
+function main {
+ do_something
+ do_something_else
+}
+function do_something { ... }
+function do_something_else { ... }
+
+main
+This structure lets us start with the lede. We describe the top-level functionality right away. Only then do we get to the secondary details. The name main makes it pretty clear that it contains the top-level functionality.
I’ve recently started writing my shell code like this, and I’m happy with the results. I’ve also started to use some other programming techniques in my shell scripts to improve readability: better naming, extracting more methods, and moving helper methods into separate files. It feels good to treat shell scripts like real code instead of just some stuff I’ve hacked together.
+PS. The WordPress theme I’m currently using (Twenty Eleven) also buries the lede — I can barely even see the title of the blog post on my screen without scrolling. I’m going to have to change that soon.
+I’ve been using GNU/Linux since 1994, starting with a Slackware 2.2 CD-ROM I ordered from the back of a magazine. I’ve been heavily involved in my local GNU/Linux community since 1999, and I give frequent presentations at various groups. I’ve made some small contributions to several Open Source projects.
+But I don’t feel like I’ve done enough to contribute to the wider community. So this year, I’m going to resolve to step up my contributions, and do more.
+I was lucky enough this past year to find someone interested in helping to run the St. Louis GNU/Linux Users Group (STLLUG). I’ve been running the group so long that I’ve somewhat stagnated. It’s great to find someone who will bring a fresh energy and new ideas. Thanks, Andrew!
+Mostly freed from the more general administrative tasks (mostly planning meeting topics and speakers), I’m hoping to find the time to work on a few projects. First, I want to overhaul the web site. It needs a new look, as well as an easier way to update it. I’m planning to implement some sort of CMS — possibly WordPress or Octopress, or at the very least, a git repo to manage updates.
+I installed WordPress a long time ago, but I haven’t published many posts. I’ve got a few drafts in various stages. So this year I’m going to actually get the blog going, and hopefully post about once a week. I’ll be sharing things I learn on the Internet, as well as some of the things I learn from my experiences with various technologies and techniques.
+There are a few items I’ve been meaning to work on and contribute. I’d like to finally get around to them:
+I’ve been working on a few Ruby gems. I’d like to get them to a state where they’re useful to more people. These include:
+I enjoyed building a quick Rails app during last year’s Rails Rumble, even if it doesn’t turn out to be useful or make any money. I’d like to create a few small apps again this year, either in Rails or Apache Cordova. I’ve got some ideas — we’ll see how if they turn into anything useful or worth selling.
+Last year, I started joining the This Agile Life podcast. I enjoy it. I’m hoping to continue with that, and possibly doing some podcasting about Ruby and Rails.
+I’m going to attempt to give a presentation at a conference. I often give presentations at local groups, but haven’t addressed a larger audience. I’ve got a few ideas rattling around, and will see if I can turn them into presentations worthy of a larger conference.
+What’s your Open Source resolution?
+Here’s a relatively simple way to rename a bunch of files from the command line. It uses sed within a command substitution to compute the new names from the old names.
In this example, we’re renaming files that start with “ABC” to start with “XYZ” instead:
+ for i in ABC*; do mv $i $(echo $i | sed -e s/^ABC/XYZ/); done
+You’ll have to use shell globbing (wildcards) in the first part, to determine which files will be the source of the renaming, and regular expressions in the second part to translate the old names into the new names.
+It’s a good idea to use echo in place of mv before running this, to see what the results will be, so you don’t make a mistake.
Depending on the situation, you may need to adapt this for your particular needs. For example, if you have too many files to rename, you would need to use xargs. Or sed might not be up for the task of transforming the names that you want. Or you might need to use find to find files within a hierarchy. As with any UNIX idiom, there are hundreds of variations on the theme.
The term “burying the lede” comes from the field of journalism. Here’s the Wiktionary definition:
++To begin a story with details of secondary importance to the reader while postponing more essential points or facts.
Like a good news article, code should tell a story. And the story should start with what’s most important. In the case of code, the most important information is the high-level functionality — a succinct summary of what the program does. In other words, write (and organize) the code top-down, as opposed to bottom-up.
+Unfortunately, shell script doesn’t make this easy. Due to the way shell scripts are interpreted, you can’t call a function until after you’ve defined it. This leads to most of us structuring our code like this:
+function do_something { ... }
+function do_something_else { ... }
+
+do_something
+do_something_else
+The problem with this is that the function definitions will likely take quite a few lines, and we won’t see what the top-level functionality is until we reach the end of the script.
+I’d like to propose a standard way to structure shell scripts to mitigate this issue. (I’m really only talking about shell scripts that have function definitions within them.) I’m sure I’ve seen a few scripts do this, but it’s not very common at all.
+My proposal is simple:
+function main {
+ do_something
+ do_something_else
+}
+function do_something { ... }
+function do_something_else { ... }
+
+main
+This structure lets us start with the lede. We describe the top-level functionality right away. Only then do we get to the secondary details. The name main makes it pretty clear that it contains the top-level functionality.
I’ve recently started writing my shell code like this, and I’m happy with the results. I’ve also started to use some other programming techniques in my shell scripts to improve readability: better naming, extracting more methods, and moving helper methods into separate files. It feels good to treat shell scripts like real code instead of just some stuff I’ve hacked together.
+PS. The WordPress theme I’m currently using (Twenty Eleven) also buries the lede — I can barely even see the title of the blog post on my screen without scrolling. I’m going to have to change that soon.
+]]>But I don’t feel like I’ve done enough to contribute to the wider community. So this year, I’m going to resolve to step up my contributions, and do more.
+I was lucky enough this past year to find someone interested in helping to run the St. Louis GNU/Linux Users Group (STLLUG). I’ve been running the group so long that I’ve somewhat stagnated. It’s great to find someone who will bring a fresh energy and new ideas. Thanks, Andrew!
+Mostly freed from the more general administrative tasks (mostly planning meeting topics and speakers), I’m hoping to find the time to work on a few projects. First, I want to overhaul the web site. It needs a new look, as well as an easier way to update it. I’m planning to implement some sort of CMS — possibly WordPress or Octopress, or at the very least, a git repo to manage updates.
+I installed WordPress a long time ago, but I haven’t published many posts. I’ve got a few drafts in various stages. So this year I’m going to actually get the blog going, and hopefully post about once a week. I’ll be sharing things I learn on the Internet, as well as some of the things I learn from my experiences with various technologies and techniques.
+There are a few items I’ve been meaning to work on and contribute. I’d like to finally get around to them:
+I’ve been working on a few Ruby gems. I’d like to get them to a state where they’re useful to more people. These include:
+I enjoyed building a quick Rails app during last year’s Rails Rumble, even if it doesn’t turn out to be useful or make any money. I’d like to create a few small apps again this year, either in Rails or Apache Cordova. I’ve got some ideas — we’ll see how if they turn into anything useful or worth selling.
+Last year, I started joining the This Agile Life podcast. I enjoy it. I’m hoping to continue with that, and possibly doing some podcasting about Ruby and Rails.
+I’m going to attempt to give a presentation at a conference. I often give presentations at local groups, but haven’t addressed a larger audience. I’ve got a few ideas rattling around, and will see if I can turn them into presentations worthy of a larger conference.
+What’s your Open Source resolution?
+]]>sed within a command substitution to compute the new names from the old names.
+In this example, we’re renaming files that start with “ABC” to start with “XYZ” instead:
+ for i in ABC*; do mv $i $(echo $i | sed -e s/^ABC/XYZ/); done
+You’ll have to use shell globbing (wildcards) in the first part, to determine which files will be the source of the renaming, and regular expressions in the second part to translate the old names into the new names.
+It’s a good idea to use echo in place of mv before running this, to see what the results will be, so you don’t make a mistake.
Depending on the situation, you may need to adapt this for your particular needs. For example, if you have too many files to rename, you would need to use xargs. Or sed might not be up for the task of transforming the names that you want. Or you might need to use find to find files within a hierarchy. As with any UNIX idiom, there are hundreds of variations on the theme.
Web Development, Ruby on Rails, Open Source
+Most of us don’t write very readable shell scripts. There are plenty of things we could do better, but today I want to talk about one in particular — burying the lede.
+The term “burying the lede” comes from the field of journalism. Here’s the Wiktionary definition:
++To begin a story with details of secondary importance to the reader while postponing more essential points or facts.
Like a good news article, code should tell a story. And the story should start with what’s most important. In the case of code, the most important information is the high-level functionality — a succinct summary of what the program does. In other words, write (and organize) the code top-down, as opposed to bottom-up.
+Unfortunately, shell script doesn’t make this easy. Due to the way shell scripts are interpreted, you can’t call a function until after you’ve defined it. This leads to most of us structuring our code like this:
+function do_something { ... }
+function do_something_else { ... }
+
+do_something
+do_something_else
+The problem with this is that the function definitions will likely take quite a few lines, and we won’t see what the top-level functionality is until we reach the end of the script.
+I’d like to propose a standard way to structure shell scripts to mitigate this issue. (I’m really only talking about shell scripts that have function definitions within them.) I’m sure I’ve seen a few scripts do this, but it’s not very common at all.
+My proposal is simple:
+function main {
+ do_something
+ do_something_else
+}
+function do_something { ... }
+function do_something_else { ... }
+
+main
+This structure lets us start with the lede. We describe the top-level functionality right away. Only then do we get to the secondary details. The name main makes it pretty clear that it contains the top-level functionality.
I’ve recently started writing my shell code like this, and I’m happy with the results. I’ve also started to use some other programming techniques in my shell scripts to improve readability: better naming, extracting more methods, and moving helper methods into separate files. It feels good to treat shell scripts like real code instead of just some stuff I’ve hacked together.
+PS. The WordPress theme I’m currently using (Twenty Eleven) also buries the lede — I can barely even see the title of the blog post on my screen without scrolling. I’m going to have to change that soon.
+Here’s a relatively simple way to rename a bunch of files from the command line. It uses sed within a command substitution to compute the new names from the old names.
In this example, we’re renaming files that start with “ABC” to start with “XYZ” instead:
+ for i in ABC*; do mv $i $(echo $i | sed -e s/^ABC/XYZ/); done
+You’ll have to use shell globbing (wildcards) in the first part, to determine which files will be the source of the renaming, and regular expressions in the second part to translate the old names into the new names.
+It’s a good idea to use echo in place of mv before running this, to see what the results will be, so you don’t make a mistake.
Depending on the situation, you may need to adapt this for your particular needs. For example, if you have too many files to rename, you would need to use xargs. Or sed might not be up for the task of transforming the names that you want. Or you might need to use find to find files within a hierarchy. As with any UNIX idiom, there are hundreds of variations on the theme.
The term “burying the lede” comes from the field of journalism. Here’s the Wiktionary definition:
++To begin a story with details of secondary importance to the reader while postponing more essential points or facts.
Like a good news article, code should tell a story. And the story should start with what’s most important. In the case of code, the most important information is the high-level functionality — a succinct summary of what the program does. In other words, write (and organize) the code top-down, as opposed to bottom-up.
+Unfortunately, shell script doesn’t make this easy. Due to the way shell scripts are interpreted, you can’t call a function until after you’ve defined it. This leads to most of us structuring our code like this:
+function do_something { ... }
+function do_something_else { ... }
+
+do_something
+do_something_else
+The problem with this is that the function definitions will likely take quite a few lines, and we won’t see what the top-level functionality is until we reach the end of the script.
+I’d like to propose a standard way to structure shell scripts to mitigate this issue. (I’m really only talking about shell scripts that have function definitions within them.) I’m sure I’ve seen a few scripts do this, but it’s not very common at all.
+My proposal is simple:
+function main {
+ do_something
+ do_something_else
+}
+function do_something { ... }
+function do_something_else { ... }
+
+main
+This structure lets us start with the lede. We describe the top-level functionality right away. Only then do we get to the secondary details. The name main makes it pretty clear that it contains the top-level functionality.
I’ve recently started writing my shell code like this, and I’m happy with the results. I’ve also started to use some other programming techniques in my shell scripts to improve readability: better naming, extracting more methods, and moving helper methods into separate files. It feels good to treat shell scripts like real code instead of just some stuff I’ve hacked together.
+PS. The WordPress theme I’m currently using (Twenty Eleven) also buries the lede — I can barely even see the title of the blog post on my screen without scrolling. I’m going to have to change that soon.
+]]>sed within a command substitution to compute the new names from the old names.
+In this example, we’re renaming files that start with “ABC” to start with “XYZ” instead:
+ for i in ABC*; do mv $i $(echo $i | sed -e s/^ABC/XYZ/); done
+You’ll have to use shell globbing (wildcards) in the first part, to determine which files will be the source of the renaming, and regular expressions in the second part to translate the old names into the new names.
+It’s a good idea to use echo in place of mv before running this, to see what the results will be, so you don’t make a mistake.
Depending on the situation, you may need to adapt this for your particular needs. For example, if you have too many files to rename, you would need to use xargs. Or sed might not be up for the task of transforming the names that you want. Or you might need to use find to find files within a hierarchy. As with any UNIX idiom, there are hundreds of variations on the theme.
Web Development, Ruby on Rails, Open Source
+It’s that time of year again — time for a retrospective on how I did on my goals for the year. I had 5 main goals for 2015:
+I got pretty lucky on this one. My main contract with Mercy got extended several times. Amos and I must have been doing a good job of keeping the customer happy. We even made it through a couple rounds of layoffs. I’m wrapping up the gig at Mercy now. I’m working one day a week there, as the project winds down.
+I also started a new gig this month at CenturyLink. I’m working on a cloud development team. Our current project involves selling WordPress as a service. The manager had been courting me for most of the year. I’m excited about my new role; I’ll be writing about it in a blog post soon.
+I set a goal in 2014 to give my first conference talk. I accomplished that, giving an ambitious talk at RubyConf. I enjoyed having done that, and vowed to do more conference speaking.
+I gave 3 conference talks in 2015. I gave a workshop on HTTP at RailsConf. I talked about immutable infrastructure at Madison+ Ruby. At RubyConf, I gave a talk on a micro-ORM I wrote. I also gave a lightning talk about Agile estimation (#noestimates).
+I was an alternate speaker at Windy City Rails, but did not give my talk on Alternatives to ActiveRecord. I also went to Strange Loop, mainly to see several friends and acquaintances speak.
+I wrote 24 blog articles this year. That’s about one every other week. What really kept me going was participating in a writing pact. When the pact was going, I had a 75% blogging rate. That’s pretty good.
+I’m not so sure about the quality of my blog writing though. I know that practicing writing is supposed to make you better. I know I wrote some really good articles over the past year, but I think I also wrote some articles that weren’t very good. I think sometimes the deadline has caused more harm than good. I’m not really sure what to do about that; perhaps just pushing on is the right answer.
+I’ve taken a lot of notes on the design of my programming language. Any time I learn something interesting about another language, or come up with another idea, I write it down.
+But I haven’t worked on the implementation. (I last worked on the implementation in 2014.) I should be experimenting with some ideas, implementing them to see how they work out. I’ve even kicked around the idea of starting with a Forth variant, just to get something working quickly.
+I haven’t written any articles on my ideas this year either. My notes are pretty extensive, and it would be good to write some articles to help get my thoughts straight.
+I’ve got some things to say about Agile, and want to write a book to express those ideas. I’ve made a start — I’ve got the chapters outlines, and have started on a few chapters. But I haven’t made as much progress as I’d like to. I shared what I’ve got with Amos, and he showed some interest in pairing with me on the writing. Hopefully we’ll work on it together in 2016 and publish it.
+There were a few other accomplishments that weren’t explicitly on my list, but I’d like to call attention to.
+I’ve continued participating on the This Agile Life podcast. I was in 12 of the 33 episodes that were recorded in 2015. I hope to participate in more in 2016. We’re considering scheduling a standard recording night each week, which might help us record more regularly.
+I recently took over as maintainer of Virtus, a library to declare attributes for Ruby model classes. I haven’t done a lot yet, since I’ve been busy with travel, vacation, and holidays. But I hope to catch up with all the pending pull requests and issues in the next month or so.
+The accomplishment I’m most proud of is mentoring for the Roy Clay Sr. Tech Impact program. This is a program begun as a result of the Ferguson protest movement. We’re helping teach kids (from 14 to 25) web design and development. My personal goal was to give these kids an opportunity that they would not have otherwise had. But it turned out that some of them have actually started a business building web sites for small companies. I’m so proud of the progress they’ve made in such a short time; it’s a challenging program.
+I’m pretty happy with my accomplishments this year. I made at least some progress on each of the goals I set. I’ve been thinking about my goals for next year; I’ll write that as a separate blog article next week.
+I got my first computer in 1984. It was a Commodore 64. I had to do extra chores and save up my allowance to buy it. I was 13.
+Back then, Sears and other retail stores had Commodore 64 computers out on display. Whenever I went to the store, I’d write a short BASIC program and leave it running on the display computers:
+10 PRINT "CRAIG IS GREAT!" +20 GOTO 10+
Hey, I was a 13-year-old kid. Later, I got a little more sophisticated. I’d change the background color instead. I still remember the POKE address:
+10 FOR I=0 TO 255 +20 POKE 53281, I +30 NEXT I +40 GOTO 10 +RUN+
This was fast enough to change the background color every few scan lines, creating a flashing scrolling effect.
+Later, I learned 6502 assembly language. I translated the BASIC program into assembler, and memorized the bytes to type in at the store. In assembly language, the background color would change several times per scan line. The effect was kind of psychedelic.
+All that happened in the mid-1980s.
+Fast-forward to about 2000 or so. I was telling the above story after a St. Louis LUG meeting. I explained how I had memorized the 10 or 12 bytes of machine code, and would leave the program running with its psychedelic effect.
+After thinking about it for a bit, I thought that 10 or 12 bytes seemed too much. It actually bothered me — I couldn’t fall asleep when I got home. I got up and found my old 6502 manuals. I figured out how to write the code in 7 bytes. I installed the Vice C64 emulator on my Linux desktop, and tested my code. It worked as expected. (The emulator was already clock-cycle perfect by then.) Here’s the assembly code:
+INX ; $E8 ; 232 +STX $D021 ; $8E $21 $D0 ; 142 33 208 ; $D021 = 53281 +JMP $C000 ; $4C $00 $C0 ; 76 0 192 ; $C000 = 49152+
Here’s the BASIC program to store that program in memory and run it:
+10 FOR N=49152 TO 49152+6: READ Q : POKE N, Q : NEXT +20 DATA 232, 142, 33, 208, 76, 0, 192 +30 SYS 49152 +RUN+
The moral of the story is that you can optimize even a 10-byte program, 15 years after the last time it was used. So don’t tell me that your program can’t be improved, no matter how small it is.
+PS. I rewrote the code above while writing this article in 2015, about 15 years after the last time I rewrote it. And I again downloaded Vice to test it, this time on Mac OS X.
+I’ve been working on application architectures based on Uncle Bob’s Ruby Midwest talk, following the hexagonal architectural pattern. I posted an article a couple months ago showing a way that works fairly well in Rails, and some accompanying Rails example code. But there was one thing I wasn’t quite happy with.
+The problem is that we used callbacks (actually, a publish/subscribe mechanism) in a situation where they don’t seem to quite fit:
+ def show
+ interactor.on(:display) { |order| render order }
+ interactor.on(:not_found) { |order_id| render status: 404 }
+ interactor.get(params[:id])
+ end
+What we really want is to respond in different ways, depending on the result of the call to interactor.get(). There’s no good reason to define the responses before the call. It makes a lot more sense to define the responses after the call, because they’ll happen after the call. I’d much prefer that the code be written in the order that it will be run.
I discussed this problem with my friend and colleague, Amos King. We came up with a better solution, which puts things back in the right order:
+ def show
+ interactor.get(params[:id]) do |on|
+ on.display { |order| render order }
+ on.not_found { |order_id| render status: 404 }
+ end
+ end
+He even wrote a small library to do this, which he called Riposte. I’m not sure what to call this pattern, but it seems to work pretty well in this situation. I suppose that they’re still technically callbacks, because they’re passed in in the block that’s passed in to the call to interactor.get(). But due to the magic of Ruby blocks, we get to put them in the order they should be.
Riposte also gives you the option of using the response object directly, instead of passing a block:
+ def show
+ on = interactor.get(params[:id])
+ on.display { |order| render order }
+ on.not_found { |order_id| render status: 404 }
+ end
+This shows that it’s just returning an object, with the twist that the response object has methods that take blocks. The nested blocks variant is really the same thing, except that it’s yielding to the response object instead of returning it.
+I’ve decide that is the pattern I’d like to use for interactions and their callers within Ruby hexagonal architecture.
+I’ve started working on my own framework in Ruby in the past couple days. It’s built upon my recent work at understanding Uncle Bob’s Ruby Midwest 2011 talk, and his article on Clean Architecture, and the resulting hexagonal architecture (AKA ports and adapters).
+Somehow my research in that vein led me to Gary Bernhardt’s Boundaries talk. I’ve read a lot about the talk, and knew about the idea of “functional core / imperative shell”. And I’ve worked with a lot of similar ideas lately. But I believe this is the first time that I actually watched the whole video.
+Even after having read a lot about similar ideas, it was pretty mind-expanding. Gary’s really good at presenting these kinds of ideas in a simple way.
+OOP as usually taught includes encapsulation of data together with behavior, with mutable objects. Functional programming separates data and behavior, with mostly immutable data. From experience, encapsulating data and behavior together seems helpful. But experience also shows that immutability is useful. So it would be good to have both of those together. This is something I’ve been thinking for a few years — how best do we get both?
+Gary calls the combination “FauxO”. Logic and data are still combined, but there’s no mutation. Anywhere OOP would normally have mutation would just generate a new object. There’s no language restriction involved in enforcing immutability — just discipline.
+But without mutability, it’s hard to do IO and maintain state. So Gary’s solution is to encapsulate as much as possible into an immutable (functional or FauxO) core, and around that, use an imperative (traditional OOP) shell. The functional core contains the bulk of the logic, and the imperative shell is a glue layer that handles the real world, including disk, network, and other I/O.
+The result of this is that the shell has fewer paths, but more dependencies. The core contains no dependencies, but encapsulates the different logic paths. So we’re encapsulating dependencies on one side, and business logic on the other side. Or put another way, the way to figure out the separation is by doing as much as you can without mutation, and then encapsulating the mutation separately.
+I love how this naturally breaks things up, so that the core is all testable with unit tests, and the imperative shell is tested with integration tests. And since the shell has few or no logic paths, you get the testing pyramid, with more unit tests and fewer integration tests. The whole thing ends up being quite beautiful. Tests end up being very fast without any extra effort — not even stubbing or mocking. This tells us that things have been decomposed very well — an elegant design.
+Gary makes the case that immutable objects can be treated as values, and passed across boundaries. Even process boundaries. This is something I’ve noticed as I’ve been working on my own Uncle Bob style hexagonal framework, but nobody in that camp ever mentioned that — they prefer DTOs or something more like hashes. I’m completely against hashes, because of the “stringly-typed” problem. And I don’t see much advantage in a DTO if I’ve got an immutable object; I’d be basically copying the object to an almost identical object. And I’d be losing any laziness possible for derived values within the original immutable object.
+It’s striking to me how Gary’s image of an imperative shell around a functional core, plus Net, Disk, and State outside of the shell mirror’s Uncle Bob’s concentric circles. Uncle Bob has entities in the middle, surrounded by use cases, surrounded by Web, DB, and UI.
+Another advantage that Gary shows is that breaking things up this way allows easy concurrency. In his example, he shows using the actor model — either just using threads and queues, or an actor library (or language feature).
+After several years of thinking about the architectural issues seen in most large Rails apps, I’m starting to come to an understanding of how to combine all these ideas and come up with an architecture that will work better.
++
I’ve had a long love-hate relationship with Rails. I love the MVC framework and how it’s improved our speed of writing web apps. But I’ve never really been completely happy with it. I don’t generally agree with most of its opinions. I prefer models that follow the Data Mapper pattern, not the Active Record pattern. This includes separating the persistence layer from the models’ business logic. I prefer Slim or HAML to ERB. I prefer RSpec to Test::Unit or MiniTest. When Merb hit the scene, I was ready to make the jump, until Merb merged with Rails.
+So inspired by PJ Hagerty’s recent article on alternative Ruby web frameworks, I started thinking about how I’d write a replacement for Rails. I’d definitely keep the basic MVC framework. But I’d also want to implement a more hexagonal architecture.
+I started sketching out what this would look like, but I ended up starting with a Rails controller and finding the simplest way to make it hexagonal. I really don’t like callbacks, because they make tracing program execution difficult. But I didn’t see any other alternative. I found a simple pub/sub Ruby library called Wisper. It literally has only publish, subscribe, and on methods. (You use on to register single callbacks via blocks, and subscribe to register an object with method names corresponding to the callback names.)
The trick was figuring out how to break the controller into 2 pieces. What finally helped me was to find the single responsibilities of the 2 pieces. The Rails controller would remain in charge of managing the web interface, but would delegate to the other piece to handle any application-specific business logic. I decided to re-watch Uncle Bob Martin’s “Architecture The Lost Years” talk, which was the first time I was introduced to the ideas of Hexagonal Architecture. (He doesn’t name the architecture in the talk, but later calls it Clean Architecture.) He does a decent job of explaining how to break these 2 pieces apart. He used the term “interactor” in that talk, so I decided to go with that. He said that Jacobsen calls it a Control Object in Object Oriented Software Engineering, but that’s too close to Rails’s “controller”.
+So here’s an example of what I ended up with:
+class OrderController < ApplicationController
+ def index
+ interactor.on(:display) { |orders| render orders }
+ interactor.list
+ end
+
+ def show
+ interactor.on(:display) { |order| render order }
+ interactor.on(:not_found) { |order_id| render status: 404 }
+ interactor.get(params[:id])
+ end
+
+private
+
+ def interactor
+ @interactor ||= OrderInteractor.new
+ end
+end
+require "wisper" +require "order" + +class OrderInteractor + include Wisper.publisher + + def list + orders = Order.all + publish(:display, orders) + end + + def get(id) + order = Order.find(id) + publish(:display, order) + rescue ActiveRecord::RecordNotFound + publish(:not_found, id) + end +end+
I do have a few problems with this solution though. I’m not a fan of the name “interactor” for the business logic. I thought about calling it OrderOperator, or maybe OrderOperations, because it’s really a collection of operations. Perhaps it would be better to separate each operation into a separate class. Trailblazer does it that way. And for more complicated business logic, I would do that too, using the Method Object pattern. But like a Rails controller, there’s a lot in common among all the operations. I feel like a separate class for each operation for each would create too many coupled classes.
I’m also uncomfortable with the fact that the controller is delegating almost everything to the interactor. I guess this is OK, but it feels like there’s too little left when every line starts with interactor. I suppose extracting things some more would help mitigate this concern I’ll likely write a small gem to perform that extraction. I expect that that will allow a typical controller to be written in only a few lines. And maybe the same for the interactor side.
With the business logic extracted out of the controller, it was really easy for me to write a command-line version of the app. As Uncle Bob says, “the web is not particularly important to your application.”
+I’ve put the code for this example on GitHub: https://github.com/boochtek/hexagonal-rails. I’ll likely experiment with it some more over the next few weeks and months.
+January kept me pretty busy, so I’m a little late to this. But better late than never. And as an Agile practitioner, I don’t think personal retrospectives should be limited to one time of year.
+Last year I wrote a blog entry listing my goals for 2014. As far as New Year’s resolutions go, I was relatively successful — about 50% of my goals accomplished. Unfortunately, my Open Source contributions weren’t as strong as I had hoped; while I released some of my own work, I didn’t do much else. I did increase my blogging; getting in on a weekly blogging pact helped immensely. I also increased my participation on the This Agile Life podcast to a level that I’m happy with. But the accomplishment I’m most proud of was giving a presentation at RubyConf.
+I’d like to keep things rolling from last year, but crank up a few things. My plans are quite ambitious, so I don’t expect to get everything done by any means. But I think by setting the bar high, I’ll end up with a lot I can be proud of.
+Late last year, I took the jump into independent consulting. So far, I’ve really enjoyed it, and I’m booked up through April. My wife graduates in May, so we’ve got the possibility of moving if that makes sense. So I’ll be looking for consulting projects in town, but I’ll also be looking at jobs in San Francisco and Chicago. The possibilities are exciting, and I’ll be taking my time to find something just right.
+I was incredibly nervous leading up to my RubyConf presentation. Part of that was just the common fear of public speaking. For me, that only kicks in at around 100 people, and this audience was around 250. I think another reason was that I chose a really ambitious topic, and I kept finding more that I wanted to talk about, but wasn’t prepared for. But I think I did a pretty good job presenting an advanced topic. And I was so pumped by the sense of accomplishment as soon as I finished. So I’m hoping to do it more. I’ve already submitted a couple proposals, and plan to submit several more.
+I believe that blogging is important for me to get my thoughts down — for myself and to share with others. I was really successful last year when I had a partner to keep me honest, via a pact. So I’ve started up another pact this year, which will hopefully ensure I’ll keep things going. I’ve got a really long backlog of topics, so as long as I keep at it, I’ll have plenty to write about.
+I also want to move away from WordPress to a static system — probably Middleman. I’ve got 2 major problems with WordPress. First, I no longer trust its security, nor the security of any application written in PHP. Second, it generates HTML every time someone requests a page, instead of when the content is updated. I find that to be a waste of resources, and problematic from a security standpoint. The main problem with moving to a static blogging system is that I really want to allow comments, pingbacks, and tweetbacks. So I’ll have to find a way to integrate those.
+Last year I started thinking about programming language design, and started implementing a language tentatively called Brilliant. I’ve done a lot more thinking on the topic, and have a lot of notes. But I haven’t implemented much more yet. This year, I’d like to get my thoughts more organized, and write a series of blog posts on various aspects of language design. The most interesting part seems to be the trade-offs involved in the ways that various language features interact. So I’d like to make some progress on the language implementation, but more importantly, I’d like to get a lot of my design ideas written down.
+I’m also going to spend a lot of time learning a bunch more programming languages, so I have a better understanding of possible features, combinations of features, and their interactions. I’ve already start with Elixir, Clojure, and Racket. I’m hoping to also look at OCaml, Factor, and Haskell. I’ll probably also take a look at the 2 “Seven Languages in Seven Weeks” books.
+I think people often have trouble getting started with Agile. I started on a book last year, and got down quite a lot of good ideas. But I realized that I’m going to have a hard time organizing all those ideas into something coherent. Still, I’d like to try to get something out there that lets people get started with Agile. My idea is to present a toolbox of practices to get started with and build on that foundation over time with additional practices. Sort of a playbook on how to get started over the first 6 to 12 months and be successful. I want to make some progress on the book, at least enough to decide whether it’s worth the effort to finish it and self-publish it.
++
I’ve run across a pattern in Ruby lately that I really like. It solves some problems that I’ve struggled with for several years. Let me start with the problems.
+Let’s say you want to include an ORM in a model class, and want to tell it what database table to use. Typically, you’d do this:
+class User + include MyORM::Model + table 'people' +end+
But that table call is more like an option to the module inclusion than anything else. So what we’d really like is something like this:
class User + include MyORM::Model, table: 'people' +end+
But that’s not valid Ruby; include doesn’t let you pass anything other than a module.
So when I was learning about Virtus, I noticed that its example of how to include it is a bit different than the standard Ruby idiomatic include:
class User + include Virtus.model +end+
At first glance, it reads like the first example. But on closer inspection and consideration, it’s quite a bit different. Where MyORM::Model is a constant that refers to a module, Virtus.model is a method call. So there’s a method named model in the Virtus module. That method returns another module — which is exactly what’s needed in order to include it into our model class.
The easiest way to implement Virtus.model would be this:
module Virtus + def model + ::Virtus::Model + end +end + +module Virtus::Model + # ... +end+
If Virtus.model doesn’t need to take any arguments, that’s perfectly fine. In fact, I’ve started to use this implementation of the pattern for modules that don’t need parameters.
Because Virtus.model is a method, we can also call it with options:
class User + include Virtus.model(constructor: false, mass_assignment: false) +end+
We could even pass a block. But how do we process those options? There are a few different ways. However we do it, we have to be sure to return a module. And we can create modules in a few different ways.
+Virtus uses the builder pattern. It takes the parameters passed in and builds a module dynamically. By that, I mean that it calls Module.new and then adds methods to that module. It does this by mixing in other modules, but it could do it by dynamically defining methods as well.
I’ve never seen this pattern in any other language. It’s obviously only possible because we can dynamically create modules.
+The use of this idiom seems to be catching on a bit in the Ruby community. I’ve started using it myself, and will be adding it to my Includable::ActiveRecord gem soon.
++
+
I’ve decided to design and implement my own programming language, and call it Brilliant.
+I’ve been interested in programming languages and linguistics almost as long as I’ve been using computers. I’ve long thought that if I ever go back to college, it’s likely that I’ll concentrate on programming languages as a specialty.
+My recent discovery and involvement with the Crystal programming language has gotten me excited about new language ideas. It’s also helped me realize that implementing a language myself is feasible, and that there’s no better time to start than now.
+For now, the Brilliant implementation doesn’t let you do much more than “Hello World”. But you gotta start somewhere. So this article isn’t really “Introducing Brilliant” so much as the start of a series of articles on its design and implementation.
+I wanted to use a PEG (parsing expression grammar) parser for several reasons. For one, they seem to have gained a lot of popularity in the past few years. Also, PEGs cannot be ambiguous, which can solve a few difficult problems, such as the “dangling else“. Perhaps my favorite feature of PEG grammars is that you don’t need a separate tokenizer (lexer). This provides a nice advantage in that we can use keywords like “class” as variables, as long as they’re not used in a place where the keyword would make sense.
So knowing that I wanted to use a PEG, I had to find a PEG parser. I kind of wanted to use ANTLR, which has been a leading parser for many years. But the PEG seems to be new to version 4, and I couldn’t find any Ruby bindings for version 4. Treetop seems to be the most popular parser for Ruby, but I found the EBNF format that Rattler uses to be more to my taste. I think the fact that it’s newer also gives it a few advantages, having had a chance to learn some lessons from Treetop.
+I thought about using the Rubinius VM, but decided to go with LLVM, mainly since it has slightly better docs for Ruby, and because it’s what Crystal uses. Also, it’s pretty easy to get it to compile to a binary executable or run in a JIT. In the future, I might consider switching to the Rubinius VM, the Erlang VM, or the Perl 6 VM (Parrot). But for now, I like the idea of being able to compile to a binary and easily interface with C, just like Crystal.
+My main goal is to have fun playing around with language ideas.
+I’ve found a really great language in Ruby, so I’ll be using it as a starting point. But Ruby does have its faults. In some ways, I want to answer the question “what would Ruby look like if we designed it today?”.
+But I also want to explore other ideas. What if objects defaulted to immutable? What if functions and methods were assumed to be pure by default? Might it be possible to infer the purity of a function or method? (If so, we could automatically memoize them.) Can we make creating an actor as easy as creating an object?
+I’ll also be looking at ideas from other programming languages. Could we get some of the benefits of Haskell’s purity without having to do somersaults to do IO? Could we mix Python’s indentation style scoping with brace style or begin/end style? Could we integrate Icon’s ideas about success and failure (goal-directed execution)? What interesting features can we pull from Ada, Io, CoffeeScript, Crystal, Rubinius, Perl 6, etc.?
+
I’m not so much as interested in cutting-edge features, as in features that can be easily used by the average programmer. More importantly, I’m interested in how features interact with each other, so they fit well together to create a whole that’s greater than the sum of the parts.
+I wanted to name my programming language “Fermat”. I’ve long been intrigued by Fermat’s Last Theorem, and Fermat’s Little Theorem is important in number theory. Unfortunately, there’s already a computer algebra system with that name.
+So I decided to find a name in the same vein as “Ruby” and “Crystal”. I looked at the Wikipedia page for “gemstones” for some inspiration. A lot of the names of gemstones are already taken. I considered some obscure gemstones, but saw the word “brilliant” and thought it was decent. It’s not the name of another gemstone, but still evokes some similarity to Ruby and Crystal.
+So that’s the name for now. Perhaps I’ll decide to change it at some point in the future, but I needed a name for the project, as well as a file extension for source code files. I chose “bril” for that. I suppose “br” would be a better choice. Perhaps I’ll change that before the next article in this series.
I hope to work on Brilliant every once in a while. I expect it’ll take a couple years before it’s really very useful.
+When I do add a major feature, I’ll be certain to blog about it. I’ve got tons of ideas strewn about in various files. It would be great to get them organized and published —and even better to get them implemented.
+There’s a tweet that I saw recently, with some simple advice for novice programmers:
++Slow down.
This is probably good advice for most programmers. Our team recently noticed that every time we try to rush things, we make mistakes. And the mistakes end up costing us more time than if we had just done things at our normal pace. Slowing down ensures that you do things right, and when you do things right, you end up with a higher-quality product.
+There are 2 types of code quality: internal and external. External code quality can be measured by how many bugs have been reported by customers. Internal code quality is harder to measure, but it mainly deals with the ability to change the code. When your internal quality is low, you’ve got lots of technical debt, and it’s harder to make changes.
+So when you try to write code quickly, code quality decreases, leading to a code base that takes more time to make changes to. Conversely, when you slow down, your code quality improves, and it becomes easier to make changes more quickly. So when writing code, slowing down in the short run leads to a speed-up in the long run.
+But writing code isn’t the only place where we try to speed up. On an Agile team, we’re always trying to improve the way we work — especially at the beginning stages of an Agile transformation. So we’re eager to make changes in our processes. But I’d urge you to slow down here as well.
+My colleague Amos and I frequently argue over pair switching. It’s funny, because we agree on everything except for 1 small detail. We both think pair switching is very important, to ensure that team members see more of what’s going on, to bring more ideas to each story, to prevent knowledge silos, and to encourage team ownership. Where we disagree is how long an ideal pairing session should last. I think pairs should switch every 2 hours, and he thinks 1 hour is ideal. I’ve seen teams reach the 1 hour pairing sessions successfully. But usually not without some pain and even often failing at the first attempt.
+There’s nothing inherently wrong with failing. But if you fail at something, you’re not likely to try again. After all, you should learn from your failures, right?
+So if you want your team to do something, you probably don’t want them to fail at it. If they fail, they won’t want to try a second time. That’s just human nature, and learning from failure. While you might think that they failed because they weren’t ready for the change yet, they’ll most likely think that they failed because this particular change won’t work for their situation. And they probably won’t know what to change when trying again, so they won’t try again.
+I’ve seen this over and over. Back when Linux was up-and-coming, when a consultant pushed a company into using Linux before they were ready for it, and it didn’t work out, that company was cautious about trying again. So instead of being on the leading edge of using Linux, or even the middle of the pack, they ended up more toward the trailing edge. Had they not been pushed, they would have gotten more benefit in the long run.
+So my advice in process improvement is the same as in programming: slow down. Take small steps toward what you think is the ideal. Make a small change, see how it works out, and adjust. As long as you’re still moving in the right direction, I believe you’ll move faster by taking small steps than by trying to make big leaps.
+Most of us don’t write very readable shell scripts. There are plenty of things we could do better, but today I want to talk about one in particular — burying the lede.
+The term “burying the lede” comes from the field of journalism. Here’s the Wiktionary definition:
++To begin a story with details of secondary importance to the reader while postponing more essential points or facts.
Like a good news article, code should tell a story. And the story should start with what’s most important. In the case of code, the most important information is the high-level functionality — a succinct summary of what the program does. In other words, write (and organize) the code top-down, as opposed to bottom-up.
+Unfortunately, shell script doesn’t make this easy. Due to the way shell scripts are interpreted, you can’t call a function until after you’ve defined it. This leads to most of us structuring our code like this:
+function do_something { ... }
+function do_something_else { ... }
+
+do_something
+do_something_else
+The problem with this is that the function definitions will likely take quite a few lines, and we won’t see what the top-level functionality is until we reach the end of the script.
+I’d like to propose a standard way to structure shell scripts to mitigate this issue. (I’m really only talking about shell scripts that have function definitions within them.) I’m sure I’ve seen a few scripts do this, but it’s not very common at all.
+My proposal is simple:
+function main {
+ do_something
+ do_something_else
+}
+function do_something { ... }
+function do_something_else { ... }
+
+main
+This structure lets us start with the lede. We describe the top-level functionality right away. Only then do we get to the secondary details. The name main makes it pretty clear that it contains the top-level functionality.
I’ve recently started writing my shell code like this, and I’m happy with the results. I’ve also started to use some other programming techniques in my shell scripts to improve readability: better naming, extracting more methods, and moving helper methods into separate files. It feels good to treat shell scripts like real code instead of just some stuff I’ve hacked together.
+PS. The WordPress theme I’m currently using (Twenty Eleven) also buries the lede — I can barely even see the title of the blog post on my screen without scrolling. I’m going to have to change that soon.
+Web Development, Ruby on Rails, Open Source
+I’ve been working on application architectures based on Uncle Bob’s Ruby Midwest talk, following the hexagonal architectural pattern. I posted an article a couple months ago showing a way that works fairly well in Rails, and some accompanying Rails example code. But there was one thing I wasn’t quite happy with.
+The problem is that we used callbacks (actually, a publish/subscribe mechanism) in a situation where they don’t seem to quite fit:
+ def show
+ interactor.on(:display) { |order| render order }
+ interactor.on(:not_found) { |order_id| render status: 404 }
+ interactor.get(params[:id])
+ end
+What we really want is to respond in different ways, depending on the result of the call to interactor.get(). There’s no good reason to define the responses before the call. It makes a lot more sense to define the responses after the call, because they’ll happen after the call. I’d much prefer that the code be written in the order that it will be run.
I discussed this problem with my friend and colleague, Amos King. We came up with a better solution, which puts things back in the right order:
+ def show
+ interactor.get(params[:id]) do |on|
+ on.display { |order| render order }
+ on.not_found { |order_id| render status: 404 }
+ end
+ end
+He even wrote a small library to do this, which he called Riposte. I’m not sure what to call this pattern, but it seems to work pretty well in this situation. I suppose that they’re still technically callbacks, because they’re passed in in the block that’s passed in to the call to interactor.get(). But due to the magic of Ruby blocks, we get to put them in the order they should be.
Riposte also gives you the option of using the response object directly, instead of passing a block:
+ def show
+ on = interactor.get(params[:id])
+ on.display { |order| render order }
+ on.not_found { |order_id| render status: 404 }
+ end
+This shows that it’s just returning an object, with the twist that the response object has methods that take blocks. The nested blocks variant is really the same thing, except that it’s yielding to the response object instead of returning it.
+I’ve decide that is the pattern I’d like to use for interactions and their callers within Ruby hexagonal architecture.
+I’ve started working on my own framework in Ruby in the past couple days. It’s built upon my recent work at understanding Uncle Bob’s Ruby Midwest 2011 talk, and his article on Clean Architecture, and the resulting hexagonal architecture (AKA ports and adapters).
+Somehow my research in that vein led me to Gary Bernhardt’s Boundaries talk. I’ve read a lot about the talk, and knew about the idea of “functional core / imperative shell”. And I’ve worked with a lot of similar ideas lately. But I believe this is the first time that I actually watched the whole video.
+Even after having read a lot about similar ideas, it was pretty mind-expanding. Gary’s really good at presenting these kinds of ideas in a simple way.
+OOP as usually taught includes encapsulation of data together with behavior, with mutable objects. Functional programming separates data and behavior, with mostly immutable data. From experience, encapsulating data and behavior together seems helpful. But experience also shows that immutability is useful. So it would be good to have both of those together. This is something I’ve been thinking for a few years — how best do we get both?
+Gary calls the combination “FauxO”. Logic and data are still combined, but there’s no mutation. Anywhere OOP would normally have mutation would just generate a new object. There’s no language restriction involved in enforcing immutability — just discipline.
+But without mutability, it’s hard to do IO and maintain state. So Gary’s solution is to encapsulate as much as possible into an immutable (functional or FauxO) core, and around that, use an imperative (traditional OOP) shell. The functional core contains the bulk of the logic, and the imperative shell is a glue layer that handles the real world, including disk, network, and other I/O.
+The result of this is that the shell has fewer paths, but more dependencies. The core contains no dependencies, but encapsulates the different logic paths. So we’re encapsulating dependencies on one side, and business logic on the other side. Or put another way, the way to figure out the separation is by doing as much as you can without mutation, and then encapsulating the mutation separately.
+I love how this naturally breaks things up, so that the core is all testable with unit tests, and the imperative shell is tested with integration tests. And since the shell has few or no logic paths, you get the testing pyramid, with more unit tests and fewer integration tests. The whole thing ends up being quite beautiful. Tests end up being very fast without any extra effort — not even stubbing or mocking. This tells us that things have been decomposed very well — an elegant design.
+Gary makes the case that immutable objects can be treated as values, and passed across boundaries. Even process boundaries. This is something I’ve noticed as I’ve been working on my own Uncle Bob style hexagonal framework, but nobody in that camp ever mentioned that — they prefer DTOs or something more like hashes. I’m completely against hashes, because of the “stringly-typed” problem. And I don’t see much advantage in a DTO if I’ve got an immutable object; I’d be basically copying the object to an almost identical object. And I’d be losing any laziness possible for derived values within the original immutable object.
+It’s striking to me how Gary’s image of an imperative shell around a functional core, plus Net, Disk, and State outside of the shell mirror’s Uncle Bob’s concentric circles. Uncle Bob has entities in the middle, surrounded by use cases, surrounded by Web, DB, and UI.
+Another advantage that Gary shows is that breaking things up this way allows easy concurrency. In his example, he shows using the actor model — either just using threads and queues, or an actor library (or language feature).
+After several years of thinking about the architectural issues seen in most large Rails apps, I’m starting to come to an understanding of how to combine all these ideas and come up with an architecture that will work better.
++
The problem is that we used callbacks (actually, a publish/subscribe mechanism) in a situation where they don’t seem to quite fit:
+ def show
+ interactor.on(:display) { |order| render order }
+ interactor.on(:not_found) { |order_id| render status: 404 }
+ interactor.get(params[:id])
+ end
+What we really want is to respond in different ways, depending on the result of the call to interactor.get(). There’s no good reason to define the responses before the call. It makes a lot more sense to define the responses after the call, because they’ll happen after the call. I’d much prefer that the code be written in the order that it will be run.
I discussed this problem with my friend and colleague, Amos King. We came up with a better solution, which puts things back in the right order:
+ def show
+ interactor.get(params[:id]) do |on|
+ on.display { |order| render order }
+ on.not_found { |order_id| render status: 404 }
+ end
+ end
+He even wrote a small library to do this, which he called Riposte. I’m not sure what to call this pattern, but it seems to work pretty well in this situation. I suppose that they’re still technically callbacks, because they’re passed in in the block that’s passed in to the call to interactor.get(). But due to the magic of Ruby blocks, we get to put them in the order they should be.
Riposte also gives you the option of using the response object directly, instead of passing a block:
+ def show
+ on = interactor.get(params[:id])
+ on.display { |order| render order }
+ on.not_found { |order_id| render status: 404 }
+ end
+This shows that it’s just returning an object, with the twist that the response object has methods that take blocks. The nested blocks variant is really the same thing, except that it’s yielding to the response object instead of returning it.
+I’ve decide that is the pattern I’d like to use for interactions and their callers within Ruby hexagonal architecture.
+]]>Somehow my research in that vein led me to Gary Bernhardt’s Boundaries talk. I’ve read a lot about the talk, and knew about the idea of “functional core / imperative shell”. And I’ve worked with a lot of similar ideas lately. But I believe this is the first time that I actually watched the whole video.
+Even after having read a lot about similar ideas, it was pretty mind-expanding. Gary’s really good at presenting these kinds of ideas in a simple way.
+OOP as usually taught includes encapsulation of data together with behavior, with mutable objects. Functional programming separates data and behavior, with mostly immutable data. From experience, encapsulating data and behavior together seems helpful. But experience also shows that immutability is useful. So it would be good to have both of those together. This is something I’ve been thinking for a few years — how best do we get both?
+Gary calls the combination “FauxO”. Logic and data are still combined, but there’s no mutation. Anywhere OOP would normally have mutation would just generate a new object. There’s no language restriction involved in enforcing immutability — just discipline.
+But without mutability, it’s hard to do IO and maintain state. So Gary’s solution is to encapsulate as much as possible into an immutable (functional or FauxO) core, and around that, use an imperative (traditional OOP) shell. The functional core contains the bulk of the logic, and the imperative shell is a glue layer that handles the real world, including disk, network, and other I/O.
+The result of this is that the shell has fewer paths, but more dependencies. The core contains no dependencies, but encapsulates the different logic paths. So we’re encapsulating dependencies on one side, and business logic on the other side. Or put another way, the way to figure out the separation is by doing as much as you can without mutation, and then encapsulating the mutation separately.
+I love how this naturally breaks things up, so that the core is all testable with unit tests, and the imperative shell is tested with integration tests. And since the shell has few or no logic paths, you get the testing pyramid, with more unit tests and fewer integration tests. The whole thing ends up being quite beautiful. Tests end up being very fast without any extra effort — not even stubbing or mocking. This tells us that things have been decomposed very well — an elegant design.
+Gary makes the case that immutable objects can be treated as values, and passed across boundaries. Even process boundaries. This is something I’ve noticed as I’ve been working on my own Uncle Bob style hexagonal framework, but nobody in that camp ever mentioned that — they prefer DTOs or something more like hashes. I’m completely against hashes, because of the “stringly-typed” problem. And I don’t see much advantage in a DTO if I’ve got an immutable object; I’d be basically copying the object to an almost identical object. And I’d be losing any laziness possible for derived values within the original immutable object.
+It’s striking to me how Gary’s image of an imperative shell around a functional core, plus Net, Disk, and State outside of the shell mirror’s Uncle Bob’s concentric circles. Uncle Bob has entities in the middle, surrounded by use cases, surrounded by Web, DB, and UI.
+Another advantage that Gary shows is that breaking things up this way allows easy concurrency. In his example, he shows using the actor model — either just using threads and queues, or an actor library (or language feature).
+After several years of thinking about the architectural issues seen in most large Rails apps, I’m starting to come to an understanding of how to combine all these ideas and come up with an architecture that will work better.
++]]>
I got pretty lucky on this one. My main contract with Mercy got extended several times. Amos and I must have been doing a good job of keeping the customer happy. We even made it through a couple rounds of layoffs. I’m wrapping up the gig at Mercy now. I’m working one day a week there, as the project winds down.
+I also started a new gig this month at CenturyLink. I’m working on a cloud development team. Our current project involves selling WordPress as a service. The manager had been courting me for most of the year. I’m excited about my new role; I’ll be writing about it in a blog post soon.
+I set a goal in 2014 to give my first conference talk. I accomplished that, giving an ambitious talk at RubyConf. I enjoyed having done that, and vowed to do more conference speaking.
+I gave 3 conference talks in 2015. I gave a workshop on HTTP at RailsConf. I talked about immutable infrastructure at Madison+ Ruby. At RubyConf, I gave a talk on a micro-ORM I wrote. I also gave a lightning talk about Agile estimation (#noestimates).
+I was an alternate speaker at Windy City Rails, but did not give my talk on Alternatives to ActiveRecord. I also went to Strange Loop, mainly to see several friends and acquaintances speak.
+I wrote 24 blog articles this year. That’s about one every other week. What really kept me going was participating in a writing pact. When the pact was going, I had a 75% blogging rate. That’s pretty good.
+I’m not so sure about the quality of my blog writing though. I know that practicing writing is supposed to make you better. I know I wrote some really good articles over the past year, but I think I also wrote some articles that weren’t very good. I think sometimes the deadline has caused more harm than good. I’m not really sure what to do about that; perhaps just pushing on is the right answer.
+I’ve taken a lot of notes on the design of my programming language. Any time I learn something interesting about another language, or come up with another idea, I write it down.
+But I haven’t worked on the implementation. (I last worked on the implementation in 2014.) I should be experimenting with some ideas, implementing them to see how they work out. I’ve even kicked around the idea of starting with a Forth variant, just to get something working quickly.
+I haven’t written any articles on my ideas this year either. My notes are pretty extensive, and it would be good to write some articles to help get my thoughts straight.
+I’ve got some things to say about Agile, and want to write a book to express those ideas. I’ve made a start — I’ve got the chapters outlines, and have started on a few chapters. But I haven’t made as much progress as I’d like to. I shared what I’ve got with Amos, and he showed some interest in pairing with me on the writing. Hopefully we’ll work on it together in 2016 and publish it.
+There were a few other accomplishments that weren’t explicitly on my list, but I’d like to call attention to.
+I’ve continued participating on the This Agile Life podcast. I was in 12 of the 33 episodes that were recorded in 2015. I hope to participate in more in 2016. We’re considering scheduling a standard recording night each week, which might help us record more regularly.
+I recently took over as maintainer of Virtus, a library to declare attributes for Ruby model classes. I haven’t done a lot yet, since I’ve been busy with travel, vacation, and holidays. But I hope to catch up with all the pending pull requests and issues in the next month or so.
+The accomplishment I’m most proud of is mentoring for the Roy Clay Sr. Tech Impact program. This is a program begun as a result of the Ferguson protest movement. We’re helping teach kids (from 14 to 25) web design and development. My personal goal was to give these kids an opportunity that they would not have otherwise had. But it turned out that some of them have actually started a business building web sites for small companies. I’m so proud of the progress they’ve made in such a short time; it’s a challenging program.
+I’m pretty happy with my accomplishments this year. I made at least some progress on each of the goals I set. I’ve been thinking about my goals for next year; I’ll write that as a separate blog article next week.
+]]>Back then, Sears and other retail stores had Commodore 64 computers out on display. Whenever I went to the store, I’d write a short BASIC program and leave it running on the display computers:
+10 PRINT "CRAIG IS GREAT!" +20 GOTO 10+
Hey, I was a 13-year-old kid. Later, I got a little more sophisticated. I’d change the background color instead. I still remember the POKE address:
+10 FOR I=0 TO 255 +20 POKE 53281, I +30 NEXT I +40 GOTO 10 +RUN+
This was fast enough to change the background color every few scan lines, creating a flashing scrolling effect.
+Later, I learned 6502 assembly language. I translated the BASIC program into assembler, and memorized the bytes to type in at the store. In assembly language, the background color would change several times per scan line. The effect was kind of psychedelic.
+All that happened in the mid-1980s.
+Fast-forward to about 2000 or so. I was telling the above story after a St. Louis LUG meeting. I explained how I had memorized the 10 or 12 bytes of machine code, and would leave the program running with its psychedelic effect.
+After thinking about it for a bit, I thought that 10 or 12 bytes seemed too much. It actually bothered me — I couldn’t fall asleep when I got home. I got up and found my old 6502 manuals. I figured out how to write the code in 7 bytes. I installed the Vice C64 emulator on my Linux desktop, and tested my code. It worked as expected. (The emulator was already clock-cycle perfect by then.) Here’s the assembly code:
+INX ; $E8 ; 232 +STX $D021 ; $8E $21 $D0 ; 142 33 208 ; $D021 = 53281 +JMP $C000 ; $4C $00 $C0 ; 76 0 192 ; $C000 = 49152+
Here’s the BASIC program to store that program in memory and run it:
+10 FOR N=49152 TO 49152+6: READ Q : POKE N, Q : NEXT +20 DATA 232, 142, 33, 208, 76, 0, 192 +30 SYS 49152 +RUN+
The moral of the story is that you can optimize even a 10-byte program, 15 years after the last time it was used. So don’t tell me that your program can’t be improved, no matter how small it is.
+PS. I rewrote the code above while writing this article in 2015, about 15 years after the last time I rewrote it. And I again downloaded Vice to test it, this time on Mac OS X.
+]]>The problem is that we used callbacks (actually, a publish/subscribe mechanism) in a situation where they don’t seem to quite fit:
+ def show
+ interactor.on(:display) { |order| render order }
+ interactor.on(:not_found) { |order_id| render status: 404 }
+ interactor.get(params[:id])
+ end
+What we really want is to respond in different ways, depending on the result of the call to interactor.get(). There’s no good reason to define the responses before the call. It makes a lot more sense to define the responses after the call, because they’ll happen after the call. I’d much prefer that the code be written in the order that it will be run.
I discussed this problem with my friend and colleague, Amos King. We came up with a better solution, which puts things back in the right order:
+ def show
+ interactor.get(params[:id]) do |on|
+ on.display { |order| render order }
+ on.not_found { |order_id| render status: 404 }
+ end
+ end
+He even wrote a small library to do this, which he called Riposte. I’m not sure what to call this pattern, but it seems to work pretty well in this situation. I suppose that they’re still technically callbacks, because they’re passed in in the block that’s passed in to the call to interactor.get(). But due to the magic of Ruby blocks, we get to put them in the order they should be.
Riposte also gives you the option of using the response object directly, instead of passing a block:
+ def show
+ on = interactor.get(params[:id])
+ on.display { |order| render order }
+ on.not_found { |order_id| render status: 404 }
+ end
+This shows that it’s just returning an object, with the twist that the response object has methods that take blocks. The nested blocks variant is really the same thing, except that it’s yielding to the response object instead of returning it.
+I’ve decide that is the pattern I’d like to use for interactions and their callers within Ruby hexagonal architecture.
+]]>Somehow my research in that vein led me to Gary Bernhardt’s Boundaries talk. I’ve read a lot about the talk, and knew about the idea of “functional core / imperative shell”. And I’ve worked with a lot of similar ideas lately. But I believe this is the first time that I actually watched the whole video.
+Even after having read a lot about similar ideas, it was pretty mind-expanding. Gary’s really good at presenting these kinds of ideas in a simple way.
+OOP as usually taught includes encapsulation of data together with behavior, with mutable objects. Functional programming separates data and behavior, with mostly immutable data. From experience, encapsulating data and behavior together seems helpful. But experience also shows that immutability is useful. So it would be good to have both of those together. This is something I’ve been thinking for a few years — how best do we get both?
+Gary calls the combination “FauxO”. Logic and data are still combined, but there’s no mutation. Anywhere OOP would normally have mutation would just generate a new object. There’s no language restriction involved in enforcing immutability — just discipline.
+But without mutability, it’s hard to do IO and maintain state. So Gary’s solution is to encapsulate as much as possible into an immutable (functional or FauxO) core, and around that, use an imperative (traditional OOP) shell. The functional core contains the bulk of the logic, and the imperative shell is a glue layer that handles the real world, including disk, network, and other I/O.
+The result of this is that the shell has fewer paths, but more dependencies. The core contains no dependencies, but encapsulates the different logic paths. So we’re encapsulating dependencies on one side, and business logic on the other side. Or put another way, the way to figure out the separation is by doing as much as you can without mutation, and then encapsulating the mutation separately.
+I love how this naturally breaks things up, so that the core is all testable with unit tests, and the imperative shell is tested with integration tests. And since the shell has few or no logic paths, you get the testing pyramid, with more unit tests and fewer integration tests. The whole thing ends up being quite beautiful. Tests end up being very fast without any extra effort — not even stubbing or mocking. This tells us that things have been decomposed very well — an elegant design.
+Gary makes the case that immutable objects can be treated as values, and passed across boundaries. Even process boundaries. This is something I’ve noticed as I’ve been working on my own Uncle Bob style hexagonal framework, but nobody in that camp ever mentioned that — they prefer DTOs or something more like hashes. I’m completely against hashes, because of the “stringly-typed” problem. And I don’t see much advantage in a DTO if I’ve got an immutable object; I’d be basically copying the object to an almost identical object. And I’d be losing any laziness possible for derived values within the original immutable object.
+It’s striking to me how Gary’s image of an imperative shell around a functional core, plus Net, Disk, and State outside of the shell mirror’s Uncle Bob’s concentric circles. Uncle Bob has entities in the middle, surrounded by use cases, surrounded by Web, DB, and UI.
+Another advantage that Gary shows is that breaking things up this way allows easy concurrency. In his example, he shows using the actor model — either just using threads and queues, or an actor library (or language feature).
+After several years of thinking about the architectural issues seen in most large Rails apps, I’m starting to come to an understanding of how to combine all these ideas and come up with an architecture that will work better.
++]]>
So inspired by PJ Hagerty’s recent article on alternative Ruby web frameworks, I started thinking about how I’d write a replacement for Rails. I’d definitely keep the basic MVC framework. But I’d also want to implement a more hexagonal architecture.
+I started sketching out what this would look like, but I ended up starting with a Rails controller and finding the simplest way to make it hexagonal. I really don’t like callbacks, because they make tracing program execution difficult. But I didn’t see any other alternative. I found a simple pub/sub Ruby library called Wisper. It literally has only publish, subscribe, and on methods. (You use on to register single callbacks via blocks, and subscribe to register an object with method names corresponding to the callback names.)
The trick was figuring out how to break the controller into 2 pieces. What finally helped me was to find the single responsibilities of the 2 pieces. The Rails controller would remain in charge of managing the web interface, but would delegate to the other piece to handle any application-specific business logic. I decided to re-watch Uncle Bob Martin’s “Architecture The Lost Years” talk, which was the first time I was introduced to the ideas of Hexagonal Architecture. (He doesn’t name the architecture in the talk, but later calls it Clean Architecture.) He does a decent job of explaining how to break these 2 pieces apart. He used the term “interactor” in that talk, so I decided to go with that. He said that Jacobsen calls it a Control Object in Object Oriented Software Engineering, but that’s too close to Rails’s “controller”.
+So here’s an example of what I ended up with:
+class OrderController < ApplicationController
+ def index
+ interactor.on(:display) { |orders| render orders }
+ interactor.list
+ end
+
+ def show
+ interactor.on(:display) { |order| render order }
+ interactor.on(:not_found) { |order_id| render status: 404 }
+ interactor.get(params[:id])
+ end
+
+private
+
+ def interactor
+ @interactor ||= OrderInteractor.new
+ end
+end
+require "wisper" +require "order" + +class OrderInteractor + include Wisper.publisher + + def list + orders = Order.all + publish(:display, orders) + end + + def get(id) + order = Order.find(id) + publish(:display, order) + rescue ActiveRecord::RecordNotFound + publish(:not_found, id) + end +end+
I do have a few problems with this solution though. I’m not a fan of the name “interactor” for the business logic. I thought about calling it OrderOperator, or maybe OrderOperations, because it’s really a collection of operations. Perhaps it would be better to separate each operation into a separate class. Trailblazer does it that way. And for more complicated business logic, I would do that too, using the Method Object pattern. But like a Rails controller, there’s a lot in common among all the operations. I feel like a separate class for each operation for each would create too many coupled classes.
I’m also uncomfortable with the fact that the controller is delegating almost everything to the interactor. I guess this is OK, but it feels like there’s too little left when every line starts with interactor. I suppose extracting things some more would help mitigate this concern I’ll likely write a small gem to perform that extraction. I expect that that will allow a typical controller to be written in only a few lines. And maybe the same for the interactor side.
With the business logic extracted out of the controller, it was really easy for me to write a command-line version of the app. As Uncle Bob says, “the web is not particularly important to your application.”
+I’ve put the code for this example on GitHub: https://github.com/boochtek/hexagonal-rails. I’ll likely experiment with it some more over the next few weeks and months.
+]]>Last year I wrote a blog entry listing my goals for 2014. As far as New Year’s resolutions go, I was relatively successful — about 50% of my goals accomplished. Unfortunately, my Open Source contributions weren’t as strong as I had hoped; while I released some of my own work, I didn’t do much else. I did increase my blogging; getting in on a weekly blogging pact helped immensely. I also increased my participation on the This Agile Life podcast to a level that I’m happy with. But the accomplishment I’m most proud of was giving a presentation at RubyConf.
+I’d like to keep things rolling from last year, but crank up a few things. My plans are quite ambitious, so I don’t expect to get everything done by any means. But I think by setting the bar high, I’ll end up with a lot I can be proud of.
+Late last year, I took the jump into independent consulting. So far, I’ve really enjoyed it, and I’m booked up through April. My wife graduates in May, so we’ve got the possibility of moving if that makes sense. So I’ll be looking for consulting projects in town, but I’ll also be looking at jobs in San Francisco and Chicago. The possibilities are exciting, and I’ll be taking my time to find something just right.
+I was incredibly nervous leading up to my RubyConf presentation. Part of that was just the common fear of public speaking. For me, that only kicks in at around 100 people, and this audience was around 250. I think another reason was that I chose a really ambitious topic, and I kept finding more that I wanted to talk about, but wasn’t prepared for. But I think I did a pretty good job presenting an advanced topic. And I was so pumped by the sense of accomplishment as soon as I finished. So I’m hoping to do it more. I’ve already submitted a couple proposals, and plan to submit several more.
+I believe that blogging is important for me to get my thoughts down — for myself and to share with others. I was really successful last year when I had a partner to keep me honest, via a pact. So I’ve started up another pact this year, which will hopefully ensure I’ll keep things going. I’ve got a really long backlog of topics, so as long as I keep at it, I’ll have plenty to write about.
+I also want to move away from WordPress to a static system — probably Middleman. I’ve got 2 major problems with WordPress. First, I no longer trust its security, nor the security of any application written in PHP. Second, it generates HTML every time someone requests a page, instead of when the content is updated. I find that to be a waste of resources, and problematic from a security standpoint. The main problem with moving to a static blogging system is that I really want to allow comments, pingbacks, and tweetbacks. So I’ll have to find a way to integrate those.
+Last year I started thinking about programming language design, and started implementing a language tentatively called Brilliant. I’ve done a lot more thinking on the topic, and have a lot of notes. But I haven’t implemented much more yet. This year, I’d like to get my thoughts more organized, and write a series of blog posts on various aspects of language design. The most interesting part seems to be the trade-offs involved in the ways that various language features interact. So I’d like to make some progress on the language implementation, but more importantly, I’d like to get a lot of my design ideas written down.
+I’m also going to spend a lot of time learning a bunch more programming languages, so I have a better understanding of possible features, combinations of features, and their interactions. I’ve already start with Elixir, Clojure, and Racket. I’m hoping to also look at OCaml, Factor, and Haskell. I’ll probably also take a look at the 2 “Seven Languages in Seven Weeks” books.
+I think people often have trouble getting started with Agile. I started on a book last year, and got down quite a lot of good ideas. But I realized that I’m going to have a hard time organizing all those ideas into something coherent. Still, I’d like to try to get something out there that lets people get started with Agile. My idea is to present a toolbox of practices to get started with and build on that foundation over time with additional practices. Sort of a playbook on how to get started over the first 6 to 12 months and be successful. I want to make some progress on the book, at least enough to decide whether it’s worth the effort to finish it and self-publish it.
++]]>
Let’s say you want to include an ORM in a model class, and want to tell it what database table to use. Typically, you’d do this:
+class User + include MyORM::Model + table 'people' +end+
But that table call is more like an option to the module inclusion than anything else. So what we’d really like is something like this:
class User + include MyORM::Model, table: 'people' +end+
But that’s not valid Ruby; include doesn’t let you pass anything other than a module.
So when I was learning about Virtus, I noticed that its example of how to include it is a bit different than the standard Ruby idiomatic include:
class User + include Virtus.model +end+
At first glance, it reads like the first example. But on closer inspection and consideration, it’s quite a bit different. Where MyORM::Model is a constant that refers to a module, Virtus.model is a method call. So there’s a method named model in the Virtus module. That method returns another module — which is exactly what’s needed in order to include it into our model class.
The easiest way to implement Virtus.model would be this:
module Virtus + def model + ::Virtus::Model + end +end + +module Virtus::Model + # ... +end+
If Virtus.model doesn’t need to take any arguments, that’s perfectly fine. In fact, I’ve started to use this implementation of the pattern for modules that don’t need parameters.
Because Virtus.model is a method, we can also call it with options:
class User + include Virtus.model(constructor: false, mass_assignment: false) +end+
We could even pass a block. But how do we process those options? There are a few different ways. However we do it, we have to be sure to return a module. And we can create modules in a few different ways.
+Virtus uses the builder pattern. It takes the parameters passed in and builds a module dynamically. By that, I mean that it calls Module.new and then adds methods to that module. It does this by mixing in other modules, but it could do it by dynamically defining methods as well.
I’ve never seen this pattern in any other language. It’s obviously only possible because we can dynamically create modules.
+The use of this idiom seems to be catching on a bit in the Ruby community. I’ve started using it myself, and will be adding it to my Includable::ActiveRecord gem soon.
++
+]]>
I’ve been interested in programming languages and linguistics almost as long as I’ve been using computers. I’ve long thought that if I ever go back to college, it’s likely that I’ll concentrate on programming languages as a specialty.
+My recent discovery and involvement with the Crystal programming language has gotten me excited about new language ideas. It’s also helped me realize that implementing a language myself is feasible, and that there’s no better time to start than now.
+For now, the Brilliant implementation doesn’t let you do much more than “Hello World”. But you gotta start somewhere. So this article isn’t really “Introducing Brilliant” so much as the start of a series of articles on its design and implementation.
+I wanted to use a PEG (parsing expression grammar) parser for several reasons. For one, they seem to have gained a lot of popularity in the past few years. Also, PEGs cannot be ambiguous, which can solve a few difficult problems, such as the “dangling else“. Perhaps my favorite feature of PEG grammars is that you don’t need a separate tokenizer (lexer). This provides a nice advantage in that we can use keywords like “class” as variables, as long as they’re not used in a place where the keyword would make sense.
So knowing that I wanted to use a PEG, I had to find a PEG parser. I kind of wanted to use ANTLR, which has been a leading parser for many years. But the PEG seems to be new to version 4, and I couldn’t find any Ruby bindings for version 4. Treetop seems to be the most popular parser for Ruby, but I found the EBNF format that Rattler uses to be more to my taste. I think the fact that it’s newer also gives it a few advantages, having had a chance to learn some lessons from Treetop.
+I thought about using the Rubinius VM, but decided to go with LLVM, mainly since it has slightly better docs for Ruby, and because it’s what Crystal uses. Also, it’s pretty easy to get it to compile to a binary executable or run in a JIT. In the future, I might consider switching to the Rubinius VM, the Erlang VM, or the Perl 6 VM (Parrot). But for now, I like the idea of being able to compile to a binary and easily interface with C, just like Crystal.
+My main goal is to have fun playing around with language ideas.
+I’ve found a really great language in Ruby, so I’ll be using it as a starting point. But Ruby does have its faults. In some ways, I want to answer the question “what would Ruby look like if we designed it today?”.
+But I also want to explore other ideas. What if objects defaulted to immutable? What if functions and methods were assumed to be pure by default? Might it be possible to infer the purity of a function or method? (If so, we could automatically memoize them.) Can we make creating an actor as easy as creating an object?
+I’ll also be looking at ideas from other programming languages. Could we get some of the benefits of Haskell’s purity without having to do somersaults to do IO? Could we mix Python’s indentation style scoping with brace style or begin/end style? Could we integrate Icon’s ideas about success and failure (goal-directed execution)? What interesting features can we pull from Ada, Io, CoffeeScript, Crystal, Rubinius, Perl 6, etc.?
+
I’m not so much as interested in cutting-edge features, as in features that can be easily used by the average programmer. More importantly, I’m interested in how features interact with each other, so they fit well together to create a whole that’s greater than the sum of the parts.
+I wanted to name my programming language “Fermat”. I’ve long been intrigued by Fermat’s Last Theorem, and Fermat’s Little Theorem is important in number theory. Unfortunately, there’s already a computer algebra system with that name.
+So I decided to find a name in the same vein as “Ruby” and “Crystal”. I looked at the Wikipedia page for “gemstones” for some inspiration. A lot of the names of gemstones are already taken. I considered some obscure gemstones, but saw the word “brilliant” and thought it was decent. It’s not the name of another gemstone, but still evokes some similarity to Ruby and Crystal.
+So that’s the name for now. Perhaps I’ll decide to change it at some point in the future, but I needed a name for the project, as well as a file extension for source code files. I chose “bril” for that. I suppose “br” would be a better choice. Perhaps I’ll change that before the next article in this series.
I hope to work on Brilliant every once in a while. I expect it’ll take a couple years before it’s really very useful.
+When I do add a major feature, I’ll be certain to blog about it. I’ve got tons of ideas strewn about in various files. It would be great to get them organized and published —and even better to get them implemented.
+]]>+Slow down.
This is probably good advice for most programmers. Our team recently noticed that every time we try to rush things, we make mistakes. And the mistakes end up costing us more time than if we had just done things at our normal pace. Slowing down ensures that you do things right, and when you do things right, you end up with a higher-quality product.
+There are 2 types of code quality: internal and external. External code quality can be measured by how many bugs have been reported by customers. Internal code quality is harder to measure, but it mainly deals with the ability to change the code. When your internal quality is low, you’ve got lots of technical debt, and it’s harder to make changes.
+So when you try to write code quickly, code quality decreases, leading to a code base that takes more time to make changes to. Conversely, when you slow down, your code quality improves, and it becomes easier to make changes more quickly. So when writing code, slowing down in the short run leads to a speed-up in the long run.
+But writing code isn’t the only place where we try to speed up. On an Agile team, we’re always trying to improve the way we work — especially at the beginning stages of an Agile transformation. So we’re eager to make changes in our processes. But I’d urge you to slow down here as well.
+My colleague Amos and I frequently argue over pair switching. It’s funny, because we agree on everything except for 1 small detail. We both think pair switching is very important, to ensure that team members see more of what’s going on, to bring more ideas to each story, to prevent knowledge silos, and to encourage team ownership. Where we disagree is how long an ideal pairing session should last. I think pairs should switch every 2 hours, and he thinks 1 hour is ideal. I’ve seen teams reach the 1 hour pairing sessions successfully. But usually not without some pain and even often failing at the first attempt.
+There’s nothing inherently wrong with failing. But if you fail at something, you’re not likely to try again. After all, you should learn from your failures, right?
+So if you want your team to do something, you probably don’t want them to fail at it. If they fail, they won’t want to try a second time. That’s just human nature, and learning from failure. While you might think that they failed because they weren’t ready for the change yet, they’ll most likely think that they failed because this particular change won’t work for their situation. And they probably won’t know what to change when trying again, so they won’t try again.
+I’ve seen this over and over. Back when Linux was up-and-coming, when a consultant pushed a company into using Linux before they were ready for it, and it didn’t work out, that company was cautious about trying again. So instead of being on the leading edge of using Linux, or even the middle of the pack, they ended up more toward the trailing edge. Had they not been pushed, they would have gotten more benefit in the long run.
+So my advice in process improvement is the same as in programming: slow down. Take small steps toward what you think is the ideal. Make a small change, see how it works out, and adjust. As long as you’re still moving in the right direction, I believe you’ll move faster by taking small steps than by trying to make big leaps.
+]]>The term “burying the lede” comes from the field of journalism. Here’s the Wiktionary definition:
++To begin a story with details of secondary importance to the reader while postponing more essential points or facts.
Like a good news article, code should tell a story. And the story should start with what’s most important. In the case of code, the most important information is the high-level functionality — a succinct summary of what the program does. In other words, write (and organize) the code top-down, as opposed to bottom-up.
+Unfortunately, shell script doesn’t make this easy. Due to the way shell scripts are interpreted, you can’t call a function until after you’ve defined it. This leads to most of us structuring our code like this:
+function do_something { ... }
+function do_something_else { ... }
+
+do_something
+do_something_else
+The problem with this is that the function definitions will likely take quite a few lines, and we won’t see what the top-level functionality is until we reach the end of the script.
+I’d like to propose a standard way to structure shell scripts to mitigate this issue. (I’m really only talking about shell scripts that have function definitions within them.) I’m sure I’ve seen a few scripts do this, but it’s not very common at all.
+My proposal is simple:
+function main {
+ do_something
+ do_something_else
+}
+function do_something { ... }
+function do_something_else { ... }
+
+main
+This structure lets us start with the lede. We describe the top-level functionality right away. Only then do we get to the secondary details. The name main makes it pretty clear that it contains the top-level functionality.
I’ve recently started writing my shell code like this, and I’m happy with the results. I’ve also started to use some other programming techniques in my shell scripts to improve readability: better naming, extracting more methods, and moving helper methods into separate files. It feels good to treat shell scripts like real code instead of just some stuff I’ve hacked together.
+PS. The WordPress theme I’m currently using (Twenty Eleven) also buries the lede — I can barely even see the title of the blog post on my screen without scrolling. I’m going to have to change that soon.
+]]>Web Development, Ruby on Rails, Open Source
+I’ve had a long love-hate relationship with Rails. I love the MVC framework and how it’s improved our speed of writing web apps. But I’ve never really been completely happy with it. I don’t generally agree with most of its opinions. I prefer models that follow the Data Mapper pattern, not the Active Record pattern. This includes separating the persistence layer from the models’ business logic. I prefer Slim or HAML to ERB. I prefer RSpec to Test::Unit or MiniTest. When Merb hit the scene, I was ready to make the jump, until Merb merged with Rails.
+So inspired by PJ Hagerty’s recent article on alternative Ruby web frameworks, I started thinking about how I’d write a replacement for Rails. I’d definitely keep the basic MVC framework. But I’d also want to implement a more hexagonal architecture.
+I started sketching out what this would look like, but I ended up starting with a Rails controller and finding the simplest way to make it hexagonal. I really don’t like callbacks, because they make tracing program execution difficult. But I didn’t see any other alternative. I found a simple pub/sub Ruby library called Wisper. It literally has only publish, subscribe, and on methods. (You use on to register single callbacks via blocks, and subscribe to register an object with method names corresponding to the callback names.)
The trick was figuring out how to break the controller into 2 pieces. What finally helped me was to find the single responsibilities of the 2 pieces. The Rails controller would remain in charge of managing the web interface, but would delegate to the other piece to handle any application-specific business logic. I decided to re-watch Uncle Bob Martin’s “Architecture The Lost Years” talk, which was the first time I was introduced to the ideas of Hexagonal Architecture. (He doesn’t name the architecture in the talk, but later calls it Clean Architecture.) He does a decent job of explaining how to break these 2 pieces apart. He used the term “interactor” in that talk, so I decided to go with that. He said that Jacobsen calls it a Control Object in Object Oriented Software Engineering, but that’s too close to Rails’s “controller”.
+So here’s an example of what I ended up with:
+class OrderController < ApplicationController
+ def index
+ interactor.on(:display) { |orders| render orders }
+ interactor.list
+ end
+
+ def show
+ interactor.on(:display) { |order| render order }
+ interactor.on(:not_found) { |order_id| render status: 404 }
+ interactor.get(params[:id])
+ end
+
+private
+
+ def interactor
+ @interactor ||= OrderInteractor.new
+ end
+end
+require "wisper" +require "order" + +class OrderInteractor + include Wisper.publisher + + def list + orders = Order.all + publish(:display, orders) + end + + def get(id) + order = Order.find(id) + publish(:display, order) + rescue ActiveRecord::RecordNotFound + publish(:not_found, id) + end +end+
I do have a few problems with this solution though. I’m not a fan of the name “interactor” for the business logic. I thought about calling it OrderOperator, or maybe OrderOperations, because it’s really a collection of operations. Perhaps it would be better to separate each operation into a separate class. Trailblazer does it that way. And for more complicated business logic, I would do that too, using the Method Object pattern. But like a Rails controller, there’s a lot in common among all the operations. I feel like a separate class for each operation for each would create too many coupled classes.
I’m also uncomfortable with the fact that the controller is delegating almost everything to the interactor. I guess this is OK, but it feels like there’s too little left when every line starts with interactor. I suppose extracting things some more would help mitigate this concern I’ll likely write a small gem to perform that extraction. I expect that that will allow a typical controller to be written in only a few lines. And maybe the same for the interactor side.
With the business logic extracted out of the controller, it was really easy for me to write a command-line version of the app. As Uncle Bob says, “the web is not particularly important to your application.”
+I’ve put the code for this example on GitHub: https://github.com/boochtek/hexagonal-rails. I’ll likely experiment with it some more over the next few weeks and months.
+I created a Ruby gem recently, called includable-activerecord. It’s pretty small, but I thought I might explain why I created it, and discuss its implementation.
+When you use ActiveRecord, you normally include it in your model like this:
+class User < ActiveRecord::Base + # ... +end+
Your User class is inheriting from the ActiveRecord::Base class. This is class-based inheritance, also called “classical” inheritance. (That’s “classical” as in “class”, not as a synonym for “traditional”.) Class-based inheritance represents an “is-a” relationship. So we’re saying that a user is an ActiveRecord base. Another way to say this is that User is a subclass of ActiveRecord::Base.
+
+There are a few problems with this. First, what is a “base”? The name was chosen because it’s a base class. But just like we don’t give factory classes names like UserFactory (at least not in Ruby), we shouldn’t name base classes Base.
I suppose that we’re trying to say that this is an ActiveRecord model. That sounds fine at first glance — this is our model for users. But what if we also want to say that a user is a person? Ruby doesn’t allow inheriting from multiple classes. Now we have to choose whether to inherit from ActiveRecord::Base or Person. Person makes more sense, because it fills the “is-a” rule better. Class inheritance is intended for a hierarchical “is-a” relationship, such as “a user is a person”, or “a circle is a shape”. But since ActiveRecord::Base is a base class, we have to use it as our base class.
We could work around this problem by subclassing Person from ActiveRecord::Base and then subclassing User from Person. That’s fine if Person is also a model that we store in the database. But if that’s not the case, then we have a problem.
Mixins
+Ruby provides another way of implementing inheritance — mixins. We often don’t think of this as an inheritance model, but it really is. When we include a module, that module gets added to the class’s ancestor chain. We can mix in as many modules as we want.
+Mixins indicate more of an “acts like” relationship than an “is-a” relationship. It’s for shared behavior between classes that don’t have a hierarchical relationship. For example, when we mix in the Enumerable module, we’re saying that we want our class to act like other classes that include Enumerable. That sounds more like what we want ActiveRecord to be. We want our user model to behave like other ActiveRecord models, in the way that they can persist to a database.
But ActiveRecord doesn’t support that. Almost all the other Ruby ORMs do; as we’ve shown above, this is for good reasons.
+So I decided to see if I could implement the equivalent of the ActiveRecord::Base class as a module that could be mixed into model classes. I decided to call my mixin module ActiveRecord::Model, because classes that mix it in will behave as ActiveRecord models.
It turns out that ActiveRecord::Base is a pretty complex class. It includes and extends a lot of other modules. Luckily, as of ActiveRecord 4.0, that’s all the code it includes.
The module only defines a single class method, included. This is one of Ruby’s many hook methods. It gets called when the module in question gets included in another module, and receives that other model as its argument. All we need to have this method do is to include everything that ActiveRecord::Base includes, and extend everything that ActiveRecord::Base extends. Ruby provides a method that’s defined on all classes, called included_modules, which we can use to get the list of everything that’s included in ActiveRecord::Base. Unfortunately, there’s no equivalent list of extended_modules. But a quick search on Stack Overflow found an implementation of extended_modules that we could use.
So with a bit of magic (i.e. hooks and meta-programming), we can get the lists of constituent modules from the ActiveRecord::Base class, and include them in our ActiveRecord::Model module.
So with all that, we can now include the includable-activerecord gem and mix it in, with all the advantages that provides:
+class User + include ActiveRecord::Model + # ... +end+
It was exciting to be able to make this work. Since I wrote it as a proof of concept, I haven’t written any tests yet. But it seems to be working just fine. The main thing I really need to look into is making sure that plugins that extend ActiveRecord::Base from their own code will still work. I’m pretty sure this will work out of the box, because the ActiveRecord::Model.included doesn’t run until the model class is loaded, and that happens after those plugins have initialized themselves.
It’s challenging to test Rails custom validators.
+I recently had to write a validator to require that an entered date is before or after a specified date.
+It didn’t seem like writing the validator would be too difficult – I’ve written custom validators before, and date comparisons aren’t all that tricky. But when it came time to write the tests, I ran into several issues. And since I always try to follow TDD / test-first, I was blocked before I even began.
+The biggest issue was the ActiveModel::EachValidator#validates_each API. It’s definitely not a well-designed API. You write your validator as a subclass, overriding validates_each. The method takes a model object, the name of the attribute of the model being tested, and the value of that attribute. You can also get the options passed to the custom validator via the options method. To perform a validation, you have to update the model’s errors hash.
The big flaw in the API is that instead of returning a result, you have to update the model. This needlessly couples the model and the validator. And it violates the Single Responsibility Principle — it has to determine validity of the field, and it has to update the errors hash of the model. This is not conducive to testing. Testing this method requires testing that the side-effect has taken place in the collaborator (model), which means it’s not really a unit test any more.
So to make it easier to unit test the validator, I broke the coupling by breaking it into 2 pieces, one for each responsibility. I moved the responsibility for determining validity to a separate method, which I called errors_for. It returns a hash of the errors found. This simplified the validates_each method to simply take the result of errors_for and update the errors hash of the model:
def validate_each(record, attribute_name, attribute_value) + record.errors[attribute_name].concat(errors_for(attribute_value, options)) +end+
This made it much easier to unit test the errors_for method. This method doesn’t even need to know about the model — only about the value of the attribute we’re trying to validate. We simply pass in the attribute’s value and the options.
So we could write the tests without even pulling in ActiveRecord or any models:
+describe DateValidator do
+ let(:validator) { DateValidator.new(attributes: :attribute_name) }
+ let(:errors) { validator.errors_for(attribute_value, validation_options) }
+
+ describe 'when attribute value is NOT a valid date' do
+ let(:attribute_value) { 'not a valid date' }
+ it { errors.must_include 'is not a valid date' }
+ end
+
+ describe 'when attribute value IS a valid date' do
+ let(:attribute_value) { Date.parse('2013-12-11') }
+ it { errors.must_be :empty? }
+ end
+end
+And the errors_for method looked something like this:
def errors_for(attribute_value, options) + unless attribute_value.is_a?(Date) + return [options.fetch(:message, "is not a valid date")] + end + [] +end+
Integration testing can also be a bit of a challenge. I recommend following the example from this Stack Overflow answer. Basically, create a minimal model object that contains the field and the validation. Then test that the model behaves like you expect with different values and validations.
+So inspired by PJ Hagerty’s recent article on alternative Ruby web frameworks, I started thinking about how I’d write a replacement for Rails. I’d definitely keep the basic MVC framework. But I’d also want to implement a more hexagonal architecture.
+I started sketching out what this would look like, but I ended up starting with a Rails controller and finding the simplest way to make it hexagonal. I really don’t like callbacks, because they make tracing program execution difficult. But I didn’t see any other alternative. I found a simple pub/sub Ruby library called Wisper. It literally has only publish, subscribe, and on methods. (You use on to register single callbacks via blocks, and subscribe to register an object with method names corresponding to the callback names.)
The trick was figuring out how to break the controller into 2 pieces. What finally helped me was to find the single responsibilities of the 2 pieces. The Rails controller would remain in charge of managing the web interface, but would delegate to the other piece to handle any application-specific business logic. I decided to re-watch Uncle Bob Martin’s “Architecture The Lost Years” talk, which was the first time I was introduced to the ideas of Hexagonal Architecture. (He doesn’t name the architecture in the talk, but later calls it Clean Architecture.) He does a decent job of explaining how to break these 2 pieces apart. He used the term “interactor” in that talk, so I decided to go with that. He said that Jacobsen calls it a Control Object in Object Oriented Software Engineering, but that’s too close to Rails’s “controller”.
+So here’s an example of what I ended up with:
+class OrderController < ApplicationController
+ def index
+ interactor.on(:display) { |orders| render orders }
+ interactor.list
+ end
+
+ def show
+ interactor.on(:display) { |order| render order }
+ interactor.on(:not_found) { |order_id| render status: 404 }
+ interactor.get(params[:id])
+ end
+
+private
+
+ def interactor
+ @interactor ||= OrderInteractor.new
+ end
+end
+require "wisper" +require "order" + +class OrderInteractor + include Wisper.publisher + + def list + orders = Order.all + publish(:display, orders) + end + + def get(id) + order = Order.find(id) + publish(:display, order) + rescue ActiveRecord::RecordNotFound + publish(:not_found, id) + end +end+
I do have a few problems with this solution though. I’m not a fan of the name “interactor” for the business logic. I thought about calling it OrderOperator, or maybe OrderOperations, because it’s really a collection of operations. Perhaps it would be better to separate each operation into a separate class. Trailblazer does it that way. And for more complicated business logic, I would do that too, using the Method Object pattern. But like a Rails controller, there’s a lot in common among all the operations. I feel like a separate class for each operation for each would create too many coupled classes.
I’m also uncomfortable with the fact that the controller is delegating almost everything to the interactor. I guess this is OK, but it feels like there’s too little left when every line starts with interactor. I suppose extracting things some more would help mitigate this concern I’ll likely write a small gem to perform that extraction. I expect that that will allow a typical controller to be written in only a few lines. And maybe the same for the interactor side.
With the business logic extracted out of the controller, it was really easy for me to write a command-line version of the app. As Uncle Bob says, “the web is not particularly important to your application.”
+I’ve put the code for this example on GitHub: https://github.com/boochtek/hexagonal-rails. I’ll likely experiment with it some more over the next few weeks and months.
+]]>When you use ActiveRecord, you normally include it in your model like this:
+class User < ActiveRecord::Base + # ... +end+
Your User class is inheriting from the ActiveRecord::Base class. This is class-based inheritance, also called “classical” inheritance. (That’s “classical” as in “class”, not as a synonym for “traditional”.) Class-based inheritance represents an “is-a” relationship. So we’re saying that a user is an ActiveRecord base. Another way to say this is that User is a subclass of ActiveRecord::Base.
+
+There are a few problems with this. First, what is a “base”? The name was chosen because it’s a base class. But just like we don’t give factory classes names like UserFactory (at least not in Ruby), we shouldn’t name base classes Base.
I suppose that we’re trying to say that this is an ActiveRecord model. That sounds fine at first glance — this is our model for users. But what if we also want to say that a user is a person? Ruby doesn’t allow inheriting from multiple classes. Now we have to choose whether to inherit from ActiveRecord::Base or Person. Person makes more sense, because it fills the “is-a” rule better. Class inheritance is intended for a hierarchical “is-a” relationship, such as “a user is a person”, or “a circle is a shape”. But since ActiveRecord::Base is a base class, we have to use it as our base class.
We could work around this problem by subclassing Person from ActiveRecord::Base and then subclassing User from Person. That’s fine if Person is also a model that we store in the database. But if that’s not the case, then we have a problem.
Mixins
+Ruby provides another way of implementing inheritance — mixins. We often don’t think of this as an inheritance model, but it really is. When we include a module, that module gets added to the class’s ancestor chain. We can mix in as many modules as we want.
+Mixins indicate more of an “acts like” relationship than an “is-a” relationship. It’s for shared behavior between classes that don’t have a hierarchical relationship. For example, when we mix in the Enumerable module, we’re saying that we want our class to act like other classes that include Enumerable. That sounds more like what we want ActiveRecord to be. We want our user model to behave like other ActiveRecord models, in the way that they can persist to a database.
But ActiveRecord doesn’t support that. Almost all the other Ruby ORMs do; as we’ve shown above, this is for good reasons.
+So I decided to see if I could implement the equivalent of the ActiveRecord::Base class as a module that could be mixed into model classes. I decided to call my mixin module ActiveRecord::Model, because classes that mix it in will behave as ActiveRecord models.
It turns out that ActiveRecord::Base is a pretty complex class. It includes and extends a lot of other modules. Luckily, as of ActiveRecord 4.0, that’s all the code it includes.
The module only defines a single class method, included. This is one of Ruby’s many hook methods. It gets called when the module in question gets included in another module, and receives that other model as its argument. All we need to have this method do is to include everything that ActiveRecord::Base includes, and extend everything that ActiveRecord::Base extends. Ruby provides a method that’s defined on all classes, called included_modules, which we can use to get the list of everything that’s included in ActiveRecord::Base. Unfortunately, there’s no equivalent list of extended_modules. But a quick search on Stack Overflow found an implementation of extended_modules that we could use.
So with a bit of magic (i.e. hooks and meta-programming), we can get the lists of constituent modules from the ActiveRecord::Base class, and include them in our ActiveRecord::Model module.
So with all that, we can now include the includable-activerecord gem and mix it in, with all the advantages that provides:
+class User + include ActiveRecord::Model + # ... +end+
It was exciting to be able to make this work. Since I wrote it as a proof of concept, I haven’t written any tests yet. But it seems to be working just fine. The main thing I really need to look into is making sure that plugins that extend ActiveRecord::Base from their own code will still work. I’m pretty sure this will work out of the box, because the ActiveRecord::Model.included doesn’t run until the model class is loaded, and that happens after those plugins have initialized themselves.
I recently had to write a validator to require that an entered date is before or after a specified date.
+It didn’t seem like writing the validator would be too difficult – I’ve written custom validators before, and date comparisons aren’t all that tricky. But when it came time to write the tests, I ran into several issues. And since I always try to follow TDD / test-first, I was blocked before I even began.
+The biggest issue was the ActiveModel::EachValidator#validates_each API. It’s definitely not a well-designed API. You write your validator as a subclass, overriding validates_each. The method takes a model object, the name of the attribute of the model being tested, and the value of that attribute. You can also get the options passed to the custom validator via the options method. To perform a validation, you have to update the model’s errors hash.
The big flaw in the API is that instead of returning a result, you have to update the model. This needlessly couples the model and the validator. And it violates the Single Responsibility Principle — it has to determine validity of the field, and it has to update the errors hash of the model. This is not conducive to testing. Testing this method requires testing that the side-effect has taken place in the collaborator (model), which means it’s not really a unit test any more.
So to make it easier to unit test the validator, I broke the coupling by breaking it into 2 pieces, one for each responsibility. I moved the responsibility for determining validity to a separate method, which I called errors_for. It returns a hash of the errors found. This simplified the validates_each method to simply take the result of errors_for and update the errors hash of the model:
def validate_each(record, attribute_name, attribute_value) + record.errors[attribute_name].concat(errors_for(attribute_value, options)) +end+
This made it much easier to unit test the errors_for method. This method doesn’t even need to know about the model — only about the value of the attribute we’re trying to validate. We simply pass in the attribute’s value and the options.
So we could write the tests without even pulling in ActiveRecord or any models:
+describe DateValidator do
+ let(:validator) { DateValidator.new(attributes: :attribute_name) }
+ let(:errors) { validator.errors_for(attribute_value, validation_options) }
+
+ describe 'when attribute value is NOT a valid date' do
+ let(:attribute_value) { 'not a valid date' }
+ it { errors.must_include 'is not a valid date' }
+ end
+
+ describe 'when attribute value IS a valid date' do
+ let(:attribute_value) { Date.parse('2013-12-11') }
+ it { errors.must_be :empty? }
+ end
+end
+And the errors_for method looked something like this:
def errors_for(attribute_value, options) + unless attribute_value.is_a?(Date) + return [options.fetch(:message, "is not a valid date")] + end + [] +end+
Integration testing can also be a bit of a challenge. I recommend following the example from this Stack Overflow answer. Basically, create a minimal model object that contains the field and the validation. Then test that the model behaves like you expect with different values and validations.
+]]>Web Development, Ruby on Rails, Open Source
+I recently decided to start using Emacs again. I used it extensively from the early 1990s until the early 2000s. I pretty much stopped using it when I had a sysadmin job with no Emacs on the servers, and no ability to install it. With the rising popularity of tmux and tmate for remote pairing, and my dislike for vim’s modes, I decided to try going back to Emacs in the terminal.
+One thing I really want in a text editor is good cursor key support. Shifted cursor keys
+should select text, and Control+left and right should move by words. (Apple HIG says to use Option+left and right to move by words; most apps on Mac OS X seem to support both.) Things have worked this way on almost every text editor on every OS I’ve used — Amiga, DOS, Windows, NeXT, Mac, Motif, Gnome, KDE. It’s a part of the CUA standard that’s been in common usage on everything since the mid-1980s.
Enabling cursor keys in Emacs was pretty easy. I’ve decided to use Prelude to make getting started with Emacs easy. Emacs comes with the cursor keys enabled, but Prelude disables them. Undoing Prelude’s change is pretty easy:
+(setq prelude-guru nil)+
Trying to make shifted cursor keys work is where the trouble began. They work in the GUI version of Emacs, but not from the terminal. It turns out that the Mac Terminal doesn’t distinguish between cursor keys and shifted cursor keys in its default configuration. So I had to figure out how to configure key bindings in Terminal.
+That’s easy enough — they’re in the preferences. But what should I set them to? This took a lot of research. Terminal emulation and ANSI code sequences are obscure, complex, and inconsistent. I eventually found the info I needed. For starters, Shift+Right, Shift+Left, Shift+Home, and Shift+End are defined in the terminfo. The rest I was able to piece together from various sources around the Internet.
+I’m also trying to script my Mac configuration. So instead of manually adding all the keybindings in the Terminal preferences pane, I decided to write a script. Mac OS X does a decent job of allowing you to change preferences from the command line. For example, to always show the tab bar:
+defaults write -app Terminal ShowTabBar 1+
Easy enough, except for a couple problems. First, I had to figure out the obscure syntax used in the preferences for key codes. I was able to piece these together with some more Internet research. But the really big problem is that the keyboard bindings are 2 levels deep within a “dictionary” (hash map). And the defaults command doesn’t handle that. There are some obscure utilities that handle nested preferences, but they don’t work well with the preferences caching in Mac OS X 10.9 — a problem I ran into while testing.
So now I’m writing a utility in Python that does what the defaults command does, but that will handle nested dictionaries.
There’s a term for this process of having to solve one issue before you can solve another, and the issues get several layers deep. It’s called yak shaving.
+Here’s another good example:
+
I’m sure this will be the first of many posts about me yak shaving.
+I created a Ruby gem recently, called includable-activerecord. It’s pretty small, but I thought I might explain why I created it, and discuss its implementation.
+When you use ActiveRecord, you normally include it in your model like this:
+class User < ActiveRecord::Base + # ... +end+
Your User class is inheriting from the ActiveRecord::Base class. This is class-based inheritance, also called “classical” inheritance. (That’s “classical” as in “class”, not as a synonym for “traditional”.) Class-based inheritance represents an “is-a” relationship. So we’re saying that a user is an ActiveRecord base. Another way to say this is that User is a subclass of ActiveRecord::Base.
+
+There are a few problems with this. First, what is a “base”? The name was chosen because it’s a base class. But just like we don’t give factory classes names like UserFactory (at least not in Ruby), we shouldn’t name base classes Base.
I suppose that we’re trying to say that this is an ActiveRecord model. That sounds fine at first glance — this is our model for users. But what if we also want to say that a user is a person? Ruby doesn’t allow inheriting from multiple classes. Now we have to choose whether to inherit from ActiveRecord::Base or Person. Person makes more sense, because it fills the “is-a” rule better. Class inheritance is intended for a hierarchical “is-a” relationship, such as “a user is a person”, or “a circle is a shape”. But since ActiveRecord::Base is a base class, we have to use it as our base class.
We could work around this problem by subclassing Person from ActiveRecord::Base and then subclassing User from Person. That’s fine if Person is also a model that we store in the database. But if that’s not the case, then we have a problem.
Mixins
+Ruby provides another way of implementing inheritance — mixins. We often don’t think of this as an inheritance model, but it really is. When we include a module, that module gets added to the class’s ancestor chain. We can mix in as many modules as we want.
+Mixins indicate more of an “acts like” relationship than an “is-a” relationship. It’s for shared behavior between classes that don’t have a hierarchical relationship. For example, when we mix in the Enumerable module, we’re saying that we want our class to act like other classes that include Enumerable. That sounds more like what we want ActiveRecord to be. We want our user model to behave like other ActiveRecord models, in the way that they can persist to a database.
But ActiveRecord doesn’t support that. Almost all the other Ruby ORMs do; as we’ve shown above, this is for good reasons.
+So I decided to see if I could implement the equivalent of the ActiveRecord::Base class as a module that could be mixed into model classes. I decided to call my mixin module ActiveRecord::Model, because classes that mix it in will behave as ActiveRecord models.
It turns out that ActiveRecord::Base is a pretty complex class. It includes and extends a lot of other modules. Luckily, as of ActiveRecord 4.0, that’s all the code it includes.
The module only defines a single class method, included. This is one of Ruby’s many hook methods. It gets called when the module in question gets included in another module, and receives that other model as its argument. All we need to have this method do is to include everything that ActiveRecord::Base includes, and extend everything that ActiveRecord::Base extends. Ruby provides a method that’s defined on all classes, called included_modules, which we can use to get the list of everything that’s included in ActiveRecord::Base. Unfortunately, there’s no equivalent list of extended_modules. But a quick search on Stack Overflow found an implementation of extended_modules that we could use.
So with a bit of magic (i.e. hooks and meta-programming), we can get the lists of constituent modules from the ActiveRecord::Base class, and include them in our ActiveRecord::Model module.
So with all that, we can now include the includable-activerecord gem and mix it in, with all the advantages that provides:
+class User + include ActiveRecord::Model + # ... +end+
It was exciting to be able to make this work. Since I wrote it as a proof of concept, I haven’t written any tests yet. But it seems to be working just fine. The main thing I really need to look into is making sure that plugins that extend ActiveRecord::Base from their own code will still work. I’m pretty sure this will work out of the box, because the ActiveRecord::Model.included doesn’t run until the model class is loaded, and that happens after those plugins have initialized themselves.
It’s challenging to test Rails custom validators.
+I recently had to write a validator to require that an entered date is before or after a specified date.
+It didn’t seem like writing the validator would be too difficult – I’ve written custom validators before, and date comparisons aren’t all that tricky. But when it came time to write the tests, I ran into several issues. And since I always try to follow TDD / test-first, I was blocked before I even began.
+The biggest issue was the ActiveModel::EachValidator#validates_each API. It’s definitely not a well-designed API. You write your validator as a subclass, overriding validates_each. The method takes a model object, the name of the attribute of the model being tested, and the value of that attribute. You can also get the options passed to the custom validator via the options method. To perform a validation, you have to update the model’s errors hash.
The big flaw in the API is that instead of returning a result, you have to update the model. This needlessly couples the model and the validator. And it violates the Single Responsibility Principle — it has to determine validity of the field, and it has to update the errors hash of the model. This is not conducive to testing. Testing this method requires testing that the side-effect has taken place in the collaborator (model), which means it’s not really a unit test any more.
So to make it easier to unit test the validator, I broke the coupling by breaking it into 2 pieces, one for each responsibility. I moved the responsibility for determining validity to a separate method, which I called errors_for. It returns a hash of the errors found. This simplified the validates_each method to simply take the result of errors_for and update the errors hash of the model:
def validate_each(record, attribute_name, attribute_value) + record.errors[attribute_name].concat(errors_for(attribute_value, options)) +end+
This made it much easier to unit test the errors_for method. This method doesn’t even need to know about the model — only about the value of the attribute we’re trying to validate. We simply pass in the attribute’s value and the options.
So we could write the tests without even pulling in ActiveRecord or any models:
+describe DateValidator do
+ let(:validator) { DateValidator.new(attributes: :attribute_name) }
+ let(:errors) { validator.errors_for(attribute_value, validation_options) }
+
+ describe 'when attribute value is NOT a valid date' do
+ let(:attribute_value) { 'not a valid date' }
+ it { errors.must_include 'is not a valid date' }
+ end
+
+ describe 'when attribute value IS a valid date' do
+ let(:attribute_value) { Date.parse('2013-12-11') }
+ it { errors.must_be :empty? }
+ end
+end
+And the errors_for method looked something like this:
def errors_for(attribute_value, options) + unless attribute_value.is_a?(Date) + return [options.fetch(:message, "is not a valid date")] + end + [] +end+
Integration testing can also be a bit of a challenge. I recommend following the example from this Stack Overflow answer. Basically, create a minimal model object that contains the field and the validation. Then test that the model behaves like you expect with different values and validations.
+I’ve been using Python at work for the past few months. I learned Python back in the early 2000s, but never used it for any large projects. I learned Ruby in late 2005, and it quickly became my language of choice for most cases.
+So while I still prefer Ruby, and will likely use Ruby more in the future than Python, I wanted to assess the strengths and weaknesses of Python in relation to Ruby. Perhaps some of the lessons could be applied when writing Ruby, and it could help to decide when to use each. Also, I’m interested in programming language design, and wanted to document pros and cons in that light.
+Where Python Sucks (As Compared to Ruby)
++
I’ve been more interested in programming patterns lately, partly due to the Ruby community’s recent interest — especially the Ruby Rogue podcast’s love affair with “Smalltalk Best Practice Patterns”.
+I consider most of the patterns in “Smalltalk Best Practice Patterns” to be patterns “in the small” — things that are typically employed on a single line or method. The Gang Of Four patterns are more medium sized, dealing with methods and classes. The PEAA book covers architectural-scale patterns. I suppose “The Pragmatic Programmer” and similar books could (should!) be considered to be very general patterns, mostly about the practice of programming.
+One type of pattern that I have not seen discussed much is debugging patterns. I’m not exactly sure why that is; probably just our general concentration on designing the program code itself. There are definitely testing patterns. But I can’t think of anything that I’ve seen that covers debugging patterns. A quick search on the Internet doesn’t turn up too much.
+Anyway, a co-worker (Helena) and I were debugging recently, and were having trouble figuring out where a certain method on a certain object was being called. We came up with a really cool solution. We immediately called it a grenade, because its entire purpose is to blow up (raise an exception) and display a backtrace to show us the caller of the method that we’re looking for.
+Here’s our implementation in Ruby:
+
+module Grenade
+ def method_under_investigation(*)
+ raise "method_under_investigation called"
+ end
+end
+
+class Xyz
+ ...
+ def xyz
+ object_under_investigation.extend(Grenade)
+ end
+ ...
+endI’m sure we could wrap that in some more semantic sugar, even going as far as making it look something like this:
+
+class Xyz
+ ...
+ def xyz
+ object_under_investigation.blow_up_when_method_called(:method_under_investigation)
+ end
+ ...
+end
+I’m not sure that would really be worth it though, unless we were to add it to some sort of library.
+So that’s our contribution to the (small) list of debugging patterns.
+Amos and I got in a heated discussion recently on whether we should write a single line comment to better explain some code. (The code in question was Amos’s very elegant solution to testing whether a job got sent to Resque.)
+Amos doesn’t believe in writing comments much at all. He thinks that if you’re writing a comment, it means that you’re doing something wrong, and that you probably need to write the code more clearly.
+I agree with that, to a point. First off, it’s not necessary to write perfect code. If you can change a class or method name to better describe what you’re doing (and more importantly, why you’re doing it) then you should definitely do so. But it’s not always worth refactoring until you get every “why” answered. More importantly, I don’t think it’s even possible to capture everything in the code that is worth capturing. For example, why did you choose this implementation, as opposed to another that might be more obvious or common?
+After our argument, I came up with a good rule of thumb (or “pattern”):
++Write comments for your (future) self.1
In other words, if your comment will help you to understand the code more quickly when you look at it in the future, then it’s a valid comment. It also means that you can assume that the reader has about as much general programming knowledge as you currently do. (Your future self will have more general knowledge, but possibly less specific knowledge of the lines of code in question. And because of this, your current solution might not make as much sense in the future. You might know of a better solution in the future, but you’ll have to know all the constraints that you had when you originally wrote the code.)
+This is not to say that you should not write comments in clear English, that others can understand. The comment is written for a future maintainer. That may be you (which is why the rule works well), or it may be someone else. The rule is more about when to write a comment, and what level of competence you should assume of the reader.
+1 Perhaps it should be “Write comments TO your (future) self”.
+Web Development, Ruby on Rails, Open Source
+It’s that time of year again — time for a retrospective on how I did on my goals for the year. I had 5 main goals for 2015:
+I got pretty lucky on this one. My main contract with Mercy got extended several times. Amos and I must have been doing a good job of keeping the customer happy. We even made it through a couple rounds of layoffs. I’m wrapping up the gig at Mercy now. I’m working one day a week there, as the project winds down.
+I also started a new gig this month at CenturyLink. I’m working on a cloud development team. Our current project involves selling WordPress as a service. The manager had been courting me for most of the year. I’m excited about my new role; I’ll be writing about it in a blog post soon.
+I set a goal in 2014 to give my first conference talk. I accomplished that, giving an ambitious talk at RubyConf. I enjoyed having done that, and vowed to do more conference speaking.
+I gave 3 conference talks in 2015. I gave a workshop on HTTP at RailsConf. I talked about immutable infrastructure at Madison+ Ruby. At RubyConf, I gave a talk on a micro-ORM I wrote. I also gave a lightning talk about Agile estimation (#noestimates).
+I was an alternate speaker at Windy City Rails, but did not give my talk on Alternatives to ActiveRecord. I also went to Strange Loop, mainly to see several friends and acquaintances speak.
+I wrote 24 blog articles this year. That’s about one every other week. What really kept me going was participating in a writing pact. When the pact was going, I had a 75% blogging rate. That’s pretty good.
+I’m not so sure about the quality of my blog writing though. I know that practicing writing is supposed to make you better. I know I wrote some really good articles over the past year, but I think I also wrote some articles that weren’t very good. I think sometimes the deadline has caused more harm than good. I’m not really sure what to do about that; perhaps just pushing on is the right answer.
+I’ve taken a lot of notes on the design of my programming language. Any time I learn something interesting about another language, or come up with another idea, I write it down.
+But I haven’t worked on the implementation. (I last worked on the implementation in 2014.) I should be experimenting with some ideas, implementing them to see how they work out. I’ve even kicked around the idea of starting with a Forth variant, just to get something working quickly.
+I haven’t written any articles on my ideas this year either. My notes are pretty extensive, and it would be good to write some articles to help get my thoughts straight.
+I’ve got some things to say about Agile, and want to write a book to express those ideas. I’ve made a start — I’ve got the chapters outlines, and have started on a few chapters. But I haven’t made as much progress as I’d like to. I shared what I’ve got with Amos, and he showed some interest in pairing with me on the writing. Hopefully we’ll work on it together in 2016 and publish it.
+There were a few other accomplishments that weren’t explicitly on my list, but I’d like to call attention to.
+I’ve continued participating on the This Agile Life podcast. I was in 12 of the 33 episodes that were recorded in 2015. I hope to participate in more in 2016. We’re considering scheduling a standard recording night each week, which might help us record more regularly.
+I recently took over as maintainer of Virtus, a library to declare attributes for Ruby model classes. I haven’t done a lot yet, since I’ve been busy with travel, vacation, and holidays. But I hope to catch up with all the pending pull requests and issues in the next month or so.
+The accomplishment I’m most proud of is mentoring for the Roy Clay Sr. Tech Impact program. This is a program begun as a result of the Ferguson protest movement. We’re helping teach kids (from 14 to 25) web design and development. My personal goal was to give these kids an opportunity that they would not have otherwise had. But it turned out that some of them have actually started a business building web sites for small companies. I’m so proud of the progress they’ve made in such a short time; it’s a challenging program.
+I’m pretty happy with my accomplishments this year. I made at least some progress on each of the goals I set. I’ve been thinking about my goals for next year; I’ll write that as a separate blog article next week.
+I’ve been working on application architectures based on Uncle Bob’s Ruby Midwest talk, following the hexagonal architectural pattern. I posted an article a couple months ago showing a way that works fairly well in Rails, and some accompanying Rails example code. But there was one thing I wasn’t quite happy with.
+The problem is that we used callbacks (actually, a publish/subscribe mechanism) in a situation where they don’t seem to quite fit:
+ def show
+ interactor.on(:display) { |order| render order }
+ interactor.on(:not_found) { |order_id| render status: 404 }
+ interactor.get(params[:id])
+ end
+What we really want is to respond in different ways, depending on the result of the call to interactor.get(). There’s no good reason to define the responses before the call. It makes a lot more sense to define the responses after the call, because they’ll happen after the call. I’d much prefer that the code be written in the order that it will be run.
I discussed this problem with my friend and colleague, Amos King. We came up with a better solution, which puts things back in the right order:
+ def show
+ interactor.get(params[:id]) do |on|
+ on.display { |order| render order }
+ on.not_found { |order_id| render status: 404 }
+ end
+ end
+He even wrote a small library to do this, which he called Riposte. I’m not sure what to call this pattern, but it seems to work pretty well in this situation. I suppose that they’re still technically callbacks, because they’re passed in in the block that’s passed in to the call to interactor.get(). But due to the magic of Ruby blocks, we get to put them in the order they should be.
Riposte also gives you the option of using the response object directly, instead of passing a block:
+ def show
+ on = interactor.get(params[:id])
+ on.display { |order| render order }
+ on.not_found { |order_id| render status: 404 }
+ end
+This shows that it’s just returning an object, with the twist that the response object has methods that take blocks. The nested blocks variant is really the same thing, except that it’s yielding to the response object instead of returning it.
+I’ve decide that is the pattern I’d like to use for interactions and their callers within Ruby hexagonal architecture.
+I’ve started working on my own framework in Ruby in the past couple days. It’s built upon my recent work at understanding Uncle Bob’s Ruby Midwest 2011 talk, and his article on Clean Architecture, and the resulting hexagonal architecture (AKA ports and adapters).
+Somehow my research in that vein led me to Gary Bernhardt’s Boundaries talk. I’ve read a lot about the talk, and knew about the idea of “functional core / imperative shell”. And I’ve worked with a lot of similar ideas lately. But I believe this is the first time that I actually watched the whole video.
+Even after having read a lot about similar ideas, it was pretty mind-expanding. Gary’s really good at presenting these kinds of ideas in a simple way.
+OOP as usually taught includes encapsulation of data together with behavior, with mutable objects. Functional programming separates data and behavior, with mostly immutable data. From experience, encapsulating data and behavior together seems helpful. But experience also shows that immutability is useful. So it would be good to have both of those together. This is something I’ve been thinking for a few years — how best do we get both?
+Gary calls the combination “FauxO”. Logic and data are still combined, but there’s no mutation. Anywhere OOP would normally have mutation would just generate a new object. There’s no language restriction involved in enforcing immutability — just discipline.
+But without mutability, it’s hard to do IO and maintain state. So Gary’s solution is to encapsulate as much as possible into an immutable (functional or FauxO) core, and around that, use an imperative (traditional OOP) shell. The functional core contains the bulk of the logic, and the imperative shell is a glue layer that handles the real world, including disk, network, and other I/O.
+The result of this is that the shell has fewer paths, but more dependencies. The core contains no dependencies, but encapsulates the different logic paths. So we’re encapsulating dependencies on one side, and business logic on the other side. Or put another way, the way to figure out the separation is by doing as much as you can without mutation, and then encapsulating the mutation separately.
+I love how this naturally breaks things up, so that the core is all testable with unit tests, and the imperative shell is tested with integration tests. And since the shell has few or no logic paths, you get the testing pyramid, with more unit tests and fewer integration tests. The whole thing ends up being quite beautiful. Tests end up being very fast without any extra effort — not even stubbing or mocking. This tells us that things have been decomposed very well — an elegant design.
+Gary makes the case that immutable objects can be treated as values, and passed across boundaries. Even process boundaries. This is something I’ve noticed as I’ve been working on my own Uncle Bob style hexagonal framework, but nobody in that camp ever mentioned that — they prefer DTOs or something more like hashes. I’m completely against hashes, because of the “stringly-typed” problem. And I don’t see much advantage in a DTO if I’ve got an immutable object; I’d be basically copying the object to an almost identical object. And I’d be losing any laziness possible for derived values within the original immutable object.
+It’s striking to me how Gary’s image of an imperative shell around a functional core, plus Net, Disk, and State outside of the shell mirror’s Uncle Bob’s concentric circles. Uncle Bob has entities in the middle, surrounded by use cases, surrounded by Web, DB, and UI.
+Another advantage that Gary shows is that breaking things up this way allows easy concurrency. In his example, he shows using the actor model — either just using threads and queues, or an actor library (or language feature).
+After several years of thinking about the architectural issues seen in most large Rails apps, I’m starting to come to an understanding of how to combine all these ideas and come up with an architecture that will work better.
++
I’ve had a long love-hate relationship with Rails. I love the MVC framework and how it’s improved our speed of writing web apps. But I’ve never really been completely happy with it. I don’t generally agree with most of its opinions. I prefer models that follow the Data Mapper pattern, not the Active Record pattern. This includes separating the persistence layer from the models’ business logic. I prefer Slim or HAML to ERB. I prefer RSpec to Test::Unit or MiniTest. When Merb hit the scene, I was ready to make the jump, until Merb merged with Rails.
+So inspired by PJ Hagerty’s recent article on alternative Ruby web frameworks, I started thinking about how I’d write a replacement for Rails. I’d definitely keep the basic MVC framework. But I’d also want to implement a more hexagonal architecture.
+I started sketching out what this would look like, but I ended up starting with a Rails controller and finding the simplest way to make it hexagonal. I really don’t like callbacks, because they make tracing program execution difficult. But I didn’t see any other alternative. I found a simple pub/sub Ruby library called Wisper. It literally has only publish, subscribe, and on methods. (You use on to register single callbacks via blocks, and subscribe to register an object with method names corresponding to the callback names.)
The trick was figuring out how to break the controller into 2 pieces. What finally helped me was to find the single responsibilities of the 2 pieces. The Rails controller would remain in charge of managing the web interface, but would delegate to the other piece to handle any application-specific business logic. I decided to re-watch Uncle Bob Martin’s “Architecture The Lost Years” talk, which was the first time I was introduced to the ideas of Hexagonal Architecture. (He doesn’t name the architecture in the talk, but later calls it Clean Architecture.) He does a decent job of explaining how to break these 2 pieces apart. He used the term “interactor” in that talk, so I decided to go with that. He said that Jacobsen calls it a Control Object in Object Oriented Software Engineering, but that’s too close to Rails’s “controller”.
+So here’s an example of what I ended up with:
+class OrderController < ApplicationController
+ def index
+ interactor.on(:display) { |orders| render orders }
+ interactor.list
+ end
+
+ def show
+ interactor.on(:display) { |order| render order }
+ interactor.on(:not_found) { |order_id| render status: 404 }
+ interactor.get(params[:id])
+ end
+
+private
+
+ def interactor
+ @interactor ||= OrderInteractor.new
+ end
+end
+require "wisper" +require "order" + +class OrderInteractor + include Wisper.publisher + + def list + orders = Order.all + publish(:display, orders) + end + + def get(id) + order = Order.find(id) + publish(:display, order) + rescue ActiveRecord::RecordNotFound + publish(:not_found, id) + end +end+
I do have a few problems with this solution though. I’m not a fan of the name “interactor” for the business logic. I thought about calling it OrderOperator, or maybe OrderOperations, because it’s really a collection of operations. Perhaps it would be better to separate each operation into a separate class. Trailblazer does it that way. And for more complicated business logic, I would do that too, using the Method Object pattern. But like a Rails controller, there’s a lot in common among all the operations. I feel like a separate class for each operation for each would create too many coupled classes.
I’m also uncomfortable with the fact that the controller is delegating almost everything to the interactor. I guess this is OK, but it feels like there’s too little left when every line starts with interactor. I suppose extracting things some more would help mitigate this concern I’ll likely write a small gem to perform that extraction. I expect that that will allow a typical controller to be written in only a few lines. And maybe the same for the interactor side.
With the business logic extracted out of the controller, it was really easy for me to write a command-line version of the app. As Uncle Bob says, “the web is not particularly important to your application.”
+I’ve put the code for this example on GitHub: https://github.com/boochtek/hexagonal-rails. I’ll likely experiment with it some more over the next few weeks and months.
+January kept me pretty busy, so I’m a little late to this. But better late than never. And as an Agile practitioner, I don’t think personal retrospectives should be limited to one time of year.
+Last year I wrote a blog entry listing my goals for 2014. As far as New Year’s resolutions go, I was relatively successful — about 50% of my goals accomplished. Unfortunately, my Open Source contributions weren’t as strong as I had hoped; while I released some of my own work, I didn’t do much else. I did increase my blogging; getting in on a weekly blogging pact helped immensely. I also increased my participation on the This Agile Life podcast to a level that I’m happy with. But the accomplishment I’m most proud of was giving a presentation at RubyConf.
+I’d like to keep things rolling from last year, but crank up a few things. My plans are quite ambitious, so I don’t expect to get everything done by any means. But I think by setting the bar high, I’ll end up with a lot I can be proud of.
+Late last year, I took the jump into independent consulting. So far, I’ve really enjoyed it, and I’m booked up through April. My wife graduates in May, so we’ve got the possibility of moving if that makes sense. So I’ll be looking for consulting projects in town, but I’ll also be looking at jobs in San Francisco and Chicago. The possibilities are exciting, and I’ll be taking my time to find something just right.
+I was incredibly nervous leading up to my RubyConf presentation. Part of that was just the common fear of public speaking. For me, that only kicks in at around 100 people, and this audience was around 250. I think another reason was that I chose a really ambitious topic, and I kept finding more that I wanted to talk about, but wasn’t prepared for. But I think I did a pretty good job presenting an advanced topic. And I was so pumped by the sense of accomplishment as soon as I finished. So I’m hoping to do it more. I’ve already submitted a couple proposals, and plan to submit several more.
+I believe that blogging is important for me to get my thoughts down — for myself and to share with others. I was really successful last year when I had a partner to keep me honest, via a pact. So I’ve started up another pact this year, which will hopefully ensure I’ll keep things going. I’ve got a really long backlog of topics, so as long as I keep at it, I’ll have plenty to write about.
+I also want to move away from WordPress to a static system — probably Middleman. I’ve got 2 major problems with WordPress. First, I no longer trust its security, nor the security of any application written in PHP. Second, it generates HTML every time someone requests a page, instead of when the content is updated. I find that to be a waste of resources, and problematic from a security standpoint. The main problem with moving to a static blogging system is that I really want to allow comments, pingbacks, and tweetbacks. So I’ll have to find a way to integrate those.
+Last year I started thinking about programming language design, and started implementing a language tentatively called Brilliant. I’ve done a lot more thinking on the topic, and have a lot of notes. But I haven’t implemented much more yet. This year, I’d like to get my thoughts more organized, and write a series of blog posts on various aspects of language design. The most interesting part seems to be the trade-offs involved in the ways that various language features interact. So I’d like to make some progress on the language implementation, but more importantly, I’d like to get a lot of my design ideas written down.
+I’m also going to spend a lot of time learning a bunch more programming languages, so I have a better understanding of possible features, combinations of features, and their interactions. I’ve already start with Elixir, Clojure, and Racket. I’m hoping to also look at OCaml, Factor, and Haskell. I’ll probably also take a look at the 2 “Seven Languages in Seven Weeks” books.
+I think people often have trouble getting started with Agile. I started on a book last year, and got down quite a lot of good ideas. But I realized that I’m going to have a hard time organizing all those ideas into something coherent. Still, I’d like to try to get something out there that lets people get started with Agile. My idea is to present a toolbox of practices to get started with and build on that foundation over time with additional practices. Sort of a playbook on how to get started over the first 6 to 12 months and be successful. I want to make some progress on the book, at least enough to decide whether it’s worth the effort to finish it and self-publish it.
++
I’ve run across a pattern in Ruby lately that I really like. It solves some problems that I’ve struggled with for several years. Let me start with the problems.
+Let’s say you want to include an ORM in a model class, and want to tell it what database table to use. Typically, you’d do this:
+class User + include MyORM::Model + table 'people' +end+
But that table call is more like an option to the module inclusion than anything else. So what we’d really like is something like this:
class User + include MyORM::Model, table: 'people' +end+
But that’s not valid Ruby; include doesn’t let you pass anything other than a module.
So when I was learning about Virtus, I noticed that its example of how to include it is a bit different than the standard Ruby idiomatic include:
class User + include Virtus.model +end+
At first glance, it reads like the first example. But on closer inspection and consideration, it’s quite a bit different. Where MyORM::Model is a constant that refers to a module, Virtus.model is a method call. So there’s a method named model in the Virtus module. That method returns another module — which is exactly what’s needed in order to include it into our model class.
The easiest way to implement Virtus.model would be this:
module Virtus + def model + ::Virtus::Model + end +end + +module Virtus::Model + # ... +end+
If Virtus.model doesn’t need to take any arguments, that’s perfectly fine. In fact, I’ve started to use this implementation of the pattern for modules that don’t need parameters.
Because Virtus.model is a method, we can also call it with options:
class User + include Virtus.model(constructor: false, mass_assignment: false) +end+
We could even pass a block. But how do we process those options? There are a few different ways. However we do it, we have to be sure to return a module. And we can create modules in a few different ways.
+Virtus uses the builder pattern. It takes the parameters passed in and builds a module dynamically. By that, I mean that it calls Module.new and then adds methods to that module. It does this by mixing in other modules, but it could do it by dynamically defining methods as well.
I’ve never seen this pattern in any other language. It’s obviously only possible because we can dynamically create modules.
+The use of this idiom seems to be catching on a bit in the Ruby community. I’ve started using it myself, and will be adding it to my Includable::ActiveRecord gem soon.
++
+
I’ve decided to design and implement my own programming language, and call it Brilliant.
+I’ve been interested in programming languages and linguistics almost as long as I’ve been using computers. I’ve long thought that if I ever go back to college, it’s likely that I’ll concentrate on programming languages as a specialty.
+My recent discovery and involvement with the Crystal programming language has gotten me excited about new language ideas. It’s also helped me realize that implementing a language myself is feasible, and that there’s no better time to start than now.
+For now, the Brilliant implementation doesn’t let you do much more than “Hello World”. But you gotta start somewhere. So this article isn’t really “Introducing Brilliant” so much as the start of a series of articles on its design and implementation.
+I wanted to use a PEG (parsing expression grammar) parser for several reasons. For one, they seem to have gained a lot of popularity in the past few years. Also, PEGs cannot be ambiguous, which can solve a few difficult problems, such as the “dangling else“. Perhaps my favorite feature of PEG grammars is that you don’t need a separate tokenizer (lexer). This provides a nice advantage in that we can use keywords like “class” as variables, as long as they’re not used in a place where the keyword would make sense.
So knowing that I wanted to use a PEG, I had to find a PEG parser. I kind of wanted to use ANTLR, which has been a leading parser for many years. But the PEG seems to be new to version 4, and I couldn’t find any Ruby bindings for version 4. Treetop seems to be the most popular parser for Ruby, but I found the EBNF format that Rattler uses to be more to my taste. I think the fact that it’s newer also gives it a few advantages, having had a chance to learn some lessons from Treetop.
+I thought about using the Rubinius VM, but decided to go with LLVM, mainly since it has slightly better docs for Ruby, and because it’s what Crystal uses. Also, it’s pretty easy to get it to compile to a binary executable or run in a JIT. In the future, I might consider switching to the Rubinius VM, the Erlang VM, or the Perl 6 VM (Parrot). But for now, I like the idea of being able to compile to a binary and easily interface with C, just like Crystal.
+My main goal is to have fun playing around with language ideas.
+I’ve found a really great language in Ruby, so I’ll be using it as a starting point. But Ruby does have its faults. In some ways, I want to answer the question “what would Ruby look like if we designed it today?”.
+But I also want to explore other ideas. What if objects defaulted to immutable? What if functions and methods were assumed to be pure by default? Might it be possible to infer the purity of a function or method? (If so, we could automatically memoize them.) Can we make creating an actor as easy as creating an object?
+I’ll also be looking at ideas from other programming languages. Could we get some of the benefits of Haskell’s purity without having to do somersaults to do IO? Could we mix Python’s indentation style scoping with brace style or begin/end style? Could we integrate Icon’s ideas about success and failure (goal-directed execution)? What interesting features can we pull from Ada, Io, CoffeeScript, Crystal, Rubinius, Perl 6, etc.?
+
I’m not so much as interested in cutting-edge features, as in features that can be easily used by the average programmer. More importantly, I’m interested in how features interact with each other, so they fit well together to create a whole that’s greater than the sum of the parts.
+I wanted to name my programming language “Fermat”. I’ve long been intrigued by Fermat’s Last Theorem, and Fermat’s Little Theorem is important in number theory. Unfortunately, there’s already a computer algebra system with that name.
+So I decided to find a name in the same vein as “Ruby” and “Crystal”. I looked at the Wikipedia page for “gemstones” for some inspiration. A lot of the names of gemstones are already taken. I considered some obscure gemstones, but saw the word “brilliant” and thought it was decent. It’s not the name of another gemstone, but still evokes some similarity to Ruby and Crystal.
+So that’s the name for now. Perhaps I’ll decide to change it at some point in the future, but I needed a name for the project, as well as a file extension for source code files. I chose “bril” for that. I suppose “br” would be a better choice. Perhaps I’ll change that before the next article in this series.
I hope to work on Brilliant every once in a while. I expect it’ll take a couple years before it’s really very useful.
+When I do add a major feature, I’ll be certain to blog about it. I’ve got tons of ideas strewn about in various files. It would be great to get them organized and published —and even better to get them implemented.
+Most of us don’t write very readable shell scripts. There are plenty of things we could do better, but today I want to talk about one in particular — burying the lede.
+The term “burying the lede” comes from the field of journalism. Here’s the Wiktionary definition:
++To begin a story with details of secondary importance to the reader while postponing more essential points or facts.
Like a good news article, code should tell a story. And the story should start with what’s most important. In the case of code, the most important information is the high-level functionality — a succinct summary of what the program does. In other words, write (and organize) the code top-down, as opposed to bottom-up.
+Unfortunately, shell script doesn’t make this easy. Due to the way shell scripts are interpreted, you can’t call a function until after you’ve defined it. This leads to most of us structuring our code like this:
+function do_something { ... }
+function do_something_else { ... }
+
+do_something
+do_something_else
+The problem with this is that the function definitions will likely take quite a few lines, and we won’t see what the top-level functionality is until we reach the end of the script.
+I’d like to propose a standard way to structure shell scripts to mitigate this issue. (I’m really only talking about shell scripts that have function definitions within them.) I’m sure I’ve seen a few scripts do this, but it’s not very common at all.
+My proposal is simple:
+function main {
+ do_something
+ do_something_else
+}
+function do_something { ... }
+function do_something_else { ... }
+
+main
+This structure lets us start with the lede. We describe the top-level functionality right away. Only then do we get to the secondary details. The name main makes it pretty clear that it contains the top-level functionality.
I’ve recently started writing my shell code like this, and I’m happy with the results. I’ve also started to use some other programming techniques in my shell scripts to improve readability: better naming, extracting more methods, and moving helper methods into separate files. It feels good to treat shell scripts like real code instead of just some stuff I’ve hacked together.
+PS. The WordPress theme I’m currently using (Twenty Eleven) also buries the lede — I can barely even see the title of the blog post on my screen without scrolling. I’m going to have to change that soon.
+I recently decided to start using Emacs again. I used it extensively from the early 1990s until the early 2000s. I pretty much stopped using it when I had a sysadmin job with no Emacs on the servers, and no ability to install it. With the rising popularity of tmux and tmate for remote pairing, and my dislike for vim’s modes, I decided to try going back to Emacs in the terminal.
+One thing I really want in a text editor is good cursor key support. Shifted cursor keys
+should select text, and Control+left and right should move by words. (Apple HIG says to use Option+left and right to move by words; most apps on Mac OS X seem to support both.) Things have worked this way on almost every text editor on every OS I’ve used — Amiga, DOS, Windows, NeXT, Mac, Motif, Gnome, KDE. It’s a part of the CUA standard that’s been in common usage on everything since the mid-1980s.
Enabling cursor keys in Emacs was pretty easy. I’ve decided to use Prelude to make getting started with Emacs easy. Emacs comes with the cursor keys enabled, but Prelude disables them. Undoing Prelude’s change is pretty easy:
+(setq prelude-guru nil)+
Trying to make shifted cursor keys work is where the trouble began. They work in the GUI version of Emacs, but not from the terminal. It turns out that the Mac Terminal doesn’t distinguish between cursor keys and shifted cursor keys in its default configuration. So I had to figure out how to configure key bindings in Terminal.
+That’s easy enough — they’re in the preferences. But what should I set them to? This took a lot of research. Terminal emulation and ANSI code sequences are obscure, complex, and inconsistent. I eventually found the info I needed. For starters, Shift+Right, Shift+Left, Shift+Home, and Shift+End are defined in the terminfo. The rest I was able to piece together from various sources around the Internet.
+I’m also trying to script my Mac configuration. So instead of manually adding all the keybindings in the Terminal preferences pane, I decided to write a script. Mac OS X does a decent job of allowing you to change preferences from the command line. For example, to always show the tab bar:
+defaults write -app Terminal ShowTabBar 1+
Easy enough, except for a couple problems. First, I had to figure out the obscure syntax used in the preferences for key codes. I was able to piece these together with some more Internet research. But the really big problem is that the keyboard bindings are 2 levels deep within a “dictionary” (hash map). And the defaults command doesn’t handle that. There are some obscure utilities that handle nested preferences, but they don’t work well with the preferences caching in Mac OS X 10.9 — a problem I ran into while testing.
So now I’m writing a utility in Python that does what the defaults command does, but that will handle nested dictionaries.
There’s a term for this process of having to solve one issue before you can solve another, and the issues get several layers deep. It’s called yak shaving.
+Here’s another good example:
+
I’m sure this will be the first of many posts about me yak shaving.
+I created a Ruby gem recently, called includable-activerecord. It’s pretty small, but I thought I might explain why I created it, and discuss its implementation.
+When you use ActiveRecord, you normally include it in your model like this:
+class User < ActiveRecord::Base + # ... +end+
Your User class is inheriting from the ActiveRecord::Base class. This is class-based inheritance, also called “classical” inheritance. (That’s “classical” as in “class”, not as a synonym for “traditional”.) Class-based inheritance represents an “is-a” relationship. So we’re saying that a user is an ActiveRecord base. Another way to say this is that User is a subclass of ActiveRecord::Base.
+
+There are a few problems with this. First, what is a “base”? The name was chosen because it’s a base class. But just like we don’t give factory classes names like UserFactory (at least not in Ruby), we shouldn’t name base classes Base.
I suppose that we’re trying to say that this is an ActiveRecord model. That sounds fine at first glance — this is our model for users. But what if we also want to say that a user is a person? Ruby doesn’t allow inheriting from multiple classes. Now we have to choose whether to inherit from ActiveRecord::Base or Person. Person makes more sense, because it fills the “is-a” rule better. Class inheritance is intended for a hierarchical “is-a” relationship, such as “a user is a person”, or “a circle is a shape”. But since ActiveRecord::Base is a base class, we have to use it as our base class.
We could work around this problem by subclassing Person from ActiveRecord::Base and then subclassing User from Person. That’s fine if Person is also a model that we store in the database. But if that’s not the case, then we have a problem.
Mixins
+Ruby provides another way of implementing inheritance — mixins. We often don’t think of this as an inheritance model, but it really is. When we include a module, that module gets added to the class’s ancestor chain. We can mix in as many modules as we want.
+Mixins indicate more of an “acts like” relationship than an “is-a” relationship. It’s for shared behavior between classes that don’t have a hierarchical relationship. For example, when we mix in the Enumerable module, we’re saying that we want our class to act like other classes that include Enumerable. That sounds more like what we want ActiveRecord to be. We want our user model to behave like other ActiveRecord models, in the way that they can persist to a database.
But ActiveRecord doesn’t support that. Almost all the other Ruby ORMs do; as we’ve shown above, this is for good reasons.
+So I decided to see if I could implement the equivalent of the ActiveRecord::Base class as a module that could be mixed into model classes. I decided to call my mixin module ActiveRecord::Model, because classes that mix it in will behave as ActiveRecord models.
It turns out that ActiveRecord::Base is a pretty complex class. It includes and extends a lot of other modules. Luckily, as of ActiveRecord 4.0, that’s all the code it includes.
The module only defines a single class method, included. This is one of Ruby’s many hook methods. It gets called when the module in question gets included in another module, and receives that other model as its argument. All we need to have this method do is to include everything that ActiveRecord::Base includes, and extend everything that ActiveRecord::Base extends. Ruby provides a method that’s defined on all classes, called included_modules, which we can use to get the list of everything that’s included in ActiveRecord::Base. Unfortunately, there’s no equivalent list of extended_modules. But a quick search on Stack Overflow found an implementation of extended_modules that we could use.
So with a bit of magic (i.e. hooks and meta-programming), we can get the lists of constituent modules from the ActiveRecord::Base class, and include them in our ActiveRecord::Model module.
So with all that, we can now include the includable-activerecord gem and mix it in, with all the advantages that provides:
+class User + include ActiveRecord::Model + # ... +end+
It was exciting to be able to make this work. Since I wrote it as a proof of concept, I haven’t written any tests yet. But it seems to be working just fine. The main thing I really need to look into is making sure that plugins that extend ActiveRecord::Base from their own code will still work. I’m pretty sure this will work out of the box, because the ActiveRecord::Model.included doesn’t run until the model class is loaded, and that happens after those plugins have initialized themselves.
Web Development, Ruby on Rails, Open Source
+It’s that time of year again — time for a retrospective on how I did on my goals for the year. I had 5 main goals for 2015:
+I got pretty lucky on this one. My main contract with Mercy got extended several times. Amos and I must have been doing a good job of keeping the customer happy. We even made it through a couple rounds of layoffs. I’m wrapping up the gig at Mercy now. I’m working one day a week there, as the project winds down.
+I also started a new gig this month at CenturyLink. I’m working on a cloud development team. Our current project involves selling WordPress as a service. The manager had been courting me for most of the year. I’m excited about my new role; I’ll be writing about it in a blog post soon.
+I set a goal in 2014 to give my first conference talk. I accomplished that, giving an ambitious talk at RubyConf. I enjoyed having done that, and vowed to do more conference speaking.
+I gave 3 conference talks in 2015. I gave a workshop on HTTP at RailsConf. I talked about immutable infrastructure at Madison+ Ruby. At RubyConf, I gave a talk on a micro-ORM I wrote. I also gave a lightning talk about Agile estimation (#noestimates).
+I was an alternate speaker at Windy City Rails, but did not give my talk on Alternatives to ActiveRecord. I also went to Strange Loop, mainly to see several friends and acquaintances speak.
+I wrote 24 blog articles this year. That’s about one every other week. What really kept me going was participating in a writing pact. When the pact was going, I had a 75% blogging rate. That’s pretty good.
+I’m not so sure about the quality of my blog writing though. I know that practicing writing is supposed to make you better. I know I wrote some really good articles over the past year, but I think I also wrote some articles that weren’t very good. I think sometimes the deadline has caused more harm than good. I’m not really sure what to do about that; perhaps just pushing on is the right answer.
+I’ve taken a lot of notes on the design of my programming language. Any time I learn something interesting about another language, or come up with another idea, I write it down.
+But I haven’t worked on the implementation. (I last worked on the implementation in 2014.) I should be experimenting with some ideas, implementing them to see how they work out. I’ve even kicked around the idea of starting with a Forth variant, just to get something working quickly.
+I haven’t written any articles on my ideas this year either. My notes are pretty extensive, and it would be good to write some articles to help get my thoughts straight.
+I’ve got some things to say about Agile, and want to write a book to express those ideas. I’ve made a start — I’ve got the chapters outlines, and have started on a few chapters. But I haven’t made as much progress as I’d like to. I shared what I’ve got with Amos, and he showed some interest in pairing with me on the writing. Hopefully we’ll work on it together in 2016 and publish it.
+There were a few other accomplishments that weren’t explicitly on my list, but I’d like to call attention to.
+I’ve continued participating on the This Agile Life podcast. I was in 12 of the 33 episodes that were recorded in 2015. I hope to participate in more in 2016. We’re considering scheduling a standard recording night each week, which might help us record more regularly.
+I recently took over as maintainer of Virtus, a library to declare attributes for Ruby model classes. I haven’t done a lot yet, since I’ve been busy with travel, vacation, and holidays. But I hope to catch up with all the pending pull requests and issues in the next month or so.
+The accomplishment I’m most proud of is mentoring for the Roy Clay Sr. Tech Impact program. This is a program begun as a result of the Ferguson protest movement. We’re helping teach kids (from 14 to 25) web design and development. My personal goal was to give these kids an opportunity that they would not have otherwise had. But it turned out that some of them have actually started a business building web sites for small companies. I’m so proud of the progress they’ve made in such a short time; it’s a challenging program.
+I’m pretty happy with my accomplishments this year. I made at least some progress on each of the goals I set. I’ve been thinking about my goals for next year; I’ll write that as a separate blog article next week.
+January kept me pretty busy, so I’m a little late to this. But better late than never. And as an Agile practitioner, I don’t think personal retrospectives should be limited to one time of year.
+Last year I wrote a blog entry listing my goals for 2014. As far as New Year’s resolutions go, I was relatively successful — about 50% of my goals accomplished. Unfortunately, my Open Source contributions weren’t as strong as I had hoped; while I released some of my own work, I didn’t do much else. I did increase my blogging; getting in on a weekly blogging pact helped immensely. I also increased my participation on the This Agile Life podcast to a level that I’m happy with. But the accomplishment I’m most proud of was giving a presentation at RubyConf.
+I’d like to keep things rolling from last year, but crank up a few things. My plans are quite ambitious, so I don’t expect to get everything done by any means. But I think by setting the bar high, I’ll end up with a lot I can be proud of.
+Late last year, I took the jump into independent consulting. So far, I’ve really enjoyed it, and I’m booked up through April. My wife graduates in May, so we’ve got the possibility of moving if that makes sense. So I’ll be looking for consulting projects in town, but I’ll also be looking at jobs in San Francisco and Chicago. The possibilities are exciting, and I’ll be taking my time to find something just right.
+I was incredibly nervous leading up to my RubyConf presentation. Part of that was just the common fear of public speaking. For me, that only kicks in at around 100 people, and this audience was around 250. I think another reason was that I chose a really ambitious topic, and I kept finding more that I wanted to talk about, but wasn’t prepared for. But I think I did a pretty good job presenting an advanced topic. And I was so pumped by the sense of accomplishment as soon as I finished. So I’m hoping to do it more. I’ve already submitted a couple proposals, and plan to submit several more.
+I believe that blogging is important for me to get my thoughts down — for myself and to share with others. I was really successful last year when I had a partner to keep me honest, via a pact. So I’ve started up another pact this year, which will hopefully ensure I’ll keep things going. I’ve got a really long backlog of topics, so as long as I keep at it, I’ll have plenty to write about.
+I also want to move away from WordPress to a static system — probably Middleman. I’ve got 2 major problems with WordPress. First, I no longer trust its security, nor the security of any application written in PHP. Second, it generates HTML every time someone requests a page, instead of when the content is updated. I find that to be a waste of resources, and problematic from a security standpoint. The main problem with moving to a static blogging system is that I really want to allow comments, pingbacks, and tweetbacks. So I’ll have to find a way to integrate those.
+Last year I started thinking about programming language design, and started implementing a language tentatively called Brilliant. I’ve done a lot more thinking on the topic, and have a lot of notes. But I haven’t implemented much more yet. This year, I’d like to get my thoughts more organized, and write a series of blog posts on various aspects of language design. The most interesting part seems to be the trade-offs involved in the ways that various language features interact. So I’d like to make some progress on the language implementation, but more importantly, I’d like to get a lot of my design ideas written down.
+I’m also going to spend a lot of time learning a bunch more programming languages, so I have a better understanding of possible features, combinations of features, and their interactions. I’ve already start with Elixir, Clojure, and Racket. I’m hoping to also look at OCaml, Factor, and Haskell. I’ll probably also take a look at the 2 “Seven Languages in Seven Weeks” books.
+I think people often have trouble getting started with Agile. I started on a book last year, and got down quite a lot of good ideas. But I realized that I’m going to have a hard time organizing all those ideas into something coherent. Still, I’d like to try to get something out there that lets people get started with Agile. My idea is to present a toolbox of practices to get started with and build on that foundation over time with additional practices. Sort of a playbook on how to get started over the first 6 to 12 months and be successful. I want to make some progress on the book, at least enough to decide whether it’s worth the effort to finish it and self-publish it.
++
I’ve decided to design and implement my own programming language, and call it Brilliant.
+I’ve been interested in programming languages and linguistics almost as long as I’ve been using computers. I’ve long thought that if I ever go back to college, it’s likely that I’ll concentrate on programming languages as a specialty.
+My recent discovery and involvement with the Crystal programming language has gotten me excited about new language ideas. It’s also helped me realize that implementing a language myself is feasible, and that there’s no better time to start than now.
+For now, the Brilliant implementation doesn’t let you do much more than “Hello World”. But you gotta start somewhere. So this article isn’t really “Introducing Brilliant” so much as the start of a series of articles on its design and implementation.
+I wanted to use a PEG (parsing expression grammar) parser for several reasons. For one, they seem to have gained a lot of popularity in the past few years. Also, PEGs cannot be ambiguous, which can solve a few difficult problems, such as the “dangling else“. Perhaps my favorite feature of PEG grammars is that you don’t need a separate tokenizer (lexer). This provides a nice advantage in that we can use keywords like “class” as variables, as long as they’re not used in a place where the keyword would make sense.
So knowing that I wanted to use a PEG, I had to find a PEG parser. I kind of wanted to use ANTLR, which has been a leading parser for many years. But the PEG seems to be new to version 4, and I couldn’t find any Ruby bindings for version 4. Treetop seems to be the most popular parser for Ruby, but I found the EBNF format that Rattler uses to be more to my taste. I think the fact that it’s newer also gives it a few advantages, having had a chance to learn some lessons from Treetop.
+I thought about using the Rubinius VM, but decided to go with LLVM, mainly since it has slightly better docs for Ruby, and because it’s what Crystal uses. Also, it’s pretty easy to get it to compile to a binary executable or run in a JIT. In the future, I might consider switching to the Rubinius VM, the Erlang VM, or the Perl 6 VM (Parrot). But for now, I like the idea of being able to compile to a binary and easily interface with C, just like Crystal.
+My main goal is to have fun playing around with language ideas.
+I’ve found a really great language in Ruby, so I’ll be using it as a starting point. But Ruby does have its faults. In some ways, I want to answer the question “what would Ruby look like if we designed it today?”.
+But I also want to explore other ideas. What if objects defaulted to immutable? What if functions and methods were assumed to be pure by default? Might it be possible to infer the purity of a function or method? (If so, we could automatically memoize them.) Can we make creating an actor as easy as creating an object?
+I’ll also be looking at ideas from other programming languages. Could we get some of the benefits of Haskell’s purity without having to do somersaults to do IO? Could we mix Python’s indentation style scoping with brace style or begin/end style? Could we integrate Icon’s ideas about success and failure (goal-directed execution)? What interesting features can we pull from Ada, Io, CoffeeScript, Crystal, Rubinius, Perl 6, etc.?
+
I’m not so much as interested in cutting-edge features, as in features that can be easily used by the average programmer. More importantly, I’m interested in how features interact with each other, so they fit well together to create a whole that’s greater than the sum of the parts.
+I wanted to name my programming language “Fermat”. I’ve long been intrigued by Fermat’s Last Theorem, and Fermat’s Little Theorem is important in number theory. Unfortunately, there’s already a computer algebra system with that name.
+So I decided to find a name in the same vein as “Ruby” and “Crystal”. I looked at the Wikipedia page for “gemstones” for some inspiration. A lot of the names of gemstones are already taken. I considered some obscure gemstones, but saw the word “brilliant” and thought it was decent. It’s not the name of another gemstone, but still evokes some similarity to Ruby and Crystal.
+So that’s the name for now. Perhaps I’ll decide to change it at some point in the future, but I needed a name for the project, as well as a file extension for source code files. I chose “bril” for that. I suppose “br” would be a better choice. Perhaps I’ll change that before the next article in this series.
I hope to work on Brilliant every once in a while. I expect it’ll take a couple years before it’s really very useful.
+When I do add a major feature, I’ll be certain to blog about it. I’ve got tons of ideas strewn about in various files. It would be great to get them organized and published —and even better to get them implemented.
+I got pretty lucky on this one. My main contract with Mercy got extended several times. Amos and I must have been doing a good job of keeping the customer happy. We even made it through a couple rounds of layoffs. I’m wrapping up the gig at Mercy now. I’m working one day a week there, as the project winds down.
+I also started a new gig this month at CenturyLink. I’m working on a cloud development team. Our current project involves selling WordPress as a service. The manager had been courting me for most of the year. I’m excited about my new role; I’ll be writing about it in a blog post soon.
+I set a goal in 2014 to give my first conference talk. I accomplished that, giving an ambitious talk at RubyConf. I enjoyed having done that, and vowed to do more conference speaking.
+I gave 3 conference talks in 2015. I gave a workshop on HTTP at RailsConf. I talked about immutable infrastructure at Madison+ Ruby. At RubyConf, I gave a talk on a micro-ORM I wrote. I also gave a lightning talk about Agile estimation (#noestimates).
+I was an alternate speaker at Windy City Rails, but did not give my talk on Alternatives to ActiveRecord. I also went to Strange Loop, mainly to see several friends and acquaintances speak.
+I wrote 24 blog articles this year. That’s about one every other week. What really kept me going was participating in a writing pact. When the pact was going, I had a 75% blogging rate. That’s pretty good.
+I’m not so sure about the quality of my blog writing though. I know that practicing writing is supposed to make you better. I know I wrote some really good articles over the past year, but I think I also wrote some articles that weren’t very good. I think sometimes the deadline has caused more harm than good. I’m not really sure what to do about that; perhaps just pushing on is the right answer.
+I’ve taken a lot of notes on the design of my programming language. Any time I learn something interesting about another language, or come up with another idea, I write it down.
+But I haven’t worked on the implementation. (I last worked on the implementation in 2014.) I should be experimenting with some ideas, implementing them to see how they work out. I’ve even kicked around the idea of starting with a Forth variant, just to get something working quickly.
+I haven’t written any articles on my ideas this year either. My notes are pretty extensive, and it would be good to write some articles to help get my thoughts straight.
+I’ve got some things to say about Agile, and want to write a book to express those ideas. I’ve made a start — I’ve got the chapters outlines, and have started on a few chapters. But I haven’t made as much progress as I’d like to. I shared what I’ve got with Amos, and he showed some interest in pairing with me on the writing. Hopefully we’ll work on it together in 2016 and publish it.
+There were a few other accomplishments that weren’t explicitly on my list, but I’d like to call attention to.
+I’ve continued participating on the This Agile Life podcast. I was in 12 of the 33 episodes that were recorded in 2015. I hope to participate in more in 2016. We’re considering scheduling a standard recording night each week, which might help us record more regularly.
+I recently took over as maintainer of Virtus, a library to declare attributes for Ruby model classes. I haven’t done a lot yet, since I’ve been busy with travel, vacation, and holidays. But I hope to catch up with all the pending pull requests and issues in the next month or so.
+The accomplishment I’m most proud of is mentoring for the Roy Clay Sr. Tech Impact program. This is a program begun as a result of the Ferguson protest movement. We’re helping teach kids (from 14 to 25) web design and development. My personal goal was to give these kids an opportunity that they would not have otherwise had. But it turned out that some of them have actually started a business building web sites for small companies. I’m so proud of the progress they’ve made in such a short time; it’s a challenging program.
+I’m pretty happy with my accomplishments this year. I made at least some progress on each of the goals I set. I’ve been thinking about my goals for next year; I’ll write that as a separate blog article next week.
+]]>Last year I wrote a blog entry listing my goals for 2014. As far as New Year’s resolutions go, I was relatively successful — about 50% of my goals accomplished. Unfortunately, my Open Source contributions weren’t as strong as I had hoped; while I released some of my own work, I didn’t do much else. I did increase my blogging; getting in on a weekly blogging pact helped immensely. I also increased my participation on the This Agile Life podcast to a level that I’m happy with. But the accomplishment I’m most proud of was giving a presentation at RubyConf.
+I’d like to keep things rolling from last year, but crank up a few things. My plans are quite ambitious, so I don’t expect to get everything done by any means. But I think by setting the bar high, I’ll end up with a lot I can be proud of.
+Late last year, I took the jump into independent consulting. So far, I’ve really enjoyed it, and I’m booked up through April. My wife graduates in May, so we’ve got the possibility of moving if that makes sense. So I’ll be looking for consulting projects in town, but I’ll also be looking at jobs in San Francisco and Chicago. The possibilities are exciting, and I’ll be taking my time to find something just right.
+I was incredibly nervous leading up to my RubyConf presentation. Part of that was just the common fear of public speaking. For me, that only kicks in at around 100 people, and this audience was around 250. I think another reason was that I chose a really ambitious topic, and I kept finding more that I wanted to talk about, but wasn’t prepared for. But I think I did a pretty good job presenting an advanced topic. And I was so pumped by the sense of accomplishment as soon as I finished. So I’m hoping to do it more. I’ve already submitted a couple proposals, and plan to submit several more.
+I believe that blogging is important for me to get my thoughts down — for myself and to share with others. I was really successful last year when I had a partner to keep me honest, via a pact. So I’ve started up another pact this year, which will hopefully ensure I’ll keep things going. I’ve got a really long backlog of topics, so as long as I keep at it, I’ll have plenty to write about.
+I also want to move away from WordPress to a static system — probably Middleman. I’ve got 2 major problems with WordPress. First, I no longer trust its security, nor the security of any application written in PHP. Second, it generates HTML every time someone requests a page, instead of when the content is updated. I find that to be a waste of resources, and problematic from a security standpoint. The main problem with moving to a static blogging system is that I really want to allow comments, pingbacks, and tweetbacks. So I’ll have to find a way to integrate those.
+Last year I started thinking about programming language design, and started implementing a language tentatively called Brilliant. I’ve done a lot more thinking on the topic, and have a lot of notes. But I haven’t implemented much more yet. This year, I’d like to get my thoughts more organized, and write a series of blog posts on various aspects of language design. The most interesting part seems to be the trade-offs involved in the ways that various language features interact. So I’d like to make some progress on the language implementation, but more importantly, I’d like to get a lot of my design ideas written down.
+I’m also going to spend a lot of time learning a bunch more programming languages, so I have a better understanding of possible features, combinations of features, and their interactions. I’ve already start with Elixir, Clojure, and Racket. I’m hoping to also look at OCaml, Factor, and Haskell. I’ll probably also take a look at the 2 “Seven Languages in Seven Weeks” books.
+I think people often have trouble getting started with Agile. I started on a book last year, and got down quite a lot of good ideas. But I realized that I’m going to have a hard time organizing all those ideas into something coherent. Still, I’d like to try to get something out there that lets people get started with Agile. My idea is to present a toolbox of practices to get started with and build on that foundation over time with additional practices. Sort of a playbook on how to get started over the first 6 to 12 months and be successful. I want to make some progress on the book, at least enough to decide whether it’s worth the effort to finish it and self-publish it.
++]]>
I’ve been interested in programming languages and linguistics almost as long as I’ve been using computers. I’ve long thought that if I ever go back to college, it’s likely that I’ll concentrate on programming languages as a specialty.
+My recent discovery and involvement with the Crystal programming language has gotten me excited about new language ideas. It’s also helped me realize that implementing a language myself is feasible, and that there’s no better time to start than now.
+For now, the Brilliant implementation doesn’t let you do much more than “Hello World”. But you gotta start somewhere. So this article isn’t really “Introducing Brilliant” so much as the start of a series of articles on its design and implementation.
+I wanted to use a PEG (parsing expression grammar) parser for several reasons. For one, they seem to have gained a lot of popularity in the past few years. Also, PEGs cannot be ambiguous, which can solve a few difficult problems, such as the “dangling else“. Perhaps my favorite feature of PEG grammars is that you don’t need a separate tokenizer (lexer). This provides a nice advantage in that we can use keywords like “class” as variables, as long as they’re not used in a place where the keyword would make sense.
So knowing that I wanted to use a PEG, I had to find a PEG parser. I kind of wanted to use ANTLR, which has been a leading parser for many years. But the PEG seems to be new to version 4, and I couldn’t find any Ruby bindings for version 4. Treetop seems to be the most popular parser for Ruby, but I found the EBNF format that Rattler uses to be more to my taste. I think the fact that it’s newer also gives it a few advantages, having had a chance to learn some lessons from Treetop.
+I thought about using the Rubinius VM, but decided to go with LLVM, mainly since it has slightly better docs for Ruby, and because it’s what Crystal uses. Also, it’s pretty easy to get it to compile to a binary executable or run in a JIT. In the future, I might consider switching to the Rubinius VM, the Erlang VM, or the Perl 6 VM (Parrot). But for now, I like the idea of being able to compile to a binary and easily interface with C, just like Crystal.
+My main goal is to have fun playing around with language ideas.
+I’ve found a really great language in Ruby, so I’ll be using it as a starting point. But Ruby does have its faults. In some ways, I want to answer the question “what would Ruby look like if we designed it today?”.
+But I also want to explore other ideas. What if objects defaulted to immutable? What if functions and methods were assumed to be pure by default? Might it be possible to infer the purity of a function or method? (If so, we could automatically memoize them.) Can we make creating an actor as easy as creating an object?
+I’ll also be looking at ideas from other programming languages. Could we get some of the benefits of Haskell’s purity without having to do somersaults to do IO? Could we mix Python’s indentation style scoping with brace style or begin/end style? Could we integrate Icon’s ideas about success and failure (goal-directed execution)? What interesting features can we pull from Ada, Io, CoffeeScript, Crystal, Rubinius, Perl 6, etc.?
+
I’m not so much as interested in cutting-edge features, as in features that can be easily used by the average programmer. More importantly, I’m interested in how features interact with each other, so they fit well together to create a whole that’s greater than the sum of the parts.
+I wanted to name my programming language “Fermat”. I’ve long been intrigued by Fermat’s Last Theorem, and Fermat’s Little Theorem is important in number theory. Unfortunately, there’s already a computer algebra system with that name.
+So I decided to find a name in the same vein as “Ruby” and “Crystal”. I looked at the Wikipedia page for “gemstones” for some inspiration. A lot of the names of gemstones are already taken. I considered some obscure gemstones, but saw the word “brilliant” and thought it was decent. It’s not the name of another gemstone, but still evokes some similarity to Ruby and Crystal.
+So that’s the name for now. Perhaps I’ll decide to change it at some point in the future, but I needed a name for the project, as well as a file extension for source code files. I chose “bril” for that. I suppose “br” would be a better choice. Perhaps I’ll change that before the next article in this series.
I hope to work on Brilliant every once in a while. I expect it’ll take a couple years before it’s really very useful.
+When I do add a major feature, I’ll be certain to blog about it. I’ve got tons of ideas strewn about in various files. It would be great to get them organized and published —and even better to get them implemented.
+]]>Web Development, Ruby on Rails, Open Source
+I’ve been using Python at work for the past few months. I learned Python back in the early 2000s, but never used it for any large projects. I learned Ruby in late 2005, and it quickly became my language of choice for most cases.
+So while I still prefer Ruby, and will likely use Ruby more in the future than Python, I wanted to assess the strengths and weaknesses of Python in relation to Ruby. Perhaps some of the lessons could be applied when writing Ruby, and it could help to decide when to use each. Also, I’m interested in programming language design, and wanted to document pros and cons in that light.
+Where Python Sucks (As Compared to Ruby)
++
I’ve been more interested in programming patterns lately, partly due to the Ruby community’s recent interest — especially the Ruby Rogue podcast’s love affair with “Smalltalk Best Practice Patterns”.
+I consider most of the patterns in “Smalltalk Best Practice Patterns” to be patterns “in the small” — things that are typically employed on a single line or method. The Gang Of Four patterns are more medium sized, dealing with methods and classes. The PEAA book covers architectural-scale patterns. I suppose “The Pragmatic Programmer” and similar books could (should!) be considered to be very general patterns, mostly about the practice of programming.
+One type of pattern that I have not seen discussed much is debugging patterns. I’m not exactly sure why that is; probably just our general concentration on designing the program code itself. There are definitely testing patterns. But I can’t think of anything that I’ve seen that covers debugging patterns. A quick search on the Internet doesn’t turn up too much.
+Anyway, a co-worker (Helena) and I were debugging recently, and were having trouble figuring out where a certain method on a certain object was being called. We came up with a really cool solution. We immediately called it a grenade, because its entire purpose is to blow up (raise an exception) and display a backtrace to show us the caller of the method that we’re looking for.
+Here’s our implementation in Ruby:
+
+module Grenade
+ def method_under_investigation(*)
+ raise "method_under_investigation called"
+ end
+end
+
+class Xyz
+ ...
+ def xyz
+ object_under_investigation.extend(Grenade)
+ end
+ ...
+endI’m sure we could wrap that in some more semantic sugar, even going as far as making it look something like this:
+
+class Xyz
+ ...
+ def xyz
+ object_under_investigation.blow_up_when_method_called(:method_under_investigation)
+ end
+ ...
+end
+I’m not sure that would really be worth it though, unless we were to add it to some sort of library.
+So that’s our contribution to the (small) list of debugging patterns.
+Web Development, Ruby on Rails, Open Source
+I’ve been using Python at work for the past few months. I learned Python back in the early 2000s, but never used it for any large projects. I learned Ruby in late 2005, and it quickly became my language of choice for most cases.
+So while I still prefer Ruby, and will likely use Ruby more in the future than Python, I wanted to assess the strengths and weaknesses of Python in relation to Ruby. Perhaps some of the lessons could be applied when writing Ruby, and it could help to decide when to use each. Also, I’m interested in programming language design, and wanted to document pros and cons in that light.
+Where Python Sucks (As Compared to Ruby)
++
So while I still prefer Ruby, and will likely use Ruby more in the future than Python, I wanted to assess the strengths and weaknesses of Python in relation to Ruby. Perhaps some of the lessons could be applied when writing Ruby, and it could help to decide when to use each. Also, I’m interested in programming language design, and wanted to document pros and cons in that light.
+Where Python Sucks (As Compared to Ruby)
++]]>
Web Development, Ruby on Rails, Open Source
+I’ve been working on application architectures based on Uncle Bob’s Ruby Midwest talk, following the hexagonal architectural pattern. I posted an article a couple months ago showing a way that works fairly well in Rails, and some accompanying Rails example code. But there was one thing I wasn’t quite happy with.
+The problem is that we used callbacks (actually, a publish/subscribe mechanism) in a situation where they don’t seem to quite fit:
+ def show
+ interactor.on(:display) { |order| render order }
+ interactor.on(:not_found) { |order_id| render status: 404 }
+ interactor.get(params[:id])
+ end
+What we really want is to respond in different ways, depending on the result of the call to interactor.get(). There’s no good reason to define the responses before the call. It makes a lot more sense to define the responses after the call, because they’ll happen after the call. I’d much prefer that the code be written in the order that it will be run.
I discussed this problem with my friend and colleague, Amos King. We came up with a better solution, which puts things back in the right order:
+ def show
+ interactor.get(params[:id]) do |on|
+ on.display { |order| render order }
+ on.not_found { |order_id| render status: 404 }
+ end
+ end
+He even wrote a small library to do this, which he called Riposte. I’m not sure what to call this pattern, but it seems to work pretty well in this situation. I suppose that they’re still technically callbacks, because they’re passed in in the block that’s passed in to the call to interactor.get(). But due to the magic of Ruby blocks, we get to put them in the order they should be.
Riposte also gives you the option of using the response object directly, instead of passing a block:
+ def show
+ on = interactor.get(params[:id])
+ on.display { |order| render order }
+ on.not_found { |order_id| render status: 404 }
+ end
+This shows that it’s just returning an object, with the twist that the response object has methods that take blocks. The nested blocks variant is really the same thing, except that it’s yielding to the response object instead of returning it.
+I’ve decide that is the pattern I’d like to use for interactions and their callers within Ruby hexagonal architecture.
+I’ve started working on my own framework in Ruby in the past couple days. It’s built upon my recent work at understanding Uncle Bob’s Ruby Midwest 2011 talk, and his article on Clean Architecture, and the resulting hexagonal architecture (AKA ports and adapters).
+Somehow my research in that vein led me to Gary Bernhardt’s Boundaries talk. I’ve read a lot about the talk, and knew about the idea of “functional core / imperative shell”. And I’ve worked with a lot of similar ideas lately. But I believe this is the first time that I actually watched the whole video.
+Even after having read a lot about similar ideas, it was pretty mind-expanding. Gary’s really good at presenting these kinds of ideas in a simple way.
+OOP as usually taught includes encapsulation of data together with behavior, with mutable objects. Functional programming separates data and behavior, with mostly immutable data. From experience, encapsulating data and behavior together seems helpful. But experience also shows that immutability is useful. So it would be good to have both of those together. This is something I’ve been thinking for a few years — how best do we get both?
+Gary calls the combination “FauxO”. Logic and data are still combined, but there’s no mutation. Anywhere OOP would normally have mutation would just generate a new object. There’s no language restriction involved in enforcing immutability — just discipline.
+But without mutability, it’s hard to do IO and maintain state. So Gary’s solution is to encapsulate as much as possible into an immutable (functional or FauxO) core, and around that, use an imperative (traditional OOP) shell. The functional core contains the bulk of the logic, and the imperative shell is a glue layer that handles the real world, including disk, network, and other I/O.
+The result of this is that the shell has fewer paths, but more dependencies. The core contains no dependencies, but encapsulates the different logic paths. So we’re encapsulating dependencies on one side, and business logic on the other side. Or put another way, the way to figure out the separation is by doing as much as you can without mutation, and then encapsulating the mutation separately.
+I love how this naturally breaks things up, so that the core is all testable with unit tests, and the imperative shell is tested with integration tests. And since the shell has few or no logic paths, you get the testing pyramid, with more unit tests and fewer integration tests. The whole thing ends up being quite beautiful. Tests end up being very fast without any extra effort — not even stubbing or mocking. This tells us that things have been decomposed very well — an elegant design.
+Gary makes the case that immutable objects can be treated as values, and passed across boundaries. Even process boundaries. This is something I’ve noticed as I’ve been working on my own Uncle Bob style hexagonal framework, but nobody in that camp ever mentioned that — they prefer DTOs or something more like hashes. I’m completely against hashes, because of the “stringly-typed” problem. And I don’t see much advantage in a DTO if I’ve got an immutable object; I’d be basically copying the object to an almost identical object. And I’d be losing any laziness possible for derived values within the original immutable object.
+It’s striking to me how Gary’s image of an imperative shell around a functional core, plus Net, Disk, and State outside of the shell mirror’s Uncle Bob’s concentric circles. Uncle Bob has entities in the middle, surrounded by use cases, surrounded by Web, DB, and UI.
+Another advantage that Gary shows is that breaking things up this way allows easy concurrency. In his example, he shows using the actor model — either just using threads and queues, or an actor library (or language feature).
+After several years of thinking about the architectural issues seen in most large Rails apps, I’m starting to come to an understanding of how to combine all these ideas and come up with an architecture that will work better.
++
I’ve had a long love-hate relationship with Rails. I love the MVC framework and how it’s improved our speed of writing web apps. But I’ve never really been completely happy with it. I don’t generally agree with most of its opinions. I prefer models that follow the Data Mapper pattern, not the Active Record pattern. This includes separating the persistence layer from the models’ business logic. I prefer Slim or HAML to ERB. I prefer RSpec to Test::Unit or MiniTest. When Merb hit the scene, I was ready to make the jump, until Merb merged with Rails.
+So inspired by PJ Hagerty’s recent article on alternative Ruby web frameworks, I started thinking about how I’d write a replacement for Rails. I’d definitely keep the basic MVC framework. But I’d also want to implement a more hexagonal architecture.
+I started sketching out what this would look like, but I ended up starting with a Rails controller and finding the simplest way to make it hexagonal. I really don’t like callbacks, because they make tracing program execution difficult. But I didn’t see any other alternative. I found a simple pub/sub Ruby library called Wisper. It literally has only publish, subscribe, and on methods. (You use on to register single callbacks via blocks, and subscribe to register an object with method names corresponding to the callback names.)
The trick was figuring out how to break the controller into 2 pieces. What finally helped me was to find the single responsibilities of the 2 pieces. The Rails controller would remain in charge of managing the web interface, but would delegate to the other piece to handle any application-specific business logic. I decided to re-watch Uncle Bob Martin’s “Architecture The Lost Years” talk, which was the first time I was introduced to the ideas of Hexagonal Architecture. (He doesn’t name the architecture in the talk, but later calls it Clean Architecture.) He does a decent job of explaining how to break these 2 pieces apart. He used the term “interactor” in that talk, so I decided to go with that. He said that Jacobsen calls it a Control Object in Object Oriented Software Engineering, but that’s too close to Rails’s “controller”.
+So here’s an example of what I ended up with:
+class OrderController < ApplicationController
+ def index
+ interactor.on(:display) { |orders| render orders }
+ interactor.list
+ end
+
+ def show
+ interactor.on(:display) { |order| render order }
+ interactor.on(:not_found) { |order_id| render status: 404 }
+ interactor.get(params[:id])
+ end
+
+private
+
+ def interactor
+ @interactor ||= OrderInteractor.new
+ end
+end
+require "wisper" +require "order" + +class OrderInteractor + include Wisper.publisher + + def list + orders = Order.all + publish(:display, orders) + end + + def get(id) + order = Order.find(id) + publish(:display, order) + rescue ActiveRecord::RecordNotFound + publish(:not_found, id) + end +end+
I do have a few problems with this solution though. I’m not a fan of the name “interactor” for the business logic. I thought about calling it OrderOperator, or maybe OrderOperations, because it’s really a collection of operations. Perhaps it would be better to separate each operation into a separate class. Trailblazer does it that way. And for more complicated business logic, I would do that too, using the Method Object pattern. But like a Rails controller, there’s a lot in common among all the operations. I feel like a separate class for each operation for each would create too many coupled classes.
I’m also uncomfortable with the fact that the controller is delegating almost everything to the interactor. I guess this is OK, but it feels like there’s too little left when every line starts with interactor. I suppose extracting things some more would help mitigate this concern I’ll likely write a small gem to perform that extraction. I expect that that will allow a typical controller to be written in only a few lines. And maybe the same for the interactor side.
With the business logic extracted out of the controller, it was really easy for me to write a command-line version of the app. As Uncle Bob says, “the web is not particularly important to your application.”
+I’ve put the code for this example on GitHub: https://github.com/boochtek/hexagonal-rails. I’ll likely experiment with it some more over the next few weeks and months.
+I’ve run across a pattern in Ruby lately that I really like. It solves some problems that I’ve struggled with for several years. Let me start with the problems.
+Let’s say you want to include an ORM in a model class, and want to tell it what database table to use. Typically, you’d do this:
+class User + include MyORM::Model + table 'people' +end+
But that table call is more like an option to the module inclusion than anything else. So what we’d really like is something like this:
class User + include MyORM::Model, table: 'people' +end+
But that’s not valid Ruby; include doesn’t let you pass anything other than a module.
So when I was learning about Virtus, I noticed that its example of how to include it is a bit different than the standard Ruby idiomatic include:
class User + include Virtus.model +end+
At first glance, it reads like the first example. But on closer inspection and consideration, it’s quite a bit different. Where MyORM::Model is a constant that refers to a module, Virtus.model is a method call. So there’s a method named model in the Virtus module. That method returns another module — which is exactly what’s needed in order to include it into our model class.
The easiest way to implement Virtus.model would be this:
module Virtus + def model + ::Virtus::Model + end +end + +module Virtus::Model + # ... +end+
If Virtus.model doesn’t need to take any arguments, that’s perfectly fine. In fact, I’ve started to use this implementation of the pattern for modules that don’t need parameters.
Because Virtus.model is a method, we can also call it with options:
class User + include Virtus.model(constructor: false, mass_assignment: false) +end+
We could even pass a block. But how do we process those options? There are a few different ways. However we do it, we have to be sure to return a module. And we can create modules in a few different ways.
+Virtus uses the builder pattern. It takes the parameters passed in and builds a module dynamically. By that, I mean that it calls Module.new and then adds methods to that module. It does this by mixing in other modules, but it could do it by dynamically defining methods as well.
I’ve never seen this pattern in any other language. It’s obviously only possible because we can dynamically create modules.
+The use of this idiom seems to be catching on a bit in the Ruby community. I’ve started using it myself, and will be adding it to my Includable::ActiveRecord gem soon.
++
+
I created a Ruby gem recently, called includable-activerecord. It’s pretty small, but I thought I might explain why I created it, and discuss its implementation.
+When you use ActiveRecord, you normally include it in your model like this:
+class User < ActiveRecord::Base + # ... +end+
Your User class is inheriting from the ActiveRecord::Base class. This is class-based inheritance, also called “classical” inheritance. (That’s “classical” as in “class”, not as a synonym for “traditional”.) Class-based inheritance represents an “is-a” relationship. So we’re saying that a user is an ActiveRecord base. Another way to say this is that User is a subclass of ActiveRecord::Base.
+
+There are a few problems with this. First, what is a “base”? The name was chosen because it’s a base class. But just like we don’t give factory classes names like UserFactory (at least not in Ruby), we shouldn’t name base classes Base.
I suppose that we’re trying to say that this is an ActiveRecord model. That sounds fine at first glance — this is our model for users. But what if we also want to say that a user is a person? Ruby doesn’t allow inheriting from multiple classes. Now we have to choose whether to inherit from ActiveRecord::Base or Person. Person makes more sense, because it fills the “is-a” rule better. Class inheritance is intended for a hierarchical “is-a” relationship, such as “a user is a person”, or “a circle is a shape”. But since ActiveRecord::Base is a base class, we have to use it as our base class.
We could work around this problem by subclassing Person from ActiveRecord::Base and then subclassing User from Person. That’s fine if Person is also a model that we store in the database. But if that’s not the case, then we have a problem.
Mixins
+Ruby provides another way of implementing inheritance — mixins. We often don’t think of this as an inheritance model, but it really is. When we include a module, that module gets added to the class’s ancestor chain. We can mix in as many modules as we want.
+Mixins indicate more of an “acts like” relationship than an “is-a” relationship. It’s for shared behavior between classes that don’t have a hierarchical relationship. For example, when we mix in the Enumerable module, we’re saying that we want our class to act like other classes that include Enumerable. That sounds more like what we want ActiveRecord to be. We want our user model to behave like other ActiveRecord models, in the way that they can persist to a database.
But ActiveRecord doesn’t support that. Almost all the other Ruby ORMs do; as we’ve shown above, this is for good reasons.
+So I decided to see if I could implement the equivalent of the ActiveRecord::Base class as a module that could be mixed into model classes. I decided to call my mixin module ActiveRecord::Model, because classes that mix it in will behave as ActiveRecord models.
It turns out that ActiveRecord::Base is a pretty complex class. It includes and extends a lot of other modules. Luckily, as of ActiveRecord 4.0, that’s all the code it includes.
The module only defines a single class method, included. This is one of Ruby’s many hook methods. It gets called when the module in question gets included in another module, and receives that other model as its argument. All we need to have this method do is to include everything that ActiveRecord::Base includes, and extend everything that ActiveRecord::Base extends. Ruby provides a method that’s defined on all classes, called included_modules, which we can use to get the list of everything that’s included in ActiveRecord::Base. Unfortunately, there’s no equivalent list of extended_modules. But a quick search on Stack Overflow found an implementation of extended_modules that we could use.
So with a bit of magic (i.e. hooks and meta-programming), we can get the lists of constituent modules from the ActiveRecord::Base class, and include them in our ActiveRecord::Model module.
So with all that, we can now include the includable-activerecord gem and mix it in, with all the advantages that provides:
+class User + include ActiveRecord::Model + # ... +end+
It was exciting to be able to make this work. Since I wrote it as a proof of concept, I haven’t written any tests yet. But it seems to be working just fine. The main thing I really need to look into is making sure that plugins that extend ActiveRecord::Base from their own code will still work. I’m pretty sure this will work out of the box, because the ActiveRecord::Model.included doesn’t run until the model class is loaded, and that happens after those plugins have initialized themselves.
I’ve been using Python at work for the past few months. I learned Python back in the early 2000s, but never used it for any large projects. I learned Ruby in late 2005, and it quickly became my language of choice for most cases.
+So while I still prefer Ruby, and will likely use Ruby more in the future than Python, I wanted to assess the strengths and weaknesses of Python in relation to Ruby. Perhaps some of the lessons could be applied when writing Ruby, and it could help to decide when to use each. Also, I’m interested in programming language design, and wanted to document pros and cons in that light.
+Where Python Sucks (As Compared to Ruby)
++
I’ve been more interested in programming patterns lately, partly due to the Ruby community’s recent interest — especially the Ruby Rogue podcast’s love affair with “Smalltalk Best Practice Patterns”.
+I consider most of the patterns in “Smalltalk Best Practice Patterns” to be patterns “in the small” — things that are typically employed on a single line or method. The Gang Of Four patterns are more medium sized, dealing with methods and classes. The PEAA book covers architectural-scale patterns. I suppose “The Pragmatic Programmer” and similar books could (should!) be considered to be very general patterns, mostly about the practice of programming.
+One type of pattern that I have not seen discussed much is debugging patterns. I’m not exactly sure why that is; probably just our general concentration on designing the program code itself. There are definitely testing patterns. But I can’t think of anything that I’ve seen that covers debugging patterns. A quick search on the Internet doesn’t turn up too much.
+Anyway, a co-worker (Helena) and I were debugging recently, and were having trouble figuring out where a certain method on a certain object was being called. We came up with a really cool solution. We immediately called it a grenade, because its entire purpose is to blow up (raise an exception) and display a backtrace to show us the caller of the method that we’re looking for.
+Here’s our implementation in Ruby:
+
+module Grenade
+ def method_under_investigation(*)
+ raise "method_under_investigation called"
+ end
+end
+
+class Xyz
+ ...
+ def xyz
+ object_under_investigation.extend(Grenade)
+ end
+ ...
+endI’m sure we could wrap that in some more semantic sugar, even going as far as making it look something like this:
+
+class Xyz
+ ...
+ def xyz
+ object_under_investigation.blow_up_when_method_called(:method_under_investigation)
+ end
+ ...
+end
+I’m not sure that would really be worth it though, unless we were to add it to some sort of library.
+So that’s our contribution to the (small) list of debugging patterns.
+The problem is that we used callbacks (actually, a publish/subscribe mechanism) in a situation where they don’t seem to quite fit:
+ def show
+ interactor.on(:display) { |order| render order }
+ interactor.on(:not_found) { |order_id| render status: 404 }
+ interactor.get(params[:id])
+ end
+What we really want is to respond in different ways, depending on the result of the call to interactor.get(). There’s no good reason to define the responses before the call. It makes a lot more sense to define the responses after the call, because they’ll happen after the call. I’d much prefer that the code be written in the order that it will be run.
I discussed this problem with my friend and colleague, Amos King. We came up with a better solution, which puts things back in the right order:
+ def show
+ interactor.get(params[:id]) do |on|
+ on.display { |order| render order }
+ on.not_found { |order_id| render status: 404 }
+ end
+ end
+He even wrote a small library to do this, which he called Riposte. I’m not sure what to call this pattern, but it seems to work pretty well in this situation. I suppose that they’re still technically callbacks, because they’re passed in in the block that’s passed in to the call to interactor.get(). But due to the magic of Ruby blocks, we get to put them in the order they should be.
Riposte also gives you the option of using the response object directly, instead of passing a block:
+ def show
+ on = interactor.get(params[:id])
+ on.display { |order| render order }
+ on.not_found { |order_id| render status: 404 }
+ end
+This shows that it’s just returning an object, with the twist that the response object has methods that take blocks. The nested blocks variant is really the same thing, except that it’s yielding to the response object instead of returning it.
+I’ve decide that is the pattern I’d like to use for interactions and their callers within Ruby hexagonal architecture.
+]]>Somehow my research in that vein led me to Gary Bernhardt’s Boundaries talk. I’ve read a lot about the talk, and knew about the idea of “functional core / imperative shell”. And I’ve worked with a lot of similar ideas lately. But I believe this is the first time that I actually watched the whole video.
+Even after having read a lot about similar ideas, it was pretty mind-expanding. Gary’s really good at presenting these kinds of ideas in a simple way.
+OOP as usually taught includes encapsulation of data together with behavior, with mutable objects. Functional programming separates data and behavior, with mostly immutable data. From experience, encapsulating data and behavior together seems helpful. But experience also shows that immutability is useful. So it would be good to have both of those together. This is something I’ve been thinking for a few years — how best do we get both?
+Gary calls the combination “FauxO”. Logic and data are still combined, but there’s no mutation. Anywhere OOP would normally have mutation would just generate a new object. There’s no language restriction involved in enforcing immutability — just discipline.
+But without mutability, it’s hard to do IO and maintain state. So Gary’s solution is to encapsulate as much as possible into an immutable (functional or FauxO) core, and around that, use an imperative (traditional OOP) shell. The functional core contains the bulk of the logic, and the imperative shell is a glue layer that handles the real world, including disk, network, and other I/O.
+The result of this is that the shell has fewer paths, but more dependencies. The core contains no dependencies, but encapsulates the different logic paths. So we’re encapsulating dependencies on one side, and business logic on the other side. Or put another way, the way to figure out the separation is by doing as much as you can without mutation, and then encapsulating the mutation separately.
+I love how this naturally breaks things up, so that the core is all testable with unit tests, and the imperative shell is tested with integration tests. And since the shell has few or no logic paths, you get the testing pyramid, with more unit tests and fewer integration tests. The whole thing ends up being quite beautiful. Tests end up being very fast without any extra effort — not even stubbing or mocking. This tells us that things have been decomposed very well — an elegant design.
+Gary makes the case that immutable objects can be treated as values, and passed across boundaries. Even process boundaries. This is something I’ve noticed as I’ve been working on my own Uncle Bob style hexagonal framework, but nobody in that camp ever mentioned that — they prefer DTOs or something more like hashes. I’m completely against hashes, because of the “stringly-typed” problem. And I don’t see much advantage in a DTO if I’ve got an immutable object; I’d be basically copying the object to an almost identical object. And I’d be losing any laziness possible for derived values within the original immutable object.
+It’s striking to me how Gary’s image of an imperative shell around a functional core, plus Net, Disk, and State outside of the shell mirror’s Uncle Bob’s concentric circles. Uncle Bob has entities in the middle, surrounded by use cases, surrounded by Web, DB, and UI.
+Another advantage that Gary shows is that breaking things up this way allows easy concurrency. In his example, he shows using the actor model — either just using threads and queues, or an actor library (or language feature).
+After several years of thinking about the architectural issues seen in most large Rails apps, I’m starting to come to an understanding of how to combine all these ideas and come up with an architecture that will work better.
++]]>
So inspired by PJ Hagerty’s recent article on alternative Ruby web frameworks, I started thinking about how I’d write a replacement for Rails. I’d definitely keep the basic MVC framework. But I’d also want to implement a more hexagonal architecture.
+I started sketching out what this would look like, but I ended up starting with a Rails controller and finding the simplest way to make it hexagonal. I really don’t like callbacks, because they make tracing program execution difficult. But I didn’t see any other alternative. I found a simple pub/sub Ruby library called Wisper. It literally has only publish, subscribe, and on methods. (You use on to register single callbacks via blocks, and subscribe to register an object with method names corresponding to the callback names.)
The trick was figuring out how to break the controller into 2 pieces. What finally helped me was to find the single responsibilities of the 2 pieces. The Rails controller would remain in charge of managing the web interface, but would delegate to the other piece to handle any application-specific business logic. I decided to re-watch Uncle Bob Martin’s “Architecture The Lost Years” talk, which was the first time I was introduced to the ideas of Hexagonal Architecture. (He doesn’t name the architecture in the talk, but later calls it Clean Architecture.) He does a decent job of explaining how to break these 2 pieces apart. He used the term “interactor” in that talk, so I decided to go with that. He said that Jacobsen calls it a Control Object in Object Oriented Software Engineering, but that’s too close to Rails’s “controller”.
+So here’s an example of what I ended up with:
+class OrderController < ApplicationController
+ def index
+ interactor.on(:display) { |orders| render orders }
+ interactor.list
+ end
+
+ def show
+ interactor.on(:display) { |order| render order }
+ interactor.on(:not_found) { |order_id| render status: 404 }
+ interactor.get(params[:id])
+ end
+
+private
+
+ def interactor
+ @interactor ||= OrderInteractor.new
+ end
+end
+require "wisper" +require "order" + +class OrderInteractor + include Wisper.publisher + + def list + orders = Order.all + publish(:display, orders) + end + + def get(id) + order = Order.find(id) + publish(:display, order) + rescue ActiveRecord::RecordNotFound + publish(:not_found, id) + end +end+
I do have a few problems with this solution though. I’m not a fan of the name “interactor” for the business logic. I thought about calling it OrderOperator, or maybe OrderOperations, because it’s really a collection of operations. Perhaps it would be better to separate each operation into a separate class. Trailblazer does it that way. And for more complicated business logic, I would do that too, using the Method Object pattern. But like a Rails controller, there’s a lot in common among all the operations. I feel like a separate class for each operation for each would create too many coupled classes.
I’m also uncomfortable with the fact that the controller is delegating almost everything to the interactor. I guess this is OK, but it feels like there’s too little left when every line starts with interactor. I suppose extracting things some more would help mitigate this concern I’ll likely write a small gem to perform that extraction. I expect that that will allow a typical controller to be written in only a few lines. And maybe the same for the interactor side.
With the business logic extracted out of the controller, it was really easy for me to write a command-line version of the app. As Uncle Bob says, “the web is not particularly important to your application.”
+I’ve put the code for this example on GitHub: https://github.com/boochtek/hexagonal-rails. I’ll likely experiment with it some more over the next few weeks and months.
+]]>Let’s say you want to include an ORM in a model class, and want to tell it what database table to use. Typically, you’d do this:
+class User + include MyORM::Model + table 'people' +end+
But that table call is more like an option to the module inclusion than anything else. So what we’d really like is something like this:
class User + include MyORM::Model, table: 'people' +end+
But that’s not valid Ruby; include doesn’t let you pass anything other than a module.
So when I was learning about Virtus, I noticed that its example of how to include it is a bit different than the standard Ruby idiomatic include:
class User + include Virtus.model +end+
At first glance, it reads like the first example. But on closer inspection and consideration, it’s quite a bit different. Where MyORM::Model is a constant that refers to a module, Virtus.model is a method call. So there’s a method named model in the Virtus module. That method returns another module — which is exactly what’s needed in order to include it into our model class.
The easiest way to implement Virtus.model would be this:
module Virtus + def model + ::Virtus::Model + end +end + +module Virtus::Model + # ... +end+
If Virtus.model doesn’t need to take any arguments, that’s perfectly fine. In fact, I’ve started to use this implementation of the pattern for modules that don’t need parameters.
Because Virtus.model is a method, we can also call it with options:
class User + include Virtus.model(constructor: false, mass_assignment: false) +end+
We could even pass a block. But how do we process those options? There are a few different ways. However we do it, we have to be sure to return a module. And we can create modules in a few different ways.
+Virtus uses the builder pattern. It takes the parameters passed in and builds a module dynamically. By that, I mean that it calls Module.new and then adds methods to that module. It does this by mixing in other modules, but it could do it by dynamically defining methods as well.
I’ve never seen this pattern in any other language. It’s obviously only possible because we can dynamically create modules.
+The use of this idiom seems to be catching on a bit in the Ruby community. I’ve started using it myself, and will be adding it to my Includable::ActiveRecord gem soon.
++
+]]>
When you use ActiveRecord, you normally include it in your model like this:
+class User < ActiveRecord::Base + # ... +end+
Your User class is inheriting from the ActiveRecord::Base class. This is class-based inheritance, also called “classical” inheritance. (That’s “classical” as in “class”, not as a synonym for “traditional”.) Class-based inheritance represents an “is-a” relationship. So we’re saying that a user is an ActiveRecord base. Another way to say this is that User is a subclass of ActiveRecord::Base.
+
+There are a few problems with this. First, what is a “base”? The name was chosen because it’s a base class. But just like we don’t give factory classes names like UserFactory (at least not in Ruby), we shouldn’t name base classes Base.
I suppose that we’re trying to say that this is an ActiveRecord model. That sounds fine at first glance — this is our model for users. But what if we also want to say that a user is a person? Ruby doesn’t allow inheriting from multiple classes. Now we have to choose whether to inherit from ActiveRecord::Base or Person. Person makes more sense, because it fills the “is-a” rule better. Class inheritance is intended for a hierarchical “is-a” relationship, such as “a user is a person”, or “a circle is a shape”. But since ActiveRecord::Base is a base class, we have to use it as our base class.
We could work around this problem by subclassing Person from ActiveRecord::Base and then subclassing User from Person. That’s fine if Person is also a model that we store in the database. But if that’s not the case, then we have a problem.
Mixins
+Ruby provides another way of implementing inheritance — mixins. We often don’t think of this as an inheritance model, but it really is. When we include a module, that module gets added to the class’s ancestor chain. We can mix in as many modules as we want.
+Mixins indicate more of an “acts like” relationship than an “is-a” relationship. It’s for shared behavior between classes that don’t have a hierarchical relationship. For example, when we mix in the Enumerable module, we’re saying that we want our class to act like other classes that include Enumerable. That sounds more like what we want ActiveRecord to be. We want our user model to behave like other ActiveRecord models, in the way that they can persist to a database.
But ActiveRecord doesn’t support that. Almost all the other Ruby ORMs do; as we’ve shown above, this is for good reasons.
+So I decided to see if I could implement the equivalent of the ActiveRecord::Base class as a module that could be mixed into model classes. I decided to call my mixin module ActiveRecord::Model, because classes that mix it in will behave as ActiveRecord models.
It turns out that ActiveRecord::Base is a pretty complex class. It includes and extends a lot of other modules. Luckily, as of ActiveRecord 4.0, that’s all the code it includes.
The module only defines a single class method, included. This is one of Ruby’s many hook methods. It gets called when the module in question gets included in another module, and receives that other model as its argument. All we need to have this method do is to include everything that ActiveRecord::Base includes, and extend everything that ActiveRecord::Base extends. Ruby provides a method that’s defined on all classes, called included_modules, which we can use to get the list of everything that’s included in ActiveRecord::Base. Unfortunately, there’s no equivalent list of extended_modules. But a quick search on Stack Overflow found an implementation of extended_modules that we could use.
So with a bit of magic (i.e. hooks and meta-programming), we can get the lists of constituent modules from the ActiveRecord::Base class, and include them in our ActiveRecord::Model module.
So with all that, we can now include the includable-activerecord gem and mix it in, with all the advantages that provides:
+class User + include ActiveRecord::Model + # ... +end+
It was exciting to be able to make this work. Since I wrote it as a proof of concept, I haven’t written any tests yet. But it seems to be working just fine. The main thing I really need to look into is making sure that plugins that extend ActiveRecord::Base from their own code will still work. I’m pretty sure this will work out of the box, because the ActiveRecord::Model.included doesn’t run until the model class is loaded, and that happens after those plugins have initialized themselves.
So while I still prefer Ruby, and will likely use Ruby more in the future than Python, I wanted to assess the strengths and weaknesses of Python in relation to Ruby. Perhaps some of the lessons could be applied when writing Ruby, and it could help to decide when to use each. Also, I’m interested in programming language design, and wanted to document pros and cons in that light.
+Where Python Sucks (As Compared to Ruby)
++]]>
I consider most of the patterns in “Smalltalk Best Practice Patterns” to be patterns “in the small” — things that are typically employed on a single line or method. The Gang Of Four patterns are more medium sized, dealing with methods and classes. The PEAA book covers architectural-scale patterns. I suppose “The Pragmatic Programmer” and similar books could (should!) be considered to be very general patterns, mostly about the practice of programming.
+One type of pattern that I have not seen discussed much is debugging patterns. I’m not exactly sure why that is; probably just our general concentration on designing the program code itself. There are definitely testing patterns. But I can’t think of anything that I’ve seen that covers debugging patterns. A quick search on the Internet doesn’t turn up too much.
+Anyway, a co-worker (Helena) and I were debugging recently, and were having trouble figuring out where a certain method on a certain object was being called. We came up with a really cool solution. We immediately called it a grenade, because its entire purpose is to blow up (raise an exception) and display a backtrace to show us the caller of the method that we’re looking for.
+Here’s our implementation in Ruby:
+
+module Grenade
+ def method_under_investigation(*)
+ raise "method_under_investigation called"
+ end
+end
+
+class Xyz
+ ...
+ def xyz
+ object_under_investigation.extend(Grenade)
+ end
+ ...
+endI’m sure we could wrap that in some more semantic sugar, even going as far as making it look something like this:
+
+class Xyz
+ ...
+ def xyz
+ object_under_investigation.blow_up_when_method_called(:method_under_investigation)
+ end
+ ...
+end
+I’m not sure that would really be worth it though, unless we were to add it to some sort of library.
+So that’s our contribution to the (small) list of debugging patterns.
+]]>Web Development, Ruby on Rails, Open Source
+Most of us don’t write very readable shell scripts. There are plenty of things we could do better, but today I want to talk about one in particular — burying the lede.
+The term “burying the lede” comes from the field of journalism. Here’s the Wiktionary definition:
++To begin a story with details of secondary importance to the reader while postponing more essential points or facts.
Like a good news article, code should tell a story. And the story should start with what’s most important. In the case of code, the most important information is the high-level functionality — a succinct summary of what the program does. In other words, write (and organize) the code top-down, as opposed to bottom-up.
+Unfortunately, shell script doesn’t make this easy. Due to the way shell scripts are interpreted, you can’t call a function until after you’ve defined it. This leads to most of us structuring our code like this:
+function do_something { ... }
+function do_something_else { ... }
+
+do_something
+do_something_else
+The problem with this is that the function definitions will likely take quite a few lines, and we won’t see what the top-level functionality is until we reach the end of the script.
+I’d like to propose a standard way to structure shell scripts to mitigate this issue. (I’m really only talking about shell scripts that have function definitions within them.) I’m sure I’ve seen a few scripts do this, but it’s not very common at all.
+My proposal is simple:
+function main {
+ do_something
+ do_something_else
+}
+function do_something { ... }
+function do_something_else { ... }
+
+main
+This structure lets us start with the lede. We describe the top-level functionality right away. Only then do we get to the secondary details. The name main makes it pretty clear that it contains the top-level functionality.
I’ve recently started writing my shell code like this, and I’m happy with the results. I’ve also started to use some other programming techniques in my shell scripts to improve readability: better naming, extracting more methods, and moving helper methods into separate files. It feels good to treat shell scripts like real code instead of just some stuff I’ve hacked together.
+PS. The WordPress theme I’m currently using (Twenty Eleven) also buries the lede — I can barely even see the title of the blog post on my screen without scrolling. I’m going to have to change that soon.
+I recently decided to start using Emacs again. I used it extensively from the early 1990s until the early 2000s. I pretty much stopped using it when I had a sysadmin job with no Emacs on the servers, and no ability to install it. With the rising popularity of tmux and tmate for remote pairing, and my dislike for vim’s modes, I decided to try going back to Emacs in the terminal.
+One thing I really want in a text editor is good cursor key support. Shifted cursor keys
+should select text, and Control+left and right should move by words. (Apple HIG says to use Option+left and right to move by words; most apps on Mac OS X seem to support both.) Things have worked this way on almost every text editor on every OS I’ve used — Amiga, DOS, Windows, NeXT, Mac, Motif, Gnome, KDE. It’s a part of the CUA standard that’s been in common usage on everything since the mid-1980s.
Enabling cursor keys in Emacs was pretty easy. I’ve decided to use Prelude to make getting started with Emacs easy. Emacs comes with the cursor keys enabled, but Prelude disables them. Undoing Prelude’s change is pretty easy:
+(setq prelude-guru nil)+
Trying to make shifted cursor keys work is where the trouble began. They work in the GUI version of Emacs, but not from the terminal. It turns out that the Mac Terminal doesn’t distinguish between cursor keys and shifted cursor keys in its default configuration. So I had to figure out how to configure key bindings in Terminal.
+That’s easy enough — they’re in the preferences. But what should I set them to? This took a lot of research. Terminal emulation and ANSI code sequences are obscure, complex, and inconsistent. I eventually found the info I needed. For starters, Shift+Right, Shift+Left, Shift+Home, and Shift+End are defined in the terminfo. The rest I was able to piece together from various sources around the Internet.
+I’m also trying to script my Mac configuration. So instead of manually adding all the keybindings in the Terminal preferences pane, I decided to write a script. Mac OS X does a decent job of allowing you to change preferences from the command line. For example, to always show the tab bar:
+defaults write -app Terminal ShowTabBar 1+
Easy enough, except for a couple problems. First, I had to figure out the obscure syntax used in the preferences for key codes. I was able to piece these together with some more Internet research. But the really big problem is that the keyboard bindings are 2 levels deep within a “dictionary” (hash map). And the defaults command doesn’t handle that. There are some obscure utilities that handle nested preferences, but they don’t work well with the preferences caching in Mac OS X 10.9 — a problem I ran into while testing.
So now I’m writing a utility in Python that does what the defaults command does, but that will handle nested dictionaries.
There’s a term for this process of having to solve one issue before you can solve another, and the issues get several layers deep. It’s called yak shaving.
+Here’s another good example:
+
I’m sure this will be the first of many posts about me yak shaving.
+The term “burying the lede” comes from the field of journalism. Here’s the Wiktionary definition:
++To begin a story with details of secondary importance to the reader while postponing more essential points or facts.
Like a good news article, code should tell a story. And the story should start with what’s most important. In the case of code, the most important information is the high-level functionality — a succinct summary of what the program does. In other words, write (and organize) the code top-down, as opposed to bottom-up.
+Unfortunately, shell script doesn’t make this easy. Due to the way shell scripts are interpreted, you can’t call a function until after you’ve defined it. This leads to most of us structuring our code like this:
+function do_something { ... }
+function do_something_else { ... }
+
+do_something
+do_something_else
+The problem with this is that the function definitions will likely take quite a few lines, and we won’t see what the top-level functionality is until we reach the end of the script.
+I’d like to propose a standard way to structure shell scripts to mitigate this issue. (I’m really only talking about shell scripts that have function definitions within them.) I’m sure I’ve seen a few scripts do this, but it’s not very common at all.
+My proposal is simple:
+function main {
+ do_something
+ do_something_else
+}
+function do_something { ... }
+function do_something_else { ... }
+
+main
+This structure lets us start with the lede. We describe the top-level functionality right away. Only then do we get to the secondary details. The name main makes it pretty clear that it contains the top-level functionality.
I’ve recently started writing my shell code like this, and I’m happy with the results. I’ve also started to use some other programming techniques in my shell scripts to improve readability: better naming, extracting more methods, and moving helper methods into separate files. It feels good to treat shell scripts like real code instead of just some stuff I’ve hacked together.
+PS. The WordPress theme I’m currently using (Twenty Eleven) also buries the lede — I can barely even see the title of the blog post on my screen without scrolling. I’m going to have to change that soon.
+]]>One thing I really want in a text editor is good cursor key support. Shifted cursor keys
+should select text, and Control+left and right should move by words. (Apple HIG says to use Option+left and right to move by words; most apps on Mac OS X seem to support both.) Things have worked this way on almost every text editor on every OS I’ve used — Amiga, DOS, Windows, NeXT, Mac, Motif, Gnome, KDE. It’s a part of the CUA standard that’s been in common usage on everything since the mid-1980s.
Enabling cursor keys in Emacs was pretty easy. I’ve decided to use Prelude to make getting started with Emacs easy. Emacs comes with the cursor keys enabled, but Prelude disables them. Undoing Prelude’s change is pretty easy:
+(setq prelude-guru nil)+
Trying to make shifted cursor keys work is where the trouble began. They work in the GUI version of Emacs, but not from the terminal. It turns out that the Mac Terminal doesn’t distinguish between cursor keys and shifted cursor keys in its default configuration. So I had to figure out how to configure key bindings in Terminal.
+That’s easy enough — they’re in the preferences. But what should I set them to? This took a lot of research. Terminal emulation and ANSI code sequences are obscure, complex, and inconsistent. I eventually found the info I needed. For starters, Shift+Right, Shift+Left, Shift+Home, and Shift+End are defined in the terminfo. The rest I was able to piece together from various sources around the Internet.
+I’m also trying to script my Mac configuration. So instead of manually adding all the keybindings in the Terminal preferences pane, I decided to write a script. Mac OS X does a decent job of allowing you to change preferences from the command line. For example, to always show the tab bar:
+defaults write -app Terminal ShowTabBar 1+
Easy enough, except for a couple problems. First, I had to figure out the obscure syntax used in the preferences for key codes. I was able to piece these together with some more Internet research. But the really big problem is that the keyboard bindings are 2 levels deep within a “dictionary” (hash map). And the defaults command doesn’t handle that. There are some obscure utilities that handle nested preferences, but they don’t work well with the preferences caching in Mac OS X 10.9 — a problem I ran into while testing.
So now I’m writing a utility in Python that does what the defaults command does, but that will handle nested dictionaries.
There’s a term for this process of having to solve one issue before you can solve another, and the issues get several layers deep. It’s called yak shaving.
+Here’s another good example:
+
I’m sure this will be the first of many posts about me yak shaving.
+]]>Web Development, Ruby on Rails, Open Source
+I’ve written up a list of career-related resolutions the past few years. I’ve been pretty successful meeting those goals, so I’m going to continue the tradition.
+I want to increase the Open Source code I write this year. That’s basically everything I write that’s not directly related to work.
+I took over maintenance of Virtus late last year, but haven’t done a good job at finding the time for that. That’s probably more responding to issues on GitHub and merging pull requests. But eventually, I’ll likely add some features and do some refactoring.
+My goal is to work on 6 apps and libraries this year. That’s a pretty aggressive goal, but I want to focus on both learning new things and building some simple but useful things. Think MVP — focus on getting a lot of bang for not too much effort.
+I want to work on a new Rails app, to familiarize myself with Rails 5. I want to get some experience with some more modern gems. I also want to see if I can use some new techniques with a Rails app, especially things that might help us get closer to a hexagonal architecture. I’m also hoping to work with some different web frameworks — maybe Lotus, Rodakase, Trailblazer, or Phoenix. Or maybe one of the Crystal web frameworks.
+I also want to work on a couple Elm apps. I started the STL Elm group as an excuse to learn the language. I’d like to work on a Twitter client, that might eventually turn into a more general reading app. Beyond Twitter, it would keep track of things I want to read. The other Elm app I’d like to write is a game, based on the old Space Taxi game I loved to play on the Commodore 64.
+I wrote a micro-ORM last year called Ruby Preserves. I’ve started converting that from working with raw SQL to sitting atop the awesome Sequel gem. The simplicity is still there so far, and basing it on Sequel has so far gone easier than I expected. But I haven’t figured out how to do relationships (JOINs) yet; that will be the real test.
+I’m pretty happy with my 2015 conference experience. I want to keep my conference level about the same. I don’t really want to commit to more talks than I gave last year. Conference presentations take a lot of time and energy to write and practice.
+I’m planning to go to RailsConf, RubyConf, and Strange Loop. I’m hoping to give a talk at each of those, if I can. But I’ll probably attend all of them even if I’m not speaking. I’m also submitting a talk to Agile 2016. I’m unlikely to go to any other conferences, and even more unlikely to give more than 4 conference talks.
+I really want to finish my Effective Agile book this year. I’m going to try to pull Amos in to pair with me on it occasionally, to move it forward. If I’m able to get it done, I’d also like to maybe write a book on Elm.
+I actually want to do less blogging this year. Well, sort of. I want to put coding and book writing ahead of blogging. If that means less blogging, I’m okay with that. So my goal for blogging is more like every other week. And when I do write a blog article, I’d rather it be related to some code I’m working on, something that I could use in my book, or some more in-depth thoughts about programming language design.
+The contract I recently started at CenturyLink Cloud is open-ended, so I’ll likely be there for the entire year. I’m enjoying it so far; it’s a challenge, but I think I can make a significant impact. However, I’m really interested in moving to San Francisco in 2017. So I’m going to work on preparing for that in several ways.
+I’m going to resurrect my LinkedIn account. I’ve neglected it for a few years now. I’ll make sure everything is up to date, and make some connections I’ve been putting off. I also want to reclaim my Stack Exchange and Hacker News accounts.
+I’m going to pay a an expert to help me revamp my résumé. I think it’s pretty decent, but it could use some freshening up. I want it to stand out. I want to do a better job of explaining what I really do — which is to join a team to help them improve their processes and their technical skills.
+I’ll also need to clean up all my web sites, so they look nice when people come to take a look at them. This includes my personal site, consulting business site, wiki, and blogs. I should also upgrade my server to the latest version of Debian, and use Ansible and some other tools to provision it using the principles of Infrastructure as Code.
+It’s that time of year again — time for a retrospective on how I did on my goals for the year. I had 5 main goals for 2015:
+I got pretty lucky on this one. My main contract with Mercy got extended several times. Amos and I must have been doing a good job of keeping the customer happy. We even made it through a couple rounds of layoffs. I’m wrapping up the gig at Mercy now. I’m working one day a week there, as the project winds down.
+I also started a new gig this month at CenturyLink. I’m working on a cloud development team. Our current project involves selling WordPress as a service. The manager had been courting me for most of the year. I’m excited about my new role; I’ll be writing about it in a blog post soon.
+I set a goal in 2014 to give my first conference talk. I accomplished that, giving an ambitious talk at RubyConf. I enjoyed having done that, and vowed to do more conference speaking.
+I gave 3 conference talks in 2015. I gave a workshop on HTTP at RailsConf. I talked about immutable infrastructure at Madison+ Ruby. At RubyConf, I gave a talk on a micro-ORM I wrote. I also gave a lightning talk about Agile estimation (#noestimates).
+I was an alternate speaker at Windy City Rails, but did not give my talk on Alternatives to ActiveRecord. I also went to Strange Loop, mainly to see several friends and acquaintances speak.
+I wrote 24 blog articles this year. That’s about one every other week. What really kept me going was participating in a writing pact. When the pact was going, I had a 75% blogging rate. That’s pretty good.
+I’m not so sure about the quality of my blog writing though. I know that practicing writing is supposed to make you better. I know I wrote some really good articles over the past year, but I think I also wrote some articles that weren’t very good. I think sometimes the deadline has caused more harm than good. I’m not really sure what to do about that; perhaps just pushing on is the right answer.
+I’ve taken a lot of notes on the design of my programming language. Any time I learn something interesting about another language, or come up with another idea, I write it down.
+But I haven’t worked on the implementation. (I last worked on the implementation in 2014.) I should be experimenting with some ideas, implementing them to see how they work out. I’ve even kicked around the idea of starting with a Forth variant, just to get something working quickly.
+I haven’t written any articles on my ideas this year either. My notes are pretty extensive, and it would be good to write some articles to help get my thoughts straight.
+I’ve got some things to say about Agile, and want to write a book to express those ideas. I’ve made a start — I’ve got the chapters outlines, and have started on a few chapters. But I haven’t made as much progress as I’d like to. I shared what I’ve got with Amos, and he showed some interest in pairing with me on the writing. Hopefully we’ll work on it together in 2016 and publish it.
+There were a few other accomplishments that weren’t explicitly on my list, but I’d like to call attention to.
+I’ve continued participating on the This Agile Life podcast. I was in 12 of the 33 episodes that were recorded in 2015. I hope to participate in more in 2016. We’re considering scheduling a standard recording night each week, which might help us record more regularly.
+I recently took over as maintainer of Virtus, a library to declare attributes for Ruby model classes. I haven’t done a lot yet, since I’ve been busy with travel, vacation, and holidays. But I hope to catch up with all the pending pull requests and issues in the next month or so.
+The accomplishment I’m most proud of is mentoring for the Roy Clay Sr. Tech Impact program. This is a program begun as a result of the Ferguson protest movement. We’re helping teach kids (from 14 to 25) web design and development. My personal goal was to give these kids an opportunity that they would not have otherwise had. But it turned out that some of them have actually started a business building web sites for small companies. I’m so proud of the progress they’ve made in such a short time; it’s a challenging program.
+I’m pretty happy with my accomplishments this year. I made at least some progress on each of the goals I set. I’ve been thinking about my goals for next year; I’ll write that as a separate blog article next week.
+January kept me pretty busy, so I’m a little late to this. But better late than never. And as an Agile practitioner, I don’t think personal retrospectives should be limited to one time of year.
+Last year I wrote a blog entry listing my goals for 2014. As far as New Year’s resolutions go, I was relatively successful — about 50% of my goals accomplished. Unfortunately, my Open Source contributions weren’t as strong as I had hoped; while I released some of my own work, I didn’t do much else. I did increase my blogging; getting in on a weekly blogging pact helped immensely. I also increased my participation on the This Agile Life podcast to a level that I’m happy with. But the accomplishment I’m most proud of was giving a presentation at RubyConf.
+I’d like to keep things rolling from last year, but crank up a few things. My plans are quite ambitious, so I don’t expect to get everything done by any means. But I think by setting the bar high, I’ll end up with a lot I can be proud of.
+Late last year, I took the jump into independent consulting. So far, I’ve really enjoyed it, and I’m booked up through April. My wife graduates in May, so we’ve got the possibility of moving if that makes sense. So I’ll be looking for consulting projects in town, but I’ll also be looking at jobs in San Francisco and Chicago. The possibilities are exciting, and I’ll be taking my time to find something just right.
+I was incredibly nervous leading up to my RubyConf presentation. Part of that was just the common fear of public speaking. For me, that only kicks in at around 100 people, and this audience was around 250. I think another reason was that I chose a really ambitious topic, and I kept finding more that I wanted to talk about, but wasn’t prepared for. But I think I did a pretty good job presenting an advanced topic. And I was so pumped by the sense of accomplishment as soon as I finished. So I’m hoping to do it more. I’ve already submitted a couple proposals, and plan to submit several more.
+I believe that blogging is important for me to get my thoughts down — for myself and to share with others. I was really successful last year when I had a partner to keep me honest, via a pact. So I’ve started up another pact this year, which will hopefully ensure I’ll keep things going. I’ve got a really long backlog of topics, so as long as I keep at it, I’ll have plenty to write about.
+I also want to move away from WordPress to a static system — probably Middleman. I’ve got 2 major problems with WordPress. First, I no longer trust its security, nor the security of any application written in PHP. Second, it generates HTML every time someone requests a page, instead of when the content is updated. I find that to be a waste of resources, and problematic from a security standpoint. The main problem with moving to a static blogging system is that I really want to allow comments, pingbacks, and tweetbacks. So I’ll have to find a way to integrate those.
+Last year I started thinking about programming language design, and started implementing a language tentatively called Brilliant. I’ve done a lot more thinking on the topic, and have a lot of notes. But I haven’t implemented much more yet. This year, I’d like to get my thoughts more organized, and write a series of blog posts on various aspects of language design. The most interesting part seems to be the trade-offs involved in the ways that various language features interact. So I’d like to make some progress on the language implementation, but more importantly, I’d like to get a lot of my design ideas written down.
+I’m also going to spend a lot of time learning a bunch more programming languages, so I have a better understanding of possible features, combinations of features, and their interactions. I’ve already start with Elixir, Clojure, and Racket. I’m hoping to also look at OCaml, Factor, and Haskell. I’ll probably also take a look at the 2 “Seven Languages in Seven Weeks” books.
+I think people often have trouble getting started with Agile. I started on a book last year, and got down quite a lot of good ideas. But I realized that I’m going to have a hard time organizing all those ideas into something coherent. Still, I’d like to try to get something out there that lets people get started with Agile. My idea is to present a toolbox of practices to get started with and build on that foundation over time with additional practices. Sort of a playbook on how to get started over the first 6 to 12 months and be successful. I want to make some progress on the book, at least enough to decide whether it’s worth the effort to finish it and self-publish it.
++
I want to increase the Open Source code I write this year. That’s basically everything I write that’s not directly related to work.
+I took over maintenance of Virtus late last year, but haven’t done a good job at finding the time for that. That’s probably more responding to issues on GitHub and merging pull requests. But eventually, I’ll likely add some features and do some refactoring.
+My goal is to work on 6 apps and libraries this year. That’s a pretty aggressive goal, but I want to focus on both learning new things and building some simple but useful things. Think MVP — focus on getting a lot of bang for not too much effort.
+I want to work on a new Rails app, to familiarize myself with Rails 5. I want to get some experience with some more modern gems. I also want to see if I can use some new techniques with a Rails app, especially things that might help us get closer to a hexagonal architecture. I’m also hoping to work with some different web frameworks — maybe Lotus, Rodakase, Trailblazer, or Phoenix. Or maybe one of the Crystal web frameworks.
+I also want to work on a couple Elm apps. I started the STL Elm group as an excuse to learn the language. I’d like to work on a Twitter client, that might eventually turn into a more general reading app. Beyond Twitter, it would keep track of things I want to read. The other Elm app I’d like to write is a game, based on the old Space Taxi game I loved to play on the Commodore 64.
+I wrote a micro-ORM last year called Ruby Preserves. I’ve started converting that from working with raw SQL to sitting atop the awesome Sequel gem. The simplicity is still there so far, and basing it on Sequel has so far gone easier than I expected. But I haven’t figured out how to do relationships (JOINs) yet; that will be the real test.
+I’m pretty happy with my 2015 conference experience. I want to keep my conference level about the same. I don’t really want to commit to more talks than I gave last year. Conference presentations take a lot of time and energy to write and practice.
+I’m planning to go to RailsConf, RubyConf, and Strange Loop. I’m hoping to give a talk at each of those, if I can. But I’ll probably attend all of them even if I’m not speaking. I’m also submitting a talk to Agile 2016. I’m unlikely to go to any other conferences, and even more unlikely to give more than 4 conference talks.
+I really want to finish my Effective Agile book this year. I’m going to try to pull Amos in to pair with me on it occasionally, to move it forward. If I’m able to get it done, I’d also like to maybe write a book on Elm.
+I actually want to do less blogging this year. Well, sort of. I want to put coding and book writing ahead of blogging. If that means less blogging, I’m okay with that. So my goal for blogging is more like every other week. And when I do write a blog article, I’d rather it be related to some code I’m working on, something that I could use in my book, or some more in-depth thoughts about programming language design.
+The contract I recently started at CenturyLink Cloud is open-ended, so I’ll likely be there for the entire year. I’m enjoying it so far; it’s a challenge, but I think I can make a significant impact. However, I’m really interested in moving to San Francisco in 2017. So I’m going to work on preparing for that in several ways.
+I’m going to resurrect my LinkedIn account. I’ve neglected it for a few years now. I’ll make sure everything is up to date, and make some connections I’ve been putting off. I also want to reclaim my Stack Exchange and Hacker News accounts.
+I’m going to pay a an expert to help me revamp my résumé. I think it’s pretty decent, but it could use some freshening up. I want it to stand out. I want to do a better job of explaining what I really do — which is to join a team to help them improve their processes and their technical skills.
+I’ll also need to clean up all my web sites, so they look nice when people come to take a look at them. This includes my personal site, consulting business site, wiki, and blogs. I should also upgrade my server to the latest version of Debian, and use Ansible and some other tools to provision it using the principles of Infrastructure as Code.
+]]>I got pretty lucky on this one. My main contract with Mercy got extended several times. Amos and I must have been doing a good job of keeping the customer happy. We even made it through a couple rounds of layoffs. I’m wrapping up the gig at Mercy now. I’m working one day a week there, as the project winds down.
+I also started a new gig this month at CenturyLink. I’m working on a cloud development team. Our current project involves selling WordPress as a service. The manager had been courting me for most of the year. I’m excited about my new role; I’ll be writing about it in a blog post soon.
+I set a goal in 2014 to give my first conference talk. I accomplished that, giving an ambitious talk at RubyConf. I enjoyed having done that, and vowed to do more conference speaking.
+I gave 3 conference talks in 2015. I gave a workshop on HTTP at RailsConf. I talked about immutable infrastructure at Madison+ Ruby. At RubyConf, I gave a talk on a micro-ORM I wrote. I also gave a lightning talk about Agile estimation (#noestimates).
+I was an alternate speaker at Windy City Rails, but did not give my talk on Alternatives to ActiveRecord. I also went to Strange Loop, mainly to see several friends and acquaintances speak.
+I wrote 24 blog articles this year. That’s about one every other week. What really kept me going was participating in a writing pact. When the pact was going, I had a 75% blogging rate. That’s pretty good.
+I’m not so sure about the quality of my blog writing though. I know that practicing writing is supposed to make you better. I know I wrote some really good articles over the past year, but I think I also wrote some articles that weren’t very good. I think sometimes the deadline has caused more harm than good. I’m not really sure what to do about that; perhaps just pushing on is the right answer.
+I’ve taken a lot of notes on the design of my programming language. Any time I learn something interesting about another language, or come up with another idea, I write it down.
+But I haven’t worked on the implementation. (I last worked on the implementation in 2014.) I should be experimenting with some ideas, implementing them to see how they work out. I’ve even kicked around the idea of starting with a Forth variant, just to get something working quickly.
+I haven’t written any articles on my ideas this year either. My notes are pretty extensive, and it would be good to write some articles to help get my thoughts straight.
+I’ve got some things to say about Agile, and want to write a book to express those ideas. I’ve made a start — I’ve got the chapters outlines, and have started on a few chapters. But I haven’t made as much progress as I’d like to. I shared what I’ve got with Amos, and he showed some interest in pairing with me on the writing. Hopefully we’ll work on it together in 2016 and publish it.
+There were a few other accomplishments that weren’t explicitly on my list, but I’d like to call attention to.
+I’ve continued participating on the This Agile Life podcast. I was in 12 of the 33 episodes that were recorded in 2015. I hope to participate in more in 2016. We’re considering scheduling a standard recording night each week, which might help us record more regularly.
+I recently took over as maintainer of Virtus, a library to declare attributes for Ruby model classes. I haven’t done a lot yet, since I’ve been busy with travel, vacation, and holidays. But I hope to catch up with all the pending pull requests and issues in the next month or so.
+The accomplishment I’m most proud of is mentoring for the Roy Clay Sr. Tech Impact program. This is a program begun as a result of the Ferguson protest movement. We’re helping teach kids (from 14 to 25) web design and development. My personal goal was to give these kids an opportunity that they would not have otherwise had. But it turned out that some of them have actually started a business building web sites for small companies. I’m so proud of the progress they’ve made in such a short time; it’s a challenging program.
+I’m pretty happy with my accomplishments this year. I made at least some progress on each of the goals I set. I’ve been thinking about my goals for next year; I’ll write that as a separate blog article next week.
+]]>Last year I wrote a blog entry listing my goals for 2014. As far as New Year’s resolutions go, I was relatively successful — about 50% of my goals accomplished. Unfortunately, my Open Source contributions weren’t as strong as I had hoped; while I released some of my own work, I didn’t do much else. I did increase my blogging; getting in on a weekly blogging pact helped immensely. I also increased my participation on the This Agile Life podcast to a level that I’m happy with. But the accomplishment I’m most proud of was giving a presentation at RubyConf.
+I’d like to keep things rolling from last year, but crank up a few things. My plans are quite ambitious, so I don’t expect to get everything done by any means. But I think by setting the bar high, I’ll end up with a lot I can be proud of.
+Late last year, I took the jump into independent consulting. So far, I’ve really enjoyed it, and I’m booked up through April. My wife graduates in May, so we’ve got the possibility of moving if that makes sense. So I’ll be looking for consulting projects in town, but I’ll also be looking at jobs in San Francisco and Chicago. The possibilities are exciting, and I’ll be taking my time to find something just right.
+I was incredibly nervous leading up to my RubyConf presentation. Part of that was just the common fear of public speaking. For me, that only kicks in at around 100 people, and this audience was around 250. I think another reason was that I chose a really ambitious topic, and I kept finding more that I wanted to talk about, but wasn’t prepared for. But I think I did a pretty good job presenting an advanced topic. And I was so pumped by the sense of accomplishment as soon as I finished. So I’m hoping to do it more. I’ve already submitted a couple proposals, and plan to submit several more.
+I believe that blogging is important for me to get my thoughts down — for myself and to share with others. I was really successful last year when I had a partner to keep me honest, via a pact. So I’ve started up another pact this year, which will hopefully ensure I’ll keep things going. I’ve got a really long backlog of topics, so as long as I keep at it, I’ll have plenty to write about.
+I also want to move away from WordPress to a static system — probably Middleman. I’ve got 2 major problems with WordPress. First, I no longer trust its security, nor the security of any application written in PHP. Second, it generates HTML every time someone requests a page, instead of when the content is updated. I find that to be a waste of resources, and problematic from a security standpoint. The main problem with moving to a static blogging system is that I really want to allow comments, pingbacks, and tweetbacks. So I’ll have to find a way to integrate those.
+Last year I started thinking about programming language design, and started implementing a language tentatively called Brilliant. I’ve done a lot more thinking on the topic, and have a lot of notes. But I haven’t implemented much more yet. This year, I’d like to get my thoughts more organized, and write a series of blog posts on various aspects of language design. The most interesting part seems to be the trade-offs involved in the ways that various language features interact. So I’d like to make some progress on the language implementation, but more importantly, I’d like to get a lot of my design ideas written down.
+I’m also going to spend a lot of time learning a bunch more programming languages, so I have a better understanding of possible features, combinations of features, and their interactions. I’ve already start with Elixir, Clojure, and Racket. I’m hoping to also look at OCaml, Factor, and Haskell. I’ll probably also take a look at the 2 “Seven Languages in Seven Weeks” books.
+I think people often have trouble getting started with Agile. I started on a book last year, and got down quite a lot of good ideas. But I realized that I’m going to have a hard time organizing all those ideas into something coherent. Still, I’d like to try to get something out there that lets people get started with Agile. My idea is to present a toolbox of practices to get started with and build on that foundation over time with additional practices. Sort of a playbook on how to get started over the first 6 to 12 months and be successful. I want to make some progress on the book, at least enough to decide whether it’s worth the effort to finish it and self-publish it.
++]]>
Web Development, Ruby on Rails, Open Source
+It all started with an email about a WebInspect report. It listed a buffer overflow, which we had marked as a false positive. I read the WebInspect report carefully, and found a note at the bottom that said you could test manually to confirm whether it was a false positive or not. Unfortunately, the manual test listed had a few problems. First, it jammed the lines together, without the proper line-breaks. Second, it assumed the site was using HTTP, not HTTPS, so used telnet. Third, it was testing against a page that didn’t exist, giving a 404. Keeping those in mind, I tried the manual test using the openssl s_client command:
openssl s_client -quiet -connect mysite.example.com:443 +POST /login HTTP/1.1 +Host: mysite.example.com +Transfer-Encoding: chunked + +c00000000+
The test terminated immediately. The report said that this meant that the server was vulnerable to a buffer overflow and arbitrary code execution.
+At first, we thought this was caused by Apache or Tomcat, or possibly the application code. But the reported vulnerability was an Apache CVE from 2002 (CVE-2002-0392), fixed by vendors long ago. After a while, we realized that if we hit the servers directly, we did not get the indication of a vulnerability. If we hit the site through the F5 VIP, we saw the immediate termination of the connection. The issue is with handling of HTTP chunked encoding. Nginx had a similar issue in 2013 (CVE-2013-2028).
+So we turned our attention to the F5 load balancers. We were able to confirm that other sites using F5 load balancers were exhibiting the same behavior. We also confirmed that WebInspect run against the servers directly did not show the issue (even as a false positive). We reported the issue to F5, and they are looking into it.
+I’m disclosing this publicly now for a few reasons. First, I’m not a security researcher, and almost nobody follows my blog — especially people looking for security issues that could be exploited. Second, I’ve not developed a payload, so I have no idea whether this is exploitable. But at this point, it’s merely a potential vulnerability. I’m not sure I’ll even spend the time to research and create a payload to prove the vulnerability. If I do, I’ll be more careful with the disclosure.
++
January kept me pretty busy, so I’m a little late to this. But better late than never. And as an Agile practitioner, I don’t think personal retrospectives should be limited to one time of year.
+Last year I wrote a blog entry listing my goals for 2014. As far as New Year’s resolutions go, I was relatively successful — about 50% of my goals accomplished. Unfortunately, my Open Source contributions weren’t as strong as I had hoped; while I released some of my own work, I didn’t do much else. I did increase my blogging; getting in on a weekly blogging pact helped immensely. I also increased my participation on the This Agile Life podcast to a level that I’m happy with. But the accomplishment I’m most proud of was giving a presentation at RubyConf.
+I’d like to keep things rolling from last year, but crank up a few things. My plans are quite ambitious, so I don’t expect to get everything done by any means. But I think by setting the bar high, I’ll end up with a lot I can be proud of.
+Late last year, I took the jump into independent consulting. So far, I’ve really enjoyed it, and I’m booked up through April. My wife graduates in May, so we’ve got the possibility of moving if that makes sense. So I’ll be looking for consulting projects in town, but I’ll also be looking at jobs in San Francisco and Chicago. The possibilities are exciting, and I’ll be taking my time to find something just right.
+I was incredibly nervous leading up to my RubyConf presentation. Part of that was just the common fear of public speaking. For me, that only kicks in at around 100 people, and this audience was around 250. I think another reason was that I chose a really ambitious topic, and I kept finding more that I wanted to talk about, but wasn’t prepared for. But I think I did a pretty good job presenting an advanced topic. And I was so pumped by the sense of accomplishment as soon as I finished. So I’m hoping to do it more. I’ve already submitted a couple proposals, and plan to submit several more.
+I believe that blogging is important for me to get my thoughts down — for myself and to share with others. I was really successful last year when I had a partner to keep me honest, via a pact. So I’ve started up another pact this year, which will hopefully ensure I’ll keep things going. I’ve got a really long backlog of topics, so as long as I keep at it, I’ll have plenty to write about.
+I also want to move away from WordPress to a static system — probably Middleman. I’ve got 2 major problems with WordPress. First, I no longer trust its security, nor the security of any application written in PHP. Second, it generates HTML every time someone requests a page, instead of when the content is updated. I find that to be a waste of resources, and problematic from a security standpoint. The main problem with moving to a static blogging system is that I really want to allow comments, pingbacks, and tweetbacks. So I’ll have to find a way to integrate those.
+Last year I started thinking about programming language design, and started implementing a language tentatively called Brilliant. I’ve done a lot more thinking on the topic, and have a lot of notes. But I haven’t implemented much more yet. This year, I’d like to get my thoughts more organized, and write a series of blog posts on various aspects of language design. The most interesting part seems to be the trade-offs involved in the ways that various language features interact. So I’d like to make some progress on the language implementation, but more importantly, I’d like to get a lot of my design ideas written down.
+I’m also going to spend a lot of time learning a bunch more programming languages, so I have a better understanding of possible features, combinations of features, and their interactions. I’ve already start with Elixir, Clojure, and Racket. I’m hoping to also look at OCaml, Factor, and Haskell. I’ll probably also take a look at the 2 “Seven Languages in Seven Weeks” books.
+I think people often have trouble getting started with Agile. I started on a book last year, and got down quite a lot of good ideas. But I realized that I’m going to have a hard time organizing all those ideas into something coherent. Still, I’d like to try to get something out there that lets people get started with Agile. My idea is to present a toolbox of practices to get started with and build on that foundation over time with additional practices. Sort of a playbook on how to get started over the first 6 to 12 months and be successful. I want to make some progress on the book, at least enough to decide whether it’s worth the effort to finish it and self-publish it.
++
I facilitated our team retrospective this morning. I felt like we made a little forward progress, but not as much as I would have liked. But it really brought one thing to the forefront of my thoughts today — empathy gained through communication.
+We have a pretty large team by Agile standards — we had 20 people in our retro: 16 developers, 3 QA folks, and 1 manager. Out of those, only about 5 or 6 speak up regularly. I recently sent out a survey to the team, trying to get feedback on how we could improve our retros. A couple of the questions tried to get a feel for why people aren’t speaking up more. Only about half the people responded, and the answers didn’t really answer my question as well as I had hoped.
+So on Amos‘s suggestion, we did the Safety Check exercise. We got a good set of answers to why people don’t feel safe. About half of the answers were about the fear of looking stupid in front of other people. About half of those mentioned the manager — they’re worried they might get in trouble for what they say. We talked some about fear and how it’s more often than not misplaced. And that the worst consequences are usually not as bad as you might think. But then we got to the crux of the problem — there’s not enough trust amongst the team, and especially between the team members and the manager.
+About half of our team is new (within the past 6 months) — including the manager. While the developers have made some good progress building trust amongst each other, we haven’t had as much time with the manager to build trust between him and the rest of the team. So the lack of trust isn’t at all surprising.
+Honestly, I already knew we had trust issues, and wanted to address them, but needed a way to lead the team to that same realization. With this exercise driving out the issue, we were then able to have a conversation about trust. The conversation was pretty good. We got more voices to contribute than probably any other topic we’d previously covered. (I was disappointed that the manager kept quiet though. I later found that he was trying to mitigate people’s fears by keeping quiet, but I urged him to contribute more in the future.)
+But one point really stood out in my mind — a point of view that I hadn’t previously thought much about. Lauren, one of our QA analysts, pointed out that most human communication is non-verbal. We give tons of cues via body language, facial expressions, eye contact, tone of voice, even posture. I don’t recall if Lauren said it explicitly, but she pointed out that these cues build empathy between the speakers. She encouraged us to use more voice chat and video chat, as opposed to IRC text chat, because it would create more empathy between the people communicating, which would lead to more trust.
+I spent most of the rest of the day talking to people on the phone or via Google Hangouts voice. And every single time, I consciously noticed that I was gaining empathy for the person I was speaking with. I assume (and hope) that that’s working both ways. I suppose that it’s always been happening, but I never really noticed it.
+I’ve heard a lot of talk about empathy among Agile practitioners lately. It’s been mentioned on the Ruby Rogues podcast, and Angela Harms has been preaching it for years. I already understood how important it is. But until today, I didn’t really feel it happening.
+So if you’re looking to build trust with someone, spend some time talking with them. Preferably in person, but if that’s not possible, seriously consider video or voice modes of communication, instead of sending an email or an instant message.
++
I’m considering moving away from WordPress, for a couple reasons:
+Now that I’m starting to actually blog consistently, it makes sense to change. But before I move to something different, I want to be sure that I find all the features that I need. This post is my thought process about what I want.
+I’ve been playing with Jekyll lately, using it to generate a simple static site that can be updated easily. It’s pretty nice, and pretty easy to use. Something based on Jekyll would work well. The trickiest part will be figuring out how to manage comments. Or maybe I’ll just have to learn to live more minimally.
+Octopress is the obvious candidate. It fits most of my needs and wants. Most likely I’ll write my own commenting engine and add it to my Octopress template.
+The only other candidate that I’ve found is Ghost. It’s written in JavaScript and runs on Node. I don’t find Node to be that compelling, but the templates look great, and it’s designed for coding blogs.
+I’ll probably take a quick look at Droplets, too. It’s written in PHP, but seems to fit my other requirements.
+Unfortunately, that seems to be all there is in this space. Maybe I need to investigate more. Or maybe Octopress just has the static blog generation marked cornered. Either way, I’ll probably change my blogging software in the next month or two. Wish me luck!
++
telnet. Third, it was testing against a page that didn’t exist, giving a 404. Keeping those in mind, I tried the manual test using the openssl s_client command:
+openssl s_client -quiet -connect mysite.example.com:443 +POST /login HTTP/1.1 +Host: mysite.example.com +Transfer-Encoding: chunked + +c00000000+
The test terminated immediately. The report said that this meant that the server was vulnerable to a buffer overflow and arbitrary code execution.
+At first, we thought this was caused by Apache or Tomcat, or possibly the application code. But the reported vulnerability was an Apache CVE from 2002 (CVE-2002-0392), fixed by vendors long ago. After a while, we realized that if we hit the servers directly, we did not get the indication of a vulnerability. If we hit the site through the F5 VIP, we saw the immediate termination of the connection. The issue is with handling of HTTP chunked encoding. Nginx had a similar issue in 2013 (CVE-2013-2028).
+So we turned our attention to the F5 load balancers. We were able to confirm that other sites using F5 load balancers were exhibiting the same behavior. We also confirmed that WebInspect run against the servers directly did not show the issue (even as a false positive). We reported the issue to F5, and they are looking into it.
+I’m disclosing this publicly now for a few reasons. First, I’m not a security researcher, and almost nobody follows my blog — especially people looking for security issues that could be exploited. Second, I’ve not developed a payload, so I have no idea whether this is exploitable. But at this point, it’s merely a potential vulnerability. I’m not sure I’ll even spend the time to research and create a payload to prove the vulnerability. If I do, I’ll be more careful with the disclosure.
++]]>
Last year I wrote a blog entry listing my goals for 2014. As far as New Year’s resolutions go, I was relatively successful — about 50% of my goals accomplished. Unfortunately, my Open Source contributions weren’t as strong as I had hoped; while I released some of my own work, I didn’t do much else. I did increase my blogging; getting in on a weekly blogging pact helped immensely. I also increased my participation on the This Agile Life podcast to a level that I’m happy with. But the accomplishment I’m most proud of was giving a presentation at RubyConf.
+I’d like to keep things rolling from last year, but crank up a few things. My plans are quite ambitious, so I don’t expect to get everything done by any means. But I think by setting the bar high, I’ll end up with a lot I can be proud of.
+Late last year, I took the jump into independent consulting. So far, I’ve really enjoyed it, and I’m booked up through April. My wife graduates in May, so we’ve got the possibility of moving if that makes sense. So I’ll be looking for consulting projects in town, but I’ll also be looking at jobs in San Francisco and Chicago. The possibilities are exciting, and I’ll be taking my time to find something just right.
+I was incredibly nervous leading up to my RubyConf presentation. Part of that was just the common fear of public speaking. For me, that only kicks in at around 100 people, and this audience was around 250. I think another reason was that I chose a really ambitious topic, and I kept finding more that I wanted to talk about, but wasn’t prepared for. But I think I did a pretty good job presenting an advanced topic. And I was so pumped by the sense of accomplishment as soon as I finished. So I’m hoping to do it more. I’ve already submitted a couple proposals, and plan to submit several more.
+I believe that blogging is important for me to get my thoughts down — for myself and to share with others. I was really successful last year when I had a partner to keep me honest, via a pact. So I’ve started up another pact this year, which will hopefully ensure I’ll keep things going. I’ve got a really long backlog of topics, so as long as I keep at it, I’ll have plenty to write about.
+I also want to move away from WordPress to a static system — probably Middleman. I’ve got 2 major problems with WordPress. First, I no longer trust its security, nor the security of any application written in PHP. Second, it generates HTML every time someone requests a page, instead of when the content is updated. I find that to be a waste of resources, and problematic from a security standpoint. The main problem with moving to a static blogging system is that I really want to allow comments, pingbacks, and tweetbacks. So I’ll have to find a way to integrate those.
+Last year I started thinking about programming language design, and started implementing a language tentatively called Brilliant. I’ve done a lot more thinking on the topic, and have a lot of notes. But I haven’t implemented much more yet. This year, I’d like to get my thoughts more organized, and write a series of blog posts on various aspects of language design. The most interesting part seems to be the trade-offs involved in the ways that various language features interact. So I’d like to make some progress on the language implementation, but more importantly, I’d like to get a lot of my design ideas written down.
+I’m also going to spend a lot of time learning a bunch more programming languages, so I have a better understanding of possible features, combinations of features, and their interactions. I’ve already start with Elixir, Clojure, and Racket. I’m hoping to also look at OCaml, Factor, and Haskell. I’ll probably also take a look at the 2 “Seven Languages in Seven Weeks” books.
+I think people often have trouble getting started with Agile. I started on a book last year, and got down quite a lot of good ideas. But I realized that I’m going to have a hard time organizing all those ideas into something coherent. Still, I’d like to try to get something out there that lets people get started with Agile. My idea is to present a toolbox of practices to get started with and build on that foundation over time with additional practices. Sort of a playbook on how to get started over the first 6 to 12 months and be successful. I want to make some progress on the book, at least enough to decide whether it’s worth the effort to finish it and self-publish it.
++]]>
We have a pretty large team by Agile standards — we had 20 people in our retro: 16 developers, 3 QA folks, and 1 manager. Out of those, only about 5 or 6 speak up regularly. I recently sent out a survey to the team, trying to get feedback on how we could improve our retros. A couple of the questions tried to get a feel for why people aren’t speaking up more. Only about half the people responded, and the answers didn’t really answer my question as well as I had hoped.
+So on Amos‘s suggestion, we did the Safety Check exercise. We got a good set of answers to why people don’t feel safe. About half of the answers were about the fear of looking stupid in front of other people. About half of those mentioned the manager — they’re worried they might get in trouble for what they say. We talked some about fear and how it’s more often than not misplaced. And that the worst consequences are usually not as bad as you might think. But then we got to the crux of the problem — there’s not enough trust amongst the team, and especially between the team members and the manager.
+About half of our team is new (within the past 6 months) — including the manager. While the developers have made some good progress building trust amongst each other, we haven’t had as much time with the manager to build trust between him and the rest of the team. So the lack of trust isn’t at all surprising.
+Honestly, I already knew we had trust issues, and wanted to address them, but needed a way to lead the team to that same realization. With this exercise driving out the issue, we were then able to have a conversation about trust. The conversation was pretty good. We got more voices to contribute than probably any other topic we’d previously covered. (I was disappointed that the manager kept quiet though. I later found that he was trying to mitigate people’s fears by keeping quiet, but I urged him to contribute more in the future.)
+But one point really stood out in my mind — a point of view that I hadn’t previously thought much about. Lauren, one of our QA analysts, pointed out that most human communication is non-verbal. We give tons of cues via body language, facial expressions, eye contact, tone of voice, even posture. I don’t recall if Lauren said it explicitly, but she pointed out that these cues build empathy between the speakers. She encouraged us to use more voice chat and video chat, as opposed to IRC text chat, because it would create more empathy between the people communicating, which would lead to more trust.
+I spent most of the rest of the day talking to people on the phone or via Google Hangouts voice. And every single time, I consciously noticed that I was gaining empathy for the person I was speaking with. I assume (and hope) that that’s working both ways. I suppose that it’s always been happening, but I never really noticed it.
+I’ve heard a lot of talk about empathy among Agile practitioners lately. It’s been mentioned on the Ruby Rogues podcast, and Angela Harms has been preaching it for years. I already understood how important it is. But until today, I didn’t really feel it happening.
+So if you’re looking to build trust with someone, spend some time talking with them. Preferably in person, but if that’s not possible, seriously consider video or voice modes of communication, instead of sending an email or an instant message.
++]]>
Now that I’m starting to actually blog consistently, it makes sense to change. But before I move to something different, I want to be sure that I find all the features that I need. This post is my thought process about what I want.
+I’ve been playing with Jekyll lately, using it to generate a simple static site that can be updated easily. It’s pretty nice, and pretty easy to use. Something based on Jekyll would work well. The trickiest part will be figuring out how to manage comments. Or maybe I’ll just have to learn to live more minimally.
+Octopress is the obvious candidate. It fits most of my needs and wants. Most likely I’ll write my own commenting engine and add it to my Octopress template.
+The only other candidate that I’ve found is Ghost. It’s written in JavaScript and runs on Node. I don’t find Node to be that compelling, but the templates look great, and it’s designed for coding blogs.
+I’ll probably take a quick look at Droplets, too. It’s written in PHP, but seems to fit my other requirements.
+Unfortunately, that seems to be all there is in this space. Maybe I need to investigate more. Or maybe Octopress just has the static blog generation marked cornered. Either way, I’ll probably change my blogging software in the next month or two. Wish me luck!
++]]>
Web Development, Ruby on Rails, Open Source
+Most of us don’t write very readable shell scripts. There are plenty of things we could do better, but today I want to talk about one in particular — burying the lede.
+The term “burying the lede” comes from the field of journalism. Here’s the Wiktionary definition:
++To begin a story with details of secondary importance to the reader while postponing more essential points or facts.
Like a good news article, code should tell a story. And the story should start with what’s most important. In the case of code, the most important information is the high-level functionality — a succinct summary of what the program does. In other words, write (and organize) the code top-down, as opposed to bottom-up.
+Unfortunately, shell script doesn’t make this easy. Due to the way shell scripts are interpreted, you can’t call a function until after you’ve defined it. This leads to most of us structuring our code like this:
+function do_something { ... }
+function do_something_else { ... }
+
+do_something
+do_something_else
+The problem with this is that the function definitions will likely take quite a few lines, and we won’t see what the top-level functionality is until we reach the end of the script.
+I’d like to propose a standard way to structure shell scripts to mitigate this issue. (I’m really only talking about shell scripts that have function definitions within them.) I’m sure I’ve seen a few scripts do this, but it’s not very common at all.
+My proposal is simple:
+function main {
+ do_something
+ do_something_else
+}
+function do_something { ... }
+function do_something_else { ... }
+
+main
+This structure lets us start with the lede. We describe the top-level functionality right away. Only then do we get to the secondary details. The name main makes it pretty clear that it contains the top-level functionality.
I’ve recently started writing my shell code like this, and I’m happy with the results. I’ve also started to use some other programming techniques in my shell scripts to improve readability: better naming, extracting more methods, and moving helper methods into separate files. It feels good to treat shell scripts like real code instead of just some stuff I’ve hacked together.
+PS. The WordPress theme I’m currently using (Twenty Eleven) also buries the lede — I can barely even see the title of the blog post on my screen without scrolling. I’m going to have to change that soon.
+I recently decided to start using Emacs again. I used it extensively from the early 1990s until the early 2000s. I pretty much stopped using it when I had a sysadmin job with no Emacs on the servers, and no ability to install it. With the rising popularity of tmux and tmate for remote pairing, and my dislike for vim’s modes, I decided to try going back to Emacs in the terminal.
+One thing I really want in a text editor is good cursor key support. Shifted cursor keys
+should select text, and Control+left and right should move by words. (Apple HIG says to use Option+left and right to move by words; most apps on Mac OS X seem to support both.) Things have worked this way on almost every text editor on every OS I’ve used — Amiga, DOS, Windows, NeXT, Mac, Motif, Gnome, KDE. It’s a part of the CUA standard that’s been in common usage on everything since the mid-1980s.
Enabling cursor keys in Emacs was pretty easy. I’ve decided to use Prelude to make getting started with Emacs easy. Emacs comes with the cursor keys enabled, but Prelude disables them. Undoing Prelude’s change is pretty easy:
+(setq prelude-guru nil)+
Trying to make shifted cursor keys work is where the trouble began. They work in the GUI version of Emacs, but not from the terminal. It turns out that the Mac Terminal doesn’t distinguish between cursor keys and shifted cursor keys in its default configuration. So I had to figure out how to configure key bindings in Terminal.
+That’s easy enough — they’re in the preferences. But what should I set them to? This took a lot of research. Terminal emulation and ANSI code sequences are obscure, complex, and inconsistent. I eventually found the info I needed. For starters, Shift+Right, Shift+Left, Shift+Home, and Shift+End are defined in the terminfo. The rest I was able to piece together from various sources around the Internet.
+I’m also trying to script my Mac configuration. So instead of manually adding all the keybindings in the Terminal preferences pane, I decided to write a script. Mac OS X does a decent job of allowing you to change preferences from the command line. For example, to always show the tab bar:
+defaults write -app Terminal ShowTabBar 1+
Easy enough, except for a couple problems. First, I had to figure out the obscure syntax used in the preferences for key codes. I was able to piece these together with some more Internet research. But the really big problem is that the keyboard bindings are 2 levels deep within a “dictionary” (hash map). And the defaults command doesn’t handle that. There are some obscure utilities that handle nested preferences, but they don’t work well with the preferences caching in Mac OS X 10.9 — a problem I ran into while testing.
So now I’m writing a utility in Python that does what the defaults command does, but that will handle nested dictionaries.
There’s a term for this process of having to solve one issue before you can solve another, and the issues get several layers deep. It’s called yak shaving.
+Here’s another good example:
+
I’m sure this will be the first of many posts about me yak shaving.
+I’m considering moving away from WordPress, for a couple reasons:
+Now that I’m starting to actually blog consistently, it makes sense to change. But before I move to something different, I want to be sure that I find all the features that I need. This post is my thought process about what I want.
+I’ve been playing with Jekyll lately, using it to generate a simple static site that can be updated easily. It’s pretty nice, and pretty easy to use. Something based on Jekyll would work well. The trickiest part will be figuring out how to manage comments. Or maybe I’ll just have to learn to live more minimally.
+Octopress is the obvious candidate. It fits most of my needs and wants. Most likely I’ll write my own commenting engine and add it to my Octopress template.
+The only other candidate that I’ve found is Ghost. It’s written in JavaScript and runs on Node. I don’t find Node to be that compelling, but the templates look great, and it’s designed for coding blogs.
+I’ll probably take a quick look at Droplets, too. It’s written in PHP, but seems to fit my other requirements.
+Unfortunately, that seems to be all there is in this space. Maybe I need to investigate more. Or maybe Octopress just has the static blog generation marked cornered. Either way, I’ll probably change my blogging software in the next month or two. Wish me luck!
++
Here’s a relatively simple way to rename a bunch of files from the command line. It uses sed within a command substitution to compute the new names from the old names.
In this example, we’re renaming files that start with “ABC” to start with “XYZ” instead:
+ for i in ABC*; do mv $i $(echo $i | sed -e s/^ABC/XYZ/); done
+You’ll have to use shell globbing (wildcards) in the first part, to determine which files will be the source of the renaming, and regular expressions in the second part to translate the old names into the new names.
+It’s a good idea to use echo in place of mv before running this, to see what the results will be, so you don’t make a mistake.
Depending on the situation, you may need to adapt this for your particular needs. For example, if you have too many files to rename, you would need to use xargs. Or sed might not be up for the task of transforming the names that you want. Or you might need to use find to find files within a hierarchy. As with any UNIX idiom, there are hundreds of variations on the theme.
The term “burying the lede” comes from the field of journalism. Here’s the Wiktionary definition:
++To begin a story with details of secondary importance to the reader while postponing more essential points or facts.
Like a good news article, code should tell a story. And the story should start with what’s most important. In the case of code, the most important information is the high-level functionality — a succinct summary of what the program does. In other words, write (and organize) the code top-down, as opposed to bottom-up.
+Unfortunately, shell script doesn’t make this easy. Due to the way shell scripts are interpreted, you can’t call a function until after you’ve defined it. This leads to most of us structuring our code like this:
+function do_something { ... }
+function do_something_else { ... }
+
+do_something
+do_something_else
+The problem with this is that the function definitions will likely take quite a few lines, and we won’t see what the top-level functionality is until we reach the end of the script.
+I’d like to propose a standard way to structure shell scripts to mitigate this issue. (I’m really only talking about shell scripts that have function definitions within them.) I’m sure I’ve seen a few scripts do this, but it’s not very common at all.
+My proposal is simple:
+function main {
+ do_something
+ do_something_else
+}
+function do_something { ... }
+function do_something_else { ... }
+
+main
+This structure lets us start with the lede. We describe the top-level functionality right away. Only then do we get to the secondary details. The name main makes it pretty clear that it contains the top-level functionality.
I’ve recently started writing my shell code like this, and I’m happy with the results. I’ve also started to use some other programming techniques in my shell scripts to improve readability: better naming, extracting more methods, and moving helper methods into separate files. It feels good to treat shell scripts like real code instead of just some stuff I’ve hacked together.
+PS. The WordPress theme I’m currently using (Twenty Eleven) also buries the lede — I can barely even see the title of the blog post on my screen without scrolling. I’m going to have to change that soon.
+]]>One thing I really want in a text editor is good cursor key support. Shifted cursor keys
+should select text, and Control+left and right should move by words. (Apple HIG says to use Option+left and right to move by words; most apps on Mac OS X seem to support both.) Things have worked this way on almost every text editor on every OS I’ve used — Amiga, DOS, Windows, NeXT, Mac, Motif, Gnome, KDE. It’s a part of the CUA standard that’s been in common usage on everything since the mid-1980s.
Enabling cursor keys in Emacs was pretty easy. I’ve decided to use Prelude to make getting started with Emacs easy. Emacs comes with the cursor keys enabled, but Prelude disables them. Undoing Prelude’s change is pretty easy:
+(setq prelude-guru nil)+
Trying to make shifted cursor keys work is where the trouble began. They work in the GUI version of Emacs, but not from the terminal. It turns out that the Mac Terminal doesn’t distinguish between cursor keys and shifted cursor keys in its default configuration. So I had to figure out how to configure key bindings in Terminal.
+That’s easy enough — they’re in the preferences. But what should I set them to? This took a lot of research. Terminal emulation and ANSI code sequences are obscure, complex, and inconsistent. I eventually found the info I needed. For starters, Shift+Right, Shift+Left, Shift+Home, and Shift+End are defined in the terminfo. The rest I was able to piece together from various sources around the Internet.
+I’m also trying to script my Mac configuration. So instead of manually adding all the keybindings in the Terminal preferences pane, I decided to write a script. Mac OS X does a decent job of allowing you to change preferences from the command line. For example, to always show the tab bar:
+defaults write -app Terminal ShowTabBar 1+
Easy enough, except for a couple problems. First, I had to figure out the obscure syntax used in the preferences for key codes. I was able to piece these together with some more Internet research. But the really big problem is that the keyboard bindings are 2 levels deep within a “dictionary” (hash map). And the defaults command doesn’t handle that. There are some obscure utilities that handle nested preferences, but they don’t work well with the preferences caching in Mac OS X 10.9 — a problem I ran into while testing.
So now I’m writing a utility in Python that does what the defaults command does, but that will handle nested dictionaries.
There’s a term for this process of having to solve one issue before you can solve another, and the issues get several layers deep. It’s called yak shaving.
+Here’s another good example:
+I’m sure this will be the first of many posts about me yak shaving.
+]]>Now that I’m starting to actually blog consistently, it makes sense to change. But before I move to something different, I want to be sure that I find all the features that I need. This post is my thought process about what I want.
+I’ve been playing with Jekyll lately, using it to generate a simple static site that can be updated easily. It’s pretty nice, and pretty easy to use. Something based on Jekyll would work well. The trickiest part will be figuring out how to manage comments. Or maybe I’ll just have to learn to live more minimally.
+Octopress is the obvious candidate. It fits most of my needs and wants. Most likely I’ll write my own commenting engine and add it to my Octopress template.
+The only other candidate that I’ve found is Ghost. It’s written in JavaScript and runs on Node. I don’t find Node to be that compelling, but the templates look great, and it’s designed for coding blogs.
+I’ll probably take a quick look at Droplets, too. It’s written in PHP, but seems to fit my other requirements.
+Unfortunately, that seems to be all there is in this space. Maybe I need to investigate more. Or maybe Octopress just has the static blog generation marked cornered. Either way, I’ll probably change my blogging software in the next month or two. Wish me luck!
++]]>
sed within a command substitution to compute the new names from the old names.
+In this example, we’re renaming files that start with “ABC” to start with “XYZ” instead:
+ for i in ABC*; do mv $i $(echo $i | sed -e s/^ABC/XYZ/); done
+You’ll have to use shell globbing (wildcards) in the first part, to determine which files will be the source of the renaming, and regular expressions in the second part to translate the old names into the new names.
+It’s a good idea to use echo in place of mv before running this, to see what the results will be, so you don’t make a mistake.
Depending on the situation, you may need to adapt this for your particular needs. For example, if you have too many files to rename, you would need to use xargs. Or sed might not be up for the task of transforming the names that you want. Or you might need to use find to find files within a hierarchy. As with any UNIX idiom, there are hundreds of variations on the theme.
Web Development, Ruby on Rails, Open Source
+I recently attended an Open Space hosted at work. I’d never been to an Open Space, and didn’t know what to expect. We’d been told that this was a workshop to help Engineering Managers (my role), Product Owners, and Product Analysts find better ways of working together. But due to the way an Open Space works, it evolved into something completely different — and better.
+We’d brought in Diana Larsen to facilitate the Open Space. Diana is a stalwart of the Agile community, focusing on how people and teams interact. She literally (co-)wrote the book on Agile retrospectives. Diana was also kind enough to be our guest at an Agile LINC meetup later in the evening.
+The morning started off with all the participants sitting in chairs arranged in a circle. Diana rang a chime, a nice soothing tone that literally set the tone for the day. (Most people didn’t seem to like it, but I thought it had its purpose.) It also acted as a call to gather in the meeting space. She then walked around the inside of the circle as she explained what was going to happen.
+The idea behind Open Spaces came with the realization that at a conference, the “hallway track” (ad hoc discussions in the hallways) was often more valuable than the scheduled talks. So they figured out a way to capture that experience. There are only a few rules:
+Once Diana set the scene and explained the rules, people came up and presented ideas for topics. If you proposed a topic, you chose a time and location on the topic board. At that time, you’d facilitate a discussion on that topic. The format was really conducive to discussions. There was no preparation, so discussions were from the heart — lots of people felt that they could contribute.
+Being new to the company (only 2 months), I got a lot out of the workshop, beyond the content itself. I got to get to know several more people. I’d even say I made a few friends. Having open discussions, we found that many of the teams were having the same issues. This made it easy for me to talk to other people.
+All-in-all, I found the Open Space to be extremely conducive to discussions aimed at identifying issues, brainstorming solutions, and planning action items. I felt like we made great strides in addressing some of the biggest problems our organization is currently facing.
+I’ve written up a list of career-related resolutions the past few years. I’ve been pretty successful meeting those goals, so I’m going to continue the tradition.
+I want to increase the Open Source code I write this year. That’s basically everything I write that’s not directly related to work.
+I took over maintenance of Virtus late last year, but haven’t done a good job at finding the time for that. That’s probably more responding to issues on GitHub and merging pull requests. But eventually, I’ll likely add some features and do some refactoring.
+My goal is to work on 6 apps and libraries this year. That’s a pretty aggressive goal, but I want to focus on both learning new things and building some simple but useful things. Think MVP — focus on getting a lot of bang for not too much effort.
+I want to work on a new Rails app, to familiarize myself with Rails 5. I want to get some experience with some more modern gems. I also want to see if I can use some new techniques with a Rails app, especially things that might help us get closer to a hexagonal architecture. I’m also hoping to work with some different web frameworks — maybe Lotus, Rodakase, Trailblazer, or Phoenix. Or maybe one of the Crystal web frameworks.
+I also want to work on a couple Elm apps. I started the STL Elm group as an excuse to learn the language. I’d like to work on a Twitter client, that might eventually turn into a more general reading app. Beyond Twitter, it would keep track of things I want to read. The other Elm app I’d like to write is a game, based on the old Space Taxi game I loved to play on the Commodore 64.
+I wrote a micro-ORM last year called Ruby Preserves. I’ve started converting that from working with raw SQL to sitting atop the awesome Sequel gem. The simplicity is still there so far, and basing it on Sequel has so far gone easier than I expected. But I haven’t figured out how to do relationships (JOINs) yet; that will be the real test.
+I’m pretty happy with my 2015 conference experience. I want to keep my conference level about the same. I don’t really want to commit to more talks than I gave last year. Conference presentations take a lot of time and energy to write and practice.
+I’m planning to go to RailsConf, RubyConf, and Strange Loop. I’m hoping to give a talk at each of those, if I can. But I’ll probably attend all of them even if I’m not speaking. I’m also submitting a talk to Agile 2016. I’m unlikely to go to any other conferences, and even more unlikely to give more than 4 conference talks.
+I really want to finish my Effective Agile book this year. I’m going to try to pull Amos in to pair with me on it occasionally, to move it forward. If I’m able to get it done, I’d also like to maybe write a book on Elm.
+I actually want to do less blogging this year. Well, sort of. I want to put coding and book writing ahead of blogging. If that means less blogging, I’m okay with that. So my goal for blogging is more like every other week. And when I do write a blog article, I’d rather it be related to some code I’m working on, something that I could use in my book, or some more in-depth thoughts about programming language design.
+The contract I recently started at CenturyLink Cloud is open-ended, so I’ll likely be there for the entire year. I’m enjoying it so far; it’s a challenge, but I think I can make a significant impact. However, I’m really interested in moving to San Francisco in 2017. So I’m going to work on preparing for that in several ways.
+I’m going to resurrect my LinkedIn account. I’ve neglected it for a few years now. I’ll make sure everything is up to date, and make some connections I’ve been putting off. I also want to reclaim my Stack Exchange and Hacker News accounts.
+I’m going to pay a an expert to help me revamp my résumé. I think it’s pretty decent, but it could use some freshening up. I want it to stand out. I want to do a better job of explaining what I really do — which is to join a team to help them improve their processes and their technical skills.
+I’ll also need to clean up all my web sites, so they look nice when people come to take a look at them. This includes my personal site, consulting business site, wiki, and blogs. I should also upgrade my server to the latest version of Debian, and use Ansible and some other tools to provision it using the principles of Infrastructure as Code.
+Web Development, Ruby on Rails, Open Source
+While creating a web page isn’t too difficult, there are a lot of moving parts involved in creating an effective website. We’ve written up this checklist as a guide for anyone who has decided that they need a website.
+This list is for a basic static website. A web application will require significantly more effort. We’re working on a separate checklist for web apps.
+You’ll probably want your own domain name.
+You’ll need to have someone take care of the servers that tell the world what server addresses your domain name corresponds to.
+You’ll need servers to host your web site on. There are a lot of options available, from virtual hosts (a Linux server where you control everything) to application-specific services.
+Designing and developing the site can vary from picking an existing template and adding content, to developing a full web application.
+What other services do you need, besides just the web site?
+Over the lifetime of the site, you’ll likely pay more in maintenance costs than the upfront costs.
++
I’ve been working on application architectures based on Uncle Bob’s Ruby Midwest talk, following the hexagonal architectural pattern. I posted an article a couple months ago showing a way that works fairly well in Rails, and some accompanying Rails example code. But there was one thing I wasn’t quite happy with.
+The problem is that we used callbacks (actually, a publish/subscribe mechanism) in a situation where they don’t seem to quite fit:
+ def show
+ interactor.on(:display) { |order| render order }
+ interactor.on(:not_found) { |order_id| render status: 404 }
+ interactor.get(params[:id])
+ end
+What we really want is to respond in different ways, depending on the result of the call to interactor.get(). There’s no good reason to define the responses before the call. It makes a lot more sense to define the responses after the call, because they’ll happen after the call. I’d much prefer that the code be written in the order that it will be run.
I discussed this problem with my friend and colleague, Amos King. We came up with a better solution, which puts things back in the right order:
+ def show
+ interactor.get(params[:id]) do |on|
+ on.display { |order| render order }
+ on.not_found { |order_id| render status: 404 }
+ end
+ end
+He even wrote a small library to do this, which he called Riposte. I’m not sure what to call this pattern, but it seems to work pretty well in this situation. I suppose that they’re still technically callbacks, because they’re passed in in the block that’s passed in to the call to interactor.get(). But due to the magic of Ruby blocks, we get to put them in the order they should be.
Riposte also gives you the option of using the response object directly, instead of passing a block:
+ def show
+ on = interactor.get(params[:id])
+ on.display { |order| render order }
+ on.not_found { |order_id| render status: 404 }
+ end
+This shows that it’s just returning an object, with the twist that the response object has methods that take blocks. The nested blocks variant is really the same thing, except that it’s yielding to the response object instead of returning it.
+I’ve decide that is the pattern I’d like to use for interactions and their callers within Ruby hexagonal architecture.
+I’ve started working on my own framework in Ruby in the past couple days. It’s built upon my recent work at understanding Uncle Bob’s Ruby Midwest 2011 talk, and his article on Clean Architecture, and the resulting hexagonal architecture (AKA ports and adapters).
+Somehow my research in that vein led me to Gary Bernhardt’s Boundaries talk. I’ve read a lot about the talk, and knew about the idea of “functional core / imperative shell”. And I’ve worked with a lot of similar ideas lately. But I believe this is the first time that I actually watched the whole video.
+Even after having read a lot about similar ideas, it was pretty mind-expanding. Gary’s really good at presenting these kinds of ideas in a simple way.
+OOP as usually taught includes encapsulation of data together with behavior, with mutable objects. Functional programming separates data and behavior, with mostly immutable data. From experience, encapsulating data and behavior together seems helpful. But experience also shows that immutability is useful. So it would be good to have both of those together. This is something I’ve been thinking for a few years — how best do we get both?
+Gary calls the combination “FauxO”. Logic and data are still combined, but there’s no mutation. Anywhere OOP would normally have mutation would just generate a new object. There’s no language restriction involved in enforcing immutability — just discipline.
+But without mutability, it’s hard to do IO and maintain state. So Gary’s solution is to encapsulate as much as possible into an immutable (functional or FauxO) core, and around that, use an imperative (traditional OOP) shell. The functional core contains the bulk of the logic, and the imperative shell is a glue layer that handles the real world, including disk, network, and other I/O.
+The result of this is that the shell has fewer paths, but more dependencies. The core contains no dependencies, but encapsulates the different logic paths. So we’re encapsulating dependencies on one side, and business logic on the other side. Or put another way, the way to figure out the separation is by doing as much as you can without mutation, and then encapsulating the mutation separately.
+I love how this naturally breaks things up, so that the core is all testable with unit tests, and the imperative shell is tested with integration tests. And since the shell has few or no logic paths, you get the testing pyramid, with more unit tests and fewer integration tests. The whole thing ends up being quite beautiful. Tests end up being very fast without any extra effort — not even stubbing or mocking. This tells us that things have been decomposed very well — an elegant design.
+Gary makes the case that immutable objects can be treated as values, and passed across boundaries. Even process boundaries. This is something I’ve noticed as I’ve been working on my own Uncle Bob style hexagonal framework, but nobody in that camp ever mentioned that — they prefer DTOs or something more like hashes. I’m completely against hashes, because of the “stringly-typed” problem. And I don’t see much advantage in a DTO if I’ve got an immutable object; I’d be basically copying the object to an almost identical object. And I’d be losing any laziness possible for derived values within the original immutable object.
+It’s striking to me how Gary’s image of an imperative shell around a functional core, plus Net, Disk, and State outside of the shell mirror’s Uncle Bob’s concentric circles. Uncle Bob has entities in the middle, surrounded by use cases, surrounded by Web, DB, and UI.
+Another advantage that Gary shows is that breaking things up this way allows easy concurrency. In his example, he shows using the actor model — either just using threads and queues, or an actor library (or language feature).
+After several years of thinking about the architectural issues seen in most large Rails apps, I’m starting to come to an understanding of how to combine all these ideas and come up with an architecture that will work better.
++
I’ve had a long love-hate relationship with Rails. I love the MVC framework and how it’s improved our speed of writing web apps. But I’ve never really been completely happy with it. I don’t generally agree with most of its opinions. I prefer models that follow the Data Mapper pattern, not the Active Record pattern. This includes separating the persistence layer from the models’ business logic. I prefer Slim or HAML to ERB. I prefer RSpec to Test::Unit or MiniTest. When Merb hit the scene, I was ready to make the jump, until Merb merged with Rails.
+So inspired by PJ Hagerty’s recent article on alternative Ruby web frameworks, I started thinking about how I’d write a replacement for Rails. I’d definitely keep the basic MVC framework. But I’d also want to implement a more hexagonal architecture.
+I started sketching out what this would look like, but I ended up starting with a Rails controller and finding the simplest way to make it hexagonal. I really don’t like callbacks, because they make tracing program execution difficult. But I didn’t see any other alternative. I found a simple pub/sub Ruby library called Wisper. It literally has only publish, subscribe, and on methods. (You use on to register single callbacks via blocks, and subscribe to register an object with method names corresponding to the callback names.)
The trick was figuring out how to break the controller into 2 pieces. What finally helped me was to find the single responsibilities of the 2 pieces. The Rails controller would remain in charge of managing the web interface, but would delegate to the other piece to handle any application-specific business logic. I decided to re-watch Uncle Bob Martin’s “Architecture The Lost Years” talk, which was the first time I was introduced to the ideas of Hexagonal Architecture. (He doesn’t name the architecture in the talk, but later calls it Clean Architecture.) He does a decent job of explaining how to break these 2 pieces apart. He used the term “interactor” in that talk, so I decided to go with that. He said that Jacobsen calls it a Control Object in Object Oriented Software Engineering, but that’s too close to Rails’s “controller”.
+So here’s an example of what I ended up with:
+class OrderController < ApplicationController
+ def index
+ interactor.on(:display) { |orders| render orders }
+ interactor.list
+ end
+
+ def show
+ interactor.on(:display) { |order| render order }
+ interactor.on(:not_found) { |order_id| render status: 404 }
+ interactor.get(params[:id])
+ end
+
+private
+
+ def interactor
+ @interactor ||= OrderInteractor.new
+ end
+end
+require "wisper" +require "order" + +class OrderInteractor + include Wisper.publisher + + def list + orders = Order.all + publish(:display, orders) + end + + def get(id) + order = Order.find(id) + publish(:display, order) + rescue ActiveRecord::RecordNotFound + publish(:not_found, id) + end +end+
I do have a few problems with this solution though. I’m not a fan of the name “interactor” for the business logic. I thought about calling it OrderOperator, or maybe OrderOperations, because it’s really a collection of operations. Perhaps it would be better to separate each operation into a separate class. Trailblazer does it that way. And for more complicated business logic, I would do that too, using the Method Object pattern. But like a Rails controller, there’s a lot in common among all the operations. I feel like a separate class for each operation for each would create too many coupled classes.
I’m also uncomfortable with the fact that the controller is delegating almost everything to the interactor. I guess this is OK, but it feels like there’s too little left when every line starts with interactor. I suppose extracting things some more would help mitigate this concern I’ll likely write a small gem to perform that extraction. I expect that that will allow a typical controller to be written in only a few lines. And maybe the same for the interactor side.
With the business logic extracted out of the controller, it was really easy for me to write a command-line version of the app. As Uncle Bob says, “the web is not particularly important to your application.”
+I’ve put the code for this example on GitHub: https://github.com/boochtek/hexagonal-rails. I’ll likely experiment with it some more over the next few weeks and months.
+I went to RailsConf this year, and the very first talk was a keynote by David Heinemeier Hansson (DHH), the creator of Ruby on Rails. The TL;DR of his talk was “TDD rarely has value”. He followed up with a blog post the next day, titled “TDD is dead. Long live testing.“, and 2 more posts. I think this line of thought is terribly misguided, and causing more harm than good. This article is my response.
+First, I would like to address the good points of the talk. He said that programming is pseudoscience, and that people want to tell us that there’s a secret to being a better programmer. But what it really takes is working hard — reading a lot of code, writing a lot of code, and rewriting a lot of code. He’s right. And I also agree with him that you should forget about patterns for a while when learning to code. Beginners try to throw patterns at a problem instead of letting the patterns emerge where they’re supposed to.
+I don’t completely agree that programming is a pseudoscience. In some ways it is, but I think it’s more of a craft. It’s a craft, because there’s a lot of science involved, but there’s also an art to doing it well. And like any craft, you’re always working to get better. So to respond to DHH’s stance that “software is more like poetry than physics”, I think it falls
+somewhere in between.
With regard to the software engineering practices we use, there really isn’t much science available, mostly because it’s a soft science. That is, it’s really hard to isolate a single variable when comparing code between projects. And nobody has the time or money to write the same code so many times that the differences would be statistically significant.
+So we don’t have much science on TDD. But we do have some. Here’s a collection of several: StudiesOfTestDrivenDevelopment. And here’s one that explicitly looks are the difference between test-first and test-last: Does Test-Driven Development Really Improve Software Design Quality? What do these tell us? They tell us that TDD costs us about 10-30% in short-term productivity; reduces bugs by 30-90%, and decreases code complexity by about 30%. As Code Complete tells us (in section 20.5, with studies to back it up), improving quality reduces development costs. So, like most Agile practices, this is a case where spending a bit more time in the short term leads to time savings in the long term.
+The more important lesson in the talk was that you have to do what works best for you and your situation. If TDD doesn’t give better results, then either find out how to make it give better results, or stop using it. As we often say in the Agile world, Agile doesn’t mean that you can stop using your brain. While I think TDD is appropriate in most situations, there are cases where it’s not worth the additional up-front cost. If the most important thing for your project is time-to-market, then not testing might be the right decision for you.
+To me, TDD provides a bunch of benefits. First and foremost, TDD is a design discipline. It ensures that I think about how my code will be used before I think about how to implement it. This is very powerful in ensuring that the code is well-written from the perspective of other code using it.
+Tested code provides confidence to be able to make changes without breaking things. If we write tests after the code, we’re less likely to write them. Tests written after the code also tend to test the implementation instead of the desired functionality. What we really want is tests written as a specification. With tests as a specification, we can come back later and understand why code was written. Without tests, or with poor tests, we can’t understand why the code is there; if we want to rewrite it, we don’t have the confidence that we’re not missing something. Writing tests first also ensures that we only write the code that is needed to implement the required functionality.
+I’m not sure why DHH hasn’t “gotten” TDD. I’m not sure if it’s because he’s a better coder than average, or if he just thinks in a different way than most of us. I think it’s partly because he doesn’t understand TDD, which he admitted might be the case. And I think he’s conflating TDD and unit testing.
+DHH is influential in the developer community, especially those newer to Ruby and Rails. People listen to what he has to say. I was happy to see almost every other speaker made fun of DHH’s ideas, and most of the crowd knew better. But there will be a lot of others who will hear DHH, respect his opinions, and not give TDD the try that it deserves. And that’s sad, because it will lead to an overall reduction in code quality in the world.
+Here are some other people’s thoughts on the matter:
++
I created a Ruby gem recently, called includable-activerecord. It’s pretty small, but I thought I might explain why I created it, and discuss its implementation.
+When you use ActiveRecord, you normally include it in your model like this:
+class User < ActiveRecord::Base + # ... +end+
Your User class is inheriting from the ActiveRecord::Base class. This is class-based inheritance, also called “classical” inheritance. (That’s “classical” as in “class”, not as a synonym for “traditional”.) Class-based inheritance represents an “is-a” relationship. So we’re saying that a user is an ActiveRecord base. Another way to say this is that User is a subclass of ActiveRecord::Base.
+
+There are a few problems with this. First, what is a “base”? The name was chosen because it’s a base class. But just like we don’t give factory classes names like UserFactory (at least not in Ruby), we shouldn’t name base classes Base.
I suppose that we’re trying to say that this is an ActiveRecord model. That sounds fine at first glance — this is our model for users. But what if we also want to say that a user is a person? Ruby doesn’t allow inheriting from multiple classes. Now we have to choose whether to inherit from ActiveRecord::Base or Person. Person makes more sense, because it fills the “is-a” rule better. Class inheritance is intended for a hierarchical “is-a” relationship, such as “a user is a person”, or “a circle is a shape”. But since ActiveRecord::Base is a base class, we have to use it as our base class.
We could work around this problem by subclassing Person from ActiveRecord::Base and then subclassing User from Person. That’s fine if Person is also a model that we store in the database. But if that’s not the case, then we have a problem.
Mixins
+Ruby provides another way of implementing inheritance — mixins. We often don’t think of this as an inheritance model, but it really is. When we include a module, that module gets added to the class’s ancestor chain. We can mix in as many modules as we want.
+Mixins indicate more of an “acts like” relationship than an “is-a” relationship. It’s for shared behavior between classes that don’t have a hierarchical relationship. For example, when we mix in the Enumerable module, we’re saying that we want our class to act like other classes that include Enumerable. That sounds more like what we want ActiveRecord to be. We want our user model to behave like other ActiveRecord models, in the way that they can persist to a database.
But ActiveRecord doesn’t support that. Almost all the other Ruby ORMs do; as we’ve shown above, this is for good reasons.
+So I decided to see if I could implement the equivalent of the ActiveRecord::Base class as a module that could be mixed into model classes. I decided to call my mixin module ActiveRecord::Model, because classes that mix it in will behave as ActiveRecord models.
It turns out that ActiveRecord::Base is a pretty complex class. It includes and extends a lot of other modules. Luckily, as of ActiveRecord 4.0, that’s all the code it includes.
The module only defines a single class method, included. This is one of Ruby’s many hook methods. It gets called when the module in question gets included in another module, and receives that other model as its argument. All we need to have this method do is to include everything that ActiveRecord::Base includes, and extend everything that ActiveRecord::Base extends. Ruby provides a method that’s defined on all classes, called included_modules, which we can use to get the list of everything that’s included in ActiveRecord::Base. Unfortunately, there’s no equivalent list of extended_modules. But a quick search on Stack Overflow found an implementation of extended_modules that we could use.
So with a bit of magic (i.e. hooks and meta-programming), we can get the lists of constituent modules from the ActiveRecord::Base class, and include them in our ActiveRecord::Model module.
So with all that, we can now include the includable-activerecord gem and mix it in, with all the advantages that provides:
+class User + include ActiveRecord::Model + # ... +end+
It was exciting to be able to make this work. Since I wrote it as a proof of concept, I haven’t written any tests yet. But it seems to be working just fine. The main thing I really need to look into is making sure that plugins that extend ActiveRecord::Base from their own code will still work. I’m pretty sure this will work out of the box, because the ActiveRecord::Model.included doesn’t run until the model class is loaded, and that happens after those plugins have initialized themselves.
It’s challenging to test Rails custom validators.
+I recently had to write a validator to require that an entered date is before or after a specified date.
+It didn’t seem like writing the validator would be too difficult – I’ve written custom validators before, and date comparisons aren’t all that tricky. But when it came time to write the tests, I ran into several issues. And since I always try to follow TDD / test-first, I was blocked before I even began.
+The biggest issue was the ActiveModel::EachValidator#validates_each API. It’s definitely not a well-designed API. You write your validator as a subclass, overriding validates_each. The method takes a model object, the name of the attribute of the model being tested, and the value of that attribute. You can also get the options passed to the custom validator via the options method. To perform a validation, you have to update the model’s errors hash.
The big flaw in the API is that instead of returning a result, you have to update the model. This needlessly couples the model and the validator. And it violates the Single Responsibility Principle — it has to determine validity of the field, and it has to update the errors hash of the model. This is not conducive to testing. Testing this method requires testing that the side-effect has taken place in the collaborator (model), which means it’s not really a unit test any more.
So to make it easier to unit test the validator, I broke the coupling by breaking it into 2 pieces, one for each responsibility. I moved the responsibility for determining validity to a separate method, which I called errors_for. It returns a hash of the errors found. This simplified the validates_each method to simply take the result of errors_for and update the errors hash of the model:
def validate_each(record, attribute_name, attribute_value) + record.errors[attribute_name].concat(errors_for(attribute_value, options)) +end+
This made it much easier to unit test the errors_for method. This method doesn’t even need to know about the model — only about the value of the attribute we’re trying to validate. We simply pass in the attribute’s value and the options.
So we could write the tests without even pulling in ActiveRecord or any models:
+describe DateValidator do
+ let(:validator) { DateValidator.new(attributes: :attribute_name) }
+ let(:errors) { validator.errors_for(attribute_value, validation_options) }
+
+ describe 'when attribute value is NOT a valid date' do
+ let(:attribute_value) { 'not a valid date' }
+ it { errors.must_include 'is not a valid date' }
+ end
+
+ describe 'when attribute value IS a valid date' do
+ let(:attribute_value) { Date.parse('2013-12-11') }
+ it { errors.must_be :empty? }
+ end
+end
+And the errors_for method looked something like this:
def errors_for(attribute_value, options) + unless attribute_value.is_a?(Date) + return [options.fetch(:message, "is not a valid date")] + end + [] +end+
Integration testing can also be a bit of a challenge. I recommend following the example from this Stack Overflow answer. Basically, create a minimal model object that contains the field and the validation. Then test that the model behaves like you expect with different values and validations.
+This list is for a basic static website. A web application will require significantly more effort. We’re working on a separate checklist for web apps.
+You’ll probably want your own domain name.
+You’ll need to have someone take care of the servers that tell the world what server addresses your domain name corresponds to.
+You’ll need servers to host your web site on. There are a lot of options available, from virtual hosts (a Linux server where you control everything) to application-specific services.
+Designing and developing the site can vary from picking an existing template and adding content, to developing a full web application.
+What other services do you need, besides just the web site?
+Over the lifetime of the site, you’ll likely pay more in maintenance costs than the upfront costs.
++]]>
The problem is that we used callbacks (actually, a publish/subscribe mechanism) in a situation where they don’t seem to quite fit:
+ def show
+ interactor.on(:display) { |order| render order }
+ interactor.on(:not_found) { |order_id| render status: 404 }
+ interactor.get(params[:id])
+ end
+What we really want is to respond in different ways, depending on the result of the call to interactor.get(). There’s no good reason to define the responses before the call. It makes a lot more sense to define the responses after the call, because they’ll happen after the call. I’d much prefer that the code be written in the order that it will be run.
I discussed this problem with my friend and colleague, Amos King. We came up with a better solution, which puts things back in the right order:
+ def show
+ interactor.get(params[:id]) do |on|
+ on.display { |order| render order }
+ on.not_found { |order_id| render status: 404 }
+ end
+ end
+He even wrote a small library to do this, which he called Riposte. I’m not sure what to call this pattern, but it seems to work pretty well in this situation. I suppose that they’re still technically callbacks, because they’re passed in in the block that’s passed in to the call to interactor.get(). But due to the magic of Ruby blocks, we get to put them in the order they should be.
Riposte also gives you the option of using the response object directly, instead of passing a block:
+ def show
+ on = interactor.get(params[:id])
+ on.display { |order| render order }
+ on.not_found { |order_id| render status: 404 }
+ end
+This shows that it’s just returning an object, with the twist that the response object has methods that take blocks. The nested blocks variant is really the same thing, except that it’s yielding to the response object instead of returning it.
+I’ve decide that is the pattern I’d like to use for interactions and their callers within Ruby hexagonal architecture.
+]]>Somehow my research in that vein led me to Gary Bernhardt’s Boundaries talk. I’ve read a lot about the talk, and knew about the idea of “functional core / imperative shell”. And I’ve worked with a lot of similar ideas lately. But I believe this is the first time that I actually watched the whole video.
+Even after having read a lot about similar ideas, it was pretty mind-expanding. Gary’s really good at presenting these kinds of ideas in a simple way.
+OOP as usually taught includes encapsulation of data together with behavior, with mutable objects. Functional programming separates data and behavior, with mostly immutable data. From experience, encapsulating data and behavior together seems helpful. But experience also shows that immutability is useful. So it would be good to have both of those together. This is something I’ve been thinking for a few years — how best do we get both?
+Gary calls the combination “FauxO”. Logic and data are still combined, but there’s no mutation. Anywhere OOP would normally have mutation would just generate a new object. There’s no language restriction involved in enforcing immutability — just discipline.
+But without mutability, it’s hard to do IO and maintain state. So Gary’s solution is to encapsulate as much as possible into an immutable (functional or FauxO) core, and around that, use an imperative (traditional OOP) shell. The functional core contains the bulk of the logic, and the imperative shell is a glue layer that handles the real world, including disk, network, and other I/O.
+The result of this is that the shell has fewer paths, but more dependencies. The core contains no dependencies, but encapsulates the different logic paths. So we’re encapsulating dependencies on one side, and business logic on the other side. Or put another way, the way to figure out the separation is by doing as much as you can without mutation, and then encapsulating the mutation separately.
+I love how this naturally breaks things up, so that the core is all testable with unit tests, and the imperative shell is tested with integration tests. And since the shell has few or no logic paths, you get the testing pyramid, with more unit tests and fewer integration tests. The whole thing ends up being quite beautiful. Tests end up being very fast without any extra effort — not even stubbing or mocking. This tells us that things have been decomposed very well — an elegant design.
+Gary makes the case that immutable objects can be treated as values, and passed across boundaries. Even process boundaries. This is something I’ve noticed as I’ve been working on my own Uncle Bob style hexagonal framework, but nobody in that camp ever mentioned that — they prefer DTOs or something more like hashes. I’m completely against hashes, because of the “stringly-typed” problem. And I don’t see much advantage in a DTO if I’ve got an immutable object; I’d be basically copying the object to an almost identical object. And I’d be losing any laziness possible for derived values within the original immutable object.
+It’s striking to me how Gary’s image of an imperative shell around a functional core, plus Net, Disk, and State outside of the shell mirror’s Uncle Bob’s concentric circles. Uncle Bob has entities in the middle, surrounded by use cases, surrounded by Web, DB, and UI.
+Another advantage that Gary shows is that breaking things up this way allows easy concurrency. In his example, he shows using the actor model — either just using threads and queues, or an actor library (or language feature).
+After several years of thinking about the architectural issues seen in most large Rails apps, I’m starting to come to an understanding of how to combine all these ideas and come up with an architecture that will work better.
++]]>
So inspired by PJ Hagerty’s recent article on alternative Ruby web frameworks, I started thinking about how I’d write a replacement for Rails. I’d definitely keep the basic MVC framework. But I’d also want to implement a more hexagonal architecture.
+I started sketching out what this would look like, but I ended up starting with a Rails controller and finding the simplest way to make it hexagonal. I really don’t like callbacks, because they make tracing program execution difficult. But I didn’t see any other alternative. I found a simple pub/sub Ruby library called Wisper. It literally has only publish, subscribe, and on methods. (You use on to register single callbacks via blocks, and subscribe to register an object with method names corresponding to the callback names.)
The trick was figuring out how to break the controller into 2 pieces. What finally helped me was to find the single responsibilities of the 2 pieces. The Rails controller would remain in charge of managing the web interface, but would delegate to the other piece to handle any application-specific business logic. I decided to re-watch Uncle Bob Martin’s “Architecture The Lost Years” talk, which was the first time I was introduced to the ideas of Hexagonal Architecture. (He doesn’t name the architecture in the talk, but later calls it Clean Architecture.) He does a decent job of explaining how to break these 2 pieces apart. He used the term “interactor” in that talk, so I decided to go with that. He said that Jacobsen calls it a Control Object in Object Oriented Software Engineering, but that’s too close to Rails’s “controller”.
+So here’s an example of what I ended up with:
+class OrderController < ApplicationController
+ def index
+ interactor.on(:display) { |orders| render orders }
+ interactor.list
+ end
+
+ def show
+ interactor.on(:display) { |order| render order }
+ interactor.on(:not_found) { |order_id| render status: 404 }
+ interactor.get(params[:id])
+ end
+
+private
+
+ def interactor
+ @interactor ||= OrderInteractor.new
+ end
+end
+require "wisper" +require "order" + +class OrderInteractor + include Wisper.publisher + + def list + orders = Order.all + publish(:display, orders) + end + + def get(id) + order = Order.find(id) + publish(:display, order) + rescue ActiveRecord::RecordNotFound + publish(:not_found, id) + end +end+
I do have a few problems with this solution though. I’m not a fan of the name “interactor” for the business logic. I thought about calling it OrderOperator, or maybe OrderOperations, because it’s really a collection of operations. Perhaps it would be better to separate each operation into a separate class. Trailblazer does it that way. And for more complicated business logic, I would do that too, using the Method Object pattern. But like a Rails controller, there’s a lot in common among all the operations. I feel like a separate class for each operation for each would create too many coupled classes.
I’m also uncomfortable with the fact that the controller is delegating almost everything to the interactor. I guess this is OK, but it feels like there’s too little left when every line starts with interactor. I suppose extracting things some more would help mitigate this concern I’ll likely write a small gem to perform that extraction. I expect that that will allow a typical controller to be written in only a few lines. And maybe the same for the interactor side.
With the business logic extracted out of the controller, it was really easy for me to write a command-line version of the app. As Uncle Bob says, “the web is not particularly important to your application.”
+I’ve put the code for this example on GitHub: https://github.com/boochtek/hexagonal-rails. I’ll likely experiment with it some more over the next few weeks and months.
+]]>First, I would like to address the good points of the talk. He said that programming is pseudoscience, and that people want to tell us that there’s a secret to being a better programmer. But what it really takes is working hard — reading a lot of code, writing a lot of code, and rewriting a lot of code. He’s right. And I also agree with him that you should forget about patterns for a while when learning to code. Beginners try to throw patterns at a problem instead of letting the patterns emerge where they’re supposed to.
+I don’t completely agree that programming is a pseudoscience. In some ways it is, but I think it’s more of a craft. It’s a craft, because there’s a lot of science involved, but there’s also an art to doing it well. And like any craft, you’re always working to get better. So to respond to DHH’s stance that “software is more like poetry than physics”, I think it falls
+somewhere in between.
With regard to the software engineering practices we use, there really isn’t much science available, mostly because it’s a soft science. That is, it’s really hard to isolate a single variable when comparing code between projects. And nobody has the time or money to write the same code so many times that the differences would be statistically significant.
+So we don’t have much science on TDD. But we do have some. Here’s a collection of several: StudiesOfTestDrivenDevelopment. And here’s one that explicitly looks are the difference between test-first and test-last: Does Test-Driven Development Really Improve Software Design Quality? What do these tell us? They tell us that TDD costs us about 10-30% in short-term productivity; reduces bugs by 30-90%, and decreases code complexity by about 30%. As Code Complete tells us (in section 20.5, with studies to back it up), improving quality reduces development costs. So, like most Agile practices, this is a case where spending a bit more time in the short term leads to time savings in the long term.
+The more important lesson in the talk was that you have to do what works best for you and your situation. If TDD doesn’t give better results, then either find out how to make it give better results, or stop using it. As we often say in the Agile world, Agile doesn’t mean that you can stop using your brain. While I think TDD is appropriate in most situations, there are cases where it’s not worth the additional up-front cost. If the most important thing for your project is time-to-market, then not testing might be the right decision for you.
+To me, TDD provides a bunch of benefits. First and foremost, TDD is a design discipline. It ensures that I think about how my code will be used before I think about how to implement it. This is very powerful in ensuring that the code is well-written from the perspective of other code using it.
+Tested code provides confidence to be able to make changes without breaking things. If we write tests after the code, we’re less likely to write them. Tests written after the code also tend to test the implementation instead of the desired functionality. What we really want is tests written as a specification. With tests as a specification, we can come back later and understand why code was written. Without tests, or with poor tests, we can’t understand why the code is there; if we want to rewrite it, we don’t have the confidence that we’re not missing something. Writing tests first also ensures that we only write the code that is needed to implement the required functionality.
+I’m not sure why DHH hasn’t “gotten” TDD. I’m not sure if it’s because he’s a better coder than average, or if he just thinks in a different way than most of us. I think it’s partly because he doesn’t understand TDD, which he admitted might be the case. And I think he’s conflating TDD and unit testing.
+DHH is influential in the developer community, especially those newer to Ruby and Rails. People listen to what he has to say. I was happy to see almost every other speaker made fun of DHH’s ideas, and most of the crowd knew better. But there will be a lot of others who will hear DHH, respect his opinions, and not give TDD the try that it deserves. And that’s sad, because it will lead to an overall reduction in code quality in the world.
+Here are some other people’s thoughts on the matter:
++]]>
When you use ActiveRecord, you normally include it in your model like this:
+class User < ActiveRecord::Base + # ... +end+
Your User class is inheriting from the ActiveRecord::Base class. This is class-based inheritance, also called “classical” inheritance. (That’s “classical” as in “class”, not as a synonym for “traditional”.) Class-based inheritance represents an “is-a” relationship. So we’re saying that a user is an ActiveRecord base. Another way to say this is that User is a subclass of ActiveRecord::Base.
+
+There are a few problems with this. First, what is a “base”? The name was chosen because it’s a base class. But just like we don’t give factory classes names like UserFactory (at least not in Ruby), we shouldn’t name base classes Base.
I suppose that we’re trying to say that this is an ActiveRecord model. That sounds fine at first glance — this is our model for users. But what if we also want to say that a user is a person? Ruby doesn’t allow inheriting from multiple classes. Now we have to choose whether to inherit from ActiveRecord::Base or Person. Person makes more sense, because it fills the “is-a” rule better. Class inheritance is intended for a hierarchical “is-a” relationship, such as “a user is a person”, or “a circle is a shape”. But since ActiveRecord::Base is a base class, we have to use it as our base class.
We could work around this problem by subclassing Person from ActiveRecord::Base and then subclassing User from Person. That’s fine if Person is also a model that we store in the database. But if that’s not the case, then we have a problem.
Mixins
+Ruby provides another way of implementing inheritance — mixins. We often don’t think of this as an inheritance model, but it really is. When we include a module, that module gets added to the class’s ancestor chain. We can mix in as many modules as we want.
+Mixins indicate more of an “acts like” relationship than an “is-a” relationship. It’s for shared behavior between classes that don’t have a hierarchical relationship. For example, when we mix in the Enumerable module, we’re saying that we want our class to act like other classes that include Enumerable. That sounds more like what we want ActiveRecord to be. We want our user model to behave like other ActiveRecord models, in the way that they can persist to a database.
But ActiveRecord doesn’t support that. Almost all the other Ruby ORMs do; as we’ve shown above, this is for good reasons.
+So I decided to see if I could implement the equivalent of the ActiveRecord::Base class as a module that could be mixed into model classes. I decided to call my mixin module ActiveRecord::Model, because classes that mix it in will behave as ActiveRecord models.
It turns out that ActiveRecord::Base is a pretty complex class. It includes and extends a lot of other modules. Luckily, as of ActiveRecord 4.0, that’s all the code it includes.
The module only defines a single class method, included. This is one of Ruby’s many hook methods. It gets called when the module in question gets included in another module, and receives that other model as its argument. All we need to have this method do is to include everything that ActiveRecord::Base includes, and extend everything that ActiveRecord::Base extends. Ruby provides a method that’s defined on all classes, called included_modules, which we can use to get the list of everything that’s included in ActiveRecord::Base. Unfortunately, there’s no equivalent list of extended_modules. But a quick search on Stack Overflow found an implementation of extended_modules that we could use.
So with a bit of magic (i.e. hooks and meta-programming), we can get the lists of constituent modules from the ActiveRecord::Base class, and include them in our ActiveRecord::Model module.
So with all that, we can now include the includable-activerecord gem and mix it in, with all the advantages that provides:
+class User + include ActiveRecord::Model + # ... +end+
It was exciting to be able to make this work. Since I wrote it as a proof of concept, I haven’t written any tests yet. But it seems to be working just fine. The main thing I really need to look into is making sure that plugins that extend ActiveRecord::Base from their own code will still work. I’m pretty sure this will work out of the box, because the ActiveRecord::Model.included doesn’t run until the model class is loaded, and that happens after those plugins have initialized themselves.
I recently had to write a validator to require that an entered date is before or after a specified date.
+It didn’t seem like writing the validator would be too difficult – I’ve written custom validators before, and date comparisons aren’t all that tricky. But when it came time to write the tests, I ran into several issues. And since I always try to follow TDD / test-first, I was blocked before I even began.
+The biggest issue was the ActiveModel::EachValidator#validates_each API. It’s definitely not a well-designed API. You write your validator as a subclass, overriding validates_each. The method takes a model object, the name of the attribute of the model being tested, and the value of that attribute. You can also get the options passed to the custom validator via the options method. To perform a validation, you have to update the model’s errors hash.
The big flaw in the API is that instead of returning a result, you have to update the model. This needlessly couples the model and the validator. And it violates the Single Responsibility Principle — it has to determine validity of the field, and it has to update the errors hash of the model. This is not conducive to testing. Testing this method requires testing that the side-effect has taken place in the collaborator (model), which means it’s not really a unit test any more.
So to make it easier to unit test the validator, I broke the coupling by breaking it into 2 pieces, one for each responsibility. I moved the responsibility for determining validity to a separate method, which I called errors_for. It returns a hash of the errors found. This simplified the validates_each method to simply take the result of errors_for and update the errors hash of the model:
def validate_each(record, attribute_name, attribute_value) + record.errors[attribute_name].concat(errors_for(attribute_value, options)) +end+
This made it much easier to unit test the errors_for method. This method doesn’t even need to know about the model — only about the value of the attribute we’re trying to validate. We simply pass in the attribute’s value and the options.
So we could write the tests without even pulling in ActiveRecord or any models:
+describe DateValidator do
+ let(:validator) { DateValidator.new(attributes: :attribute_name) }
+ let(:errors) { validator.errors_for(attribute_value, validation_options) }
+
+ describe 'when attribute value is NOT a valid date' do
+ let(:attribute_value) { 'not a valid date' }
+ it { errors.must_include 'is not a valid date' }
+ end
+
+ describe 'when attribute value IS a valid date' do
+ let(:attribute_value) { Date.parse('2013-12-11') }
+ it { errors.must_be :empty? }
+ end
+end
+And the errors_for method looked something like this:
def errors_for(attribute_value, options) + unless attribute_value.is_a?(Date) + return [options.fetch(:message, "is not a valid date")] + end + [] +end+
Integration testing can also be a bit of a challenge. I recommend following the example from this Stack Overflow answer. Basically, create a minimal model object that contains the field and the validation. Then test that the model behaves like you expect with different values and validations.
+]]>Web Development, Ruby on Rails, Open Source
+I’ve been working on application architectures based on Uncle Bob’s Ruby Midwest talk, following the hexagonal architectural pattern. I posted an article a couple months ago showing a way that works fairly well in Rails, and some accompanying Rails example code. But there was one thing I wasn’t quite happy with.
+The problem is that we used callbacks (actually, a publish/subscribe mechanism) in a situation where they don’t seem to quite fit:
+ def show
+ interactor.on(:display) { |order| render order }
+ interactor.on(:not_found) { |order_id| render status: 404 }
+ interactor.get(params[:id])
+ end
+What we really want is to respond in different ways, depending on the result of the call to interactor.get(). There’s no good reason to define the responses before the call. It makes a lot more sense to define the responses after the call, because they’ll happen after the call. I’d much prefer that the code be written in the order that it will be run.
I discussed this problem with my friend and colleague, Amos King. We came up with a better solution, which puts things back in the right order:
+ def show
+ interactor.get(params[:id]) do |on|
+ on.display { |order| render order }
+ on.not_found { |order_id| render status: 404 }
+ end
+ end
+He even wrote a small library to do this, which he called Riposte. I’m not sure what to call this pattern, but it seems to work pretty well in this situation. I suppose that they’re still technically callbacks, because they’re passed in in the block that’s passed in to the call to interactor.get(). But due to the magic of Ruby blocks, we get to put them in the order they should be.
Riposte also gives you the option of using the response object directly, instead of passing a block:
+ def show
+ on = interactor.get(params[:id])
+ on.display { |order| render order }
+ on.not_found { |order_id| render status: 404 }
+ end
+This shows that it’s just returning an object, with the twist that the response object has methods that take blocks. The nested blocks variant is really the same thing, except that it’s yielding to the response object instead of returning it.
+I’ve decide that is the pattern I’d like to use for interactions and their callers within Ruby hexagonal architecture.
+I’ve had a long love-hate relationship with Rails. I love the MVC framework and how it’s improved our speed of writing web apps. But I’ve never really been completely happy with it. I don’t generally agree with most of its opinions. I prefer models that follow the Data Mapper pattern, not the Active Record pattern. This includes separating the persistence layer from the models’ business logic. I prefer Slim or HAML to ERB. I prefer RSpec to Test::Unit or MiniTest. When Merb hit the scene, I was ready to make the jump, until Merb merged with Rails.
+So inspired by PJ Hagerty’s recent article on alternative Ruby web frameworks, I started thinking about how I’d write a replacement for Rails. I’d definitely keep the basic MVC framework. But I’d also want to implement a more hexagonal architecture.
+I started sketching out what this would look like, but I ended up starting with a Rails controller and finding the simplest way to make it hexagonal. I really don’t like callbacks, because they make tracing program execution difficult. But I didn’t see any other alternative. I found a simple pub/sub Ruby library called Wisper. It literally has only publish, subscribe, and on methods. (You use on to register single callbacks via blocks, and subscribe to register an object with method names corresponding to the callback names.)
The trick was figuring out how to break the controller into 2 pieces. What finally helped me was to find the single responsibilities of the 2 pieces. The Rails controller would remain in charge of managing the web interface, but would delegate to the other piece to handle any application-specific business logic. I decided to re-watch Uncle Bob Martin’s “Architecture The Lost Years” talk, which was the first time I was introduced to the ideas of Hexagonal Architecture. (He doesn’t name the architecture in the talk, but later calls it Clean Architecture.) He does a decent job of explaining how to break these 2 pieces apart. He used the term “interactor” in that talk, so I decided to go with that. He said that Jacobsen calls it a Control Object in Object Oriented Software Engineering, but that’s too close to Rails’s “controller”.
+So here’s an example of what I ended up with:
+class OrderController < ApplicationController
+ def index
+ interactor.on(:display) { |orders| render orders }
+ interactor.list
+ end
+
+ def show
+ interactor.on(:display) { |order| render order }
+ interactor.on(:not_found) { |order_id| render status: 404 }
+ interactor.get(params[:id])
+ end
+
+private
+
+ def interactor
+ @interactor ||= OrderInteractor.new
+ end
+end
+require "wisper" +require "order" + +class OrderInteractor + include Wisper.publisher + + def list + orders = Order.all + publish(:display, orders) + end + + def get(id) + order = Order.find(id) + publish(:display, order) + rescue ActiveRecord::RecordNotFound + publish(:not_found, id) + end +end+
I do have a few problems with this solution though. I’m not a fan of the name “interactor” for the business logic. I thought about calling it OrderOperator, or maybe OrderOperations, because it’s really a collection of operations. Perhaps it would be better to separate each operation into a separate class. Trailblazer does it that way. And for more complicated business logic, I would do that too, using the Method Object pattern. But like a Rails controller, there’s a lot in common among all the operations. I feel like a separate class for each operation for each would create too many coupled classes.
I’m also uncomfortable with the fact that the controller is delegating almost everything to the interactor. I guess this is OK, but it feels like there’s too little left when every line starts with interactor. I suppose extracting things some more would help mitigate this concern I’ll likely write a small gem to perform that extraction. I expect that that will allow a typical controller to be written in only a few lines. And maybe the same for the interactor side.
With the business logic extracted out of the controller, it was really easy for me to write a command-line version of the app. As Uncle Bob says, “the web is not particularly important to your application.”
+I’ve put the code for this example on GitHub: https://github.com/boochtek/hexagonal-rails. I’ll likely experiment with it some more over the next few weeks and months.
+I went to RailsConf this year, and the very first talk was a keynote by David Heinemeier Hansson (DHH), the creator of Ruby on Rails. The TL;DR of his talk was “TDD rarely has value”. He followed up with a blog post the next day, titled “TDD is dead. Long live testing.“, and 2 more posts. I think this line of thought is terribly misguided, and causing more harm than good. This article is my response.
+First, I would like to address the good points of the talk. He said that programming is pseudoscience, and that people want to tell us that there’s a secret to being a better programmer. But what it really takes is working hard — reading a lot of code, writing a lot of code, and rewriting a lot of code. He’s right. And I also agree with him that you should forget about patterns for a while when learning to code. Beginners try to throw patterns at a problem instead of letting the patterns emerge where they’re supposed to.
+I don’t completely agree that programming is a pseudoscience. In some ways it is, but I think it’s more of a craft. It’s a craft, because there’s a lot of science involved, but there’s also an art to doing it well. And like any craft, you’re always working to get better. So to respond to DHH’s stance that “software is more like poetry than physics”, I think it falls
+somewhere in between.
With regard to the software engineering practices we use, there really isn’t much science available, mostly because it’s a soft science. That is, it’s really hard to isolate a single variable when comparing code between projects. And nobody has the time or money to write the same code so many times that the differences would be statistically significant.
+So we don’t have much science on TDD. But we do have some. Here’s a collection of several: StudiesOfTestDrivenDevelopment. And here’s one that explicitly looks are the difference between test-first and test-last: Does Test-Driven Development Really Improve Software Design Quality? What do these tell us? They tell us that TDD costs us about 10-30% in short-term productivity; reduces bugs by 30-90%, and decreases code complexity by about 30%. As Code Complete tells us (in section 20.5, with studies to back it up), improving quality reduces development costs. So, like most Agile practices, this is a case where spending a bit more time in the short term leads to time savings in the long term.
+The more important lesson in the talk was that you have to do what works best for you and your situation. If TDD doesn’t give better results, then either find out how to make it give better results, or stop using it. As we often say in the Agile world, Agile doesn’t mean that you can stop using your brain. While I think TDD is appropriate in most situations, there are cases where it’s not worth the additional up-front cost. If the most important thing for your project is time-to-market, then not testing might be the right decision for you.
+To me, TDD provides a bunch of benefits. First and foremost, TDD is a design discipline. It ensures that I think about how my code will be used before I think about how to implement it. This is very powerful in ensuring that the code is well-written from the perspective of other code using it.
+Tested code provides confidence to be able to make changes without breaking things. If we write tests after the code, we’re less likely to write them. Tests written after the code also tend to test the implementation instead of the desired functionality. What we really want is tests written as a specification. With tests as a specification, we can come back later and understand why code was written. Without tests, or with poor tests, we can’t understand why the code is there; if we want to rewrite it, we don’t have the confidence that we’re not missing something. Writing tests first also ensures that we only write the code that is needed to implement the required functionality.
+I’m not sure why DHH hasn’t “gotten” TDD. I’m not sure if it’s because he’s a better coder than average, or if he just thinks in a different way than most of us. I think it’s partly because he doesn’t understand TDD, which he admitted might be the case. And I think he’s conflating TDD and unit testing.
+DHH is influential in the developer community, especially those newer to Ruby and Rails. People listen to what he has to say. I was happy to see almost every other speaker made fun of DHH’s ideas, and most of the crowd knew better. But there will be a lot of others who will hear DHH, respect his opinions, and not give TDD the try that it deserves. And that’s sad, because it will lead to an overall reduction in code quality in the world.
+Here are some other people’s thoughts on the matter:
++
I created a Ruby gem recently, called includable-activerecord. It’s pretty small, but I thought I might explain why I created it, and discuss its implementation.
+When you use ActiveRecord, you normally include it in your model like this:
+class User < ActiveRecord::Base + # ... +end+
Your User class is inheriting from the ActiveRecord::Base class. This is class-based inheritance, also called “classical” inheritance. (That’s “classical” as in “class”, not as a synonym for “traditional”.) Class-based inheritance represents an “is-a” relationship. So we’re saying that a user is an ActiveRecord base. Another way to say this is that User is a subclass of ActiveRecord::Base.
+
+There are a few problems with this. First, what is a “base”? The name was chosen because it’s a base class. But just like we don’t give factory classes names like UserFactory (at least not in Ruby), we shouldn’t name base classes Base.
I suppose that we’re trying to say that this is an ActiveRecord model. That sounds fine at first glance — this is our model for users. But what if we also want to say that a user is a person? Ruby doesn’t allow inheriting from multiple classes. Now we have to choose whether to inherit from ActiveRecord::Base or Person. Person makes more sense, because it fills the “is-a” rule better. Class inheritance is intended for a hierarchical “is-a” relationship, such as “a user is a person”, or “a circle is a shape”. But since ActiveRecord::Base is a base class, we have to use it as our base class.
We could work around this problem by subclassing Person from ActiveRecord::Base and then subclassing User from Person. That’s fine if Person is also a model that we store in the database. But if that’s not the case, then we have a problem.
Mixins
+Ruby provides another way of implementing inheritance — mixins. We often don’t think of this as an inheritance model, but it really is. When we include a module, that module gets added to the class’s ancestor chain. We can mix in as many modules as we want.
+Mixins indicate more of an “acts like” relationship than an “is-a” relationship. It’s for shared behavior between classes that don’t have a hierarchical relationship. For example, when we mix in the Enumerable module, we’re saying that we want our class to act like other classes that include Enumerable. That sounds more like what we want ActiveRecord to be. We want our user model to behave like other ActiveRecord models, in the way that they can persist to a database.
But ActiveRecord doesn’t support that. Almost all the other Ruby ORMs do; as we’ve shown above, this is for good reasons.
+So I decided to see if I could implement the equivalent of the ActiveRecord::Base class as a module that could be mixed into model classes. I decided to call my mixin module ActiveRecord::Model, because classes that mix it in will behave as ActiveRecord models.
It turns out that ActiveRecord::Base is a pretty complex class. It includes and extends a lot of other modules. Luckily, as of ActiveRecord 4.0, that’s all the code it includes.
The module only defines a single class method, included. This is one of Ruby’s many hook methods. It gets called when the module in question gets included in another module, and receives that other model as its argument. All we need to have this method do is to include everything that ActiveRecord::Base includes, and extend everything that ActiveRecord::Base extends. Ruby provides a method that’s defined on all classes, called included_modules, which we can use to get the list of everything that’s included in ActiveRecord::Base. Unfortunately, there’s no equivalent list of extended_modules. But a quick search on Stack Overflow found an implementation of extended_modules that we could use.
So with a bit of magic (i.e. hooks and meta-programming), we can get the lists of constituent modules from the ActiveRecord::Base class, and include them in our ActiveRecord::Model module.
So with all that, we can now include the includable-activerecord gem and mix it in, with all the advantages that provides:
+class User + include ActiveRecord::Model + # ... +end+
It was exciting to be able to make this work. Since I wrote it as a proof of concept, I haven’t written any tests yet. But it seems to be working just fine. The main thing I really need to look into is making sure that plugins that extend ActiveRecord::Base from their own code will still work. I’m pretty sure this will work out of the box, because the ActiveRecord::Model.included doesn’t run until the model class is loaded, and that happens after those plugins have initialized themselves.
It’s challenging to test Rails custom validators.
+I recently had to write a validator to require that an entered date is before or after a specified date.
+It didn’t seem like writing the validator would be too difficult – I’ve written custom validators before, and date comparisons aren’t all that tricky. But when it came time to write the tests, I ran into several issues. And since I always try to follow TDD / test-first, I was blocked before I even began.
+The biggest issue was the ActiveModel::EachValidator#validates_each API. It’s definitely not a well-designed API. You write your validator as a subclass, overriding validates_each. The method takes a model object, the name of the attribute of the model being tested, and the value of that attribute. You can also get the options passed to the custom validator via the options method. To perform a validation, you have to update the model’s errors hash.
The big flaw in the API is that instead of returning a result, you have to update the model. This needlessly couples the model and the validator. And it violates the Single Responsibility Principle — it has to determine validity of the field, and it has to update the errors hash of the model. This is not conducive to testing. Testing this method requires testing that the side-effect has taken place in the collaborator (model), which means it’s not really a unit test any more.
So to make it easier to unit test the validator, I broke the coupling by breaking it into 2 pieces, one for each responsibility. I moved the responsibility for determining validity to a separate method, which I called errors_for. It returns a hash of the errors found. This simplified the validates_each method to simply take the result of errors_for and update the errors hash of the model:
def validate_each(record, attribute_name, attribute_value) + record.errors[attribute_name].concat(errors_for(attribute_value, options)) +end+
This made it much easier to unit test the errors_for method. This method doesn’t even need to know about the model — only about the value of the attribute we’re trying to validate. We simply pass in the attribute’s value and the options.
So we could write the tests without even pulling in ActiveRecord or any models:
+describe DateValidator do
+ let(:validator) { DateValidator.new(attributes: :attribute_name) }
+ let(:errors) { validator.errors_for(attribute_value, validation_options) }
+
+ describe 'when attribute value is NOT a valid date' do
+ let(:attribute_value) { 'not a valid date' }
+ it { errors.must_include 'is not a valid date' }
+ end
+
+ describe 'when attribute value IS a valid date' do
+ let(:attribute_value) { Date.parse('2013-12-11') }
+ it { errors.must_be :empty? }
+ end
+end
+And the errors_for method looked something like this:
def errors_for(attribute_value, options) + unless attribute_value.is_a?(Date) + return [options.fetch(:message, "is not a valid date")] + end + [] +end+
Integration testing can also be a bit of a challenge. I recommend following the example from this Stack Overflow answer. Basically, create a minimal model object that contains the field and the validation. Then test that the model behaves like you expect with different values and validations.
+The problem is that we used callbacks (actually, a publish/subscribe mechanism) in a situation where they don’t seem to quite fit:
+ def show
+ interactor.on(:display) { |order| render order }
+ interactor.on(:not_found) { |order_id| render status: 404 }
+ interactor.get(params[:id])
+ end
+What we really want is to respond in different ways, depending on the result of the call to interactor.get(). There’s no good reason to define the responses before the call. It makes a lot more sense to define the responses after the call, because they’ll happen after the call. I’d much prefer that the code be written in the order that it will be run.
I discussed this problem with my friend and colleague, Amos King. We came up with a better solution, which puts things back in the right order:
+ def show
+ interactor.get(params[:id]) do |on|
+ on.display { |order| render order }
+ on.not_found { |order_id| render status: 404 }
+ end
+ end
+He even wrote a small library to do this, which he called Riposte. I’m not sure what to call this pattern, but it seems to work pretty well in this situation. I suppose that they’re still technically callbacks, because they’re passed in in the block that’s passed in to the call to interactor.get(). But due to the magic of Ruby blocks, we get to put them in the order they should be.
Riposte also gives you the option of using the response object directly, instead of passing a block:
+ def show
+ on = interactor.get(params[:id])
+ on.display { |order| render order }
+ on.not_found { |order_id| render status: 404 }
+ end
+This shows that it’s just returning an object, with the twist that the response object has methods that take blocks. The nested blocks variant is really the same thing, except that it’s yielding to the response object instead of returning it.
+I’ve decide that is the pattern I’d like to use for interactions and their callers within Ruby hexagonal architecture.
+]]>So inspired by PJ Hagerty’s recent article on alternative Ruby web frameworks, I started thinking about how I’d write a replacement for Rails. I’d definitely keep the basic MVC framework. But I’d also want to implement a more hexagonal architecture.
+I started sketching out what this would look like, but I ended up starting with a Rails controller and finding the simplest way to make it hexagonal. I really don’t like callbacks, because they make tracing program execution difficult. But I didn’t see any other alternative. I found a simple pub/sub Ruby library called Wisper. It literally has only publish, subscribe, and on methods. (You use on to register single callbacks via blocks, and subscribe to register an object with method names corresponding to the callback names.)
The trick was figuring out how to break the controller into 2 pieces. What finally helped me was to find the single responsibilities of the 2 pieces. The Rails controller would remain in charge of managing the web interface, but would delegate to the other piece to handle any application-specific business logic. I decided to re-watch Uncle Bob Martin’s “Architecture The Lost Years” talk, which was the first time I was introduced to the ideas of Hexagonal Architecture. (He doesn’t name the architecture in the talk, but later calls it Clean Architecture.) He does a decent job of explaining how to break these 2 pieces apart. He used the term “interactor” in that talk, so I decided to go with that. He said that Jacobsen calls it a Control Object in Object Oriented Software Engineering, but that’s too close to Rails’s “controller”.
+So here’s an example of what I ended up with:
+class OrderController < ApplicationController
+ def index
+ interactor.on(:display) { |orders| render orders }
+ interactor.list
+ end
+
+ def show
+ interactor.on(:display) { |order| render order }
+ interactor.on(:not_found) { |order_id| render status: 404 }
+ interactor.get(params[:id])
+ end
+
+private
+
+ def interactor
+ @interactor ||= OrderInteractor.new
+ end
+end
+require "wisper" +require "order" + +class OrderInteractor + include Wisper.publisher + + def list + orders = Order.all + publish(:display, orders) + end + + def get(id) + order = Order.find(id) + publish(:display, order) + rescue ActiveRecord::RecordNotFound + publish(:not_found, id) + end +end+
I do have a few problems with this solution though. I’m not a fan of the name “interactor” for the business logic. I thought about calling it OrderOperator, or maybe OrderOperations, because it’s really a collection of operations. Perhaps it would be better to separate each operation into a separate class. Trailblazer does it that way. And for more complicated business logic, I would do that too, using the Method Object pattern. But like a Rails controller, there’s a lot in common among all the operations. I feel like a separate class for each operation for each would create too many coupled classes.
I’m also uncomfortable with the fact that the controller is delegating almost everything to the interactor. I guess this is OK, but it feels like there’s too little left when every line starts with interactor. I suppose extracting things some more would help mitigate this concern I’ll likely write a small gem to perform that extraction. I expect that that will allow a typical controller to be written in only a few lines. And maybe the same for the interactor side.
With the business logic extracted out of the controller, it was really easy for me to write a command-line version of the app. As Uncle Bob says, “the web is not particularly important to your application.”
+I’ve put the code for this example on GitHub: https://github.com/boochtek/hexagonal-rails. I’ll likely experiment with it some more over the next few weeks and months.
+]]>First, I would like to address the good points of the talk. He said that programming is pseudoscience, and that people want to tell us that there’s a secret to being a better programmer. But what it really takes is working hard — reading a lot of code, writing a lot of code, and rewriting a lot of code. He’s right. And I also agree with him that you should forget about patterns for a while when learning to code. Beginners try to throw patterns at a problem instead of letting the patterns emerge where they’re supposed to.
+I don’t completely agree that programming is a pseudoscience. In some ways it is, but I think it’s more of a craft. It’s a craft, because there’s a lot of science involved, but there’s also an art to doing it well. And like any craft, you’re always working to get better. So to respond to DHH’s stance that “software is more like poetry than physics”, I think it falls
+somewhere in between.
With regard to the software engineering practices we use, there really isn’t much science available, mostly because it’s a soft science. That is, it’s really hard to isolate a single variable when comparing code between projects. And nobody has the time or money to write the same code so many times that the differences would be statistically significant.
+So we don’t have much science on TDD. But we do have some. Here’s a collection of several: StudiesOfTestDrivenDevelopment. And here’s one that explicitly looks are the difference between test-first and test-last: Does Test-Driven Development Really Improve Software Design Quality? What do these tell us? They tell us that TDD costs us about 10-30% in short-term productivity; reduces bugs by 30-90%, and decreases code complexity by about 30%. As Code Complete tells us (in section 20.5, with studies to back it up), improving quality reduces development costs. So, like most Agile practices, this is a case where spending a bit more time in the short term leads to time savings in the long term.
+The more important lesson in the talk was that you have to do what works best for you and your situation. If TDD doesn’t give better results, then either find out how to make it give better results, or stop using it. As we often say in the Agile world, Agile doesn’t mean that you can stop using your brain. While I think TDD is appropriate in most situations, there are cases where it’s not worth the additional up-front cost. If the most important thing for your project is time-to-market, then not testing might be the right decision for you.
+To me, TDD provides a bunch of benefits. First and foremost, TDD is a design discipline. It ensures that I think about how my code will be used before I think about how to implement it. This is very powerful in ensuring that the code is well-written from the perspective of other code using it.
+Tested code provides confidence to be able to make changes without breaking things. If we write tests after the code, we’re less likely to write them. Tests written after the code also tend to test the implementation instead of the desired functionality. What we really want is tests written as a specification. With tests as a specification, we can come back later and understand why code was written. Without tests, or with poor tests, we can’t understand why the code is there; if we want to rewrite it, we don’t have the confidence that we’re not missing something. Writing tests first also ensures that we only write the code that is needed to implement the required functionality.
+I’m not sure why DHH hasn’t “gotten” TDD. I’m not sure if it’s because he’s a better coder than average, or if he just thinks in a different way than most of us. I think it’s partly because he doesn’t understand TDD, which he admitted might be the case. And I think he’s conflating TDD and unit testing.
+DHH is influential in the developer community, especially those newer to Ruby and Rails. People listen to what he has to say. I was happy to see almost every other speaker made fun of DHH’s ideas, and most of the crowd knew better. But there will be a lot of others who will hear DHH, respect his opinions, and not give TDD the try that it deserves. And that’s sad, because it will lead to an overall reduction in code quality in the world.
+Here are some other people’s thoughts on the matter:
++]]>
When you use ActiveRecord, you normally include it in your model like this:
+class User < ActiveRecord::Base + # ... +end+
Your User class is inheriting from the ActiveRecord::Base class. This is class-based inheritance, also called “classical” inheritance. (That’s “classical” as in “class”, not as a synonym for “traditional”.) Class-based inheritance represents an “is-a” relationship. So we’re saying that a user is an ActiveRecord base. Another way to say this is that User is a subclass of ActiveRecord::Base.
+
+There are a few problems with this. First, what is a “base”? The name was chosen because it’s a base class. But just like we don’t give factory classes names like UserFactory (at least not in Ruby), we shouldn’t name base classes Base.
I suppose that we’re trying to say that this is an ActiveRecord model. That sounds fine at first glance — this is our model for users. But what if we also want to say that a user is a person? Ruby doesn’t allow inheriting from multiple classes. Now we have to choose whether to inherit from ActiveRecord::Base or Person. Person makes more sense, because it fills the “is-a” rule better. Class inheritance is intended for a hierarchical “is-a” relationship, such as “a user is a person”, or “a circle is a shape”. But since ActiveRecord::Base is a base class, we have to use it as our base class.
We could work around this problem by subclassing Person from ActiveRecord::Base and then subclassing User from Person. That’s fine if Person is also a model that we store in the database. But if that’s not the case, then we have a problem.
Mixins
+Ruby provides another way of implementing inheritance — mixins. We often don’t think of this as an inheritance model, but it really is. When we include a module, that module gets added to the class’s ancestor chain. We can mix in as many modules as we want.
+Mixins indicate more of an “acts like” relationship than an “is-a” relationship. It’s for shared behavior between classes that don’t have a hierarchical relationship. For example, when we mix in the Enumerable module, we’re saying that we want our class to act like other classes that include Enumerable. That sounds more like what we want ActiveRecord to be. We want our user model to behave like other ActiveRecord models, in the way that they can persist to a database.
But ActiveRecord doesn’t support that. Almost all the other Ruby ORMs do; as we’ve shown above, this is for good reasons.
+So I decided to see if I could implement the equivalent of the ActiveRecord::Base class as a module that could be mixed into model classes. I decided to call my mixin module ActiveRecord::Model, because classes that mix it in will behave as ActiveRecord models.
It turns out that ActiveRecord::Base is a pretty complex class. It includes and extends a lot of other modules. Luckily, as of ActiveRecord 4.0, that’s all the code it includes.
The module only defines a single class method, included. This is one of Ruby’s many hook methods. It gets called when the module in question gets included in another module, and receives that other model as its argument. All we need to have this method do is to include everything that ActiveRecord::Base includes, and extend everything that ActiveRecord::Base extends. Ruby provides a method that’s defined on all classes, called included_modules, which we can use to get the list of everything that’s included in ActiveRecord::Base. Unfortunately, there’s no equivalent list of extended_modules. But a quick search on Stack Overflow found an implementation of extended_modules that we could use.
So with a bit of magic (i.e. hooks and meta-programming), we can get the lists of constituent modules from the ActiveRecord::Base class, and include them in our ActiveRecord::Model module.
So with all that, we can now include the includable-activerecord gem and mix it in, with all the advantages that provides:
+class User + include ActiveRecord::Model + # ... +end+
It was exciting to be able to make this work. Since I wrote it as a proof of concept, I haven’t written any tests yet. But it seems to be working just fine. The main thing I really need to look into is making sure that plugins that extend ActiveRecord::Base from their own code will still work. I’m pretty sure this will work out of the box, because the ActiveRecord::Model.included doesn’t run until the model class is loaded, and that happens after those plugins have initialized themselves.
I recently had to write a validator to require that an entered date is before or after a specified date.
+It didn’t seem like writing the validator would be too difficult – I’ve written custom validators before, and date comparisons aren’t all that tricky. But when it came time to write the tests, I ran into several issues. And since I always try to follow TDD / test-first, I was blocked before I even began.
+The biggest issue was the ActiveModel::EachValidator#validates_each API. It’s definitely not a well-designed API. You write your validator as a subclass, overriding validates_each. The method takes a model object, the name of the attribute of the model being tested, and the value of that attribute. You can also get the options passed to the custom validator via the options method. To perform a validation, you have to update the model’s errors hash.
The big flaw in the API is that instead of returning a result, you have to update the model. This needlessly couples the model and the validator. And it violates the Single Responsibility Principle — it has to determine validity of the field, and it has to update the errors hash of the model. This is not conducive to testing. Testing this method requires testing that the side-effect has taken place in the collaborator (model), which means it’s not really a unit test any more.
So to make it easier to unit test the validator, I broke the coupling by breaking it into 2 pieces, one for each responsibility. I moved the responsibility for determining validity to a separate method, which I called errors_for. It returns a hash of the errors found. This simplified the validates_each method to simply take the result of errors_for and update the errors hash of the model:
def validate_each(record, attribute_name, attribute_value) + record.errors[attribute_name].concat(errors_for(attribute_value, options)) +end+
This made it much easier to unit test the errors_for method. This method doesn’t even need to know about the model — only about the value of the attribute we’re trying to validate. We simply pass in the attribute’s value and the options.
So we could write the tests without even pulling in ActiveRecord or any models:
+describe DateValidator do
+ let(:validator) { DateValidator.new(attributes: :attribute_name) }
+ let(:errors) { validator.errors_for(attribute_value, validation_options) }
+
+ describe 'when attribute value is NOT a valid date' do
+ let(:attribute_value) { 'not a valid date' }
+ it { errors.must_include 'is not a valid date' }
+ end
+
+ describe 'when attribute value IS a valid date' do
+ let(:attribute_value) { Date.parse('2013-12-11') }
+ it { errors.must_be :empty? }
+ end
+end
+And the errors_for method looked something like this:
def errors_for(attribute_value, options) + unless attribute_value.is_a?(Date) + return [options.fetch(:message, "is not a valid date")] + end + [] +end+
Integration testing can also be a bit of a challenge. I recommend following the example from this Stack Overflow answer. Basically, create a minimal model object that contains the field and the validation. Then test that the model behaves like you expect with different values and validations.
+]]>I was wondering if you had made any progress with it? It seems like a language I would enjoy working with.
+Best of luck.
+]]>Really?
+]]>Here is why –
+http://dennis-nerush.blogspot.co.il/2015/11/applying-tdd-in-your-company-is-more.html
It’s taken me years to realize that being right isn’t terribly important. Especially when there’s more than one right answer — which there usually is. It’s more important to work as a team. It’s more important to be respected and to have respect for others.
+A few weeks after that interview, I was pair programming with the person who had asked me the question. We’re both senior developers, so we both have a lot of experience and opinions based on that experience. We were writing a shell script, and we both had an idea in mind about how to write the code. I let him proceed with his idea. It was a pretty good idea; probably better than mine. But we paired very effectively. I’d let him finish some code, and I’d find a way to make it better. Then he’d find a way to make my code better. What we ended up with was so much better than my original idea, and his original idea as well. I commented on this, and he agreed. We left that pairing session feeling the high of having accomplished something rare — two very experience programmers coming up with better code than we could have imagined going in.
+I like to think of writing code as a path towards a destination. The destination is good code that does what it’s supposed to, is readable (intention revealing), is concise, and is well-factored so as to be easy to change in the future. But there are many paths to that destination. Especially when pair programming, the code gets refined as ideas are shared, getting you closer and closer to that destination. Sometimes the different paths end up with the same code; sometimes they end up with different code. But if the code does its job well (according to those criteria), it doesn’t really matter what code you ended up with.
+Thinking back to the original question, I think the answer is a little more nuanced. (I’m pretty sure I followed up with an explanation, but I don’t recall the details.) It truly doesn’t matter in a lot of cases. If there are different paths that lead to the same destination, and they’re all roughly equal, then my rule works. It can also work even if the first path you try (a “wrong” path) doesn’t work out, as long as it’s easy enough to try a different path. I find that the majority of day-to-day coding fits these conditions.
+But there are some places where it’s costly to get things wrong the first time. In these cases, it’s worth spending some time thinking about and discussing the alternatives before getting started. Software architecture is the big one that comes to mind. In general, weighing the pros and cons of each option and applying previous experience works best.
+So next time you think about trying to convince someone you’re right, fight the urge. Instead, let them show you what they’re thinking. They just might surprise you. And more importantly, you might surprise yourself.
+]]>We’d brought in Diana Larsen to facilitate the Open Space. Diana is a stalwart of the Agile community, focusing on how people and teams interact. She literally (co-)wrote the book on Agile retrospectives. Diana was also kind enough to be our guest at an Agile LINC meetup later in the evening.
+The morning started off with all the participants sitting in chairs arranged in a circle. Diana rang a chime, a nice soothing tone that literally set the tone for the day. (Most people didn’t seem to like it, but I thought it had its purpose.) It also acted as a call to gather in the meeting space. She then walked around the inside of the circle as she explained what was going to happen.
+The idea behind Open Spaces came with the realization that at a conference, the “hallway track” (ad hoc discussions in the hallways) was often more valuable than the scheduled talks. So they figured out a way to capture that experience. There are only a few rules:
+Once Diana set the scene and explained the rules, people came up and presented ideas for topics. If you proposed a topic, you chose a time and location on the topic board. At that time, you’d facilitate a discussion on that topic. The format was really conducive to discussions. There was no preparation, so discussions were from the heart — lots of people felt that they could contribute.
+Being new to the company (only 2 months), I got a lot out of the workshop, beyond the content itself. I got to get to know several more people. I’d even say I made a few friends. Having open discussions, we found that many of the teams were having the same issues. This made it easy for me to talk to other people.
+All-in-all, I found the Open Space to be extremely conducive to discussions aimed at identifying issues, brainstorming solutions, and planning action items. I felt like we made great strides in addressing some of the biggest problems our organization is currently facing.
+]]>I want to increase the Open Source code I write this year. That’s basically everything I write that’s not directly related to work.
+I took over maintenance of Virtus late last year, but haven’t done a good job at finding the time for that. That’s probably more responding to issues on GitHub and merging pull requests. But eventually, I’ll likely add some features and do some refactoring.
+My goal is to work on 6 apps and libraries this year. That’s a pretty aggressive goal, but I want to focus on both learning new things and building some simple but useful things. Think MVP — focus on getting a lot of bang for not too much effort.
+I want to work on a new Rails app, to familiarize myself with Rails 5. I want to get some experience with some more modern gems. I also want to see if I can use some new techniques with a Rails app, especially things that might help us get closer to a hexagonal architecture. I’m also hoping to work with some different web frameworks — maybe Lotus, Rodakase, Trailblazer, or Phoenix. Or maybe one of the Crystal web frameworks.
+I also want to work on a couple Elm apps. I started the STL Elm group as an excuse to learn the language. I’d like to work on a Twitter client, that might eventually turn into a more general reading app. Beyond Twitter, it would keep track of things I want to read. The other Elm app I’d like to write is a game, based on the old Space Taxi game I loved to play on the Commodore 64.
+I wrote a micro-ORM last year called Ruby Preserves. I’ve started converting that from working with raw SQL to sitting atop the awesome Sequel gem. The simplicity is still there so far, and basing it on Sequel has so far gone easier than I expected. But I haven’t figured out how to do relationships (JOINs) yet; that will be the real test.
+I’m pretty happy with my 2015 conference experience. I want to keep my conference level about the same. I don’t really want to commit to more talks than I gave last year. Conference presentations take a lot of time and energy to write and practice.
+I’m planning to go to RailsConf, RubyConf, and Strange Loop. I’m hoping to give a talk at each of those, if I can. But I’ll probably attend all of them even if I’m not speaking. I’m also submitting a talk to Agile 2016. I’m unlikely to go to any other conferences, and even more unlikely to give more than 4 conference talks.
+I really want to finish my Effective Agile book this year. I’m going to try to pull Amos in to pair with me on it occasionally, to move it forward. If I’m able to get it done, I’d also like to maybe write a book on Elm.
+I actually want to do less blogging this year. Well, sort of. I want to put coding and book writing ahead of blogging. If that means less blogging, I’m okay with that. So my goal for blogging is more like every other week. And when I do write a blog article, I’d rather it be related to some code I’m working on, something that I could use in my book, or some more in-depth thoughts about programming language design.
+The contract I recently started at CenturyLink Cloud is open-ended, so I’ll likely be there for the entire year. I’m enjoying it so far; it’s a challenge, but I think I can make a significant impact. However, I’m really interested in moving to San Francisco in 2017. So I’m going to work on preparing for that in several ways.
+I’m going to resurrect my LinkedIn account. I’ve neglected it for a few years now. I’ll make sure everything is up to date, and make some connections I’ve been putting off. I also want to reclaim my Stack Exchange and Hacker News accounts.
+I’m going to pay a an expert to help me revamp my résumé. I think it’s pretty decent, but it could use some freshening up. I want it to stand out. I want to do a better job of explaining what I really do — which is to join a team to help them improve their processes and their technical skills.
+I’ll also need to clean up all my web sites, so they look nice when people come to take a look at them. This includes my personal site, consulting business site, wiki, and blogs. I should also upgrade my server to the latest version of Debian, and use Ansible and some other tools to provision it using the principles of Infrastructure as Code.
+]]>I started out with a pretty simple question: “What do you value (in regards to what we’re building); what are you willing to fight for?” I asked them each to write down several values and then put them on the board before looking at everyone else’s answers. I also asked each person to rank their values in order of importance.
+It turned out that my question was a little vague. Some people thought about the question in terms of the end result, and some in terms of the process of creating the software. In some ways that was a bit of a problem, because the different interpretations led people in different directions. But in other ways, not pushing them in any particular direction got more varied answers, exposing how they think about the project and the product.
+My list (in order) was Effectiveness (doing the right thing), Quality (doing things right the first time), Happiness, Purpose, and Teamwork. In retrospect, I should have put Happiness first. If I’m not happy at work, I don’t really want to be there, and need to move on. (Sometimes I can trade some happiness at work for more happiness at home, but I’m definitely a person that needs to be happy at work.) The other values serve to improve my happiness, but the happiness is more important.
+My own issue ranking my values turned out to be a problem with the ranking in general. Should they be ranked in importance of the necessity of the value as an outcome, or in importance of the necessity to focus on the value? I think the former is what I was looking for, but even I wasn’t clear on that when I began the exercise.
+After everyone put their values up on the board, we read them off. Then I asked the team to choose several values that we share as a team. We pulled them off the individual members’ lists, and put them in the team list. Then I asked each person to come up and rank those values, then explain why they had ordered them that way, especially when they ordered them significantly different than the last person. I was hoping to come to some convergence of the rank over time, so we could document our values in rank order. That didn’t happen. But the discussion was illuminating to me and to everyone on the team.
+I think the most interesting part about the lack of convergence was the difference between the developers and the product guys. The product guys definitely viewed the values more in terms of outcomes than the process. That makes sense — they’re not as intimately involved in the process of building the product.
+We were able to converge on the top priority though: Will the user buy the product? This was a combination of a couple different values that we merged together. This included the end user experience as well as making sure the team would continue to have a reason for existing. The rest of the values we left unordered: Teamwork (cohesiveness), Data driven decisions, Team ownership, Simplicity, Effectiveness, Maintainability / Supportability, Quality, Automation, and Performance. I think that’s a pretty decent list.
+As a couple teammates pointed out, those values are probably in part a reflection of this current point in time. If I asked the same question some other time, under different conditions and team dynamics, the answers would probably change a bit. And we’d probably come up with other answers if asked again, just due to randomness of the way we think about these things.
+But I don’t think I’d do this activity a second time with the team. It was really about understanding our motivations — both our own, and those of our teammates. I found it effective in that way, and also in helping the team to think about our culture and how we can work to shape it to help us all push in the same direction.
+There are a few caveats. When I asked for feedback on the exercise, one teammate pointed out that it wouldn’t work if people weren’t honest about their values, and they answered with what they thought management or their teammates wanted to hear. I don’t think that was an issue with this group, but it’s something to keep in mind.
+The other major thing I’d do is to make it clear up front that I’m not looking for any action items from this activity; it’s more about understanding each other and ourselves. And next time, I’ll work to clarify how to rank the values.
+I would recommend this activity for a new team, or when the makeup of the team is changing in some significant way. I wish there was a way to help a team converge on the ranking of their values, but I suppose I should be happy that agreeing on the set of important values went pretty quickly. And the diversity of ideas and opinions is probably a blessing that I should be embracing — the more ideas we have, the wider the variety of solutions we can imagine.
+]]>I got pretty lucky on this one. My main contract with Mercy got extended several times. Amos and I must have been doing a good job of keeping the customer happy. We even made it through a couple rounds of layoffs. I’m wrapping up the gig at Mercy now. I’m working one day a week there, as the project winds down.
+I also started a new gig this month at CenturyLink. I’m working on a cloud development team. Our current project involves selling WordPress as a service. The manager had been courting me for most of the year. I’m excited about my new role; I’ll be writing about it in a blog post soon.
+I set a goal in 2014 to give my first conference talk. I accomplished that, giving an ambitious talk at RubyConf. I enjoyed having done that, and vowed to do more conference speaking.
+I gave 3 conference talks in 2015. I gave a workshop on HTTP at RailsConf. I talked about immutable infrastructure at Madison+ Ruby. At RubyConf, I gave a talk on a micro-ORM I wrote. I also gave a lightning talk about Agile estimation (#noestimates).
+I was an alternate speaker at Windy City Rails, but did not give my talk on Alternatives to ActiveRecord. I also went to Strange Loop, mainly to see several friends and acquaintances speak.
+I wrote 24 blog articles this year. That’s about one every other week. What really kept me going was participating in a writing pact. When the pact was going, I had a 75% blogging rate. That’s pretty good.
+I’m not so sure about the quality of my blog writing though. I know that practicing writing is supposed to make you better. I know I wrote some really good articles over the past year, but I think I also wrote some articles that weren’t very good. I think sometimes the deadline has caused more harm than good. I’m not really sure what to do about that; perhaps just pushing on is the right answer.
+I’ve taken a lot of notes on the design of my programming language. Any time I learn something interesting about another language, or come up with another idea, I write it down.
+But I haven’t worked on the implementation. (I last worked on the implementation in 2014.) I should be experimenting with some ideas, implementing them to see how they work out. I’ve even kicked around the idea of starting with a Forth variant, just to get something working quickly.
+I haven’t written any articles on my ideas this year either. My notes are pretty extensive, and it would be good to write some articles to help get my thoughts straight.
+I’ve got some things to say about Agile, and want to write a book to express those ideas. I’ve made a start — I’ve got the chapters outlines, and have started on a few chapters. But I haven’t made as much progress as I’d like to. I shared what I’ve got with Amos, and he showed some interest in pairing with me on the writing. Hopefully we’ll work on it together in 2016 and publish it.
+There were a few other accomplishments that weren’t explicitly on my list, but I’d like to call attention to.
+I’ve continued participating on the This Agile Life podcast. I was in 12 of the 33 episodes that were recorded in 2015. I hope to participate in more in 2016. We’re considering scheduling a standard recording night each week, which might help us record more regularly.
+I recently took over as maintainer of Virtus, a library to declare attributes for Ruby model classes. I haven’t done a lot yet, since I’ve been busy with travel, vacation, and holidays. But I hope to catch up with all the pending pull requests and issues in the next month or so.
+The accomplishment I’m most proud of is mentoring for the Roy Clay Sr. Tech Impact program. This is a program begun as a result of the Ferguson protest movement. We’re helping teach kids (from 14 to 25) web design and development. My personal goal was to give these kids an opportunity that they would not have otherwise had. But it turned out that some of them have actually started a business building web sites for small companies. I’m so proud of the progress they’ve made in such a short time; it’s a challenging program.
+I’m pretty happy with my accomplishments this year. I made at least some progress on each of the goals I set. I’ve been thinking about my goals for next year; I’ll write that as a separate blog article next week.
+]]>I have a moderate case of arachnophobia. I don’t run away when I see a spider, but it creeps my out when one is crawling on me. When I was in college, I decided to buy a tarantula to attempt to get over my irrational fear of spiders. I thought I’d be able to get more comfortable with the tarantula over time, eventually to the point of letting it crawl on my arm. It didn’t work. Although I did find that my fear of tarantulas is rational — I got a terrible case of hives just from touching the urticating hairs that fell off into its water sponge.
+Last week, I was on vacation in Mexico. One of the excursions we took involved jumping in the water a lot. I’m not a strong swimmer — mostly because I have a hard time closing my nose; I hold my nose when I jump in. We zip-lined into the water a lot. At one point, there was a cliff to dive into the water from. It was about 15 feet above the water. It didn’t look so far down before jumping. But it felt like a really long way down the first time I jumped from it. It was pretty scary for me. So I did it a second time. There wasn’t any peer pressure to jump a second time. I literally jumped a second time specifically because I was scared.
+Fear is a weird thing. Fear is there to protect us. But it’s there to protect us from the dangers of the African savannah. Most of the things our fears protect us from don’t exist in our everyday modern lives. So maybe we should work to gain a better understanding of how our fears work, to figure out when to pay attention to them and when to ignore them.
+Fortunately, our brain has a good mechanism to help us do this. Our brains basically have 2 main processing systems. The first one is for quick reactions. This one involves things that are nearly reflexes. Fear is in this system. The second system is our analytical reasoning system. This system takes longer to process, but is able to take on more information.
+Whenever the situation allows us time for both systems to work, we need to listen to them both. We need to listen to our fears, because they’re there for a reason. But that reason might not pertain to our situation. So we need to realize that, and let the slow analytical system determine if we should ignore our fears.
+If we don’t allow both systems to work, we’re not taking full advantage of our brains; we’re not taking full advantage of the situations that life is presenting to us.
+]]>Our tour guide was a lot of fun. He made jokes, told us about the cenotes, and led us in the activities. But he also encouraged us. When someone was scared to do something, he was supportive. He told us that it was okay, and we could do it. But we also felt like it was OK to fail, if we really couldn’t. It really felt like his encouragement was literally creating courage.
+What was really neat was that despite the language barrier, everyone else was also supportive and encouraging. Everyone cheered with encouragement before someone would attempt something difficult. And we’d cheer especially loud once someone accomplished something that was difficult for their abilities.
+It was an awesome feeling to feel so supported. It made me feel like I was in a safe place, where I could try new things that were a little past my comfort zone. I was able to do the zip-line upside-down. I jumped off a 15-foot cliff into the water. I even jumped off the cliff a second time, even though I was a little scared.
+Back at the resort, we played some volleyball in the pool. It was a similar situation, with players of varying ages and abilities. Again, we tried to help the weaker players feel comfortable so they could improve without feeling judged or self-conscious. It helped everyone have a good time. It made everything more fun to be in such a supportive environment, whether I was in a position as one of the more skilled (volleyball), or one of the less skilled (jumping or zip-lining into the water). We were all able to accomplish more, with less effort.
+These experiences provide a good lesson that can be applied in a lot of places. Such a supportive environment would help any relationship, and any team. I’ve been on a couple really good software development teams, but I don’t think any of them have been as supportive as these two groups of strangers.
+I’ve decided that this should be one of my goals as a team leader. I want to create an encouraging environment for the whole team. I want to make sure that everyone is comfortable enough that they feel like they can try things that are difficult, even if they might fail (as long as nobody gets hurt).
+If a group of strangers can do this, so can your team. So can you and your significant others. We need to work every day to make sure that we’re supporting each other. It’s the best way to get everyone to achieve more.
+]]>Back then, Sears and other retail stores had Commodore 64 computers out on display. Whenever I went to the store, I’d write a short BASIC program and leave it running on the display computers:
+10 PRINT "CRAIG IS GREAT!" +20 GOTO 10+
Hey, I was a 13-year-old kid. Later, I got a little more sophisticated. I’d change the background color instead. I still remember the POKE address:
+10 FOR I=0 TO 255 +20 POKE 53281, I +30 NEXT I +40 GOTO 10 +RUN+
This was fast enough to change the background color every few scan lines, creating a flashing scrolling effect.
+Later, I learned 6502 assembly language. I translated the BASIC program into assembler, and memorized the bytes to type in at the store. In assembly language, the background color would change several times per scan line. The effect was kind of psychedelic.
+All that happened in the mid-1980s.
+Fast-forward to about 2000 or so. I was telling the above story after a St. Louis LUG meeting. I explained how I had memorized the 10 or 12 bytes of machine code, and would leave the program running with its psychedelic effect.
+After thinking about it for a bit, I thought that 10 or 12 bytes seemed too much. It actually bothered me — I couldn’t fall asleep when I got home. I got up and found my old 6502 manuals. I figured out how to write the code in 7 bytes. I installed the Vice C64 emulator on my Linux desktop, and tested my code. It worked as expected. (The emulator was already clock-cycle perfect by then.) Here’s the assembly code:
+INX ; $E8 ; 232 +STX $D021 ; $8E $21 $D0 ; 142 33 208 ; $D021 = 53281 +JMP $C000 ; $4C $00 $C0 ; 76 0 192 ; $C000 = 49152+
Here’s the BASIC program to store that program in memory and run it:
+10 FOR N=49152 TO 49152+6: READ Q : POKE N, Q : NEXT +20 DATA 232, 142, 33, 208, 76, 0, 192 +30 SYS 49152 +RUN+
The moral of the story is that you can optimize even a 10-byte program, 15 years after the last time it was used. So don’t tell me that your program can’t be improved, no matter how small it is.
+PS. I rewrote the code above while writing this article in 2015, about 15 years after the last time I rewrote it. And I again downloaded Vice to test it, this time on Mac OS X.
+]]>I think this is a key differentiator for me as a consultant. Most consultants (and Agile coaches) come in and tell people what to do. I don’t like to just tell people what to do. I’d much prefer to work side-by-side with them, getting a better understanding of what their challenges are. Once I have a better understanding of the challenges, I’m able to better brainstorm some ideas to try. Then we can experiment to see what will work and what won’t.
+Instead of telling people what to do, I show them how. Most people learn better from seeing than from hearing. They also learn better if you explain how and why, not just what. So showing them how to do something is more effective than telling them. By showing and doing, you can also set a good example. This is especially important when collaboration is a large part of what needs to be improved.
+I’ve found that this style of consulting is more highly respected by everyone. I build trust with developers by working closely with them. Managers like to keep me around once they see how effective these methods can be, so the gigs I take on tend to last relatively long.
+The biggest problem I have is explaining how this works. I don’t really know what to put on my résumé. Sometimes I call myself an Agile practitioner, and sometimes an Agile player/coach. But those aren’t terribly satisfying descriptions. I’m considering actually putting “I help teams improve the way they work — both their processes and their technical skills” on the résumé. But that seems awkward, and misses the show versus tell part. I’d be open to any suggestions.
++]]>
I started with two questions that I’ve used with teams before, to some success (although not so successful for one particular team). The first question I asked was “How happy are you at work?” I had them put a rating from 0 to 10, with 0 meaning they should have quit last week, and 10 meaning they couldn’t imaging being happier at work.
+The answers were mostly 7s and 8s, with a 5 and a 9. The average came to 7.5, which is pretty good. The 5 concerns me a bit, especially that it’s 2 points lower than anyone else’s answer.
+The next question I asked was “How effective do you think the teams is?”. Again, from 0 to 10, with 0 meaning they can’t accomplish anything, and 10 meaning you couldn’t imagine a more effective team.
+When I ask both of these questions, the scores are always highly correlated. If your team isn’t doing good work, it’ll make you unhappy. And if you are unhappy, you’re less likely to do your best work. This team was no different; the 5 and 9 became a 6 and a 10, and most of the 7s became 8s, for an average of just under 8.
+The next question I asked was “What makes you happy at work?”. The answers were mostly about the teamwork and teammates. This went quicker than I expected. At this point, I was worried the retro would only last a little more than 30 minutes.
+The final question I asked was “What would make you happier at work?”. This was the real pay-off. We spent about half an hour just talking about the things that would make us happier, and what we could do to improve our happiness. We came up with 10 potential action items. I usually limit teams to trying 3 or 4 action items, but most of the items are quite small, so we’re going to try 6 of them. One is just observing another team’s standup meetings, to see how they’re using their time effectively.
+Everyone went away feeling that this was a really good retro. It felt good to focus on happiness. Happiness is something I’ve been talking a lot about on the This Agile Life podcast, and it felt good to take some action on it. I’ve done “positive-only” retros before, but this one felt even better than that, by specifically targeting happiness and how we can achieve it.
+]]>Web Development, Ruby on Rails, Open Source
+Not too long ago, I was asked during a job interview “how do you convince your teammates that you’re right?” I answered with probably the most surprising answer: “I don’t.”
+It’s taken me years to realize that being right isn’t terribly important. Especially when there’s more than one right answer — which there usually is. It’s more important to work as a team. It’s more important to be respected and to have respect for others.
+A few weeks after that interview, I was pair programming with the person who had asked me the question. We’re both senior developers, so we both have a lot of experience and opinions based on that experience. We were writing a shell script, and we both had an idea in mind about how to write the code. I let him proceed with his idea. It was a pretty good idea; probably better than mine. But we paired very effectively. I’d let him finish some code, and I’d find a way to make it better. Then he’d find a way to make my code better. What we ended up with was so much better than my original idea, and his original idea as well. I commented on this, and he agreed. We left that pairing session feeling the high of having accomplished something rare — two very experience programmers coming up with better code than we could have imagined going in.
+I like to think of writing code as a path towards a destination. The destination is good code that does what it’s supposed to, is readable (intention revealing), is concise, and is well-factored so as to be easy to change in the future. But there are many paths to that destination. Especially when pair programming, the code gets refined as ideas are shared, getting you closer and closer to that destination. Sometimes the different paths end up with the same code; sometimes they end up with different code. But if the code does its job well (according to those criteria), it doesn’t really matter what code you ended up with.
+Thinking back to the original question, I think the answer is a little more nuanced. (I’m pretty sure I followed up with an explanation, but I don’t recall the details.) It truly doesn’t matter in a lot of cases. If there are different paths that lead to the same destination, and they’re all roughly equal, then my rule works. It can also work even if the first path you try (a “wrong” path) doesn’t work out, as long as it’s easy enough to try a different path. I find that the majority of day-to-day coding fits these conditions.
+But there are some places where it’s costly to get things wrong the first time. In these cases, it’s worth spending some time thinking about and discussing the alternatives before getting started. Software architecture is the big one that comes to mind. In general, weighing the pros and cons of each option and applying previous experience works best.
+So next time you think about trying to convince someone you’re right, fight the urge. Instead, let them show you what they’re thinking. They just might surprise you. And more importantly, you might surprise yourself.
+I recently attended an Open Space hosted at work. I’d never been to an Open Space, and didn’t know what to expect. We’d been told that this was a workshop to help Engineering Managers (my role), Product Owners, and Product Analysts find better ways of working together. But due to the way an Open Space works, it evolved into something completely different — and better.
+We’d brought in Diana Larsen to facilitate the Open Space. Diana is a stalwart of the Agile community, focusing on how people and teams interact. She literally (co-)wrote the book on Agile retrospectives. Diana was also kind enough to be our guest at an Agile LINC meetup later in the evening.
+The morning started off with all the participants sitting in chairs arranged in a circle. Diana rang a chime, a nice soothing tone that literally set the tone for the day. (Most people didn’t seem to like it, but I thought it had its purpose.) It also acted as a call to gather in the meeting space. She then walked around the inside of the circle as she explained what was going to happen.
+The idea behind Open Spaces came with the realization that at a conference, the “hallway track” (ad hoc discussions in the hallways) was often more valuable than the scheduled talks. So they figured out a way to capture that experience. There are only a few rules:
+Once Diana set the scene and explained the rules, people came up and presented ideas for topics. If you proposed a topic, you chose a time and location on the topic board. At that time, you’d facilitate a discussion on that topic. The format was really conducive to discussions. There was no preparation, so discussions were from the heart — lots of people felt that they could contribute.
+Being new to the company (only 2 months), I got a lot out of the workshop, beyond the content itself. I got to get to know several more people. I’d even say I made a few friends. Having open discussions, we found that many of the teams were having the same issues. This made it easy for me to talk to other people.
+All-in-all, I found the Open Space to be extremely conducive to discussions aimed at identifying issues, brainstorming solutions, and planning action items. I felt like we made great strides in addressing some of the biggest problems our organization is currently facing.
+I’ve written up a list of career-related resolutions the past few years. I’ve been pretty successful meeting those goals, so I’m going to continue the tradition.
+I want to increase the Open Source code I write this year. That’s basically everything I write that’s not directly related to work.
+I took over maintenance of Virtus late last year, but haven’t done a good job at finding the time for that. That’s probably more responding to issues on GitHub and merging pull requests. But eventually, I’ll likely add some features and do some refactoring.
+My goal is to work on 6 apps and libraries this year. That’s a pretty aggressive goal, but I want to focus on both learning new things and building some simple but useful things. Think MVP — focus on getting a lot of bang for not too much effort.
+I want to work on a new Rails app, to familiarize myself with Rails 5. I want to get some experience with some more modern gems. I also want to see if I can use some new techniques with a Rails app, especially things that might help us get closer to a hexagonal architecture. I’m also hoping to work with some different web frameworks — maybe Lotus, Rodakase, Trailblazer, or Phoenix. Or maybe one of the Crystal web frameworks.
+I also want to work on a couple Elm apps. I started the STL Elm group as an excuse to learn the language. I’d like to work on a Twitter client, that might eventually turn into a more general reading app. Beyond Twitter, it would keep track of things I want to read. The other Elm app I’d like to write is a game, based on the old Space Taxi game I loved to play on the Commodore 64.
+I wrote a micro-ORM last year called Ruby Preserves. I’ve started converting that from working with raw SQL to sitting atop the awesome Sequel gem. The simplicity is still there so far, and basing it on Sequel has so far gone easier than I expected. But I haven’t figured out how to do relationships (JOINs) yet; that will be the real test.
+I’m pretty happy with my 2015 conference experience. I want to keep my conference level about the same. I don’t really want to commit to more talks than I gave last year. Conference presentations take a lot of time and energy to write and practice.
+I’m planning to go to RailsConf, RubyConf, and Strange Loop. I’m hoping to give a talk at each of those, if I can. But I’ll probably attend all of them even if I’m not speaking. I’m also submitting a talk to Agile 2016. I’m unlikely to go to any other conferences, and even more unlikely to give more than 4 conference talks.
+I really want to finish my Effective Agile book this year. I’m going to try to pull Amos in to pair with me on it occasionally, to move it forward. If I’m able to get it done, I’d also like to maybe write a book on Elm.
+I actually want to do less blogging this year. Well, sort of. I want to put coding and book writing ahead of blogging. If that means less blogging, I’m okay with that. So my goal for blogging is more like every other week. And when I do write a blog article, I’d rather it be related to some code I’m working on, something that I could use in my book, or some more in-depth thoughts about programming language design.
+The contract I recently started at CenturyLink Cloud is open-ended, so I’ll likely be there for the entire year. I’m enjoying it so far; it’s a challenge, but I think I can make a significant impact. However, I’m really interested in moving to San Francisco in 2017. So I’m going to work on preparing for that in several ways.
+I’m going to resurrect my LinkedIn account. I’ve neglected it for a few years now. I’ll make sure everything is up to date, and make some connections I’ve been putting off. I also want to reclaim my Stack Exchange and Hacker News accounts.
+I’m going to pay a an expert to help me revamp my résumé. I think it’s pretty decent, but it could use some freshening up. I want it to stand out. I want to do a better job of explaining what I really do — which is to join a team to help them improve their processes and their technical skills.
+I’ll also need to clean up all my web sites, so they look nice when people come to take a look at them. This includes my personal site, consulting business site, wiki, and blogs. I should also upgrade my server to the latest version of Debian, and use Ansible and some other tools to provision it using the principles of Infrastructure as Code.
+I held a retrospective with my new team last week. The team includes 2 senior developers, 2 junior developers, a product owner, and a product analyst. I’ve joined the team as an engineering manager, which I think of more as a team lead with an elevated title. Being new to this group, I wanted a way to understand their values. What motivates them? What common values do we share that we can leverage to move forward in the same direction?
+I started out with a pretty simple question: “What do you value (in regards to what we’re building); what are you willing to fight for?” I asked them each to write down several values and then put them on the board before looking at everyone else’s answers. I also asked each person to rank their values in order of importance.
+It turned out that my question was a little vague. Some people thought about the question in terms of the end result, and some in terms of the process of creating the software. In some ways that was a bit of a problem, because the different interpretations led people in different directions. But in other ways, not pushing them in any particular direction got more varied answers, exposing how they think about the project and the product.
+My list (in order) was Effectiveness (doing the right thing), Quality (doing things right the first time), Happiness, Purpose, and Teamwork. In retrospect, I should have put Happiness first. If I’m not happy at work, I don’t really want to be there, and need to move on. (Sometimes I can trade some happiness at work for more happiness at home, but I’m definitely a person that needs to be happy at work.) The other values serve to improve my happiness, but the happiness is more important.
+My own issue ranking my values turned out to be a problem with the ranking in general. Should they be ranked in importance of the necessity of the value as an outcome, or in importance of the necessity to focus on the value? I think the former is what I was looking for, but even I wasn’t clear on that when I began the exercise.
+After everyone put their values up on the board, we read them off. Then I asked the team to choose several values that we share as a team. We pulled them off the individual members’ lists, and put them in the team list. Then I asked each person to come up and rank those values, then explain why they had ordered them that way, especially when they ordered them significantly different than the last person. I was hoping to come to some convergence of the rank over time, so we could document our values in rank order. That didn’t happen. But the discussion was illuminating to me and to everyone on the team.
+I think the most interesting part about the lack of convergence was the difference between the developers and the product guys. The product guys definitely viewed the values more in terms of outcomes than the process. That makes sense — they’re not as intimately involved in the process of building the product.
+We were able to converge on the top priority though: Will the user buy the product? This was a combination of a couple different values that we merged together. This included the end user experience as well as making sure the team would continue to have a reason for existing. The rest of the values we left unordered: Teamwork (cohesiveness), Data driven decisions, Team ownership, Simplicity, Effectiveness, Maintainability / Supportability, Quality, Automation, and Performance. I think that’s a pretty decent list.
+As a couple teammates pointed out, those values are probably in part a reflection of this current point in time. If I asked the same question some other time, under different conditions and team dynamics, the answers would probably change a bit. And we’d probably come up with other answers if asked again, just due to randomness of the way we think about these things.
+But I don’t think I’d do this activity a second time with the team. It was really about understanding our motivations — both our own, and those of our teammates. I found it effective in that way, and also in helping the team to think about our culture and how we can work to shape it to help us all push in the same direction.
+There are a few caveats. When I asked for feedback on the exercise, one teammate pointed out that it wouldn’t work if people weren’t honest about their values, and they answered with what they thought management or their teammates wanted to hear. I don’t think that was an issue with this group, but it’s something to keep in mind.
+The other major thing I’d do is to make it clear up front that I’m not looking for any action items from this activity; it’s more about understanding each other and ourselves. And next time, I’ll work to clarify how to rank the values.
+I would recommend this activity for a new team, or when the makeup of the team is changing in some significant way. I wish there was a way to help a team converge on the ranking of their values, but I suppose I should be happy that agreeing on the set of important values went pretty quickly. And the diversity of ideas and opinions is probably a blessing that I should be embracing — the more ideas we have, the wider the variety of solutions we can imagine.
+It’s that time of year again — time for a retrospective on how I did on my goals for the year. I had 5 main goals for 2015:
+I got pretty lucky on this one. My main contract with Mercy got extended several times. Amos and I must have been doing a good job of keeping the customer happy. We even made it through a couple rounds of layoffs. I’m wrapping up the gig at Mercy now. I’m working one day a week there, as the project winds down.
+I also started a new gig this month at CenturyLink. I’m working on a cloud development team. Our current project involves selling WordPress as a service. The manager had been courting me for most of the year. I’m excited about my new role; I’ll be writing about it in a blog post soon.
+I set a goal in 2014 to give my first conference talk. I accomplished that, giving an ambitious talk at RubyConf. I enjoyed having done that, and vowed to do more conference speaking.
+I gave 3 conference talks in 2015. I gave a workshop on HTTP at RailsConf. I talked about immutable infrastructure at Madison+ Ruby. At RubyConf, I gave a talk on a micro-ORM I wrote. I also gave a lightning talk about Agile estimation (#noestimates).
+I was an alternate speaker at Windy City Rails, but did not give my talk on Alternatives to ActiveRecord. I also went to Strange Loop, mainly to see several friends and acquaintances speak.
+I wrote 24 blog articles this year. That’s about one every other week. What really kept me going was participating in a writing pact. When the pact was going, I had a 75% blogging rate. That’s pretty good.
+I’m not so sure about the quality of my blog writing though. I know that practicing writing is supposed to make you better. I know I wrote some really good articles over the past year, but I think I also wrote some articles that weren’t very good. I think sometimes the deadline has caused more harm than good. I’m not really sure what to do about that; perhaps just pushing on is the right answer.
+I’ve taken a lot of notes on the design of my programming language. Any time I learn something interesting about another language, or come up with another idea, I write it down.
+But I haven’t worked on the implementation. (I last worked on the implementation in 2014.) I should be experimenting with some ideas, implementing them to see how they work out. I’ve even kicked around the idea of starting with a Forth variant, just to get something working quickly.
+I haven’t written any articles on my ideas this year either. My notes are pretty extensive, and it would be good to write some articles to help get my thoughts straight.
+I’ve got some things to say about Agile, and want to write a book to express those ideas. I’ve made a start — I’ve got the chapters outlines, and have started on a few chapters. But I haven’t made as much progress as I’d like to. I shared what I’ve got with Amos, and he showed some interest in pairing with me on the writing. Hopefully we’ll work on it together in 2016 and publish it.
+There were a few other accomplishments that weren’t explicitly on my list, but I’d like to call attention to.
+I’ve continued participating on the This Agile Life podcast. I was in 12 of the 33 episodes that were recorded in 2015. I hope to participate in more in 2016. We’re considering scheduling a standard recording night each week, which might help us record more regularly.
+I recently took over as maintainer of Virtus, a library to declare attributes for Ruby model classes. I haven’t done a lot yet, since I’ve been busy with travel, vacation, and holidays. But I hope to catch up with all the pending pull requests and issues in the next month or so.
+The accomplishment I’m most proud of is mentoring for the Roy Clay Sr. Tech Impact program. This is a program begun as a result of the Ferguson protest movement. We’re helping teach kids (from 14 to 25) web design and development. My personal goal was to give these kids an opportunity that they would not have otherwise had. But it turned out that some of them have actually started a business building web sites for small companies. I’m so proud of the progress they’ve made in such a short time; it’s a challenging program.
+I’m pretty happy with my accomplishments this year. I made at least some progress on each of the goals I set. I’ve been thinking about my goals for next year; I’ll write that as a separate blog article next week.
+I’ve always been someone who faces my fears.
+I have a moderate case of arachnophobia. I don’t run away when I see a spider, but it creeps my out when one is crawling on me. When I was in college, I decided to buy a tarantula to attempt to get over my irrational fear of spiders. I thought I’d be able to get more comfortable with the tarantula over time, eventually to the point of letting it crawl on my arm. It didn’t work. Although I did find that my fear of tarantulas is rational — I got a terrible case of hives just from touching the urticating hairs that fell off into its water sponge.
+Last week, I was on vacation in Mexico. One of the excursions we took involved jumping in the water a lot. I’m not a strong swimmer — mostly because I have a hard time closing my nose; I hold my nose when I jump in. We zip-lined into the water a lot. At one point, there was a cliff to dive into the water from. It was about 15 feet above the water. It didn’t look so far down before jumping. But it felt like a really long way down the first time I jumped from it. It was pretty scary for me. So I did it a second time. There wasn’t any peer pressure to jump a second time. I literally jumped a second time specifically because I was scared.
+Fear is a weird thing. Fear is there to protect us. But it’s there to protect us from the dangers of the African savannah. Most of the things our fears protect us from don’t exist in our everyday modern lives. So maybe we should work to gain a better understanding of how our fears work, to figure out when to pay attention to them and when to ignore them.
+Fortunately, our brain has a good mechanism to help us do this. Our brains basically have 2 main processing systems. The first one is for quick reactions. This one involves things that are nearly reflexes. Fear is in this system. The second system is our analytical reasoning system. This system takes longer to process, but is able to take on more information.
+Whenever the situation allows us time for both systems to work, we need to listen to them both. We need to listen to our fears, because they’re there for a reason. But that reason might not pertain to our situation. So we need to realize that, and let the slow analytical system determine if we should ignore our fears.
+If we don’t allow both systems to work, we’re not taking full advantage of our brains; we’re not taking full advantage of the situations that life is presenting to us.
+I’ve been on vacation the past week, in Cozumel, Mexico. One day, we went on an excursion called Xenotes. A cenote (say-NO-tay) is a sinkhole filled with fresh water. (The “X” is to give it a more Mayan-sounding trademarkable name.) We had a lot of fun swimming, kayaking, and zip-lining. A bilingual tour guide led our group, which consisted of people from across the US and South America, of various ages and physical abilities.
+Our tour guide was a lot of fun. He made jokes, told us about the cenotes, and led us in the activities. But he also encouraged us. When someone was scared to do something, he was supportive. He told us that it was okay, and we could do it. But we also felt like it was OK to fail, if we really couldn’t. It really felt like his encouragement was literally creating courage.
+What was really neat was that despite the language barrier, everyone else was also supportive and encouraging. Everyone cheered with encouragement before someone would attempt something difficult. And we’d cheer especially loud once someone accomplished something that was difficult for their abilities.
+It was an awesome feeling to feel so supported. It made me feel like I was in a safe place, where I could try new things that were a little past my comfort zone. I was able to do the zip-line upside-down. I jumped off a 15-foot cliff into the water. I even jumped off the cliff a second time, even though I was a little scared.
+Back at the resort, we played some volleyball in the pool. It was a similar situation, with players of varying ages and abilities. Again, we tried to help the weaker players feel comfortable so they could improve without feeling judged or self-conscious. It helped everyone have a good time. It made everything more fun to be in such a supportive environment, whether I was in a position as one of the more skilled (volleyball), or one of the less skilled (jumping or zip-lining into the water). We were all able to accomplish more, with less effort.
+These experiences provide a good lesson that can be applied in a lot of places. Such a supportive environment would help any relationship, and any team. I’ve been on a couple really good software development teams, but I don’t think any of them have been as supportive as these two groups of strangers.
+I’ve decided that this should be one of my goals as a team leader. I want to create an encouraging environment for the whole team. I want to make sure that everyone is comfortable enough that they feel like they can try things that are difficult, even if they might fail (as long as nobody gets hurt).
+If a group of strangers can do this, so can your team. So can you and your significant others. We need to work every day to make sure that we’re supporting each other. It’s the best way to get everyone to achieve more.
+I got my first computer in 1984. It was a Commodore 64. I had to do extra chores and save up my allowance to buy it. I was 13.
+Back then, Sears and other retail stores had Commodore 64 computers out on display. Whenever I went to the store, I’d write a short BASIC program and leave it running on the display computers:
+10 PRINT "CRAIG IS GREAT!" +20 GOTO 10+
Hey, I was a 13-year-old kid. Later, I got a little more sophisticated. I’d change the background color instead. I still remember the POKE address:
+10 FOR I=0 TO 255 +20 POKE 53281, I +30 NEXT I +40 GOTO 10 +RUN+
This was fast enough to change the background color every few scan lines, creating a flashing scrolling effect.
+Later, I learned 6502 assembly language. I translated the BASIC program into assembler, and memorized the bytes to type in at the store. In assembly language, the background color would change several times per scan line. The effect was kind of psychedelic.
+All that happened in the mid-1980s.
+Fast-forward to about 2000 or so. I was telling the above story after a St. Louis LUG meeting. I explained how I had memorized the 10 or 12 bytes of machine code, and would leave the program running with its psychedelic effect.
+After thinking about it for a bit, I thought that 10 or 12 bytes seemed too much. It actually bothered me — I couldn’t fall asleep when I got home. I got up and found my old 6502 manuals. I figured out how to write the code in 7 bytes. I installed the Vice C64 emulator on my Linux desktop, and tested my code. It worked as expected. (The emulator was already clock-cycle perfect by then.) Here’s the assembly code:
+INX ; $E8 ; 232 +STX $D021 ; $8E $21 $D0 ; 142 33 208 ; $D021 = 53281 +JMP $C000 ; $4C $00 $C0 ; 76 0 192 ; $C000 = 49152+
Here’s the BASIC program to store that program in memory and run it:
+10 FOR N=49152 TO 49152+6: READ Q : POKE N, Q : NEXT +20 DATA 232, 142, 33, 208, 76, 0, 192 +30 SYS 49152 +RUN+
The moral of the story is that you can optimize even a 10-byte program, 15 years after the last time it was used. So don’t tell me that your program can’t be improved, no matter how small it is.
+PS. I rewrote the code above while writing this article in 2015, about 15 years after the last time I rewrote it. And I again downloaded Vice to test it, this time on Mac OS X.
+I’m wrapping up my current consulting gig at Mercy in December, and starting a new gig at CenturyLink. I’m a software developer, but that’s only a part of what I do. What I really do is join a team and help them improve the way they work — both their processes and their technical skills.
+I think this is a key differentiator for me as a consultant. Most consultants (and Agile coaches) come in and tell people what to do. I don’t like to just tell people what to do. I’d much prefer to work side-by-side with them, getting a better understanding of what their challenges are. Once I have a better understanding of the challenges, I’m able to better brainstorm some ideas to try. Then we can experiment to see what will work and what won’t.
+Instead of telling people what to do, I show them how. Most people learn better from seeing than from hearing. They also learn better if you explain how and why, not just what. So showing them how to do something is more effective than telling them. By showing and doing, you can also set a good example. This is especially important when collaboration is a large part of what needs to be improved.
+I’ve found that this style of consulting is more highly respected by everyone. I build trust with developers by working closely with them. Managers like to keep me around once they see how effective these methods can be, so the gigs I take on tend to last relatively long.
+The biggest problem I have is explaining how this works. I don’t really know what to put on my résumé. Sometimes I call myself an Agile practitioner, and sometimes an Agile player/coach. But those aren’t terribly satisfying descriptions. I’m considering actually putting “I help teams improve the way they work — both their processes and their technical skills” on the résumé. But that seems awkward, and misses the show versus tell part. I’d be open to any suggestions.
++
I facilitated a retrospective today; it was one of the best retros I’ve ever been involved with. I figured out what activities I wanted to do earlier in the morning. They were really quite simple. I wanted to focus on happiness.
+I started with two questions that I’ve used with teams before, to some success (although not so successful for one particular team). The first question I asked was “How happy are you at work?” I had them put a rating from 0 to 10, with 0 meaning they should have quit last week, and 10 meaning they couldn’t imaging being happier at work.
+The answers were mostly 7s and 8s, with a 5 and a 9. The average came to 7.5, which is pretty good. The 5 concerns me a bit, especially that it’s 2 points lower than anyone else’s answer.
+The next question I asked was “How effective do you think the teams is?”. Again, from 0 to 10, with 0 meaning they can’t accomplish anything, and 10 meaning you couldn’t imagine a more effective team.
+When I ask both of these questions, the scores are always highly correlated. If your team isn’t doing good work, it’ll make you unhappy. And if you are unhappy, you’re less likely to do your best work. This team was no different; the 5 and 9 became a 6 and a 10, and most of the 7s became 8s, for an average of just under 8.
+The next question I asked was “What makes you happy at work?”. The answers were mostly about the teamwork and teammates. This went quicker than I expected. At this point, I was worried the retro would only last a little more than 30 minutes.
+The final question I asked was “What would make you happier at work?”. This was the real pay-off. We spent about half an hour just talking about the things that would make us happier, and what we could do to improve our happiness. We came up with 10 potential action items. I usually limit teams to trying 3 or 4 action items, but most of the items are quite small, so we’re going to try 6 of them. One is just observing another team’s standup meetings, to see how they’re using their time effectively.
+Everyone went away feeling that this was a really good retro. It felt good to focus on happiness. Happiness is something I’ve been talking a lot about on the This Agile Life podcast, and it felt good to take some action on it. I’ve done “positive-only” retros before, but this one felt even better than that, by specifically targeting happiness and how we can achieve it.
+Web Development, Ruby on Rails, Open Source
+I’m considering buying a chording keyer. A keyer is a 1-handed text input device. Chording means that you can hit more than 1 key at a time. I’ve been interested in these for a long time actually. They’ve been popular in the wearable computing (“cyborg”) field, but never caught on anywhere else. I’ve always thought that 1-handed chording keyer would be a great input device to use with a cell phone. It’d be even better with a heads-up display like the Google Glass.
+There are quite a few chording keyers available. It doesn’t appear that any will meet exactly what I’m really looking for, but I might take the leap anyway. It should be a hand-held device. I really want a Bluetooth device, so I can use it with a computer, phone, or tablet. Below are the ones I’m considering.
+The Twiddler has been around quite a while, as probably the main commercially available keyer for wearable computing. There was a time that it was unavailable, but there’s a new version available from HandyKey now. It’s $200 ($220 Canadian), and comes in only USB.
+The Twiddler looks like a small TV remote. The current version (2.1) has 4 thumb keys, a thumb joystick (for mouse), and 12 small finger keys. It has good community support, including an alternate chord layout.
+In10did has been trying to bring out a few variations of their devices. The Decatxt looks like a pack of cigarettes, with 8 keys on the front and 2 thumb keys. It can be used with 1 or 2 hands. All letters can be typed with 1 finger or 1 thumb and 1 finger.
+The Decatxt has USB and Bluetooth models, but I’m unable to find pricing or a way to buy one. It looks like there have been no updates for over a year, so I’m concerned that this is going to be vaporware.
+The CyKey is based on the Microwriter, which goes back to the early 1980s. The Microwriter was a desktop-based device, but it looks like the CyKey might be able to be used as a hand-held device. It has 9 buttons on the face, arranged in 3 groups of 3 buttons.
+The CyKey is $125 (£75) and works over InfraRed connected to USB. A Bluetooth model is supposedly in the works.
+The EkaPad is like a cross between the Decatxt and the Twiddler. It has 12 buttons on the face, but no thumb keys. It’s got a nice well-thought-out design that looks quite ergonomic.
+The EkaPad is $150, available in USB only. A desktop holder is available to hold it upright, or it can be used hand-held.
+The FrogPad is meant to be used on a flat surface only. It looks kind of like a third of a laptop keyboard. It’s got 15 regular keys and 5 modifier keys. Only 1 key and 1 modifier can be chorded. Right-handed and left-handed models are available, with USB connectivity.
+The FrogPad2 was recently announced, replacing the original FrogPad. It switches to standard desktop-style keys, and adds some more keys along the top. It supports USB On-the-Go and Bluetooth. I’m not really interested in this model with its regular keys, but it doesn’t appear that the original version is being made any longer. The new models are priced at $200. I believe the old models were $150.
+The Chordite looks the most promising, but it’s only a concept with some DIY prototypes. It’s a hand-held device, with 2 buttons on each of the 4 fingers — one activated by the distal phalanx and the other by the middle phalanx. This initially sounds like it would be difficult to press 2 different buttons with 1 finger, but I think the way they’re positioned would make it actually work really well.
+The septambic keyer is another DIY concept, hand-built and used by wearable computing folks. It’s fitted to your palm, and you squeeze your fingers toward a fist to activate the buttons. There’s one button for each of the 4 fingers, and 3 for the thumb.
+The Clove 2 is a Bluetooth-enabled glove with 5 buttons — 1 for each finger. It’s another do-it-yourself project.
+I found an interesting project called ASETNIOP that allows chording on a standard Qwerty keyboard. (Assuming the keyboard supports multi-key roll-over well enough. Most keyboards should work.) It’s got a really nice online interactive tutorial. You basically chord with the 8 home-row keys, plus the spacebar.
+For Android, a program called GKOS for Android uses multi-touch with 1 or 2 button presses. The buttons are different sizes, depending on their frequency. I like this concept, but I don’t think the implementation is quite ready for production.
+I also found an app for iOS called Nintype that is a combination between Swype and a chording keyer.
+I think I’m going to try the Twiddler. If I find the concept to be a good one, hopefully I’ll build myself a Chordite (or have someone build one for me).
+I’m also going to play with implementing some of the ideas from ASETNIOP, using KeyRemap4MacBook.
+Frogpad2 failed recently (see https://www.facebook.com/profile.php?id=105714169451329), but there is another possibility using freeware: http://www.autohotkey.com/ and scripts (easy adaptable!?):
+half querty: http://www.autohotkey.com/board/topic/1257-half-qwerty-one-handed-typing/
+frogpad: https://github.com/clarkm/dupepad/blob/master/frogpad.ahk
+Will be trying soon…
The In10did DecaTxt is available on eBay and Amazon now. I ordered one recently and had it shipped over from the USA, which was a bit expensive when customs fees are added. It arrived yesterday morning and I plugged it in after arriving home from work. Sadly, it appears to do nothing whatsoever. Not sure if this model is DOA (but surely they test them?), or what. If I can get it to work, or get a replacement shipped, I’ll try to record my WPM with the device every day for a couple of weeks, to see where the improvement curve starts to taper off.
+Update: It works just fine! Actually the problem was that my laptop only supports Bluetooth 3.0, but at least 4.0 is needed. It also wasn’t discoverable by my phone because Android 4.3 or newer is needed. Tested it on a newer phone and on my work PC and it connected straight away. Looking forward to trying it on an Android tablet and measuring my speed over a few weeks.
+I’m glad you were able to get the DecaTxt connected and working. We are planning for a second version with micro USB rather than mini and a few software changes like being able to shut off the Bluetooth antenna. I’d love to get your feedback if you would email me and offer suggestions.
+Thanks,
+Wayne
+
+
+
+
+
+ I’ve run across a pattern in Ruby lately that I really like. It solves some problems that I’ve struggled with for several years. Let me start with the problems.
+Let’s say you want to include an ORM in a model class, and want to tell it what database table to use. Typically, you’d do this:
+class User + include MyORM::Model + table 'people' +end+
But that table call is more like an option to the module inclusion than anything else. So what we’d really like is something like this:
class User + include MyORM::Model, table: 'people' +end+
But that’s not valid Ruby; include doesn’t let you pass anything other than a module.
So when I was learning about Virtus, I noticed that its example of how to include it is a bit different than the standard Ruby idiomatic include:
class User + include Virtus.model +end+
At first glance, it reads like the first example. But on closer inspection and consideration, it’s quite a bit different. Where MyORM::Model is a constant that refers to a module, Virtus.model is a method call. So there’s a method named model in the Virtus module. That method returns another module — which is exactly what’s needed in order to include it into our model class.
The easiest way to implement Virtus.model would be this:
module Virtus + def model + ::Virtus::Model + end +end + +module Virtus::Model + # ... +end+
If Virtus.model doesn’t need to take any arguments, that’s perfectly fine. In fact, I’ve started to use this implementation of the pattern for modules that don’t need parameters.
Because Virtus.model is a method, we can also call it with options:
class User + include Virtus.model(constructor: false, mass_assignment: false) +end+
We could even pass a block. But how do we process those options? There are a few different ways. However we do it, we have to be sure to return a module. And we can create modules in a few different ways.
+Virtus uses the builder pattern. It takes the parameters passed in and builds a module dynamically. By that, I mean that it calls Module.new and then adds methods to that module. It does this by mixing in other modules, but it could do it by dynamically defining methods as well.
I’ve never seen this pattern in any other language. It’s obviously only possible because we can dynamically create modules.
+The use of this idiom seems to be catching on a bit in the Ruby community. I’ve started using it myself, and will be adding it to my Includable::ActiveRecord gem soon.
++
+
I think it would be interesting to try using a block as the config to your include. Make a capitalized method that returns a module. Then you could pass a block with curly braces to that method.
+
+class User
+ include MyORM::Model {
+ table "people"
+ }
+end
+
Web Development, Ruby on Rails, Open Source
+January kept me pretty busy, so I’m a little late to this. But better late than never. And as an Agile practitioner, I don’t think personal retrospectives should be limited to one time of year.
+Last year I wrote a blog entry listing my goals for 2014. As far as New Year’s resolutions go, I was relatively successful — about 50% of my goals accomplished. Unfortunately, my Open Source contributions weren’t as strong as I had hoped; while I released some of my own work, I didn’t do much else. I did increase my blogging; getting in on a weekly blogging pact helped immensely. I also increased my participation on the This Agile Life podcast to a level that I’m happy with. But the accomplishment I’m most proud of was giving a presentation at RubyConf.
+I’d like to keep things rolling from last year, but crank up a few things. My plans are quite ambitious, so I don’t expect to get everything done by any means. But I think by setting the bar high, I’ll end up with a lot I can be proud of.
+Late last year, I took the jump into independent consulting. So far, I’ve really enjoyed it, and I’m booked up through April. My wife graduates in May, so we’ve got the possibility of moving if that makes sense. So I’ll be looking for consulting projects in town, but I’ll also be looking at jobs in San Francisco and Chicago. The possibilities are exciting, and I’ll be taking my time to find something just right.
+I was incredibly nervous leading up to my RubyConf presentation. Part of that was just the common fear of public speaking. For me, that only kicks in at around 100 people, and this audience was around 250. I think another reason was that I chose a really ambitious topic, and I kept finding more that I wanted to talk about, but wasn’t prepared for. But I think I did a pretty good job presenting an advanced topic. And I was so pumped by the sense of accomplishment as soon as I finished. So I’m hoping to do it more. I’ve already submitted a couple proposals, and plan to submit several more.
+I believe that blogging is important for me to get my thoughts down — for myself and to share with others. I was really successful last year when I had a partner to keep me honest, via a pact. So I’ve started up another pact this year, which will hopefully ensure I’ll keep things going. I’ve got a really long backlog of topics, so as long as I keep at it, I’ll have plenty to write about.
+I also want to move away from WordPress to a static system — probably Middleman. I’ve got 2 major problems with WordPress. First, I no longer trust its security, nor the security of any application written in PHP. Second, it generates HTML every time someone requests a page, instead of when the content is updated. I find that to be a waste of resources, and problematic from a security standpoint. The main problem with moving to a static blogging system is that I really want to allow comments, pingbacks, and tweetbacks. So I’ll have to find a way to integrate those.
+Last year I started thinking about programming language design, and started implementing a language tentatively called Brilliant. I’ve done a lot more thinking on the topic, and have a lot of notes. But I haven’t implemented much more yet. This year, I’d like to get my thoughts more organized, and write a series of blog posts on various aspects of language design. The most interesting part seems to be the trade-offs involved in the ways that various language features interact. So I’d like to make some progress on the language implementation, but more importantly, I’d like to get a lot of my design ideas written down.
+I’m also going to spend a lot of time learning a bunch more programming languages, so I have a better understanding of possible features, combinations of features, and their interactions. I’ve already start with Elixir, Clojure, and Racket. I’m hoping to also look at OCaml, Factor, and Haskell. I’ll probably also take a look at the 2 “Seven Languages in Seven Weeks” books.
+I think people often have trouble getting started with Agile. I started on a book last year, and got down quite a lot of good ideas. But I realized that I’m going to have a hard time organizing all those ideas into something coherent. Still, I’d like to try to get something out there that lets people get started with Agile. My idea is to present a toolbox of practices to get started with and build on that foundation over time with additional practices. Sort of a playbook on how to get started over the first 6 to 12 months and be successful. I want to make some progress on the book, at least enough to decide whether it’s worth the effort to finish it and self-publish it.
++
Web Development, Ruby on Rails, Open Source
+BoochTek, LLC is a small web development company, based in St. Louis, Missouri. We specialize in Ruby, Ruby on Rails, Rails rescue projects, Agile methodologies, JavaScript, and HTML 5. We also do GNU/Linux system administration and network security.
+
+
+
+
+
+
+ I ran into some former colleagues recently, from a company where I had worked to help transform the team to be more Agile. They’ve gone through some reorganization and management changes recently. One of the guys said that their team culture has helped them maintain quality in the face of those changes. This struck me as odd, since I had considered the work I had done there as somewhat of a disappointment. While I felt I had made a small dent, I didn’t feel like I’d made a true Agile transformation. Much of what I had taught didn’t seem to “stick”.
+Later that night I thought about why my opinion of the team and his opinion were so different. There are a lot of reasons why an Agile “transformation” could fail. It could be due to lack of support from management. Or even worse, not getting the team members to buy into the ideas — usually due to fear of change. But while those had some effect in this case, they weren’t really the main issues. Now that I’ve had some time and some distance from that team, I’ve gained some clarity on what the real issues were.
+I think the reason that I think this transformation was a failure was due to the continued pace of change that true Agile requires. Basically the team experienced “change fatigue”, where everything keeps changing and you feel like you can never catch your breath. But the more interesting thing is how our perceptions differed. He seemed to think that the transformation was a success — they’re doing things better than they used to. I view it as more of a failure, because they basically stopped improving — at least at the pace that I was hoping for.
+I think this difference in mindset is pretty fundamental. My view of Agile involves continuous improvement — always inspecting and adapting our processes. I suppose that means that my preferred flavor of Agile is “Kaizen“. But other people don’t see improvement and change as a constant — they see each change as a means to an end. I’m starting to realize that neither viewpoint is objectively correct. Maybe they’re both fine viewpoints to have. Maybe I shouldn’t be so hard on myself and view that engagement as a failure, especially if my teammates view it as a success. Maybe perfection is the enemy of the good. And maybe I need to learn to be happy with “good enough”.
++
+
+
+
+
+
+ On a recent episode (78) of This Agile Life, my fellow hosts talked about when to do Test-Driven Development (TDD). They all said that you should always do TDD — at least for anything that will go into production; there’s an exception for experimenting or “spiking”.
+I wasn’t on that episode, but later commented on the topic. (Episode 83 — which wasn’t really all that great.) My take was slightly different. I said that you should do TDD only when the benefits outweigh the costs. Unfortunately, we usually greatly underestimate the benefits. And the costs often seem high at first, because it takes some time to get good at writing automated tests. Not to mention that both the costs and the benefits are usually hard to measure.
+What is the cost of writing automated tests? I’ve asked this question before and recorded the answers (inasmuch as we have them) in a previous blog entry. TDD costs us about 10-30% in short-term productivity. The benefit that they found was a reduction in bugs by 30-90%, and a decrease in code complexity by about 30%.
+But what about when the costs are higher than the normal 10 to 30 percent? One good example of this is when there’s no test framework for the situation you’re testing. This might be a new language or framework that you’re working with. More likely it’s a complex API that you have to mock out. So that could increase the cost of automated testing so as to outweigh the benefits — especially on a short project. I could imagine situations where the cost of writing the mocks could eat up more than the project itself.
+Another case where we might consider skipping testing is when we’re more concerned about time to market than quality. This is almost always a mistake. Your code will almost always last longer than you expect. (Remember Y2K?) And if the code lasts longer than you expect, that means you’ll have to deal with bugs that whole time. But we have to work with the information we have at the time we make our decisions. And sometimes that might tell us that time to market is more important than anything.
+One final case I can imagine is when a true expert is coding something that they’re very familiar with. I could picture someone like Uncle Bob writing code (in a language that he’s familiar with) without tests just as effectively as I could write code with tests.
+But these situations should not be common; they’re edge cases. In almost all real-world cases, TDD is the right thing to do. Don’t forget, TDD is also a design discipline — it helps you design a better API. So keep doing TDD. But as with any practice, don’t do it blindly without considering why we’re doing it. Make sure you understand the costs, and whether the benefits outweigh the costs.
+
+
+
+
+
+
+ I’m a big proponent of Agile (mostly XP; I’m mostly anti-Scrum) and I’ve contributed some to the #noestimates “movement”.
+I don’t really mean that nobody should ever estimate anything. I mean that I’ve never seen useful (fine-grained) estimates anywhere. Here are some of the problems with estimates that I’ve seen frequently:
+I’ll note that most of these pit management against the team, instead of working together toward a common cause. Most of the practices also lead to seriously demoralizing the team. And most of the time, the estimates aren’t really even taken into account very much.
+My advice is to first understand the value of a project before you consider estimating the costs. The estimation at this point will be very rough, so make sure that you have a very wide margin between the expected value and the rough estimate of the cost. If you’re pretty certain of the expected value, I’d probably want to make sure I could still be profitable even if it took 3 or 4 times as long to complete as the rough estimate. And if there’s uncertainty in the expected value, much more.
+Another way to mitigate the risk of throwing money at something that’s not going to have positive ROI is to reduce the feedback loop. Order the work so that the tasks are ranked in order of value. (Realistically, you’ll have dependencies of tasks to worry about, and should consider effort involved too.) So work on the most valuable feature first — get that out into production as soon as possible. Once that’s done, you can assess if your ROI is positive or not. Keep iterating in this fashion, working on the features that will provide the most value first. Keep assessing your ROI, and stop when the ROI is no longer worth it, compared to other projects the team could be working on.
+At a fine-grained level, if you’re using story points, I’d ask you to do the math to see if just counting the stories would be as effective at predicting how much will be done over time as using the story points. If so, you can save the time the team spends on estimating stories. I’d still recommend spending time talking about stories so that everyone has a shared understanding of what needs to be done, and to break stories up into a smaller, more manageable size — with one acceptance criteria per story. Also take a look to see if empirical average cycle time (how long it takes a single story to move from start to finish) might provide you the predictive power just as well as estimates. (I.e. is it bandwidth or latency that really provides the predictive power you’re looking for?)
+And don’t forget Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.
+Web Development, Ruby on Rails, Open Source
+I’m surprised that I haven’t gotten this story down in print before. It’s something I’ve mentioned many times — including a few times on the podcast. It’s a great story about the power of retrospectives, and it’s a great story about the power of a blameless post-mortem.
+I don’t recall all the specifics at this point. It was about 5 years ago. I’d just noticed that Arun had made some sort of mistake. That’s fine, people make mistakes. The thing that was different about his mistake was that I had made the same mistake about a week prior. And Amos had made the same mistake about a week before that.
+Noticing a pattern of mistakes, Amos and I called an impromptu retrospective. We gathered all the developers into a conference room. We explained the problem that we were running into. At first, Arun was defensive. That’s understandable; he thought we were there to come down on him, to lay blame. But we made it clear that we weren’t focusing on him. We admitted that we had also made the same mistake recently. We weren’t there to lay blame; we were there to figure out how our team could stop making the mistake. It took Arun a few minutes to get over the defensiveness.
+With the defensiveness out of the way, we could focus on the issue at hand. We were able to figure out the root cause of us all making the mistake. (I don’t know if we played the “5 whys” game, but I’m sure we effectively did something similar.) And with that, we were able to change our process, so that nobody else would make the same mistake again.
+There are 2 important points to this story. First, you don’t have to wait until a scheduled retrospective to hold a retrospective. This one was impromptu, and it’s the best one we ever had. We saw a problem, addressed it, and found a solution in less than an hour. Had we waited until the end of the week, we would have forgotten some of the details, and wouldn’t have been as effective at solving the problem. Second, when addressing problems, take your ego out of the equation. If you’re in a position of authority, take the blame — but never place blame. Focus on what’s important — solving the problem.
+And don’t forget the Retrospective Prime Directive:
++Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
+
Web Development, Ruby on Rails, Open Source
+I facilitated a retrospective today; it was one of the best retros I’ve ever been involved with. I figured out what activities I wanted to do earlier in the morning. They were really quite simple. I wanted to focus on happiness.
+I started with two questions that I’ve used with teams before, to some success (although not so successful for one particular team). The first question I asked was “How happy are you at work?” I had them put a rating from 0 to 10, with 0 meaning they should have quit last week, and 10 meaning they couldn’t imaging being happier at work.
+The answers were mostly 7s and 8s, with a 5 and a 9. The average came to 7.5, which is pretty good. The 5 concerns me a bit, especially that it’s 2 points lower than anyone else’s answer.
+The next question I asked was “How effective do you think the teams is?”. Again, from 0 to 10, with 0 meaning they can’t accomplish anything, and 10 meaning you couldn’t imagine a more effective team.
+When I ask both of these questions, the scores are always highly correlated. If your team isn’t doing good work, it’ll make you unhappy. And if you are unhappy, you’re less likely to do your best work. This team was no different; the 5 and 9 became a 6 and a 10, and most of the 7s became 8s, for an average of just under 8.
+The next question I asked was “What makes you happy at work?”. The answers were mostly about the teamwork and teammates. This went quicker than I expected. At this point, I was worried the retro would only last a little more than 30 minutes.
+The final question I asked was “What would make you happier at work?”. This was the real pay-off. We spent about half an hour just talking about the things that would make us happier, and what we could do to improve our happiness. We came up with 10 potential action items. I usually limit teams to trying 3 or 4 action items, but most of the items are quite small, so we’re going to try 6 of them. One is just observing another team’s standup meetings, to see how they’re using their time effectively.
+Everyone went away feeling that this was a really good retro. It felt good to focus on happiness. Happiness is something I’ve been talking a lot about on the This Agile Life podcast, and it felt good to take some action on it. I’ve done “positive-only” retros before, but this one felt even better than that, by specifically targeting happiness and how we can achieve it.
+Web Development, Ruby on Rails, Open Source
+I’m wrapping up my current consulting gig at Mercy in December, and starting a new gig at CenturyLink. I’m a software developer, but that’s only a part of what I do. What I really do is join a team and help them improve the way they work — both their processes and their technical skills.
+I think this is a key differentiator for me as a consultant. Most consultants (and Agile coaches) come in and tell people what to do. I don’t like to just tell people what to do. I’d much prefer to work side-by-side with them, getting a better understanding of what their challenges are. Once I have a better understanding of the challenges, I’m able to better brainstorm some ideas to try. Then we can experiment to see what will work and what won’t.
+Instead of telling people what to do, I show them how. Most people learn better from seeing than from hearing. They also learn better if you explain how and why, not just what. So showing them how to do something is more effective than telling them. By showing and doing, you can also set a good example. This is especially important when collaboration is a large part of what needs to be improved.
+I’ve found that this style of consulting is more highly respected by everyone. I build trust with developers by working closely with them. Managers like to keep me around once they see how effective these methods can be, so the gigs I take on tend to last relatively long.
+The biggest problem I have is explaining how this works. I don’t really know what to put on my résumé. Sometimes I call myself an Agile practitioner, and sometimes an Agile player/coach. But those aren’t terribly satisfying descriptions. I’m considering actually putting “I help teams improve the way they work — both their processes and their technical skills” on the résumé. But that seems awkward, and misses the show versus tell part. I’d be open to any suggestions.
++
Web Development, Ruby on Rails, Open Source
+I got my first computer in 1984. It was a Commodore 64. I had to do extra chores and save up my allowance to buy it. I was 13.
+Back then, Sears and other retail stores had Commodore 64 computers out on display. Whenever I went to the store, I’d write a short BASIC program and leave it running on the display computers:
+10 PRINT "CRAIG IS GREAT!" +20 GOTO 10+
Hey, I was a 13-year-old kid. Later, I got a little more sophisticated. I’d change the background color instead. I still remember the POKE address:
+10 FOR I=0 TO 255 +20 POKE 53281, I +30 NEXT I +40 GOTO 10 +RUN+
This was fast enough to change the background color every few scan lines, creating a flashing scrolling effect.
+Later, I learned 6502 assembly language. I translated the BASIC program into assembler, and memorized the bytes to type in at the store. In assembly language, the background color would change several times per scan line. The effect was kind of psychedelic.
+All that happened in the mid-1980s.
+Fast-forward to about 2000 or so. I was telling the above story after a St. Louis LUG meeting. I explained how I had memorized the 10 or 12 bytes of machine code, and would leave the program running with its psychedelic effect.
+After thinking about it for a bit, I thought that 10 or 12 bytes seemed too much. It actually bothered me — I couldn’t fall asleep when I got home. I got up and found my old 6502 manuals. I figured out how to write the code in 7 bytes. I installed the Vice C64 emulator on my Linux desktop, and tested my code. It worked as expected. (The emulator was already clock-cycle perfect by then.) Here’s the assembly code:
+INX ; $E8 ; 232 +STX $D021 ; $8E $21 $D0 ; 142 33 208 ; $D021 = 53281 +JMP $C000 ; $4C $00 $C0 ; 76 0 192 ; $C000 = 49152+
Here’s the BASIC program to store that program in memory and run it:
+10 FOR N=49152 TO 49152+6: READ Q : POKE N, Q : NEXT +20 DATA 232, 142, 33, 208, 76, 0, 192 +30 SYS 49152 +RUN+
The moral of the story is that you can optimize even a 10-byte program, 15 years after the last time it was used. So don’t tell me that your program can’t be improved, no matter how small it is.
+PS. I rewrote the code above while writing this article in 2015, about 15 years after the last time I rewrote it. And I again downloaded Vice to test it, this time on Mac OS X.
+Web Development, Ruby on Rails, Open Source
+I’ve been on vacation the past week, in Cozumel, Mexico. One day, we went on an excursion called Xenotes. A cenote (say-NO-tay) is a sinkhole filled with fresh water. (The “X” is to give it a more Mayan-sounding trademarkable name.) We had a lot of fun swimming, kayaking, and zip-lining. A bilingual tour guide led our group, which consisted of people from across the US and South America, of various ages and physical abilities.
+Our tour guide was a lot of fun. He made jokes, told us about the cenotes, and led us in the activities. But he also encouraged us. When someone was scared to do something, he was supportive. He told us that it was okay, and we could do it. But we also felt like it was OK to fail, if we really couldn’t. It really felt like his encouragement was literally creating courage.
+What was really neat was that despite the language barrier, everyone else was also supportive and encouraging. Everyone cheered with encouragement before someone would attempt something difficult. And we’d cheer especially loud once someone accomplished something that was difficult for their abilities.
+It was an awesome feeling to feel so supported. It made me feel like I was in a safe place, where I could try new things that were a little past my comfort zone. I was able to do the zip-line upside-down. I jumped off a 15-foot cliff into the water. I even jumped off the cliff a second time, even though I was a little scared.
+Back at the resort, we played some volleyball in the pool. It was a similar situation, with players of varying ages and abilities. Again, we tried to help the weaker players feel comfortable so they could improve without feeling judged or self-conscious. It helped everyone have a good time. It made everything more fun to be in such a supportive environment, whether I was in a position as one of the more skilled (volleyball), or one of the less skilled (jumping or zip-lining into the water). We were all able to accomplish more, with less effort.
+These experiences provide a good lesson that can be applied in a lot of places. Such a supportive environment would help any relationship, and any team. I’ve been on a couple really good software development teams, but I don’t think any of them have been as supportive as these two groups of strangers.
+I’ve decided that this should be one of my goals as a team leader. I want to create an encouraging environment for the whole team. I want to make sure that everyone is comfortable enough that they feel like they can try things that are difficult, even if they might fail (as long as nobody gets hurt).
+If a group of strangers can do this, so can your team. So can you and your significant others. We need to work every day to make sure that we’re supporting each other. It’s the best way to get everyone to achieve more.
+Web Development, Ruby on Rails, Open Source
+I’ve always been someone who faces my fears.
+I have a moderate case of arachnophobia. I don’t run away when I see a spider, but it creeps my out when one is crawling on me. When I was in college, I decided to buy a tarantula to attempt to get over my irrational fear of spiders. I thought I’d be able to get more comfortable with the tarantula over time, eventually to the point of letting it crawl on my arm. It didn’t work. Although I did find that my fear of tarantulas is rational — I got a terrible case of hives just from touching the urticating hairs that fell off into its water sponge.
+Last week, I was on vacation in Mexico. One of the excursions we took involved jumping in the water a lot. I’m not a strong swimmer — mostly because I have a hard time closing my nose; I hold my nose when I jump in. We zip-lined into the water a lot. At one point, there was a cliff to dive into the water from. It was about 15 feet above the water. It didn’t look so far down before jumping. But it felt like a really long way down the first time I jumped from it. It was pretty scary for me. So I did it a second time. There wasn’t any peer pressure to jump a second time. I literally jumped a second time specifically because I was scared.
+Fear is a weird thing. Fear is there to protect us. But it’s there to protect us from the dangers of the African savannah. Most of the things our fears protect us from don’t exist in our everyday modern lives. So maybe we should work to gain a better understanding of how our fears work, to figure out when to pay attention to them and when to ignore them.
+Fortunately, our brain has a good mechanism to help us do this. Our brains basically have 2 main processing systems. The first one is for quick reactions. This one involves things that are nearly reflexes. Fear is in this system. The second system is our analytical reasoning system. This system takes longer to process, but is able to take on more information.
+Whenever the situation allows us time for both systems to work, we need to listen to them both. We need to listen to our fears, because they’re there for a reason. But that reason might not pertain to our situation. So we need to realize that, and let the slow analytical system determine if we should ignore our fears.
+If we don’t allow both systems to work, we’re not taking full advantage of our brains; we’re not taking full advantage of the situations that life is presenting to us.
+Web Development, Ruby on Rails, Open Source
+It’s that time of year again — time for a retrospective on how I did on my goals for the year. I had 5 main goals for 2015:
+I got pretty lucky on this one. My main contract with Mercy got extended several times. Amos and I must have been doing a good job of keeping the customer happy. We even made it through a couple rounds of layoffs. I’m wrapping up the gig at Mercy now. I’m working one day a week there, as the project winds down.
+I also started a new gig this month at CenturyLink. I’m working on a cloud development team. Our current project involves selling WordPress as a service. The manager had been courting me for most of the year. I’m excited about my new role; I’ll be writing about it in a blog post soon.
+I set a goal in 2014 to give my first conference talk. I accomplished that, giving an ambitious talk at RubyConf. I enjoyed having done that, and vowed to do more conference speaking.
+I gave 3 conference talks in 2015. I gave a workshop on HTTP at RailsConf. I talked about immutable infrastructure at Madison+ Ruby. At RubyConf, I gave a talk on a micro-ORM I wrote. I also gave a lightning talk about Agile estimation (#noestimates).
+I was an alternate speaker at Windy City Rails, but did not give my talk on Alternatives to ActiveRecord. I also went to Strange Loop, mainly to see several friends and acquaintances speak.
+I wrote 24 blog articles this year. That’s about one every other week. What really kept me going was participating in a writing pact. When the pact was going, I had a 75% blogging rate. That’s pretty good.
+I’m not so sure about the quality of my blog writing though. I know that practicing writing is supposed to make you better. I know I wrote some really good articles over the past year, but I think I also wrote some articles that weren’t very good. I think sometimes the deadline has caused more harm than good. I’m not really sure what to do about that; perhaps just pushing on is the right answer.
+I’ve taken a lot of notes on the design of my programming language. Any time I learn something interesting about another language, or come up with another idea, I write it down.
+But I haven’t worked on the implementation. (I last worked on the implementation in 2014.) I should be experimenting with some ideas, implementing them to see how they work out. I’ve even kicked around the idea of starting with a Forth variant, just to get something working quickly.
+I haven’t written any articles on my ideas this year either. My notes are pretty extensive, and it would be good to write some articles to help get my thoughts straight.
+I’ve got some things to say about Agile, and want to write a book to express those ideas. I’ve made a start — I’ve got the chapters outlines, and have started on a few chapters. But I haven’t made as much progress as I’d like to. I shared what I’ve got with Amos, and he showed some interest in pairing with me on the writing. Hopefully we’ll work on it together in 2016 and publish it.
+There were a few other accomplishments that weren’t explicitly on my list, but I’d like to call attention to.
+I’ve continued participating on the This Agile Life podcast. I was in 12 of the 33 episodes that were recorded in 2015. I hope to participate in more in 2016. We’re considering scheduling a standard recording night each week, which might help us record more regularly.
+I recently took over as maintainer of Virtus, a library to declare attributes for Ruby model classes. I haven’t done a lot yet, since I’ve been busy with travel, vacation, and holidays. But I hope to catch up with all the pending pull requests and issues in the next month or so.
+The accomplishment I’m most proud of is mentoring for the Roy Clay Sr. Tech Impact program. This is a program begun as a result of the Ferguson protest movement. We’re helping teach kids (from 14 to 25) web design and development. My personal goal was to give these kids an opportunity that they would not have otherwise had. But it turned out that some of them have actually started a business building web sites for small companies. I’m so proud of the progress they’ve made in such a short time; it’s a challenging program.
+I’m pretty happy with my accomplishments this year. I made at least some progress on each of the goals I set. I’ve been thinking about my goals for next year; I’ll write that as a separate blog article next week.
+Web Development, Ruby on Rails, Open Source
+I’ve written up a list of career-related resolutions the past few years. I’ve been pretty successful meeting those goals, so I’m going to continue the tradition.
+I want to increase the Open Source code I write this year. That’s basically everything I write that’s not directly related to work.
+I took over maintenance of Virtus late last year, but haven’t done a good job at finding the time for that. That’s probably more responding to issues on GitHub and merging pull requests. But eventually, I’ll likely add some features and do some refactoring.
+My goal is to work on 6 apps and libraries this year. That’s a pretty aggressive goal, but I want to focus on both learning new things and building some simple but useful things. Think MVP — focus on getting a lot of bang for not too much effort.
+I want to work on a new Rails app, to familiarize myself with Rails 5. I want to get some experience with some more modern gems. I also want to see if I can use some new techniques with a Rails app, especially things that might help us get closer to a hexagonal architecture. I’m also hoping to work with some different web frameworks — maybe Lotus, Rodakase, Trailblazer, or Phoenix. Or maybe one of the Crystal web frameworks.
+I also want to work on a couple Elm apps. I started the STL Elm group as an excuse to learn the language. I’d like to work on a Twitter client, that might eventually turn into a more general reading app. Beyond Twitter, it would keep track of things I want to read. The other Elm app I’d like to write is a game, based on the old Space Taxi game I loved to play on the Commodore 64.
+I wrote a micro-ORM last year called Ruby Preserves. I’ve started converting that from working with raw SQL to sitting atop the awesome Sequel gem. The simplicity is still there so far, and basing it on Sequel has so far gone easier than I expected. But I haven’t figured out how to do relationships (JOINs) yet; that will be the real test.
+I’m pretty happy with my 2015 conference experience. I want to keep my conference level about the same. I don’t really want to commit to more talks than I gave last year. Conference presentations take a lot of time and energy to write and practice.
+I’m planning to go to RailsConf, RubyConf, and Strange Loop. I’m hoping to give a talk at each of those, if I can. But I’ll probably attend all of them even if I’m not speaking. I’m also submitting a talk to Agile 2016. I’m unlikely to go to any other conferences, and even more unlikely to give more than 4 conference talks.
+I really want to finish my Effective Agile book this year. I’m going to try to pull Amos in to pair with me on it occasionally, to move it forward. If I’m able to get it done, I’d also like to maybe write a book on Elm.
+I actually want to do less blogging this year. Well, sort of. I want to put coding and book writing ahead of blogging. If that means less blogging, I’m okay with that. So my goal for blogging is more like every other week. And when I do write a blog article, I’d rather it be related to some code I’m working on, something that I could use in my book, or some more in-depth thoughts about programming language design.
+The contract I recently started at CenturyLink Cloud is open-ended, so I’ll likely be there for the entire year. I’m enjoying it so far; it’s a challenge, but I think I can make a significant impact. However, I’m really interested in moving to San Francisco in 2017. So I’m going to work on preparing for that in several ways.
+I’m going to resurrect my LinkedIn account. I’ve neglected it for a few years now. I’ll make sure everything is up to date, and make some connections I’ve been putting off. I also want to reclaim my Stack Exchange and Hacker News accounts.
+I’m going to pay a an expert to help me revamp my résumé. I think it’s pretty decent, but it could use some freshening up. I want it to stand out. I want to do a better job of explaining what I really do — which is to join a team to help them improve their processes and their technical skills.
+I’ll also need to clean up all my web sites, so they look nice when people come to take a look at them. This includes my personal site, consulting business site, wiki, and blogs. I should also upgrade my server to the latest version of Debian, and use Ansible and some other tools to provision it using the principles of Infrastructure as Code.
+Web Development, Ruby on Rails, Open Source
+I held a retrospective with my new team last week. The team includes 2 senior developers, 2 junior developers, a product owner, and a product analyst. I’ve joined the team as an engineering manager, which I think of more as a team lead with an elevated title. Being new to this group, I wanted a way to understand their values. What motivates them? What common values do we share that we can leverage to move forward in the same direction?
+I started out with a pretty simple question: “What do you value (in regards to what we’re building); what are you willing to fight for?” I asked them each to write down several values and then put them on the board before looking at everyone else’s answers. I also asked each person to rank their values in order of importance.
+It turned out that my question was a little vague. Some people thought about the question in terms of the end result, and some in terms of the process of creating the software. In some ways that was a bit of a problem, because the different interpretations led people in different directions. But in other ways, not pushing them in any particular direction got more varied answers, exposing how they think about the project and the product.
+My list (in order) was Effectiveness (doing the right thing), Quality (doing things right the first time), Happiness, Purpose, and Teamwork. In retrospect, I should have put Happiness first. If I’m not happy at work, I don’t really want to be there, and need to move on. (Sometimes I can trade some happiness at work for more happiness at home, but I’m definitely a person that needs to be happy at work.) The other values serve to improve my happiness, but the happiness is more important.
+My own issue ranking my values turned out to be a problem with the ranking in general. Should they be ranked in importance of the necessity of the value as an outcome, or in importance of the necessity to focus on the value? I think the former is what I was looking for, but even I wasn’t clear on that when I began the exercise.
+After everyone put their values up on the board, we read them off. Then I asked the team to choose several values that we share as a team. We pulled them off the individual members’ lists, and put them in the team list. Then I asked each person to come up and rank those values, then explain why they had ordered them that way, especially when they ordered them significantly different than the last person. I was hoping to come to some convergence of the rank over time, so we could document our values in rank order. That didn’t happen. But the discussion was illuminating to me and to everyone on the team.
+I think the most interesting part about the lack of convergence was the difference between the developers and the product guys. The product guys definitely viewed the values more in terms of outcomes than the process. That makes sense — they’re not as intimately involved in the process of building the product.
+We were able to converge on the top priority though: Will the user buy the product? This was a combination of a couple different values that we merged together. This included the end user experience as well as making sure the team would continue to have a reason for existing. The rest of the values we left unordered: Teamwork (cohesiveness), Data driven decisions, Team ownership, Simplicity, Effectiveness, Maintainability / Supportability, Quality, Automation, and Performance. I think that’s a pretty decent list.
+As a couple teammates pointed out, those values are probably in part a reflection of this current point in time. If I asked the same question some other time, under different conditions and team dynamics, the answers would probably change a bit. And we’d probably come up with other answers if asked again, just due to randomness of the way we think about these things.
+But I don’t think I’d do this activity a second time with the team. It was really about understanding our motivations — both our own, and those of our teammates. I found it effective in that way, and also in helping the team to think about our culture and how we can work to shape it to help us all push in the same direction.
+There are a few caveats. When I asked for feedback on the exercise, one teammate pointed out that it wouldn’t work if people weren’t honest about their values, and they answered with what they thought management or their teammates wanted to hear. I don’t think that was an issue with this group, but it’s something to keep in mind.
+The other major thing I’d do is to make it clear up front that I’m not looking for any action items from this activity; it’s more about understanding each other and ourselves. And next time, I’ll work to clarify how to rank the values.
+I would recommend this activity for a new team, or when the makeup of the team is changing in some significant way. I wish there was a way to help a team converge on the ranking of their values, but I suppose I should be happy that agreeing on the set of important values went pretty quickly. And the diversity of ideas and opinions is probably a blessing that I should be embracing — the more ideas we have, the wider the variety of solutions we can imagine.
+Web Development, Ruby on Rails, Open Source
+I recently attended an Open Space hosted at work. I’d never been to an Open Space, and didn’t know what to expect. We’d been told that this was a workshop to help Engineering Managers (my role), Product Owners, and Product Analysts find better ways of working together. But due to the way an Open Space works, it evolved into something completely different — and better.
+We’d brought in Diana Larsen to facilitate the Open Space. Diana is a stalwart of the Agile community, focusing on how people and teams interact. She literally (co-)wrote the book on Agile retrospectives. Diana was also kind enough to be our guest at an Agile LINC meetup later in the evening.
+The morning started off with all the participants sitting in chairs arranged in a circle. Diana rang a chime, a nice soothing tone that literally set the tone for the day. (Most people didn’t seem to like it, but I thought it had its purpose.) It also acted as a call to gather in the meeting space. She then walked around the inside of the circle as she explained what was going to happen.
+The idea behind Open Spaces came with the realization that at a conference, the “hallway track” (ad hoc discussions in the hallways) was often more valuable than the scheduled talks. So they figured out a way to capture that experience. There are only a few rules:
+Once Diana set the scene and explained the rules, people came up and presented ideas for topics. If you proposed a topic, you chose a time and location on the topic board. At that time, you’d facilitate a discussion on that topic. The format was really conducive to discussions. There was no preparation, so discussions were from the heart — lots of people felt that they could contribute.
+Being new to the company (only 2 months), I got a lot out of the workshop, beyond the content itself. I got to get to know several more people. I’d even say I made a few friends. Having open discussions, we found that many of the teams were having the same issues. This made it easy for me to talk to other people.
+All-in-all, I found the Open Space to be extremely conducive to discussions aimed at identifying issues, brainstorming solutions, and planning action items. I felt like we made great strides in addressing some of the biggest problems our organization is currently facing.
+Web Development, Ruby on Rails, Open Source
+Not too long ago, I was asked during a job interview “how do you convince your teammates that you’re right?” I answered with probably the most surprising answer: “I don’t.”
+It’s taken me years to realize that being right isn’t terribly important. Especially when there’s more than one right answer — which there usually is. It’s more important to work as a team. It’s more important to be respected and to have respect for others.
+A few weeks after that interview, I was pair programming with the person who had asked me the question. We’re both senior developers, so we both have a lot of experience and opinions based on that experience. We were writing a shell script, and we both had an idea in mind about how to write the code. I let him proceed with his idea. It was a pretty good idea; probably better than mine. But we paired very effectively. I’d let him finish some code, and I’d find a way to make it better. Then he’d find a way to make my code better. What we ended up with was so much better than my original idea, and his original idea as well. I commented on this, and he agreed. We left that pairing session feeling the high of having accomplished something rare — two very experience programmers coming up with better code than we could have imagined going in.
+I like to think of writing code as a path towards a destination. The destination is good code that does what it’s supposed to, is readable (intention revealing), is concise, and is well-factored so as to be easy to change in the future. But there are many paths to that destination. Especially when pair programming, the code gets refined as ideas are shared, getting you closer and closer to that destination. Sometimes the different paths end up with the same code; sometimes they end up with different code. But if the code does its job well (according to those criteria), it doesn’t really matter what code you ended up with.
+Thinking back to the original question, I think the answer is a little more nuanced. (I’m pretty sure I followed up with an explanation, but I don’t recall the details.) It truly doesn’t matter in a lot of cases. If there are different paths that lead to the same destination, and they’re all roughly equal, then my rule works. It can also work even if the first path you try (a “wrong” path) doesn’t work out, as long as it’s easy enough to try a different path. I find that the majority of day-to-day coding fits these conditions.
+But there are some places where it’s costly to get things wrong the first time. In these cases, it’s worth spending some time thinking about and discussing the alternatives before getting started. Software architecture is the big one that comes to mind. In general, weighing the pros and cons of each option and applying previous experience works best.
+So next time you think about trying to convince someone you’re right, fight the urge. Instead, let them show you what they’re thinking. They just might surprise you. And more importantly, you might surprise yourself.
+
+
+
+
+
+
+ I’ve been using Python at work for the past few months. I learned Python back in the early 2000s, but never used it for any large projects. I learned Ruby in late 2005, and it quickly became my language of choice for most cases.
+So while I still prefer Ruby, and will likely use Ruby more in the future than Python, I wanted to assess the strengths and weaknesses of Python in relation to Ruby. Perhaps some of the lessons could be applied when writing Ruby, and it could help to decide when to use each. Also, I’m interested in programming language design, and wanted to document pros and cons in that light.
+Where Python Sucks (As Compared to Ruby)
++
Web Development, Ruby on Rails, Open Source
+It’s challenging to test Rails custom validators.
+I recently had to write a validator to require that an entered date is before or after a specified date.
+It didn’t seem like writing the validator would be too difficult – I’ve written custom validators before, and date comparisons aren’t all that tricky. But when it came time to write the tests, I ran into several issues. And since I always try to follow TDD / test-first, I was blocked before I even began.
+The biggest issue was the ActiveModel::EachValidator#validates_each API. It’s definitely not a well-designed API. You write your validator as a subclass, overriding validates_each. The method takes a model object, the name of the attribute of the model being tested, and the value of that attribute. You can also get the options passed to the custom validator via the options method. To perform a validation, you have to update the model’s errors hash.
The big flaw in the API is that instead of returning a result, you have to update the model. This needlessly couples the model and the validator. And it violates the Single Responsibility Principle — it has to determine validity of the field, and it has to update the errors hash of the model. This is not conducive to testing. Testing this method requires testing that the side-effect has taken place in the collaborator (model), which means it’s not really a unit test any more.
So to make it easier to unit test the validator, I broke the coupling by breaking it into 2 pieces, one for each responsibility. I moved the responsibility for determining validity to a separate method, which I called errors_for. It returns a hash of the errors found. This simplified the validates_each method to simply take the result of errors_for and update the errors hash of the model:
def validate_each(record, attribute_name, attribute_value) + record.errors[attribute_name].concat(errors_for(attribute_value, options)) +end+
This made it much easier to unit test the errors_for method. This method doesn’t even need to know about the model — only about the value of the attribute we’re trying to validate. We simply pass in the attribute’s value and the options.
So we could write the tests without even pulling in ActiveRecord or any models:
+describe DateValidator do
+ let(:validator) { DateValidator.new(attributes: :attribute_name) }
+ let(:errors) { validator.errors_for(attribute_value, validation_options) }
+
+ describe 'when attribute value is NOT a valid date' do
+ let(:attribute_value) { 'not a valid date' }
+ it { errors.must_include 'is not a valid date' }
+ end
+
+ describe 'when attribute value IS a valid date' do
+ let(:attribute_value) { Date.parse('2013-12-11') }
+ it { errors.must_be :empty? }
+ end
+end
+And the errors_for method looked something like this:
def errors_for(attribute_value, options) + unless attribute_value.is_a?(Date) + return [options.fetch(:message, "is not a valid date")] + end + [] +end+
Integration testing can also be a bit of a challenge. I recommend following the example from this Stack Overflow answer. Basically, create a minimal model object that contains the field and the validation. Then test that the model behaves like you expect with different values and validations.
+Web Development, Ruby on Rails, Open Source
+I’m surprised that I haven’t gotten this story down in print before. It’s something I’ve mentioned many times — including a few times on the podcast. It’s a great story about the power of retrospectives, and it’s a great story about the power of a blameless post-mortem.
+I don’t recall all the specifics at this point. It was about 5 years ago. I’d just noticed that Arun had made some sort of mistake. That’s fine, people make mistakes. The thing that was different about his mistake was that I had made the same mistake about a week prior. And Amos had made the same mistake about a week before that.
+Noticing a pattern of mistakes, Amos and I called an impromptu retrospective. We gathered all the developers into a conference room. We explained the problem that we were running into. At first, Arun was defensive. That’s understandable; he thought we were there to come down on him, to lay blame. But we made it clear that we weren’t focusing on him. We admitted that we had also made the same mistake recently. We weren’t there to lay blame; we were there to figure out how our team could stop making the mistake. It took Arun a few minutes to get over the defensiveness.
+With the defensiveness out of the way, we could focus on the issue at hand. We were able to figure out the root cause of us all making the mistake. (I don’t know if we played the “5 whys” game, but I’m sure we effectively did something similar.) And with that, we were able to change our process, so that nobody else would make the same mistake again.
+There are 2 important points to this story. First, you don’t have to wait until a scheduled retrospective to hold a retrospective. This one was impromptu, and it’s the best one we ever had. We saw a problem, addressed it, and found a solution in less than an hour. Had we waited until the end of the week, we would have forgotten some of the details, and wouldn’t have been as effective at solving the problem. Second, when addressing problems, take your ego out of the equation. If you’re in a position of authority, take the blame — but never place blame. Focus on what’s important — solving the problem.
+And don’t forget the Retrospective Prime Directive:
++Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
+
I’m a big proponent of Agile (mostly XP; I’m mostly anti-Scrum) and I’ve contributed some to the #noestimates “movement”.
+I don’t really mean that nobody should ever estimate anything. I mean that I’ve never seen useful (fine-grained) estimates anywhere. Here are some of the problems with estimates that I’ve seen frequently:
+I’ll note that most of these pit management against the team, instead of working together toward a common cause. Most of the practices also lead to seriously demoralizing the team. And most of the time, the estimates aren’t really even taken into account very much.
+My advice is to first understand the value of a project before you consider estimating the costs. The estimation at this point will be very rough, so make sure that you have a very wide margin between the expected value and the rough estimate of the cost. If you’re pretty certain of the expected value, I’d probably want to make sure I could still be profitable even if it took 3 or 4 times as long to complete as the rough estimate. And if there’s uncertainty in the expected value, much more.
+Another way to mitigate the risk of throwing money at something that’s not going to have positive ROI is to reduce the feedback loop. Order the work so that the tasks are ranked in order of value to the customer. (Realistically, you’ll have dependencies of tasks to worry about, and should consider effort involved too.) So work on the most valuable feature first — get that out into production as soon as possible. Once that’s done, you can assess if your ROI is positive or not. Keep iterating in this fashion, working on the features that will provide the most value first. Keep assessing your ROI, and stop when the ROI is no longer worth it, compared to other projects the team could be working on.
+At a fine-grained level, if you’re using story points, I’d ask you to do the math to see if just counting the stories would be as effective at predicting how much will be done over time as using the story points. If so, you can save the time the team spends on estimating stories. I’d still recommend spending time talking about stories so that everyone has a shared understanding of what needs to be done, and to break stories up into a smaller, more manageable size — with one acceptance criteria per story. Also take a look to see if empirical average cycle time (how long it takes a single story to move from start to finish) might provide you the predictive power just as well as estimates. (I.e. is it bandwidth or latency that really provides the predictive power you’re looking for?)
+And don’t forget Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.
+While creating a web page isn’t too difficult, there are a lot of moving parts involved in creating an effective website. We’ve written up this checklist as a guide for anyone who has decided that they need a website.
+This list is for a basic static website. A web application will require significantly more effort. We’re working on a separate checklist for web apps.
+You’ll probably want your own domain name.
+You’ll need to have someone take care of the servers that tell the world what server addresses your domain name corresponds to.
+You’ll need servers to host your web site on. There are a lot of options available, from virtual hosts (a Linux server where you control everything) to application-specific services.
+Designing and developing the site can vary from picking an existing template and adding content, to developing a full web application.
+What other services do you need, besides just the web site?
+Over the lifetime of the site, you’ll likely pay more in maintenance costs than the upfront costs.
++
It all started with an email about a WebInspect report. It listed a buffer overflow, which we had marked as a false positive. I read the WebInspect report carefully, and found a note at the bottom that said you could test manually to confirm whether it was a false positive or not. Unfortunately, the manual test listed had a few problems. First, it jammed the lines together, without the proper line-breaks. Second, it assumed the site was using HTTP, not HTTPS, so used telnet. Third, it was testing against a page that didn’t exist, giving a 404. Keeping those in mind, I tried the manual test using the openssl s_client command:
openssl s_client -quiet -connect mysite.example.com:443 +POST /login HTTP/1.1 +Host: mysite.example.com +Transfer-Encoding: chunked + +c00000000+
The test terminated immediately. The report said that this meant that the server was vulnerable to a buffer overflow and arbitrary code execution.
+At first, we thought this was caused by Apache or Tomcat, or possibly the application code. But the reported vulnerability was an Apache CVE from 2002 (CVE-2002-0392), fixed by vendors long ago. After a while, we realized that if we hit the servers directly, we did not get the indication of a vulnerability. If we hit the site through the F5 VIP, we saw the immediate termination of the connection. The issue is with handling of HTTP chunked encoding. Nginx had a similar issue in 2013 (CVE-2013-2028).
+So we turned our attention to the F5 load balancers. We were able to confirm that other sites using F5 load balancers were exhibiting the same behavior. We also confirmed that WebInspect run against the servers directly did not show the issue (even as a false positive). We reported the issue to F5, and they are looking into it.
+I’m disclosing this publicly now for a few reasons. First, I’m not a security researcher, and almost nobody follows my blog — especially people looking for security issues that could be exploited. Second, I’ve not developed a payload, so I have no idea whether this is exploitable. But at this point, it’s merely a potential vulnerability. I’m not sure I’ll even spend the time to research and create a payload to prove the vulnerability. If I do, I’ll be more careful with the disclosure.
++
I’ve been working on application architectures based on Uncle Bob’s Ruby Midwest talk, following the hexagonal architectural pattern. I posted an article a couple months ago showing a way that works fairly well in Rails, and some accompanying Rails example code. But there was one thing I wasn’t quite happy with.
+The problem is that we used callbacks (actually, a publish/subscribe mechanism) in a situation where they don’t seem to quite fit:
+ def show
+ interactor.on(:display) { |order| render order }
+ interactor.on(:not_found) { |order_id| render status: 404 }
+ interactor.get(params[:id])
+ end
+What we really want is to respond in different ways, depending on the result of the call to interactor.get(). There’s no good reason to define the responses before the call. It makes a lot more sense to define the responses after the call, because they’ll happen after the call. I’d much prefer that the code be written in the order that it will be run.
I discussed this problem with my friend and colleague, Amos King. We came up with a better solution, which puts things back in the right order:
+ def show
+ interactor.get(params[:id]) do |on|
+ on.display { |order| render order }
+ on.not_found { |order_id| render status: 404 }
+ end
+ end
+He even wrote a small library to do this, which he called Riposte. I’m not sure what to call this pattern, but it seems to work pretty well in this situation. I suppose that they’re still technically callbacks, because they’re passed in in the block that’s passed in to the call to interactor.get(). But due to the magic of Ruby blocks, we get to put them in the order they should be.
Riposte also gives you the option of using the response object directly, instead of passing a block:
+ def show
+ on = interactor.get(params[:id])
+ on.display { |order| render order }
+ on.not_found { |order_id| render status: 404 }
+ end
+This shows that it’s just returning an object, with the twist that the response object has methods that take blocks. The nested blocks variant is really the same thing, except that it’s yielding to the response object instead of returning it.
+I’ve decide that is the pattern I’d like to use for interactions and their callers within Ruby hexagonal architecture.
+I’ve started working on my own framework in Ruby in the past couple days. It’s built upon my recent work at understanding Uncle Bob’s Ruby Midwest 2011 talk, and his article on Clean Architecture, and the resulting hexagonal architecture (AKA ports and adapters).
+Somehow my research in that vein led me to Gary Bernhardt’s Boundaries talk. I’ve read a lot about the talk, and knew about the idea of “functional core / imperative shell”. And I’ve worked with a lot of similar ideas lately. But I believe this is the first time that I actually watched the whole video.
+Even after having read a lot about similar ideas, it was pretty mind-expanding. Gary’s really good at presenting these kinds of ideas in a simple way.
+OOP as usually taught includes encapsulation of data together with behavior, with mutable objects. Functional programming separates data and behavior, with mostly immutable data. From experience, encapsulating data and behavior together seems helpful. But experience also shows that immutability is useful. So it would be good to have both of those together. This is something I’ve been thinking for a few years — how best do we get both?
+Gary calls the combination “FauxO”. Logic and data are still combined, but there’s no mutation. Anywhere OOP would normally have mutation would just generate a new object. There’s no language restriction involved in enforcing immutability — just discipline.
+But without mutability, it’s hard to do IO and maintain state. So Gary’s solution is to encapsulate as much as possible into an immutable (functional or FauxO) core, and around that, use an imperative (traditional OOP) shell. The functional core contains the bulk of the logic, and the imperative shell is a glue layer that handles the real world, including disk, network, and other I/O.
+The result of this is that the shell has fewer paths, but more dependencies. The core contains no dependencies, but encapsulates the different logic paths. So we’re encapsulating dependencies on one side, and business logic on the other side. Or put another way, the way to figure out the separation is by doing as much as you can without mutation, and then encapsulating the mutation separately.
+I love how this naturally breaks things up, so that the core is all testable with unit tests, and the imperative shell is tested with integration tests. And since the shell has few or no logic paths, you get the testing pyramid, with more unit tests and fewer integration tests. The whole thing ends up being quite beautiful. Tests end up being very fast without any extra effort — not even stubbing or mocking. This tells us that things have been decomposed very well — an elegant design.
+Gary makes the case that immutable objects can be treated as values, and passed across boundaries. Even process boundaries. This is something I’ve noticed as I’ve been working on my own Uncle Bob style hexagonal framework, but nobody in that camp ever mentioned that — they prefer DTOs or something more like hashes. I’m completely against hashes, because of the “stringly-typed” problem. And I don’t see much advantage in a DTO if I’ve got an immutable object; I’d be basically copying the object to an almost identical object. And I’d be losing any laziness possible for derived values within the original immutable object.
+It’s striking to me how Gary’s image of an imperative shell around a functional core, plus Net, Disk, and State outside of the shell mirror’s Uncle Bob’s concentric circles. Uncle Bob has entities in the middle, surrounded by use cases, surrounded by Web, DB, and UI.
+Another advantage that Gary shows is that breaking things up this way allows easy concurrency. In his example, he shows using the actor model — either just using threads and queues, or an actor library (or language feature).
+After several years of thinking about the architectural issues seen in most large Rails apps, I’m starting to come to an understanding of how to combine all these ideas and come up with an architecture that will work better.
++
The Agile Manifesto was written in 2001, as a way to explain the common values amongst several “light-weight” software development methodologies that had come about. The term “Agile” was chosen as a shorthand for those commonalities.
+Once “Agile” started to show success, we started to see many people use the term to market their products and services, whether or not they really believed in the values and principles of the Agile Manifesto. It’s gotten to the point where some of us don’t see much value in using the term “Agile” any more. Even some of those involved in creating the manifesto have suggested new terms. Dave Thomas suggests “Agility” and Andy Hunt has started working on something called GROWS. Personally, I’m considering going back to the term “Extreme Programming”, even though I’ve incorporated ideas from other Agile methodologies.
+It recently occurred to me that Agile, when done “right”, is closely aligned with the happiness of the team members. This is really interesting, because it aligns the interests of the employees and the business — a win-win situation. My next thought was that maybe the next step after “Agile” will be a focus on happiness and motivation.
+I’ve recently been thinking about personal motivation lately, in the context of team practices. According to Daniel Pink’s book Drive, people are motivated by autonomy, mastery, and purpose. I personally add a fourth that can sometimes trump the other three: identity. And of course, happiness can also be motivating — both in the attempt to achieve happiness and in just being happy. (I suspect that happiness is more of a parallel to motivation than a cause though.)
+There are a couple different ways that happiness can be achieved at work. The traditional way is for work to be a means to an end. In this view, the purpose of your job is to provide the money to live your life (outside of work) the way that you want to live it. There’s nothing wrong with this way of thinking. But for the lucky few, we can work on something that makes us happy in and of itself. That’s generally done by finding a job doing something that we enjoy.
+But perhaps that’s thinking about things the wrong way. For one, plenty of people who have gone that route are still unhappy at work. I think a lot of that has to do more with the context surrounding the work than the work itself. Maybe you’ve got a lousy manager. Maybe you don’t like the people you work with. Maybe the tools you have to work with are bad. Maybe the processes add a lot of unnecessary tedium.
+So maybe we need to find ways to be happier at work. Most of the Agile practices seem to make team members happy. For example, replacing a light-weight process for a heavier process always makes me happy. And I typically leave retrospectives in a good mood. So that’s a good starting point. But we should see if we can take the idea further. If we take employee happiness as a core value, where can we go? What kind of practices would we want to add? Please share any ideas in the comments below.
+On a recent episode (78) of This Agile Life, my fellow hosts talked about when to do Test-Driven Development (TDD). They all said that you should always do TDD — at least for anything that will go into production; there’s an exception for experimenting or “spiking”.
+I wasn’t on that episode, but later commented on the topic. (Episode 83 — which wasn’t really all that great.) My take was slightly different. I said that you should do TDD only when the benefits outweigh the costs. Unfortunately, we usually greatly underestimate the benefits. And the costs often seem high at first, because it takes some time to get good at writing automated tests. Not to mention that both the costs and the benefits are usually hard to measure.
+What is the cost of writing automated tests? I’ve asked this question before and recorded the answers (inasmuch as we have them) in a previous blog entry. TDD costs us about 10-30% in short-term productivity. The benefit that they found was a reduction in bugs by 30-90%, and a decrease in code complexity by about 30%.
+But what about when the costs are higher than the normal 10 to 30 percent? One good example of this is when there’s no test framework for the situation you’re testing. This might be a new language or framework that you’re working with. More likely it’s a complex API that you have to mock out. So that could increase the cost of automated testing so as to outweigh the benefits — especially on a short project. I could imagine situations where the cost of writing the mocks could eat up more than the project itself.
+Another case where we might consider skipping testing is when we’re more concerned about time to market than quality. This is almost always a mistake. Your code will almost always last longer than you expect. (Remember Y2K?) And if the code lasts longer than you expect, that means you’ll have to deal with bugs that whole time. But we have to work with the information we have at the time we make our decisions. And sometimes that might tell us that time to market is more important than anything.
+One final case I can imagine is when a true expert is coding something that they’re very familiar with. I could picture someone like Uncle Bob writing code (in a language that he’s familiar with) without tests just as effectively as I could write code with tests.
+But these situations should not be common; they’re edge cases. In almost all real-world cases, TDD is the right thing to do. Don’t forget, TDD is also a design discipline — it helps you design a better API. So keep doing TDD. But as with any practice, don’t do it blindly without considering why we’re doing it. Make sure you understand the costs, and whether the benefits outweigh the costs.
+I ran into some former colleagues recently, from a company where I had worked to help transform the team to be more Agile. They’ve gone through some reorganization and management changes recently. One of the guys said that their team culture has helped them maintain quality in the face of those changes. This struck me as odd, since I had considered the work I had done there as somewhat of a disappointment. While I felt I had made a small dent, I didn’t feel like I’d made a true Agile transformation. Much of what I had taught didn’t seem to “stick”.
+Later that night I thought about why my opinion of the team and his opinion were so different. There are a lot of reasons why an Agile “transformation” could fail. It could be due to lack of support from management. Or even worse, not getting the team members to buy into the ideas — usually due to fear of change. But while those had some effect in this case, they weren’t really the main issues. Now that I’ve had some time and some distance from that team, I’ve gained some clarity on what the real issues were.
+I think the reason that I think this transformation was a failure was due to the continued pace of change that true Agile requires. Basically the team experienced “change fatigue”, where everything keeps changing and you feel like you can never catch your breath. But the more interesting thing is how our perceptions differed. He seemed to think that the transformation was a success — they’re doing things better than they used to. I view it as more of a failure, because they basically stopped improving — at least at the pace that I was hoping for.
+I think this difference in mindset is pretty fundamental. My view of Agile involves continuous improvement — always inspecting and adapting our processes. I suppose that means that my preferred flavor of Agile is “Kaizen“. But other people don’t see improvement and change as a constant — they see each change as a means to an end. I’m starting to realize that neither viewpoint is objectively correct. Maybe they’re both fine viewpoints to have. Maybe I shouldn’t be so hard on myself and view that engagement as a failure, especially if my teammates view it as a success. Maybe perfection is the enemy of the good. And maybe I need to learn to be happy with “good enough”.
++
I frequently participate in a podcast called This Agile Life. Recently, a listener asked how much time Agile teams should spend on self improvement. I said 10% to 25%, leaning towards 15% to 20% for most teams. That comes to at least one hour per day, and maybe even more than one day per week.
+I’m including personal self improvement and team retrospectives in this self-improvement time. This can be as simple as configuring your IDE to make you more efficient, learning to use a tool better, or following up on action items from a retro.
+That may seem like a lot of time “wasted”. But I think I can justify the cost of all that time.
+The purpose of spending time on team or self-improvement — the whole point — is to increase our performance and our efficiency. How much improvement can we expect? Can we improve by 1% each week? That doesn’t sound too unreasonable. I think that’s an achievable goal for almost any team, at least on average.
+Spending 20% of your time to gain 1% doesn’t seem like it’s worth it — until you consider the long term. With compound interest, you’ll be 67% more efficient by the end of a year.1 At that point, you’ll be able to get things done in 59% of the time — saving 41% of the time required at the beginning of the year.2 The following years will show even more progress, as compared to when you started. If 10x programmers exist, continuous improvement is apparently the way to get there.
+So there’s a pretty good return on investment, even with a small amount of improvement each week. You’ll be significantly more efficient.
+But efficiency isn’t really what you should aim for. You should aim for effectiveness. You can be efficient in creating the wrong thing. Part of improving should be ensuring that you’re not just building things right, but that you’re building the right things. Build what the customer really needs. Find ways to ask the right questions.
+Most importantly, find ways to keep improving. It would be a waste of time not to.
+ +Web Development, Ruby on Rails, Open Source
+I’ve had a long love-hate relationship with Rails. I love the MVC framework and how it’s improved our speed of writing web apps. But I’ve never really been completely happy with it. I don’t generally agree with most of its opinions. I prefer models that follow the Data Mapper pattern, not the Active Record pattern. This includes separating the persistence layer from the models’ business logic. I prefer Slim or HAML to ERB. I prefer RSpec to Test::Unit or MiniTest. When Merb hit the scene, I was ready to make the jump, until Merb merged with Rails.
+So inspired by PJ Hagerty’s recent article on alternative Ruby web frameworks, I started thinking about how I’d write a replacement for Rails. I’d definitely keep the basic MVC framework. But I’d also want to implement a more hexagonal architecture.
+I started sketching out what this would look like, but I ended up starting with a Rails controller and finding the simplest way to make it hexagonal. I really don’t like callbacks, because they make tracing program execution difficult. But I didn’t see any other alternative. I found a simple pub/sub Ruby library called Wisper. It literally has only publish, subscribe, and on methods. (You use on to register single callbacks via blocks, and subscribe to register an object with method names corresponding to the callback names.)
The trick was figuring out how to break the controller into 2 pieces. What finally helped me was to find the single responsibilities of the 2 pieces. The Rails controller would remain in charge of managing the web interface, but would delegate to the other piece to handle any application-specific business logic. I decided to re-watch Uncle Bob Martin’s “Architecture The Lost Years” talk, which was the first time I was introduced to the ideas of Hexagonal Architecture. (He doesn’t name the architecture in the talk, but later calls it Clean Architecture.) He does a decent job of explaining how to break these 2 pieces apart. He used the term “interactor” in that talk, so I decided to go with that. He said that Jacobsen calls it a Control Object in Object Oriented Software Engineering, but that’s too close to Rails’s “controller”.
+So here’s an example of what I ended up with:
+class OrderController < ApplicationController
+ def index
+ interactor.on(:display) { |orders| render orders }
+ interactor.list
+ end
+
+ def show
+ interactor.on(:display) { |order| render order }
+ interactor.on(:not_found) { |order_id| render status: 404 }
+ interactor.get(params[:id])
+ end
+
+private
+
+ def interactor
+ @interactor ||= OrderInteractor.new
+ end
+end
+require "wisper" +require "order" + +class OrderInteractor + include Wisper.publisher + + def list + orders = Order.all + publish(:display, orders) + end + + def get(id) + order = Order.find(id) + publish(:display, order) + rescue ActiveRecord::RecordNotFound + publish(:not_found, id) + end +end+
I do have a few problems with this solution though. I’m not a fan of the name “interactor” for the business logic. I thought about calling it OrderOperator, or maybe OrderOperations, because it’s really a collection of operations. Perhaps it would be better to separate each operation into a separate class. Trailblazer does it that way. And for more complicated business logic, I would do that too, using the Method Object pattern. But like a Rails controller, there’s a lot in common among all the operations. I feel like a separate class for each operation for each would create too many coupled classes.
I’m also uncomfortable with the fact that the controller is delegating almost everything to the interactor. I guess this is OK, but it feels like there’s too little left when every line starts with interactor. I suppose extracting things some more would help mitigate this concern I’ll likely write a small gem to perform that extraction. I expect that that will allow a typical controller to be written in only a few lines. And maybe the same for the interactor side.
With the business logic extracted out of the controller, it was really easy for me to write a command-line version of the app. As Uncle Bob says, “the web is not particularly important to your application.”
+I’ve put the code for this example on GitHub: https://github.com/boochtek/hexagonal-rails. I’ll likely experiment with it some more over the next few weeks and months.
+January kept me pretty busy, so I’m a little late to this. But better late than never. And as an Agile practitioner, I don’t think personal retrospectives should be limited to one time of year.
+Last year I wrote a blog entry listing my goals for 2014. As far as New Year’s resolutions go, I was relatively successful — about 50% of my goals accomplished. Unfortunately, my Open Source contributions weren’t as strong as I had hoped; while I released some of my own work, I didn’t do much else. I did increase my blogging; getting in on a weekly blogging pact helped immensely. I also increased my participation on the This Agile Life podcast to a level that I’m happy with. But the accomplishment I’m most proud of was giving a presentation at RubyConf.
+I’d like to keep things rolling from last year, but crank up a few things. My plans are quite ambitious, so I don’t expect to get everything done by any means. But I think by setting the bar high, I’ll end up with a lot I can be proud of.
+Late last year, I took the jump into independent consulting. So far, I’ve really enjoyed it, and I’m booked up through April. My wife graduates in May, so we’ve got the possibility of moving if that makes sense. So I’ll be looking for consulting projects in town, but I’ll also be looking at jobs in San Francisco and Chicago. The possibilities are exciting, and I’ll be taking my time to find something just right.
+I was incredibly nervous leading up to my RubyConf presentation. Part of that was just the common fear of public speaking. For me, that only kicks in at around 100 people, and this audience was around 250. I think another reason was that I chose a really ambitious topic, and I kept finding more that I wanted to talk about, but wasn’t prepared for. But I think I did a pretty good job presenting an advanced topic. And I was so pumped by the sense of accomplishment as soon as I finished. So I’m hoping to do it more. I’ve already submitted a couple proposals, and plan to submit several more.
+I believe that blogging is important for me to get my thoughts down — for myself and to share with others. I was really successful last year when I had a partner to keep me honest, via a pact. So I’ve started up another pact this year, which will hopefully ensure I’ll keep things going. I’ve got a really long backlog of topics, so as long as I keep at it, I’ll have plenty to write about.
+I also want to move away from WordPress to a static system — probably Middleman. I’ve got 2 major problems with WordPress. First, I no longer trust its security, nor the security of any application written in PHP. Second, it generates HTML every time someone requests a page, instead of when the content is updated. I find that to be a waste of resources, and problematic from a security standpoint. The main problem with moving to a static blogging system is that I really want to allow comments, pingbacks, and tweetbacks. So I’ll have to find a way to integrate those.
+Last year I started thinking about programming language design, and started implementing a language tentatively called Brilliant. I’ve done a lot more thinking on the topic, and have a lot of notes. But I haven’t implemented much more yet. This year, I’d like to get my thoughts more organized, and write a series of blog posts on various aspects of language design. The most interesting part seems to be the trade-offs involved in the ways that various language features interact. So I’d like to make some progress on the language implementation, but more importantly, I’d like to get a lot of my design ideas written down.
+I’m also going to spend a lot of time learning a bunch more programming languages, so I have a better understanding of possible features, combinations of features, and their interactions. I’ve already start with Elixir, Clojure, and Racket. I’m hoping to also look at OCaml, Factor, and Haskell. I’ll probably also take a look at the 2 “Seven Languages in Seven Weeks” books.
+I think people often have trouble getting started with Agile. I started on a book last year, and got down quite a lot of good ideas. But I realized that I’m going to have a hard time organizing all those ideas into something coherent. Still, I’d like to try to get something out there that lets people get started with Agile. My idea is to present a toolbox of practices to get started with and build on that foundation over time with additional practices. Sort of a playbook on how to get started over the first 6 to 12 months and be successful. I want to make some progress on the book, at least enough to decide whether it’s worth the effort to finish it and self-publish it.
++
I went to RailsConf this year, and the very first talk was a keynote by David Heinemeier Hansson (DHH), the creator of Ruby on Rails. The TL;DR of his talk was “TDD rarely has value”. He followed up with a blog post the next day, titled “TDD is dead. Long live testing.“, and 2 more posts. I think this line of thought is terribly misguided, and causing more harm than good. This article is my response.
+First, I would like to address the good points of the talk. He said that programming is pseudoscience, and that people want to tell us that there’s a secret to being a better programmer. But what it really takes is working hard — reading a lot of code, writing a lot of code, and rewriting a lot of code. He’s right. And I also agree with him that you should forget about patterns for a while when learning to code. Beginners try to throw patterns at a problem instead of letting the patterns emerge where they’re supposed to.
+I don’t completely agree that programming is a pseudoscience. In some ways it is, but I think it’s more of a craft. It’s a craft, because there’s a lot of science involved, but there’s also an art to doing it well. And like any craft, you’re always working to get better. So to respond to DHH’s stance that “software is more like poetry than physics”, I think it falls
+somewhere in between.
With regard to the software engineering practices we use, there really isn’t much science available, mostly because it’s a soft science. That is, it’s really hard to isolate a single variable when comparing code between projects. And nobody has the time or money to write the same code so many times that the differences would be statistically significant.
+So we don’t have much science on TDD. But we do have some. Here’s a collection of several: StudiesOfTestDrivenDevelopment. And here’s one that explicitly looks are the difference between test-first and test-last: Does Test-Driven Development Really Improve Software Design Quality? What do these tell us? They tell us that TDD costs us about 10-30% in short-term productivity; reduces bugs by 30-90%, and decreases code complexity by about 30%. As Code Complete tells us (in section 20.5, with studies to back it up), improving quality reduces development costs. So, like most Agile practices, this is a case where spending a bit more time in the short term leads to time savings in the long term.
+The more important lesson in the talk was that you have to do what works best for you and your situation. If TDD doesn’t give better results, then either find out how to make it give better results, or stop using it. As we often say in the Agile world, Agile doesn’t mean that you can stop using your brain. While I think TDD is appropriate in most situations, there are cases where it’s not worth the additional up-front cost. If the most important thing for your project is time-to-market, then not testing might be the right decision for you.
+To me, TDD provides a bunch of benefits. First and foremost, TDD is a design discipline. It ensures that I think about how my code will be used before I think about how to implement it. This is very powerful in ensuring that the code is well-written from the perspective of other code using it.
+Tested code provides confidence to be able to make changes without breaking things. If we write tests after the code, we’re less likely to write them. Tests written after the code also tend to test the implementation instead of the desired functionality. What we really want is tests written as a specification. With tests as a specification, we can come back later and understand why code was written. Without tests, or with poor tests, we can’t understand why the code is there; if we want to rewrite it, we don’t have the confidence that we’re not missing something. Writing tests first also ensures that we only write the code that is needed to implement the required functionality.
+I’m not sure why DHH hasn’t “gotten” TDD. I’m not sure if it’s because he’s a better coder than average, or if he just thinks in a different way than most of us. I think it’s partly because he doesn’t understand TDD, which he admitted might be the case. And I think he’s conflating TDD and unit testing.
+DHH is influential in the developer community, especially those newer to Ruby and Rails. People listen to what he has to say. I was happy to see almost every other speaker made fun of DHH’s ideas, and most of the crowd knew better. But there will be a lot of others who will hear DHH, respect his opinions, and not give TDD the try that it deserves. And that’s sad, because it will lead to an overall reduction in code quality in the world.
+Here are some other people’s thoughts on the matter:
++
I’ve run across a pattern in Ruby lately that I really like. It solves some problems that I’ve struggled with for several years. Let me start with the problems.
+Let’s say you want to include an ORM in a model class, and want to tell it what database table to use. Typically, you’d do this:
+class User + include MyORM::Model + table 'people' +end+
But that table call is more like an option to the module inclusion than anything else. So what we’d really like is something like this:
class User + include MyORM::Model, table: 'people' +end+
But that’s not valid Ruby; include doesn’t let you pass anything other than a module.
So when I was learning about Virtus, I noticed that its example of how to include it is a bit different than the standard Ruby idiomatic include:
class User + include Virtus.model +end+
At first glance, it reads like the first example. But on closer inspection and consideration, it’s quite a bit different. Where MyORM::Model is a constant that refers to a module, Virtus.model is a method call. So there’s a method named model in the Virtus module. That method returns another module — which is exactly what’s needed in order to include it into our model class.
The easiest way to implement Virtus.model would be this:
module Virtus + def model + ::Virtus::Model + end +end + +module Virtus::Model + # ... +end+
If Virtus.model doesn’t need to take any arguments, that’s perfectly fine. In fact, I’ve started to use this implementation of the pattern for modules that don’t need parameters.
Because Virtus.model is a method, we can also call it with options:
class User + include Virtus.model(constructor: false, mass_assignment: false) +end+
We could even pass a block. But how do we process those options? There are a few different ways. However we do it, we have to be sure to return a module. And we can create modules in a few different ways.
+Virtus uses the builder pattern. It takes the parameters passed in and builds a module dynamically. By that, I mean that it calls Module.new and then adds methods to that module. It does this by mixing in other modules, but it could do it by dynamically defining methods as well.
I’ve never seen this pattern in any other language. It’s obviously only possible because we can dynamically create modules.
+The use of this idiom seems to be catching on a bit in the Ruby community. I’ve started using it myself, and will be adding it to my Includable::ActiveRecord gem soon.
++
+
I’ve decided to design and implement my own programming language, and call it Brilliant.
+I’ve been interested in programming languages and linguistics almost as long as I’ve been using computers. I’ve long thought that if I ever go back to college, it’s likely that I’ll concentrate on programming languages as a specialty.
+My recent discovery and involvement with the Crystal programming language has gotten me excited about new language ideas. It’s also helped me realize that implementing a language myself is feasible, and that there’s no better time to start than now.
+For now, the Brilliant implementation doesn’t let you do much more than “Hello World”. But you gotta start somewhere. So this article isn’t really “Introducing Brilliant” so much as the start of a series of articles on its design and implementation.
+I wanted to use a PEG (parsing expression grammar) parser for several reasons. For one, they seem to have gained a lot of popularity in the past few years. Also, PEGs cannot be ambiguous, which can solve a few difficult problems, such as the “dangling else“. Perhaps my favorite feature of PEG grammars is that you don’t need a separate tokenizer (lexer). This provides a nice advantage in that we can use keywords like “class” as variables, as long as they’re not used in a place where the keyword would make sense.
So knowing that I wanted to use a PEG, I had to find a PEG parser. I kind of wanted to use ANTLR, which has been a leading parser for many years. But the PEG seems to be new to version 4, and I couldn’t find any Ruby bindings for version 4. Treetop seems to be the most popular parser for Ruby, but I found the EBNF format that Rattler uses to be more to my taste. I think the fact that it’s newer also gives it a few advantages, having had a chance to learn some lessons from Treetop.
+I thought about using the Rubinius VM, but decided to go with LLVM, mainly since it has slightly better docs for Ruby, and because it’s what Crystal uses. Also, it’s pretty easy to get it to compile to a binary executable or run in a JIT. In the future, I might consider switching to the Rubinius VM, the Erlang VM, or the Perl 6 VM (Parrot). But for now, I like the idea of being able to compile to a binary and easily interface with C, just like Crystal.
+My main goal is to have fun playing around with language ideas.
+I’ve found a really great language in Ruby, so I’ll be using it as a starting point. But Ruby does have its faults. In some ways, I want to answer the question “what would Ruby look like if we designed it today?”.
+But I also want to explore other ideas. What if objects defaulted to immutable? What if functions and methods were assumed to be pure by default? Might it be possible to infer the purity of a function or method? (If so, we could automatically memoize them.) Can we make creating an actor as easy as creating an object?
+I’ll also be looking at ideas from other programming languages. Could we get some of the benefits of Haskell’s purity without having to do somersaults to do IO? Could we mix Python’s indentation style scoping with brace style or begin/end style? Could we integrate Icon’s ideas about success and failure (goal-directed execution)? What interesting features can we pull from Ada, Io, CoffeeScript, Crystal, Rubinius, Perl 6, etc.?
+
I’m not so much as interested in cutting-edge features, as in features that can be easily used by the average programmer. More importantly, I’m interested in how features interact with each other, so they fit well together to create a whole that’s greater than the sum of the parts.
+I wanted to name my programming language “Fermat”. I’ve long been intrigued by Fermat’s Last Theorem, and Fermat’s Little Theorem is important in number theory. Unfortunately, there’s already a computer algebra system with that name.
+So I decided to find a name in the same vein as “Ruby” and “Crystal”. I looked at the Wikipedia page for “gemstones” for some inspiration. A lot of the names of gemstones are already taken. I considered some obscure gemstones, but saw the word “brilliant” and thought it was decent. It’s not the name of another gemstone, but still evokes some similarity to Ruby and Crystal.
+So that’s the name for now. Perhaps I’ll decide to change it at some point in the future, but I needed a name for the project, as well as a file extension for source code files. I chose “bril” for that. I suppose “br” would be a better choice. Perhaps I’ll change that before the next article in this series.
I hope to work on Brilliant every once in a while. I expect it’ll take a couple years before it’s really very useful.
+When I do add a major feature, I’ll be certain to blog about it. I’ve got tons of ideas strewn about in various files. It would be great to get them organized and published —and even better to get them implemented.
+I don’t believe that estimation should be part of any Agile practice.
+One of our managers recently mentioned that we hadn’t met the “contract” that we had “committed” to in our last iteration. This was complete nonsense, because A) we hadn’t made any such commitments, and B) we completed many more story points than the previous iterations (and without inflating story points).
+
But her language made me come to several realizations. First and foremost, estimates are contracts. Sure, they’re not supposed to be treated as commitments, but they almost always are. And what does the Agile Manifesto say about this? It says that we should value customer collaboration over contract negotiation, and responding to change over following a plan. So it’s pretty clear that treating estimates as commitments is completely counter to the Agile values.
+Why does this matter? What benefits do the Agile values bring us? I think the biggest benefit they bring is changing the way that we work, so that we can better deliver value to our customers. Without Agile, we’d just keep working the way we’ve always done things. And that didn’t seem to be working out so well. If we follow the Agile values and principles, at least we’ll have a fighting chance of improving our ability to deliver value.
+Ask yourself — have you ever seen a software development project that was on time and on budget? Where the estimates were spot-on? Of course not. For one, we’re terrible at estimating. For another, our plans change — either from external factors, or from what we learn as we go.
+To me, Agile is also about facing reality — and embracing it. It realizes that we’re terrible at estimating. It realizes that plans change. Most Agile methodologies have some tricks to counteract Hofstadter’s law. Generally, we use relative story points instead of hours, and then use an empirical factor to convert points to hours.
+When this works, it is better than any other estimation I’ve ever seen. But it doesn’t work very often. People have trouble with relative estimation. How do you set the basis for what a point means without relating it to actual hours? Affinity estimation could work, but then you have to remember what the basis was. We’ve got a large distributed team, and when we tried this, we couldn’t all remember what the basis was.
+Since we couldn’t get affinity estimation to work, we tried changing to perfect hours (only powers of 2). But then people thought of them as time. When we took longer than the estimate on an individual story, managers and team members thought we were taking longer than we should have. So our estimates ended up causing problems.
+Managers want estimates so that they can have predictability. They want to know when new features will be available. Is there a better way to get what we need?
+I believe there’s a better way — prioritization. If you work on the most important thing first, then the most important thing will get done first. We should always be working on the next most important thing.
+What if there’s more than 1 thing that’s most important? Then you’ve failed. You’ve failed at logic if you can’t understand that only 1 thing can be most important. You’ve failed at prioritizing the customers’ needs. You’ve failed at project management.
+1. Why can’t you just tell us how long it will really take?
+Because we don’t know. Because we can’t know. This is the first time we’ve ever implemented the functionality you’ve asked for. If we’d done it before, we’d just use that existing code. As Glenn Vanderburg pointed out in his excellent talk on Software Engineering, we’re not building software, we’re architecting it.
+2. But we have to tell our customers what to expect.
+Why? Is the product so bad that you can’t keep customers around without leading them on with future enhancements? And why do customers need exact dates? A general roadmap telling them what the priorities for upcoming features should be sufficient.
+3. But we have to have messaging about new features.
+OK. Then send out that messaging once the feature has made it to Staging. Or even after it’s been rolled out to Production.
+4. But we’ve promised these new features to the customers by this date.
+Ah, so you’ve made promises to the customer that you don’t have control over. Have you ever heard of “under-promise and over-deliver”? That’s how you create happy customers. Yet you’ve done just the opposite, haven’t you? And then you want to blame someone else.
+Risk
+Estimates are risk. But the risk doesn’t come at the end, when the estimates are shown to be incorrect. The risk was in asking for the estimates in the first place, and placing trust in them. Don’t do it. Don’t promise things that you can’t be sure of.
+Embrace this reality. Embrace this uncertainty. Always focus on what’s most important. That’s how you make customers happy.
+There’s a tweet that I saw recently, with some simple advice for novice programmers:
++Slow down.
This is probably good advice for most programmers. Our team recently noticed that every time we try to rush things, we make mistakes. And the mistakes end up costing us more time than if we had just done things at our normal pace. Slowing down ensures that you do things right, and when you do things right, you end up with a higher-quality product.
+There are 2 types of code quality: internal and external. External code quality can be measured by how many bugs have been reported by customers. Internal code quality is harder to measure, but it mainly deals with the ability to change the code. When your internal quality is low, you’ve got lots of technical debt, and it’s harder to make changes.
+So when you try to write code quickly, code quality decreases, leading to a code base that takes more time to make changes to. Conversely, when you slow down, your code quality improves, and it becomes easier to make changes more quickly. So when writing code, slowing down in the short run leads to a speed-up in the long run.
+But writing code isn’t the only place where we try to speed up. On an Agile team, we’re always trying to improve the way we work — especially at the beginning stages of an Agile transformation. So we’re eager to make changes in our processes. But I’d urge you to slow down here as well.
+My colleague Amos and I frequently argue over pair switching. It’s funny, because we agree on everything except for 1 small detail. We both think pair switching is very important, to ensure that team members see more of what’s going on, to bring more ideas to each story, to prevent knowledge silos, and to encourage team ownership. Where we disagree is how long an ideal pairing session should last. I think pairs should switch every 2 hours, and he thinks 1 hour is ideal. I’ve seen teams reach the 1 hour pairing sessions successfully. But usually not without some pain and even often failing at the first attempt.
+There’s nothing inherently wrong with failing. But if you fail at something, you’re not likely to try again. After all, you should learn from your failures, right?
+So if you want your team to do something, you probably don’t want them to fail at it. If they fail, they won’t want to try a second time. That’s just human nature, and learning from failure. While you might think that they failed because they weren’t ready for the change yet, they’ll most likely think that they failed because this particular change won’t work for their situation. And they probably won’t know what to change when trying again, so they won’t try again.
+I’ve seen this over and over. Back when Linux was up-and-coming, when a consultant pushed a company into using Linux before they were ready for it, and it didn’t work out, that company was cautious about trying again. So instead of being on the leading edge of using Linux, or even the middle of the pack, they ended up more toward the trailing edge. Had they not been pushed, they would have gotten more benefit in the long run.
+So my advice in process improvement is the same as in programming: slow down. Take small steps toward what you think is the ideal. Make a small change, see how it works out, and adjust. As long as you’re still moving in the right direction, I believe you’ll move faster by taking small steps than by trying to make big leaps.
+Most of us don’t write very readable shell scripts. There are plenty of things we could do better, but today I want to talk about one in particular — burying the lede.
+The term “burying the lede” comes from the field of journalism. Here’s the Wiktionary definition:
++To begin a story with details of secondary importance to the reader while postponing more essential points or facts.
Like a good news article, code should tell a story. And the story should start with what’s most important. In the case of code, the most important information is the high-level functionality — a succinct summary of what the program does. In other words, write (and organize) the code top-down, as opposed to bottom-up.
+Unfortunately, shell script doesn’t make this easy. Due to the way shell scripts are interpreted, you can’t call a function until after you’ve defined it. This leads to most of us structuring our code like this:
+function do_something { ... }
+function do_something_else { ... }
+
+do_something
+do_something_else
+The problem with this is that the function definitions will likely take quite a few lines, and we won’t see what the top-level functionality is until we reach the end of the script.
+I’d like to propose a standard way to structure shell scripts to mitigate this issue. (I’m really only talking about shell scripts that have function definitions within them.) I’m sure I’ve seen a few scripts do this, but it’s not very common at all.
+My proposal is simple:
+function main {
+ do_something
+ do_something_else
+}
+function do_something { ... }
+function do_something_else { ... }
+
+main
+This structure lets us start with the lede. We describe the top-level functionality right away. Only then do we get to the secondary details. The name main makes it pretty clear that it contains the top-level functionality.
I’ve recently started writing my shell code like this, and I’m happy with the results. I’ve also started to use some other programming techniques in my shell scripts to improve readability: better naming, extracting more methods, and moving helper methods into separate files. It feels good to treat shell scripts like real code instead of just some stuff I’ve hacked together.
+PS. The WordPress theme I’m currently using (Twenty Eleven) also buries the lede — I can barely even see the title of the blog post on my screen without scrolling. I’m going to have to change that soon.
+I recently decided to start using Emacs again. I used it extensively from the early 1990s until the early 2000s. I pretty much stopped using it when I had a sysadmin job with no Emacs on the servers, and no ability to install it. With the rising popularity of tmux and tmate for remote pairing, and my dislike for vim’s modes, I decided to try going back to Emacs in the terminal.
+One thing I really want in a text editor is good cursor key support. Shifted cursor keys
+should select text, and Control+left and right should move by words. (Apple HIG says to use Option+left and right to move by words; most apps on Mac OS X seem to support both.) Things have worked this way on almost every text editor on every OS I’ve used — Amiga, DOS, Windows, NeXT, Mac, Motif, Gnome, KDE. It’s a part of the CUA standard that’s been in common usage on everything since the mid-1980s.
Enabling cursor keys in Emacs was pretty easy. I’ve decided to use Prelude to make getting started with Emacs easy. Emacs comes with the cursor keys enabled, but Prelude disables them. Undoing Prelude’s change is pretty easy:
+(setq prelude-guru nil)+
Trying to make shifted cursor keys work is where the trouble began. They work in the GUI version of Emacs, but not from the terminal. It turns out that the Mac Terminal doesn’t distinguish between cursor keys and shifted cursor keys in its default configuration. So I had to figure out how to configure key bindings in Terminal.
+That’s easy enough — they’re in the preferences. But what should I set them to? This took a lot of research. Terminal emulation and ANSI code sequences are obscure, complex, and inconsistent. I eventually found the info I needed. For starters, Shift+Right, Shift+Left, Shift+Home, and Shift+End are defined in the terminfo. The rest I was able to piece together from various sources around the Internet.
+I’m also trying to script my Mac configuration. So instead of manually adding all the keybindings in the Terminal preferences pane, I decided to write a script. Mac OS X does a decent job of allowing you to change preferences from the command line. For example, to always show the tab bar:
+defaults write -app Terminal ShowTabBar 1+
Easy enough, except for a couple problems. First, I had to figure out the obscure syntax used in the preferences for key codes. I was able to piece these together with some more Internet research. But the really big problem is that the keyboard bindings are 2 levels deep within a “dictionary” (hash map). And the defaults command doesn’t handle that. There are some obscure utilities that handle nested preferences, but they don’t work well with the preferences caching in Mac OS X 10.9 — a problem I ran into while testing.
So now I’m writing a utility in Python that does what the defaults command does, but that will handle nested dictionaries.
There’s a term for this process of having to solve one issue before you can solve another, and the issues get several layers deep. It’s called yak shaving.
+Here’s another good example:
+
I’m sure this will be the first of many posts about me yak shaving.
+I’m considering buying a chording keyer. A keyer is a 1-handed text input device. Chording means that you can hit more than 1 key at a time. I’ve been interested in these for a long time actually. They’ve been popular in the wearable computing (“cyborg”) field, but never caught on anywhere else. I’ve always thought that 1-handed chording keyer would be a great input device to use with a cell phone. It’d be even better with a heads-up display like the Google Glass.
+There are quite a few chording keyers available. It doesn’t appear that any will meet exactly what I’m really looking for, but I might take the leap anyway. It should be a hand-held device. I really want a Bluetooth device, so I can use it with a computer, phone, or tablet. Below are the ones I’m considering.
+The Twiddler has been around quite a while, as probably the main commercially available keyer for wearable computing. There was a time that it was unavailable, but there’s a new version available from HandyKey now. It’s $200 ($220 Canadian), and comes in only USB.
+The Twiddler looks like a small TV remote. The current version (2.1) has 4 thumb keys, a thumb joystick (for mouse), and 12 small finger keys. It has good community support, including an alternate chord layout.
+In10did has been trying to bring out a few variations of their devices. The Decatxt looks like a pack of cigarettes, with 8 keys on the front and 2 thumb keys. It can be used with 1 or 2 hands. All letters can be typed with 1 finger or 1 thumb and 1 finger.
+The Decatxt has USB and Bluetooth models, but I’m unable to find pricing or a way to buy one. It looks like there have been no updates for over a year, so I’m concerned that this is going to be vaporware.
+The CyKey is based on the Microwriter, which goes back to the early 1980s. The Microwriter was a desktop-based device, but it looks like the CyKey might be able to be used as a hand-held device. It has 9 buttons on the face, arranged in 3 groups of 3 buttons.
+The CyKey is $125 (£75) and works over InfraRed connected to USB. A Bluetooth model is supposedly in the works.
+The EkaPad is like a cross between the Decatxt and the Twiddler. It has 12 buttons on the face, but no thumb keys. It’s got a nice well-thought-out design that looks quite ergonomic.
+The EkaPad is $150, available in USB only. A desktop holder is available to hold it upright, or it can be used hand-held.
+The FrogPad is meant to be used on a flat surface only. It looks kind of like a third of a laptop keyboard. It’s got 15 regular keys and 5 modifier keys. Only 1 key and 1 modifier can be chorded. Right-handed and left-handed models are available, with USB connectivity.
+The FrogPad2 was recently announced, replacing the original FrogPad. It switches to standard desktop-style keys, and adds some more keys along the top. It supports USB On-the-Go and Bluetooth. I’m not really interested in this model with its regular keys, but it doesn’t appear that the original version is being made any longer. The new models are priced at $200. I believe the old models were $150.
+The Chordite looks the most promising, but it’s only a concept with some DIY prototypes. It’s a hand-held device, with 2 buttons on each of the 4 fingers — one activated by the distal phalanx and the other by the middle phalanx. This initially sounds like it would be difficult to press 2 different buttons with 1 finger, but I think the way they’re positioned would make it actually work really well.
+The septambic keyer is another DIY concept, hand-built and used by wearable computing folks. It’s fitted to your palm, and you squeeze your fingers toward a fist to activate the buttons. There’s one button for each of the 4 fingers, and 3 for the thumb.
+The Clove 2 is a Bluetooth-enabled glove with 5 buttons — 1 for each finger. It’s another do-it-yourself project.
+I found an interesting project called ASETNIOP that allows chording on a standard Qwerty keyboard. (Assuming the keyboard supports multi-key roll-over well enough. Most keyboards should work.) It’s got a really nice online interactive tutorial. You basically chord with the 8 home-row keys, plus the spacebar.
+For Android, a program called GKOS for Android uses multi-touch with 1 or 2 button presses. The buttons are different sizes, depending on their frequency. I like this concept, but I don’t think the implementation is quite ready for production.
+I also found an app for iOS called Nintype that is a combination between Swype and a chording keyer.
+I think I’m going to try the Twiddler. If I find the concept to be a good one, hopefully I’ll build myself a Chordite (or have someone build one for me).
+I’m also going to play with implementing some of the ideas from ASETNIOP, using KeyRemap4MacBook.
+Web Development, Ruby on Rails, Open Source
+I facilitated our team retrospective this morning. I felt like we made a little forward progress, but not as much as I would have liked. But it really brought one thing to the forefront of my thoughts today — empathy gained through communication.
+We have a pretty large team by Agile standards — we had 20 people in our retro: 16 developers, 3 QA folks, and 1 manager. Out of those, only about 5 or 6 speak up regularly. I recently sent out a survey to the team, trying to get feedback on how we could improve our retros. A couple of the questions tried to get a feel for why people aren’t speaking up more. Only about half the people responded, and the answers didn’t really answer my question as well as I had hoped.
+So on Amos‘s suggestion, we did the Safety Check exercise. We got a good set of answers to why people don’t feel safe. About half of the answers were about the fear of looking stupid in front of other people. About half of those mentioned the manager — they’re worried they might get in trouble for what they say. We talked some about fear and how it’s more often than not misplaced. And that the worst consequences are usually not as bad as you might think. But then we got to the crux of the problem — there’s not enough trust amongst the team, and especially between the team members and the manager.
+About half of our team is new (within the past 6 months) — including the manager. While the developers have made some good progress building trust amongst each other, we haven’t had as much time with the manager to build trust between him and the rest of the team. So the lack of trust isn’t at all surprising.
+Honestly, I already knew we had trust issues, and wanted to address them, but needed a way to lead the team to that same realization. With this exercise driving out the issue, we were then able to have a conversation about trust. The conversation was pretty good. We got more voices to contribute than probably any other topic we’d previously covered. (I was disappointed that the manager kept quiet though. I later found that he was trying to mitigate people’s fears by keeping quiet, but I urged him to contribute more in the future.)
+But one point really stood out in my mind — a point of view that I hadn’t previously thought much about. Lauren, one of our QA analysts, pointed out that most human communication is non-verbal. We give tons of cues via body language, facial expressions, eye contact, tone of voice, even posture. I don’t recall if Lauren said it explicitly, but she pointed out that these cues build empathy between the speakers. She encouraged us to use more voice chat and video chat, as opposed to IRC text chat, because it would create more empathy between the people communicating, which would lead to more trust.
+I spent most of the rest of the day talking to people on the phone or via Google Hangouts voice. And every single time, I consciously noticed that I was gaining empathy for the person I was speaking with. I assume (and hope) that that’s working both ways. I suppose that it’s always been happening, but I never really noticed it.
+I’ve heard a lot of talk about empathy among Agile practitioners lately. It’s been mentioned on the Ruby Rogues podcast, and Angela Harms has been preaching it for years. I already understood how important it is. But until today, I didn’t really feel it happening.
+So if you’re looking to build trust with someone, spend some time talking with them. Preferably in person, but if that’s not possible, seriously consider video or voice modes of communication, instead of sending an email or an instant message.
++
I’m considering moving away from WordPress, for a couple reasons:
+Now that I’m starting to actually blog consistently, it makes sense to change. But before I move to something different, I want to be sure that I find all the features that I need. This post is my thought process about what I want.
+I’ve been playing with Jekyll lately, using it to generate a simple static site that can be updated easily. It’s pretty nice, and pretty easy to use. Something based on Jekyll would work well. The trickiest part will be figuring out how to manage comments. Or maybe I’ll just have to learn to live more minimally.
+Octopress is the obvious candidate. It fits most of my needs and wants. Most likely I’ll write my own commenting engine and add it to my Octopress template.
+The only other candidate that I’ve found is Ghost. It’s written in JavaScript and runs on Node. I don’t find Node to be that compelling, but the templates look great, and it’s designed for coding blogs.
+I’ll probably take a quick look at Droplets, too. It’s written in PHP, but seems to fit my other requirements.
+Unfortunately, that seems to be all there is in this space. Maybe I need to investigate more. Or maybe Octopress just has the static blog generation marked cornered. Either way, I’ll probably change my blogging software in the next month or two. Wish me luck!
++
It’s challenging to test Rails custom validators.
+I recently had to write a validator to require that an entered date is before or after a specified date.
+It didn’t seem like writing the validator would be too difficult – I’ve written custom validators before, and date comparisons aren’t all that tricky. But when it came time to write the tests, I ran into several issues. And since I always try to follow TDD / test-first, I was blocked before I even began.
+The biggest issue was the ActiveModel::EachValidator#validates_each API. It’s definitely not a well-designed API. You write your validator as a subclass, overriding validates_each. The method takes a model object, the name of the attribute of the model being tested, and the value of that attribute. You can also get the options passed to the custom validator via the options method. To perform a validation, you have to update the model’s errors hash.
The big flaw in the API is that instead of returning a result, you have to update the model. This needlessly couples the model and the validator. And it violates the Single Responsibility Principle — it has to determine validity of the field, and it has to update the errors hash of the model. This is not conducive to testing. Testing this method requires testing that the side-effect has taken place in the collaborator (model), which means it’s not really a unit test any more.
So to make it easier to unit test the validator, I broke the coupling by breaking it into 2 pieces, one for each responsibility. I moved the responsibility for determining validity to a separate method, which I called errors_for. It returns a hash of the errors found. This simplified the validates_each method to simply take the result of errors_for and update the errors hash of the model:
def validate_each(record, attribute_name, attribute_value) + record.errors[attribute_name].concat(errors_for(attribute_value, options)) +end+
This made it much easier to unit test the errors_for method. This method doesn’t even need to know about the model — only about the value of the attribute we’re trying to validate. We simply pass in the attribute’s value and the options.
So we could write the tests without even pulling in ActiveRecord or any models:
+describe DateValidator do
+ let(:validator) { DateValidator.new(attributes: :attribute_name) }
+ let(:errors) { validator.errors_for(attribute_value, validation_options) }
+
+ describe 'when attribute value is NOT a valid date' do
+ let(:attribute_value) { 'not a valid date' }
+ it { errors.must_include 'is not a valid date' }
+ end
+
+ describe 'when attribute value IS a valid date' do
+ let(:attribute_value) { Date.parse('2013-12-11') }
+ it { errors.must_be :empty? }
+ end
+end
+And the errors_for method looked something like this:
def errors_for(attribute_value, options) + unless attribute_value.is_a?(Date) + return [options.fetch(:message, "is not a valid date")] + end + [] +end+
Integration testing can also be a bit of a challenge. I recommend following the example from this Stack Overflow answer. Basically, create a minimal model object that contains the field and the validation. Then test that the model behaves like you expect with different values and validations.
+Today I was informed that I’ve been impeding progress on our team.
+This was somewhat shocking, since I feel like I’m always pushing
+forward to make our team and myself better.
Like most anyone, my initial reaction to criticism was defensiveness.
+I don’t handle criticism well. (You might find that hard to believe,
+after reading the rest of this post. Maybe it’s just the confrontation
+part I don’t handle well.) Thankfully the blow was softened somewhat,
+because the person providing the criticism didn’t tell me directly —
+they told Amos, a trusted colleague of mine. Amos then passed it on to
+me. I’m grateful for that — this is the best way for me to have received
+that criticism.
What I did next is the astonishing thing. I swallowed my pride for a
+minute. Not an easy thing for me to do, for all the usual reasons, and
+more. I decided to address the problem head on. If someone was telling
+someone else that I was causing some sort of a problem, then even that
+perception was a problem that I needed to address. So I decided to hold
+a retrospective for myself. Retrospectives are the way Agile teams address
+problems and improve how they work. If it would work for a team, I figured
+it should work for an individual.
I’d held retrospectives by myself before. Before I even knew about
+retrospectives, I’d taken some time to assess how I had done things
+on a couple of projects I had worked on as an independent contractor. But
+those were about technical decisions I had made and processes I had
+followed. This one would be different. This one was about a personal
+shortcoming, an action of mine that had caused some harm. This one
+involved feelings and emotions.
So I asked Amos to facilitate my one-person retro. We’d both done a lot
+of retrospectives, but neither one of us had done anything like this before.
+We had a bit of trouble getting started. We didn’t have any details
+about why the anonymous person felt the way he felt. So it was hard
+to address something that nebulous. So I asked Amos if he could follow
+up with the person. Luckily, the person was online and able to respond
+in real time.
So we talked things through some. We went on some tangents. We made some
+progress — things that I could write down as take-aways and action items.
+We got off-topic again, and then came back to it. Then Amos decided to
+play The Why Game. This worked amazingly well. It helped me to find the
+root reasons why I was holding back change. Basically I’m afraid of
+failure. Going deeper, we looked into why I’m afraid of failure. This
+line of inquiry was particularly effective. Hopefully it’ll be enough for
+me to stop being an impediment to change. Here are my notes / take-aways:
At first, I thought that I’d never heard of anyone doing anything like
+this. But then I recalled that I’d heard about somewhere that everyone
+does this, with their whole team. That would be hard. I’d have to
+trust everyone in the room.
But I would recommend this for anyone that can pull it off. It’s hard,
+but it has a large payoff. Just like a team retrospective, it feels good
+making this kind of breakthrough, and knowing that just spending that
+little amount of time has made me a better person. (Mine took about an hour.)
+I think the hardest part is finding someone (or a group of people) you
+trust to be your facilitator.
I’ve decided to call this thing an introspective. A retrospective is
+about looking back. This is about looking inward. I’d be interested to
+find out who is doing this kind of thing. Does it have a commonly accepted
+name? How does it work? What techniques work best? If you’ve got any answers or ideas, please comment below, or tweet me @CraigBuchek.
So thank you to that anonymous person. Your way of addressing this was
+probably more effective than you could have imagined that it might be.
+I hope that this exercise will help me make the changes required, to make
+me a better person, and help the team become the best that we can be.
Amos has written up his thoughts on the introspective.
+I’ve been using GNU/Linux since 1994, starting with a Slackware 2.2 CD-ROM I ordered from the back of a magazine. I’ve been heavily involved in my local GNU/Linux community since 1999, and I give frequent presentations at various groups. I’ve made some small contributions to several Open Source projects.
+But I don’t feel like I’ve done enough to contribute to the wider community. So this year, I’m going to resolve to step up my contributions, and do more.
+I was lucky enough this past year to find someone interested in helping to run the St. Louis GNU/Linux Users Group (STLLUG). I’ve been running the group so long that I’ve somewhat stagnated. It’s great to find someone who will bring a fresh energy and new ideas. Thanks, Andrew!
+Mostly freed from the more general administrative tasks (mostly planning meeting topics and speakers), I’m hoping to find the time to work on a few projects. First, I want to overhaul the web site. It needs a new look, as well as an easier way to update it. I’m planning to implement some sort of CMS — possibly WordPress or Octopress, or at the very least, a git repo to manage updates.
+I installed WordPress a long time ago, but I haven’t published many posts. I’ve got a few drafts in various stages. So this year I’m going to actually get the blog going, and hopefully post about once a week. I’ll be sharing things I learn on the Internet, as well as some of the things I learn from my experiences with various technologies and techniques.
+There are a few items I’ve been meaning to work on and contribute. I’d like to finally get around to them:
+I’ve been working on a few Ruby gems. I’d like to get them to a state where they’re useful to more people. These include:
+I enjoyed building a quick Rails app during last year’s Rails Rumble, even if it doesn’t turn out to be useful or make any money. I’d like to create a few small apps again this year, either in Rails or Apache Cordova. I’ve got some ideas — we’ll see how if they turn into anything useful or worth selling.
+Last year, I started joining the This Agile Life podcast. I enjoy it. I’m hoping to continue with that, and possibly doing some podcasting about Ruby and Rails.
+I’m going to attempt to give a presentation at a conference. I often give presentations at local groups, but haven’t addressed a larger audience. I’ve got a few ideas rattling around, and will see if I can turn them into presentations worthy of a larger conference.
+What’s your Open Source resolution?
+I’ve been using Python at work for the past few months. I learned Python back in the early 2000s, but never used it for any large projects. I learned Ruby in late 2005, and it quickly became my language of choice for most cases.
+So while I still prefer Ruby, and will likely use Ruby more in the future than Python, I wanted to assess the strengths and weaknesses of Python in relation to Ruby. Perhaps some of the lessons could be applied when writing Ruby, and it could help to decide when to use each. Also, I’m interested in programming language design, and wanted to document pros and cons in that light.
+Where Python Sucks (As Compared to Ruby)
++
I’ve been more interested in programming patterns lately, partly due to the Ruby community’s recent interest — especially the Ruby Rogue podcast’s love affair with “Smalltalk Best Practice Patterns”.
+I consider most of the patterns in “Smalltalk Best Practice Patterns” to be patterns “in the small” — things that are typically employed on a single line or method. The Gang Of Four patterns are more medium sized, dealing with methods and classes. The PEAA book covers architectural-scale patterns. I suppose “The Pragmatic Programmer” and similar books could (should!) be considered to be very general patterns, mostly about the practice of programming.
+One type of pattern that I have not seen discussed much is debugging patterns. I’m not exactly sure why that is; probably just our general concentration on designing the program code itself. There are definitely testing patterns. But I can’t think of anything that I’ve seen that covers debugging patterns. A quick search on the Internet doesn’t turn up too much.
+Anyway, a co-worker (Helena) and I were debugging recently, and were having trouble figuring out where a certain method on a certain object was being called. We came up with a really cool solution. We immediately called it a grenade, because its entire purpose is to blow up (raise an exception) and display a backtrace to show us the caller of the method that we’re looking for.
+Here’s our implementation in Ruby:
+
+module Grenade
+ def method_under_investigation(*)
+ raise "method_under_investigation called"
+ end
+end
+
+class Xyz
+ ...
+ def xyz
+ object_under_investigation.extend(Grenade)
+ end
+ ...
+endI’m sure we could wrap that in some more semantic sugar, even going as far as making it look something like this:
+
+class Xyz
+ ...
+ def xyz
+ object_under_investigation.blow_up_when_method_called(:method_under_investigation)
+ end
+ ...
+end
+I’m not sure that would really be worth it though, unless we were to add it to some sort of library.
+So that’s our contribution to the (small) list of debugging patterns.
+Amos and I got in a heated discussion recently on whether we should write a single line comment to better explain some code. (The code in question was Amos’s very elegant solution to testing whether a job got sent to Resque.)
+Amos doesn’t believe in writing comments much at all. He thinks that if you’re writing a comment, it means that you’re doing something wrong, and that you probably need to write the code more clearly.
+I agree with that, to a point. First off, it’s not necessary to write perfect code. If you can change a class or method name to better describe what you’re doing (and more importantly, why you’re doing it) then you should definitely do so. But it’s not always worth refactoring until you get every “why” answered. More importantly, I don’t think it’s even possible to capture everything in the code that is worth capturing. For example, why did you choose this implementation, as opposed to another that might be more obvious or common?
+After our argument, I came up with a good rule of thumb (or “pattern”):
++Write comments for your (future) self.1
In other words, if your comment will help you to understand the code more quickly when you look at it in the future, then it’s a valid comment. It also means that you can assume that the reader has about as much general programming knowledge as you currently do. (Your future self will have more general knowledge, but possibly less specific knowledge of the lines of code in question. And because of this, your current solution might not make as much sense in the future. You might know of a better solution in the future, but you’ll have to know all the constraints that you had when you originally wrote the code.)
+This is not to say that you should not write comments in clear English, that others can understand. The comment is written for a future maintainer. That may be you (which is why the rule works well), or it may be someone else. The rule is more about when to write a comment, and what level of competence you should assume of the reader.
+1 Perhaps it should be “Write comments TO your (future) self”.
+Here’s a relatively simple way to rename a bunch of files from the command line. It uses sed within a command substitution to compute the new names from the old names.
In this example, we’re renaming files that start with “ABC” to start with “XYZ” instead:
+ for i in ABC*; do mv $i $(echo $i | sed -e s/^ABC/XYZ/); done
+You’ll have to use shell globbing (wildcards) in the first part, to determine which files will be the source of the renaming, and regular expressions in the second part to translate the old names into the new names.
+It’s a good idea to use echo in place of mv before running this, to see what the results will be, so you don’t make a mistake.
Depending on the situation, you may need to adapt this for your particular needs. For example, if you have too many files to rename, you would need to use xargs. Or sed might not be up for the task of transforming the names that you want. Or you might need to use find to find files within a hierarchy. As with any UNIX idiom, there are hundreds of variations on the theme.
Welcome to the BoochTek blog. BoochTek, LLC is a small web development company, based in St. Louis, Missouri. We specialize in Ruby on Rails, jQuery (JavaScript), and PHP.
+This bog will be a place where we can share some of our experiences in web development, Open Source, programming, and technology in general.
+Web Development, Ruby on Rails, Open Source
+Welcome to the BoochTek blog. BoochTek, LLC is a small web development company, based in St. Louis, Missouri. We specialize in Ruby on Rails, jQuery (JavaScript), and PHP.
+This bog will be a place where we can share some of our experiences in web development, Open Source, programming, and technology in general.
+Web Development, Ruby on Rails, Open Source
+I don’t believe that estimation should be part of any Agile practice.
+One of our managers recently mentioned that we hadn’t met the “contract” that we had “committed” to in our last iteration. This was complete nonsense, because A) we hadn’t made any such commitments, and B) we completed many more story points than the previous iterations (and without inflating story points).
+
But her language made me come to several realizations. First and foremost, estimates are contracts. Sure, they’re not supposed to be treated as commitments, but they almost always are. And what does the Agile Manifesto say about this? It says that we should value customer collaboration over contract negotiation, and responding to change over following a plan. So it’s pretty clear that treating estimates as commitments is completely counter to the Agile values.
+Why does this matter? What benefits do the Agile values bring us? I think the biggest benefit they bring is changing the way that we work, so that we can better deliver value to our customers. Without Agile, we’d just keep working the way we’ve always done things. And that didn’t seem to be working out so well. If we follow the Agile values and principles, at least we’ll have a fighting chance of improving our ability to deliver value.
+Ask yourself — have you ever seen a software development project that was on time and on budget? Where the estimates were spot-on? Of course not. For one, we’re terrible at estimating. For another, our plans change — either from external factors, or from what we learn as we go.
+To me, Agile is also about facing reality — and embracing it. It realizes that we’re terrible at estimating. It realizes that plans change. Most Agile methodologies have some tricks to counteract Hofstadter’s law. Generally, we use relative story points instead of hours, and then use an empirical factor to convert points to hours.
+When this works, it is better than any other estimation I’ve ever seen. But it doesn’t work very often. People have trouble with relative estimation. How do you set the basis for what a point means without relating it to actual hours? Affinity estimation could work, but then you have to remember what the basis was. We’ve got a large distributed team, and when we tried this, we couldn’t all remember what the basis was.
+Since we couldn’t get affinity estimation to work, we tried changing to perfect hours (only powers of 2). But then people thought of them as time. When we took longer than the estimate on an individual story, managers and team members thought we were taking longer than we should have. So our estimates ended up causing problems.
+Managers want estimates so that they can have predictability. They want to know when new features will be available. Is there a better way to get what we need?
+I believe there’s a better way — prioritization. If you work on the most important thing first, then the most important thing will get done first. We should always be working on the next most important thing.
+What if there’s more than 1 thing that’s most important? Then you’ve failed. You’ve failed at logic if you can’t understand that only 1 thing can be most important. You’ve failed at prioritizing the customers’ needs. You’ve failed at project management.
+1. Why can’t you just tell us how long it will really take?
+Because we don’t know. Because we can’t know. This is the first time we’ve ever implemented the functionality you’ve asked for. If we’d done it before, we’d just use that existing code. As Glenn Vanderburg pointed out in his excellent talk on Software Engineering, we’re not building software, we’re architecting it.
+2. But we have to tell our customers what to expect.
+Why? Is the product so bad that you can’t keep customers around without leading them on with future enhancements? And why do customers need exact dates? A general roadmap telling them what the priorities for upcoming features should be sufficient.
+3. But we have to have messaging about new features.
+OK. Then send out that messaging once the feature has made it to Staging. Or even after it’s been rolled out to Production.
+4. But we’ve promised these new features to the customers by this date.
+Ah, so you’ve made promises to the customer that you don’t have control over. Have you ever heard of “under-promise and over-deliver”? That’s how you create happy customers. Yet you’ve done just the opposite, haven’t you? And then you want to blame someone else.
+Risk
+Estimates are risk. But the risk doesn’t come at the end, when the estimates are shown to be incorrect. The risk was in asking for the estimates in the first place, and placing trust in them. Don’t do it. Don’t promise things that you can’t be sure of.
+Embrace this reality. Embrace this uncertainty. Always focus on what’s most important. That’s how you make customers happy.
+Web Development, Ruby on Rails, Open Source
+I don’t believe that estimation should be part of any Agile practice.
+One of our managers recently mentioned that we hadn’t met the “contract” that we had “committed” to in our last iteration. This was complete nonsense, because A) we hadn’t made any such commitments, and B) we completed many more story points than the previous iterations (and without inflating story points).
+
But her language made me come to several realizations. First and foremost, estimates are contracts. Sure, they’re not supposed to be treated as commitments, but they almost always are. And what does the Agile Manifesto say about this? It says that we should value customer collaboration over contract negotiation, and responding to change over following a plan. So it’s pretty clear that treating estimates as commitments is completely counter to the Agile values.
+Why does this matter? What benefits do the Agile values bring us? I think the biggest benefit they bring is changing the way that we work, so that we can better deliver value to our customers. Without Agile, we’d just keep working the way we’ve always done things. And that didn’t seem to be working out so well. If we follow the Agile values and principles, at least we’ll have a fighting chance of improving our ability to deliver value.
+Ask yourself — have you ever seen a software development project that was on time and on budget? Where the estimates were spot-on? Of course not. For one, we’re terrible at estimating. For another, our plans change — either from external factors, or from what we learn as we go.
+To me, Agile is also about facing reality — and embracing it. It realizes that we’re terrible at estimating. It realizes that plans change. Most Agile methodologies have some tricks to counteract Hofstadter’s law. Generally, we use relative story points instead of hours, and then use an empirical factor to convert points to hours.
+When this works, it is better than any other estimation I’ve ever seen. But it doesn’t work very often. People have trouble with relative estimation. How do you set the basis for what a point means without relating it to actual hours? Affinity estimation could work, but then you have to remember what the basis was. We’ve got a large distributed team, and when we tried this, we couldn’t all remember what the basis was.
+Since we couldn’t get affinity estimation to work, we tried changing to perfect hours (only powers of 2). But then people thought of them as time. When we took longer than the estimate on an individual story, managers and team members thought we were taking longer than we should have. So our estimates ended up causing problems.
+Managers want estimates so that they can have predictability. They want to know when new features will be available. Is there a better way to get what we need?
+I believe there’s a better way — prioritization. If you work on the most important thing first, then the most important thing will get done first. We should always be working on the next most important thing.
+What if there’s more than 1 thing that’s most important? Then you’ve failed. You’ve failed at logic if you can’t understand that only 1 thing can be most important. You’ve failed at prioritizing the customers’ needs. You’ve failed at project management.
+1. Why can’t you just tell us how long it will really take?
+Because we don’t know. Because we can’t know. This is the first time we’ve ever implemented the functionality you’ve asked for. If we’d done it before, we’d just use that existing code. As Glenn Vanderburg pointed out in his excellent talk on Software Engineering, we’re not building software, we’re architecting it.
+2. But we have to tell our customers what to expect.
+Why? Is the product so bad that you can’t keep customers around without leading them on with future enhancements? And why do customers need exact dates? A general roadmap telling them what the priorities for upcoming features should be sufficient.
+3. But we have to have messaging about new features.
+OK. Then send out that messaging once the feature has made it to Staging. Or even after it’s been rolled out to Production.
+4. But we’ve promised these new features to the customers by this date.
+Ah, so you’ve made promises to the customer that you don’t have control over. Have you ever heard of “under-promise and over-deliver”? That’s how you create happy customers. Yet you’ve done just the opposite, haven’t you? And then you want to blame someone else.
+Risk
+Estimates are risk. But the risk doesn’t come at the end, when the estimates are shown to be incorrect. The risk was in asking for the estimates in the first place, and placing trust in them. Don’t do it. Don’t promise things that you can’t be sure of.
+Embrace this reality. Embrace this uncertainty. Always focus on what’s most important. That’s how you make customers happy.
+| t |
| t |
| t |
Testing Rails Validators<\/a><\/blockquote>\n
I feel like the lesson here is: Yes, if you come to Python expecting Ruby, you’re gonna have a bad time.
+