Unzipping multiple zip files on Unix

To unzip multiple .zip files with one command command on a UNIX system the obvious command to try is 'unzip *.zip' - but that doesn't work...

$ unzip *zip
Archive: ipab20080103_wk01.zip
caution: filename not matched: ipab20080110_wk02.zip
caution: filename not matched: ipab20080117_wk03.zip
[...]

UNIX is expanding the wildcard and passing that string to unzip, which thinks that you are asking for specific files from the zip archive given as the first argument.

You need to escape the wildcard with a backslash so that 'unzip' sees it and expands it correctly.

$ unzip \*.zip
Archive: ipab20080103_wk01.zip
inflating: ipab20080103.xml
inflating: ipab20080103lst.txt
inflating: ipab20080103rpt.html

Archive: ipab20080110_wk02.zip
inflating: ipab20080110.xml
inflating: ipab20080110lst.txt
inflating: ipab20080110rpt.html
[...]

Glad I stumbled on that - saves me a lot of time...

Default Auto Capitalization in HTML Forms with Safari on iPad2

Ran into a nasty gotcha testing out one of my web sites on an iPad2 with Safari.

By default the iPad will capitalize the first letter in a sentence. But with my application the login page requires an email address and these are typically in al lower case.

Safari forces the first letter of the email address into upper case, e.g. Jones@example.com - but this does not match the text in the application's databases (jones@example.com).

My app doesn't force text into lower case on its end (and it shouldn't !), which means that I could not login to my site. And in this case using the SHIFT key on the keyboard does not let you enter the first letter in lower case.

The solution is for the User of the iPad to go to Settings -> General -> Keyboard and set Auto-Capitalization to Off.

This is a really bad default setting - yes, it can be useful if you are entering regular text - but it's not that useful...

I can't expect my users to deal with this on their end. I could force all email address into lower case in my application and that is probably what I'll end up doing.

HTML5 forms can define that a text entry box represents an email address. This adds convenience when entering from a mobile device (the keyboard can display a '.com' key, for example). Whether or not using this has any effect on auto-capitalization I have yet to test.

Firefox Security and file:/// URLs cause problems when testing HTML5

I'm experimenting with some of the great features in HTML5 and specifically with Web Storage. The way I typically try out things like this is to write a simple HTML page with the relevant JavaScript and CSS code and then open that in the browser.

With my Web Storage example, things work great in Chrome and Safari but nothing happens in Firefox 5 on the Mac - even though I know the browser supports this feature.

The issue lies in the security model behind Firefox. It is quite restrictive in what it will let you do with file:/// urls. The intention is to avoid any chance of a remote page being able to access a local file.

That is fine, but there is no obvious alert or notification that Firefox is doing this - instead your code just doesn't work. If I hadn't run it on Chrome first, my reaction would have been to question my own code.

So bear that in mind if you work the same way that I do - perhaps use Chrome as your first choice for development - and if something simple doesn't work, try it in a different browser before questioning your own code.

Rails meta_search - sorting on custom columns

I use Ernie Miller's excellent meta_search gem for searching the contents of tables in my Rails 3 Apps.

I have a lot of index views that are tables of data and each has a search form at the top of the page that uses meta search and the column headers use the sort links provided by meta_search to reorder the rows.

Typically I also have custom columns, such as the number of objects that are associated with a given row via some relationship. Some of those relationships can be quite complex and in some cases there is no simple way to express them in a way that works with meta_search.

I handle the sorting in the controller. It's outside the database but with my current application the amount of data makes this perfectly manageable.

I've come up with a way to let my custom column sorting coexist with meta_search and I reckon it might be useful to others.

All the code can be found at this gist on Github :https://gist.github.com/1019358

It works by adding another parameter called 'custom_sort' to the existing search[] parameters. The index action in the controller sees this, performs the custom sort and passes a custom_sort value to the view.

The view calls the custom_sort_helper with a set of arguments and that creates the column header link with the correct parameters to pass back to the controller.

So far it works well and allows me to sort on my custom columns with a set of rows selected by meta_search searches.

I'm sure the code could be more elegant - leave me a column and tell my how.



 

Rails send_data and UTF-8

I often use send_data to output plain text from a Rails action, typically as a simple way to download, say, a CSV format file.

I'll have something like this to output the text to the browser:


      send_data(@output, :type => 'text/plain', :disposition => 'inline')

But if the text is UTF-8 and contains non-ASCII characters then you need to specify the character set. 

Confusingly, to me, you don't do this with a separate argument at the Rails level. Instead you add it as a modifier on the :type argument like this:

      send_data(@output, :type => 'text/plain; charset=utf-8', :disposition => 'inline')

 

Rails migration add_column and Postgresql

Just ran into a difference between MySQL and Postgresql when running a migration that added a new column to an existing table.

The intent of the original line was to add a new boolean column called 'active' and set the default value to true:

    add_column :people, :active, :boolean, :default => true

This works fine on MySQL but with Postgresql the default value was not used on existing records. It appears that Postgresql sees that NULL is an acceptable value for the column and uses that as the value.

The way to fix this is to add a 'null' attribute to the call like this:

    add_column :people, :active, :boolean, :default => true, :null => false

Now, running rake db:migrate sets all existing records to true

 

Google Chrome Browser, Integers and HTML5 forms

In HTML5 forms you can specify the type of input that is expected with the 'type' attribute.

For example, type = "number" specifies that the input tag expects a number. In general this is great as it permits client side validation, but it can have some side effects in some cases.

The specific case that is causing me problems occurs in the Google Chrome browser when it handles integers entered into an input element with type = "number".

Rather than simple displaying the integer, Chrome inserts commas into the number.

For example, 123456789 becomes 123,456,789

The commas are not included when the form is submitted but they are there if I cut and paste the text.

I don't want these - if I give it an integer all I want to see if the integer. But there is no readily accessible option in Chrome to disable this feature.

The workaround is to explicitly set the type to text (type = "text"). You lose the client side validation but you avoid the commas.

Now, I write Rails applications and use the simple_form gem to help create forms. This knows about the types of input each form input is going to accept and so it liberally uses the 'type' attrbutes. Fortunately you can override these as follows:

    <%= f.input :myinteger, :input_html => { :type => 'text'} %>

The real solution, in my opinion, is for the browser to act very conservatively in interpreting user input. If the server wants the user to see commas then it should tell the browser explicitly.