April 18, 2014

O'Reilly RubyRails 4 Application Development HOTSHOT

O'Reilly Media, Inc. @ 2014/04/18 03:00 PM

In Detail

Rails is a rapidly moving, open source, web development framework, and keeping up to speed with it is a big task. You might have already built applications using it, but there have been significant changes in the syntax and semantic of the Rails framework in the latest upgrade. Upgrading applications needs an approach that not only helps the upgrade, but also helps to improve on what has already been built, so that it performs even better.

Presenting a practical approach to upgrading your knowledge for Rails 4, this guide shows you how to build the most popular types of applications using Rails 4, and highlights new ways to do things. The book also closely follows lots of the best practices, gems, and popular solutions already known to the community, and tracks the changes in these based on Version 4 of Rails. This book brings new ideas to refactor and restructure code to make it perform better in production, and enables you to write production-ready code.

The book starts off with relatively simple application, demonstrating the new application structure, the testing framework, and several day-to-day tasks. The complexity of applications will increase with each chapter.

In the first half of the book, you will learn to build a recipe sharing website, a conference and RSVP management application, an online Pinboard similar to Pinterest, a SaaS-based application, and a customizable content management system demonstrating concepts. In the later half, you will get to know MongoDB by building an analytics dashboard using MongoDB and Rails. You will also create a mash-up of some common APIs such as Google Maps and Twitter and make them work with one another. One of the new features we will look at in this book is an API-only application with no frontend. At the end of the book, you will learn how to use HTML5 concepts to your advantage and extend the Rails framework with reusable engines.

This book is designed to update, upgrade, and improve your knowledge of Rails 4, as well as your applications.


Attractive practical projects to polish your application building skills, through a straightforward, highly focused and interesting approach towards application development.

Who this book is for

If you are a developer who is already familiar with the basics of the Rails framework and have previously worked with Rails 3.2 or earlier, then this is the ideal book for you. It is assumed that you have some prior experience with the development of applications. This book will help you to upgrade your existing knowledge and also ensure its applicability. You will be expected to setup Rails, MySQL / PostgreSQL, Mongodb and required dependencies themselves.

March 26, 2014

O'Reilly RubyCustomizing Chef

O'Reilly Media, Inc. @ 2014/03/26 03:28 PM

Learn how to customize Chef by examining the internal structure this configuration management tool and navigating its source code. This practical book also shows you how to integrate external tooling with Chef via the API, and takes a look at more advanced customization. By the time you finish this book, you'll have a thorough understanding of how Chef fits together and be able to position your customization in the most appropriate place.

December 19, 2013

O'Reilly RubyLearning Mongoid

O'Reilly Media, Inc. @ 2013/12/19 08:30 PM

In Detail

Mongoid helps you to leverage the power of schema-less and efficient document-based design, dynamic queries, and atomic modifier operations. Mongoid eases the work of Ruby developers while they are working on complex frameworks.

Starting with why and how you should use Mongoid, this book covers the various components of Mongoid. It then delves deeper into the detail of queries and relations, and you will learn some tips and tricks on improving performance. With this book, you will be able to build robust and large-scale web applications with Mongoid and Rails.

Starting with the basics, this book introduces you to components such as moped and origin, and how information is managed, learn about the various datatypes, embedded documents, arrays, and hashes. You will learn how a document is stored and manipulated with callbacks, validations, and even atomic updates. This book will then show you the querying mechanism in detail, right from simple to complex queries, and even explains eager loading, lazy evaluation, and chaining of queries. Finally, this book will explain the importance of performance tuning and how to use the right indexes. It also explains MapReduce and the Aggregation Framework.


A step-by-step tutorial with focused examples that will help you build scalable, high performance Rails web applications with Mongoid.

Who this book is for

If you are an application developer who wants to learn how to use Mongoid in a Rails application, this book will be great for you. You are expected to be familiar with MongoDB and Ruby.

November 16, 2013

O'Reilly RubyCrafting Rails 4 Applications

José Valim @ 2013/11/16 05:32 AM

Get ready to see Rails as you've never seen it before. Learn how to extend the framework, change its behavior, and replace whole components to bend it to your will. Eight different test-driven tutorials will help you understand Rails' inner workings and prepare you to tackle complicated projects with solutions that are well-tested, modular, and easy to maintain.

This second edition of the bestselling Crafting Rails Applications has been updated to Rails 4 and discusses new topics such as streaming, mountable engines, and thread safety.

Rails is one of the most extensible frameworks out there. This pioneering book deep-dives into the Rails plugin APIs and shows you, the intermediate Rails developer, how to use them to write better web applications and make your day-to-day work with Rails more productive.

Rails Core developer Jose Valim guides you through eight different tutorials, each using test-driven development to build a new Rails plugin or application that solves common problems with these APIs. You'll learn how the Rails rendering stack works and customize it to read templates from the database while you discover how to mimic Active Record behavior, such as validations, in any other object. You'll find out how Rails integrates with Rack, the different ways to stream data from your web application, and how to mix Rails engines and Sinatra applications into your Rails apps, so you can choose the most appropriate tool for the job. In addition, you'll improve your productivity by customizing generators and responders.

This book will help you understand Rails' inner workings, including generators, template handlers, internationalization, routing, and responders. With the knowledge you'll gain, you'll create well-tested, modular, and robust solutions for your next project.

O'Reilly RubyBuild Awesome Command-Line Applications in Ruby 2

O'Reilly Media, Inc. @ 2013/11/16 05:31 AM

Speak directly to your system. With its simple commands, flags, and parameters, a well-formed command-line application is the quickest way to automate a backup, a build, or a deployment and simplify your life. With this book, you'll learn specific ways to write command-line applications that are easy to use, deploy, and maintain, using a set of clear best practices and the Ruby programming language. This book is designed to make any programmer or system administrator more productive in their job. Now updated for Ruby 2.

November 13, 2013

O'Reilly RubyRuby Under a Microscope

O'Reilly Media, Inc. @ 2013/11/13 07:33 AM

Ruby Under a Microscope gives developers an inside, hands-on look at Ruby's core, using simple diagrams coupled with clear explanations.

October 24, 2013

Ryan Davis9000 Commits

2013/10/24 07:00 PM

I just committed the 9000th commit to my perforce repo. Woot!

% p4 counter change

Time between 1000s. You can see some burnout/slowdown between 2009-06 to 2012-02, but it’s been maintaining >1000 per year since then.

% p4 changes | grep "Change .000" | cut -f4 -d\   | ruby -rdate -e 'puts $stdin.read.lines.map { |s| Date.parse s }.each_cons(2).map { |a, b| [a, (a - b).to_i].join " " }'
2013-10-24 335
2012-11-23 294
2012-02-03 436
2010-11-24 540
2009-06-02 358
2008-06-09 489
2007-02-06 655
2005-04-22 1065

Granted, # of commits or commits / day is a stupid metric to follow if you’re trying to measure productivity… but since I’m not trying to game my own system, this ain’t bad.

October 18, 2013

Ryan DavisTime Machine Repair

2013/10/18 07:00 PM

Turn off time machine on all involved parties, then:

% sudo chflags -R nouchg /Volumes/tmgreed/greed.sparsebundle
% sudo emacs -q -nw /Volumes/tmgreed/greed.sparsebundle/com.apple.TimeMachine.MachineID.plist

  # Setting VerificationState to 0 and removing RecoveryBackupDeclinedDate

% sudo hdiutil attach -nomount -noverify -noautofsck -readwrite /Volumes/tmgreed/greed.sparsebundle
% tail -f /var/log/fsck_hfs.log

  # wait for regular check to finish... if it passes, go for it, otherwise:

% sudo fsck_hfs -drfy /dev/diskXs2

  # once you're done:

% hdiutil detach  /dev/diskXs2

For me, everything fixed itself so I was able to skip the last step.

From: http://www.garth.org/archives/2010,07,16,124,fixing-time-machine-sparsebundle-network-backup-errors.html

October 15, 2013

Ryan DavisHappy Birfday to me!

2013/10/15 10:04 PM

Today is my Thirteen Year Anniversary with Ruby! Yay!

780 gem releases (up by 150), 8982 commits (up by 1146), and bazillions of test runs later, and I’m still going strong. Rawr!

October 08, 2013

O'Reilly RubyRubyMotion

O'Reilly Media, Inc. @ 2013/10/08 09:35 PM

Make beautiful apps with beautiful code: use the elegant and concise Ruby programming language with RubyMotion to write truly native iOS apps with less code while having more fun. You'll learn the essentials of creating great apps, and by the end of this book, you'll have built a fully functional API-driven app. Whether you're a newcomer looking for an alternative to Objective-C or a hardened Rails veteran, RubyMotion allows you to create gorgeous apps with no compromise in performance or developer happiness.

October 02, 2013

O'Reilly RubyAgile Web Development with Rails 4

Rails just keeps on changing. Both Rails 3 and 4, as well as Ruby 1.9 and 2.0, bring hundreds of improvements, including new APIs and substantial performance enhancements. The fourth edition of this award-winning classic has been reorganized and refocused so it's more useful than ever before for developers new to Ruby and Rails.

Rails 4 introduces a number of user-facing changes, and the ebook has been updated to match all the latest changes and new best practices in Rails. This includes full support for Ruby 2.0, controller concerns, Russian Doll caching, strong parameters, Turbolinks, new test and bin directory layouts, and much more.

August 13, 2013

O'Reilly RubyJump Start Rails

O'Reilly Media, Inc. @ 2013/08/13 04:36 AM

Jump Start Rails provides you with a fun and yet practical introduction to Rails, an incredibly popular framework that makes it possible to quickly develop incredibly powerful web applications with Ruby. This short book covers Rails 4, the latest version of the framework, and while it's not intended to be a completely comprehensive Rails guide or an in-depth Ruby tutorial, it will quickly get you up to speed with Rails and give you the confidence to start experimenting on your own.

The book is built around a real-life example project: a personal portfolio site. It's a fun and easily understandable project that is used to demonstrate the concepts outlined in the book in a practical way.

This is a clear, approachable and very easy-to-follow book that will get you to to speed with Rails in no time.

July 31, 2013

O'Reilly RubyFour short links: 31 July 2013

Nat Torkington @ 2013/07/31 12:39 PM
How to Easily Resize and Cache Images for the Mobile Web (Pete Warden) — I set up a server running the excellent ImageProxy open-source project, and then I placed a Cloudfront CDN in front of it to cache the results. …

July 30, 2013

Ryan DavisTriage Applescript for OmniFocus

2013/07/30 07:00 PM

I have a bunch of omnifocus tasks that tell me to go review my projects’ issue trackers. Each one has a note with a url in it that is hyperlinked. Unfortunately, omnifocus doesn’t let you cmd-click the url to open in the background. It’s incredibly aggravating that you have to flip back and forth between safari and omnifocus over and over. It is even worse when you do it across spaces (I always have omnifocus fullscreened).

I wrote this applescript (blech) because I couldn’t take it anymore and omnigroup has ignored my bug report for 2+ years now. All it does is go through each task in the current window and open a new Safari tab for each note that starts with “http”.

I hope it helps bring sanity to someone else.

tell application "Safari"
	tell application "OmniFocus"
		set urls to note of value of leaves of content of window 1
	end tell
	make new document
	repeat with aUrl in urls
		if aUrl starts with "http" then
			make new tab at end of window 1 with properties {URL:aUrl}
		end if
	end repeat
	delete tab 1 of window 1
end tell

I have this in the script menu titled “Triage”. Enjoy

July 25, 2013

Ruby InsideThis Month in Ruby: PeepCode Acquired, Rails 3.2.14, And More

Peter Cooper @ 2013/07/25 08:16 PM

Welcome to a roundup of Ruby news, articles, videos, and more, for July 2013 cobbled together from my e-mail newsletter, Ruby Weekly.

Highlights include: PeepCode acquired by Pluralsight, Practicing Ruby archives made public, Rails 3.2.14, and an interesting interview with Matz.


The First Four Volumes of Practicing Ruby, Now Available Online
Practicing Ruby is a high quality, paid Ruby journal run by Gregory Brown, but he's made archives of over 60 articles available to the public. There's a ton of stuff to enjoy here.

PeepCode Acquired by Pluralsight
Ruby and Rails screencasting pioneer Geoffrey Grosenbach has announced he has sold Peepcode to Pluralsight, a large online training provider.

The Plan for RSpec 3
RSpec 2.0 was released in October 2010 and RSpec 2.14 will be the last RSpec 2 feature release. Work on RSpec 3 has begun and Myron Marston shares what's going to be involved.

Rails 3.2.14 RC1 and RC2 Released
A variety of bug fixes for Rails 3.2 arrived in 3.2.14 RC1 with one minor regression fixed in RC2. Final due soon.

The Future of Computing - An Interview with Matz
Last year, Ruby's creator Yukihiro 'Matz' Matsumoto released a book called The Future of Computing (only in Japanese, I believe) and did an interview with a Chinese publisher. Fred Wu has translated it into English.

RSpec 2.14 Released
Myron Marston unveils the last 2.x feature release of the popular spec framework and announces work is well underway for the future RSpec 3. 2.14 includes a new feature called 'spies' which is shown off here.

Functional Programming and Ruby
At GoRuCo 2013, Pat Shaughnessy gave a 40 minute talk comparing Haskell (a functional language) to Ruby and looked at how to implement common functional patterns in Ruby. Well explained and backed by good slides.


Streaming with Rails 4
Saurabh Bhatia looks at Rails 4's support for live streaming (the ability to send partial requests out to the client on the fly).

Reading the Ruby Source to Understand Rails Idiosyncrasies
I'm not sure you always need to dig quite so deep but Eno Compton takes an interesting journey through MRI's source code to see the difference between Range#cover? and Range#include?

Speed Up Heroku Deploys
Alex MacCaw was suffering from slow deploys to Heroku but he found a workaround.

Shoes 4 – A Progress Report
Shoes was a graphical toolkit put together by Why the Lucky Stiff that made it simple to create GUI apps in Ruby. Since Why disappeared, others have picked up work on it, and Shoes 4 is set to be a complete rewrite.

Put Yourself on Rails with A Push of A Button
A technique for quickly bringing up a workspace for doing Rails work (including terminals, a Rails console, a Rails server, etc.)

Multitenancy with Rails: An E-book by Ryan Bigg
Ryan Bigg, of Rails in Action fame, is writing an e-book about building a multi-tenanted Rails app.

Incremental Redesign with Rails
Lars Klevan shows how to use prepend_view_path to make in-progress redesigns on a production codebase simpler.

How to Declutter Your 'lib' Directory
If you have an established Rails project, its 'lib' folder might be getting a little full. Kuba Suder looks at ways to clean it up and put things elsewhere.

Design Patterns: The Template Method Pattern
An introductory Ruby-oriented look at arguably the simplest design pattern.

Object Oriented Rails: Writing Better Controllers
Damien Le Berrigaud of Pivotal Labs tries to avoid stubs and mocks and leans on dependency injection to test his controllers' code.

Vimscript And You
HashRocket's Jonathan Jackson demonstrates how you can use RSpec against Vim to aid in the development of a Vim plugin with Vimscript.

MotionPhrase: Next Level Localization for RubyMotion Applications
PhraseApp is a translation management tool for producing multilingual Web sites, Rails apps, etc, but it also works for localizing RubyMotion apps too, as demonstrated here.

Ruby's Eigenclasses Demystified
Andrea Singh looks at Ruby's quirky 'eigenclasses' (a.k.a. metaclasses) and explains things in both code and diagrams. Dates from 2011 but worth revisiting.

The Self-Pipe Trick Explained
Jesse Storimer shows off a cute Unix trick/technique in Ruby.

Practical RSpec Wrapping
Why would you want to use around hooks in RSpec? Dru Riley explains.

Using PostgreSQL's 'hstore' in A Rails Application on Engine Yard Cloud
If you want to take advantage of schemaless features without abandoning your relational database, using 'hstore' within Postgres is a great option. Here's an introduction on using the hstore PostgreSQL extension in a Rails app.

Implementing Subdomain and Custom Domain Support in Rails
A look at how one development team implement subdomain and custom domain features in their Rails app.


dotRB: The Largest Ruby Conference in France (October 18, Paris)
Following on from a successful 'dotJS' JavaScript event comes dotRB. Announced speakers so far include Steve Klabnik, Konstantin Haase, and Brian Ford.


11 Talks from La Conf Paris
Some big names to enjoy here including Yehuda Katz, Amy Hoy, Sandi Metz, and Steve Klabnik.

Deathmatch: Bundler vs Rubygems.org
At GoRuCo 2013, Andre Arko told the story of the quest to make 'bundle install' faster.

How to Set Up RSpec
A well produced 6 minute screencast.

To Know A Garbage Collector
Mike Bernstein discusses his experiments with MRI Ruby's garbage collector, his investigations into other languages and the influence of their GC implementations, the history of the subject, and more.

Kata and Analysis with Jim Weirich
From RubyConf India 2013 comes a live coding session by the inimitable Jim Weirich where he walks through the popular 'roman numeral' conversion kata using TDD along the way.

Aaron 'tenderlove' Patterson's RubyConf India 2013 Keynote
An hour with Ruby and Rails core contributor Aaron 'tenderlove' Patterson covering esoteric Ruby stuff and Postgres to career advice and cats. Warning: The audio is rather poor here and cuts out entirely for the second half so don't waste your time if this will drive you crazy.

5 Minutes of EuRuKo 2013
European Ruby conference (EuRuKo) took place in Athens last month and Clemens Helm has put together a 5 minute collection of clips and insights from the event. Includes Matz, Xavier Noria, Benjamin Smith, Pat Shaughnessy and Steve Klabnik.

Nokogiri: History and Future
Nokogiri is the most popular way to parse and process XML in Ruby and at GoRuCo 2013, Mike Dalessio gave a short 11 minute talk on the origins of the project, how to determine if it suits you, and looks at some of the tooling around it.

Libraries, Code and Tools

Upton: A Web Scraping Framework
A Ruby-based web-scraping framework that abstracts away the common parts of web scraping so developers can concentrate on the unique parts of their project.

LanguageFilter: Detect and Optionally Filter Multiple Categories of Language
Wave goodbye to sex, hatred, profanity, violence, etc, in your app.

Lita: A Ruby Chat Bot with Redis-based Storage
Can be twisted to work with any chat service and extended with plugins.

Pkgr: Make A Debian Package Out of A Rails App in 5 Minutes
A high-level tool that turns Rails applications into native Debian packages.

Flynn - Open Source Platform As A Service, Powered by Docker
Flynn is an as-yet-unreleased Heroku-inspired system to simplify deploying and maintaining apps. Instead of using complex config management systems, Flynn allows self-serve management of containerized deployments. The creator is currently trying to raise money to work on the project.


Software Craftsperson at Bendyworks
If you're the type of person who learns new languages as a matter of course, contributes to open source for fun, and ships code with a calm and collected professionalism: you seem like our kind of developer. Join our world-class team in Madison, Wisconsin.

Senior backend- / API-developer at Rabble (Stockholm, Sweden)
Tired of bullshit ads? Help us develop Sweden's leading app for mobile offers, where customers and businesses meet on equal terms! Join us in the heart of Stockholm to play with geospatial data and Ruby API's all day long!

Ruby on Rails developer at SupaDupa (London, UK)
We're looking for an experienced Ruby on Rails developer to join the small team behind SupaDupa.me, an e-commerce platform aimed at creatives. Excited about the challenge of working on the full stack, from front-end dev to system administration? Get in touch!

Ruby Programmer: IT and System Automation
Want to change the future of education? We are trying to build an awesome team that enjoys challenges and results. Interested? Come work with us in beautiful Switzerland.

Ruby Developers at HouseTrip (London, UK)
Want to work with a 18-person team of passionate Ruby developers who love good code and care for their product in central London? We are currently hiring. Ranked by Wired Magazine the number two start-up in London (2012), HouseTrip is Europe’s largest holiday rental booking website!

Last but not least..

ruby -run -e httpd . -p5000
Run a local HTTP server with a single line of Ruby. Just one character longer than the classic python -m SimpleHTTPServer but more obviously flexible (plus, it's Ruby ;-)).

July 17, 2013

Ryan DavisMy Emacs Setup, pt 8: Ruby and Outline

2013/07/17 07:00 PM

This is part 8 of My Emacs Setup.

I’ve got a bitch of a file I have to maintain. One of the methods is ~650 lines long. It flogs out at 1200 (industry average for non-rails methods is ~10). It is horrible but there is little-to-nothing that I can do in ruby to make it better. No, the refactoring mantra isn’t applicable here… That’s an argument for another day.

The point is, it is huge and I have to maintain / understand / navigate it. Emacs has a bunch of tools to index files and jump around to definitions and the like, but this is inside one method so they don’t help. Emacs also has a ton of various outlining tools, but none of them work with ruby because ruby’s syntax is a serious PITA. I may have finally found a compromise that works well enough.

Add this to your enh-ruby-mode or ruby-mode hook:

(defun ruby-outline-level ()
  (or (and (match-string 1)
           (or (cdr (assoc (match-string 1) outline-heading-alist))
               (- (match-end 1) (match-beginning 1))))
      (cdr (assoc (match-string 0) outline-heading-alist))
      (- (match-end 0) (match-beginning 0))))

(set (make-local-variable 'outline-level) 'ruby-outline-level)

(set (make-local-variable 'outline-regexp)
     (rx (group (* " "))
         (or "begin" "case" "class" "def" "else" "elsif" "end"
             "ensure" "if" "module" "rescue" "when" "unless")


Then add this to your outline-minor-mode hook:

(require 'outline-magic)

(defun outline-cycle-fast ()
  "Emulates 2 hits of outline-cycle, giving me what I want to see 90% of the time"

  (setq this-command 'outline-cycle-children))

(let ((map outline-minor-mode-map))
  (define-key map (kbd "M-o M-o") 'outline-cycle)
  (define-key map (kbd "M-o o")   'outline-cycle-fast))

Now you can go to the top of a huge if/elseif/else block and hit M-o o and it’ll collapse to the top level items, which is a lot more navigable for me than a raw 650 line method. Now I can drill down individual branches and only expand (using M-o M-o) the subsection I want to see at the time. Now it looks like:

    loop do # START OF CASE
      if src.scan(/[\ \t\r\f\v]/) then # \s - \n + \v
        self.space_seen = true
      elsif src.check(/[^a-zA-Z]/) then
        if src.scan(/\n|#/) then...
        elsif src.scan(/[\]\)\}]/) then...
        elsif src.scan(/\!/) then...
        elsif src.scan(/\.\.\.?|,|![=~]?/) then...
        elsif src.check(/\./) then...
        elsif src.scan(/\(/) then...
        elsif src.check(/\=/) then...
        elsif src.scan(/\"(#{ESC_RE}|#(#{ESC_RE}|[^\{\#\@\$\"\\])|[^\"\\\#])*\"/o) then...
        elsif src.scan(/\"/) then # FALLBACK...
        elsif src.scan(/\@\@?#{IDENT_CHAR_RE}+/o) then...
        elsif src.scan(/\:\:/) then...
        elsif ! is_end? && src.scan(/:([a-zA-Z_]#{IDENT_CHAR_RE}*(?:[?!]|=(?==>)|=(?![=>]))?)/) then...
        elsif src.scan(/\:/) then...
        elsif src.check(/[0-9]/) then...
        elsif src.scan(/\[/) then...
        elsif src.scan(/\'(\\.|[^\'])*\'/) then...
        elsif src.check(/\|/) then...
        elsif src.scan(/\{/) then...
        elsif src.scan(/->/) then...
        elsif src.scan(/[+-]/) then...
        elsif src.check(/\*/) then...
        elsif src.check(/\</) then...
        elsif src.check(/\>/) then...
        elsif src.scan(/\`/) then...
        elsif src.scan(/\?/) then...
        elsif src.check(/\&/) then...
        elsif src.scan(/\//) then...
        elsif src.scan(/\^=/) then...
        elsif src.scan(/\^/) then...
        elsif src.scan(/\;/) then...
        elsif src.scan(/\~/) then...
        elsif src.scan(/\\/) then...
        elsif src.scan(/\%/) then...
        elsif src.check(/\$/) then...
        elsif src.check(/\_/) then...
      end # END OF CASE

July 11, 2013

Ryan DavisMy Emacs Setup, pt 7: Q & A (1)

2013/07/11 07:00 PM

This is part 7 of My Emacs Setup.

In my last post I asked for suggestions on what to blog about next. I got some questions that I thought were interesting so I’m answering them here:

JEG asks:

I have a ton of specific questions. Here are just a few:

Awesome! Keep throwing them at me.

  • Do you use emacserver and emacsclient?

I certainly have in the past, I pretty much don’t nowadays. This is mostly because I run almost all of my shells within emacs, making emacsclient (mostly) unnecessary. Open prompts are relative to the current directory of whatever buffer you’re in (including shells) and you can open globs, so rather than doing emacsclient lib/*.rb I can just type C-x C-f lib/*.rb RET.

That said, I do fire up M-x server-start once in a while and run emacsclient from Terminal.app. Because I’m running the server from the GUI emacs, I can get Terminal.app communicating over to the GUI and feel more comfortable.

  • How do you handle integration with the OS X clipboard? (Especially, if you said yes above.)

As I said, I generally use the GUI anyways so clipboard integration Just Works(tm).

I do like having save-interprogram-paste-before-kill set to t via custom. That makes the OS integration a bit smoother.

  • What do you use for .erb files?

Nothing. I try not to work on view code (and people thank me for that). If I did, I’d prolly try out MMM again. I didn’t like the older alternatives.

  • Do you indent manually or with an automatic tool?

Um… I use ruby-mode or enh-ruby-mode (or whatever language’s mode) to do indentation for me with plain TAB. I’m not sure if that’s what you’re asking.

JD asks:

  • How much to you rely on [c|e]tags for navigation in projects?

I love exuberant ctags and have a script called retag that does-what-I-want 99% of the time. That said, I don’t use tags that much because most of my projects are limited in scope enough and have sane file layout that it isn’t strictly necessary.

I do recommend using tags to all newcomers to emacs tho. I think it is a very powerful tool (esp once you start using pop-tag-mark to go back from whence you came).

  • Any tricks/best practices for expanding text? I’m a long-time user of dabbrev-expand, but feel like I might be missing some opportunities by not using hippie-expand.

Ah! yes! I have the following in rwd-expand.el:

(eval-after-load "dabbrev" '(defalias 'dabbrev-expand 'hippie-expand))

Then, I set hippie-expand-try-functions-list to:


I believe that the defaults for hippie-expand are pretty good by themselves, but IIRC, I reordered some of them to suit my needs a bit better. It could probably still use some tweaking, but this works for me well enough that it stays off my radar.

Thanks - love the series.

Thank you!

July 03, 2013

Ryan DavisMy Emacs Setup, pt 6: What Next?

2013/07/03 07:00 PM

This is part 6 of My Emacs Setup.

Um. So… I’ve blogged the top-level architecture of my emacs setup. I have a lot of emacs stuff left. Rather than go through every file, what would you guys like to see? Comment below and I’ll try to make it happen.

Ryan Davisruby_parser, flog, & flay now have ruby 2.0 support

2013/07/03 07:00 PM

With yesterday’s release of ruby parser 3.2.0 both flog and flay automatically pick up the ability to parse ruby 2.0 syntax. Enjoy and please file issues if you come across anything.

June 29, 2013

Ruby InsideDoes the GIL Make Your Ruby Code Thread-Safe?

Jesse Storimer @ 2013/06/29 05:16 PM

This is a guest post by Jesse Storimer. He teaches the Unix fu workshop, an online class for Ruby developers looking to do some awesome systems hacking in Ruby and boost their confidence when it comes to their server stack. Spots are limited, so check it out the class while there's still room. He's also the esteemed author of Working with Unix Processes, Working with TCP Sockets and Working with Ruby Threads.

There are some misconceptions in the Ruby community about this question surrounding MRI's GIL. If you only take one thing away from this article today, let it be this: The GIL does not make your Ruby code thread-safe.

But you shouldn't take my word for it.

This series started off just trying to understand what the GIL is at a technical level. Part 1 explained how race conditions could occur in the C code that's used to implement MRI. Yet, the GIL seemed to eliminate that risk, at least for the Array#<< method we looked at.

Part 2 confirmed that the GIL did, in fact, make MRI's native C method implementations atomic. In other words, these native implementations were free from race conditions. These guarantees only applied to MRI's native C functions, not to the Ruby that your write. So we were left with a lingering question:

Does the GIL provide any guarantee that your Ruby code will be thread-safe?

I've already answered that question. Now I want to make sure that the misconception doesn't go any further.

Race conditions redux

Race conditions exist when some piece of data is shared between multiple threads, and those threads attempt to act on that data at the same time. When this happens without some kind of synchronization, like locking, your program can start to do unexpected things and data can be lost.

Let's step back and recap how such a race condition can occur. We'll use the following Ruby code example for this section:

class Sheep
  def initialize
    @shorn = false

  def shorn?

  def shear!
    puts "shearing..."
    @shorn = true

This class definition should be nothing new. A Sheep is not shorn when initialized. The shear! method performs the shearing and marks the sheep as shorn.

sheep = Sheep.new

5.times.map do
  Thread.new do
    unless sheep.shorn?

The bit of code creates a new sheep and spawns 5 threads. Each thread races to check if the sheep has been shorn? If not, it invokes the shear! method.

Here's the result I see from running this on MRI 2.0 several times.

$ ruby check_then_set.rb
$ ruby check_then_set.rb
$ ruby check_then_set.rb

Sometimes the same sheep is being shorn twice!

If you were under the impression that the GIL made your code 'just work' in the presence of multiple threads, this should dispel that. The GIL can make no such guarantee. Notice that the first time running the file, the expected result was produced. In subsequent runs, unexpected output was produced. If you continued running the example, you'll see still different variations.

These unexpected results are due to a race condition in your Ruby code. It's actually a common enough race condition that there's a name to describe this pattern: a check-then-set race condition. In a check-then-set race condition, two or more threads check a value, then set some state based on that value. With nothing to provide atomicity, it's possible that two threads race past the 'check' phase, then both perform the 'set' phase.

Recognizing race conditions

Before we look at how to fix this, first I want you to understand how to recognize this. I owe @brixen for introducing to me the terminology of interleavings in the context of concurrency. It's really helpful.

Remember that a context switch can occur on any line of your code. When switching from one thread to another, imagine your program being chopped up into a set of discrete blocks. This sequential set of blocks is a set of interleavings.

At one end of the spectrum, it's possible that there's a context switch after every line of code! This set of interleavings would have each line of code interleaved. At the other end of the spectrum, it's possible that there are no context switches during the body of the thread. This set of interleavings would have all the code in its original order for each thread. In between these two ends, there are lots of ways that your program can be chopped up and interleaved.

Some of these interleavings are OK. Not every line of code introduces a race condition. But imagining your programs as a set of possible interleavings can help you recognize when race conditions do occur. I'll use a series of diagrams to show this code may be interleaved by two Ruby threads.

Just to make the diagrams simpler, I replaced the shear! method call with the code from the body of the method.

Consider this diagram the legend for the ones to follow; the code highlighted in red is the set of interleavings from Thread A, the code highlighted in blue is the set of interleavings from Thread B.

Now let's see how this code could be interleaved by simulating context switches. The simplest case is if neither thread is interrupted during the course of executing this code. This would result in no race conditions and would produce the expected output for us. That might look like this:

Now I've organized the diagram so you can see the sequential ordering of events. Remember that the GIL locks around the execution of Ruby code, so two threads can't truly run in parallel. The ordering of events here is sequential, starting at the top and working down.

In this interleaving, Thread A did all of its work, then the thread scheduler triggered a context switch to Thread B. Since Thread A had already done the shearing and updated the shorn variable, Thread B didn't have anything to do.

But it isn't always this simple. Remember that the thread scheduler could trigger a context switch at any point in this block of code. This time we just got lucky.

Let's look at a more nefarious example, one that would produce unexpected output for us.

In this possible interleaving, the context switch occurs right at a point that can cause trouble. Thread A checks the condition and starts shearing. Then the thread scheduler schedules a context switch and Thread B takes over. Even though Thread A already performed the shearing, it didn't get a chance to update the shorn attribute yet, so Thread B doesn't know about it.

Thread B checks the condition for itself, finds it to be false, and shears the sheep again. Once it finishes, Thread A is scheduled again and finishes execution. Even though Thread B set shorn = true when it ran through the code, Thread A does it again because it picks up exactly where it left off.

A sheep getting shorn twice may not seem like much to care about, but replace sheep with invoice, and shearing with collecting payment; we would have some unhappy customers!

I'll share one more example to illustrate the non-deterministic nature of things here.

This just adds more context switches, so each thread progresses a little bit at a time, but keeps switching back and forth. Let your mind take this to its logical conclusion, it's possible for a context switch to happen on any line of the program. The interleaving that occurs can also be different each time the code is executed, so it may produce the expected result on one iteration, and an unexpected result the next time around.

This is really a great way to think about race conditions. When you're writing multi-threaded code, you want to be thinking about how the program might be chopped up and interleaved, and the effects of various interleavings. If it seems that some interleavings will lead to incorrect results, you should re-think your approach to the problem or introduce synchronization with Mutex.

This is terrible!

At this point it seems fitting to tell you that you can make this code example thread-safe by introducing synchronization with Mutex. It's true, you can do that. But I intentionally cooked up this example to prove a point;  it's terrible code. You shouldn't write code like this in a multi-threaded environment.

Whenever you have multiple threads sharing a reference to an object, and making modifications to it, you're going to run into trouble unless you have some kind of locking in place to prevent a context switch from happening in the middle of the modification.

However, this particular race condition is easily solvable without explicitly using locks in your code. Here's one solution using Queue:

require 'thread'

class Sheep
  # ...

sheep = Sheep.new
sheep_queue = Queue.new
sheep_queue << sheep

5.times.map do
  Thread.new do
      sheep = sheep_queue.pop(true)

    rescue ThreadError
      # raised by Queue#pop in the threads
      # that don't pop the sheep

I left out the Sheep implementation because it's the same. Now, instead of each thread sharing the sheep object and racing to shear it, the Queue provides the synchronization.

If you run this against MRI, or any of the other truly parallel Ruby implementations, it will produce the expected result every time. We've eliminated the race condition in this code. Even though all the threads may call the Queue#pop method at more-or-less the same time, it uses a Mutex internally to ensure that only one thread can receive the sheep.

Once this single thread receives the sheep, the race condition disappears. With just one thread, there's no one else to race with!

The reason I suggest using Queue instead of a lock is that its simpler to use a Queue correctly. Locks are notoriously easy to get wrong. They bring new concerns like deadlocking and performance degradations when used incorrectly. Using a data structure is like depending on an abstraction. It wraps up the tricky stuff in a more restrictive, but simpler API.

Lazy initialization

I'll just quickly point out that lazy initialization is another form of the the check-then-set race condition. The ||= operator effectively expands to

@logger ||= Logger.new

# expands to 

if @logger == nil
  @logger = Logger.new


Look at the expanded version and imagine where the interleavings could occur. With multiple threads and no synchronization, it's definitely possible for that @logger to be initialized twice. Again, initializing a Logger twice may not be a problem in this case, but I have seen bugs like this in the wild that do cause issues.


I want to leave you with some lessons at the end of all this.

4 out of 5 dentists agree that multi-threaded programming is hard to get right.

At the end of the day, all that the GIL guarantees is that MRI's native C implementations of Ruby methods will be executed atomically (but even this has caveats). This behaviour can sometimes help us as Ruby developers, but the GIL is really there for the protection of MRI internals, not as a dependable API for Ruby developers.

So the GIL doesn't 'solve' thread-safety issues. As I said, getting multi-threaded programming right is hard, but we solve hard problems every day. One way that we work with hard problems is with good abstractions.

For example, when I need to do an HTTP request in my code, I need to use a socket. But I don't usually use a socket directly, that would be cumbersome and error-prone. Instead, I use an abstraction. An HTTP client provides a more restrictive, simpler API that hides the socket interactions and associated edge cases from me.

If multi-threaded programming is hard to get right, maybe you shouldn't be doing it directly.

"If you add a thread to your application, you've probably added five new bugs in doing so."

- Mike Perham

We're seeing more and more abstractions around threads. An approach that's catching on in the Ruby community is the Actor model of concurrency, with the most popular implementation being Celluloid. Celluloid provides a great abstraction that marries concurrency primitives to Ruby's object model. Celluloid can't guarantee that your code will be thread-safe or free from race conditions, but it wraps up best practices. I encourage you give Celluloid a try.

These problems that we're talking about aren't specific to Ruby or MRI. This is the reality of programming in a multi-core world. The number of cores on our devices is only going up, and MRI is still figuring out its answer to this situation. Despite its guarantees, the GIL's restriction on parallel execution seems like the wrong direction. This is part of MRI's growing pains. Other implementations, like JRuby and Rubinius, are running truly parallel with no GIL.

We're seeing lots of new languages that have concurrency abstractions built-in at the core of the language. The Ruby language doesn't have any of this, at least not yet. Another benefit of relying on abstraction is that the abstractions can improve their implementation, while your code remains unchanged. For example, if the implementation of Queue switched from relying on locks to using lock-free synchronization, your code would reap the benefits without any modification.

For the time being, Ruby developers should educate themselves about these issues! Learn about concurrency. Be aware of race conditions. Thinking about code as interleavings can help you reason about race conditions.

I'll leave off with a quote that's influencing much of the work being done in the larger field of concurrency today:

Don't communicate by sharing state; share state by communicating.

Using data structures for synchronization supports this; the Actor model supports this. This idea is at the core of the concurrency model of languages like Go, Erlang, and others.

Ruby needs to look to what's working in other languages and embrace it. As a Ruby developer, you can do this today by trying out and supporting some of these alternative approaches. With more people on board, these approaches could become the new standard for Ruby.

Thanks to Brian Shirai for reviewing a draft of this.

Last updated at 2014/04/21 09:00 AM | Presented by Aredridel and Christoffer Sawicki | Hosted at The Internet Company