#376 JRuby Basics

JRuby is a polished and stable Ruby implementation. Here I show the basics of setting it up and executing Java from within Ruby. I also see how it compares with MRI at running threads.

"Explore It!" and "Scalable and Modular Architecture for CSS"

“Explore It! Reduce Risk and Increase Confidence with Exploratory Testing” and “Scalable and Modular Architecture for CSS” now available

Ruby Programming 36th Batch: Registrations now open

Registrations are now open for RubyLearning’s popular Ruby programming course. This is an intensive, online course for beginners that helps you get started with Ruby programming.

Here is what Demetris Demetriou, a participant who just graduated, has to say – “When I joined this course I was sceptical about how useful this course would be for me instead of reading material and watching videos on YouTube and thus saving money. After the course started I realised how valuable this course was. In the past I had read many Ruby books over and over, but never got into really getting practical with it and never had confidence in it. Lots of theory but couldn’t use it. I feel that the exercises in this course and the support, monitoring from our mentor Victor, made the huge difference that all books in the past didn’t. It wasn’t about reading lots of books, but simply few things and get practical and understand them well. I feel I learnt a lot and I’m coming back for more to rubylearning.org Thanks a lot Victor and Satish and all the other Rubyists who gave us today’s Ruby.”

What’s Ruby?

Ruby

According to http://www.ruby-lang.org/en/ – “Ruby is a dynamic, open source programming language with a focus on simplicity and productivity. Ruby’s elegant syntax is natural to read and easy to write.”

Yukihiro Matsumoto, the creator of Ruby, in an interview says –

I believe people want to express themselves when they program. They don’t want to fight with the language. Programming languages must feel natural to programmers. I tried to make people enjoy programming and concentrate on the fun and creative part of programming when they use Ruby.

What Will I Learn?

In the Ruby programming course, you will learn the essential features of Ruby that you will end up using every day. You will also be introduced to Git, GitHub, HTTP concepts, RubyGems, Rack and Heroku.

Depending on participation levels, we throw a Ruby coding challenge in the mix, right for the level we are at. We have been known to give out a prize or two for the ‘best’ solution.

Who’s It For?

A beginner with some knowledge of programming..

You can read what past participants have to say about the course.

Mentors

Satish Talim, Michael Kohl, Satoshi Asakawa, Victor Goff III and others from the RubyLearning team.

Dates

The course starts on Saturday, 22nd Sept. 2012 and runs for seven weeks.

RubyLearning’s IRC Channel

Most of the mentors and students hang out at RubyLearning’s IRC (irc.freenode.net) channel (#rubylearning.org) for both technical and non-technical discussions. Everyone benefits with the active discussions on Ruby with the mentors.

How do I register and pay the course fees?

  • The course is based on the The Ultimate Guide to Ruby Programming eBook. This book is normally priced at US$ 19.95 and we are discounting it US$ 10.00 by combining it in the Course+eBook option below.
  • You can pay either by Paypal or send cash via Western Union Money Transfer or by bank transfer (if you are in India). The fees collected helps RubyLearning maintain the site, this Ruby course, the Ruby eBook, and provide quality content to you.
  • Once you pay the fees below, register on the RubyLearning.org site and send us your name and registered email id while creating an account at RubyLearning.org to satish [at] rubylearning [dot] com We will enrol you into the course within 48 hours.
  • If you have purchased the eBook at the time of registration, we will personally email you the eBook within 48 hours.

You can pay the Course Fees by selecting one of the three options from the drop-down menu below. Please select your option and then click on the “Buy Now” button.

Options

At the end of this course you should have all the knowledge to explore the wonderful world of Ruby on your own.

Here are some details on how the course works:

Important:

Once the course starts, you can login and start with the lessons any day and time and post your queries in the forum under the relevant lessons. Someone shall always be there to answer them. Just to set the expectations correctly, there is no real-time ‘webcasting’.

Methodology:

  • The Mentors shall give you URL’s of pages and sometimes some extra notes; you need to read through. Read the pre-class reading material at a convenient time of your choice – the dates mentioned are just for your guideline. While reading, please make a note of all your doubts, queries, questions, clarifications, comments about the lesson and after you have completed all the pages, post these on the forum under the relevant lesson. There could be some questions that relate to something that has not been mentioned or discussed by the mentors thus far; you could post the same too. Please remember that with every post, do mention the operating system of your computer.
  • The mentor shall highlight the important points that you need to remember for that day’s session.
  • There could be exercises every day. Please do them.
  • Participate in the forum for asking and answering questions or starting discussions. Share knowledge, and exchange ideas among yourselves during the course period. Participants are strongly encouraged to post technical questions, interesting articles, tools, sample programs or anything that is relevant to the class / lesson. Please do not post a simple "Thank you" note or "Hello" message to the forum. Please be aware that these messages are considered noises by people subscribed to the forum.

Outline of Work Expectations:

  1. Most of the days, you will have exercises to solve. These are there to help you assimilate whatever you have learned till then.
  2. Some days may have some extra assignments / food for thought articles / programs
  3. Above all, do take part in the relevant forums. Past participants will confirm that they learned the best by active participation.

Some Commonly Asked Questions

  • Qs. Is there any specific time when I need to be online?
    Ans. No. You need not be online at a specific time of the day.
  • Qs. Is it important for me to take part in the course forums?
    Ans. YES. You must Participate in the forum(s) for asking and answering questions or starting discussions. Share knowledge, and exchange ideas among yourselves (participants) during the course period. Participants are strongly encouraged to post technical questions, interesting articles, tools, sample programs or anything that is relevant to the class / lesson. Past participants will confirm that they learned the best by active participation.
  • Qs. How much time do I need to spend online for a course, in a day?
    Ans. This will vary from person to person. All depends upon your comfort level and the amount of time you want to spend on a particular lesson or task.
  • Qs. Is there any specific set time for feedback (e.g., any mentor responds to me within 24 hours?)
    Ans. Normally somebody should answer your query / question within 24 hours.
  • Qs. What happens if nobody answers my questions / queries?
    Ans. Normally, that will not happen. In case you feel that your question / query is not answered, then please post the same in the thread – “Any UnAnswered Questions / Queries”.
  • Qs. What happens to the class (or forums) after a course is over? Can you keep it open for a few more days so that students can complete and discuss too?
    Ans. The course and its forum is open for a month after the last day of the course.

Remember, the idea is to have fun learning Ruby.

Technorati Tags: , , ,


(Powered by LaunchBit)

Rapid Android Development: Build Rich, Sensor-Based Applications with Processing now in beta

Rapid Android Development: Build Rich, Sensor-Based Applications with Processing now in beta

Depending on jQuery and Perspective

The reported errata for Master Time and Space With JavaScript (buy it here) has been pretty light so far. A bunch of typos, some setup weirdness.

And one interesting issue worth exploring. What is a dependency, and maybe more to the point, where is a dependency?

This issue was raised by a reviewer whose name I’m not going to mention — that’s not a reflection on the reviewer, but rather a reflection on the fact that I’m going to put words in his mouth to expand on his brief comment on the issue, so my interpretation of his position may not actually be his position.

Anyway the reviewer had a comment about when to convert to and from jQuery objects. He raised it in the context of the autocomplete example from the please-go-pay-for-it Book 2, but it also applies to the toggler example in just-for-free Book 1, and really, in any case where you have a JavaScript object which uses a data type that is a jQuery object.

Here’s the deal. I have an object — in this case it’s my autocomplete selector, but I’ll pretend it’s a generic widget because the exact object doesn’t matter — which is being initialized via a function call like so.

    widget = new Widget({parentSelector: "#autodiv"});

The key point here being the parentSelector: "#autodiv" option. In the eventual constructor, that #autodiv is immediately converted to a jQuery object (The example in the book is more elaborate, I’m simplifying to focus on the issue at hand…)

    var Widget = function(options) {
        this.$domParent = $(options.parentSelector);
    };

The reviewer’s point was that he’d rather convert the selector to jQuery in the call to Widget and pass the argument to Widget already converted to a jQuery object, rather than have the Widget constructor do the conversion:

    widget = new Widget({domParent: $("#autodiv")});

    var Widget = function(options) {
        this.$domParent = options.domParent;
    };

I’m not convinced yet that one way is better than the other — I haven’t changed the book code, but I certainly respect this reviewer’s opinion on how to structure JavaScript. But I do think that the two options make different assumptions about the structure of the application that are worth teasing out.

In my structure, jQuery is treated as an implementation detail of the Widget. Since jQuery is an implementation detail, outside code wouldn’t be expected to know about it, so outside code communicates to the Widget via a selector. Now, I grant that there’s a little bit of fiction there, since the selector syntax is (somewhat) jQuery specific. If I really wanted to isolate jQuery, then the calling argument should just be the DOM ID, and the Widget would also be responsible for converting the DOM ID to a jQuery object, with the intermediate step of building a jQuery selector string:

    widget = new Widget({parentId: "autodiv"});

    var Widget = function(options) {
        this.$domParent = $("#" + options.parentId);
    };

The advantage of treating jQuery as an implementation detail of my widget is that the rest of my code does not need to know or care about it, and I can presumably even test other parts of my code without jQuery even being around. Also, if I choose to swap jQuery out for some reason, the rest of my code doesn’t need to know, only my widget needs to be changed. I would consider the conceptual point about jQuery being an implementation detail of the widget to be important even if I find it exceptionally unlikely that I would swap out jQuery. (For one thing, it also protects me against jQuery itself changing).

In my reviewer’s structure jQuery is a dependency of the application as a whole. Looked at from that perspective, it makes sense to convert everything to jQuery objects as early as possible, to maintain consistency of representation across the entire application. The code as a whole may be easier to read, since we aren’t continually having to worry about whether an object is a jQuery object or just some kind of DOM identification. If multiple widgets are all using the same jQuery object, then we might prevent some duplicate conversion to jQuery objects. This probably simplifies the internal code at the cost of making us more dependent on jQuery itself. As a practical matter, that tradeoff might be worth it — once we’ve decided to use jQuery, changing it is probably unlikely.

Essentially, it’s a question of where you draw your boundaries. I’m not sure there’s a long-term practical difference between these two structures, in that I don’t think one of them necessarily leads to better or more flexible code over time, especially given even rudimentary attention to practical details. But I do think you should be clear about which structure you are using — mixing the two by treating jQuery as a specific dependency of some parts of the code but a general dependency of other parts would probably lead to confusion later on.

Update:

A reddit commenter asked why I wasn’t passing a DOM element into the Widget, as in:

new Widget({parentSelector: document.getElementBy("autodiv")});

My response: I have nothing really against passing in a DOM element beyond it being a little verbose and an old-timey superstition against using getElementBy. Using a DOM element still keeps the dependency in the widget.

Like this? Go ahead and read Master Time and Space With JavaScript

Depending on jQuery and Perspective

The reported errata for Master Time and Space With JavaScript (buy it here) has been pretty light so far. A bunch of typos, some setup weirdness.

And one interesting issue worth exploring. What is a dependency, and maybe more to the point, where is a dependency?

This issue was raised by a reviewer whose name I’m not going to mention — that’s not a reflection on the reviewer, but rather a reflection on the fact that I’m going to put words in his mouth to expand on his brief comment on the issue, so my interpretation of his position may not actually be his position.

Anyway the reviewer had a comment about when to convert to and from jQuery objects. He raised it in the context of the autocomplete example from the please-go-pay-for-it Book 2, but it also applies to the toggler example in just-for-free Book 1, and really, in any case where you have a JavaScript object which uses a data type that is a jQuery object.

Here’s the deal. I have an object — in this case it’s my autocomplete selector, but I’ll pretend it’s a generic widget because the exact object doesn’t matter — which is being initialized via a function call like so.

    widget = new Widget({parentSelector: "#autodiv"});

The key point here being the parentSelector: "#autodiv" option. In the eventual constructor, that #autodiv is immediately converted to a jQuery object (The example in the book is more elaborate, I’m simplifying to focus on the issue at hand…)

    var Widget = function(options) {
        this.$domParent = $(options.parentSelector);
    };

The reviewer’s point was that he’d rather convert the selector to jQuery in the call to Widget and pass the argument to Widget already converted to a jQuery object, rather than have the Widget constructor do the conversion:

    widget = new Widget({domParent: $("#autodiv")});

    var Widget = function(options) {
        this.$domParent = options.domParent;
    };

I’m not convinced yet that one way is better than the other — I haven’t changed the book code, but I certainly respect this reviewer’s opinion on how to structure JavaScript. But I do think that the two options make different assumptions about the structure of the application that are worth teasing out.

In my structure, jQuery is treated as an implementation detail of the Widget. Since jQuery is an implementation detail, outside code wouldn’t be expected to know about it, so outside code communicates to the Widget via a selector. Now, I grant that there’s a little bit of fiction there, since the selector syntax is (somewhat) jQuery specific. If I really wanted to isolate jQuery, then the calling argument should just be the DOM ID, and the Widget would also be responsible for converting the DOM ID to a jQuery object, with the intermediate step of building a jQuery selector string:

    widget = new Widget({parentId: "autodiv"});

    var Widget = function(options) {
        this.$domParent = $("#" + options.parentId);
    };

The advantage of treating jQuery as an implementation detail of my widget is that the rest of my code does not need to know or care about it, and I can presumably even test other parts of my code without jQuery even being around. Also, if I choose to swap jQuery out for some reason, the rest of my code doesn’t need to know, only my widget needs to be changed. I would consider the conceptual point about jQuery being an implementation detail of the widget to be important even if I find it exceptionally unlikely that I would swap out jQuery. (For one thing, it also protects me against jQuery itself changing).

In my reviewer’s structure jQuery is a dependency of the application as a whole. Looked at from that perspective, it makes sense to convert everything to jQuery objects as early as possible, to maintain consistency of representation across the entire application. The code as a whole may be easier to read, since we aren’t continually having to worry about whether an object is a jQuery object or just some kind of DOM identification. If multiple widgets are all using the same jQuery object, then we might prevent some duplicate conversion to jQuery objects. This probably simplifies the internal code at the cost of making us more dependent on jQuery itself. As a practical matter, that tradeoff might be worth it — once we’ve decided to use jQuery, changing it is probably unlikely.

Essentially, it’s a question of where you draw your boundaries. I’m not sure there’s a long-term practical difference between these two structures, in that I don’t think one of them necessarily leads to better or more flexible code over time, especially given even rudimentary attention to practical details. But I do think you should be clear about which structure you are using — mixing the two by treating jQuery as a specific dependency of some parts of the code but a general dependency of other parts would probably lead to confusion later on.

Like this? Go ahead and read Master Time and Space With JavaScript

#374 Image Manipulation

Learn how to do extensive image manipulation with the ImageMagick commands. Also learn how RMagick can be used in combination with CarrierWave to process uploaded images.

Cucumber Recipes: Automate Anything with BDD Tools and Techniques now in beta

Cucumber Recipes: Automate Anything with BDD Tools and Techniques now in beta

Five Interesting Things You Can Do with Heroku Buildpacks

  • static content
  • Deploy elsewhere
  • null
  • multiple buildpacks


How’s it Going? MSTWJS Edition

And now for a more inside-baseball post about how the self-publishing aspects of Master Space and Time With JavaScript are going. Did you know you can buy it?

Short answer: Pretty well, though I could always have done better. Still unclear how this will work over the long haul.

At this point, the book has been on sale for 10 days, plus the pre-sale to people who were on the mailing list. It’s clear that the initial burst of traffic from incoming links is slowing down, and I’m now entering the longer struggle to get people interested — not completely sure how to do that.

Anyway, a few disconnected points about the process so far

One of the big things I miss about a larger publisher is the marketing reach. That said, there’s something really nice about how people feel a little bit of ownership concerning self-published projects that they like. I’ve gotten a couple of very nice copy-edit runs, for example.

I’ve generally been lucky in reviews (notable exception: the two-star review of RTP on Amazon that I check out whenever my Impostor’s Syndrome feels insufficiently pronounced…), and so far, the people who have commented on the books where I can see them have been positive.

I can be a little transparent with numbers. As I type this, traffic is still about double the level that I had generated in the past on days that I posted to the blog, and much, much higher than the ambient level of traffic when I hadn’t been posting.

Over the course of the ten days, about one in six people that have hit the landing page at http://www.noelrappin.com/mstwjs and aliases convert to either the free version or one of the paid versions. Low day was 12%, high day was just under 23%. There doesn’t seem to be a consistent trend between traffic and conversion rate.

So that’s about one in six doing anything, of those that do choose, about one in six or so actually bite on one of the paid versions. So that’s a paid conversion rate in the 2 – 3% range. That rate seems to be slightly negatively correlated with traffic, which is actually in line with what I would expect.

As for the pricing strategy, which I thought was so clever… So far, there have only been a very few people buying book 2 at the $7 level — most purchases have been of the whole book at $15. I’m not planning on changing the pricing (beyond my already-stated plan to raise the $15 when Book 3 gets near-final). I want to see how this looks when there are more individual books for sale. But there’s a good chance this means that I outsmarted myself, and probably could have priced a little higher.

So far, as best as I can tell, under 3% of people who originally downloaded the free version came back to upgrade. That seems very low, but it might be higher — the way I’m counting this, if somebody gave me a bogus email for their freebie, I wouldn’t track it as an upgrade. Also, I assume this number goes up a touch as people read the book and as upgrade reminders go out. Still, as it stands, it’s not a great data point for the “give away free stuff to increase sales” school of internet marketing.

Over the course of the ten days, the number one referrer, by far, was Peter Cooper’s JavaScript Weekly email newsletter. It’s the biggest by about a factor of three over the next highest measurable referrer. Next up was Twitter, and I think the highest link out of those came from JavaScript daily, and I think the second one was from my feed. It’s really hard to track those for sure, though. Third was Google Reader, though I think that was mostly blog posts and not links to the landing page. Fourth was Reddit — my post there didn’t get much traffic, and fifth was the Ruby5 podcast and show notes. Rounding out the referrals so far is Mike Gunderloy’s Fresh Cup links, and then we also get some noise with internal referrals and things like Pocket, and the Ruby Rogues link, which just came out.

Another point of comparison is that MSTWJS sales are about 150% + of RTP sales over the first ten days. That’s less impressive than it sounds, I really struggled to get traction with RTP after the initial burst. (That’s the paid number for MSTWJS, and it includes the pre-sale to the list). RTP had a free section as well, and I don’t have any stats on how often that was downloaded, but since it was just a link and not a shopping cart, I think it was pretty high.

That’s where we are — I hope that those of you that bought or downloaded the book are enjoying it, and if you are hoping to do your own self-publishing project, I hope this information is helpful.

Oh, and the book is still on sale.

#372 Bullet

Bullet will notify you of database queries that can potentially be improved through eager loading or counter cache column. A variety of notification alerts are supported.

Raspberry Pi now available

Raspberry Pi book now available in the Pragmatic exPress series

August Tokaido Update

It’s been a while since I posted anything on my blog, and I figured I’d catch everyone up on the work I’ve been doing on Tokaido.

Components

Tokaido itself is made up of a number of components, which I am working on in parallel:

  • Ruby binary build, statically compiled
  • A logging and alerting UI
  • Remote Notifications for Rails 3+
  • Integration with Puma Express
  • Integration with code quality tools
  • Resolve bundler issue related to binary builds and deployment to Heroku
  • Work with community members to start shipping binary builds of popular gems (gates on fixing the bundler bug)

A number of people are doing parts of the work to make Tokaido a reality. I specifically want to thank:

  • Michal Papis of the rvm team for using the sm framework to make the Tokaido build maintainable over time and doing the heavy lifting to take the initial spike I did and get a reproducible binary build
  • Terence Lee of Heroku for packaging up these early binary builds for use at several Rails Girls events, with great success!

Ruby Binary Build, Statically Compiled

This is the first work I did, a few months ago, with help from Michal Papis. I detailed the hard parts of making Ruby statically compiled in June’s status update. Since then, Terence Lee (@hone02) has used the binary build at several Rails Girls events, dramatically reducing the time needed for Rails installation on OSX. In addition to the Tokaido binary build, Terence also precompiled a number of gems, and put built a script to download the entire thing as a zip, install it into the user’s home directory, and modify their ~/.profile to include it.

This strategy works well for trainings, but has a number of limitations:

  • Since it relies on precompiled gems already existing in the gem home, the gems cannot be removed or upgraded without requiring a C compiler. The correct solution is what gems authors do for Windows: ship versions of binary gems with specific OSX designations. Currently, binary gems do not interact well with Heroku deploys (or anyone using bundle install --deployment), so we have been working to resolve those issues before foisting a bunch of new binary gems on the world. See below.
  • It relies on modifying all instances of the Terminal, which means that some system edge-cases leak into this solution. It also relies on modifying ~/.profile, which may not work depending on what shell the user is using and what other startup scripts the user is running. For Tokaido, we will have a way to launch a Terminal that reliably injects itself without these problems, and without polluting all instances of Terminal.
  • It is difficult to upgrade components, like patch levels of Ruby or versions of C dependencies like libyaml. Tokaido.app will store its copy of Ruby and gems in a sandbox, loadable from the UI (as I described in the second bullet), which makes it easy for the .app to upgrade patch levels of Ruby or whatever components it needs.

Because I understand that many people WANT the ability to have their Ruby take over their terminal, Tokaido will integrate with rvm (and rbenv, if possible) to mount Tokaido.app as the default version of Ruby in your shell.

A Logging and Alerting UI

The primary UI for Tokaido will be a logging and alerting UI for your Rails application. I expect that you will spend the most time in the “Requests” UI, which will show you a list of the previous requests, and the log of the current request. My goal is to use the logging UI to improve on the typical “tail the log” experience. I’ve been working with Austin Bales, a designer at do.com to develop some mockups, and hope to have something for people to look at in the next few weeks.

In addition to an improved logging experience, Tokaido will alert you when something has gone wrong in your request. This may include exceptions (5xx) or information provided by plugins (bullet can let you know when your code is triggering an N+1 query; see the README for more information). The list of prior requests will highlight requests with issues, and problems in the notifications tray will directly link you to the request where the error occurred.

If everything goes well, the Tokaido UI will replace your logging workflow, without impacting the rest of the tasks you perform from the command-line.

Remote Notifications for Rails 3+

Rails 3 shipped with a new instrumentation API, which provides detailed information about many events that happen inside of Rails. This system is used by Rails’ own logging system, and I would like to use it in Tokaido as well.

The instrumentation API provides all of the information we need, but no built-in way to communicate those notifications across processes. Because Tokaido.app will not run in the same process as the Rails app, I have been working on a gem (remote_notifications) that provides a standard way to send these notifications to another process.

This gem also backports Aaron’s Rails instrumentation work (see his talk at Railsberry for more information) to Rails 3.0 and 3.1, which makes it possible to build a reliable tree from notifications, even on systems with low clock resolution.

It also includes a mechanism for subscribing to notifications sent from another process using the regular notifications API, and pluggable serializers and deserializers. It isn’t quite done yet, but I should have an initial release soon.

Integration with Puma Express

Puma is a new threaded web server built by Evan Phoenix of Rubinius fame. Puma Express manages Puma servers, automatically setting up the DNS (appname.dev) for you. This is similar to the approach used by Pow, but without a Node dependency.

Tokaido will integrate with Puma Express, so you will not need to manually boot and shut down your server. Because Tokaido also takes care of logging, there shouldn’t be any need for dedicated tabs with persistent running processes when you use Tokaido.

You will also be able to install an executable into your system (a la GitX and Textmate) to make it easy to boot up a Tokaido in the context of the current application:

$ tokaido .

This will be especially useful for people using the rvm “mounted” Tokaido.

Integration with Code Quality Tools

By default, Tokaido will integrate with flog, flay and rails-best-practices. It will periodically scan your Rails app for problems and notify you via the app’s notification tray. This mechanism will be extensible, so a future version of Tokaido might integrate with Code Climate or support code quality plugins.

Binary Gems and Heroku

Bundler provides a mechanism for deployment (bundle install --deployment) that specifically rejects deploys that require changes to the Gemfile.lock. When deploying a Gemfile.lock that was built using binary gems from a different platform, this mechanism rejects the deploy. At present, only Windows makes heavy use of binary gems, and Heroku’s solution to date has been to simply remove the Gemfile.lock and re-resolve dependencies.

Unfortunately, this solution eliminates the most important guarantee made by bundler, and is untenable in the long-term. If OS X users started to use binary gems more broadly, this would bring this problem into much wider circulation. Also, because platform-specific gems can contain alternate dependencies (see, for example Nokogiri 1.4.2), it is important that bundle install support alternate platforms more extensively than with a naïve solution.

There are a few possible solutions:

  • Do not use --deployment on Heroku. This would allow bundler to update the Gemfile.lock for the new platform. It would also mean that if a developer didn’t update their Gemfile.lock before deploying, they might run unexpected code. This is a short-term fix, but would probably alleviate most of the symptoms without introducing a lot of new caveats.
  • Fix --deployment to allow changes to the Gemfile.lock, but only in response to a genuine platform change. Unfortunately, because of cases like Nokogiri 1.4.2, this could theoretically result in totally different code running in production.
  • Provide a mechanism for developers to explicitly add a deployment environment: bundle platform add x86_64-linux. This would pre-resolve gems across all available platforms and ensure that the same gem versions could be used everywhere.
  • Improve the bundler resolution mechanism to allow gems with the same name, version and dependencies to be treated the same. Because dependencies can also exhibit this problem (a dependency of some JRuby gem could be another JRuby gem with its own non-standard dependencies), this would need to ensure that the entire subtree was the same.

The last solution is most promising, because the platform-specific gems Tokaido is concerned with are simply precompiled variants of the same gem. In the vast majority of cases, this simply means that the gem author is saving the end-developer the step of using a C compiler, but doesn’t actually change a lot else.

Unfortunately, Rubygems itself doesn’t distinguish between precompiled variants of gems and gems with different dependencies, so we will have to add smarts into bundler to detect the difference. My guess is that we will use a short-term fix like the first option while working on a longer-term fix like the last option.

Work Time

As I said in the original Kickstarter, I planned to take time off from work to work on the project. I have structured that time by working mornings on Tokaido, and shifting client work to the afternoons and evenings.

I don’t have a specific ship-date in mind for Tokaido yet, but you should start seeing more work-product as the project progresses, starting over the next few weeks.

Thanks for your patience. It shall be rewarded!

August Tokaido Update

It’s been a while since I posted anything on my blog, and I figured I’d catch everyone up on the work I’ve been doing on Tokaido.

Components

Tokaido itself is made up of a number of components, which I am working on in parallel:

  • Ruby binary build, statically compiled
  • A logging and alerting UI
  • Remote Notifications for Rails 3+
  • Integration with Puma Express
  • Integration with code quality tools
  • Resolve bundler issue related to binary builds and deployment to Heroku
  • Work with community members to start shipping binary builds of popular gems (gates on fixing the bundler bug)

A number of people are doing parts of the work to make Tokaido a reality. I specifically want to thank:

  • Michal Papis of the rvm team for using the sm framework to make the Tokaido build maintainable over time and doing the heavy lifting to take the initial spike I did and get a reproducible binary build
  • Terence Lee of Heroku for packaging up these early binary builds for use at several Rails Girls events, with great success!

Ruby Binary Build, Statically Compiled

This is the first work I did, a few months ago, with help from Michal Papis. I detailed the hard parts of making Ruby statically compiled in June’s status update. Since then, Terence Lee (@hone02) has used the binary build at several Rails Girls events, dramatically reducing the time needed for Rails installation on OSX. In addition to the Tokaido binary build, Terence also precompiled a number of gems, and put built a script to download the entire thing as a zip, install it into the user’s home directory, and modify their ~/.profile to include it.

This strategy works well for trainings, but has a number of limitations:

  • Since it relies on precompiled gems already existing in the gem home, the gems cannot be removed or upgraded without requiring a C compiler. The correct solution is what gems authors do for Windows: ship versions of binary gems with specific OSX designations. Currently, binary gems do not interact well with Heroku deploys (or anyone using bundle install --deployment), so we have been working to resolve those issues before foisting a bunch of new binary gems on the world. See below.
  • It relies on modifying all instances of the Terminal, which means that some system edge-cases leak into this solution. It also relies on modifying ~/.profile, which may not work depending on what shell the user is using and what other startup scripts the user is running. For Tokaido, we will have a way to launch a Terminal that reliably injects itself without these problems, and without polluting all instances of Terminal.
  • It is difficult to upgrade components, like patch levels of Ruby or versions of C dependencies like libyaml. Tokaido.app will store its copy of Ruby and gems in a sandbox, loadable from the UI (as I described in the second bullet), which makes it easy for the .app to upgrade patch levels of Ruby or whatever components it needs.

Because I understand that many people WANT the ability to have their Ruby take over their terminal, Tokaido will integrate with rvm (and rbenv, if possible) to mount Tokaido.app as the default version of Ruby in your shell.

A Logging and Alerting UI

The primary UI for Tokaido will be a logging and alerting UI for your Rails application. I expect that you will spend the most time in the “Requests” UI, which will show you a list of the previous requests, and the log of the current request. My goal is to use the logging UI to improve on the typical “tail the log” experience. I’ve been working with Austin Bales, a designer at do.com to develop some mockups, and hope to have something for people to look at in the next few weeks.

In addition to an improved logging experience, Tokaido will alert you when something has gone wrong in your request. This may include exceptions (5xx) or information provided by plugins (bullet can let you know when your code is triggering an N+1 query; see the README for more information). The list of prior requests will highlight requests with issues, and problems in the notifications tray will directly link you to the request where the error occurred.

If everything goes well, the Tokaido UI will replace your logging workflow, without impacting the rest of the tasks you perform from the command-line.

Remote Notifications for Rails 3+

Rails 3 shipped with a new instrumentation API, which provides detailed information about many events that happen inside of Rails. This system is used by Rails’ own logging system, and I would like to use it in Tokaido as well.

The instrumentation API provides all of the information we need, but no built-in way to communicate those notifications across processes. Because Tokaido.app will not run in the same process as the Rails app, I have been working on a gem (remote_notifications) that provides a standard way to send these notifications to another process.

This gem also backports Aaron’s Rails instrumentation work (see his talk at Railsberry for more information) to Rails 3.0 and 3.1, which makes it possible to build a reliable tree from notifications, even on systems with low clock resolution.

It also includes a mechanism for subscribing to notifications sent from another process using the regular notifications API, and pluggable serializers and deserializers. It isn’t quite done yet, but I should have an initial release soon.

Integration with Puma Express

Puma is a new threaded web server built by Evan Phoenix of Rubinius fame. Puma Express manages Puma servers, automatically setting up the DNS (appname.dev) for you. This is similar to the approach used by Pow, but without a Node dependency.

Tokaido will integrate with Puma Express, so you will not need to manually boot and shut down your server. Because Tokaido also takes care of logging, there shouldn’t be any need for dedicated tabs with persistent running processes when you use Tokaido.

You will also be able to install an executable into your system (a la GitX and Textmate) to make it easy to boot up a Tokaido in the context of the current application:

$ tokaido .

This will be especially useful for people using the rvm “mounted” Tokaido.

Integration with Code Quality Tools

By default, Tokaido will integrate with flog, flay and rails-best-practices. It will periodically scan your Rails app for problems and notify you via the app’s notification tray. This mechanism will be extensible, so a future version of Tokaido might integrate with Code Climate or support code quality plugins.

Binary Gems and Heroku

Bundler provides a mechanism for deployment (bundle install --deployment) that specifically rejects deploys that require changes to the Gemfile.lock. When deploying a Gemfile.lock that was built using binary gems from a different platform, this mechanism rejects the deploy. At present, only Windows makes heavy use of binary gems, and Heroku’s solution to date has been to simply remove the Gemfile.lock and re-resolve dependencies.

Unfortunately, this solution eliminates the most important guarantee made by bundler, and is untenable in the long-term. If OS X users started to use binary gems more broadly, this would bring this problem into much wider circulation. Also, because platform-specific gems can contain alternate dependencies (see, for example Nokogiri 1.4.2), it is important that bundle install support alternate platforms more extensively than with a naïve solution.

There are a few possible solutions:

  • Do not use --deployment on Heroku. This would allow bundler to update the Gemfile.lock for the new platform. It would also mean that if a developer didn’t update their Gemfile.lock before deploying, they might run unexpected code. This is a short-term fix, but would probably alleviate most of the symptoms without introducing a lot of new caveats.
  • Fix --deployment to allow changes to the Gemfile.lock, but only in response to a genuine platform change. Unfortunately, because of cases like Nokogiri 1.4.2, this could theoretically result in totally different code running in production.
  • Provide a mechanism for developers to explicitly add a deployment environment: bundle platform add x86_64-linux. This would pre-resolve gems across all available platforms and ensure that the same gem versions could be used everywhere.
  • Improve the bundler resolution mechanism to allow gems with the same name, version and dependencies to be treated the same. Because dependencies can also exhibit this problem (a dependency of some JRuby gem could be another JRuby gem with its own non-standard dependencies), this would need to ensure that the entire subtree was the same.

The last solution is most promising, because the platform-specific gems Tokaido is concerned with are simply precompiled variants of the same gem. In the vast majority of cases, this simply means that the gem author is saving the end-developer the step of using a C compiler, but doesn’t actually change a lot else.

Unfortunately, Rubygems itself doesn’t distinguish between precompiled variants of gems and gems with different dependencies, so we will have to add smarts into bundler to detect the difference. My guess is that we will use a short-term fix like the first option while working on a longer-term fix like the last option.

Work Time

As I said in the original Kickstarter, I planned to take time off from work to work on the project. I have structured that time by working mornings on Tokaido, and shifting client work to the afternoons and evenings.

I don’t have a specific ship-date in mind for Tokaido yet, but you should start seeing more work-product as the project progresses, starting over the next few weeks.

Thanks for your patience. It shall be rewarded!

Design of the Status Site

A couple months ago, we launched a completely redesigned Heroku status site. Since design is important to us and, we think, to many of you, we’re taking a break from our usual blog posts to dig into the Heroku approach to visual product design.

Read on to experience the twists and turns on the way to the final design and let us know in the comments if you want to see more posts like this.

Old Status Site

New Status Site

The Premise

For platform providers, a status site is a way to build trust with your customers, and in some cases, future customers. Heroku is no different. Our existing status site hadn’t been updated in over two years and was showing its age. We took this as an opportunity to go back to basics; drafting up user personas and goals. The previous status site was designed around the persona of a Heroku user checking to see if Heroku is working this very second. We realized there is an equally
important persona — a user or prospect trying to understand how reliable the platform is.

Of the many things we could improve, we focused on three primary areas:

  • Status is as much about uptime as it is downtime.

  • We wanted to increase transparency.

  • We needed to streamline the admin experience (which we won’t show here).

When it came time to start visual designs, we did some research to get a sense of existing solutions and user expectations. After some intensive brainstorming, we came up with the idea of a timeline.

A timeline felt like the perfect device for what we were trying to achieve. Not only does it show downtime and uptime in proportion to one another, but it includes a really key piece of information: time to resolution.

Prototype

It started as just a hypothesis, and we needed to test that hypothesis with real customers as quickly as possible. It’s easy to get tied down by visual design and lose focus on what really matters: the product. Instead of spending a lot of time in an image editor like Photoshop making the page look beautiful, we wanted a working prototype with real data from the get-go. Setting aside visual design and best practices, we created a simple Sinatra application using spaghetti code and inline styles, with read-only access to a live database:


First Prototype

We tested the first pass with our customer advisory board by inviting them to do a 5-minute OpenHallway user study. It was important to set the right expectations (and context) for this survey:

This prototype is not representative of final visuals.

OpenHallway allowed us to capture the screen and audio of our testers and follow alongside them as they explored the site. Incidentally, our first tests had way too many questions and instructions. Eventually we converged on five simple questions:

  • What are your first impressions?
  • Is it clear what the page is about?
  • Does it quickly convey the current platform status?
  • Does the page increase or decrease your trust in Heroku?
  • How does this site compare to the old status site?

We also added keyboard shortcuts so our testers could simulate outages and scheduled maintenance (‘o’ and ‘m’ if you want to follow along).

Mobile

When we reviewed the OpenHallway videos, we noticed a concerning trend; several people commented that there was "too much whitespace". We knew we had taken a risky approach with the timeline and wanted to make sure we weren’t committing too early to a design and ignoring actual user needs, so we (incorrectly) interpreted this to mean that the timeline wasn’t working.

In an effort to clear ourselves from an arbitrary commitment, we took a step back. Simplify the constraints. Think mobile. We asked ourselves what the status site would look like if we only had 320×480 pixels.


Mobile Prototype

Responsive

Following this promising direction, we created a fully-responsive version that would work for iPhones, iPads, and desktops. We added a little more information in this version; and even more information as you increased screen real estate. But in all these versions, the timeline was gone.


Responsive Prototype

This again looked promising, but it was hardcoded and no longer using live data, so we started wiring it up to live data. Then a surprising thing happened and we realized that the site completely failed to satisfy our first goal of visually conveying uptime as well as downtime. In fact, once we had live data in there, we realized that if 3 consecutive days had something minor happen, like a single shared database server offline that affected significantly less than 1% of our users, it looked like our entire platform was down for 72 hours straight! It was so bad, we knew it didn’t even deserve to go through customer validation.

Hybrid

In a last ditch effort to save the responsive design, we tried adding a timeline back into it.


Hybrid Prototype

At this point, the design had all of the "features" we needed. It showed a simple list view if you were on an iPhone, added a timeline for anything larger, and progressively added more information as the screen widened. It seemed like a design win, and fit with our new guiding principles of mobile-first and responsive design. Besides, it was fun to resize the screen and see it change! (Give it a try!)

There was only one problem: we didn’t like it. It’s hard to describe exactly why; it wasn’t clear enough, the emphasis was in the wrong place, the meta data (Affected, Scale, and Duration) was supposed to add value but seemed to distract from the overall site. Design had been replaced by detail.

Bezier

So we took another step back. We took what we had learned so far and re-applied it to our initial gut reaction — the timeline.


Bezier Prototype

We added some meta information (e.g. duration), but not all of it (e.g. scale). We realized the App Operations / Tools split was very important to our users, but didn’t go far enough. Too much counted as App Operations that had no impact on our paying customers, such as the unidling of 1-dyno free apps, or the free shared database offering. We thought about having one status light for each major component of our platform, such as routing or git push, but the complexity didn’t add enough value. We then toyed with the idea of splitting based on Production vs Development instead, and it turned out to be such a great fit that we split the timeline into two columns to show it.

By this time, we had already approached all of our customer advisory board and needed more fresh eyes to look at it, so we invited random beta users to do the OpenHallway studies. This time, the comments were different: we had a winner.

We called this version bezier because we intended on having bezier curves to join the incidents with their timeline markers. We didn’t get around to implementing them until later in the beta process, but when we did, it really brought the design together, simplifying a lot of hacks we put in place to handle overlapping incidents.

Here’s the JSFiddle sandbox we used to get the right shape for the curves. It’s not exactly how we implemented it, but it’s where we started, and just knowing it was feasible let us move on with the design.

Beta and Release

All of the designs above were intended as throwaways since they were prototypes solely designed to be validated with customers. But as sometimes happens, we got such great response from the last design, that we decided to go into beta with the design largely unchanged.


Status Beta

We’re happy with the final design; we use it internally and even have it up on a big screen in our office. But like anything we build, this is a perpetual work-in-progress. The new status site provides more value than the previous one, but we’re going to continue iterating and improving, so keep the feedback coming!

The Origin of Master Space and Time With JavaScript

I have a new book, Master Space and Time With JavaSript. You can buy it.

Here’s the secret origin.

This all started over a year ago. Rails Test Prescriptions had been complete for a few months, and I was getting a little antsy to take on a new project.

But what? I wanted it to be a project where I would learn something, and I wanted it to be something where I had a particular perspective to offer.

A couple of recent experiences pushed me toward view-level coding in general, and JavaScript in particular. About then, for the first time in a while, I worked on a project that had a reasonably serious JavaScript front-end on a team small enough that I was contributing some of the JavaScript.

It quickly became clear to me that JavaScript coding had changed dramatically, not just from my first pass at it (warning clients away from it circa 2000), or my second pass (avoiding it with RJS circa 2008). The tools were better, the idioms had changed, and the expectation was that future web applications would need to handle this stuff very well.

I was also working with a new Obtiva apprentice, who wanted to build a very JavaScript-heavy site, but didn’t really know much JavaScript. In searching for books to point him to, it seemed to me like there was an underserved part of the market, not for total beginners, not a description of a particular library, not a pronouncement from On High about The Right Way To Do Things, but a practical guide to writing and testing modern JavaScript to do cool stuff.

Which is what I set about to write. My original proposal for this book may well be one of the best pages of text I’ve ever written.

And yadda, yadda, yadda, here we are.

I knew I wanted the book to build up on a single web application example — I’ve always liked that style, even though it can be a pain in the neck to structure. I also knew that I wanted to have a lot of testing in the book. Not only is writing about testing in JavaScript something that seems pretty needed, it also felt like a perspective where I actually might have useful things to say. Plus, I had used the largely-test-first style of writing before (in the Wrox book), which I’m sure was appreciated by all three of the people who bought it. I thought I could do it again.

The idea of taking an application with no JavaScript and adding JavaScript features seemed like a good hook. I’d used the Time Travel Adventures travel agency before (for my testing legacy code workshop), and the idea of a time-traveling client who was confused about what modern web sites needed seemed like a suitably silly hook. (In the first draft, the client was named Emmett Brown, but I was guided away from using that name directly, hence the client becomes the mysterious Doctor What.)

And I was off…

Here’s what you get in the books.

Book 1 is largely concerned with a particular simple-seeming request: add a show/hide toggle link to each trip on the home page. Although this is simple, it actually winds up touching a fair amount of jQuery — using selectors to find elements, binding events, and manipulating element pieces.

We build up this toggle thing in a few stages. First is a quick pass writing a simple version of the toggle functionality test-first. The goal here is a sense of what a test-driven process looks like in JavaScript, plus the basics of how Jasmine and jQuery can be brought to bear to write the feature. It’s basically the book equivalent of “fast to green”. We solve the problem with the understanding that we’ll clean up the details later.

Then we go back with two more chapters that go more in-depth on first Jasmine, then jQuery. In these chapters, we don’t add new features as much as describe the library features that supported what we did and explore related functionality.

The final chapter of Part 1 covers the JavaScript object model and why it is confusing if you come to JavaScript from a more traditional Object-Oriented language. By the end of it, we’ve used the module pattern to build the most over-designed show/hide toggle ever. I’ve had some experience doing workshops based on the material in this chapter, and it seems like even people who have been doing JavaScript for a while get something new out of it.

And that’s Book 1. It’s available for the low, low price of zero dollars and zero cents. Worth every penny.

Book 2 is mostly about apply and extend. The first chapter is about building up an widget that combines an autocomplete text input with a list of currently chosen items. Test-first, of course. The we throw some Ajax in the mix, extending our already gold-plated toggler with the ability to get data from a server. This also gives us an excuse to talk about Jasmine spies. Finally, we build up a rating widget, with the clickable stars and a histogram and stuff, which lets us talk about JSON and Mustache. There’s also a small, slightly out of date bit on the Chrome developer tools. I’ll catch up on that at some point.

Book 2 is a mere $7.

Or you can get Books 1 & 2, Plus books 3 & 4 when they come out for $15. That $15 is a temporary price, and will go up when Book 3 gets closer to completion.

Book 3 is going to be about Backbone. I know the structure of most of it — first, we’ll recreate the front page using a Backbone structure. Next, we’ll build a buy page that allows you to make several calculations about differing trip purchase options on the client. Not sure about the last part, it will definitely include communicating back to the server, probably something else.

Book 3 is going to start appearing on the site in a couple of weeks, and will probably be draft complete by the end of September.

Book 4 will cover Ember.js. I’m not sure yet what we’ll build, though I want it to be a new part of the site, and not a recreation of the same things we do in Backbone. I’m hoping that Book 4 will be out by the end of 2012.

Oh — the title. I had a list of two word titles that were like POWERWORD JavaScript, but all of them were either taken, sounded ridiculously stentorian to me, or both. The original proposal titles were “Getting Things Done in JavaScript”, which nobody liked, or “JavaScript for People who Hate JavaScript”, which nobody liked (see the pattern).

I had Master Space and Time with JavaScript on my list as kind of a joke — a reference to the Time Travel conceit in the book. Plus I liked that it sounded like a pulp adventure novel, and would lend itself to a cover easily. I know it’s not the, like, SEO favorite title, but I’m hoping that people won’t forget it once they hear it.

The cover, by the way, is my own design, and I like it considerably more than many of the other things I’ve designed. (I’m also pretty happy with the PDF layout…) I think the cover particularly works well at thumbnail size, so you can see the difference between the individual books easily.

That’s the story. Hope you like it. Buy it!, or tell all your friends (Twitter hashtag #mstwjs).

Thanks.

August Tokaido Update

It’s been a while since I posted anything on my blog, and I figured I’d catch everyone up on the work I’ve been doing on Tokaido.

Components

Tokaido itself is made up of a number of components, which I am working on in parallel:

  • Ruby binary build, statically compiled
  • A logging and alerting UI
  • Remote Notifications for Rails 3+
  • Integration with Puma Express
  • Integration with code quality tools
  • Resolve bundler issue related to binary builds and deployment to Heroku
  • Work with community members to start shipping binary builds of popular gems (gates on fixing the bundler bug)

A number of people are doing parts of the work to make Tokaido a reality. I specifically want to thank:

August Tokaido Update

It’s been a while since I posted anything on my blog, and I figured I’d catch everyone up on the work I’ve been doing on Tokaido.

Components

Tokaido itself is made up of a number of components, which I am working on in parallel:

  • Ruby binary build, statically compiled
  • A logging and alerting UI
  • Remote Notifications for Rails 3+
  • Integration with Puma Express
  • Integration with code quality tools
  • Resolve bundler issue related to binary builds and deployment to Heroku
  • Work with community members to start shipping binary builds of popular gems (gates on fixing the bundler bug)

A number of people are doing parts of the work to make Tokaido a reality. I specifically want to thank:

A Mega Ruby News and Release Roundup for July 2012 in 97 Links

Welcome to the bumper pick’n’mix of Ruby and Rails news and releases for July 2012, fresh from the pages of Ruby Weekly (now at 15,400 subscribers – give it a look).

Highlights include: Rails 3.2.7, Phusion Passenger Enterprise, RubyMine 4.5, O’Reilly’s “Learning Rails 3”, GitHub’s funding, and Rails 4.0’s live streaming support.

Headlines

Phusion Passenger Enterprise Released
The chaps at Phusion have unveiled their latest release: Passenger Enterprise. Passenger is a popular Apache and Nginx module for deploying Ruby webapps and the ‘Enterprise’ variant includes rolling restarts, a live IRB console, and more.

Rails 3.2.7 Released
Contains an important security fix for apps using digest authentication from Action Pack. But 3.2.8 is just around the corner..

Phusion Shares A Sneak Peek of the Phusion Passenger 4.0 Roadmap
After a period of radio silence, the Phusion guys are back on the air! With their Passenger system being the most popular way to serve up Ruby apps, all eyes are on the forthcoming Passenger 4.0 and here they explain some of what’s coming up.

Edge Ruby/Ruby 2.0 Adds %i and %I To Notate An Array of Symbols
As %w and %W notates a string into an array of words, %i and %I does the same but into an array of symbols. Coming to an MRI near you.. eventually. Why not %s and %S? They’re already taken. In this case, the ‘i’ stands for intern/interned.

Now In Print: ‘Deploying Rails’ by Tom Copeland and Tony Burns
Make sure your next production deployment goes smoothly with this hands-on book, which guides you through the entire production process. Dives into Puppet, Capistrano, Vagrant, Nagios, Ganglia, and all that sort of devops-y stuff.

RubyMine 4.5 Released: JetBrains’ Commercial Ruby IDE
RubyMine 4.5 introduces suport for formatting and code insight for Slim and Sass, MacRuby syntax highlighting, Capistrano deployment support, extra Sinatra integration, and more. It’s a commercial IDE but the one I’ve heard the most good things about.

GitHub Takes $100m of Funding
The Ruby world celebrates its latest home grown business success, GitHub, who this week announced they’ve received $100m in funding from Andreessen Horowitz. Will every Rubyist eventually work there? Watch this space.

Code Climate (Metrics Service) Is Now Free for Open Source Projects
Code Climate is a hosted software metrics tool for Ruby apps and it’s now available to use for free on public open source projects.

RSpec 2.11 Released
The popular BDD framework takes another step up the version ladder with 2.11. It supports the new ‘named subject’ syntax, you can stub constants for the duration of an example, and on Rails specs now run in a random order by default. And more, naturally.

Reading

O’Reilly’s ‘Learning Rails 3’ Now in Print
Learning Rails 3 by Simon St. Laurent, Edd Dumbill, and Eric J Gruber takes an interesting ‘outside in’ approach to teaching Rails, well suited for front end developers looking to make the leap. There’s a free sampler PDF you can check out.

Is It Live? Rails 4.0 To Get ‘Live Streaming’ Support
Rails 4.0 will be getting real-time data streaming support as it’s just been baked into rails-edge. Aaron Patterson shows it off in this post (yep, you can play with it now!)

Florian Hanke Benchmarks Unicorn, Thin and Ricer
In trying to make his Picky semantic search engine tool faster, Florian Hanke has tried to find the fastest Ruby Web daemon for his uses.

Getting Your Heart Rate Using R and Ruby
A fun post looking at marrying up R and Ruby to tell your heart rate from a small bit of video.

Ruby Constructs: Classes, Modules and Mixins
LivingSocial’s Matt Aimonetti clears up some concepts and misconceptions around classes, modules and mixins and how you should or shouldn’t use them.

Your First Ruby Native Extension: C
A quick how-to from someone who admittedly ‘knows barely any C or Java’ that explains how to wire up some simple C code into a native Ruby extension ready for building a gem.

Objects, Classes and Modules
The latest excerpt from Pat Shaughnessy’s forthcoming ‘Ruby Under A Microscope’ book. This time he looks at how MRI Ruby implements and stores objects and classes internally.

The Hitchhiker’s Guide to Riding a Mountain Lion
Apple’s latest operating system dropped yesterday and Prem Sichanugrist of Thoughtbot shares some insights into the upgrade process for Rubyists.

Building An API for Fun With Grape
Grape is an API-oriented Rack-based microframework for building HTTP accessible APIs. It’s been around a while but this post gives a quick introduction.

Tell, Don’t Ask (with Ruby Objects)
Bad for your relationships but good object oriented programming advice. Ben Orenstein shows off some quick before and after examples of telling your objects what to do rather than querying them to make decisions.

Rails, Objects, Tests, and Other Useful Things
Noel Rappin reflects on the various ‘Object-Oriented Rails’ and ‘fast tests’ discussions going around the Ruby world as of late.

Why I Don’t Like factory_girl
This post won’t be without controversy but Steve Klabnik outlines why he thinks the convenience of factories has ‘set Rails testing strategies and software design back two years.’ Worth a read even if you disagree.

Advanced Caching in Rails: Revised (for 2012)
Adam Hawkins has recently updated his series of Rails caching posts. It aims to teach you everything you need to know to work with any different caching level inside your Rails app.

Zendesk’s Road to Ruby 1.9
Zendesk is a popular help desk app and their dev team explains how their Ruby 1.9 upgrade project went. The end result? A 2-3x improvement in response time for their app.

Processing Images with CarrierWave
An entry level tutorial to managing uploaded files in a Rails app using CarrierWave.

Four Guidelines That I Feel Have Improved My Code
GitHub’s John Nunemaker riffs on some interesting ideas he’s brought into his Ruby development practices including the single responsibility principle, sensible interface design and high/low testing.

Streaming Zlib Processing for Ruby (in Ruby Core/2.0)
Eric Hodel has checked in a patch that adds streaming zlib processing to Ruby core. Why’s this a big deal? For starters, significant memory savings when compressing large files.

Arel’s ‘merge’ Method: A Hidden Gem
Arel is the beautiful relational algebra library that works alongside ActiveRecord in Rails 3 to let you do complex queries easily. Ben Hoskings shows off an interesting method Arel makes available to merge query conditions together.

Case Study: Using Ruby Tools for Non-Ruby Projects
A look at using Ruby tools (like Bundler and Guard) to automate common Web development workflows.

Don’t Make Your Code ‘More Testable’
Gregory Moeck reflects on the mocking and OO design trends in the Ruby world and proposes a way forward to think about the ‘testability’ of our code (or not, as the case may be).

RubyMotion Tutorials: A Resource Site
A simple resources site aiming to collect together links relevant to learning or working with RubyMotion.

How Can I Contribute to Ruby On Rails?
Steve Klabnik, now a memeber of the Rails Issue Team, shares some quite insights and FAQs into the process of contributing ideas, source, or documentation to Rails.

Functional View and Controller Testing with RubyMotion
RubyMotion (the Ruby toolkit for building iOS apps) now features a new testing layer that lets you write functional specifications for the views and controllers of your apps.

My Favorite Bundler Feature
Jerod Santo loves being able to crack open his gems.

The History of Ruby in Version Numbers
A simple GitHub gist showing what versions of MRI Ruby were released when.

Watching and Listening

Active Record Deep Dive (in 11 Short Videos)
Richard Schneeman explains ActiveRecord’s query interface in several short screencasts. You’re bound to pick something up.

Using MiniProfiler with Rails (RailsCasts)
MiniProfiler allows you to see the speed of a request conveniently on the page. Ryan Bates shows off its usage with Rails.

Making a Rails App Fast and Scalable
Slide deck for a talk given by Richard Schneeman on making a Rails App fast and scalable.

PeepCode’s Rails 3 Play by Play with Yehuda Katz
PeepCode has released the latest in their ‘look over a developer’s shoulder’ screencast series, this time focusing on Yehuda Katz (of Rails 3 fame). In an 80 minute session, he builds the backend for a scoring system using Rails 3.

Five Things You Didn’t Know Your Documentation Tool Could Do
Loren Segal, the creator of Ruby documentation tool YARD, looks at some of YARD’s lesser known features and shows off ways to visualize your code, get basic code metrics, and ensure overall quality in your documentation.

The Well Grounded Nuby
At Boston Ruby Group recently, David A Black (of Well Grounded Rubyist fame) gave a talk about getting the fundamentals of Ruby right.

Sidekiq (RailsCasts)
Sidekiq allows you to move jobs into the background for asynchronous processing. It uses threads instead of forks so it’s more memory efficient than, say, Resque.

Your Face in 10 Minutes… with MacRuby!
At GoRuCo 2012, Haris Amin gave a 10 minute lightning talk about creating a desktop Mac face detection/recognition app with MacRuby. Links to code, slides, and the Vimeo video within.

An ActiveRecord-Based Reputation System (RailsCasts)
If you need to calculate an average user’s rating or sum up a number of votes, consider using the ‘activerecord-reputation-system’ gem. Here Ryan Bates covers the basics and presents a from-scratch solution.

Libraries and Code

Synack: Send Messages to OS X Mountain Lion’s Notification Center
A client/server wrapper for terminal-notifier that allows arbitrary messages to be sent to OS X 10.8’s Notification Center.

Ricer: Fast Rack-Compliant Ruby Web Server Written in C
Unfortunately named but claims to be faster than Thin and Unicorn.

TwitterCLDR: Improving Internationalization Support in Ruby
Twitter’s engineering team has released a library that uses Unicode’s Common Locale Data Repository (CLDR) to format certain types of text into their localized equivalents. Currently supported types of text include dates, times, currencies, decimals, percentages, and symbols.

Clean Tests: Sugar for Making Test::Unit Tests Clearer
Dave Copeland’s Clean Tests aims to bring clarity to Test::Unit tests and provides a Given/When/Then structure for clarifying intent.

Brakeman 1.7.0 Released: The Rails Security Scanner
Adds support for a recent HTTP digest auth vulnerability and includes numerous improvements.

RLTK: Ruby Language Toolkit
A collection of classes and methods designed to help programmers work with languages in an easy to use and straightforward manner. Includes generators for lexers and parsers, LLVM bindings, and more.

Graphene: Stats and Graphs From Collections Of Ruby Objects
A new Ruby gem for transforming collections of Ruby objects into subtotals, percentages, tables and graphs.

Stamp: Format Dates and Times Using Human-Readable Examples
Sick of arcane strftime formatting? Give Stamp an ‘example’ of a date format you want and it’ll dish up a similar date or time for you. Not new but somehow I missed it till now!

csv_shaper: DSL for Creating CSV Output
CSV Shaper claims to make the painful world of CSV rendering and formatting easier. Supports both pure Ruby and Rails.

Sex Machine: Get Gender from First Name
This unfortunately named gem leans on a open source name-to-gender tool to give similar functionality to Rubyists.

classy_enum: Class Based Enumerator Gem for Rails
Adds class-based enumerator functionality to ActiveRecord attributes.

Rubyception: A Realtime Rails Log in Your Browser
Add Rubyception to your Rails project, navigate to /rubyception and get WebSocket-powered live log updates.

Axlsx: Office Open XML Spreadsheet Generation Library
Complete xlsx generation with support for charts, images, automated column width, customizable styles and full schema validation.

Announcing minitest-rails: Extra MiniTest Support for Rails
minitest-rails is a library that enables you to test your Rails 3 apps using minitest, the testing framework that comes in the Ruby 1.9 standard library. Documentation and a short introductory screencast included.

webmachine-ruby 1.0 Released
webmachine-ruby is a Ruby port of Erlang’s Webmachine which lets Rubyists expose interesting parts of the HTTP protocol to their applications in a declarative way. Don’t understand? Check the examples.

Jim Weirich’s Approach to ‘Programming with Nothing’
1800 lines of a cold and lonely place. Intense.

Jobs

Senior Software Engineer (Ruby) at FreeAgent [Edinburgh, Scotland]
FreeAgent are looking for a talented and passionate software engineer to join their engineering team in a senior capacity to work on their popular online accounting software.

Software Engineer at Webdoc SA [Switzerland]
You’ll join the team that develops Webdoc (a rich media sharing site) and work across the stack – Rails, MongoDB, mySQL and JavaScript.

Happy (Ruby) Web Developer (London, UK)
We sell expensive stuff to investment bankers. We run on Ruby. We enjoy using the best tools and technologies available. If you want to be a happy programmer (and join us on our summer trip to Ibiza), get started by solving our quiz.

Senior Ruby on Rails Developer (Cologne, Germany)
“Ich will nicht nach Berlin!”- simfy cologne is looking for talented Ruby on Rails backend developers. You feel at home with large Rails enterprise applications? Join simfy – one of the world’s leading music streaming services – and put our visions to life.

Senior Ruby Developer (Cambridge, MA)
Litmus, the e-mail testing and analytics company, offers a great salary, full health care benefits, 28 days paid vacation, beer fridge and Sonos sound system. They’ll also buy you lunch every day.

Last but not least..

AdhearsionConf Returns for 2012: CFP Now Open
Billing itself as the ‘conference at the Intersection Of Ruby and Voice’, the AdhearsionConf organizers have announced the conference will be back on October 20-21 in Palo Alto. No registration yet but the call for presentations is now open.

MiniProfiler: A New Profiler for Ruby
MiniProfiler is a production and development profiler that you can use to quickly isolate performance bottlenecks, both on the server and client. This post demonstrates how it works.

Writing FizzBuzz Without Modulus Division
Upon a request by JEG2, some Rubyists had a go at solving the old FizzBuzz problem without doing modulus division. This entry by Magnus Holm is a real mindbender and leans heavily on flip flops.

#370 Ransack

Ransack allows you to easily build complex search forms. It also helps in adding sortable links and building a dynamic advanced search page.