That answer? Because no one else is. It’s stupid really, but it’s the truth. We’re all afraid to run our applications in 1.9 because we don’t know many other people that are. Because of that it makes it hard for you to make your application work with 1.9 because all those gems and libraries  you use aren’t 1.9 compatible, so you’re forced to keep running your app on 1.8. And so the cycle continues.

Enter Rails 3.0. Here is a major upgrade to the most prominent web framework in the Ruby community, and I would argue the reason that most of us got into Ruby in the first place. This upgrade will force us all to make some pretty severe changes to our applications to make them fully compatible.  The changes in ActiveRecord alone are so sweeping and massive that we, as a community, are going to have to put some serious time into upgrade our applications. Yet, despite this, we are all going to do it.

Why are we all going to upgrade to Rails 3.0? Because it  looks cool and sexy, and we want those great new features and all those performance enhancements to make our applications run faster. Which leads me back to Ruby 1.9.

In Rails 3.0 they are dropping support for Ruby 1.8.6 and below in favor of Ruby >1.8.7 and >1.9.1. I propose that Rails 3.0 becomes Ruby 1.9 compatible only. Think about it. What a perfect opportunity for us all. We are all going to have to upgrade the libraries and gems we maintain to support Rails 3.0 and we are going to be upgrading our applications to Rails 3.0, so why not go full steam into Ruby 1.9?

There is no better time than now to push forward into the future as a whole community. Let’s put Ruby 1.8 behind and reap the benefits of what Ruby 1.9 has to offer. What do you say? Can we do it? I think we can.

It was an absolutely amazing experience and I can’t thank everyone involved with the project enough for all of their help, guidance, and having to put up with me over the past year.

I would go into detail about all the people I wish to thank, but I did that already in the book, and let’s be honest, you’re going to buy it and read it anyway, so I don’t want to ruin the surprise.

I’m sure you’ve already purchased your copy, but if you haven’t might I recommend you pop over to Amazon right now and pick yourself up a copy. They’re selling pretty well and you don’t want to miss out, do you? I didn’t think so.

If you are someone with a popular blog and you would like to do a review of the book, please drop me a line and I’ll see what we can do about hooking you up with a copy. Please understand, though, the publishers aren’t going to send out copies to everyone who requests them, so there will be a bit of vetting going on.

Also, if you have already purchased the book if you wouldn’t mind leaving a review of it on Amazon, that would be much appreciated. It doesn’t matter where you bought the book, if you could leave a review there, it will really make a difference. Thanks.

Buy “Distributed Programming with Ruby” Today!

Enter the APN on Rails gem. While searching I found one plugin for Rails that mostly worked for me, Sam Soffes’ apple_push_notification plugin. It was a great place to start, but I found that there were things that didn’t suite me. For starters, not having any tests is always a big turn off for me when it comes to any code. I also didn’t like that you didn’t need to save a notification in order to send it. That means you don’t have a record of what was sent and when. I also wanted to have devices stored separately from the notification. Finally, I wanted to be able to easily configure the plugin. Sam’s was using constants that would need to be changed when it hit production.

So, with all that said and done I took Sam’s great work, ripped it apart, and put it back together again, this time in gem form instead of a plugin, and here it is.

There are a few migrations, a few models, and a few Rake tasks, but here is the basic idea of how it works:

To get a better understanding of exactly how it works, and what it does, I highly recommend reading the RDOC.

There are a few things I still would like to add, for example, a controller to do CRUD for devices so iPhones can register with the Rails app. I’d also like to add a task that talks to Apple and finds out which devices are no longer accepting messages so they can be removed.

If you’d like to contribute, please feel free and for the project on GitHub:
http://github.com/markbates/apn_on_rails/tree

Again, a special thanks to Fabien Penso and Sam Soffes for their initial work on this project.

Implied Manifests

The easiest way to use Genosaurus is to let it do the work for you. Let‘s looked at what‘s called an ‘implied’ manifest:

  dir:
    simple_generator.rb
    templates:
      hello_world.txt.template

That‘s our folder structure. Now let‘s look at simple_generator.rb:

  require 'rubygems'
  require 'genosaurus'

  class SimpleGenerator < Genosaurus
  end

Now if we run that generator:

  $irb: SimpleGenerator.run

We should get a file called hello_world.txt generated in the current directory. Yes, it truly is that simple! With implied manifests our directory structure under ‘templates’ tells the whole story, and Genosaurus is smart enough to figure it out. All the file names, and the same goes for folders, need to end in .template, and Genosaurus will do the rest. All the files will go through ERB before they generated, so you can put all your lovely little dynamic goodies in there. File, and folder, names also get run through ERB so you can even make the file name dynamic too! Let‘s look at a more complex example:

  dir:
    complex_generator.rb
    templates:
      app:
        views:
          <%=param(:name).plural%>.template:
            hello_world.html.erb
        models:
          <%=param(:name)%>.rb.template

Let‘s run our complex_generator.rb file:

  require 'rubygems'
  require 'genosaurus'

  class ComplexGenerator < Genosaurus
    require_param: name
  end

Now if we run that generator:

  $irb: ComplexGenerator.run("name" => "user")

Now you should end up with the following:

  app:
    views:
      users:
        hello_world.html.erb
    models:
      user.rb.template

In the ComplexGenerator we told Genosaurus that we are requiring that the parameter, name, be passed into it. We are then using that parameter to generate the names of some files and folders. Pretty cool, eh? See how simple that is.

Explicit Manifests

Explicit manifests are used when there is a manifest.yml supplied at the same level as the generator. If there is a manifest.yml file then implied manifests are not used. This means you have to define the entire generation process. This is great if you have a pretty complicated generator, as the manifest.yml is also sent through ERB before being loaded. Let‘s look at the manifest.yml file for our simple_generator example:

  template_1:
    type: file
    template_path: <%= File.join(templates_directory_path, "templates", "hello_world.txt.template")
    output_path: hello_world.txt

Pretty simple. We give the template a name, template_1, it really doesn‘t matter what it is, but Hash objects need keys. The ‘type’ parameter is either file or directory. The template_path is the path to the template. Finally, the output_path is the where you want the file to be generated. Let‘s look at our more complex example. We can change the directory structure a bit, since we really don‘t need ERB in the file names now:

  dir:
    complex_generator.rb
    templates:
      hello_world.html.erb.template
      model.rb.template

Our manifest.yml file would look like this:

  hello_world_template:
    type: file
    template_path: <%= File.join(templates_directory_path, "templates", "hello_world.html.erb")
    output_path: <%= File.join("app", "views", param(:name).plural, "hello_world.html.erb") %>
  model_template:
    type: file
    template_path: <%= File.join(templates_directory_path, "templates", "model.html.erb")
    output_path: <%= File.join("app", "models", "#{param(:name)}.rb") %>

This will generate the exact same thing as our implied manifest.

I jumped on the spec test bandwagon about a year or so ago. I forced my whole team to start writing in nothing but spec tests. The team, is still not impressed. If I were to tell them we weren’t using spec tests anymore, they would be EXTREMELY happy with that.Spec tests are certainly prettier than ‘regular’ tests. I’ll give you that. They are more ‘human readable’. With that said I find assert_equal to be fairly easy to read.

So why do I use regular tests, and not spec tests? A couple of reasons. First, they’re there and built right in to Ruby, ready to go, no new gems or syntax to learn. They’re fast. They are faster than spec tests. I see it everyday at work. I can also, and this one is HUGE, run just a single test or a regex’d series of tests. I really love that last bit. I have yet to find a way to do that, easily, with spec tests.

Again, how people write tests doesn’t really matter so much to me, it’s just that they write them. Testing is too easy in Ruby, there’s just no reason for not writing them.

I’m very excited about this release. This is one of the first features that starts to set Mack apart from other Ruby frameworks such as Rails and Merb.  Mack is trying to set itself as the framework for doing multiple, distributed, portal applications. This release gets us headed in that direction.

There will be a tutorial post and app in the next few days. In the meantime I highly encourage you to download this release and check it out.

Changelog:

• Added Distributed Routes!

• gem: mack_ruby_core_extensions 0.1.3

• removed gem: ruby_extensions

$ sudo gem install mack

One of the main Mack pieces that has been broken out into this new gem is the inflection system. Now you can have inflections as part of any Ruby application just by requiring the gem. As far as I can tell this is the first stand alone inflection system for Ruby. I know because I couldn’t find one for Mack, that’s why I had to write one.

This gem will continually be updated, outside of the core Mack code. The forthcoming release of Mack, 0.4.0, will be converted to use the new gem.

Those who wish to contribute to the gem can find it on GitHub at: http://github.com/markbates/mack_ruby_core_extensions

The API for mack_ruby_core_extensions can be found at:
http://mrce-api.mackframework.com/

 $ sudo gem install mack_ruby_core_extensions

Instead of focusing on what didn’t make it in, let’s talk about what did make it in! There’s some cool stuff in this release.

Format Driven Content

Mack now allows you to drive different content based on the format requested. For example:

/posts – will render app/views/posts/index.html.erb
/posts.html – will also render app/views/posts/index.html.erb
/posts.xml – will render app/views/posts/index.xml.erb – A special note *.xml.erb files, despite their name, do NOT get run through ERB, instead they use the XML Builder library
/posts.js – will render app/views/posts/index.js.erb
etc…

Alternatively, in your action you can now define ‘want’ blocks, to run specific code based on the format. Example:

class PostsController
  def index
    # find all the posts in the system
     @posts = Post.find(:all)
    wants(:html) do
      # this will only be run if html is requested.
      # we need a username for a 'welcome message in the view'
      @username = @user.username
    end
    wants(:xml) do
      # this will only be run if html is requested.
      # find the last published date
      @last_pub_date = Rss.find_last_by_date_by_object(:posts)
    end
  end
end

XML Builder Support

I’m not going to go into this, there is another nice post coming shortly that will explain how to use this library to add RSS to our blog demo. Here’s the post.

Built-in Encryption

In every app I’ve ever built I found the need to use encryption. Whether it’s for encrypting something into a cookie, a password in the database, or a file on disk, we all need encryption, so I’ve baked the crypt gem into Mack.

At the very simple level you can easily do this in your code:

@my_encrypted_value = _encrypt("hello world")

and you’ll be returned a nice pieced of garbled data using the Crypt/Rijndael library. Decrypting is just as easy:

_decrypt(@my_encrypted_value) # => "hello world"

See, I told you it couldn’t be easier. It gets even better you can even define your own ‘worker’ to implement other encryption schemes. It’s as simple as this:

class Mack::Utils::Crypt::HorribleWorker
  def encrypt(value)
    value.reverse
  end
  def decrypt(value)
    value.reverse
  end
end

_encrypt("hello", :horrible) # => "olleh"
_decrypt("decrypt", :horrible) # => "hello"

See how easy that was? You can also do:

@my_encrypted_value = "Hello".encrypt
@my_encrypted_value.decrypt #=> "Hello"

Either way it’s now easy to handle encryption in your funky cool Mack app.

Changelog:

• Ticket: #8 Xml Builder Support
• Ticket: #7 Ability to drive certain content based on ‘format’
• Ticket: #9 Added a global encryption system to make encrypting/decrypting of strings easy to use
• gem: builder 2.1.2
• gem: crypt 1.1.4

Mack 0.3.0 introduces xml rendering support natively, so this shouldn’t be so hard. First things first, let’s fire up the app, shall we:

$ rake server

Now let’s head over to http://localhost:3000/posts. We should see our beautiful posts index page. Now let’s try to go to http://localhost:3000/posts.xml you should see something that looks like this:

Clearly, that’s not what we want, is it? I didn’t think so. The error is telling us that it’s looking for a file called index.xml.erb in the app/views/posts directory of our blog project. Obviously that file doesn’t exist.

Let’s take a second and talk about why Mack was looking for index.xml.erb. We haven’t changed anything in our controller. Our index method still looks something like this:

def index
  @posts = Post.find(:all)
end

No where in there does it mention xml. The only place xml is mentioned is on the the url itself, remember? We looked for /posts.xml. By adding .xml you’re telling Mack that you want to render, well… xml. So it goes looking for that. That’s also new in 0.3.0. The default is html, but if you append a format (.js, .xml, etc…), it will go looking for app/views/<controller_name>/<action_name>.<format>.erb and render it.

Ok, now that we understand why we’re looking for an xml file, let’s fire up our trusty text editor and create a new file called: app/views/posts/index.xml.erb. Let’s edit the file to look like this:

xml.instruct!  ml, :version=>"1.0"
xml.rss(:version => "2.0") do
  xml.channel do
    xml.title("My Mack Blog")
    xml.link(posts_index_full_url)
    xml.description("Find out about all the cool stuff happening on my blog!")
    xml.language("en-us")
    xml.copyright("Copyright Me")
    xml.pubDate(CGI.rfc1123_date(Time.now))
    xml.lastBuildDate(CGI.rfc1123_date(Time.now))
    @posts.each do |post|
      xml.entry do
        xml.title(post.title)
        xml.link(posts_show_full_url(:id => post.id))
        xml.description(post.body)
        xml.pubDate(post.created_at.strftime("%a, %d %b %Y %H:%M:%S"))
      end
    end
  end
end

Mack uses the standard builder gem library. I’m not going to go into explaining how that works, there are plenty of other tutorials and documentation that will show you that. I’m also not going to explain all the necessary pieces of an RSS feed. Instead I’ll point out in that code you’ll see we’re using the @posts instance variable that we set in the index action of our PostsController. Just like regular *.html.erb files we have access to all the instance variables from the controller, as well, helpers, etc…

So now if we go to http://localhost:3000/posts.xml we should see our RSS feed. If we did a view source we should see something that looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
 <channel>
  <title>My Mack Blog</title>
  <link>http://localhost:3000/posts</link>
  <description>Find out about all the cool stuff happening on my blog!</description>
  <language>en-us</language>
  <copyright>Copyright Me</copyright>

  <pubDate>Tue, 18 Mar 2008 17:18:05 GMT</pubDate>
  <lastBuildDate>Tue, 18 Mar 2008 17:18:05 GMT</lastBuildDate>
  <entry>
   <title>My New Post</title>
   <link>http://localhost:3000/posts/1</link>
   <description>This is my first post in my cool Mack blog!</description>

   <pubDate>Tue, 18 Mar 2008 11:58:30</pubDate>
  </entry>
 </channel>
</rss>

Awesome! All that’s really left is create one of those fancy RSS tags in the location field of our browsers that people can click and go straight to the RSS feed. Let’s do that now.

At the top of your app/views/posts/index.html.erb file add the following:

<%= rss_tag(posts_index_url(:format =>  ml)) %>

Now, refresh the page in your browser, and there you go, you should now see the little RSS button in the location bar of your browser. If you click that you should be taken to your feed.

That’s all there is to adding not only xml, but an RSS feed to your new blog.

The code for this demo can be found here.

I work for a company that for the time being shall be called Menderchuck. Menderchuck has been using Ruby on Rails since the company started two years ago. I am employee number three at Menderchuck, and was hired directly by the VP of Development. I was hired as the Senior Software Architect. I’m now the Director of Architecture for the company. Sorry about the bragging, I just like telling people I’m a director!

Prior to joining the company I had been using Rails for about 6 months, long before v1.0.0 of the now widely used framework. I loved Rails. I still do in fact, well, kind of. More on that later. Rails was the only choice for developing Menderchuck. The VP of Development and myself were huge fans, and having both come from Java backgrounds, we loved the flexibility and fun of Ruby as a language and Rails as a framework.

As I said we’ve spent the past two years developing Menderchuck using Rails, and for the most part things have been OK. I can’t say that they’ve been great, because, well, they haven’t. We’ve had scalability problems, deployment problems, and most importantly problems with the constraints that Rails places on development team.

The idea of an opinionated framework is great, in theory. If you follow and play by their rules things are great. The problem arises if you want to stray from the beaten path. Then you are left out on your own. Left to forge your own path, and as we’ve found at Menderchuck, you end up doing a whole hell of a lot of hacking!

Rails was designed for, and is incredible for building Web 2.0 applications. Menderchuck, although touted by the CEO as a Web 2.0 application, is really more of a complex and large scale web application, in the flavor of Web 1.0 applications. It’s also more of a portal, which can be a very difficult thing to build with the Rails framework.

Now don’t get me wrong, you CAN build a portal using Rails, but it really involves turning the framework on it’s head and kicking it in the neck. That just shouldn’t be the way build things.

Enter Mack. (More to come…)