Keywords in the Location Bar: I'm Feeling Lucky

So, I use Firefox whenever possible on whatever machine I happen to be on. Most of the time that's on my laptop and I have several plugins that enhance my Firefox experience. I'm a big fan of the delicious and evernote plugins.

What I wanted was the ability to do an "I'm feeling lucky" search from the browser bar somewhere. What I found was there's a setting for that.

Go to the keyword.URL setting in about:config on your Firefox 3 browser. Don't worry there wasn't a warranty in the first place, but do be careful when you're playing around in here.



That is the url you hit when the jibberish you type into the location bar of the browser doesn't look like a website. So this is the setting to change. The url I use is:

http://www.google.com/search?btnI=I%27m+Feeling+Lucky&ie=UTF-8&oe=UTF-8&q=

Make sure the keyword.enabled is true. It should be by default but just make sure.

Now you can type in:



And be directed straight to the rdocs on paperclip.. If you're as lucky as you feel of course.

Quick Heads up: Upgrading from Rails 1.2.6 to 2.3.2

I was just upgrading one of our apps into the new age from 1.2.6 to 2.3.2 and found an interesting issue. With the corresponding upgrade of Rspec. The new rspec generates a spec_helper.rb file with this line at the top:

ENV["RAILS_ENV"] ||= 'test'

For some reason this plays funny with our environment in that all of our dev machines were running the tests in development mode. Obviously somewhat less than ideal. Just take out the 'or' from the 'or equals' and we're set.

ENV["RAILS_ENV"] = 'test'

There is probably more to this story but just in case this could help someone wanted to jot it down real quickly.

Recursive File Finder

When looking for a bunch of files somewhere in directory structure I usually pull my hear out. But I found this cool ruby code called 'Find'. It pretty much does all the dirty work for us and its packed with ruby core. It has two methods. Find.find which takes a block and will basically recursively look through every child directory of the one you pass in. Find.prune which only makes sense in the context of a find block, and just says stop looking in here. You want to make sure you use this when you hit a file or a directory you don't want to look in.

Below is a little snippet of code I wrote to recursively find files that matched some substring. It's used like this:

 File.recursive_find('/root/search/path', 'invoice')

This will find all of the files that match the string 'invoice' somewhere in their name and return an array of these files. Here's the code:

require 'find'
class File
  def self.recursive_find(dir, match_string)
    results = []
    Find.find(dir) do |path|
      unless FileTest.directory?(path)
        unless File.basename(path) =~ /#{match_string}/
          Find.prune
        else
          results << path
        end
      else
        next
      end
    end
    results
  end
end

Agile Research

...is it possible?

I was looking at trying to manage tasks/projects in the field biology realm.

Strikes I'm considering thus far:
- hard and fast deadlines that you can't miss that are all or nothing.
- projects change frequently so estimation is tough to get down

Deadlines...

In my experience with agile thus far, it works fine when you know you want to launch a new software project by a certain time with whatever features you can develop by then. Or if you know you need a certain feature set but don't really care when it gets done. When you have both criterion that makes it much more difficult.

Just like you can't guarantee to a business owner that there site will be done with all their features in exactly one month and guarantee the developers a sustainable pace, neither can you do that in research. So is there a way to adapt to these criterion? The benefit is that the deadlines usually pop-up far enough ahead of time that you wouldn't be able to spend all the time between now and then on that project even if you wanted to.

Project Turnover...

For agile projects I've been a part of we generally do a pretty bad job of estimating stories at the beginning and a much better job towards the end. Takes a sprint or two to get the hang of it. If projects were turning over frequently, this could be a nightmare.

In the academic world, there are constantly many things pressing on your time. Teaching responsibilities, data gathering, data analysis, and synthesis/publication. For any particular research project, a researcher has to start in the data gathering stage often using new tools and new methods are these estimable? Then as they move on to the data analysis, they again are often using new tools, and new methods. The writing at last is fairly familiar. The number of graphs and the length of the article may change but writing is always familiar ground.

Thoughts?

So how does one estimate such things? Ideas for agile in the research world? Am I just trying to force it?

I appreciate your suggestions, comments, feedback!

Cross Browser Consistency

http://dowebsitesneedtolookexactlythesameineverybrowser.com/

For those that don't want to parse this url.. Do websites need to look exactly the same in ever browser?

When I first saw this url I thought to myself, "Self, the simple answer is 'Yes'." I mean who wants to go to their banks website and see a different layout when they get on with Firefox and another when they are checking their account on the road from some hotel's computer. No one! You lose all confidence in the site authors if it looks different every time you visit.

Also being a web developer I feel the pains of cross browser support all the time so I wanted to go on and commiserate with the other developers. You know why do we have to have a specific stylesheet for IE7 that is full of hacks to make it work like the standards ask, and why does IE6 even exist still and so on.

When I hit the site all I was greated with was a fancy looking 'No!'. I chuckled a bit to myself and said, "yeah right". Then, being the nerd that I am, I immediately opened up every browser I have to see what the differences were for this site. Of course lucky me launching parallels brought the gray screen of death down upon my poor tired little MacBook. But after I recovered from that I took a look at all the browsers.

Turns out the 'No!' that looked so fancy in OSX's Firefox, even fancier looking on OSX's Safari, pretty plain on XP in Firefox, Chrome and IE7, and slightly PC's Safari was a little fancier (Check it out for yourself). So when this site poses the question exactly the same I guess I have to agree. No, there is no reason to go through the effort of making sure your fonts are rendered the same way on every browser by rendering them with vectors or making sure you restyle all buttons with your own custom styles.

As long as the layout is the same and I can click a button in the same place on each browser labeled the same way and no text is falling out of divs or something like that I am pretty satisfied. I realize I'm a developer and am probably pretty utilitarian that way, but then again how many users of the web are really using more than one browser anyway.

All this said, I gotta mention.. I like the 'No!' on OSX's Safari the best. ;)

So you've got 100% Test Coverage

I stumbled across a quote at some point today. It wasn't the first time I heard it but it resonated with me today for whatever reason.

"Testing can only prove the presence of bugs, not their absence." --Edsger Dijkstra

Yep. It's so true. Hopefully, all of you have 100% or close test coverage on any app you develop but don't forget. All that test coverage is just a good sign, not a 100% working guarantee.

A good developer will try to test any edge cases that come to mind, but there are always more out there. Very sneaky, those wild combinations that users come up with, are (Just watched Star Wars last night, Yoda on the brain..).

This isn't a reason to not cover everything with tests. Just a reminder, that there is still work to be done, and as you are adding on to the code you've got, you may still find a bug or two.. Keep your eyes peeled!

DirtyForm: Watching for form changes with jQuery

Last time I mentioned that I had just finished the first steps of a jQuery plugin that would watch your forms and notify you before you left the page so your users don't lose that input they just took the time to type out but forgot to save. Well now its a little more robust and flexible.

What's new?

Lots of stuff has been updated.

• Dirty and Clean events are fired off when a form has unsaved changes, and again when the form is cleaned again.


• It works with jQuery tabs now (they are tricky and don't work like normal links).


• Not limited to forms. Any container of inputs will work just fine.

Dirty/Clean Events

Forms can observe the "dirty" event for customized behavior. So you could set up the dirty form and then bind a function to the dirty event like so:

$(function(){
  $("form")
    .dirty_form()
    .dirty(function(event, data){
      var label = $(event.target).parents("li").find("label");
      $("body").append("
" + label.text() + "Changed from " + data.from + " to: " + data.to+ "
")
    })
});

Dirty Forms + jQuery-UI tabs

You can use tabs with DirtyForm easily. Just be sure that you make the tabs into stopper links after they are set up as tabs so they can be recognized as such and set up properly. They need a lot of special casing.

$(function(){
  $("#nav").tabs();
  $("#nav a").dirty_stopper();
});

If you've already set up all the links for the app as stoppers don't worry this will still work as the other events will be unbound. No penalty for making any links into a stopper twice!

Not just for forms!

If you like throwing inputs in your table rows DirtyForm can handle it. Just tell it where you want it to look.

$(function(){
  $('tr').dirty_form();
});

The plugin is available for download from github: DirtyForm