Diligent Designer - Home

Unfortunate Word Wrapping

2008-05-10T02:05:56Z

I’ve always been suspicious of copy meant for web pages.

Leaving your beautiful layout to the vagaries of browser quirks and user font choices seems kind of like crafting a beautiful print piece and then sending it off to the printer knowing they’re likely to substitute their local (or arbitrary) version of the font metrics; and you’ll never see the final piece. It gets sent straight to the customer or public from the printer.

That’s what web layout feels like sometimes. No wonder there’s a significant strata of designers who gravitate towards Flash for their web designs.

I found a great example in my surfing tonight (I don’t think God would wear a shirt like that).

Source: puregospeltruth.com

Ruby Studio Review

2008-03-07T07:12:00Z

Thoughts on Pragmatic Studios’ Ruby Studio

I snapped a few pictures with my little digital camera just to get at least some kind of visual record. Certainly nothing like the last studio I was at where James Duncan Davidson was taking pictures like this.

Last week I was able to attend the Ruby Studio in Denver put on by guys at The Pragmatic Studio. It was a great experience and I highly recommend it to anyone who is serious about learning Ruby for professional or personal use. Dave Thomas and Chad Fowler both did a great job of instructing and connecting with their audience.

Here are few of my thoughts/suggestions for anyone who is considering attending:

1. Sit close to the front and engage with the instructors. You (or someone who cares about you) will be investing alot of time and money so you can be there; make the most of it. Dave and Chad were great about answering questions and seemed to enjoy the audience interaction. Just don’t ask questions to pontificate or try to impress Dave or Chad (or the rest of the group); chances are they won’t be.

2. Listen to Nicole Clark (The event coordinator/boss) when she suggests that you turn off your internet connection during the day (they provide wireless access). On the first day I was probably as much a culprit as the next person about checking email, etc. By the second day I was able to stay off (except for a few quick checks during breaks) and enjoyed completely focusing on the programming tasks at hand.

3. Bring a Mac and use TextMate. I felt bad at times for those in the audience without the Mac/TextMate combo because that is what both Dave and Chad were using from the front. The code->test->code cycle went very fast at times and, although the integration is really cool between OSX, Ruby, Textmate and Terminal, for those without that setup it must have been frustrating to watch and not emulate. One of the reasons I think I was able to keep up is that I had the same software/workflow setup that was being demonstrated. If you’re using some other setup, come prepared and already knowing the workflow of how to write, run and test simple ruby programs in your environment— it’ll pay off. (A personal confession: Attending the Rails Studio in Jan ‘06 with my Dell laptop and watching Dave and Mike demo code with TextTate on the Mac and seeing so many guys around me working with on MacBook Pros was the last little nudge that pushed me into finally moving back to Macs after many years of Windows use. I’ve never looked back.)

4. Make the effort to meet other people there. I found that it was a tough balance at times between wanting to really focus on learning and the benefit of getting to know fellow attendees. While lunches are a great time to spend time getting to know fellow attendees, I think they could have structured a few networking/social opportunities for one or more of the evenings; that would have helped break the ice even more. The alumni-only mailing list/yahoo group is a great place to foster and continue relationships after the event.

5. Follow (and type) along in TextMate (or your editor) with Chad and Dave’s examples. One of the things I found to be most helpful was to actually type the code they were demonstrating on the screen. There were only a one or two times when I fell far enough behind that it was a problem. The rest of the time I was benefiting from actually typing and running the code we were discussing. I created a “Ruby Studio” project in TextMate and then a subfolder for each day. I started a new file for each new topic, section or module they demonstrated. I also kept a general notes file open where I would jot general notes. Here’s a sample from the first day:

Learning to program like a Ruby programmer--learning the idioms of Ruby

The soul of Ruby is in Japan. A different philosophy of programming. Wabi-sabi (sp?)

Use MacPorts for macs on ruby

Ruby is wonderfully self-contained (install in self-contained paths)

Updating gems doesn't overwrite older versions of gems

# Update gem itself
sudo gem update --system

Add a -y flag to gem install to default to yes to install dependencies

gem dependency rails

Consider using gems for internal projects as well.

6. Buy, read and bring Dave’s Programming Ruby (Pickaxe) book with you. You will will be glad you did. Not only will you have a better understanding of the material (and can better appreciate the personal observations and nuances from Dave and Chad), but you’ll also find some eerie similarities between the examples in the book and the ones used in class. (Ask Dave to autograph your book; I think he secretly gets a kick out of it; I know I would.)

7. Know what you want to get out of the three days and have a plan. I came with a specific goal in mind of getting over a hump in my Ruby programming. I’m happy to report that my time at Ruby Studio did exactly what I had hoped it would. I’m now much more able to get down to writing and implementing ideas with Ruby; instead of having to stop and look up syntax, examples and patterns every few seconds. It was very gratifying to dig into the guts of the Capistrano gem when I got home after the Studio and really understand what was going on with the code (One of Chad’s suggestions for followup work was to download some popular gems and look through the Ruby code).

Let’s face it, this kind of focused and expert training doesn’t come cheap (If you’re not local to the training location you’re looking at spending on the north side of $2,000 between tuition, travel and lodging). I feel grateful to have the resources to be able to attend and I’ve been very happy with my two experiences so far with Pragmatic Studios.

It’s not easy to put on an excellent multi-day training seminar and these guys do a very good job of it. I believe you’ll come away confident and inspired to go out and create great applications using Ruby.

The next Ruby Studio is slated for this summer.

Fun with Autotest & Growl

2008-02-22T22:21:00Z

So tonight I was about halfway into Geoffrey Grosenbach’s RSpec Mocks and Models screencast and remembered that I had run into a roadblock the other night trying to get autotest to run correctly. I couldn’t very well be attempting BDD without a functioning autotest. And of course I couldn’t very run autotest without implementing growl notifications. And of course I couldn’t implement growl notifications without making some cool graphics that would make me happy every time I saw them.

So, being the “leans-more-toward-designer-than-developer” kind of developer that I am—here I am <strike>two</strike> <strike>three</strike> four hours later, having a ball, but not much closer to really getting my mind wrapped around RSpec and BDD. I did finally get autotest and the growl notifications working and enjoyed a fun little Photoshop diversion—plus I got some time in on my new publishing platform (still tweaking styles and layout of my Mephisto blog theme).

I’ve recently committed to trying to give back a little to the ruby/rails online community that has helped me so much over the years. So I decided to take the time to put the files up tonight (along with the code I found worked for me, and a simple screencast so you can see them in action). Maybe someone will find these useful and perhaps even enjoy their development a tiny bit more.

Download Brief Screencast

FunwithAutotestandGrowl_Fnl.mov (9mb Quicktime File)

Graphic files:

pass.png
pending.png
fail.png
AutoestGrowlButtons.psd.zip (Photoshop source file)

~/.autotest listing

  require 'autotest/redgreen'
  require 'autotest/timestamp'

  module Autotest::Growl
    def self.growl title, msg, img, pri=0, stick=""
      system "growlnotify -n autotest --image #{img} -p #{pri} -m #{ msg.inspect} #{title} #{stick}"
    end

    Autotest.add_hook :ran_command do |autotest|
      output = autotest.results.grep(/\d+\s.*examples?/).last.slice(/(\d+)\s.*examples?,\s(\d+)\s.*failures?(?:,\s(\d+)\s.*pending)?/)
      # if output =~ /[1-9]\sfailures?/ 
      if output =~ /[1-9][0-9]?\sfailure/
        growl "Test Results", "#{output}", "~/Library/autotest/fail.png", 2, "-s"
      elsif output =~ /pending/
        growl "Test Results", "#{output}", "~/Library/autotest/pending.png"
      else
        growl "Test Results", "#{output}", "~/Library/autotest/pass.png"
      end
    end
  end

Lessons Learned

The problem I had with getting autotest to work had to do with version conflicts between zentest and rspec. Just be aware that it can potentially exist and Google your way through it. I can’t even remember how or what I changed anymore to get it working, but I am using the following versions successfully as of this writing: rspec (1.1.3), ZenTest (3.9.1), rails (2.0.2).

Acknowledgements:

Geoffrey Grosenbach for his excellent PeepCode screencasts that have helped me so much.
James Deville for the writeup and code that worked for me and my setup. (Be sure to read Eric Wollesen’s comment with an update to the regex.)

Reference

RSpec Basics Peepcode Screencast (peepcode.com)
Setting up autotest to use Growl (wincent.com)

Rails Diagramming Stencil for OmniGraffle

2008-02-10T22:00:00Z

I created some stencils for OmniGraffle that help with designing the schema of your application. The stencil file is posted on Graffletopia for download.

Excerpt from the site:

Some helpful stencils for designing your database and models. Sort of an Entity Relationship Diagram (ERD) with some added stuff that helps me think through what’s going to go on when I get to coding.

Don’t feel bad if (like me) you are more of a Designer/Developer and just use the plain arrow to connect things. The ERD stuff can make your head explode if you go too deep.

In case you’re new to these kinds of things, you can add more name/type rows to the tables by clicking in a row and hitting Cmd-Enter (or menu Edit -> Tables -> Insert Row). That one was not so obvious to me initially either.

Take it all in

2008-02-04T16:08:00Z

A Super Bowl Moment of Wealth

Although I can’t say I was enthralled with the Super Bowl this year, the last few minutes were as compelling as almost any other game this year.

A tiny flicker of a moment at the conclusion of the game caught my attention and has stayed with me overnight.

In the chaotic conclusion following the end of the game, a cameraman caught Giants punter Jeff Feagles celebrating with his wife and son on the field. Although they were obviously enjoying the moment, the capturing of them seemed an afterthought to the cameraman and producer; almost as if they caught that moment while desperately trying to cue up one of the stars. But in that brief moment they captured, what was to me, the most wealthy moment of the night. Feagles’ son, while exulting in the experience of being down on the winning Super Bowl field, looked up at his dad, dazed, seemingly needing help understanding how to deal with the emotions and experience. His dad just looked at him and said. “Just take it in son. Just take it all in.”

Take it in. Take it all in.

Dieter Rams' 10 principles for good design

2008-01-17T19:02:00Z

This passion for “simplicity” and “honest design” that is always declared by Ive whenever he’s interviewed or appears in a promo video, is at the core of Dieter Rams’ 10 principles for good design:

• Good design is innovative. • Good design makes a product useful. • Good design is aesthetic. • Good design helps us to understand a product. • Good design is unobtrusive. • Good design is honest. • Good design is durable. • Good design is consequent to the last detail. • Good design is concerned with the environment. • Good design is as little design as possible.

From: 1960s Braun Products Hold the Secrets to Apple’s Future

The US ZIPScribble Map

2006-12-22T19:42:00Z

I found this interesting zip code resource/artwork at result is surprising and much more interesting than expected.

Dance Close to the Revenue Line

2006-11-10T13:39:30Z

My last trip to the bookstore, I happened upon a provacatively titled “Never Check E-Mail in the Morning” by Julie Morgenstern during my habitual graze through the business section. Despite being a sucker for business and personal development books, I’ve lately been in an “I’ll pass” phase. Nevertheless, something about the book pinged my intuition as I gave it the once-over. This one was going to have at least one great nugget inside—I felt it. I bought it and put it in my normal to-read cycle (briefcase-~~>desk~~->briefcase-~~>nightstand~~->).

I grazed through it once or twice over the past week and then started diving in today. Bingo. There it was on page 72 (of the Fireside paperback).

Dance Close to the Revenue Line

“Everything you spend your time on should be assessed in terms of its proximity to the revenue line. What’s the revenue line? It’s the point at which your company is actually making or saving money.

“Which of the tasks on your to-do list are closest to your company’s revenue line? In most cases, it’s the activity that will immediately do the following:

Generate revenue
Create the product or deliver the service
Save the company money