merb and sequel

Recently I needed to order some records by a mathematical formula, and I couldn't figure out a way to do it in DM (although it looks like the idea was well received and might make it into a future relase). I'd heard some great things about Sequel, so I decided to take a look and see what possibilities I had there.

If you haven't read anything about Sequel, head on over to its rubyforge page at http://sequel.rubyforge.org/documentation.html. There's a good amount of information from basics to how you can implement complex associations between models. There's even a link to Lori Holden's MerbCamp presentation.

Sequel piqued my interest in many ways: it uses the Active Record Pattern to create methods from column names, but you can also do a more DataMapper style definition of columns inside your model:



You can use Post.create_table! as a sort of automigrate (it will drop and recreate the table). The usage of set_schema is more for test code and experimenting, and I found it very useful when developing sequel_polymorphic and sequel_taggable.

So, while its easy enough to generate a new merb core app and customize it as you like, if you're going to be generating a lot of apps with the same configurations, its worth learning how to build a stack. Currently its mostly a manual process: you build a gem with a certain structure by hand, and then use your stack with merb-gen. Eventually this will probably be an easily streamlined process, but for now its still up to you to put things together. You can read more about the structure here and take a look at merb-sequel-stack as well.

If you're looking to get a bit closer to your DB and want a lot of flexibility and power, you should really take Sequel for a test drive. Its current maintainer, Jeremy Evans, has been a ton of help with answering dozens of questions in #sequel, even when its to answer something he doesn't agree with like polymorphic associations, which I'll go into next time.

a possible addition to www.builtbythenet.com

The same questions get answered many times a day in #merb and I have to think there's a better way, especially for dependency issues. Whether is a rubygems issue, one with Merb or any of the typical libraries people use it with, or just some random little bug you only see on windows, I haven't seen a good way to track and relate all of this information. Some goes on a wiki, some is remembered and routinely typed back by various people in #merb, some goes to the mailing list. It shouldn't have to be this way, and I'm hoping this idea will help:

dependency hell mitigator

The implementation would be dead simple, probably something like a tag cloud. It'd rely on people entering info and trying to keep things up to date...but hopefully this would result in a more organized and useful collection of all the various tricks we employ to get through those moments of keyboard tossing and mice bashing.

As usual anyone interested in coding this up is more than welcome to--the source is at jackdempsey/builtbythenet If enough people like this idea then I'll probably start in on it myself at some point and see where it goes.

I launched a site today

It takes a number and divides it by 86,400. The next iteration will include functionality to take a number and multiply by 86,400. Amazing right?

The site has no design. I don't have a business plan. I don't have sales, marketing, QA, or anyone else. And I couldn't care less.

I realized today that I agree with "release early, release often", that I try to live by those words when I can, but as a developer you only have so much control over what your boss thinks, plans, schedules, and so on. At night you're perfectly free to release any sort of crap you want, when you want to, and similar to my recent post on testing, I've realized I need to just get over my desire to perfect things and refactor ad infinitum, and just ship something.

So the site is simple. It basically does nothing right now but convert the number of requests per day into what it'd be in requests per second. This came out of a discussion with Topfunky who was wondering what 8 million requests a day would be in RPS. It was a perfect example feature to spawn the launch of www.builtbythenet.com

The idea is simple--GitHub brings you "Social Code Hosting" right? Well, think of this as Social Site Building. Users can submit feature requests at http://builtbythenet.uservoice.com/, vote for other's ideas, and take part in building a site like never before, because not only do the users drive development, the code is completely open: http://github.com/jackdempsey/builtbythenet/tree/master

People often say "I'd love to learn Merb, but am tired of building blogs. What should I build?" Well, now you have something else to try out. I imagine, at least I hope, that over time some great ideas will come out of the ether. The possibilities are endless. The 'goal' in my mind is less about what the end result is, and more about the process and the features along the way. I don't think this will ever be finished. Maybe in a few weeks it'll fall flat on its face and oh no, I'm out a $9.95 domain name. But at least I'll have tried...and if all that comes of this is another example of some Merb code, that's good enough for me.

rspec macro methods in Merb

While working on spec'ing out this merb-service-example app I came to a point where I had a lot of repetitive code, enough that I really wanted to DRY it up a bit. Long story short, after talking with David Chelimsky for a bit, I ended up with this: gists_spec.rb

I think the it_should_respond_with and it_should_return methods work well for adding clarity, reducing repetition, and making the specs even stronger. Still, I'm a bit unhappy with the method names. Some other possibilities thrown out there are:



Nothing feels perfect yet...and maybe it doesn't need to be...but, that's never stopped me from trying. What name(s) do you like? Any better suggestions?

Thor finds Mjolnir

If you've been following the development of Thor, you'll know there's been a bug that affected commands with several layers of namespacing. Tonight I'm happy to announce this bug was finally crushed by Yehuda Katz.

Just to briefly describe the pain this has brought me, a few facts:

* Class.constants only gets the top level constants. If you have Foo::Bar::Baz, don't expect to see Baz in Foo.constants

* Struct is mean:



(You can imagine how the first point led me to the second, right? Yeah...fun.

* Remember, when you ask for constants on a class, it:

Returns an array of the names of the constants accessible in mod. This includes the names of constants in any included modules (example at start of section).

It _also_ returns constants defined in any class you inherit from.

So, lets just say this all added up to a nice bit of hacking for me, and truthfully it was a good experience. It started to get old after a while, but I think this is something people don't talk about enough. Its the same with lifting weights: you purposely destroy and rip apart your muscles so they can build up bigger and stronger next time.

If you don't at least semi-often tackle hard problems, frustrating situations, and just fight through those moments when you think "screw it, PHP isn't that bad", you'll never get the kind of experience that really makes you grow as a Rubyist, and really, a programmer. You'll often find at the end not only did you learn some new tricks, but sometimes the solution is right there before your eyes....or Yehuda's eyes...but still, you'll get a lot out of it.

So anyway, I'm happy to point people to http://github.com/wycats/thor/tree/master and say 'Enjoy!' The soon to come Merb bundling tasks will be taking advantage of Thor's power, so if you haven't done anything with Thor yet, now's a great time to jump on board.

A script to help with Rails -> Merb conversions

People have asked often in #merb for something to help with converting Rails apps to Merb apps. There's no magic Wizard to do this for you, but hopefully this will help:

http://github.com/jackdempsey/find_rails/tree/master

Its a standalone Thor script that looks in your current directory (or a provided path to an app), finds the app/ directory, and scans through the code for a variety of things that people get tripped up on in Merb. I imagine this list will increase over time, but it will help with some of the obvious ones to start.

This is very much a work in progress. Running it standalone like this, especially given the way I've organized it, loses some of the flexibility Thor provides. It also makes it easier on the user to invoke. I imagine if this is used by people and grows to be anything bigger than a simple helper script, I'll refactor the way the task is started, so I'd recommend cloning this and playing with the source a bit as well.

Anyway, if you haven't played with Thor yet, you should give it a go. Its fast, flexible, and a great way to avoid the "fun" of parsing options yourself.

Currently there's a bit of an issue with installing tasks that have multilevel namespaces. For the time being, I've committed a fix to the constants branch of my fork at http://github.com/jackdempsey/thor/tree/constants

I foresee this fix getting cleaned up and merged into the main Thor repo soon. In the meantime, if you're looking at using Thor with tasks like foo:bar:baz, this fork will fix things up for you.

Update

I fixed things up a bit so that we can search on regex's as well. This came out of a discussion in #merb re: the tendency to "redirect && return" in Rails, which is the reverse of what you'll want to do in Merb.

http://github.com/jackdempsey/find_rails/commit/ea80df077c8cee0959ce1e7b4b17321924f19dc7

logging to a file in production merb

This comes up often in #merb. You can use several flags to customize things nicely:

merb -e production -l debug -d

This sets merb to run in the production environment, to use a log level of debug (use merb --help to see the others), and -d to daemonize and not log things to the console window.

introducing merb-thor

About a year ago I was working with an ActiveRecord model, and for some reason things would blow up when I tried to do anything to this model inside rake. Turns out having a field called 'link' was a very bad idea, given the rake code bel

1 2 3 4 5 6 7 8 9 10

# ########################################################################### # Include the FileUtils file manipulation functions in the top level module, # but mark them private so that they don't unintentionally define methods on # other objects. include RakeFileUtils private(*FileUtils.instance_methods(false)) private(*RakeFileUtils.instance_methods(false)) ##################################################################

The problem is our friend "send" and the fact that it could care less about the call to private. This cost me the better part of a night, and I guess I've never really forgiven rake for it...

Enter thor. If you haven't heard of this, take a look here and see what you think. The code is practically 100% covered by specs, and is easy to dive into...and something just feels better about defining plain old ruby methods instead of tasks.

So, in the interest of learning thor better, I took the merb sake tasks and converted them to their thor equivalents. The end result is found at http://github.com/jackdempsey/merb-thor/tree/master and once you have thor installed you should install the file with

1	$ thor install http://github.com/jackdempsey/merb-thor/tree/master%2Fmerb.thor?raw=true --as=merb

The --as option lets you name things nicely so in the future you can do

$ thor update merb

to get any new stuff thats added in.

I'm happy to take comments, updates, patches, etc. Enjoy!

Update
There appears to be a small bug with namespacing of commands. For the time being, all of the commands should work if you run them inside a directory where merb.thor exists. I hope to have this fixed over the next few days, but til then, this should be a quick solution.

Update Part Deux
I've created a fork of thor in a branch you can find at: http://github.com/jackdempsey/thor/tree/constants

If you install from here thor will load all .thor files it finds in your root whether they're relevant or not. This will get around the constants issue preventing things like 'thor merb:gems:refresh' from working.

Update Part Finale
So merb-thor has grown up and become part of the merb stack. I've updated the repo to point to the new goodness, but if you're reading this you can go there directly:

http://merbunity.com/tutorials/18

Much thanks to those who've shown interest in it, sent me patches, etc, I appreciate it. I'll be working on new and exciting stuff with Thor in the future, and if you have thoughts/ideas on things like http://github.com/jackdempsey/self-deprecated let me know!

merb-auth, webrat, and merb_stories

Recently I've been working on getting some stories written for www.recollectr.com and given that I just added in MerbAuth support, I thought now would be a good time to dive back into the previously paused process.

If you're interested in using webrat for merb_stories, you'll want to get the fork that supports merb from here:

http://github.com/gwynm/webrat/tree/master


I'd previously had some stories working with webrat and edge merb, but it looked like the upgrade to using MerbAuth in slice form broke some things. After some investigation I realized that the namespacing that's used in merb-slices was slightly different than what the merb supported fork of webrat was happy with...gwynm's fork adds a cookies= method to Application as follows:

class Application < Merb::Controller
  def cookies=(newcookies)
    @_cookies = newcookies
  end
end

This is fine except with MerbAuth, we have MerbAuth::Application, and as such things were busted a bit. So, doing the same for MerbAuth::Application fixed things right up:

module MerbAuth
  class Application < Merb::Controller
    def cookies=(newcookies)
      @_cookies = newcookies
    end
  end
end

Thing is, this doesn't exactly belong in MerbAuth as its specific to webrat....and it doesn't exactly belong in webrat as its going to be an issue to any merb-slice. So for the time being I have this in my app code, and things work nicely. I'll probably write a little more and maybe give some examples for general webrat and merb_stories usage, but til then hope this helps anyone else trying all three of these great components.

undefined method 'each' for nil

A common error that trips up Rails converts is the fact that you need to manually call 'render' inside your controller actions. If you don't, you'll see something like this:

/usr/local/lib/ruby/gems/1.8/gems/merb-core-0.9.4/lib/merb-core/rack/handler/mongrel.rb:85:in `process': undefined method `each' for nil:NilClass (NoMethodError)

You'll see the code around line 85 is:

         if Proc === body
              body.call(response)
         else  
              body.each { |part|
                response.body << part
              }
         end

As you can see, if nothing is returned from your action, body will be nil, and the each call will fail with the above message.

There's a plugin in the works to help catch some of these issues. In the meantime, I hope this helps!

assets not displaying

A change was made recently to how Merb handles assets, and the result is that users with apps that predate this change will not have their assets displayed. The quickest fix is to delete the config/rack.rb file in your app and let the Merb defaults handle things.

issues with dependency

Some people have reported issues with using dependency to load gems into their environment. The issues are hard to track as it works for some and fails for others. If you do find yourself with gems not loading from a dependency call, you can always use require.

This issue is known and effort will be made to have it resolved by Merb 1.0. Til then, require when needed.