Blog

Archive for January, 2009

Engine Yard Announces New Cloud Offering!

By | January 14th, 2009 at 4:01PM

It’s a beautiful day in San Francisco, and we’ve got some exciting new tech to go along with it — what more can you ask for?

Today we announced two key components to the Engine Yard Cloud strategy: Solo and Vertebra. Together, these offerings tackle the challenges of developing, deploying, managing, and securing large-scale applications for the cloud.

For two years Engine Yard has specialized in Ruby and Rails application deployment by providing premium deployment services for over 400 customers on in-house hardware. Engine Yard Solo now extends this expertise to companies of all sizes by offering their services for deploying applications on the Amazon Web Services cloud.

Vertebra is the first complete, open platform for developing and managing secure cloud applications. Initially built to automate, scale, and manage customer applications running on Engine Yard’s own cloud, Vertebra has broadened into a powerful framework for building cloud-specific applications. Vertebra is an Open Source project, and we’re eager for new community contributions!

You can read more about these two offerings in the official announcement, or in the news:

Thanks to all those customers and community members who helped beta test both Solo and Vertebra; we couldn’t have done it without you!

Popularity: 1% |

Some Thor News

By | January 13th, 2009 at 4:01PM

Over the past few months, people have been using thor for increasingly serious things. The project itself was extracted out of my textmate gem, and is a nice Railsish DSL for command-line applications. It uses classes and methods as its abstraction, in much the same way that Rails uses classes and methods. Here’s an example:

class Speak < Thor
  desc "name", "the name to say hello to"
  def hello(name)
    puts "Hello #{name}"
  end
end

Put a class like that in a file named Thorfile or *.thor into any directory or its tasks directory, and you’ll be able to invoke thor speak:hello Yehuda, and it will print Hello Yehuda. Thor also supports full option parsing:

class Speak < Thor
  desc "name", "the name to say hello to"
  method_options :loudly => false
  def hello(name)
    name.upcase! if options[:loudly]
    puts "Hello #{name}"
  end
end

Interestingly, the thor runner itself is just a thor script. That’s because the following is a valid stand-alone Ruby file that does not require the thor runner:

require 'rubygems'
require 'thor'

class Speak < Thor

  desc "name", "the name to say hello to"
  def hello(name)
    puts "Hello #{name}"
  end
end

Speak.start

You would invoke that script with binary_name hello Yehuda. The thor runner simply uses method_missing on the Thor::Runner class, so that thor foo:bar works, even though there is no foo:bar method in Thor::Runner. Here’s the method_missing method on Thor::Runner:

  def method_missing(meth, *args)
    meth = meth.to_s
    super(meth.to_sym, *args) unless meth.include? ?:

    initialize_thorfiles(meth)
    task = Thor[meth]
    task.parse task.klass.new, ARGV[1..-1]
  end

In the past few weeks, I finally got around to adding some sorely needed features. The first, to transparently wrap thor files in a Thor::Tasks namespace, so, for instance, the Merb < Thor class doesn’t conflict with the Merb module. The second was to add thor bundles (a surprisingly small commit), which allow the packaging of several files into a bundle. In the case of thor bundles, all you need to do is name a directory *.thor (instead of a file) and put a main.thor file inside. Everything will then work as expected.

Finally, thor tasks can be installed systemwide by simply calling thor install filename or thor install http://example.com/foo.thor. All of thor’s features, including bundling, work transparently with installed tasks. As far as thor is concerned, installed gems are available in addition to any local gems, everywhere.

The final bit of news is that SproutCore (which is used in Apple’s MobileMe and iWork.com), which is already built on Merb, will be adopting thor for its build tools. Charles Jolley (of SproutCore) recently submitted quite a few interesting patches yesterday to make thor ready for use with SproutCore, and I expect to announce a 1.0 release in the next few weeks. I plan to fix up global options, make it possible to install bundles from remote locations. Is there something you want in thor before the 1.0 release? Let me know!

Popularity: 1% |

Dispatch: A Day of Cleanup

By | January 10th, 2009 at 4:01PM

With most of the pieces of the puzzle in place, I took today to go back over the codebase and remove artifacts of the refactoring work I’ve been doing, and spent some time renaming variables and methods I’ve created so they more accurately reflect what they’re doing:

  • ActionView::Template had a render method on it in which almost every line was an instance_variable_get or send() into ActionView::Base. I (slowly, very very slowly) moved the method over into ActionView::Base.
  • Similarly, I moved the partial rendering code out of ActionView::RenderablePartial and onto ActionView::Base as well.
  • I reorganized ActionView, creating directories for “render” and “template”, and moving the appropriate files into the directories. This should significantly reduce the amount of visual clutter in the action_view base directory and make it easier to find the part of the code you’re looking for.
  • I was finally able to remove ActionView::Base#render_for_parts, which was the temporary shim I created when I started this round of refactoring to force all the callers into ActionView to call in with unified parameters. This was replaced with render_for_template yesterday (renamed to render_template_with_layout today), which means that the conduit between parts of ActionPack is now reduced to Template objects and layouts (also Template objects).
  • The reorganization I referenced above also moved common methods into common files. For instance, the ActionView methods related to top-level rendering are in render/rendering.rb, while the ones related to rendering partials are in render/partials.rb.

On another note, I’ve been playing with an interesting memoization technique that lets you declare the methods to be memoized in a block:

class Foo
  extend Memoizable

  memoize do
    def memoed(baz)
      baz * 1000
    end
  end

  def unmemoed(baz)
    baz * 1000
  end
end

After creating this class, Foo.new.memoed will be a memoized method, but creating the memoization will not use alias_method_chain. Instead, it uses normal Ruby structures, and super. You can see the full details in a gist I posted with the code. It definitely gets a bit into the deep end of metaprogramming magic, but the end result is memoized methods that will retain their names in stack traces (probably my biggest personal gripe with alias_method_chain).

Finally, I’m going to start putting together a quick prototype of how Rails3 can be JavaScript agnostic while retaining the existing JS helpers next week some time. I’ve already gotten a lot of good feedback from the jQuery and Mootools communities, and plan to get as much involvement as possible as I move forward. Feel free to ping me (wycats on freenode or gmail) if you have any specific suggestions or just want to chat about the project. More details to follow next week.

Popularity: 1% |

CodeMash Slides and Code

By | January 9th, 2009 at 4:01PM

Anyone interested in my CodeMash 2009 Erlang talk can pick up the slides and demo code files in tar and zip formats.

I’ve got lots more to talk about but haven’t had a lot of time to blog. More updates soon…

Popularity: 1% |

Email Alias for Former Engine Yard People

By | January 9th, 2009 at 4:01PM

Earlier this week, we let go 15% of our workforce, or 12 people, in account management, Linux sys admin, Ruby/Rails app support, DB admin, and general business admin. This represented a change across several parts of the business and was part of a plan that includes new products and services.

We really appreciate the efforts of everyone at Engine Yard and we’d like to help provide opportunities for people we’ve let go, so we’ve set up an email alias for former Engine Yard employees and contractors.

This alias is opt-in, meaning that it goes to former Engine Yard people who told our HR department that they want to be included.

If you’re interested in communicating with anyone in the group, just send an email to the following alias. Those who opted in will receive your email and reply if they’re interested.

alumni (at) engineyard (dot) com

Thanks!

— Lance

Popularity: 1% |