this.blog

Great Reception for Merbunity

2008-05-12T07:33:00.000-07:00

Wow. I'm feeling really grateful for the response to merbunity going live yesterday. A bunch of people have signed up, and hopefully busy writing tutorials to show off their merb skills.

It really is humbling to get such a reception for merbunity.com, and it gives me great hope that the site is really going to be great. Now, lets get some great tutorials and such out into the merbunity ;) Heh... that's a lot of great!

Merbunity Is Live

2008-05-11T10:11:00.000-07:00

Lets face it. Merb, for all it's goodies lacks good documentation at the moment. It' lacks a nice easy path to help beginners get into it.

I've been working on a site for a while to address this, and even though it's not finished, Merb's need for documentation is just too great.

Merbunity is a Merb commUnity site for all things Merb. Currently active are News, Tutorials, and Screencasts.

This is really a community site. It relies on the community writing the tutorials, screencasts, making the news announcements. There is other stuff on the cards, but for now I thought I'd get this out.

To try and keep the site of a high standard, it implements a peer review system. When you sign up, you can write all the tutorials and screencasts you like. When you decide that they're good enough, you can publish them, But... at that point they're not really published. They're 'Pending'. They need someone who is a "Publisher" to authorize them.

So the basic flow is, you write a tutorial or screencast, publish it, it becomes pending. At that point, you can have discussions with publishers about any tweaks that may be necessary. Once they're happy with it, they publish it for real, and it's live on the site. Don't worry though. You don't have to worry about that for ever... That would suck. Once you've published 3 "things" you become a publisher yourself, and you can publish others work, as well as your own.

When your a publisher you can also put up news on the site.

Tutorials and screencasts can be about anything you like, provided they are relevant to the Merb community. They could be about Merb, ORMS's upcoming tech, specs, whatever.

It really is up to us to make Merb great, and I think this will be a good place we can focus on.

Work is ongoing on the site to make it better all the time. Kudo's to Luke Sutton for a great site design. If there's any glitches in it, I'm sure it's my fault since I just *had* to play with it ;)

To get you started, I've posted a detailed tutorial of how to submit tutorials and screencasts.

Well, I'll step out of the way now. I hope we can use this to help people make the most of the awesomeness that is Merb :)

Looking for Powered by Merb Button Creator

2008-04-18T19:33:00.001-07:00

A while ago a very kind soul created a "Powered by Merb" button for my site Postb.ag. For the life of me I can't remember who it was though. If you see this. Please get a hold of me :)

I've Moved!

2008-04-06T17:46:00.001-07:00

Well it sure has been a long time coming. I've finally moved jobs to Engine Yard :) It took me a while to finish up at my old job, but it's finally over.

I'm moving into Engine Yard as an Application Support Engineer and I've gotta say I'm super excited about working with such a great bunch of people. That and working with Ruby full time :)

Great To See This Kind of Appreciation

2008-03-31T20:28:00.000-07:00

I'm a bit of a fan of DataMapper, and today even more so.

The site design for datamapper.org was very kindly donated by Luke Sutton aka unagi-san. He did the design as a way to contribute to datamapper, and it sure does make it nice. Not only did he do the original design for it, he continues to work on it, donating his time and talent to a great project.

Well. Today Sam Smoot, the father of DataMapper has setup a pledgie as a way to recognize the hard work, and say thanx. I think it's an awesome way for the community to help out a designer that's helped out the community. If you can spare a few dollars and like the project why not get in on it.

Introducing Whistler

2008-03-26T04:39:00.000-07:00

With all the posts about merbful_athentication lately, you'd think that was all I was working on. It's not quite the case. A lot of it isn't looking like going OS, but I've been able extract something from one of my project.

Whistler is a markup white list filter. It's based on the specs of Rick Olson's WhiteList rails plugin and runs on hpricot.

Usage is super simple. You can either include it into your model, or use it directly.

Whistler.white_list(markup_string)

That's it. There are ways of using different tags and attributes on each call. Check out the source at http://github.com/hassox/whistler

Merbful Authentication 0.9.2

2008-03-26T04:35:00.000-07:00

I've just put up a bugfix for merbful_authentication because there was a method name clash in merb-gen. This is really a very small fix. It also includes a couple of other minor fixes.

You can get the latest from rubyforge.

Merbful Authentication 0.9.1

2008-03-05T04:40:00.000-08:00

After a buggy start, and no Test::Unit support, the new MerbfulAuthentication is here.

This release is a little experimental at the moment. I mean, it's more robust in the way it handles the dependencies, but there is one area I'd really like some feedback.

To minimise the setup and configuration required, I've taken some liberty with this release. There was an issue where with the way I had the routes in 0.9.0, when the router was reloaded because of a change, the AuthenticatedSystem routes were wiped out. Also there was requires and dependencies still fairly well littered throughout the code.

To accomplish this, I've taken the liberty of writing some configuration information into the config/init.rb and config/routes.rb files. This will add the lines when you generate, if they are not already there. It won't be destructive, and you can just remove them if you want.

I'd really like some feedback to see if ppl don't like this. I can't see it causing trouble. But that doesn't mean ppl will like it ;)

So have a crack and let me know what you think :)

Merbful Authentication Initial Merb 0.9 Support

2008-02-27T03:24:00.001-08:00

It's ready for a first off flogging. A huge thanx to Shay Arnett of merborials.com fame for all the great help in getting it going, along with plenty of others how have given support and hacks to get the plugin going. Merbful Authentication, the authentication generators based on RickOlsons cool restful_authentictaion plugin is ready for a first cracking. Please bear in mind that Merb 0.9 is still in it's infancy and so is this gem. It needs to be flogged so it can be solid. Having said that, it seems to be solid, but... well, you know...

There are not too many changes from before, mostly spec updates, and internal updates that only really affect the generators to use merb-gen.

Unfortunately test unit support is... well the test unit tests aren't working atm. RSpec ones work, and all the specs should function correctly. The specs are fairly complete tho so I have at least some confidence that the plugin is working :)

Git it

The repo has now been fully moved over to git. I'm not planning on updating the SVN repo. Of course if there are people that really want to use the SVN repo, I'll push it over there.

To get merbful_authentication just

sudo gem install merbful_authentication

or get it from my git repo.

git clone git://github.com/hassox/restful-authentication.git
cd restful-authentication
git checkout -b merbful_authentication origin/merbful_authentication
rake install

How to use it

merb-gen authenticated user_model session_controller [--include-activation]

The only required argument is the user model. The sessions controller will default to Sessions. If you use the --include-activation mailers and required code will also be included.

What's different?

Well, besides the internals of the gem being simplified, there has been some changes to the generated files themselves.

There isn't the mess of dependency and require statements anymore. There is a require on 1 file lib/authenticated_system/authenticated_system_dependencies.rb All the dependencies are listed in here.

The required routes are now in the lib/authenticated_system/authenticated_system_routes.rb file. They are automatically prepended to you routes once the app has started. So now you can just start using them :)

That's really it. The other changes are in the structure of the gem itself, and just a couple of small tweaks to get the syntax right for 0.9.

I hope this release will be relatively bug free, but if you do have any issues, catch me in #merb, or shoot me an email has.sox [at] gmail DOT c o m

Merb Supports rSpec Text Stories

2008-01-27T18:45:00.000-08:00

Today I managed to release a new plugin for merb that provides basic support for rSpecs text stories. It's a bit experimental at the moment so if you want to pitch in and get it going smooth, come on down ;)

I have been hanging onto it for a little while, but I keep trying to get into the release early and often philosophy.

Get It

Like all merb plugins, this one is a gem. You can get it from gem

sudo gem install merb_stories

You can get it from source

svn checkout svn://rubyforge.org/var/svn/merb-plugins/merb_stories
cd merb_stories
rake install

Usage

At it's heart merb_stories is almost just a generator, but you do need to add it as a dependency to get going with it. You can safely remove it when you deploy, but for now it needs to be there to run the stories.

Generate A Story

In your Merb.root

ruby script/generate story my_story

This will generate all the support files, if they're missing, and also the story, story steps etc.

If you want to organise your stories a bit more, you can put them into sub-directories.

ruby script/generate story story_group/story

You can go as deep as you like with the directories.

Running Your Stories

It's really simple to run your stories. merb_stories supplies a rake task to remove any pain you might have.

rake story[my_story]

or if you used subdirectories

rake story[story_group/my_story]

You can also just run all of them at once.

rake story[all]

Thats really about all there is to it. To check out what to use stories for checkout the rSpec site.

Cool Stuff with the Merb Router

2008-01-18T06:19:00.001-08:00

Today I found out something I didn't know about the merb router when looking for routing to subdomains.

I've got a route that looks like this:

  r.match(:first_subdomain => ":account_name") do |k|
    k.match("/:controller/:action") #any old route match really
  end

That will put the value of the first subdomain into params[:account_name]. Hang on though... That doesn't work by default.

How Is It So!!!?!!?

Well it turns out that when you pass a hash to r.match it uses the hash keys as method calls to the request object. It then compares the values returned to the ones you specify.

So you can have heaps of mini matchers in you matcher and all you have to do is specify a method on the request object and then use that method name as a hash key in the match. This is probably a bit dangerous so be careful with it. In this example this does the job at the top of the route file

module Merb
  class Request
    def first_subdomain
      subdomains.first
    end
  end
end

Merbful Authentication Update

2008-01-18T04:37:00.000-08:00

There have been a couple of little teething problems with the merbful_authentication gem, mostly because it's not automatically available to your app when you run the generators. There's all that you had to do to get going which really bugged me.

The Skinny

To setup your newly generated Authenticated user, now all you need to do is setup the routes. (and the mailer if your using activation). All the including and dependency is taken care of for you. This is current as of 0.1.2. If you care about why and how... read on.

Why and How

The main issues were with the controllers not having the mixin by default. Then when you try and include it you have to make it a dependency. Not very nice... I also kept getting tripped up on the merb_helpers dependency too.

Well you'll be pleased to know that now, when you generate an authenticated user and you app loads, all the authenticated system is mixed into Application. The controller that your controllers should all inherit from. So it's now available to all your controller automatically :)

Also merb_helpers has been made a dependency where it's needed, and also a dependency on the gem so you don't have to worry about it. Ahhh... gem plugins are so nice like that.

It's up on rubyforge so sudo gem install merbful_authentication should do the job.

If you want source with that see my other post for instructions on where to get it.

Happy Hacking!

Dynaically Setup Rake Tasks

2008-01-11T07:57:00.000-08:00

This is probably really old news. I just setup my first rake task tonight though so I thought I'd put it up here. This is more for myself really so if it's not your cup of tea turn away now.

I've been playing with rSpec's text stories in Merb but I couldn't find a way to make a rake task that would take an argument for a particular story to run. e.g.

rake story:run my_story

So I've done the next best thing. I scan my directory for story files and create the rake tasks dynamically. Now I can use:

rake story:run:my_story

As well as

rake story:run:all

The code to make this dream a reality is

# Allows all found stories to be run individually by using
# rake story:run:story_name
namespace :story do
  namespace :run do
    all_stories = []
    Dir.glob('stories/stories/**/*.rb').each do |path|
      story = path.split("/").last[0..-4]
      desc "Run spec story #{story}"
      task "#{story}".to_sym do
        sh %{ruby stories/stories/#{story}.rb}
      end
      all_stories << story
    end
    
    desc 'Run all stories'
    task :all do
      all_stories.each do |story|
        puts 
        sh %{ruby stories/stories/#{story}.rb}
      end
    end
  end
end

Merbful Authentication Update 0.1.1

2008-01-07T04:39:00.000-08:00

Well, it's been out in the wild for a couple of days now, and there is at least one glaring error in the merbful_authentication code. The generator is called "authentication" instead of "authenticated" not too good for a port. That's changed now. Also there is some changes to give nice error messages when no ORM is selected or sequel is selected.

If you want to get the update you can get it the same as before.

Merbful Authentication is Born

2008-01-04T06:35:00.000-08:00

Hooray... The initial release of merbful_authentication is cooked. It took a bit longer than I thought it would, mainly thanx to my unfamiliarity with test_unit. Well, that and I was away over the christmas holidays.

At the moment there is support for Datamapper and Activerecord ORM's. Hopefully Sequel will follow soon.

How to get it

The gem has been released on rubiforge, so the usual should do the trick

sudo gem install merbful_authentication

If you want source with that.

Git:

git clone git://activereload.net/restful_authentication.git merbful_authentication.git
git checkout -b local/merbful_authetication origin/merbful_authentication

Or SVN

svn co svn://rubyforge.org/var/svn/merbful-auth

From either of these you can package and install the gem

rake package
sudo gem install pkg/merbful_authentication-0.1.0.gem

Usage

It has the same usage as restful_authentication, without the stateful stuff. So (from README)

To use:

  ./script/generate authenticated user sessions \
  --include-activation

The first parameter specifies the model that gets created in signup
(typically a user or account model).  A model with migration is 
created (if migrations are available), as well as a basic controller with the create method.

The second parameter specifies the sessions controller name.  This is
the controller that handles the actual login/logout function on the 
site.

The third parameter (--include-activation) generates the code for a 
Mailer and the required support code.  Don't forget to setup your mailer for this.

Required Setup

Unfortunately there is some setup required. At the moment, some named routes are required. You can set these up in you config/router.rb

      r.resources :users
      r.match("/login").to(:controller => "Sessions", :action => "create").name(:login)
      r.match("/logout").to(:controller => "Sessions", :action => "destroy").name(:logout)
      r.match("/users/activate/:activation_code").to(:controller => "Users", :action => "activate").name(:user_activation)

That last one is only required if you include activation. Don't forget to setup your mailer configs if your using it too.

Also, you need to have merb_helpers installed. This is for the form generation stuff. In config/dependencies.rb

dependency "merb_helpers"

All crit, comments, bug reports, patches are welcome. Patches are more welcome of course ;)

Update: You will need to install merb and merb_helpers from trunk until the official 0.5 gem for merb comes out.

Generate Merb Plugins and Generators

2007-12-19T00:24:00.000-08:00

As part of my effort to port over restful_authentication I'm at the point where I want to start making a merb plugin gem out of it. This will of course include some generators for merb and datamapper. Later I'll add the Active Record generators. This is super simple thanx to Rubigen

Just today I went to start and found the merb plugin generator wasn't able to generate generators. Now just to move on from that fairly circular sentence, a quick call to DrNic and he had it sorted pretty quickly. The end result is, that as of today, you'll need to install merb from trunk to follow this. That or wait until merb 0.5.0 is released officially.

Generate a Merb Plugin

Merb comes with an option to build the skeleton of a plugin inside the merb command.

$ merb -P merbful_authentication
      create  
      create  lib/merbful_authentication
      create  spec
      create  Rakefile
      create  README
      create  LICENSE
      create  TODO
      create  spec/spec_helper.rb
      create  spec/merbful_authentication_spec.rb
      create  lib/merbful_authentication.rb
      create  lib/merbful_authentication/merbtasks.rb
  dependency  install_rubigen_scripts
      create    script
      create    script/generate
      create    script/destroy

As you can see it's very simple to generate a merb plugin. You could call rake gem in that directory and it will build the gem for you automatically.

From here it's just like any other gem. When you add new files, be sure to add them to the gemspec in the Rakefile.

For the specific case of merbful_authentication, I want to have a generator that is available for all merb projects, and also generators with the relevant code for datamapper, activerecord, and sequel. This is a pretty important way to help support merb's ORM agnosticness.

Merb makes use of rubigen scopes. All merb projects have the merb scope and in your app when you select which orm to use via use_orm the ORM scope is selected automatically. The available scopes in a merb application at the moment are

merb

merb_default - (used when no orm is selected)

datamapper

sequel

activerecord

rspec

test_unit

The merb scope is available in all merb projects, with the others available as selected. By default the rspec library is the testing scope that is available.

How to Use Scopes?

When you make your generators, you should apply a scope to them. What this does is allows your gem to behave itself according to the configuration the user has setup. The way I'll setup the generators structure in merbful_authentication will be:

merb_generators
- authentication_generator

datamapper_generators
- authentication_model_generator

activerecord_generators
- authentication_model_generator

rspec_generators
- authentication_testing_generator

test_unit_generators
- authentication_testing_generator

The final names that I end up with might be different, but this is the general structure I will use.

Why this is useful, is that the merb generators are always available, so we can always call the authentication generator in a merb app. This in turn will have a dependency on the authentication_model generator. This is where the magic happens. So if the app has:

Scope : datamapper
The authentication_model generator defined in datamapper_generators will be active and therefore used.

Scope : activerecord
The authentication_model generator defined in activerecord_generators will be active and used instead

This is the way merb generators support the different syntaxes of models and controllers when you use script/generate resource or similar. The testing frameworks will work the same way.

How to Generate a Generator with Scope

To generate your generator with the required scope, it is really simple. In the root directory of your generated plugin:

$ ruby script/generate component_generator authentication merb
      create  merb_generators/authentication/templates
      create  test
      create  merb_generators/authentication/authentication_generator.rb
      create  test/test_authentication_generator.rb
      create  test/test_generator_helper.rb
      create  merb_generators/authentication/USAGE

There are also a whole heap of instructions on what to do next that are put up on the screen.

This will generate the authentication generator in the merb scope. See the documentation for rubigen to see how to use your shiny new generator. It's pretty much the same that you'd do for rails.

So then to make the datamapper generator

ruby script/generate component_generator authentication_model datamapper

I don't want this to show in the list of available generators when you run ruby script/generate so I will delete the USAGE file to prevent it showing up in that list.

Inside the merbful_authentication.rb (your_plugin.rb) file is the place to put your hook script. Similar to the init.rb file in rails plugins.

A note about plugins in general for merb. To mixin behavior to views and controllers you would include into and extend:

Views:- Merb::ViewContext (class)

Controllers:-

All controllers - Merb::AbstractController

Just web controllers - Merb::Controller (or Application)

Just Part controllers - Merb::PartController

Just Mail controllers - Merb::MailController

Ok now get out there and make some cool plugins for Merb! :)

Using Git with SVN

2007-12-13T20:30:00.000-08:00

I've been setting up a git repository to help aid collaboration on the port of restful_authentication to merb as merbful_authentication.

This is such a good library and I use it in all my rails sites that need authentication. It just works and I like that. All credit to Rick Olson for such a great plugin. Hopefully we'll be able to to a good job porting it.

Initially I setup a git repo with this. I'm starting to do most of my work in git so this is a good opportunity to keep going learning it.

You can get the WIP on this plugin via

git clone http://snatcht.com/git/merbful_authentication.git
# OR
git clone git://snatcht.com/git/merbful_authentication.git

This is really just a blank Merb app that has the beginnings of a port in it. There were so many people working on a port of this plugin I figured we might as well work on it together.

To include everyone in the development I needed to have svn as well. Rubyforge have been generous in approving a project for me.

The issue was, how to bring the svn into my local git repo so that I can push changes up to svn. Heres how I did it.

git clone git://snatcht.com/git/merbful_authentication.git

cd merbful_authentication.git

mate .git/config

In this file I put the following

[svn-remote "rubyforge/trunk"]
  url = svn+ssh://username@rubyforge.org/var/svn/merbful-auth/trunk
  fetch = :refs/remotes/rubyforge/trunk

Then to get the SVN linked into my local git

git-svn fetch rubyforge/trunk

git branch -a
* master
  origin/HEAD
  origin/master
  rubyforge/trunk

You can see that rubyforge/trunk is now present in my git remote branches. Next create a branch from rubyforge/trunk

git checkout -b local-svn/trunk rubyforge/trunk

This will create a local branch that you can use in git like any other branch. Now once you've made changes to your app. Merge them into the local-svn/trunk then update your svn repo with a lazy

git-svn dcommit

from within the local-svn/trunk branch.

Raising Routeable Errors in Merb Router

2007-11-30T04:58:00.000-08:00

On the #merb channel today there was an interesting puzzle to solve with routes. Merb routes have some crazy power, and today took my first crack at trying to give it a bit of a flex.

There were two distinct pieces of the puzzle that needed to be addressed. First, requests sent to actions on the application and exceptions controllers. The application controller will feed back with an error that says

"The 'Application' controller has no public actions"

The exception controller can be routed to like any other action. Failing missing actions are handled like any other controller, and actions rendering a known template will render but without the error message.

This behavior was not good for me and I didn't want it to occur. You might want the flexibility of being able to directly call the exceptions controller. But for this I don't.

Second, the error should be short and not give out too much information when either you request application or exceptions controller actions, or non-existent routes.

When Merb catches an exception it gives you a small amount of information about what the problem was. For this the requirement was that just a non-descript message be displayed.

This route setup prevents both issues from occuring and just renders an error screen with a simple message.


class Merb::Router
  DEFAULT_NOT_FOUND_HASH = { :exception => Merb::ControllerExceptions::NotFound.new("URL Not Found"),
                             :controller => "exceptions",
                             :action => "not_found"}
end

puts "Compiling routes.."
Merb::Router.prepare do |r|
 
  r.match(%r{^\/(application|exceptions)}).defer_to do |request, params|
    params.merge!(Merb::Router::DEFAULT_NOT_FOUND_HASH)
  end

# All the other routes

  r.match(%r{.+}).defer_to do |request, params|
    params.merge!(Merb::Router::DEFAULT_NOT_FOUND_HASH)
  end 
end

The first part of this route will catch any routes requested for application or exceptions controllers and render the error NotFound with the message "URL Not Found". The second part just catches any routes you haven't defined and renders that same error.

This setup will not work with default_routes. If you use default routes in between these to matchers, the bottom matcher will most likely not get called, and if you put the default routes after the last matcher in the example, default_routes will never be called. Personally, I don't like the idea of over riding the default behavior for not found errors, so I wouldn't have the second matcher, but I don't mind restricting routing from application and exceptions. At least that way you can use default_routes if you wanted to.

The defer_to method on a route will wait until the route comes in to assess it. If it matches the regexp then control is yielded to the block with the request and params objects.

Merbs error handling in controllers means that you just raise an error and the error will be caught by the exceptions controller and rendered. If you directly raise an error in the defer_to block though, your app will crash. You need to set the :controller, :action, and :exception options manually in the params hash to get error handling.

It's interesting to note that if the result of your defer_to block is false, it will not be considered as a match and will move onto the next. This does not allow for multiple defer_to matches to influence the result of another defer_to. For example, without default_routes set:

    r.match(%r{.+}).defer_to do |request, params|
      params.merge!(:one => "one")
      puts params.inspect
      false
    end 
    
    r.match(%r{.+}).defer_to do |request, params|
      params.merge!(:two => "two")
      puts params.inspect
      false
    end

will produce

{"action"=>"index", "one"=>"one"}
{"two"=>"two", "action"=>"index"}

# Instead of

{"action"=>"index", "one"=>"one", "two"=>"two"}

I'm not sold yet on what any of this means in terms of usefulness. I think I'll include the route to prevent requests going to application or exceptions directly, but I'll leave the normal behavior in for the rest of them.

New Merb Benchmarks

2007-11-27T15:47:00.001-08:00

A while ago I started to do some really simple benchmarks on Merb and Rails. Yehuda Katz, aka wycats on IRC went and wrote two simple benchmark apps that live in Merbs SVN. To get these:

svn co http://svn.devjavu.com/merb/apps/benchmark 

svn co http://svn.devjavu.com/merb/apps/rails_benchmark

Both of these will use evented mongrel and swiftiply if they're installed.

To use these benchmark apps change into the root directory.

ruby script/benchmark

That command will run all the available benchmarks.

There are a number of options. Use the -h flag to help you find your way around. The options are there to help you setup the benchmark and also to select which benchmarks to run.

ruby script/benchmark -l

will list all the benchmarks available.

ruby script/benchmark -s erb,haml

will run the template and partials for erb templates and haml templates only.

Be careful though, these can take a while. Especially on Rails.

Organic Inefficiency

2007-11-27T15:05:00.000-08:00

Merb really floats my boat at the moment. But I do think of other stuff... Really.

During my day job as a Mechanical Engineer it's part of my role to design and implement manufacturing cells in our factory. This can be pretty cool. Trying to make the cell as efficient and lean as possible can be quite a task sometimes. I've found that the cells not only need to be designed around the latest available (or is that affordable?) technology, people must be considered in the work flow if it's going to be successful.

When you design the cell with people being people in mind, all goes reasonably well. You can even make the cell efficient in a stand alone kind of way. But is that the best that can be done? I don't think so.

When the factory was first put on the floor, hopefully whoever did it did their homework and made an efficient layout so that all the individual work cells could function together reasonably well. As time goes on, you gain new products and you loose older ones. Some cells close and some new ones go in, and some of the bigger machinery which is very expensive to move now has to be planned around when you put in new equipment. What you end up with is an organically changing factory layout.

Picture this organically changing factory going forward for a few projects. Potentially you could end up with an unsatisfactory performance of the factory as a whole but this is hard to pick since all the individual cells seem to be efficient.

A work cell itself can have a very efficient theoretical process flow. In reality, if you can't translate that onto the floor the way you want, inefficiencies will result. The fact that when you lay the cell down, you "must put it in this spot" because that's where there's some free space can impact dramatically. Material in and out, and even flow in nice lines may not be optimum because you need to fit into the current factory layout. This can potentially lead to increased WIP (work in progress), increased handling equipment and all sorts of other nasties that may or may not be easily quantifiable.

It's my opinion that this kind of thing should be avoided. There is at least one software product I know of that's designed to assist with this issue. Tools like this can be very useful both to correct failing factories and also to move forward. Using a tool like FactoryFlow, is time consuming up front, for larger factories though it's much more expensive if you have to move equipment two or three times than if you invest up front with the design and do it right just once.

This is a huge issue that I'm sure could be talked about and theorised about. But this is a blog post so I won't do that to you :P

I think these same kind of organic inefficiencies can affect software development. I've seen plenty of old bloat-ware type products that attest to this. Automated BDD could go a long way towards alleviating this issue since the behavior is spec'ed and ideally you can change the implementation under the covers removing this organic inefficiency. Does it though? Is this kind of inefficiency common in software projects for the web?

I'd love to hear feed back on this issue.

Native Sass Support for Merb

2007-11-18T02:06:00.000-08:00

Nathan Weizenbaum aka nex3, a contributer to the awesome haml template system has just put support for using Sass in merb into the stable branch of Haml.

Haml has been supported in merb for a long time, longer than I've been involved with merb for sure. Sass was lacking though... Until Now :)

Before you can use Sass in Merb, you'll probably need to get the latest Haml.

sudo gem install haml

To use Sass in your Merb App it works the same way as in Rails. Put your Sass templates into public/stylesheets/sass

public/stylesheets/sass/my_style_sheet.sass

and include the css in the head of your layout application.html.*

css_include_tag :my_style_sheet

The only thing left to do now is to declare the dependency. In

config/dependencies.rb

include the line

dependency "haml"

Your app will now happily use your Sass templates, updated when you change them in development, but compiled only once during production. Sweet :)

The Great Merb Speedup

2007-11-08T18:10:00.000-08:00

Well, Merb has been coming along in leaps and bounds, but unfortunately it's also slowed down a bit in it's rendering. With all the changes this method has become heavy and quite slow.

The merb team did some great work on this yesterday. Hopefully there'll be some more in the near future too. Here's some numbers for your delectation. Please take these with a grain of salt. I'm no expert on benchmarking. See below for a full setup of how I ran the tests.

This table is on pastie for your viewing pleasure

Rails: ab -n 5000 -c 5 http://127.0.0.1:3000/tester
Merb:  ab -n 5000 -c 5 http://127.0.0.1:4000/tester

Rails Version 8117
rake rails:freeze:edge
rake rails:update

Merb Version 

Invocation:
Rails: mongrel_rails start -e production
Merb:  merb -e production > a_log_file

=======================  RESULTS =========================
0 Partials

Merb 0.4.0:         Requests per second:    456.86 [#/sec] (mean)
Merb Edge 913:      Requests per second:    723.98 [#/sec] (mean)
Rails Edge 8117:    Requests per second:    375.47 [#/sec] (mean)

10 Partials
Merb 0.4.0:         Requests per second:    150.57 [#/sec] (mean)
Merb Edge 913:      Requests per second:    424.83 [#/sec] (mean)
Rails 1.2.5:        Requests per second:    214.91 [#/sec] (mean)
Rails Edge 8117:    Requests per second:    213.56 [#/sec] (mean)

100 Partials:
Merb 0.4.0          Requests per second:    22.42 [#/sec] (mean)
Merb Edge 913:      Requests per second:    100.83 [#/sec] (mean)
Rails 1.2.5:        Requests per second:    45.15 [#/sec] (mean)
Rails Edge 8117:    Requests per second:    44.23 [#/sec] (mean)

* Merb edge without view context caching on partials
* Experimental ONLY

0 Partials:         Requests per second:    727.22 [#/sec] (mean)
10 partials:        Requests per second:    573.50 [#/sec] (mean)
100 partials:       Requests per second:    229.13 [#/sec] (mean)

The setup - Rails

rails partial_speed_test
cd partial_speed_test
ruby script/generate controller tester

# setup AR to point to an emtpy db

# setup your controller See Below
# setup routes

mongrel_rails start -e production
# run the ab tests

The Setup - Merb

merb -g partial_speed_test_merb
cd partial_speed_test_merb
ruby script/generate controller tester
 
#setup your controller See Below
# Setup routes

merb -e production

Controller setup

# app/controllers/tester.rb
 
def index
  render
end

# app/views/tester/index.html.erb (RAILS)
Inside Index
<% 10.times do %>
<%= render :partial => "blah" %>
<% end %>

# app/views/tester/index.html.erb (MERB)
Inside Index
<% 10.times do %>
<%= partial :blah %>
<% end %>

# app/views/tester/_blah.html.erb
BLAH<br/>

Merb Tests

Procedure

Uninstall merb gem

Install merb gem

Start app

Start tests

Released 0.4.0 gem
svn co with revision 913 and rake install
change the partial method to use cached_view_context instead of clean_view_context(engine) in render.rb

Rails Tests

Generate an app using the 1.2.5 gem and start it up

Run ab tests

rake rails:freeze:edge (8117)

rake rails:update

Start app and run ab tests

The number of partials was changed by changing the number in index.html.erb

Phew.. That was a long post.

Just to reiterate, take this with a grain of salt. This was just a test for my curiosity and I encourage you to run these yourself if you are so inclined. Hopefully I've captured all of the setup.

Update: Again with these numbers take them with a grain of salt. These numbers are from the activity monitor on OS X

Rails 8117          MEM(MB)         CPU       
10 Partials         24.9            99.7
100 Partials        25.8            100.0

Merb 0.4.0          MEM(MB)         CPU
10 Partials         15.6            98.8
100 Partials        21.4            100.0

Merb 913
10 Partials         14.3            98.8
100 Partials        13.8            100.0

Merb Generators Now Read Your Mind

2007-11-06T05:50:00.000-08:00

Three days ago I blogged about the new generators in merb. Meh, that's so 3 days ago ;)

Update: If you've installed these gems from trunk since 0.3.7 and before the official release of 0.4.0 you should first uninstall the merb, merb_active_record, merb_data_mapper and merb_sequel gems before you install them again.

Update #2:use_orm :active_record and :data_mapper have been changed to :activerecord and :datamapper respectively.

ivey and wycats, regulars on #merb and all round good guys today rolled up their sleeves and removed the ugly contstant Merb::GENERATOR_SCOPE that you had to modify to get the generators working. They also came up with a way to implement default model and resource_controller generators in merb.

How to use it now?

Now when you setup your brand new merb app, you go into config/dependencies.rb as usual but instead of

dependency "merb_data_mapper"

you use

use_orm :data_mapper
# and 
use_test :rspec

This will setup the dependency and also sort out what generators your app will use. You've got a good selection of generators now.

migration - a migration file

model - a model in the correct format + migration + tests / specs

controller - a blank controller + tests / specs

resource_controller - a controller setup with basic CRUD actions + tests / specs

resource - model and resource_controller and all things associated with them

So the one you'd normall use is resource.

ruby script/generate resource my_resource attr:type attr:type

This will generate a model and resource controller complete with tests / specs and migrations in the syntax of your selected ORM.

You can also use all of these generators even if you don't use an ORM at all. In that case it will just give you plain vanilla ruby classes with attr_accessors

Neat. These generators are very new though and I'm sure the content of the generated files can be improved. If you find something that you think needs to be changed please raise a ticket preferably with a patch.

wycats blog has a great outline of the major new features of the imminent version 0.4.0 of merb. If your interested you should check it out.

The New Merb Generators

2007-11-03T04:27:00.000-07:00

Update: The general information in this article is still correct, but the syntax is now nicer. You can read about the new syntax here.

In preparation for the big 0.4 release of Merb, the generators have had a major overhaul. Merb is ORM agnostic and uses plugins to harness an ORM. There are currently plugins for ActiveRecord, Sequel, and DataMapper.

The ORM agnostic goal of Merb, is a great thing, developers can use what they're comfortable with, or what suits a particular task at hand. This does create it's own issues of how to support it in the framework.

There's been great work done on merb to make this reasonably painless on selecting which ORM to use. Once the gem for the plugin is installed, a quick trip to config/dependencies.rb, and uncomment the line for your plugin and your away. But with generators it's been a bit more difficult up to now.

You'd think that will the option of ORM, and Rspec vs Test::Unit things could get a bit murky. Up to now the generators have been named specifically for the ORM you want to use so you can get the right syntax and parent classes etc. The only controller generator was just a blank stub that you have to fill out each time. Well now there's a new way to manage your generation needs.

Rubigen is awsome

DrNic extracted the generators from rails and added some of his magic to them. The result is a very clever and flexible system for generating files for your app and Merb tries it's hardest to put all this goodness to work for you.

Ok Already. Example Time

After you've installed the gem for your ORM plugin you need to tell Merb to use it for generators.

# config/merb_init.rb

# Put your selection for generators in here.  I'll use DataMapper because I like it :)
Merb::GENERATOR_SCOPE = [:data_mapper, :merb, :rspec]

This will tell Merb to generate with Datamapper, and Rspec. This could have been :active_record and :test_unit if you want to go down that road. The order you put these in will matter in future (hopefully ;))

Generate A Model

ruby script/generate model my_model attr:type attr:type

This will generate the correct model, migration if required, and the correct test or spec stub. If you change the GENERATOR_SCOPE to use :active_record and generate another model, you'll see that the correct files are generated.
Note: This currently is not available when you're not using an ORM plugin. There are plans to allow this but at the moment it's not happening.

Generate Controllers

There are two ways to generate a controller.

merb_controller
resource_controller

The first, merb_controller just generates a blank controller stub, helper and tests or specs. This is available all the time, even when you're not using an ORM.

The other is available when you use an ORM plugin.

ruby script/generate resource_controller my_model

This generates a CRUD controller with the correct sytnax for your ORM selection you specified in merb_init.rb along with the helpers and test or spec stubs.

Currently there is no "resource" generator that takes care of a model and controller and all the associated files. This is on the drawing board and hopefully it won't take too long to get it sorted.

Change the ORM, mix and match your test_unit or rspec selections to see it in action. I wouldn't experiment by changing scopes in a real project though since Merb currently only supports using one ORM at a time.

Merb Crud Controller

2007-11-02T02:55:00.000-07:00

The other day I decided to try a complete CRUD controller using the new provides format and Active Record. It supports XML, Javascript, YAML formats where appropriate and HTML across all actions. The built in error handling in Merb also helps to clean things up.

Well. Here it is, for better or worse. I really like it though ;)

class Posts < Application
  provides :xml, :js, :yaml
  
  def index
    @posts = Post.find(:all)
    render @posts
  end
  
  def show
    @post = Post.find(params[:id])
    render @post
  end
  
  def new
    only_provides :html
    @post = Post.new(params[:post])
    render
  end
  
  def create
    @post = Post.new(params[:post])
    if @post.save
      redirect url(:post, @post)
    else
      render :action => :new
    end
  end
  
  def edit
    only_provides :html
    @post = Post.find(params[:id])
    render
  end
  
  def update
    @post = Post.find(params[:id])
    if @post.update_attributes(params[:post])
      redirect url(:post, @post)
    else
      raise BadRequest
    end
  end
  
  def destroy
    @post = Post.find(params[:id])
    if @post.destroy
      redirect url(:posts)
    else
      raise BadRequest
    end
  end
end