Downtown Cartel, in partnership with Always Creative and Matt Fruge, will be launching DesiredHearts.com in the near future. Part of the unique value Desired Hearts is bringing to the online t-shirt business model is the idea of building a donation to charity into the price of the product. With every shirt purchased, a portion of the revenues will go towards a charity of the t-shirt designers choosing.

I have not seen this done in many cases online, but I do feel that it’s a socially responsible thing to do. If more businesses followed this model, where your dollars go directly to charities for things that affect us all, such as the American Cancer Society or Oxfam International, even a fractional percent of sales would add up really fast considering the $14 trillion economy we have in the US alone. The question, and risk of this model, is would you choose to shop at places where you knew that a fixed amount (5-10%) would be going to a charity - or would you shop around to save a few bucks?

An added value that can emerge from this model is the free marketing your products receive if you work in conjunction with the charities you are raising money for. For instance, if you donate $600/mo from your sales to a charity with a large distribution network, like Oxfam International or similar, there is a distinct possibility of having your products marketed throughout their extensive distribution network on a continual basis because of the benefit they receive from your increased sales.

Share your thoughts in the comments section below.

On Saturday, a few of us from The Creative Space made it down to Houston for their 2008 BarCamp. I had not been down to Houston for any community/tech events lately and it was really nice to finally get a chance to see folks I hadn’t seen in a while. I would list them all but I’ll save you the time having to read 50 or so names.

Ben gave a presentation on Merb - The Pocket Rocket Web Framework, which was a modified version of the talk he and Brian gave at Austin on Rails recently. Several in his audience had either used or at least heard of Merb, which is always a suprising thing to us considering the newness of the framework. Ben’s talk generated great discussion afterwards.

Roby, of Always Creative fame, followed up with a presentation on Building Better Brands (slideshare). He did an outstanding job and piqued the interest of several in the audience when he took folks through the process for three jobs they had recently done.

Overall, the BarCamp was fun and the community was definitely out in force.

Last tuesday (it’s been a busy week) Ben and I gave a presentation on Merb to the Austin on Rails group.  I was kind of surprised that everyone had heard of Merb and most have played with it.  Overall I think it went pretty well. We gave a quick overview on the layout of Merb, then focused on what Merb “does right”: the cool features that don’t exist in any other Ruby web frameworks, and the clever implementation that make Merb really shine.  There were a few things we missed or could have explained better, so hopefully this will clear things up a bit more.

merb-action-args

merb-action-args is a gem that allows actions to add parameters to thier method signature, which are filled in with request parameters when the action is called.  This is accomplished by some clever use of the ParseTree gem.  When a controller is first loaded, merb-action-args uses ParseTree to extract the arity of each action, which is stored in the controller.  The _call_action method, who dispatches requests to actions, has been rewritten in merb-action-args.  Instead of a simple send to the action name, the actions argument list is constructed by matching the parameter names in the arity list to the parameter names in the request’s params hash.  Finally, send is called on the action name with the newly built argument list.  merb-action-args is an optional gem in merb-more.  It is not part of merb-core because it is dependent on the ParseTree gem.

run_later

The run_later method is a recent addition to merb-core.  It’s usefull for delaying the execution of code until after the response has been served.  For example, if you need to send a confirmation email, but you don’t want the response to wait for the smtp chatter, you can wrap the email code in a run_later block.  The run_later block is pushed onto a worker queue which is always executed after the request has finished.  Because the block is essentially a proc, it keeps the same context it was called in, allowing you to access controller variables if called from within a controller.  So run_later can used instead of BackgrounDRb in some circumstances.  However, if you have very long running or CPU intensive work, it’s probably best to stick with a BackgrounDRb type solution, because the mongrel instance is consumed durring the run_later work just like during a request. It will not prioritize new requests over run_later work.

thanks

Thanks again to Damon Clinkscales and the rest of the folks over at Austin on Rails.  We had an absolute blast. Though being the first time we presented, we seemed to have a good back and forth. Hopefully they’ll have us back soon to talk more about DataMapper.