The OpenLaszlo documentation isn’t specific about how to install syntax highlighting for vim on mac. So we thought we would write up a little blurb about how to do it!

Copy the lzx.vim syntax file to dot vim directory in your home directory
cp openlaszlo/trunk/tools/lzx.vim ~/.vim/syntax/

Create a file called .vimrc.local for your custom vim modifications also in your home directory
mvim ~/.vimrc.local

Finally, add an autocommand that will auto detect the file type
au BufRead,BufNewFile *.lzx set ft=lzx

Reference:
For more information about vim file types you might want to check out http://vimdoc.sourceforge.net/htmldoc/filetype.html

OpenLaszlo documentation on how to install Vim Syntax highlighting on linux based systems
http://wiki.openlaszlo.org/Editing_LZX#Installing_VIM_Syntax_Highlighting

We at Blazing Cloud are excited by the new iPhone 4S; however, we’ve found the decision on which provider to choose to be challenging. Many of us currently have AT&T, and consequently can’t make a reliable call or receive data in the office while off wi-fi. With the initial excitement around the iPhone 4S on Sprint, we ordered a few devices and signed up for a group plan.

When a late lunch led to missing the delivery of our devices, some of the more eager employees at Blazing Cloud took off in a mad dash towards what they suspected was our UPS truck. Luckily they caught the right UPS carrier at the right time and returned with our new iPhone 4Ss. After trying out just about every appropriate and in-appropriate combination of phrases with Siri, we got into more day-to-day use and discovered what many others were discovering– slow data speeds.

After a week of poor voice calls on Sprint, we decided to take a methodical approach to comparing the providers. To conduct a test of data speeds, we took a Verizon iPhone 4S, Sprint iPhone 4S, and an AT&T 4 around town to test popular locations. We’ll update this post when we get ahold of an AT&T iPhone 4S since speeds should be higher with the new device.

We found that even with the slower iPhone 4, AT&T blew Verizon and Sprint out of the water. We ran a speed test using the mobile Speedtest.net app which is free on iTunes.

Japan Town:
Sprint 4S: .26 Mbps
Verizon 4S: .16 Mbps
AT&T 4: 3.39 Mbps

Union Square:
Sprint 4S: 1.08 Mbps
Verizon 4S: .46 Mbps
AT&T 4: 2.77 Mbps

Powell and Market:
Sprint 4S: .41 Mbps
Verizon 4S: 1.09 Mbps
AT&T 4: 3.85 Mbps

This children’s story is an adventure through computer science concepts. The main character, Lauren Ipsum, meets a Wandering Salesman in the first chapter who is finding his way home using the algorithm of that name. It’ll be interesting to read the rest of the book and to see whether it can inspire children to think about algorithms and data from a fun perspective without introducing them as computing concepts.

Pledges on KickStarter go towards translating the book into Spanish, Portuguese, and other languages. This is pretty awesome, since much of software development lingo is taken from English, it is great to evangelize learning computer science concepts in kids’ native languages.

We applaud this effort and look forward to hanging one of the book’s illustrations in our office after the completion of the project.

Even though they have already met their goal, more funding will enable translation in more languages.

Learn more about Lauren Ipsum on KickStarter.

Udemy is an online academy that enables anyone to teach and learn online. Its goal is to “democratize online education by making it fast, easy and free to create online courses.” Courses are wide-ranging in subject, but the most exciting for us are the tech training programs. Blazing Cloud has just announced its first JavaScript course through Udemy: Javascript for Programmers: Behavior Driven Development.

Blazing Cloud also offers in person programming classes at several locations in San Francisco. Upcoming classes include a six week CoffeeScript class, taught by Curtis Schofield, instructor for the Udemy JavaScript class.

The first solution I went with was Localtunnel. It was pretty easy to install the gem and run it. You basically call:

$ localtunnel 3000

Then Localtunnel provides an external URL you can insert for your callback URLs in your Twilio account.

$ localtunnel 3000
Port 3000 is now accessible from http://8bv2.localtunnel.com ...

This was pretty cool, except for the bit where I had to constantly update the callback URL on my Twilio account every time I restarted Localtunnel. I had to find a better way.

The solution I settled on was remote SSH port forwarding. I had originally gone down this path but the part that had tripped me up was that by default, remote port forwarding is disabled. To enable it, you have add the following line on the forwarding server’s /etc/ssh/sshd_config file:

GatewayPorts yes

Once you make the change and restart sshd, you can run the remote port forwarding command:

ssh -R 3333:localhost:3000 external.host.com

What this means is that the local process on port 3000 (Rails) can be accessed via port 3333 on the port forwarding server’s address. That is, http://external.host.com:3333 is “rerouted” to http://localhost:3000.

Here’s a simple diagram explaining how the whole thing works (local port 8080, remote port 8888).

Related resources you may find useful:

That’s all folks!

Here are the slides from my talk at Founder Labs:

We set up another Heroku app with just a one-line rack application.  All it needed was a rackup config file, called “config.ru” with the following line:

run Proc.new { [ 302, {'Location'=> 'http://blazingcloud.eventbrite.com' }, [] ] }

and voila! It does a simple re-direct to the new site.

it 'verifies that login is between 3 and 40 characters' do
   User.new.should validate_length_of(:login, :within => 3..40)
end

I like that validation syntax, but lately when I see a plugins, I worry that I’m in for some archaeology. I did find a replacement gem, but it didn’t work on first try, so I read up on my options. I briefly considered shoulda, which is now compatible with rspec, but I settled on remarkable because it seems to match the syntax already in use. I wrote a little test rails app with a couple of models and was pleased the results.

Setup

rails new remarkable_app -T"
cd remarkable_app

add to Gemfile:

    group :development, :test do
      gem "rspec", "2.6.0"
      gem "rspec-rails", "2.6.1"
      gem "remarkable_activerecord", "4.0.0.alpha4"
    end

Then back on the command line, set up rspec:

rails g rspec:install

edit spec/spec_helper.rb to include (after require ‘rspec/rails’):

    require 'remarkable/active_record'

Create a Model

Then make a model to play with (on the command line):

rails g model person name:string email:string
rake db:migrate
rake spec
/Users/sarah/.rvm/rubies/ruby-1.9.2-p290/bin/ruby -S bundle exec rspec ./spec/models/person_spec.rb
*

Pending:
  Person add some examples to (or delete) /Users/sarah/src/mv/experiment/remarkable_app/spec/models/person_spec.rb
    # Not Yet Implemented
    # ./spec/models/person_spec.rb:4

Finished in 0.00026 seconds
1 example, 0 failures, 1 pending

yay! ready to get started test driving some remarkable validations…

Test Driven Validation

Let’s test drive our first validation..

describe Person do
  should_validate_length_of :name, :within => 3..40
end

note that remarkable also supports:
it { should validate_length_of :name, :within => 3..40 }
For my new code I’ll probably write the more concise version, but it is nice that my old code should work.

$ rake spec
/Users/sarah/.rvm/rubies/ruby-1.9.2-p290/bin/ruby -S bundle exec rspec ./spec/models/person_spec.rb
F

Failures:

  1) Person
     Failure/Error: send(should_or_should_not, send(method, *args, &block))
       Expected Person to be invalid when name length is less than 3 characters
     # ./spec/models/person_spec.rb:4:in `block in <top (required)>'
     # ./spec/models/person_spec.rb:3:in `<top (required)>'

Finished in 0.30367 seconds
1 example, 1 failure

Failed examples:

rspec /Users/sarah/.rvm/gems/ruby-1.9.2-p290@remarkable_rails3/gems/remarkable-4.0.0.alpha4/lib/remarkable/core/macros.rb:26 # Person
rake aborted!
ruby -S bundle exec rspec ./spec/models/person_spec.rb failed

add validation to my model…

class Person < ActiveRecord::Base
  validates_length_of :name, :within => 3..40
end

Test passes!

$ rake spec
/Users/sarah/.rvm/rubies/ruby-1.9.2-p290/bin/ruby -S bundle exec rspec ./spec/models/person_spec.rb
.

Finished in 0.27601 seconds
1 example, 0 failures

More validations:

describe Person do
  should_validate_length_of :name, :within => 3..40
  should_allow_values_for :email, "sarah@foo.com"
  should_not_allow_values_for :email, "sarah", "@foo", "whatever.com"
end

Reasonably nice error output:

$ rake spec
/Users/sarah/.rvm/rubies/ruby-1.9.2-p290/bin/ruby -S bundle exec rspec ./spec/models/person_spec.rb
..F

Failures:

  1) Person
     Failure/Error: send(should_or_should_not, send(method, *args, &block))
       Did not expect Person to be valid when email is set to "sarah"
     # ./spec/models/person_spec.rb:6:in `block in <top (required)>'
     # ./spec/models/person_spec.rb:3:in `<top (required)>'

Finished in 0.29054 seconds
3 examples, 1 failure

Failed examples:

rspec /Users/sarah/.rvm/gems/ruby-1.9.2-p290@remarkable_rails3/gems/remarkable-4.0.0.alpha4/lib/remarkable/core/macros.rb:26 # Person
rake aborted!
ruby -S bundle exec rspec ./spec/models/person_spec.rb failed

Cheated a little on implementation by copying email validation from ActiveRecord docs… all good.

Now let’s add an association!

In app/model/person.rb:

describe Person do
  should_validate_length_of :name, :within => 3..40
  should_allow_values_for :email, "sarah@foo.com"
  should_not_allow_values_for :email, "sarah", "@foo", "whatever.com"
  should_have_many :addresses
end

Watch it fail:

$ rake spec
/Users/sarah/.rvm/rubies/ruby-1.9.2-p290/bin/ruby -S bundle exec rspec ./spec/models/person_spec.rb
...F

Failures:

  1) Person
     Failure/Error: send(should_or_should_not, send(method, *args, &block))
       Expected Person records have many addresses, but the association does not exist
     # ./spec/models/person_spec.rb:7:in `block in <top (required)>'
     # ./spec/models/person_spec.rb:3:in `<top (required)>'

Finished in 0.32615 seconds
4 examples, 1 failure

Make it pass:

$ rails g model address street:string person:belongs_to
      invoke  active_record
      create    db/migrate/20110721161741_create_addresses.rb
      create    app/models/address.rb
      invoke    rspec
      create      spec/models/address_spec.rb
$ rake db:migrate

.

Pending:
  Address add some examples to (or delete) /Users/sarah/src/mv/experiment/remarkable_app/spec/models/address_spec.rb
    # Not Yet Implemented
    # ./spec/models/address_spec.rb:4

Finished in 0.2998 seconds
5 examples, 0 failures, 1 pending

the rest is left as an exercise for the reader :)

Summary

Overall, I like the remarkable syntax. It seems reliable and on its way to a good release for Rails 3.

For information or to sign up, please visit our class page at

http://classes.blazingcloud.net

For an idea of what to expect from this class, check out this video episode from the first session of a previous class, complete with course outline and objectives:

1st Episode

For a complete list of episodes, visit Wolf’s blog!

Luke Wroblewski did some sweet research on inline validations and found out that people think they are totally awesome. Brian Cardarella implemented that research in the gem client_side_validations. The gem automatically generates lots of client validations based on your rails model validations. I wrote an application showing some of its capabilities and how to extend its functionality. Alright guy, show me some source for how to use this gem. I don’t need the stinking source, just let me see your app.

The Long Version

Back in 2009, Luke Wroblewski performed some research on inline form validation and how users respond to different types of inline validations (i.e. javascript validations that give immediate feedback). People complete forms quicker, make fewer mistakes, and are more satisfied when filling out forms with inline validations.  When asked to fill out a registration form, people were 42% quicker at completing the form when inline validations were present. Awesome!

This is great information to have about the way people interact with forms on our websites. Imagine we are building our own registration form for our next sweet application and we add inline validation. Our users are going to be happier with the experience of registering, they will make fewer mistakes, and they will be able to start ACTUALLY using our totally-awesome application quicker. There is just one problem… Manually coding inline validations can be a somewhat cumbersome process. First, we have to make sure that our server-side validations are working properly. After we have tested the backend, we then need to manually code up a fair bit of javascript in order to get the inline validations working. Not only is writing this inline validation code often uninteresting (we want to get the real features like that cool video player implemented). There is also a very big maintenance issue with this approach; we are actually going to write the same validation code twice: once in Rails and once in Javascript. So now, whenever we update our backend validation logic, we need to remember to update our client validation logic as well. Wouldn’t it be great if there were a way to automatically generate our client validations based on our backend code?

Enter the shiny new (very-appropriately named) gem client_side_validations. Brian Cardarella wrote the client_side_validations gem as a result of Luke Wroblewski’s research. Check out Brian’s blog post on his gem. With a few simple lines of code, we can add inline validations to our forms. The validations are generated with the default form builder, formtastic, or simple_form. A lot of the rails model validations, including (but not limited to) length_of, presence_of, uniqueness_of, and format_of are all supported out of the box, so your forms will be making these validations as soon as you install and setup the gem. You can also add your own custom validators if what comes out of the box is not enough for your bleeding-edge rockin’ Rails application.

So how does it work? What does an application that uses this gem look like? How the heck can I use this thing with existing technologies? These are some questions your are undoubtedly asking yourself this second, and I will answer them (sort of).

How does it work?

It’s simple! The gem extends the Rails default form builder, and all you have to do is set a :validate => true option on any form_for (or simple_form_for for simple form users) tag that you want the inline validations for. The form builder uses some rails reflections on your model validations to generate some json that gets included in a script tag after your form. The json is then used by the gem’s Javascript framework to perform the validations that need to be performed.

What does an application that uses this gem look like?

I have built a sample application that uses this gem to perform inline validations on a very contrived user registration form. Here is the github source and here is the Heroku application. You can create a state in the database, then you can add cities to that state. Once you have done this, you can register with the system as a user. The state and city that you enter when registering validates against the database you create. Also, this site is very selective, and you must be born on a Monday in order to register (just to show off how date validations can work). The application is a little contrived (only aliens, or time travelers would use it), but it does illustrate some more advanced ways that you can use custom remote and local inline validators with your forms.

How does it integrate with existing technologies?

As stated previously, it integrates nicely with formtastic and simple form. The sample application also shows how to integrate with devise. Take special note of the regular expression that was added to the user model. This is necessary because the default regular expression that devise uses to validate an email address does not compile in the Javascript regular expression engine.

Check out the source.

See it in action on Heroku here.

Make sure to add your states and cities before you register! Also, I know you are supposed to be born on a Monday to use the site, but you can fake your birthday, I won’t get mad (I wasn’t even born on a Monday).