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!

NetBeans Rocks

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

NetBeans really is the BOMB, as Charles Nutter notes over on his blog. Check out that link. I wanted to make sure I echoed his thoughts here, because for me, NetBeans really is the best Rails IDE on the planet. I switched over from IntelliJ some time ago and haven’t regretted it even briefly.

I really can’t say enough things about NetBeans. What other IDE makes it painless to debug (yes debug, within the IDE), refactor, and test your Ruby applications? Plus, the syntax highlighting is rockin and you get all the standard NetBeans goodness out of the box. Don’t want a huge download? No big deal, there’s a slimmed-down Ruby-only version available. Give it a shot. Even if you’re a hardcore Textmate geek, I think you’ll at least be able to see why I’m raving about it.

DRYML Tour (0.6 not quite ready)

Posted about 7 years back at The Hobo Blog

Nope, sorry. No Hobo 0.6 today, but to whet your appetites a little further, here’s an example of how clean a full DRYML template can look in the new DRYML. We’re pretty happy with the result over here - hope you like it :-)

In particular, look out for the new “smart HTML tags”. These aren’t a new DRYML feature, but a new style for the Rapid tag library. They’re just regular DRYML tags that have the same name as HTML tags. Want a link?

<a href="...">My Link</a>

Want Hobo to fill the href in for you? Say, to the author of the article you are rendering:

<a:author>...</a>

How about a form? Hobo will provide the attributes that make the form work (action, method…):

<form with="&Story.new">...</form>

Want to make that an ajax form? Just name the part (or parts) you want updated and Hobo does the rest:

<form with="&Story.new" update="stories">...</form>

So, on to that full page. It’s an index page BTW:

<Page title="Admin Home">

  <intro>
    <h1>Admin Home</h1>
  </intro>

  <maincol>
    <panel>
      <h2>All Accounts by client</h2>

      <section>
        <h3>Create a new client</h3>
        <form with="&Client.new">
          Name: <input:name/>
          <submit label="Create"/>
        </form>
      </section>

      <section>
        <p>Click on a client name to edit.</p>
      </section>

      <section repeat class="client">
        <h3><editor:name/></h3>

        <Table:accounts>
          <tr>
            <td><a/></td>
            <td>Created: <view:created_at.to_date/></td>
            <td>
              <a:quarters.latest if="&this.site_exists?">View Site</a>
            </td>
          </tr>
        </Table>

        <p>
          <b>&raquo; <a:accounts.new>Create a new account for 
              <name with="&this_parent"/></a></b>
        </p>

        <delete_button label="Delete #{this.name} permanently"/>
      </section>

      <section><page_nav/></section>

    </panel>
  </maincol>

</Page>

Let’s go over that again with some explanation. First the <page> tag.

<Page title="Admin Home">

<page> is a template. That’s a new DRYML feature. Where a normal tag has a single body, a template has a bunch of named parameters, and they can be placed wherever you like in the templates output. It’s a fill-in-the-blanks kind of model. Look up at the full listing again and you’ll see that <page> has two children – <intro> and <maincol>. These are not normal tags that are being called, they are named parameters to the <page> template. Whenever you see a tag with a capitalised name, remember that the children are parameters rather than tag calls.

Next, forms. Forms are blissfully neat now in Hobo.

<form with="&Client.new">
  Name: <input:name/>
  <submit label="Create"/>
</form>

Because the context for the form is a new AR object, Hobo knows to create a POST to the relevant RESTful create method. Furthermore, if you create the object via a has_many collection, the hidden field will be included so that the created object has the required foreign key.

Also notice the new tag for form controls: <input>, and the nice syntax to set the context to a given field: <input:name/>.

There are three general purpose tags of this kind: <view> for read-only views, <input> for form input fields and <editor> for ajax in-place editors. They all create the right stuff automatically depending on the type of the context, and it’s very easy to extend this with your own types. These replace the old show, form_field and edit (we’ve realised that nouns are better than verbs - they’re more declarative).

If the context is something enumerable, look how easy it is to repeat a tag for each item in the collection:

<section repeat class="client">

A quick click-to-edit title:

<h3><editor:name/></h3>

A table with a row for each account:

<Table:accounts>
  <tr>
    <td><a/></td>
    <td>Created: <view:created_at.to_date/></td>
    <td>
      <a:quarters.latest if="site_exists?">View Site</a>
    </td>
  </tr>
</Table>

That’s a template too - <tr> is a parameter and there are others for giving a thead and tfoot. Also Note the new in-line if syntax on that link.

And finally the page navigation:

<section><page_nav/></section>

That whole section will only appear if there is more than one page.

Sweet :-)

DRYML Tour (0.6 not quite ready)

Posted about 7 years back at The Hobo Blog

Nope, sorry. No Hobo 0.6 today, but to whet your appetites a little further, here’s an example of how clean a full DRYML template can look in the new DRYML. We’re pretty happy with the result over here - hope you like it :-)

In particular, look out for the new “smart HTML tags”. These aren’t a new DRYML feature, but a new style for the Rapid tag library. They’re just regular DRYML tags that have the same name as HTML tags. Want a link?

<a href="...">My Link</a>

Want Hobo to fill the href in for you? Say, to the author of the article you are rendering:

<a:author>...</a>

How about a form? Hobo will provide the attributes that make the form work (action, method…):

<form with="&Story.new">...</form>

Want to make that an ajax form? Just name the part (or parts) you want updated and Hobo does the rest:

<form with="&Story.new" update="stories">...</form>

So, on to that full page. It’s an index page BTW:

<Page title="Admin Home">

  <intro>
    <h1>Admin Home</h1>
  </intro>

  <maincol>
    <panel>
      <h2>All Accounts by client</h2>

      <section>
        <h3>Create a new client</h3>
        <form with="&Client.new">
          Name: <input:name/>
          <submit label="Create"/>
        </form>
      </section>

      <section>
        <p>Click on a client name to edit.</p>
      </section>

      <section repeat class="client">
        <h3><editor:name/></h3>

        <Table:accounts>
          <tr>
            <td><a/></td>
            <td>Created: <view:created_at.to_date/></td>
            <td>
              <a:quarters.latest if="&this.site_exists?">View Site</a>
            </td>
          </tr>
        </Table>

        <p>
          <b>&raquo; <a:accounts.new>Create a new account for 
              <name with="&this_parent"/></a></b>
        </p>

        <delete_button label="Delete #{this.name} permanently"/>
      </section>

      <section><page_nav/></section>

    </panel>
  </maincol>

</Page>

Let’s go over that again with some explanation. First the <page> tag.

<Page title="Admin Home">

<page> is a template. That’s a new DRYML feature. Where a normal tag has a single body, a template has a bunch of named parameters, and they can be placed wherever you like in the templates output. It’s a fill-in-the-blanks kind of model. Look up at the full listing again and you’ll see that <page> has two children – <intro> and <maincol>. These are not normal tags that are being called, they are named parameters to the <page> template. Whenever you see a tag with a capitalised name, remember that the children are parameters rather than tag calls.

Next, forms. Forms are blissfully neat now in Hobo.

<form with="&Client.new">
  Name: <input:name/>
  <submit label="Create"/>
</form>

Because the context for the form is a new AR object, Hobo knows to create a POST to the relevant RESTful create method. Furthermore, if you create the object via a has_many collection, the hidden field will be included so that the created object has the required foreign key.

Also notice the new tag for form controls: <input>, and the nice syntax to set the context to a given field: <input:name/>.

There are three general purpose tags of this kind: <view> for read-only views, <input> for form input fields and <editor> for ajax in-place editors. They all create the right stuff automatically depending on the type of the context, and it’s very easy to extend this with your own types. These replace the old show, form_field and edit (we’ve realised that nouns are better than verbs - they’re more declarative).

If the context is something enumerable, look how easy it is to repeat a tag for each item in the collection:

<section repeat class="client">

A quick click-to-edit title:

<h3><editor:name/></h3>

A table with a row for each account:

<Table:accounts>
  <tr>
    <td><a/></td>
    <td>Created: <view:created_at.to_date/></td>
    <td>
      <a:quarters.latest if="site_exists?">View Site</a>
    </td>
  </tr>
</Table>

That’s a template too - <tr> is a parameter and there are others for giving a thead and tfoot. Also Note the new in-line if syntax on that link.

And finally the page navigation:

<section><page_nav/></section>

That whole section will only appear if there is more than one page.

Sweet :-)

Speaking at the Lone Star Ruby Conference

Posted about 7 years back at PJ Hyett

If you need to hone your Ruby chops prior to heading to Berlin for RailsConf Europe check out the Lone Star Ruby Conference in Austin, TX September 7-8. I was digging the city hard after visiting for SXSW and can’t wait to get back there.

Chris and I will be representing Err Free at the conference with talks entitled On Your Best Behavior: BDD in Ruby and I Built this Killer Rails site, Now What?, respectively.

I promise mine will be entertaining, with the large caveat that it’s the first talk on Saturday after what will surely have been a long night of drinking on Friday.

There’s an early-bird registration ending tomorrow night, so if you were at all interested in attending, I’d recommend doing so soon.

Speaking at the Lone Star Ruby Conference

Posted about 7 years back at PJ Hyett

If you need to hone your Ruby chops prior to heading to Berlin for RailsConf Europe check out the Lone Star Ruby Conference in Austin, TX September 7-8. I was digging the city hard after visiting for SXSW and can’t wait to get back there.

Chris and I will be representing Err Free at the conference with talks entitled On Your Best Behavior: BDD in Ruby and I Built this Killer Rails site, Now What?, respectively.

I promise mine will be entertaining, with the large caveat that it’s the first talk on Saturday after what will surely have been a long night of drinking on Friday.

There’s an early-bird registration ending tomorrow night, so if you were at all interested in attending, I’d recommend doing so soon.

Pardon the Dust

Posted about 7 years back at Shane's Brain Extension

I recently migrated this blog from Typo to Mephisto and have a few cleanup activities to perform. Markdown formatting has to be converted, sidebar stuff has to be added, and the design needs some minor tweaks to get things looking like how they did before. So sorry for the temporary ugliness.

I’ve been really busy working on client projects and trying to get my own startup launched, and therefore have been falling behind on the open source work. Thanks to those who sent me contributions to the youtube gem. I plan on making one more release before working on version 2. youtube2 will use the GData format since YouTube is changing the API to fit more with Google’s other APIs. It is slated for release later in the year.

Pardon the Dust

Posted about 7 years back at Shane's Brain Extension

I recently migrated this blog from Typo to Mephisto and have a few cleanup activities to perform. Markdown formatting has to be converted, sidebar stuff has to be added, and the design needs some minor tweaks to get things looking like how they did before. So sorry for the temporary ugliness.

I’ve been really busy working on client projects and trying to get my own startup launched, and therefore have been falling behind on the open source work. Thanks to those who sent me contributions to the youtube gem. I plan on making one more release before working on version 2. youtube2 will use the GData format since YouTube is changing the API to fit more with Google’s other APIs. It is slated for release later in the year.

A ruby API to the Ensembl database

Posted about 7 years back at Saaien Tist

"Joy to the world, lalaa la laaaa." I can finally announce that I've released the ruby API to the Ensembl core database under the bioruby-annex umbrella. Go here for the release.

What is it?
The Ensembl database stores genetic and genomic data on a variety of species: sequences of chromosomes and positions of features such as genes and polymorphisms. This data is browseable using their genome browser, but is also directly accessible if you connect to their mysql database. A perl API to that database has been available from the start and is used by the ensembl people themselves to handle the data. A java implementation (called Ensj) is also available, but I don't know the status of that one. The ruby version should provide similar functionality to the perl API, albeit for querying only and not for writing to the database.

This API is aimed at the core database. Ensembl also provides the variation and compara databases, but these are not the focus of the current API implementation.

A minimal interface to the data of Ensembl was already available through Mitsuteru Nakao's ensembl.rb library in the bioruby project, and is based on the exportview functionality of Ensembl's web interface. Although very useful, it does not give the full functionality that can be achieved by accessing the database directly.

The ruby API basically provides two things: access to the data in the database, and transformations of those data.
Access to the data. (Virtually) all tables of the database are available through ActiveRecord, with all the automated query methods associated with that ('find_by_anything_you_like'). Say you want to get the object of a transcript with stable_id "ENST00000380593", you'd do

transcript = Ensembl::Core::Transcript.find_by_stable_id('ENST00000380593')

Transformations of the data. You might have the coordinates of a gene on the chromosome, but actually want them on a contig or supercontig. This is where the Sliceable#transform and Slice#project methods come in. In contrast to the perl API, there is no Sliceable#transfer method, because my interpretation of a 'slice' is slightly different from the perl implementation. Read the tutorial for more information.

Minimal script
Any script using the API would have to these steps:
  1. require the library
  2. include the Ensembl::Core namespace (not strictly necessary, but saves typing)
  3. connect to the database
  4. start doing stuff

So for example:
#!/usr/bin/ruby
require 'rubygems'
require_gem 'ensembl-api'

include Ensembl::Core

CoreDBConnection.connect('homo_sapiens')

transcript = Transcript.find_by_stable_id('ENST00000380593')
puts "5'UTR: " + transcript.five_prime_utr_seq


How to install
The API has been released as a gem file, which you can either download from the website and install using the command
gem install ensembl-api-0.9.gem

, or export from the SubVersion repository using the command
svn export svn://rubyforge.org/var/svn/bioruby-annex/ensembl-api
This gem depends on bioruby and ActiveRecord.

UPDATE: The code has been moved from rubyforge to github. Get it from http://github.com/jandot/ruby-ensembl-api


Documentation
Check the website at rubyforge, which will show the tutorial (based on the perl version) and the rdoc documentation. In addition, there are the tests in your gem directory, plus a sample script that shows all functionality of the perl-version of the API called examples_perl_tutorial.rb.

Credits
I owe a lot to the Ensembl core team for helping me out when I was at the Ensembl site as a "Geek for a Week"...

Call for help
If anyone would be interested in improving the API, don't hesitate to contact me. At the moment, for example, projections between coordinate systems only work if they're directly linked in the assembly table, and projections of the haplotype assembly_exceptions will now raise a NotImplementedError error. In addition, it would be very useful if we could add the variation and compara databases to the API.