flow

Scheme-relative URLs

Tue, 03 May 2011 11:35:50 -0700

I really love the IT industry so much, I’ve been hacking away in this industry for nearly 20 years and I am still learning new things. Today’s little gem is scheme-relative URLs (aka protocol-relative URLs).

This solves the age-old problem of creating URLs for other domains which work when you’re in SSL mode, I mean who hasn’t written code to determine whether you’re in SSL mode and so using either “http” or “https” for creating off-site URLs? In fact, in Rails there’s even request.scheme built into the framework. Well, no more I say!

Believe it or not, hidden away in RFC1808 (ok, not really hidden at all) is the fact that a relative URL can be something like this: //example.com/ in which case it’s relative to the current scheme – so if the document containing that URL is requested over HTTPS then that URL will be https://example.com/ and if over HTTP then the URL will be http://example.com/

And yes, before you ask, it works in CSS, link tags, script tags, hrefs and even IE6!! – it’s been around since 1995, we’re all just dumb-asses!

kthxbai

Permalink | Leave a comment »

#protip - rails console

Fri, 15 Apr 2011 22:24:00 -0700

So for anyone who doesn’t know, the Rails console (rails c in Rails3 or script/console in Rails2) runs up an irb process behind the scenes. It also loads Rails into the context, and a few other bits – but mainly it’s an irb session.

I’ve just been getting a couple of “Oh wow, I didn’t know that.” responses when I mention these things in #RubyOnRails, so I thought I’d just post this here.

Thing 1: the underscore method

The return from every command that you enter into irb is available in the underscore method _. So, if you’re like me, you often run a command and then think that you should have assigned it to some variable, or pretty-printed it or something.

The underscore method is perfect for this:

>> City.all
=> [#<City id: 218996838, name: "Chatswood", postcode: "2067", state_id: 944944227, created_at: "2009-03-30 01:56:22", updated_at: "2009-03-30 01:56:22">, #<City id: 957448139, name: "Roseville", postcode: "2069", state_id: 944944227, created_at: "2009-03-30 01:56:22", updated_at: "2009-03-30 01:56:22">, #<City id: 1015505586, name: "Willoughby", postcode: "2068", state_id: 944944227, created_at: "2009-03-30 01:56:22", updated_at: "2009-03-30 01:56:22">]

Bugger me if I didn’t just forget to assign that to something…

>> c = _
=> [#<City id: 218996838, name: "Chatswood", postcode: "2067", state_id: 944944227, created_at: "2009-03-30 01:56:22", updated_at: "2009-03-30 01:56:22">, #<City id: 957448139, name: "Roseville", postcode: "2069", state_id: 944944227, created_at: "2009-03-30 01:56:22", updated_at: "2009-03-30 01:56:22">, #<City id: 1015505586, name: "Willoughby", postcode: "2068", state_id: 944944227, created_at: "2009-03-30 01:56:22", updated_at: "2009-03-30 01:56:22">]

Yay!

The only thing to remember is that if you don’t grab it immediately, then it will be gone next command – it is overwritten with every line.

Thing 2: the y method

This is actually just the Kernel#y method, but it’s particularly useful in irb sessions when you want to print something out in an easy to read (and easy to grab if you want YAML) format.

>> { :foo => 'bar', :woo => { :ooo => 1 } }
=> {:foo=>"bar", :woo=>{:ooo=>1}}
>> y _
---
:foo: bar
:woo:
  :ooo: 1
=> nil

This is especially good for outputting large collections of Rails models.

Thing 3: the pp library

The pp or Pretty-Print lib is also great for printing out collections of data in a neat way. Just require it into your irb session and use it to great effect:

>> require 'pp'
=> true
>> pp City.all
[#<City id: 218996838, name: "Chatswood", postcode: "2067", state_id: 944944227, created_at: "2009-03-30 01:56:22", updated_at: "2009-03-30 01:56:22">,
 #<City id: 957448139, name: "Roseville", postcode: "2069", state_id: 944944227, created_at: "2009-03-30 01:56:22", updated_at: "2009-03-30 01:56:22">,
 #<City id: 1015505586, name: "Willoughby", postcode: "2068", state_id: 944944227, created_at: "2009-03-30 01:56:22", updated_at: "2009-03-30 01:56:22">]
=> nil

Voila! To make that even easier, see the next thing.

Thing 4: .irbrc

By default in *nix based operating systems the file .irbrc in your $HOME directory will be loaded by irb when it starts up. (On Windows you need to create your own irbrc anywhere you like and set the IRBRC environment variable).

You can put any Ruby commands you like in here, here’s mine:

require 'rubygems'
require 'irb/completion'
require 'pp'
require 'yaml'

def v(x)
  IO.popen( 'mvim -', 'w') do |io|
    io.puts x.to_yaml
  end
end

def less(x)
  IO.popen( 'less -', 'w') do |io|
    io.puts x.to_yaml
  end
end

You can see that it’s simple to require in your choice of libs in there, and you can even define your own methods, which brings us to the last thing.

Thing 5: total customization

The .irbrc is just Ruby, and as you’ve seen above you can define your own methods. I’ve defined two to make it easy to pipe an object (as yaml) out to an external program (I’ve got mvim and less setup) – but you can have anything you like. This lets you customize your own irb interface with whatever little helpers you want to make your work easier.

Take a look here and here at some powerful examples of what can be done.

Enjoy.

Permalink | Leave a comment »

CSS Best Practices - Attribute Selectors

Fri, 15 Apr 2011 15:45:00 -0700

On the surface, attribute selectors seem so very cool. Instead of having to explicitly define classes, or other selectors, we can use the attributes of the elements directly to style them. In my experience, by far the most common use of attribute selectors is in styling INPUT elements.

INPUT is one of the most overloaded elements in HTML, just think about how different INPUT elements are for the different types: checkbox, radio, text & file. It’s worse than that though, because as well as having all those different elements, it also has a bunch of types for which the rendering is (mostly) the same, eg. the following are all rendered as buttons: button, input, & reset. HTML5 brings a whole bunch of new problems into the mix, in HTML4 only text and password types were rendered as single row text fields, but with HTML5 this will expand dramatically, conservatively the following are likely to become common: email, search, number, tel & url.

Add to all of that the problem that IE6 never supported attribute selectors, and IE7 and above required the DOCTYPE setting to switch IE into standard mode.

There’s a bucket load of CSS like this which is very soon going to be out of date:

input[type=text], input[type=password] {
  // some style
}

So, what to do?

Well, if we still care about IE6 (which those of us producing software for money often have to) we need real classes, but wouldn’t it be nice if we could continue to rely on the attributes?

Javascript to the rescue

I use jQuery, but the same process can be done using any framework, or in raw JS. What we’re going to do is add classes to all our input elements, to make styling simpler:

function add_input_classes() {
  $('input').each( function(i) {
    var type = $(this).attr('type');
    switch( type ) {
      case 'button':
      case 'reset':
      case 'submit':
        $(this).addClass('button');
      case 'checkbox':
      case 'radio':
      case 'file':
      case 'hidden':
      case 'image':
        $(this).addClass(type);
        return;
    }
    $(this).addClass('text').addClass(type);
  });
}

$(function() {
  add_input_classes();
}

So, we add the type of each input element as a class, so <input type="radio"> will have ‘radio’ added as a class. Additionally, we add ‘button’ to all the button types. We also add ‘text’ to any type not in the switch list, ie. we assume that anything not listed is a text field. This will soon not be reliable, if you’re using other HTML5 types like the date-pickers, or the color wheel, then you’ll need to add those to the switch statement.

So then our CSS becomes nice and clear:

input.text, textarea {
  border: thin solid grey;
}

input.button {
  background-color: gray;
  color: black;
}

Then also, if we need to, we can style any individual attribute using the type as the class.

What else?

This same process can be expanded to work for all other attribute selectors as well. Javascript is much more powerful than CSS selectors, and by pushing this class assignment off into JS you’re left with much neater and more robust HTML and CSS.

Permalink | Leave a comment »

Regexp SQL finders from Rails

Fri, 15 Apr 2011 14:24:00 -0700

Ever wanted to use regex in your Rails finders? If you’re like me, and versed in regex then you might sometimes do this almost without thinking…

Product.find_by_code /^[NRW][^-]+-[456]/

So, tired of that not actually working, I wrote wherex. It works out of the box with the three primary Rails DBs (SQLite3, MySQL and PostgreSQL) and it’s easy to make any DB with REGEXP support work. I’ve given an example for how to make Oracle work in the wherex docs.

Enjoy.

Permalink | Leave a comment »