Archive for the ‘Ruby’ category

Fixing iphone4r

March 12, 2008

There’s a very nice looking plugin for Rails to make it easier to develop iPhone versions of web sites and applications, called iphone4r. It is the work Nicholas Schlueter of Simpltry.com, and built on top of work done by (no surprise!) Joe Hewitt.

The only problem I’ve had with it so far is that it doesn’t work! Okay, the problem is quite small, and fairly easily fixed if you have even the slightest understanding of Rails plugins. Since the plugin fails to copy the iui directory to your /public directory, just add a line to install.rb to copy that over. When you’re done, install.rb should look like this:

require 'fileutils'
RAILS_ROOT = File.dirname(__FILE__) + "/../../../" unless defined? RAILS_ROOT
# Install hook code here
def copy_files(source_path, destination_path, directory)
  source, destination = File.join(directory, source_path), File.join(RAILS_ROOT, destination_path)
  FileUtils.mkdir(destination) unless File.exist?(destination)
  FileUtils.cp(Dir.glob(source+'/*'), destination)
end
directory = File.join(File.dirname(__FILE__), "copy_on_install")
copy_files("/script", "/script", directory)
FileUtils.chmod 0755, File.join(RAILS_ROOT, "script", "ibug"), :verbose => true
copy_files("/public/ibug", "/public/ibug", directory)
copy_files("/public/iui", "/public/iui", directory)

Advertisements

A Kinder, Gentler Phone Number Validation

March 12, 2008

Since the very promising phone_validation plugin from Savvica is not yet done, I threw together a validation that is both super simple for the developer and very kind to the user. I’m sick of web sites that require phone numbers (or credit cards) to be entered as numerals only. That’s just not the way we normally write phone numbers (or credit card numbers), so we shouldn’t be forced to enter them that way on a web site.

My approach allows the user to enter a number between 10 and 20 digits (to allow for longer international numbers, and for punctuation) along with hyphens, periods, parentheses, and spaces. So any of the following would be allowed:
7345551212
734-555-1212
(734) 555-1212
734.555.1212
)(73-4-5551212
etc.

Of course the last one mentioned is not something you’d expect, but it’s allowed, since I don’t bother only limiting the punctuation to specific places. I built the regex with North America and the Caribbean in mind, but allowed longer numbers to account for international differences. (I whipped this together in a very short time… if you want to request changes for internationalization, let me know exactly how your needs differ from what this provides.)

Additionally, this allows for an extension to be included in the number, in a variety of ways:
734-555-1212 x 123
734-555-1212 x. 123
734-555-1212 ex. 1235
734-555-1212 EXT. 12
734-555-1212 eXteNsion 12345
etc.

If the full word “extension” is used, the period is not allowed. The letters of the word could be scrambled, although no one is likely to do that.

  validates_format_of :home_phone, :work_phone, 
    :message => "must be a valid telephone number.",
    :with => /^[\(\)0-9\- \+\.]{10,20} *[extension\.]{0,9} *[0-9]{0,5}$/i 

The things you might want (or need) to change are the number of digits accepted (from 20 to whatever), the word for “extension” and the length of the word (currently 9), and the number of digits allowed for an extension.

If you want to disallow extensions, just change it to:

  validates_format_of :home_phone, :work_phone, 
    :message => "must be a valid telephone number.",
    :with => /^[\(\)0-9\- \+\.]{10,20}$/ 

An alternative to Ruby on the iPhone

March 7, 2008

…from someone who says they’ve tried to do that:Programming Nu.

Here’s the description of the alternative, called “Nu”:

Nu is an interpreted object-oriented language. Its syntax comes from Lisp, but Nu is semantically closer to Ruby than Lisp. Nu is written in Objective-C and is designed to take full advantange of the Objective-C runtime and the many mature class libraries written in Objective-C. Nu code can fully interoperate with code written in Objective-C; messages can be sent to and from objects with no concern for whether those messages are implemented in Objective-C or Nu.

Nu currently requires Mac OS X version 10.5 or greater and runs on PowerPC and Intel systems. A Linux port is in progress; contact me directly or visit my blog for more details.

This is all from the guy that commented on Jason Fried’s prediction about the iPhone (where others raised the question of using Ruby for development):

Regarding Ruby and Objective-C:

I spent a lot of time looking at the combination of Ruby and Objective-C. Starting at the beginning of 2005, I built the RubyCocoa Resources site and later wrote my own bridge from scratch, RubyObjC. Eventually I decided that ultimately, the best way to put a scripting layer on Objective-C was to write one that was specifically designed for the job. Last year I did that, and this afternoon I got it working on the iPhone.)

If I understand this correctly, he’s more-or-less built a modified Ruby specifically designed for building apps on the iPhone. I’m not sure what challenges the new language overcomes where Ruby fails, perhaps in mapping to Objective-C concepts? Or why he chose to use a Lisp-like syntax: it would be much easier for Ruby programmers to adopt if it were both semantically and syntactically like Ruby.

A quick poke around his web site, however, renders answers to these questions.

The Future of the iPhone, according to Jason Fried

March 7, 2008

No discussion of developing with Ruby on the iPhone would be complete without mentioning Jason Fried’s take on the future of development on the iPhone:

What we saw today was the spark. The explosion will continue for twenty years. We will all feel the warmth…. just like there were a lot of players in the portable music space, there were no clear leaders. Until Apple came to town.¶ The same thing is happening today in the mobile space. Palm, Windows Mobile, Blackberry, Symbian. They’ve been players, but no one has broken out big. No one has managed to grab both the business and consumer markets like Windows did on the desktop. Until Apple came to town. At least that’s my prediction.

RubyCocoa on iPhone

March 7, 2008

I’m currently downloading (‘as we speak’–it’s 2.1 GIG) the iPhone SDK, after recently playing around with developing toy apps last night in RubyCocoa.

The idea is irresistable (if not slightly implausible) that it just might be possible to build iPhone apps with RubyCocoa. A quick Google search suggests that others are asking the same question, but no one seems to have an answer. But something on Apple’s site suggests that this might be possible:

The applications you create with Ruby and Python are packaged exactly like native Mac OS X applications. Your end-users will not be able to tell the difference. What’s more, Apple is committed to binary compatibility between releases of Mac OS X. This means you will no longer need to embed the runtime and language interpreter in your application.

So they’re saying that (for non-iPhone RubyCocoa development, at least) you don’t *need* to embed the (RubyCocoa) runtime and language interpreter in your application. This implies that it is possible to embed the runtime for RubyCocoa, and if it’s possible to do on a Mac, why not on an iPhone?

Does anyone know any reason that this would or would not be possible?

Plugging Ruby into Your Brain, revisited…

March 6, 2008

Jesse Newland has an interesting post about how to use Ruby one-liners from QuickSilver, but it wasn’t working reliably for me. Also, I wanted it to show the result in large type, rather than replacing the text of the QuickSilver command prompt. So I tried my hand, even though it relies on passing the Ruby code through AppleScript, and I’m definitely not an AppleScript programmer.

Here’s my version:

using terms from application "Quicksilver"
  on process text ruby
    do shell script "ruby -00 -e '" & ruby & "'" returning result
    show large type result
  end process text
end using terms from

I don’t have any basis for this but an irrational hunch, but I’m hoping that changing the way it returns the result will also help with the reliability. The example one-liner he gave on his page didn’t work for me with his version… let’s see if it works with mine…

(imagine progress bar here)

Whoohoo! It works. It’s possible that I mistyped it when I tried his version, so let me do it again, now that I have a proven snippet in my clipboard.

(imagine another progress bar here)

Whoops! It worked. OK, it must have been a typo on my part… So mine doesn’t really solve anything, it just changes the way the result is displayed.

Come to think of it, although its less flashy, his version has the advantage of making it easy for you to copy the result to your clipboard. Oh well, now we have two versions to choose from. I saved his as “Execute Ruby” and mine as “Execute Ruby–Large Type”.