Pivotal Labs is teaming up with Outside.In in New York City to co-host the monthly Ruby Happy Hour, on the first Wednesday of every month, starting Sep 3.
There will be pizza, beer and wii-based entertainment for everyone. Apparently these happy hours are getting quite popular, so please RSVP either in the comments here, or on Outside.In’s blog.
Where: Outside.in, 20 Jay St Suite 1019 (10th Fl), Brooklyn, NY
When: 7-9PM, Wednesday September 3rd
Who: If you’re a developer who uses Ruby and would like to meet some other Ruby folks, toss around ideas, or just have a few beers, we welcome you with open arms!
Outside.in (www.outside.in) is the web’s leading platform for neighborhood news and conversation. Outside.in’s technology dynamically maps web content to offline locations, which enables hyperlocal news discovery and sharing for consumers. The company also recently released GeoToolkit (www.outside.in/toolkit), which provides powerful tools for content creators of all sizes to optimize, promote and monetize their local content. Outside.in is supported by leading investors including Union Square Ventures, Milestone Venture Partners, Betaworks and the New York City Investment Fund. For more information, visit www.outside.in or the companyís blog at http://blog.outside.in.
As some of you may have heard, Rails 2.2 is going to be thread safe. This was pretty exciting for us as we’ve been struggling lately with memory issues running Mongrel clusters in virtualized environments, where memory is scarce and those Mongrel processes are pretty big.
While some have pointed out limitations of MRI due to green threads and certain commonly used libraries, and others are super-excited about what this means for JRuby, we were very curious about how Mongrel would perform serving Rails requests concurrently on MRI, which is very close to our/the standard Rails deployment.
As it turned out, Mongrel was pretty easy to work with, and initial tests suggest we were able to see a huge drop in memory usage while getting comparable performance to a Mongrel cluster. I haven’t included numbers as this was really more of a proof-of-concept spike and others will no doubt run with that, but we’re happy enough that we’ll be moving an app or two to edge shortly to see how well they perform.
A patch for Mongrel is pending feedback from the Mongrel team, but for now if you’re curious you can grab the source and run your own threaded Mongrel (on edge Rails) like so:
mongrel_rails -N X -n Y
where X is the number of concurrent requests Rails should process (active Rails threads) and Y is the number of concurrent requests before Mongrel starts refusing connections (standard Mongrel num-processes). Note: run one process per-core or turn off a core if you want to compare performance to a Mongrel cluster.
Feel free to provide feedback in comments, or on the mongrel-users mailing list.
Bruno Miranda posted a review of various agile project management tools including Mingle, VersionOne, TargetProcess, and Tracker. Check it out here.
We’ve let Bruno know that Tracker is actually under active development. One of the first new features that we’ll be rolling out soon is a REST API, followed by various usability improvements that will make it easier to work with larger projects.
We’re also looking for more suggestions on how to make Tracker better, especially in the area of higher level planning. Send your ideas to email@example.com, or post them on Satisfaction.
And if you haven’t tried it yet, the Tracker beta is fully open to the public, feel free to sign up.
First of all, fie on Apple for giving both their cloud storage service and their backup program names that are almost completely google-proof. They’ve recently corrected one of those by renaming “dot mac” to “MobileMe” but calling your backup program “Backup” is a great way to make it really hard to investigate. It’s like, imagine how hard it would be to do a background check on someone named John Doe.
So I use the Dot Mac Backup and it works pretty smoothly, which is the second most important feature in a backup program. (The most important feature is the ability to actually restore files.) But then one day it said that to incrementally back up my “Home Minus Media” set — the set containing my Home Folder, but excluding big-ticket items like Music, Movies, Backups, Downloads, and so on — would require 63 DVDs. WTF?
It turned out that the problem occurred after I trashed a few old DVD rips that I had finished watching, and the culprit was the directory
/Users/chaffee/.Trash. Seems like the UI was helpfully excluding it from the list of subdirectories of
/Users/chaffee, it being a system file and all, so I couldn’t mark it to exclude. That’s OK, I think, I’m a power user, so I’ll just check the box that says “Show invisible system files.”
Except there’s no such box. Try as I might, I can’t find a way to exclude the Trash folder from the UI. I had to dig into the file system and edit Backup’s own data file, as follows.
- In Backup, create a backup set and exclude at least one item in it
- Quit the Backup app
- In Finder, open up
- There will be a list of randomly named
.backupset folders. Each contains a folder named
Contents. For each, use Quick Look (hit Space) on and a file named
InfoPlist.strings to find the one containing your set.
- Open its sibling named
User.quickpick in a text editor like TextMate.
- The “quickpick” file is actually a folder, so open up the file buried under there named
- Find the section “Prune Paths” and add an entry for
- Save the file and relaunch Backup.
You should see the “
.Trash” entry excluded as if you had clicked on it — which you would have if they had showed you the silly thing in the first place.
As you can see from the screenshot, I’ve still got some excess gigabytes to hunt down and exclude, but at least I won’t get burned the next time I erase a metric buttload of pr0n– uh, I mean, content I legally acquired and temporarily transferred onto my personal computer in compliance with the DMCA.
I just released cinabox. It is intended to be The Simplest Thing That Could Possibly Work to set up a Continuous Integration (CI) server, using cruisecontrolrb (CCRB).
In addition to being a (hopefully) useful tool to help people easily set up CI systems for various platforms and languages, it is also an experiment in simplicity and minimalism:
- The project consists of only two simple scripts, one shell script to bootstrap ruby, and one ruby script to set up cruisecontrolrb.
- In the script, readability and simplicity are favored over clever abstractions and DRYness. Hopefully, even people who don’t know shell scripting or Ruby can read the scripts and easily understand the commands it is executing.
- A standardized environment is assumed: A dedicated Ubuntu 8.04 system, Ruby 1.8.6, and latest dependencies via aptitude. PCs and Virtual Machines are cheap, and Linux and CCRB are free. There’s really no reason you shouldn’t be able to run a dedicated CI box. If this environment doesn’t work for you for some reason, the scripts should be self-explanatory enough that you can easily hack it up to work for your environment (and contribute your version back to to the project!).
- I use the magic fairy dust of GitHub to eliminate build scripts, release scripts, packaging, versions, and pretty much all the regular boring overhead of a project. The README.txt is my only documentation. The GitHub “Download Tarball” link automatically provides packaging and uniquely-named packages (by the git hex commit id) for each “release”.
I’m pretty pleased with how this turned out. I hope it will lower the barrier for people to start trying out Continuous Integration, as well as provoke some thought about simplicity and minimalism. I’ve tried it out on a few flavors of Ubuntu VMs and my personal box, and it works for me. Please let me know what you think, and feel free to offer any suggestions for improvement.