Sociable
Sociable is a software development house based in Devonport, Auckland. We specialise in Ruby on Rails, Mac and iOS development.
Contact us: +64-22-680-3869 or james@sociable.co.nz
Sociable is a software development house based in Devonport, Auckland. We specialise in Ruby on Rails, Mac and iOS development.
Contact us: +64-22-680-3869 or james@sociable.co.nz
Last week I spent some time modifying Kisko Labs’ sproutcore-rails gem to use the latest build of Ember.js. emberjs-rails is a fairly simple wrapper that add’s support for serving Handlebars templates from the asset pipeline using a hjs file extension. It also serves Ember’s html5 boilerplate template as a layout called ember. Here’s a quick run through:
First, start with an empty Rails 3.1 installation:
Next, install an empty Rails application:
Add emberjs-rails to your application’s Gemfile and run bundler:
Generate a controller to serve your Ember.js application from:
Setup basic routing for your new controller: config/routes.rb
Modify your new controller to use the ember layout included in emberjs-rails, this is a slight modification of the html5 boilerplate file included with Ember.js’ starter kit: app/controllers/hello_controller.rb
Create a handlebars template to use within your Ember.js application: app/assets/javascripts/views/hello.js.hjs
Create a view on for your home_controller to include your new handlebars view, which the asset pipeline will compile for you automatically. You can also include additional information for the html meta tags and page title if you want to: app/views/hello/index.html.erb
Lastly, create your Ember.js application and create a view from the template above. The rails 3.1 ships with CoffeeScript support by default, so I’ve created the app using CoffeeScript to show how it’s done:
Now if you start your server and browse to it (usually localhost:3000 you should see a large “Hello World!” which is rendered using the template and the property on the view we created. You can also open up your browser’s JavaScript console and change the value of the text property on the hello_view object and watch it dynamically change on screen.
I hope that gives you enough information to go forth and JavaScript. Enjoy!
There seems to be a lot of chit chat in the rails world about correctly validating email addresses. The main problem is the compromise between speed and correctness, observe:
The examples above illustrate the possible methods of email validation ranging from pathetic to extreme. Given the average response speed of DNS, I think it’s legitimate to attempt a DNS lookup of the addresses domain name. This ensures that at least the user isn’t just entering ‘asdf@asdf.asdf’ to circumvent validation. Some applications however will require a higher level of certainty though, and the only way you can do that is to connect to the remote MTA and start message delivery for the address. Note that you don’t have to complete it, just verify that the SMTP server accepts the RCPT TO command without throwing an error.
I hope you find this somehow useful.
You know what I’m talking about. Businesses all over the world send out emails, whether they’re some sort of notification, invoice or marketing communication and they disallow direct replies, either by explicitly asking you not to or using a dead-end email address such as “no-reply@idontvaluemycustomers.com”.
This totally disrespects your customer, and devalues their time. I, as a customer am supposed to go to your website, find out how to contact you and then effectively communicate the context of my suggestion or problem when just hitting the reply button in my email client would have provided all this for me.
Here’s my suggestion:
From now on I will be adding a “please reply” option to emails sent from my projects to ensure my customers know that I’m here to help them. See this gist for source.
Yeah, I know. The Arduino development environment is quite limiting - especially if you are using an AVR chip that is not supported or you don’t have room for the bootloader in your project.
Something you might not have realised is that the Arduino environment comes with all the development tools needed (avr-gcc, etc) needed to build and burn firmwares for a large number of AVR based MCUs. Rather than waste your time building and installing development environment you can just hijack Arduino’s ones for your purposes with a single line of shell code. I’ve added the following to my .bashrc:
Using this I am able to compile axe.io’s usb firmware without issue.
Here’s the thing; I’m in this band, and due to the terrible prog rock nature of this band I needed more control over my tone than I was able to get just from my amplifier, so I invested in an iRig and a copy of Amplitube for iPhone. I was blown away by the quality of simulation available on…
(Source: axeio)
Venus is too close - space rock from outer space.
Today I deployed the site for Venus is too close - my space rock band. This wouldn’t ordinarily be newsworthy, however it is interesting because it’s a completely static site built using HAML and SASS to generate the output markup using a technique I’ve mentioned here before and deployed into production using Chef’s git deploy resource.
Kimono is using Carrierwave to handle image attachments and save them into GridFS - MongoDB’s built-in filesystem. GridFS is great because you get the benefits of MongoDB’s replication and sharding. Putting files into GridFS is pretty straight forward, and I won’t waste time getting into that here, Jeremy Weiland has written an excellent post on using Rails 3, Carrierwave and GridFS which does a great job of covering off the specifics of getting the three pieces of software to talk nicely together. One thing that immediately jumped out to me was the fact that Jeremy’s Rails Metal controller reads the entire file contents into RAM before sending it back to the client:
Rather than go his route I decided to monkey patch Mongo::GridIO to respond to the each method, which is required by the Rack API:
Next I can use the Rails 3 router’s ability to pass in a proc to use directly as a rack handler to respond to the request while bypassing as much of the rails stack as possible:
So now the GridFS file is streamed chunk-by-chunk to the client without storing the contents of the file in RAM on the way. Also, with a small modification this file can be moved directly to a rackup file and used directly by a rack enabled web servers such as passenger:
I hope I’ve given you a good overview of how insanely great Rack is, and how easy it is to use GridFS from within Rack. Yay for us.
Delayed::Job comes out of the box with a startup script that relies on the daemons gem. to start and stop worker processes. Problem is, I’ve never actually had it work. After browsing around my options I decided to give daemonizer a go. The main advantage I saw to daemonizer is that you simply define a single “Daemonfile” in your project’s root (similar to a Gemfile or Rakefile) explaining how to set up each processes environment.
My Daemonfile looks like this:
The only minor problem I had was with daemonizer’s gem dependencies clashing with my apps. I have submitted a patch to make sure that daemonizer uses bundle if the project has a Gemfile present.
I love HAML. I love SASS. They’ve both saved me a heap of time writing view code in Rails, but what if you’re throwing together some static HTML and CSS to mock out an interface? This is where the Travis Tilley’s excellent file system state monitor gem comes in:
Boom!
If you’ve perused the source of any moderately complicated Rails application you are likely to have come across the Single Table Inheritance (STI) pattern. STI allows you to have polymorphic models all stored in the same table or collection. It may be best to give you an example:
As you can see from the example, we have three models, Meat, Bacon and ChunkyBacon all using the “meats” table for storage. This is really great, especially if there is common model logic (attributes, validations, life-cycle callbacks, etc) needed for all three models, and extra logic on the child models (imagine ChunkyBacon has a season).
Kimono makes extensive use of STI behaviour throughout it’s model graph, although built upon the Mongoid ORM. I kept running into problems where I needed to have routes for every new subclass I created and it didn’t really fit the way I wanted the application to work. The problem is not actually the router (a simple map.resources :meats) works perfectly, but with the route helpers. A call to url_for or link_to when passed in a model instance would throw an exception because there were no routes defined for Bacon or ChunkyBacon. I started with overriding the helpers (link_to, et al) but soon discovered this didn’t work well enough because the assumptions Rails makes about routing your models go deep. How deep? To ActionDispatch::Routing::PolymorphicRoutes as it turns out.
In order to create the behaviour I wanted I needed to add a reusable method to climb up a model’s superclass chain checking if the parent is a Mongoid document until it reaches the top of the inheritance tree, then I needed to patch “build_named_route_call” to use this instead of just using the class of the model being routed. Enter lib/kimono/routing.rb:
Once that’s done, I simply add an initialiser to patch in the behaviour I want:
Now when I call url_for(@bacon) I get “/meats/1” back. Thanks Ruby.
