A few Hoptoad UI adjustments

Since we launched the Hoptoad redesign we’ve been discussing ways to improve usability which has lead to a few changes as well as some new features. Below is an overview of some of these changes:

Error Index

Error show page

1. Sensible left column: We’ve limited the information on the left to be more global in nature.
2. Error message: We moved the error message to the main column and grouped it with similar information. This allows it to display in a full and unencumbered form.
3. Navigating errors: You can now navigate through similar errors using these handy buttons.
4. Link to GitHub: This button will take you directly to the file in question if it’s available in GitHub.

We’re continuing with improvements throughout the app in order to make daily use of Hoptoad as pleasant as possible. As always, thanks for riding the toad.

regarding-plus-ones

Regarding +1

There's been a little bit of debate over Twitter and on the LRUG mailing list about the validity of "+/-1" as a response. I'm not a huge fan for a few reasons, and I thought it was worth trying to write them down, for my own clarification more than anything else

• It's an oversimplification.
• It doesn't provide any context.
• It's faddish.
• It's lazy.

In general, unless I'm asking a clear yes-or-no question, and I've explicitly said that I don't want to entertain discussion, I think I would prefer to not hear from anyone who only responds with '+1'.

Disclaimer

Bear in mind that these are just my cranky opinions, the internet is for the young and I am so old now. So very, very old. So please don't be offended if you disagree, and/or you love +1-ing things left, right and centre. It could well be that I'm wrong.

Except I'm not.

Here's why:

It's an oversimplication

Let's imagine that you and I are good friends. I write you an email one day:

Hey, come round to my place and lets have some dinner.

You respond

+1

Apart from sounding a bit like a weird robot (and we'll get to that later), all I can infer from that is... some sort of positive response. The conversation hasn't really progressed, other than I know that you're happy to come round and eat my food. Beyond that, I don't really know any more about what you think about dinner. To be honest, you're sounding pretty ungrateful, but we're buddies and so I'll forgive you.

It doesn't provide any context

So you're coming round for dinner, and I'm cooking up some delicious Steak Tartare. Or not cooking in this case, because that's raw beef mince with raw egg and a little bit of seasoning. Drooling yet?

In your '+1' response, you basically gave up your opportunity to provide any context about what you might like. You could've told me what sort of food you like, or any ingredients that you've recently become allergic to (you are a bit of a hypochondriac, but we'll save that for a proper intervention, this is just dinner). You could've said something like

Sounds good. I feel like Mexican, what do you think? How about I bring the nachos and some tequila?

But no, all I get is a +5V on pin 1 of the conversation. Do you even have thoughts or feelings? Do you know what it means to cry, but it's something you can never do? YOU ROBOT.

It's faddish

We know each other, and so you know that we both love technology more than life itself. Except, well... I am also a person too. And I like conversation, and language. If all I interested in was sounding like a computer to my computery friends, why would I bother leaving my sweet DSL connection to come round for food? I could just dial up Pizza Hut and say "aaaaaaaaffirmative" when they asked me if I wanted my Meatsplosion Special on their new wrapped-entirely-in-cheese-then-deep-fried base.

But I'm not like that; I'm literate, and I like talking to other people because that's more interesting. If our dinner conversation is going to be along the lines of "Hey, did you like the BSG finale?", «(robot voice) MINUS ONE» then I'm probably not going to invite you back for a while.

Yes, it seems to be all the rage now in our computery circles, and everyone's doing it, but that doesn't mean that it's cool. I'd rather know a bit more about what you're thinking. Hence:

It's lazy

Yep. Twitter and text messages have taught us the value of brevity, but at what price? Now everything seems to be either awesome or MADE. OF. FAIL. and so on, without any kind of context or reasoning.

Your '+1' doesn't tell me anything about why you are in favour of something; it's simply the fewest characters you could type to increase the likelyhood of something happening in a way you just to be positive for yourself. Is it really so much more expensive for you to saying something along the lines of "Sounds good, great suggestion", that you can't take the extra time to do it?

Use your words, my friend. Use your words.

ARGARGAGARAHGRAHGARAHRGHARHFAHARGHarghahrahgrahgrhahahaaaaaaaaaargargarghahrag ahahaharhaghrahgrajraHGEHRGARHGEHRHAERGHAERGHAERGHAEHGRAEIAEIADFSADPSAFPAPERPJO AERJPGAEP EGRAOPAPOERAJUAPIJGAE?IGAHAEHAGERHERIAHPIFIAPWIEFAPWJR(A£F)J(J£$FW@JF(WFJ£F JC(£$JVAJVM£JA£$)(G£GCJ A£GJ ok I'm fine now. Please continue with your emailing and stuff.

Agile JavaScript Testing

A couple weeks ago, I gave a talk at the Open Source Bridge conference in Portland Oregon on Agile JavaScript Testing.

In this presentation, I first gave an overview of Test Driven Development for those front-end JS developers who might not have heard of it yet (!) and then the difference of TDD vs. Behavior Driven Development.

I then walked through some tools:

• Screw.Unit, a nice BDD framework for JS that is quite similar to RSpec in Ruby land.

• Blue Ridge, a plugin for rails that integrates Screw-Unit with Rhino and Env.js and some rake tasks to create a command-line driven headless (no-browser == fast) testing workflow.

• JS Test Driver, a project that mounts one or more browsers as slaves, and a command-line tool which notifies all the listening browsers to run tests and aggregates the results. Very cool!

In the actual presentation I even did some live coding examples of Blue Ridge and JS Test Driver, and they worked perfectly. Here are the slides from the talk:

Presentation:Multicore Programming in Erlang

Ulf Wiger shows typical Erlang programs, patterns that scale well on multicore and patterns that don't, profiling and debugging parallel applications and ensuring correct behaviour with QuickCheck. By Ulf Wiger

Avoiding nested blocks

Today I had to silence some output streams so that messages don’t pollute the STDOUT. I used the silence_stream method built into Rails, described well in this article.

Very nice, except I also wanted to filter STDERR output. Not a problem.

Well, shit. Here I got a “too many arguments” error. So it doesn’t support multiple streams. I guess it wants me to be ugly.

I personally don’t take kindly this level of suckiness around here. I want example #2 to work. Well, after lighting some candles and praying to the Ruby gods, I came up with a scary implementation. In fact it’s so spooky that it may have the same effect as glancing at the Mexican Starting Frog of Southern Sri Lanka. You may then throw a chair at me on the Jerry Springer show, so I rather not show it to you.

However, after having cleansed my .rb file with some broc flowers and xander roots I came up with a better solution. Recursion is the key. See if you can understand what is happening.

This is a basic use of recursion, which is not immediately clear when dealing with nested Ruby blocks. When multiple streams are passed in I’m popping out the last stream and silencing it alone, then calling the same method with the remaining streams. This is happening until only one stream left to silence. The last one gets silenced with the original block passed in, which means that the original block is executed at the deepest nesting level, where all passed streams are silenced. As a result I got this much desired functionality without resorting to eval, yay.

There we go. This solution can be applied to cases where you’d rather avoid overriding stuff (thus keeping out of method implementation details).

Update: Made recursion more concise thanks to apeiros on #railsbridge.

Avoiding nested blocks

Today I had to silence some output streams so that messages don’t pollute the STDOUT. I used the silence_stream method built into Rails, described well in this article.

  silence_stream(STDOUT) do
    # ...my code...
  end

Very nice, except I also wanted to filter STDERR output. Not a problem.

  silence_stream(STDOUT, STDERR) do
    # ...my code...
  end

Well, shit. Here I got a “too many arguments” error. So it doesn’t support multiple streams. I guess it wants me to be ugly.

  silence_stream(STDOUT) do
    silence_stream(STDERR) do
      # ...my code...
    end
  end

I personally don’t take kindly this level of suckiness around here. I want example #2 to work. Well, after lighting some candles and praying to the Ruby gods, I came up with a scary implementation. In fact it’s so spooky that it may have the same effect as glancing at the Mexican Starting Frog of Southern Sri Lanka. You may then throw a chair at me on the Jerry Springer show, so I rather not show it to you.

However, after having cleansed my .rb file with some broc flowers and xander roots I came up with a better solution. Recursion is the key. See if you can understand what is happening.

def silence_streams(*streams, &blk)
  silence_stream(streams.pop) do
    if streams.empty?
      yield
    else
      silence_streams(*streams, &blk)
    end
  end
end

This is a basic use of recursion, which is not immediately clear when dealing with nested Ruby blocks. When multiple streams are passed in I’m popping out the last stream and silencing it alone, then calling the same method with the remaining streams. This is happening until only one stream left to silence. The last one gets silenced with the original block passed in, which means that the original block is executed at the deepest nesting level, where all passed streams are silenced. As a result I got this much desired functionality without resorting to eval, yay.

  silence_streams(STDOUT, STDERR) do
    # ...my code...
  end

There we go. This solution can be applied to cases where you’d rather avoid overriding stuff (thus keeping out of method implementation details).

Update: Made recursion more concise thanks to apeiros on #railsbridge.

Avoiding nested blocks

Today I had to silence some output streams so that messages don’t pollute the STDOUT. I used the silence_stream method built into Rails, described well in this article.

  silence_stream(STDOUT) do
    # ...my code...
  end

Very nice, except I also wanted to filter STDERR output. Not a problem.

  silence_stream(STDOUT, STDERR) do
    # ...my code...
  end

Well, shit. Here I got a “too many arguments” error. So it doesn’t support multiple streams. I guess it wants me to be ugly.

  silence_stream(STDOUT) do
    silence_stream(STDERR) do
      # ...my code...
    end
  end

I personally don’t take kindly this level of suckiness around here. I want example #2 to work. Well, after lighting some candles and praying to the Ruby gods, I came up with a scary implementation. In fact it’s so spooky that it may have the same effect as glancing at the Mexican Starting Frog of Southern Sri Lanka. You may then throw a chair at me on the Jerry Springer show, so I rather not show it to you.

However, after having cleansed my .rb file with some broc flowers and xander roots I came up with a better solution. Recursion is the key. See if you can understand what is happening.

def silence_streams(*streams, &blk)
  silence_stream(streams.pop) do
    if streams.empty?
      yield
    else
      silence_streams(*streams, &blk)
    end
  end
end

This is a basic use of recursion, which is not immediately clear when dealing with nested Ruby blocks. When multiple streams are passed in I’m popping out the last stream and silencing it alone, then calling the same method with the remaining streams. This is happening until only one stream left to silence. The last one gets silenced with the original block passed in, which means that the original block is executed at the deepest nesting level, where all passed streams are silenced. As a result I got this much desired functionality without resorting to eval, yay.

  silence_streams(STDOUT, STDERR) do
    # ...my code...
  end

There we go. This solution can be applied to cases where you’d rather avoid overriding stuff (thus keeping out of method implementation details).

Update: Made recursion more concise thanks to apeiros on #railsbridge.

My Apprenticeship - Thursday, July 15, 2004

This summer I'm revisiting my short apprenticeship at Object Mentor. I'll be posting commentary on all my posts from the summer of 2004 exactly 5 years later to the day.

Turns out most Linux installs come with Apache, PHP, and MySQL -- this supporting of common developer tools was weird to me coming from Windows where if it's remotely useful it must have a heinous install and cost a lot of money.

Why was I going to Canada? Because that year's XPAU (Extreme Programing Agile Universe (Now just called Agile as in 'Agile 2009' - have I mentioned that I'm speaking at it?)) was in Calgary that year. Object Mentor used to organize XPAU, so it was a pretty big deal for them. And me. I think this might have been the last year Object Mentor was running the show.

Behind the scene: Quiltivate.com a beautiful Flex on Rails website.

I met Phil several years ago at Derailed, the (Denver Ruby on Rails user group, and for a long time he was curious about how Flex can be integrated with Rails, about the graphical possibilities that Flex offers, the advantages over plain HTML/CSS/Javascript. Then he told me Kacie, his wife, had an idea about a website. She is passionate about quilts and has an eye for details and excellence. Phil is a geek that loves Rails, Kacie loves quilts, it's like Quilting meets Web 2.0 and quiltivate.com was born. In fact Phil and Kacie hired me to create a Quilt Builder that integrates with Quiltivate.com. Kacie had the vision for the whole concept, a simple to use quilt builder that removes lots of the hassle of calculating how much fabric of what color is needed and allows to play with blocks, shapes and colors. She drew a paper prototype that really highlights the tag line of their site" Innovating Traditional Quilting". Quiltivate.com offer much more than a Quilt Builder, it's a blog and a community centered around the art and craft of quilting. Over the last year I spent a couple of hours here and there, well a little more than that, to transform the paper prototype into a real Flex application. Rather than writing about what the tool does and how it does it, let's have a little look at behind the scene of the Quilt Builder with this video: <object width="400" height="300"><param name="allowfullscreen" value="true"/><param name="allowscriptaccess" value="always"/><param name="movie" value="http://vimeo.com/moogaloop.swf?clip_id=5619106&amp;server=vimeo.com&amp;show_title=1&amp;show_byline=1&amp;show_portrait=0&amp;color=&amp;fullscreen=1"/><embed src="http://vimeo.com/moogaloop.swf?clip_id=5619106&amp;server=vimeo.com&amp;show_title=1&amp;show_byline=1&amp;show_portrait=0&amp;color=&amp;fullscreen=1" type="application/x-shockwave-flash" allowfullscreen="true" allowscriptaccess="always" width="400" height="300"></embed></object>

Behind the scene: Quiltivate.com a beautiful Flex on Rails website. from daniel wanja.