UPDATE: This is rails-incompatible... which sucks.
Ruby 1.8.6 leaks memory in some surprising places. Even gsub and split on the String class cause some bad headaches. If you're using Haml and 1.8.6 - you are probably in a bit of trouble.
Read more: http://blog.edhickey.com/2008/12/03/memory-leak-in-ruby-186-string-class/
However, simply overwriting the offending methods fixes this memory leak at least. With a weird caveat that you may not use $ variables (eg $1) in any blocks passed to gsub.
Re-read that last sentence... "boom".gsub(/b(.)/) {|m| $1.upcase} will NO LONGER work. Unfortunately... rails uses that syntax, making this blog post probably moot
-
class ::String
-
# This below fixes a bad memory leak in ruby 1.8.6
-
# http://blog.edhickey.com/2008/12/03/memory-leak-in-ruby-186-string-class/
-
alias :non_garbage_split :split
-
alias :non_garbage_gsub :gsub
-
alias :non_garbage_gsub! :gsub!
-
-
def split(char)
-
holder = char
-
non_garbage_split(holder)
-
end
-
-
def gsub(*args, &block)
-
if args.size == 1
-
non_garbage_gsub(args[0], &block)
-
else
-
non_garbage_gsub(args[0], args[1], &block)
-
end
-
end
-
-
def gsub!(*args, &block)
-
holder = args[0]
-
args[0] = holder
-
non_garbage_gsub!(*args, &block)
-
end
-
#end memory leak fixes
-
end
At Motionbox, we use a RFC 3339 time format in some data we return. Javascript doesn't natively handle this format with Date.parse. The only other blog post I've seen on the subject is this:
http://dansnetwork.com/2008/11/01/javascript-iso8601rfc3339-date-parser/
However, since that's a regular expression that's parsing on the string, it can sometimes be slower (but not toooo bad... 1000 iterations on the code from the blog post above took < 100 miliseconds in IE7 (~40 miliseconds in Firefox on a macbook pro).
I knew we could do better with splits. With my code below I got it operating 60% faster (so operations take 40% of the time from the code above).
-
Date.prototype.setRFC3339 = function(dString){
-
var utcOffset, offsetSplitChar;
-
var offsetMultiplier = 1;
-
var dateTime = dString.split("T");
-
var date = dateTime[0].split("-");
-
var time = dateTime[1].split(":");
-
var offsetField = time[time.length - 1];
-
var offsetString;
-
offsetFieldIdentifier = offsetField.charAt(offsetField.length - 1);
-
if (offsetFieldIdentifier == "Z") {
-
utcOffset = 0;
-
time[time.length - 1] = offsetField.substr(0, offsetField.length - 2);
-
} else {
-
if (offsetField[offsetField.length - 1].indexOf("+") != -1) {
-
offsetSplitChar = "+";
-
offsetMultiplier = 1;
-
} else {
-
offsetSplitChar = "-";
-
offsetMultiplier = -1;
-
}
-
offsetString = offsetField.split(offsetSplitChar);
-
time[time.length - 1] == offsetString[0];
-
offsetString = offsetString[1].split(":");
-
utcOffset = (offsetString[0] * 60) + offsetString[1];
-
utcOffset = utcOffset * 60 * 1000;
-
}
-
-
this.setTime(Date.UTC(date[0], date[1] - 1, date[2], time[0], time[1], time[2]) + (utcOffset * offsetMultiplier ));
-
return this;
-
};
http://programmers-blog.com/2009/06/08/ruby-1-8-6-in-ubuntu-9-04-64-minimal

Problems install Curb on Ubuntu?
http://axonflux.com/curb-install-problems-on-ubunt

Message Driven Beans in Jruby
It was hard to find a lot of documentation on how to create a Message Driven Bean (MDB) EJB (for deployment into glassfish). Basically - I want to create a ruby app that receives messages and then does stuff with them. After tons of looking around I was able to finally put together one using NetBeans.
http://github.com/tobowers/jruby-mdb/tree/master
I don't have time now to go into the details... I, hopefully, will soon. However, edit the TesterMessageHandlerBean.java to change what message queue it listens to. Add or edit files in the src/conf/ruby directory to add ruby files.
Hope that helps... later I'll go into more detail about setting up glassfish and using OpenMQ.
I hate java, but this is a pretty damn nice way to deploy your ruby apps. Hopefully, this'll be a good start into letting us have ruby apps listening to OpenMQ in glassfish, but using jRuby.
Mamoo released as open source
I just put the Motionbox Advanced Model Observer Observer (Mamoo) up on Github. It's a light-weight (13k), but fairly powerful framework for javascript built on top of Prototype and the Motionbox EventHandler.
It's fairly well documented and has a full suite of specs written in ScrewUnit.
Mamoo let's you stop thinking about the "glue code" you need on a client-side app - and start thinking like "when this happens, I want this to happen." - Event driven architecture in JS.
Checkout the readme for a romp through most of the features.
To whet your appetite, here's a really small, but useful app written with Mamoo.
-
Message = MBX.JsModel.create("Message");
-
-
MBX.MessageView = MBX.JsView.create({
-
model: Message,
-
-
onInstanceCreate: function (message) {
-
var li = this.buildLi(message);
-
$("message_list").insert(li);
-
},
-
-
buildLi: function (message) {
-
var li = new Element("li", { id: message.primaryKey() });
-
li.update(message.get('body'));
-
li.updatesOn(message, "body");
-
return li;
-
}
-
});
-
-
// This will add the ui element
-
var message = Message.create({ body: "this is my body!" });
-
-
// and if you change body, the ui will automatically update as well
-
message.set('body', "some other body");
Assuming you have an ol with the id of "message_list" in your html page, now everytime you create a message, it'll get populated into the DOM.
I also put together a 15minute screencast that gives you a quick demo of a bunch of the features of Mamoo.
Nifty?
Bringing Holistic Awareness to Your Design - Boxes and Arrows
We did not find any correlation with user satisfaction and those teams with the most specialized team members, one way or the other: some teams with the most specialization did well, and some teams did poorly. What we did consistently observe among teams that had high user satisfaction scores, was one characteristic that stood out above all the others—what we began to call shared, holistic understanding. Those teams that achieved the highest degree of shared, holistic understanding consistently designed the best web applications. The more each team member understood the business goals, the user needs, and the capabilities and limitations of the IT environment—a holistic view—the more successful the project. In contrast, the more each team member was “siloed†into knowing just their piece of the whole, the less successful the project.
Yes, yes yes. I now work for a company that believes in top-down and bottom-up understanding. I didn't always. I've always said that even the full-time janitor needs to understand the business goals in order to most-effectively do their job.

http://blog.phusion.nl/2009/03/01/phusion-passenger-211-beta-released-thanks-sponsors/
- Support for Rails 2.3
- Improved compatibility with other Apache modules, such as mod_rewrite
- Ruby 1.9 support
- Support for NFS setups
- Various I/O handling and scaling improvements and fixes
- Improved mod_xsendfile support.
- Ability to disable Phusion Passenger for arbitrary URLs (PassengerEnabled option)
- Improved application compatibility
- Better cross-platform support (including OS X)
- Non-interactive installer
- Improved command-line admin tools
- Ability to display backtraces for all threads
- Improved security
- More customization options for exotic systems/setups
- Various usability improvements
- Various other minor improvements and bug fixes
This thing is really starting to look like a great and simple way to deploy *real* apps.
Free git training course
h/t to Ruby Flow:
Rubylearning.com is offering a free git and github training course. I don't have any personal experience with RubyLearning, but I hear good things and it might be a good introductory course for anyone that is just getting used to git.
http://rubylearning.com/blog/2009/02/10/git-and-github-a-free-course/
Hiivelogic: My Video and Slides from Acts as Conference 2009
Slides have a great quote from Steve Jobs and the talk is really great.
Saying no to features is really difficult, but hugely important. It's nice to see Dan Benjamin pushing developers to push back on requirements. It's hard sometimes, but the end-product is really worth it.
I think the part that he doesn't dig into deeply enough is true understanding of the market your product is going to end up in. Too many developers get caught up in the code and the computer aspect of their product. It takes a lot of work to try to understand the user and the market surrounding the user.
A lot of times understanding the product is harder than writing code, but it's something that everyone in your team really needs to spend a lot of time educating themselves on in order to create a successful product.
