Archive for the ‘code’ Category
d: A build light
I have a long history with build lights. A build light is as indicator that displays the success or failure of a software “build” where all the parts are integrated, the tests run, and if all right all the tests pass and to the best of out test suites knowledge, everything is working.
It’s a confidence enhancer to be sure. The light just makes it obvious, and in fact, with my current team we have a number of indicators since we’re a virtual team. Test runs show in our group chat, are visible via ccmenu, and email. But nothing seems to bring as much joy as green build light. In one former place there was a build “bunny” a WiFi enabled device that would play some audio and move it’s ears, but it never seem to catch on as good indicator of the build.
I was looking for something to install with this group when I ran across this article. And while our setup is different, this seemed like an excellent start. Here’s how I wired it up:
There’s a gem called blinky. Blinky relies on libusb-compat, but that turned out to be only a “brew” away: brew install libusb-compat. And then gem install blinky. They’re designed around this usb powered light. They’re not far away in Portchester, NY. Nice. A few lines of code later, and my light was flashing on and off. It’s warning mode seems to be a little hinky, but everything else was perfect. A little parsing of the ccmenu xml that Tddium delivers, and I was off to the races. But I couldn’t afford one light per project just for myself so I decided on a pattern that would be obvious about a failure of any of the projects. Next I wanted things to run periodically. OS X uses launchd for stuff like this and here I ran into an issue.
I do lot of Ruby development, and use rbenv to switch between runtimes. And it works just fine. But in this case a standard call to ruby wouldn’t work because launched doesn’t know anything about my shell settings and so would try and run the system ruby which has nothing installed (no gems and it’s an old version I don’t often work with at this point). I couldn’t figure out how to get launchd to use a shell that would respect my settings.
In the end my launched command is sh -c /Users/daniel/buildlight/run.sh and in there is a line that points directly to the ruby executable I wanted to run with this file /Users/daniel/.rbenv/versions/1.9.2-p290/bin/ruby ~/buildlight/light.rb. That worked. While slightly inelegant… I’ll take “works” any day. And maybe someone else can explain to me how to make launchd respect rbenv. I use Lignon (app store) to control a number of things under launchd, and it makes it really painless to load stuff and set the params. And that’s it. Now every 5 minutes it checks the builds and lets me know what’s going on. I didn’t find a lot of articles about creating a build light when I looked, so I thought I would write this up. Happy coding…
Other folks I know are using this setup to display sales and other successes over the course of the day. It can be a great way to bring some celebration to the little wins that make up our days.
Every Little Things Capistrano Does Is Magic : Ruby Fleebie
Every Little Things Capistrano Does Is Magic : Ruby Fleebie:
During all these years, Capistrano has been for me a magical gnome that I invoke by saying “cap deploy, my magical friend!” and then I close my eyes, sing a happy song in my head and when the gnome has finished his magic, I hit F5 to see if all went well. And of course, if it didn’t, I blame the damn elf.
[Blame the elf! Blame the elf!]
Rails: Unobtrusive and i18n Javascript confirm | Luca Guidi
Rails: Unobtrusive and i18n Javascript confirm | Luca Guidi:
How many times do you heard you should separate content from behavior? Never? Hmmm don’t try to cheat me.. So, why do you still use :confirm option for link_to helper?
Decoration is best, except when it isn’t
Decoration is best, except when it isn’t:
Decoration and module extension are both viable ways to compose objects in Ruby. Which to use is not a simple black-or-white choice; it depends on the purpose of the composition.For applications where you want to adorn an object with some extra functionality, or modify how it presents itself, a decorator is probably the best bet. Decorators are great for creating Presenters, where we just want to change an object’s “face” in a specific context.
On the other hand, when building up a composite object at runtime object out of individual “aspects” or “facets”, module extension may make more sense. Judicious use of module extension can lead to a kind of “emergent behavior” which is hard to replicate with decoration or delegation.
Missing refactoring…
Crazy, Heretical, and Awesome: The Way I Write Rails Apps | James on Software:
To decouple the logging from the creation of the database record, we’re going to use something called a service object. A service object is typically used to coordinate two or more objects; usually, the service object doesn’t have any logic of its own (simplified definition). We’re also going to use Dependency Injection so that we can mock everything out and make our tests awesomely fast (seconds not minutes).
[Again, a missing refactoring from the last major project...]
Source: @brynary
Sandi Metz: SOLID Design Principles – Dependency Injection
Sandi Metz: SOLID Design Principles – Dependency Injection:
Because of the style of coding in Job, it contains dependencies that effect my ability to refactor and reuse it in the future.
[An excellent example of something that was hard to think through in the last significant codebase I worked on. There are always tradeoffs in style, testing, and time spent. We managed as best we could, but I think we should have done more of this (easy to say now.)]
Source: brynary
Your tests are lying to you
Well designed code is easy to test. As a rule of thumb, anytime I get over about two or three lines of setup code for testing a method, I normally take a step back and ask myself if this method is doing too much.Test speed
The other advantage of running tests purely in isolation is that they’re fast. Very fast. When I’m coding Rails apps these days, thanks to advice from Corey Haines I’m running a spec_no_rails folder which runs independently from the rest of my Rails app. Rails apps by default epitomise this problem: default model tests exercise the whole system from the database up. By running your tests independently you’re not having to clean the database or start Rails each time you run your tests, which means that much of your interesting code can be tested in under a second. Gary Bernhardt has more information on how to set this up in his excellent Destroy All Software screencast series.
[One thing not mentioned here is a pet peeve of mine. I see a lot of tests where the dev is testing implementation rather than input and outputs. To me, checking how something was implemented is not relevant. That the method returns the expected results for a given input is. "Implementation tests" also causes a great deal of test rewrite when refactoring.]
Select and copy text within Quick Look previews
Select and copy text within Quick Look previews:
To make text selectable in Quick Look previews, you just need to enable a hidden Finder setting. Select and copy the code below, open Terminal (/Applications/Utilities), paste that code at the prompt, then press Return:
defaults write com.apple.finder QLEnableTextSelection -bool TRUE; killall FinderAfter a second or two, the Finder will restart. Once it does, you’ll be able to select text in Quick Look previews and copy it to the Clipboard for use elsewhere.
If you decide you don’t deserve to select text in Quick Look, you can turn this feature off with another Terminal command:
defaults delete com.apple.finder QLEnableTextSelection; killall Finder
[There's an improvement.]
HTTP Signature authentication scheme
A Bit More About the New Joyent Cloud API:
To solve this problem with SmartDataCenter, we’re introducing the HTTP Signature authentication scheme, which is already released as open source. The HTTP Signature scheme allows for digital signatures to be leveraged as your credentials, and does not imply any particular key management scheme. It should be suitable for just about any REST API out there, so we’re certainly hoping if you’re an API vendor you take a look at it, but rather than jump into the technical details of the spec itself, I thought it would be interesting to show you some CLI candy, so lets walk through some examples.
Source: Joyeur
Ruby On REST: Introducing the Representer Pattern
Ruby On REST: Introducing the Representer Pattern:
The calls for more object-orientation in Ruby frameworks are growing ever louder. Most web frameworks, like Rails, come with a nice database abstraction, a Rack-like HTTP endpoint, routing, and a template engine. It’s the lack of additional abstraction layers that make many programmers ask for “more OOP”.
[Yeah, been feeling this for a while. The problem is unless you can put in some serious refactoring to an established project the weight of getting things done (momentum) often overwhelms the desire to improve the codebase (which, of course, makes the future refactoring larger in the ugliest of loops).]
