Methodphitamine - I'm hooked without even using it

Posted about 7 years back at The Hobo Blog

Now that is going straight into Hobo’s core extensions. Thanks for sharing Jay!

Meaning I can finally get rid of all that omap, oselect nonsense (if you didn’t notice those methods, don’t even ask, it was a bad idea. If you did and you use them - stop!)

Hmmm. Maybe it’s time to make this stuff available in a separate gem. HoboSupport? It’s starting to bug me when I’m in a non-Hobo script and all this stuff is missing.

p.s. Hobo 0.6.1 coming today!

Methodphitamine - I'm hooked without even using it

Posted about 7 years back at The Hobo Blog

Now that is going straight into Hobo’s core extensions. Thanks for sharing Jay!

Meaning I can finally get rid of all that omap, oselect nonsense (if you didn’t notice those methods, don’t even ask, it was a bad idea. If you did and you use them - stop!)

Hmmm. Maybe it’s time to make this stuff available in a separate gem. HoboSupport? It’s starting to bug me when I’m in a non-Hobo script and all this stuff is missing.

p.s. Hobo 0.6.1 coming today!

Ruby Hoedown Videos

Posted about 7 years back at Alloy Code - Home

The Ruby Hoedown conference sessions are now available online from the Confreaks website.

Personally, my top picks for “must view” are:

  1. Using C to tune your Ruby (or Rails) Application
  2. Charity testing workshop
  3. Exploring Merb

Interestingly, while I was listening to Ezra’s presentation on Merb the first time, I kind of missed the point. The real power and purpose of Merb didn’t start sinking in for me until the second day, when I realized that there was a much bigger audience for a thread-safe, ActionPack-decoupled, performance tuned web framework. The validity of Ezra’s talk was reinforced by others, particularly Bruce Tate, who helped push the point home that Rails was just one stop on the Ruby journey. And, of course, it’s especially timely, considering the current dust-up over Pete’s Swanky Framework

Ruby Hoedown Videos

Posted about 7 years back at Alloy Code - Home

The Ruby Hoedown conference sessions are now available online from the Confreaks website.

Personally, my top picks for “must view” are:

  1. Using C to tune your Ruby (or Rails) Application
  2. Charity testing workshop
  3. Exploring Merb

Interestingly, while I was listening to Ezra’s presentation on Merb the first time, I kind of missed the point. The real power and purpose of Merb didn’t start sinking in for me until the second day, when I realized that there was a much bigger audience for a thread-safe, ActionPack-decoupled, performance tuned web framework. The validity of Ezra’s talk was reinforced by others, particularly Bruce Tate, who helped push the point home that Rails was just one stop on the Ruby journey. And, of course, it’s especially timely, considering the current dust-up over Pete’s Swanky Framework

Go get it

Posted about 7 years back at The Hobo Blog

And finally…

Also note we’re now on rubyforge so you could always just gem update hobo (subject to rubyforge delays – I only threw it up there one minute ago)

The demos on the site have not been updated, nor has the manual I’m afraid to say. But work on updating the manual is already underway so hopefully it won’t be all that long.

Have fun!

Go get it

Posted about 7 years back at The Hobo Blog

And finally…

Also note we’re now on rubyforge so you could always just gem update hobo (subject to rubyforge delays – I only threw it up there one minute ago)

The demos on the site have not been updated, nor has the manual I’m afraid to say. But work on updating the manual is already underway so hopefully it won’t be all that long.

Have fun!

Automated testing of websites via “real” users.

Posted about 7 years back at work.rowanhick.com

Of all the testing we can do, there's nothing quite like firing up your browser and navigating to the website in question, logging in and doing stuff. All of the integration tests, port tests, contrived "I'm alive" tests etc can give you an *indication* that your website code is all well and good. However what you really want to test is "can I jump to it, do x y z action, and complete those actions without it bombing out". We have a two options, we hire an army of minions who will do that for us every 15minutes on the dot OR we could do it automatically. How do we do this ? Well there are a number of ways. One option I'm going to walk through is using the magic genius of Safari Watir, RSpec tests, ruby, a few gems, cron and any Mac you can lay your hands on. We set this up a while ago monitoring some of our sites and it's great for finding out when something in your webstack has fallen over. For a < $1k investment it's a no brainer for any web site. Caveat - this ain't going to test your flash/flex content - this is just for HTML based sites. Read on... 1. Machine setup First, take one mac mini. We need to install ruby, ruby gems, rails, rspec, safariwatir, and rb-applescript bridge on it. Follow the Hivelogic narrative here for instructions on installing a full rails stack. Then just simply run these commands to finish off the last remaining gems. sudo gem install rspec sudo gem install safariwatir --include-dependencies 2. First website check So we've got our infrastructure setup. Now we need to write the scripts that actually run the test the site. These will fire up safari and tell it to navigate to various URL's, then check the content on the pages returned. So in true behaviour driven development style we write a spec that in plain english walks through the steps. It fires up a browser instance courtesy of Watir::Safari.new and uses it to navigate around pages. First let's create a file called check_google.rb like so: require 'rubygems' require 'safariwatir' context "With www.google.com" do before(:all) do @browser = Watir::Safari.new end it "can navigate to home page" do @browser.goto("http://www.google.com/") end it "homepage should not have a 404" do @browser.contains_text("404").should == nil end #it "should throw an contrived error, when seeing if yahoo is on main page" do # @browser.contains_text("www.yahoo.com").should == true #end after(:all) do @browser.close end end Now if we run spec check_google.rb we get output as follows: RowanH$ spec check_google.rb .. Finished in 2.818356 seconds 2 examples, 0 failures Fantastic, it's what we expect google is alive and tickety-boo. Now to check the failure scenario, uncomment the yahoo test: RowanH$ spec check_google.rb ..F 1) 'With www.google.com should throw an contrived error, when seeing if yahoo is on g main page' FAILED expected: true, got: nil (using ==) ./test_mysite.rb:18: Finished in 2.837444 seconds Cool, we know what a failure looks like. 3. Turning your console output into a email message We're not going to be logging in and doing this all the time, so we want to be emailed of success/failures. We are going to use a custom formatter for RSpec, which can make our output look a lot more interesting and pop it into an email. As I was running these scripts on a machine with a full rails stack I used ActiveMailer for sending emails.. (you'll see why in a minute) so let's create a custom formatter that will format our output for mailing. Lets call it mail_formatter.rb and pop it into the same place as our existing scripts - as follows. require 'rubygems' require 'action_mailer' #actual email thingy ActionMailer::Base.server_settings[:address] = 'domain@myhost.com' class Emailer < ActionMailer::Base def test_email(text, status) subject "TEST Autotest Status - #{status}" from "mytestbox@myhost.com" recipients "me@myhost.com" body text end end class MailFormat < Spec::Runner::Formatter::BaseTextFormatter def start(spec_count) @mail_output = String.new @mail_output << "Test started \n" @mail_status = "Tests OK" end def add_behaviour(name) @mail_output << "\n #{name}\n" end def example_failed(example, counter, failure) @mail_output << " - #{example.description} FAILED \n" @mail_status = "#{counter} tests FAILED" end def example_passed(example) @mail_output << " - #{example.description} PASSED \n" end def dump_summary(duration, spec_count, failure_count, something_else) @mail_output << "\n" @mail_output << "Finished in #{duration} seconds " @mail_output << "#{spec_count} test#{'s' unless spec_count == 1}, #{failure_count} failure#{'s' unless failure_count == 1}" Emailer.deliver_test_email(@mail_output, @mail_status) end end Right so this time if we a new command like so, to require the mail_formatter, and output in mail format, we should by rights receive an email: RowanH$ spec check_google.rb -r mail_formatter.rb -f MailFormat 1) 'With www.google.com should throw an contrived error, when seeing if yahoo is on main page' FAILED expected: true, got: nil (using ==) ./test_mysite.rb:18: (we still get our console output if we get a failure) 5. Automating it Okay so wrap that lot up in a shell script, and call it via cron (hey I'm not going to write *everything* out here), and you've now got a simple script that's calling up your website and checking it. 6. Extending it If you browse around for some of the safari-watir examples out there then you'll see more of how to access specific fields and named form elements - this will let you actually login and do stuff on your site(s) your testing. 7. Extra Credit - Screenshots!! Okay, we've got our system emailing us every test. But what would be really cool is if it actually sent us a screenshot everytime something turned to custard and failed so we could see what actually went wrong. Well... it's suprisingly easy. We're going to use OSX's inbuilt screencapture utility and fire off a shell command to capture a png file everytime something goes wrong. Then pop those in as attachments to our status email. Modify the code like so: In the Emailer.test_mail method, add a parameter images, and pop this code at the bottom of the method: if ( images ) for image_name in images attachment :content_type => "image/png", :filename => image_name , :body => File.read("/Users/rowanh/Desktop/failed_images/#{image_name}") end end So this will allow our email method to read in a list of images and attach them to mail message. Next we want to update our formatter. For the start method add the following: @failed_image_count = 0 @failed_images = Array.new Add a new method like so : def take_screenshot() @failed_image_count += 1 screenshot_name = "failure_#{@failed_image_count}.png" system "screencapture /Users/rowanh/Desktop/failed_images/#{screenshot_name}" @failed_images << screenshot_name end Next update example_failed so it takes_screenshot. Finally in the deliver_test_email method, pop in the @failed_images array. Conclusion Bingo! you now have a hugely useful tester, that runs away, tests your website, tells you and will actually show you what went wrong. For not a whole lot of investment. Off to setup a continuous integration machine that actually does this for each build........ Credit: http://blog.aslakhellesoy.com/2006/12/2/getting-screenshots-from-watir http://redsquirrel.com/cgi-bin/dave/projects/watir

@media Ajax Is Scarily Good

Posted about 7 years back at danwebb.net - Home

@media Ajax It seems that the @media Ajax site has just been updated. I was looking forward to it before but more speakers have been added including Brendan Eich who, according the abstract, will be demonstrating a working version of Tamarin in Firefox!

Also, Dojo’s Alex Russell, jQuery’s John Resig, YUI’s Douglas Crockford and Prototype’s erm, me will be representing the major libraries and then there’s the Ajaxians, Ben and Dion stepping up for a keynote. Finally, Mr Jeremy Keith will be hosting the hot topics panel in the traditional @media style – Hot Topics panel + JavaScript people should be quite explosive. As it was put in the Prototype Core Campfire the other day, “The JavaScript community is not so much of a community, more of a debating society” It’s going to be excellent. Of course, as it’s in London town you know we’ll be sinking a good few pints after. It will be a rare chance to get together with fellow scriptie types this side of the pond and the only pub conversation you’ll ever be allowed to mention closures in….surely that’s a good thing?

There are still early bird tickets left until the end of august so get your arse down to the site and sign up.

My presentation, Metaprogramming JavaScript, is for all those people who moan that they never learn things at conferences. It’s journey into the deep innards of JavaScript and I’ll be explaining the some of the metaprogramming techniques used in YUI, Prototype and Low Pro along with really getting into advanced JavaScript concepts like prototype inheritance, functional programming and closures. I defy you to turn up and not learn something new.

NHRuby: Shoes. And Belts. And You!

Posted about 7 years back at zerosum dirt(nap) - Home

If you’re in the greater NH/Maine/Mass seacoast area, don’t forget to check out tomorrow’s NHRuby group. Sir Brian DeLacey will be visiting us from Boston and talking about Shoes, the Ruby desktop UI toolkit from the ever-enigmatic _why.

If there’s time left to spare, I’ll probably spend some time blathering on about how you should participate in the upcoming Rails Rumble. Believe me, after seeing some of the prizes, you’re going to want to get in on the action. I was dead f**king serious about that championship belt. You’ll see.

Episode 67: restful_authentication

Posted about 7 years back at Railscasts

Need multiple user authentication? If so, the restful_authentication plugin is a great way to go. It will generate some basic authentication code for you which is good starting point to your authentication system. Watch this episode for details.

Testing the Right Stuff

Posted about 7 years back at The Rails Way - all

I’m going to take a slightly different tack here, and review some of the unit tests in rails itself. They show up two common anti patterns, spurious assertions and coupling your tests to the implementation.

Perhaps the biggest benefit of a suite of unit tests is that they can provide a safety net, preventing you from accidentally adding new bugs or introducing regressions of old bugs. With a large codebase, the unit tests can also help new developers understand your intent, though they’re no substitute for comments. However if you’re not careful with what gets included in your test cases, you can end up with a liability.

Be careful what you assert

Whenever you add an assertion to your test suite you’re sending a signal to future developers that the behaviour you’re asserting is both intentional and desired. Future developers who try to refactor your code will see a failing test, and either give up, or waste time trying to figure out if the assertion is ‘real’ or whether it was merely added because that’s what the code happened to do at present.

For an example, take the test_hatbm_attribute_access_and_respond_to from associations_test.rb , especially the assertions that the project responds to access_level= and joined_on=. Because of the current implementation of respond_do?, those assertions pass. But should they?

In reality while those values will get stored in the object, they’ll never be written back to the database. This is a surprising result for some developers, and removing those accessor methods would go a long way to helping avoid some frustrating moments.

Mock and Stub with care

Mock object frameworks like flexmock and mocha make it really easy to test how your code interacts with another system or a third party library. However you should make sure that the thing that you’re mocking doesn’t merely reflect the current implementation of a method. To take a case from rails, take a look at setup_for_named_route in routing_test.rb.

It takes the seemingly sensible approach of building a stubbed-out implementation of url_for instead of trying to build a full implementation into the test cases. The stubbed version of url_for simply returns the arguments it was passed, this makes it extremely easy to work with and to test.

The problem is not with stubbing out the method, but in the way it is used in all the named route test cases. Take test_named_route_with_nested_controller.

1
2
3
4
5
6
def test_named_route_with_nested_controller
  rs.add_named_route :users, 'admin/user', :controller => '/admin/user', :action => 'index'
  x = setup_for_named_route.new
  assert_equal({:controller => '/admin/user', :action => 'index', :use_route => :users, :only_path => false},
  x.send(:users_url))
end

The strange hash value you see in the assertion is the result of the named route method calling url_for, and returning that. The current implementation of the named route helpers does this, but what if you wanted to implement a new version of named routes which completely avoids the costly call to url_for? Every single named route test fails, even though applications which use those methods will work fine.

In this situation you have two options, you could make your tests depend on the full implementation of url_for. This would probably slow down your test cases, and require a lot more setup code, but because the return values are correct you’re not likely to impede future refactoring.

The other option is to use different stubs for every test case. Leaving you with something like this:

1
2
3
4
5
6
7
def test_named_route_with_nested_controller
  rs.add_named_route :users, 'admin/user', :controller => '/admin/user', :action => 'index'
  generated_url = "http://test.named.routes/admin/user"
  x = setup_for_named_route.new
  x.stubs(:url_for).returns(generated_url)
  assert_equal(generated_url,  x.send(:users_url))
end

Doing this for each and every test case is going to be quite time consuming and make your test cases extremely verbose. As with all things in software you’ll have to make a judgement call on this trade off and make a choice between coupling or verbosity.

Whatever approach you choose, just remember that misleading test ‘failures’ can slow down refactoring, and end up reducing your ability to respond to change. As satisfying as ‘100% coverage’ or 2:1 ratios may be, don’t blindly add assertions or mock objects just to satisfy a tool. Every line in your test cases should be there for a reason, and should be placed there with just as much care as you’d use for a line of application code.

Yet another multicolumn layout - rocks!

Posted about 7 years back at work.rowanhick.com

One chasm between traditional desktop application development and web application development is layout/forms design. It's my constant pain point "I just want a 2 column layout, with a data table in the middle" - many hours later you're still tearing your hair out trying to get it working. It should not be this way (and that's just for prototyping). To get a production tested basic grid/column based layout, that looks reasonable across all browsers and is flexible enough to grow as the app grows - well we all know how much a top notch HTML/CSS wizard is going to cost us right ? Why for every project the same ground of IE hacks and cross browser issues are solved over and over again ? This is half the reason that a sandbox environment like AIR is very appealing - don't deal with it, just get your users to use a standard environment. Enter from stage left, in the why hasn't anyone thought about it before category, are two CSS frameworks that I happened upon on Friday. One called Blueprint which is getting a bit of attention, and one with the rather confusing name of YAML. After seeing all of the examples of YAML, and reviewing the documentation I thought what the heck lets give this a go. YAML is designed for 'standard' column based layouts. It essentially says 'create your main div structure this way, in a predefined page/top nav/nav/main body/footer layout. Then within your main body div, you have options for creating 1-3 columns, and then sub columns within those columns. Whilst I haven't tested the limits, I'm sure so long as it fits within a grid you could use YAML to create it. It's not designed for your highly creative CSS award winning page with umpteem divs all over it - however that audience wouldn't be reading this blog. But for your standard store/blog/cms/other application I can see a huge head start in having the CSS pain removed from your desk. So I put the theory to the test - 4 hours later, I had a couple of layouts running and working across IE 6, IE 7, Firefox, Safari... un-fricking-believable. About 30mins of that 4 hours was the actual job of getting the css setup with the basic grid structure - the rest, playing about with colours, table styles, and creating actual views. I abhor front end CSS work and this abstracted away all of the pain, leaving me just to get on with the job. I'm not going to attempt to write a how-to or tutorial, as the original docs are so good I'll leave well enough alone - the only caveat is don't just blindly copy and paste, make sure you skim read the docs, you need to know where to put the appropriate patch files etc. But wait there's more ! Does the thought of manually constructing even your basic div structure seem a little off putting to you. Dirk Jesse (YAML's wizard) has a browser based builder for constructing your layout and outputting the CSS. Very nice indeed !. Just jump to his site and check it out. So you can expect to see some XChain screenshots gracing this site shortly.

Working with models

Posted about 7 years back at Troubleseeker - Home

First of all, models are human beings. I mention it because it seems that many people have this stereotype in their heads about a model being always skinny and bitchy or glorify them as someone perfect from a magazine. They come in all flavours as anyone else.

It is important to keep that in mind, not only when working with a model but also when editing the pictures. You don’t want to cripple the pictures by doing a dowdy photoshop job in post. Preserve the model’s dignity throughout the shoot as well as when you pick the photos and edit them.

There is a fair amount of people who are convinced to be models but are far from that. And I am not talking about measurements, weight or if they are above 5’10 or not. It’s an attitude thing – how comfortable they are in front of a camera and how well they photograph. A girl that could look pretty on the street could turn into something grotesque in front of the camera because she couldn’t relax certain parts of her face for example. And vice versa: Someone you would not expect to be a model can look gorgeous with the right make-up, angles and expression.

So what different types of models are there?

Very broad: there are commercial and editorial models. The work of commercial models can be seen everywhere: medical brochures, flyers, catalogs, the woman smiling at you on the insurance company’s website. There is a big demand for commercial models and they range from child to senior, very attractive to average joe.
Editorial models have to fulfill certain standards. They need to have the perfect dress size, a certain height and the right (ideally unique) look. They do the runway shows, fashion spreads and some of them gain worldwide recognition.

Regardless of what kind of model you are shooting, you will always want to make sure of the following two things:

  • Know what kind of shoot it is going to be
  • Your model should be as comfortable as possible.

How to make a model comfortable and why would I care?

The more comfortable someone is in front of your camera, the more relaxed he/she is. The more relaxed, the better pictures you will get.

Music

I usually ask before the shoot what kind of music the person likes I am going to shoot. It’s good to always have some background music because music relaxes and dead silence can lead to an awkward situation.

Food

Being hungry is a not a good state to be in when taking pictures or having pictures taken. The tolerance level sinks noticeably and the overall mood is usually better when everyone has something in their stomach. So snacks are always a great thing to have around.

Talk

I hear about photographers who don’t even introduce themselves to the models they are shooting. I think that’s a huge mistake. Talk to the people you are working with. Learn more about them. Not only will it relax the other person but it will also lead to a more enjoyable experience for you and during the talk you get to examine the model’s facial expressions and angles.

Beauty shots above – model: Whitney for Ben Barry, make-up: Sommer Mbonu, hair: Anne-Marie Rooney

0.6 almost there

Posted about 7 years back at The Hobo Blog

Wow – getting all our tests upgraded to the new DRYML, not to mention getting them all to pass, has been a real slog, but we just crossed the finish line. All the tests are green. We now have to make sure things like Pod and the to-do demo are working, and that fresh Hobo apps with all the Rapid pages work too. Then there’s the changelog, and we’ll be ready for take-off.

This has been a huge effort to get working, as we’ve had three major upheavals: new DRYML, much improved standard tag libraries, and a move from Rails 1.2 to Edge Rails (don’t forget to rake rails:freeze:edge – that’s required now, and will be until we hit 1.0).

Almost there!

0.6 almost there

Posted about 7 years back at The Hobo Blog

Wow – getting all our tests upgraded to the new DRYML, not to mention getting them all to pass, has been a real slog, but we just crossed the finish line. All the tests are green. We now have to make sure things like Pod and the to-do demo are working, and that fresh Hobo apps with all the Rapid pages work too. Then there’s the changelog, and we’ll be ready for take-off.

This has been a huge effort to get working, as we’ve had three major upheavals: new DRYML, much improved standard tag libraries, and a move from Rails 1.2 to Edge Rails (don’t forget to rake rails:freeze:edge – that’s required now, and will be until we hit 1.0).

Almost there!