Recently I updated rake on a project and was met with this warning:

1

WARNING: 'task :t, arg, :needs => [deps]' is deprecated.  Please use 'task :t, [args] => [deps]' instead.

It wasn’t immediately obvious to me what exactly the needed change was, and much googling didn’t reveal anything helpful. However blind poking about did. Turns out it means one should change this:

1

task :staging, :post, :needs  => :environment do |t, args|

to this:

1

task :staging, [:post]  => :environment do |t, args|

This week a good friend launched Menuito, his company aimed specifically at helping restaurants improve their websites for mobile users. Menuito is pretty damned clever. It effectively routes around the issues most restaurant websites have on mobile devices by providing a completely separate, customizable site to mobile users. And it does so with almost no technical changes to the restaurant’s existing website and servers.

Everyone knows restaurant websites are pretty terrible. Sites like Never Said About Restaurant Websites skewers the industry one soundbite at a time. And they’re easy targets, restaurants are, because it seems so obvious: if you serve the public, and you’re heavily dependent on the public’s personal preferences and ability to find you, you should make critical information as easy as possible to access. But those sites don’t; they employ Flash and PDFs and annoying background music and all the other things that seemed like such a great idea fifteen ten five years ago when the restaurant had it’s brand-new website built by someone who really just sold them a line. Someone who told them they’d be getting something beautiful but instead stuck them with a proprietary, heavy-weight, gimmick-laden turd.

I suspect if you ask restauranteurs about their websites, owners of the types of sites we’re talking about here, very few are happy. They’re not stupid, they know people need to find them, and their hours, and their menu, and can’t. But they’re restauranteurs, not geeks. For them the solution is not simply a technical one but rather one of time and money, of effort and energy, all the things most restauranteurs don’t have an abundance of. And at the end of the day they have no guarantee they won’t simply get burned again.

That’s why Menuito is so beautiful. Menuito effectively says to the restauranteur:

Let’s solve one problem at a time. Your existing site is good enough for people at their computers so let’s just leave that as-is. Instead, we’ll tweak things so that it also works for people on smart phones. And we’ll make that particular user experience perfect.

One just needs to look at Menuito’s demo.menuito.com demo site to see how effective this can be (and do be sure to look at it in both a computer browser and a mobile browser; it’s attention to detail like that that really set the folks who built Menuito apart).

Here’s hoping Menuito catches on because as it stands now, too many restaurants are nigh impossible to use on mobile devices.

For some crazy reason you find yourself thinking “it’d be really great right now if I could just run some raw SQL queries against my database in this here Rails app”, but how?

The saner amongst us would simply find a better way to do things but for those times when sanity is not an option*, there’s this stuff, and it works like so:

1

result = ActiveRecord::Base.connection.select_all( "SELECT * FROM authors_books WHERE 1" )

In that particular case it returns a hash containing the results of each row in the table. Pure, unadulterated query goodness, no extra filler.

(*like when you’re exporting a join table from MySQL to Sqlite without the weight of the instances it denotes. Oh yeah.)

You’re using Rails, you upgrade Devise and suddenly it all stops working with an InvalidHash error. Chances are you just got bit by a change to the default crypto algo. The solution, from Stack Overflow:

1) Remove config.encryptor from your initializer;
2) Add t.encryptable to your old migrations;
3) [Optional] Remove password_salt in a new recent migration. Bcrypt does not require it anymore.

Though in my experience the removal of the password_salt field is not optional since old Devise made it null=false.

I was playing around with an interface experiment and wanted to convert arbitrary strings into hex codes for displaying colours in a webpage. I just ported the JS code from this Stack Overflow solution to Ruby, now hosted on Github: str_2_hex.rb. Might be useful to someone else.

After recently re-installing my system on a new SSD everything was working fine except Rspec for a project running on Rails 2.3.5. Turns out there were a couple issues.

First, Rails was out of date. Upgrading to 2.3.11 fixed those issues.

Next, Nokogiri was throwing this error:

1
2

/Users/chris/Sites/adobe-agency-partner-portal/vendor/bundle/ruby/1.8/gems/nokogiri-1.4.4/lib/nokogiri/xml/schema.rb:37: [BUG] Segmentation fault
ruby 1.8.7 (2009-06-12 patchlevel 174) [universal-darwin10.0]

In this case my version of libxml2 was causing the problems. Upgrading that to the latest and re-installing Nokogiri fixed that issue.

To see where you stand with Nokogiri, run this command:

1
2
3
4
5
6
7
8
9
10
11
12

~/Sites/adobe-agency-partner-portal (master⚡) : bundle exec nokogiri -v---
warnings: []

ruby:
  engine: mri
  version: 1.8.7
  platform: i686-darwin10.6.0
libxml:
  loaded: 2.7.8
  binding: extension
  compiled: 2.7.8
nokogiri: 1.4.4

Today it was revealed that dating site Plenty of Fish’s databases have been severely compromised. All their data user data has been stolen, probably many times from the sounds of it. It also seems that Plenty of Fish was - let’s be generous - naive enough to keep their user’s passwords stored in the database in plaintext. That is, unencrypted, readable by anyone with access.

This is a big deal on a number of levels, not the least of which is because people have a tendency to reuse their passwords for multiple sites. It’s no small leap to imagine that most users on PoF who signed up with their Gmail account also used the same password for PoF that they used for Gmail. To put it another way, anyone who did that has now also had their Gmail account compromised, and for many people their email account is the gateway to all their accounts.

It got me thinking: what small steps could be taken on the user’s behalf to help cut down on the number of people reusing their passwords? How about something like this?

Obviously it won’t stop anyone if they’re adamant enough, but it just might get them thinking.

Everything was going smoothly until we got to testing in IE 8, at which point we started seeing errors inside loops.

Turns out IE 8 doesn’t like for() loops written like so:

1

for( var idx in items ) {

Instead, use the ol’ fashioned way:

1

for ( var i = 0; i < items.length; i++ ) {

Maybe in IE 9?

Having trouble getting your z-index-specified DOM elements to behave properly? One of them not layering like it ought to? Evidently z-index settings are only applied to elements that also have an explicitly-defined position attribute, like the following:

1

position:absolute, position:relative, or position:fixed

Duck Duck Go, a relatively new player in the search engine market currently dominated by Google, recently put up Don’t Track.us, a site that describes how Google methodically tracks and allegedly sells information about it’s users whereas DDG does not. It’s very interesting to read and got me thinking about how I use Google, and that is: really quite frequently. I’d hazard to guess that my Google search usage might average out to a couple times every hour every single day for the past ten years or so.

In the past I’d used Duck Duck Go a few times but the fact that it couldn’t be set as the default search within Safari was a real impediment. It appears that Apple has hard-coded the Big Three allowed search engines into the Safari binary, those being Google, Bing, and Yahoo (Yahoo? Does anyone really use Yahoo?).

So I figured today was a good day to try and change that and discovered that on DDG’s site there’s a link to a Safari extension that places a Duck Duck Go search bar right into the browser. Great! Except that the result is aesthetically terrible. It looks like something one would have found in IE 6. Really, just don’t bother installing it.

Saddened by this I emailed DDG this morning to bitch about it and almost immediately received back a reply from Gabriel Weinberg, DDG’s founder. Graciously he suggested I try an alternate solution provided at the bottom of that page, the one coyly hinted at via:

Safari - To add to search box (as opposed to above extension), first install Glims. Then add DDG as a custom search engine like this and then this.

Frankly, that should be linked at the top of the Tools page and the Safari extension removed. That solution is awesome. It puts DDG into the search bar as the default, Glims adds some fantastic extra functionality to Safari that I’m thoroughly enjoying, and I find DDG’s search results are just more pleasing to me than Google’s overall. Basically, switching to DDG from Google has been a pretty nice win.

If you’re on a Mac and you’re using Safari, I urge you to give it a try.