Running SimpleCov when COVERAGE=true

Posted by David Brady on May 7, 2012 None comments
spacer

I use this trick every time I start a new project, which is just often enough to go look it up but not often enough to commit it to memory, so here it is in blog form:

spec_helper.rb
if ENV['COVERAGE']
    require 'simplecov'
    SimpleCov.start 'rails'
end

Of course if you’re writing a non-rails app omit the ‘rails’ argument. If you’re not using RSpec, put it in test/minitest_helper.rb. (And, of course, if you’re using Test::Unit, stop using Test::Unit and switch to MiniTest!)

Now when you run your specs or tests as normal with ‘rspec spec’ or ‘rake test’ your regular tests will run normally. To run them and get a coverage graph, however, just run

COVERAGE=true rspec spec

or

COVERAGE=true rake test

And there you go. If memory serves me correctly, this trick is credit due to Jake Mallory, from a project we worked on together last year.

Stop SOPA: An Open Letter

Posted by David Brady on January 18, 2012 1 comments
spacer

Copy of a letter I have sent to my representative. Similar letters have also been sent to both of my senators.

Dear Representative Chaffetz,

When you campaigned in 2008, you promised to go to Congress and fight for me. As your constituent, I am writing you to ask you to PLEASE do everything in your power to fight SOPA and PIPA.

I create content for the web, and I go out of my way to ensure that everything I create is legitimate, original and worthwhile. I have had that content pirated, and I feel firsthand the frustration of seeing others use and profit from my stolen efforts and being unable to find effective recourse against these people.

I want good anti-piracy legislation. We NEED good anti-piracy legislation. But SOPA and PIPA are NOT good legislation. While I appreciate the effort put into helping web-based businesspeople like myself gain speedy recourse against pirates–and this should be a part of good anti-piracy legislation–I am unsure if the laws will help a small business like myself, and I am genuinely terrified of the breadth and ease with which this recourse may be misapplied to legitimate content created under fair use.

I know this is a tricky issue. Balancing speedy recourse against infringement versus appropriate defense against censorship of free speech will require some clear thinking, tough negotiating, and hard fighting. But that’s what we elected you for.

Please give us good anti-piracy legislation. And please, do it by first stopping SOPA and PIPA.

Thank you,

David Brady
President, Shiny Systems LLC, and active Utah District 3 voter

Leaver’s Law

Posted by David Brady on October 26, 2011 2 comments
spacer

Leaver’s Law: “Everything the system does FOR you, the system also does TO you.”

I first heard this term coined by Don Leaver, one of the best “crusty C hackers” I’ve ever met. He got his start grinding out high-performance unix code, and these days he’s writing (if you can believe it) high-performance Windows code. (Seriously, the man is terrifying. His idea of a good time is making Windows completely surrender one of its CPUs and control of the USB bus so he can process signal data from a mission-critical device without fear of the operating system “taking the app out to lunch while my data puddles on the floor”.) As he modernized from simpler to more luxurious operating systems, this was his lament: that luxury is merely the upside of complexity, and when you gotta get crap done, complexity is the downside of luxury.

I have found that this law is not limited to operating systems, but can be applied to just about anything. I have quoted this law (usually with a curse) at everything from web frameworks to the automatic timer on my car’s headlights.

Leaver’s Law. Now you know.

Software and Chicken Entrails

Posted by David Brady on August 10, 2011 None comments
spacer

I had a collection of epiphanies today about Informational Software.

“Informational Software” is a term I use to describe software that helps you understand and make decisions about information. It is not a product and does not make your business money, but it can be used to help you understand your business and therefore, in theory, help you make money. For example, analytics software does not make you money, but you can use it to understand your traffic and hopefully to then minimize your costs and maximize your revenues. (Note that if you are selling an analytics package, this definition is still true, because in that case the software is a product, not an information tool*.)

Informational Software comes in two types: software that interprets trends and data and makes decisions for the user, and software that collects and reveals data so the user can make their own decisions. Expert systems are an example of the former, analytics packages are an example of the latter.

Let’s call this mess of data the chicken entrails. We want to read them and predict the future, right? Sure we do. That’s what chicken entrails are for.

Okay, enough definition. Here are the epiphanies:

First: If your users are untrained and the data is simple, your system can advise the user and/or make decisions for them. If they cannot read the entrails, or the entrails are too simple to bother the entrail readers, do not let/make them read the entrails.

Second: (Pay attention, this is the important bit) If your users are highly trained and the data is very complex, do not attempt to interpret the entrails for them. Just show them the entrails. Highly trained users who have asked you for information software do not want you to do their job, they want a tool to help them do their job better.

Third: My instinct is always write software that interprets entrails, regardless of the complexity and regardless of user knowledge. Learn to stop and figure out what it really needed.

Fourth: Interpreting complex data is really, really hard. On a small, knock-it-out project, it is almost certainly doomed to fail. Now reread the 2nd epiphany: On small, knock-em-out projects, it is completely unnecessary.

Right now I’m working on software that reveals entrails to some truly arcane masters of entrail reading. They have become masters because the information system currently available to them is literally designed to protect the data from their eyes. I have found two pieces of data, correlated them, and put them into a report, and they think I’m a super genius. Not because my software is smart, but because it is smart enough to be dumb.

I really like epiphanies where I suddenly realize that it is not necessary to be doomed to failure.

* And if you’re smart enough to reason “but what if you’re using your analytics tool to analyze the sales of your analytics tool”, I congratulate you on your cleverness. Can you also see the flaw in this reasoning?

Two Questions

Posted by David Brady on July 27, 2011 3 comments
spacer

Recently I was talking with a friend about coaching and specifically the act of helping younger developers improve themselves. I had a sort of microepiphany when I realized that I’ve been improving myself for over two decades with the same pair of questions, originally unconsciously and only recently in my active consciousness. The next time you do something you want to get better at, ask yourself these two questions:

What about this makes me feel good? This is a VERY specific question, and it is NOT “what do I like about this?”. It’s often hard to answer. You are not allowed to say “I don’t know”, and you are not allowed to settle for answering the much easier question “what about this do I like?”—although that can be a great guide into discovering what it is that makes you feel good. If you wrote an elegant passage of code, or did something clever, or shipped a really nasty hack but saved the company (thus buying them time to refactor your nasty hack) by shipping on time, that’s what you like. But go beyond this. What about that makes you feel good? Did it make you feel smart? Did it make you feel artistic? Did it make you feel like a hero? Did it make you feel like somehow, against all the odds, you might just be starting to “get it” as a programmer?

Take a moment and really just let yourself feel good about what you did. If you can find that and tap into it, you have just found a well inside yourself that you will return to again and again in the future. Congratulations, you’ve just found the reason you’re going to spend the rest of your life getting better at this.

If you can’t answer this question, don’t sweat it. But don’t be surprised if your life ends up going a different direction. Find something else that makes you feel good, and do that instead.

What about this could I do better? Most days, you’ll think of something right off. There was some duplication, or a lack of symmetry in the code, or your variable names were kind of awkward.

Other days it’s a bit harder. “Writing this bit felt a bit grindy, like I was pushing out lots of boilerplate. I don’t see how to fix it, but does it really have to hurt this much?”

The best days are the days when you try and try and just can’t answer it. Important: this doesn’t mean you did something perfect. Far from it, and far better: it means you’ve actually managed to see your blind spot. “This”, your brain is telling you, “this empty space, here… is where more knowledge will fit.” Those are the days that herald “getting it” on a whole new level.

So, them’s my questions for you. What made you feel good? What could do better?

Felt any good or done any better recently?

Donkeypunching Ruby Koans

Posted by David Brady on July 27, 2011 3 comments
spacer

Do you want instant enlightenment? Sure, we all do.

And now you can have it!

Tonight I presented Ruby Koans at URUG. It started out simple enough, but then we got on a weird quirk about trying to make the Koan tests pass without actually satisfying the test requirements. We monkeypatched Fixnum, then started playing with patching Object#to_s… basically we were looking for TMAETTCPW: The Most AEvil Thing That Could Possibly Work. I spelled Evil AEvil because it’s extra evilly.

Mike Moore had the bright idea to just break off all the assert methods in Test::Unit; after that it just became a challenge to discover how to get the rest of the koans to run at all.

With sincere apologies to Matz, Jim and Joe, here is the result:

https://gist.github.com/1108850

CoffeeScriptCookbook.com: How YOU can help!

Posted by David Brady on May 7, 2011 6 comments
spacer

CoffeeScript is awesome. There’s a HUGE problem with The CoffeeScript Cookbook, however: it does not exist.

Want to help me fix that? Please say yes.

I just bought the domain coffeescriptcookbook.com, and I want to give it to YOU. I mean it. I want to open-source the website code and crowd-source the cookbook content. Partly because I know a lot of folks are WAY smarter than me and partly because I just don’t have enough time to make the CoffeeScript Cookbook as awesome as I need it to be.

Ideally I want to build a sort of “vettable wiki” or perhaps a very trusting git-based website, where people can submit code samples quickly and easily (but still have some way to prevent people publishing XSS attacks without any kind of safeguard). Here’s a short list of what I would like. If any of this enthuses you, please send mail to my gmail account, “ratgeyser”. [Edit: added Geoffrey Grosenbach's excellent tips]

Getting the Cookbook code/site off the ground:

  • Cookbook versioning. As of this writing, CoffeeScript is at 1.0.1. When it updates, I’d like people to be able to see in the cookbook what version introduced or changed a feature, or even to say “I’m using version x.y.z, please only show me valid recipes for that version.”
  • Syntax highlighting. Sort of obvious there, I guess.
  • Examples runnable in-browser, the same way they are on The Main CoffeeScript Website.
  • Automated recipe testing. Essentially, if you submit a recipe that’s supposed to evaluate 3 + 4, you should be able to put something like # => 7 underneath it, and if the code DOESN’T evaluate to 7, the recipe should be flagged as broken.
  • With automated recipe testing in place, we now have the ability to check a recipe against various versions of CoffeeScript. You write a recipe for version 1.1.0, and the site can immediately say “works in 1.1.0 and 1.0.2 and 1.0.1 but not in 1.0.0″. Then it can add those recipes to the cookbooks for those versions. Also, when a new version of CoffeeScript is released, all recipes can be checked against it instantly, and you immediately get a working Cookbook for that version.
  • Website design that doesn’t suck. I’m a programmer, I draw boxes around everything and every website I design looks like ass. And not just regular ass, I mean ass from 1996.

Contributing CoffeeScript Examples

  • Promotes good CoffeeScript style (as opposed to code that compiles but isn’t idiomatic)
  • Helps new programmers learn how to get over common roadblocks
  • Self-checkable examples where possible (see the bit above about automated testing)

Thoughts? Ideas? Offers to help? Let me know!

Tourbus 2 is Out!

Posted by David Brady on May 4, 2011 None comments
spacer

I just released Tourbus 2.0! You can get it by cloning the tourbus repo in that link, or by simply installing the gem from rubyforge.

What’s TourBus?

TourBus is a ruby framework for stress-testing a website. You define “Tourist” classes that “tour” their way through your site, and then tell tourbus to send a load of them at your site.

What’s New

Better Syntax, and tested support for most rubies. TourBus 2.0 has been tested and found worky on:

  • JRuby 1.6.0 <– strongly recommended, as it has better threading
  • MRI 1.8.7p334
  • MRI 1.9.2p180
  • REE 1.8.7-2011.03

Upgrading from Tourbus 0.9

  • Your tour classes will change; they are now called tourists and they go on tours, instead of being called tours who run tests (which really never made sense anyway)
  • Open your tour class, and change it to inherit from Tourist instead of Tour.
  • Change before_tests and after_tests to before_tours and after_tours.
  • Rename all your test_ methods to be tour_ methods. E.g. “def test_simple” => “def tour_simple”
  • That’s it! Tourbus should now run normally.

Quick and Easy Setup

gem install tourbus

Okay, let’s say you have a website running at localhost:3000 and you want to test that home.html includes the text “hi there” even when being pounded by hundreds of visitors at once. Let’s install and set up everything all at once! cd into your project folder, and do the following:

mkdir tours
 
echo 'class Simple < Tourist
  def tour_home
    visit "localhost:3000/home.html"
    assert_contain "hi there"
    end
end' > tours/simple.rb

That’s it, you now have a tourist ready to wander over to your site and request the home page. Let’s run him and see that everything’s okay:

tourbus

You should see a clean run followed by a text report showing what happened. If that worked, let’s make your tourist go through the website 10 times in a row. But let’s ALSO make 100 different tourists to the same 10 laps with him, all at once:

tourbus -n 10 -c 100

Happy server stressing! Check out the README for more info.

Bonus: Isolating Tourbus

Here’s how I like to install tourbus. I cd into my development folder, and then do:
rvm install jruby-1.6.0
rvm use jruby-1.6.0
rvm gemset create tourbus
rvm gemset use tourbus
git clone git://github.com/dbrady/tourbus.git
cd tourbus
gem install bundler
bundle install
gem build tourbus.gemspec
gem install tourbus-2.0.1.gem # (update version if it changes)

Next I cd into my project and do

echo 'rvm use jruby-1.6.0@tourbus' > .rvmrc

This lets me run tourbus under jruby and its own gemset, so even if my website is running rails on MRI, I can still get the lovely JVM native threads when tourbussing my site.

James Edward Gray: Associative Arrays and Ruby Hashes

Posted by David Brady on April 6, 2011 14 comments
spacer

Yesterday I put out a little screencast showing some ways of Creating Ruby Hashes. James Edward Gray II pinged me on Twitter and basically said “Great screencast! Ooh, but you forgot this! Ooh, and this! And this!” and so of course there was nothing to do for it but invite him to do a pairing screencast with me.

This video is a bit of a weird hybrid. You get 7 minutes of podcall, then 18 minutes of screencast, then another 12 minutes of podcall. James shows off some of the “hot new awesomeness” of Ruby 1.9, and then points out that this awesomeness has been around for a couple of years and nobody’s using it, in spite of it having been in the current Pickaxe for nearly as long. Along the way we talk about regular expressions, testing dogma, and the importance of never squashing creativity in the open source community. All in all, an incredibly fun time for me. James threatened to come back and do another one with me on regular expressions, and I’m mentioning it here in writing so that everybody knows I plan on taking him up on that offer.

No podcast, because half of it is us typing into a shared screen session. But here’s the video. You may need to watch it on Vimeo or download it to see the font clearly.

Associative Arrays with James Edward Gray II from David Brady on Vimeo.

Single Responsibility Principle

Posted by David Brady on April 6, 2011 4 comments
spacer

Pat and I are back with another installment of our weird little video podcast! Today we talk about the Single Responsibility Principle, which is at the heart of SOLID. SRP pushes everything out into little classes, and if you want to get anything complex done (like, for instance, you might find in any real program with more than 10 lines of code), you have to build a sort of aggregator object or manager class. Our key question for this podcall is “Even though SRP makes this aggregator class necessary, does the aggregator class itself violate SRP?”

As always we had a great time talking about it. Viewers will be happy to know that we kept the fart jokes to a minimum (I opted to go with Registered Sex Offender humor instead). Viewers distressed by the amount of airtime my cats got last time (and you know who you are, George S. from Utah) will be happy to know that my cat only farts in the microphone once, and she gets less than 10 seconds of airtime doing it. Fair warning: she really works those 10 seconds.

We Still Need a Name For Our Podcast!

Watch or listen to today’s podcast to find out what you can win if you suggest the winning name! Heck, you can win something just by listening! Congratulations to @trptcolin for winning the FIRST copy of Eloquent Ruby we’re giving away. Want to win the second? Listen to the podcast to find out how! Or reread the first sentence of the paragraph extra carefully!

Here’s the audio version: Single Responsibility Principle

And here’s the video, embedded for your viewing pleasure, or head over to Vimeo to download the full-sized 1280×480 version.

Single Responsibility Principle from David Brady on Vimeo.

gipoco.com is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.