sorted by: recent | see : popular

Content Tagged with Miscellaneous + cool

It was with much excitement that Merbcamp started yesterday with a keynote from Ezra Zygmuntowicz, initial creator of the Merb Web application framework. Aside from covering Merb-related news, Ezra revealed a project called Nanite - a "self assembling cluster of Ruby daemons."

A Nanite installation is based around a "mapper exchange" with which Ruby daemons (called Nanite "agents") register. Nanite mappers (running in, say, Rails or Merb applications, or even command line apps) can then call the exchange and gain access to the functionality of the agents. The mapper exchange makes it possible for daemons / agents to start, stop and die while allowing the whole cluster to be self-healing.

Ezra says:

Nanite is a new way of thinking about building cloud ready web applications. Having a scalable message queueing backend with all the discovery and dynamic load based dispatch that Nanite has is a very scalable way to construct web application backends.

It's still early days, but Nanite could become a key part of the back end of Ruby-developed Web applications in the future. Nanite offers some key benefits (scalability, reliability) on the cheap - it's worth investigating if these traits sound useful for your own projects.

Post supported by RichAppsConsulting: Are you looking for an Agile web 2.0 company to develop your company's website quickly and professionally? At RAC, we have a highly trained staff of developers who are experts in Rails, Flex and PHP development. We can develop solutions for your company with your budget and timeline in mind. We pride ourselves on having superior Rails programming skills the and striving for continuous improvement. For more information, call our office at 202.470.6683 or email us at contact@richappsconsulting.com. Please visit our website at http://www.richappsconsulting.com.

Terminator is a new library developed by Ara Howard and Mikel Lindsaar that solves the problem of Ruby's own "timeout" feature not actually being up to the task of terminating code. timeout is supposed to terminate the execution of a block of code if it's not finished within a certain amount of time, but due to Ruby's threading model it doesn't always work that way!

Initially, Mikel considered SystemTimer - another replacement for timeout. SystemTimer is based upon UNIX alarm signals and, for some reason, still didn't resolve the main problem (although SystemTimer has ridiculously good documentation and is clearly working well for someone). After lamenting on the Ruby-Talk mailing list, Ara Howard stepped in with a potential solution which turned into what is now Terminator.

Terminator works by starting up another Ruby instance that tracks the PID of the Ruby instance that spawned it. Windows is currently not supported.

You can install Terminator with gem install terminator or check out the code directly from here (note: they have some weird issue with referrals, just reload the URL when you get there).

(Photo credit: Kieran Huggins)

RubyFringe - described as a "pricey, limited-attendance smoozefest" by Ruby documentation co-ordinator James Britt or as "an avant-garde conference for developers that are excited about emerging technologies outside of the Ruby on Rails monoculture" by the organizers - went ahead last week and appears to have been a significant hit. A small conference with a reasonably high ticket price (though far less than RailsConf Europe!), RubyFringe was set to be a very unique sort of conference with parties, drinks and out-of-hours entertainment laid on, and a limited number of tickets made available to ensure a more intimate gathering. The gamble appears to have paid off.

Praise

I'm not quite sure exactly what went down (I had to pull out of attending) but all references I've seen have been almost over-the-top with excitement and praise:

Soleone says: "Rubyfringe was amazing! So many good talks and great people. Best talk: Giles' presentation on computer generated music. Laughed my ass off!"

Rob Sanheim says: "rubyfringe was a blast, and now i can't sleep."

Lennon Day-Reynolds says: "RubyFringe after-party unsurprisingly turned out to be awesome."

Josh Merchant described it as "an amazing - inspirational - creative- experience."

Heck, there are far too many positive mentions to read on Twitter.

Mark McGranaghan of TechCrunch wrote directly to Ruby Inside:

RubyFringe was a huge win. Unspace set out to raise the bar for software conferences, and I think that they succeeded. I hope that RubyFringe does for web conferences what Rails did for web development; show others that there is a better way, that it does not require corporate sponsorship, and that it can fun, artistic, and productive all at the same time.

Content

There are over 1000 photos from the event on Flickr.

Joey deVilla has put together some handy notes for most of the presentations.

Rowan Hick has put together a list of his RubyFringe highlights.

InfoQ attended the event and, I am told, will be putting up videos of several presentations on their site soon. Until then, the content of the talks is summarized here.

The next RubyFringe?

With such success, it's inevitable another RubyFringe conference will take place within the next year. If you're interested, Pete Forde suggests joining the Google group, and keeping an eye on RubyFringe.com for more info (although it'll be here at Ruby Inside too). It remains to be seen if the success of RubyFringe will encourage "avant garde" conferences elsewhere in the world or for non Ruby communities generally, but Ruby Inside wants to hear about them if so.

Autumn is a framework by Tim Morgan that makes it easy to develop powerful IRC (Internet Relay Chat) bots with Ruby. Version 3, a significant update, was launched just a week ago. The code is available on Github, so it's ready to fork, tweak and work on to your heart's content.

An instance of an "Autumn app" is laid out in a similar way to a Rails app. There are config, doc, script, libs, tmp, and log folders, containing much what you'd expect, as well as a leaves folder (Autumn refers to "bots" as "leaves") that contains any number of folders each containing data, helpers, models, tasks, and "views" for individual bots. A default Autumn app comes with two bots pre-installed called insulter and scorekeeper that you can use to learn from.

Autumn is a pretty significant piece of work and Tim has done an excellent job at documenting it, leaving almost no stone unturned in demonstrating how to create bots / leaves of your own with the framework.

Dr Nic Williams has been busy playing with iPhone and Objective C development lately and, unsurprisingly, has found a way to bring Ruby into the mix. He has developed rbiphonetest, a Ruby-based testing framework for iPhone / Objective C applications that uses RubyCocoa to provide the necessary bridge. As well as producing an in-depth 20 minute demonstration screencast, he has also packed some key information into his blog post.

If you're a Rubyist with ambitions of developing native iPhone applications using Objective C (and perhaps even Ruby one day), it's certainly worth a look (as are all of Dr Nic's projects, of course).

Pool Party is a new tool by Ari Lerner (of ProcessorPool fame) that makes it easy to automate the deployment, monitoring (using monit), persistent storage (using S3Fuse), and load balancing (using HAProxy) of EC2 instances. While intended to be application agnostic, there’s naturally a major slant towards Ruby applications in general, with support for Rake tasks a core feature.

Ari’s announcement blog post gives more in-depth details. Development is taking place on Github (where the README is somewhat more readable than with RDoc!) along with discussions at a Google group.

Ari presented PoolParty at RailsConf last week, and his slides are available to view below (or at Scribd):

Slapp: A simple chat wall Merb tutorial is a perfect example of the sort of tutorial / guide that could encourage a lot of people to try out a new framework (as far as Merb is new, of course). It walks you through the process of developing a “chat wall” type application with Merb from start to finish (right from installing Merb to playing with the running application).

One thing that makes the tutorial stand out is that it puts test spec driven development at the heart of the application. After installing Merb and configuring the database, you’re straight into writing a story with RSpec! This is quite different to most of the Rails introductory articles which skim over testing, and it makes the guide very suitable for those who aren’t familiar with RSpec but who want to learn how to use it while developing a Web application.

Lastly, the “finished” application is available from a Gitorious Git repository for those who want to work backwards or look at the code up front.

If you couldn’t get to the popular MountainWest RubyConf two weeks ago, don’t fear. In conjunction with Confreaks, videos of all of the presentations are available to watch online. 14 videos are available, including the following:

It seems MountainWest had a really high quality level of talks, so give it a thought when choosing which Ruby events to attend next year.

(On another level, I’m kinda surprised by how many Rubyists seem to have ended up working in groups - whether ThoughtBot, ENTP, or Engine Yard.)

Disclaimer: Scout is a commercial service. I have received no compensation for mentioning this service and am posting about it merely due to my own interest in it.

Scout is a new “a la carte” monitoring and reporting service, primarily for tracking servers and Web applications, developed by HighGroove Studios. Scout lets you use plugins (provided both by HighGroove and other Scout users) written in Ruby to customize and manipulate your monitoring arrangements. You can also write your own plugins. Subscription levels will vary from a free account (one server, up to 3 plugins, 30 minute reporting intervals) up to over $100 per month for the highest level (supporting many more servers, shorter intervals, unlimited plugin usage, etc.)

The installation process and plugin system are what make Scout particularly unique and interesting. A Scout “client” is run on each machine you wish to monitor, and is installed with RubyGems (gem install scout). The client routinely runs its plugins and sends information to the central Scout service (rather than Scout “querying” the server, as with most monitoring services). Any plugins you install through the Scout Web interface are pulled down by the Scout client to all of the relevant servers automatically!

Scout is still in its pre-release stage (though not for long) but HighGroove have offered to give the first 20 Ruby Inside readers who mail rubyinside@highgroove.com an account! So.. be quick if you want a go :) (They’ve now all gone, sorry!)

I also decided to ask the Scout team a few questions about the service to get a better feel for how it works:

Is Ruby the only language used on Scout? If not, why not, and what else are you using?

James Edward Gray II: The Scout client and server are written in Ruby, yes. They make use of data formats like YAML and Ruby’s marshaled object binary format as well as communicate using protocols like HTTP, but the beating heart is Ruby at both ends.

However, most plugins will shell out to external utilities. Some of these utilities might be considered languages in their own right. For example, AppleScript can be used to communicate with or control Mac OS X applications. Even the shells themselves are languages and plugin writers may want to make use of that fact.

The reason to rely on these external sources of data is simple: plugins can get the data they need from the expert sources with very little effort. Duplicating the functionality of all popular system utilities in Ruby would be a massive undertaking and extremely error prone. Instead, we want users cranking out handy plugins by investing small slices of time. In short, we want to focus on the interesting problems that haven’t already been solved.

Which technologies does Scout use?

Derek Haynes: The web interface is a Rails app, but the bulk of the requests are processed by a separate Merb app that handles all of the alerts, reports, and errors that are sent to Scout. We went with this setup for 2 primary reasons - we need to continue to process data even when we’re updating the web interface, so we needed to decouple the web service from the app and Merb handles these requests more efficiently.

Why did you choose Ruby for Scout’s plugin language, and how has it worked out so far?

James Edward Gray II: Like her sister language Perl, Ruby is a powerful tool when used to glue system utilities together. The ease of talking to external processes and the powerful string manipulation features make it an ideal choice for collecting important data and transforming it into the needed formats for the server. This is a big strength of Ruby’s design that gets overlooked too often. We hope to change that, of course.

How does Scout plan to deal with availability?

Charles Brian Quinn: The Scout server is running on virtualized hardware, with two physical locations at InterNAP and the AtlantaNAP data centers. We are fully load-balanced with failover support. In the event of failure at one of the datacenters, we are fully redundant. We plan on scaling out horizontally as the need arises.

Do you have any plans or see any further innovations for Scout using Ruby further down the road?

Derek Haynes: I hate to sound like a Real Estate Scammer, but it’s practically unlimited. You can include any Ruby library when running a plugin (here’s an example that “loads the Rails environment” and “another that uses hpricot“), so anyone can extend the client. An obvious answer is a Ruby DSL for working with system commands. A couple of new libraries address this in different ways, but as James said earlier, a one-size-fits-all solution is a massive undertaking.

Last week, Gregory Brown, of the O’Reilly Ruby blog and Ruby Reports, came up with the idea of devoting his time to working on Ruby-related open source projects, as a sort of “Ruby mendicant.” He figured if he could raise at least $500 for each week of work, he could devote 20-25 hours per week to the project. The contributors would then be able to suggest ideas, and potentially vote on the things Gregory would work on. His initial ideas included working on the PDF::Writer and Ruby Reports libraries (the former of which could really do with some serious time on it), amongst other things.

People caught on to and supported Gregory’s idea, and now it’s going live! He has set up a Pledgie page where he’s attempting to raise $8000 to support 26 weeks (half a year) of this work. He has also written a formal proposal of his ideas for those who are unconvinced.

The more astute reader will note that $8000 does not cover 26 weeks at $500 per week ($13,000 total.) The reason for only needing to raise $8000, however, is because Ruby Central Inc. has pledged to match donations dollar for dollar up to a maximum of $5000! So if you give $50 to the campaign now, that turns into a whole $100 to support Gregory.

I can personally appreciate that some people will not want to support this because either they feel there are already plenty of people who spend serious time each week working on open source for free or because of the less-than-stellar results of similar experiments (such as Jason Kottke’s similar “micropatron” experiment or the caboo.se documentation drive - I’m not entirely sure all that money ever got spent?) Despite these points, I have a lot of faith in Gregory considering his past contributions to the Ruby community and in being the only significantly consistent contributor to the O’Reilly Ruby blog. I think he has the staying power to do some great work here and am more than happy to vouch for him.

Ebb is a small, extremely high performance Web / HTTP server designed specifically for hosting applications built upon Web frameworks such as Rails and Merb (and, in future, apps on other non-Ruby frameworks.) The design is event based (similar to that used by Ruby daemons that use EventMachine) but Ebb itself is written in C and dispatches requests to Rack adapters. This is a real leapfrog over the popular Mongrel and Thin daemons which are primarily written in Ruby, and results in scary levels of performance.

Since the start of 2008, it seems as if the Ruby and Rails deployment sectors have been on fire! Thin, a Ruby HTTP daemon that’s faster than Mongrel, made it on the scene in January, then we discussed the problems involved in deploying apps here on Ruby Inside, and my own SwitchPipe arrived in February. Other systems such as Swiftiply have also continued to innovate. These are exciting times!

Dominiek ter Heide has put together a great tutorial that walks you through building a “Twitter agent” using Ruby, Rails and XMPP. For those who aren’t on Twitter yet, it’s a free micro-blogging cum “presence” information service that allows users to write 140 character messages that are supposed to represent their current state / feelings / location / etc. A Twitter agent, therefore, is essentially an automated Twitter user that can deliver information to other Twitter users.

The tutorial is quite in-depth with lots of code examples and helpful diagrams. Dominiek explains it all very directly, and even has the developed service running for real, so you know you’re seeing something that actually works.

ActiveMerchant is a new e-book written by Cody Fauser and produced by Geoffrey Grosenbach’s PeepCode which, unsurprisingly, is about the Active Merchant Ruby library and Rails plugin (past Ruby Inside reference). Cody Fauser is a key developer on the Active Merchant project, so all the knowledge is from the “horse’s mouth,” as it were!

The Active Merchant library was initially developed as part of the Shopify e-commerce system, and is an excellent library for interacting with payment gateways from Ruby (and Rails) code. It’s been in production use handling tens of thousands of payments since 2006 and it now has support for several payment gateways, including PayPal, Authorize.Net, and TrustCommerce.

Cody’s e-book comes in PDF format and is immaculately produced with helpful diagrams, concise code snippets, and it proves incredibly easy to read on the screen while retaining the ability to give a good printed copy. At 74 pages it goes into just the right amount of detail, and at $9 is a bargain for anyone wanting to get involved with processing payments and dealing with payment gateways from Ruby or Rails applications (you’ll hopefully make that back on your first couple of payments!)

Disclaimer: PeepCode is a Ruby Inside sponsor, but does not receive any special treatment regarding editorial posts such as this one. It truly is a good e-book!

Ruby Plus is a site offering free Ruby and Rails related screencasts recorded by Bala Paranj, much in the same vein as Ryan Bates’ Railscasts. The screencasts are generally similar in length and overall format to those from Railscasts. So far there are 29 episodes you can download.

The first twelve screencasts in the archive (for which you have to register to download, alas) were exclusively Ruby, covering topics like blocks, class_eval, modules, recursion, and so on, but unfortunately the rest of the screencasts have been entirely Rails focused beyond those first twelve. It’s still a source worth checking for Ruby and Rails screencasts though, so give it a look.

(Update: Several people have reported to me that they have an issue with Ruby Plus being portrayed in a positive light. I’ll admit I haven’t watched a significant number of the screencasts, just a couple in fact, but what I saw seemed okay in terms of production. With all the complaints, however, I figure you should be aware that there appear to be quite a few people who are not keen on the site, so you may just want to skip this post.. but I cannot remove it as it is now part of the public record and, as you probably know, I don’t do censorship.)