I just created a quick Ruby screencast on creating hashes. I don’t cover all of the possibilities, but I do show 5 ways—including one you should never use. Let me know what you think, and if you have questions or ideas for a future screencast, chime in!
Ruby Hashes from David Brady on Vimeo.
Ah, the Open-Closed Principle. In static languages like C++ and Java, classes by default are Closed-Closed. In dynamic languages like JavaScript and Ruby, they are Open-Open. In Java you have to add design pattern ceremony in order to open for classes for extension; in Ruby you have to exercise discipline in order to keep them closed for modification. Yesterday Pat Maddox and I spent 80 minutes kicking the can around talking about Monkeypatching versus the Open-Closed Principle. Along the way, we talked about everything from Rebecca Black to RSpec, from Cognitive Load to watching my cat try to claw open my office window.
Pat and I are gonna start doing this regularly. And we need a cool name for our podcast! Help us out! The giver of the winning suggestion will get something cool. Not sure what yet, but I promise it will be something cool.
But for now, just watch the rest of this post’s space for the video. Because I’m embedding it in 3… 2…
Monkeypatching and the Open-Closed Principle from David Brady on Vimeo.
Okay, let me start by saying “holy freaking crap”.
I met Wayne E. Seguin at MountainWest RubyConf, and we immediately hit it off, much to the dismay of many onlookers. At one point Evan Light said “It would be interesting to find out which of you two has the most disturbing sense of humor.” Both Wayne and I immediately shouted “OKAY!” and then I didn’t hear what either of us said after that because everyone around us was screaming “NOOOOOOOOOOOOOO!!!!!!!!”
Now, Wayne created the incredible rvm, or “Ruby enVironment Manager”, and what’s more, he created it all in bash rather than using a “real” programming language like Ruby or Python. It turns out that Wayne’s been doing a lot of bash scripting, writing BDSM which doesn’t stand for what you think it stands for and instead stands for “Bash Deployment and Server Manager”. Then again the project image is a penguin dressed in leather cracking a whip over a 4U server wearing a ball gag. So maybe it also means what you think it means.
But I digress. The point is, Wayne’s been doing a LOT of programming in bash lately.
A few weeks ago, I tried to add rvm-prompt to my bash prompt, and found that I couldn’t. I learned enough bash scripting a couple years back to write a totally sweet bash prompt that showed my git branch in different colors based on the name. Master and Production branches show in an alarm color, story branches in a calm cyan, etc, like so:
But while my prompt was sweet, my bash prompt programming was… well, not so sweet. It chained half a dozen sed scripts together to inject the ANSI color codes for each branch name, and like I said, was so complex I could not debug it. I showed it to Wayne with a mutter about “I should probably extract this to a function or something”. Wayne looked at it and made this sort of incoherent cry of alarm and dismay. In his defense, this was the prompt:
A few hours later, he called me on Skype and said, “Can I help you with your bash prompt?” I said “Sure!” and Wayne turned on screen sharing.
What I didn’t know is that he had Haris Amin on the line as well, and he had prepared an entire bash programming lesson for us.
What HE didn’t know is that I have been in the habit of recording my Skype sessions. When Wayne switched us to his Adobe Connect sharing session, I said, “Hang on, you’re not sharing this with Skype, I need to start my OTHER screencast recorder.”
And here it is. The most awesome hour I spent last week:
CRAZY Bash Programming with Wayne E Seguin and Haris Amin from David Brady on Vimeo.
Recently a coworker of mine told me he was happy with SVN, and had been for years. Why should he and his team switch to git if they were productive and happy? I posted this to our internal message board, but I think the answer is broad enough to merit posting here on my blog. Enjoy. Which vcs do you use, and why do you like it? Are there any ex-git users out there who prefer something else?
Just my $0.02, but I hear this concern from satisfied svn users a lot. I used to be one myself. There is a compelling answer, but unfortunately I don’t know how to articulate it. Almost without exception, every svn user I have seen switch to git has slapped their forehead and said, “My goodness, why didn’t you tell me the world wasn’t flat?!?”
I think the problem is threefold. First, git was very hard to use when it first came out, which turned a lot of people off. Second, it was kind of a hipster trendy thing, which turned even more people off. But most importantly, every advantage that git provides over svn is something that svn users have learned to live without, and so when you say “git can do this”, svn users say “Yeah, but we don’t need or use that.”
You need those things. They will make you happy. Take it on faith until you begin to enjoy the fruits yourself. :-) Git offers a ton of incredible things over svn. I’ll mention just my top three favorites.
First, you can branch in git, and you don’t do that in svn. I know what you’re thinking: you CAN branch in svn. That’s not what I said. I said you DON’T. Because it’s such a pain to do and merging is such a nightmare, I’ve only ever met one team that used branching heavily in svn. They were a company with 500+ developers, however, and had IT staff on hand full-time to enforce the engineering discipline to keep their branches under control, and once a week the dev team stopped and had a “merge day” when branches were folded back into the mainline. In contrast, git’s merging tools are so freakishly powerful that branching becomes nearly a zero-cost operation. In the past week, I have created or worked in not less than ten different branches across three projects. Each feature, each bugfix, isolated in its own branch. All of the code is changed and updated, and pushed up to the server. Some of the branches were merged immediately, some are still awaiting QA testing before it can be deployed. So that’s feature number one: Git makes branching and merging so easy that you’ll use it all the time.
Second, and this is a huge implication, because branching and merging are so easy, you no longer have this problem where everybody is syncing and merging with trunk, where every feature change gets deployed to production as soon as you finish it. You might be tempted to lump this in with my first point, but as somebody who occasionally gets dragged back into svn from git, this is totally a separate concern. You can’t do exploratory branches easily, so you don’t do them. With git, you can fork a branch, make some changes, forget about the branch, go back and work in master (git’s word for “trunk”) for a month, then come back to your exploratory branch and type “rebase” and it will MOVE your changes forward in time, updating the trunk and then “playing your changes back” over the new trunk, making it as though you had forked yesterday instead of a month ago. If you’ve ever made a bugfix and then had to hold off pushing your commit because QA was still testing trunk for a deploy, you need to switch to git.
Thirdly, git is distributed. Everybody gets the obvious implication of this, that you could be pushing your code to multiple servers. And big deal, right? You could be backing up your svn repo just as easily. But everybody misses the subtle implications of this, which are earth-shattering: one, what you call your sandbox, git consider to be just another repo. Which means you can be on a plane with no internet access, and you can checkout old revisions, commit code to a feature branch, fix a bug in master, and start two new exploratory branches, all without being connected to the main repo. What svn calls a commit, git calls a push, and it syncs your “local” repo with the remote one. (What git calls a commit is just storing a change from your sandbox to your local repo database to be pushed later.) And two, because you have a full copy of the local repo in your sandbox, you can play amazing games with the commit history. Checked in a file you shouldn’t have? Go back into your repo’s history and remove it from the commit stream before you push it to the server. Wrote the wrong bug number on your checkin? Amend your commit message. Pulled down latest code only to discover that 12 files are in conflict and you just want the version from two days ago? You can jump over to that commit and grab them.
That’s my $0.02, which I guess on a per-word basis appears to be quite the bargain. Sorry. TL;DR: git takes your version control game to a whole new level that you didn’t even know existed. If you’re happy with svn, you don’t NEED to use git. But if you want to STAY happy with svn, trust me: don’t ever switch. You WON’T be able to go back.
(Well, actually, you will. git has a svn emulation module that lets you have a git repo locally and push commits to a svn server. It still has the problem of “the dev team are all committing to trunk”, but features 1 and 3, of branching and distributing, still shine through. It makes working with subversion… bearable.)
I found out the night before the conference that one more speaker had canceled than the conference had backup speakers in reserve. I found this out because I was rooming with the conference organizer, Mike Moore, and BOY did he call in the favor of not asking me to split the hotel cost!
So, I spoke for about half an hour about Monkeypatching Your Brain. All while dressed in a Hilton Hotel bathrobe:
Photo by Jeremy Nicoll of Smashing Shots
It’s currently up at Justin.tv, here: http://www.justin.tv/confreaks/b/281745310 I am the second speaker, about 38 minutes in. It’s the livestream from the conference and I don’t know how long the link will be valid. Confreaks is in the process of making “proper” videos of the conference. I’ll post a link once those are up.
I originally wrote this as Git: How to Merge a Remote Fork on LiveJournal, but Google refuses to index my LJ, so I couldn’t find it when I needed it. I’m reposting this here for my own future benefit.
James Britt just updated the documentation to TourBus for me, and he pushed the changes to his own fork. Here’s how I pulled it into my own repository without forcibly overwriting my own work until I was ready to merge it. James’ fork is at http://github.com/jamesbritt/tourbus.
Comments are welcome, especially if you know a better way to do it.
In English: Add a remote to my local repository, for James’ remote. Fetch his changes. Diff his changes against master. Assuming approval of his changes, check out master, merge james’ master, and push it.
In Bash:
$ cd tourbus
$ git checkout master
$ git remote add jamesbritt git://github.com/jamesbritt/tourbus
$ git fetch jamesbritt
$ git diff jamesbritt/master
$ git merge jamesbritt-master
$ git push origin master
[Edit: Thanks to Markus Prinz for pointing out the needless tracking branch. I have removed it.]
[Edit: Markus also points out that you can skip the git fetch jamesbritt step if you use -f in the preceding step: git remote add -f jamesbritt git://github.com/jamesbritt/tourbus]
If you need to make changes to get their stuff before merging and you don’t want to do it on master, you should make your own story branch for it:
$ cd tourbus
$ git checkout master
$ git remote add jamesbritt git://github.com/jamesbritt/tourbus
$ git fetch jamesbritt
$ git diff jamesbritt/master # eep, weird changes seen
$ git checkout -b fixmerge # I'm on master, so this will branch from there
$ git merge jamesbritt/master # now we have a master + jamesbritt/master merge. Make changes as needed, then
$ git checkout master
$ git merge fixmerge
$ git push origin master
Lasse Koskela recently wrote Test Everything, But Not Private Methods on his blog. Thank you for writing this, Lasse. This is one of the most intelligent, albeit still wrong, posts I’ve read on the topic. Lasse specifically addresses one of my greatest concerns, which is simply that “if it can possibly break, it should be tested.”
It turns out that on the face, we are in agreement: you should not leave complicated code untested. Lasse’s answer (which is repeated by several folks, including Michael Feathers and Mike Bria) is simply to not write complicated private methods. If you have a complicated private method, you should make it public and test it. If it doesn’t belong on the public interface of the class, then move it to another class or create a new one where it can be public. As Michael Feathers puts it in his book Working With Legacy Code: “the real answer is that if you have the urge to test a private method, the method shouldn’t be private; if making the method public bothers you, chances are, it is because it is part of a separate responsibility: it should be on another class.”
I’m a huge fan of Michael Feathers, bordering on Fanboy lunacy, so I’m a bit hesitant to disagree with him. Also, to be fair, I agree with Lasse one hundred percent–about 90% of the time. However, Mike and Lasse present “extract method to class” as a panacea when it is in itself merely a tradeoff with serious consequences of its own.
Extracting a class dilutes and adds complexity to your namespace. Code should struggle very hard to earn a spot at this level. I spend a lot of mental energy on a project trying to understand the class hierarchy, so much so that it is worth my effort to spent time trying to keep it well-organized to assist this understanding. A method that was meant to be private and to serve a class at a specific point in time suddenly becomes a public object. Care must be taken to either make the new class generic enough and provably safe to be used by arbitrary clients, or to prevent other classes from accessing the class at all. If you find yourself trying to figure out how to control access to the class, chances are the code you are trying to extract really should be private after all.
If you are going to extract the private method to a class, considerable care should be taken that it does not, in fact, still fall under the responsibility of the class that contained it. If your new class ends up with an “-er” name, especially “-Manager” or “-Controller”, it’s probably just a Functor–a method call masquerading as an object. If the moved method has many side effects, especially ones that modify instance variables, the moved method will end up taking many arguments and returning many values that the original class must then use to modify itself. You may just end up passing in the original class to the method. Now what you’ve done is replaced the “this” keyword with a variable named “that”. This is a code smell; it’s called Feature Envy, and the solution is to move the method into the envied class. If the new class has the original class’s name in its own, you’ve all but conceded that the new class is useless in isolation from its progenitor; all you’ve really accomplished in this case is cluttering up the object namespace in order to achieve one outcome: making the private method testable. Lasse eschews inelegant workarounds like reflection nonsense or package hackery, but complicating the object map is just as inelegant if it achieves nothing more than making a private method public.
Another counterargument is–and though this is a situation that I wish did not actually exist, every developer has in fact faced it–extract class is not a free refactoring, and on large legacy projects it may be prohibitively expensive. Suddenly “change the design” becomes “they shouldn’t have designed it that way in the first place” and the only solution is to invent a time machine, go back in time, and not have done it wrong. This isn’t practical.
Sometimes you have a method that is, and should be, both private and complex enough to require testing. When that happens, you should test it.
I agree with Lasse and Mike about the problems inherent with testing private methods; I just don’t think their proposed solution is always workable.
This post is getting long, so I’m going to breaak it into to two separate entries. Next up: I want to present some cases when I think I should, even using TDD, design and write private methods that should be tested. I’m also going to address what I think is the primary concern of anti-private-testers, that testing private methods is testing implementation. (Teaser: I completely agree–but I hope to show you why, in some cases, that’s not a problem or at least an acceptable tradeoff.)
Cellular automata is a way of modeling complex systems by focusing on simple, independent entities called automatons. These automatons are not simple by design but rather by definition; because they are each a tiny, tiny part of a massive system, and because the number of possible interactions between these automatons rises exponentially with each automaton added to the system, there is no possible way that a single automaton can possibly understand the complexity of its own system.
Here’s are some of the things a cellular automaton DOES know:
The complexities of the system are beautiful and staggering. Readers of “The Land of Lisp” will recognize this example: consider a world in which resources are scarce everywhere except in a tight jungle area, where resources are very rich. Now consider an automaton which has only one choice in life: to move straight ahead or turn. The automaton consumes a resource if it finds one, and it will die if it goes for too many turns without finding a resource. Each automaton will have a random tendency towards turning or going straight. Now let’s say that every so often, the surviving automata create offspring with tendencies similar to its own.
In even this simple an example, the automata will VERY quickly–in just a few dozen generations–specialize into two different species. One species adapts to living in the jungle. It almost always turns, trying to keep itself from wandering away from the jungle. The other species almost always goes straight, trying to cover as much distance as possible to find resources in the desert.
With regard to the title of this post, that’s “The Suprising Truth About Cellular Automata”. What about the “And You” part?
Take a deep breath, and reread the rules of cellular automata. Now turn your head and look out the window. Stare off into the distance and think for a long time. Now say these words aloud:
“This is why I don’t understand politics or economics.”
Of course, the hubris rule still applies. Just because we don’t understand it, doesn’t mean we aren’t going to try and it definitely doesn’t mean we’re not going to manipulate it. But for me, this is a perfectly adequate explanation for why economic theory makes so much sense on paper and yet the world economy can be in the tank. It explains why I get offended when someone reminds me to unit test my code, even while my unit tests reveal so many defects in my code.
The scale of complexity explains why terrorist bombings and economic collapse don’t necessarily have to be the work of conspiracies, and hubris explains why I would much rather believe that they are. Conversely, hubris explains why campaigning politicians look good denouncing the ails of the system, and complexity explains why incumbent politicians look incompetent trying to fix them.
Huh, that’s odd.
Just farting around, reducing the set of Integers to their prime factors—typically Friday-night stuff, amirite?—and I noticed an interesting pattern.
And so on.
The “Huh!” moment is this: you’re writing the exponent of two in the prime factorization of the list of integers:
1 20
2 21
3 20 * 3
4 22
5 20 * 5
6 21 * 3
7 20
8 23
9 20 * 32
10 21 * 5
11 20
12 22 * 3
13 20
14 21 * 7
15 20 * 3 * 5
16 24
Yeah, so, you know that app-a-day challenge thing? So, about that….
It’s like this, folks: I thought I was putting my mad skillz on the line; it turned out I was putting my madness on display.
I got my butt handed to me by this challenge in two equal portions. First, real life interrupted in a big way. One of my clients called me to tell me his airport software was being audited by the FAA in 24 hours–and there was a bug in my product that needed fixing. It sounded like a reasonably small tweak, so I agreed to handle it, thinking I’d even have time to ship my app afterwards. Turns out it was a redesign of the entire access control system which took me about 20 hours. I delivered it around 9am the next day and then went to bed and slept through a SECOND day of not shipping an app.
Fair humility where it is due, however, the other equal part of me getting served was that there really are just so many moving parts to an Android application that it’s insane. I’ll blame the tools and documentation here, hopefully convincingly, but the argument will stand that lack of experience is why I could not quickly overcome tool and documentation issues. But here’s the argument anyway: The Android development environment is epic shit. Not epic THE shit, just epic SHIT. Like somebody’s been feeding their mastodon too much fiber.
High-ceremony languages require high-tooling support. Low-ceremony languages require high-documentation support. For example, C# is the highest-ceremony language I’ve ever worked with–followed closely by Java. C#, however, is supported by Developer Studio, which is the best freaking IDE ever made. Seriously, I don’t like Microsoft on principle, and I don’t care for any of their languages professionally anymore. But I used their tools for over a decade and I’ve never seen their match. Don’t even bother posting a knee-jerk comment in response about this unless you know what you’re talking about, because you don’t, so just shut up. Oh, and if your knee-jerk comment was to say that Eclipse is pretty good, you also need to fuck off. And then get help. It’s called Stockholm Syndrome. Look it up (after you fuck off).
Ahem. Moving on.
Low-ceremony languages need high-documentation support. All you really need there is a good text editor (which means emacs, since I’m still in a mood to start shit) and off you go. You have the freedom to write expressive code that is readable enough that you don’t NEED all the tooling support. (Detractors of languages like Lisp and Ruby will say that you also have the freedom to write awful code. When you’re older, and learn big words like economics and sustainability, you’ll understand. For now, just understand that there are a lot of freedoms which one learns quickly to not exercise if one wants to keep one’s job.)
So anyway, yeah. Didn’t mean for this to turn into a rant, but Java is very high-ceremony, Android’s documentation is still rather in its infancy, and the tool support is Eclipse, of which my opinion has not changed in 4 years.
Will I still code in Android? Yes. The documentation will get better, and my experience with knowing how to fix Eclipse’s brain damage (syntax errors that are fixed but won’t go away until you clean the project or restart eclipse, etc) will get better. I’ll probably even stop complaining about it at some point.
But yeah. For now… let’s just say that the experiment ended with “findings” rather than “results”.
