Phusion Passenger 4.0.37 released

Posted 6 months back at Phusion Corporate Blog


Phusion Passenger is a fast and robust web server and application server for Ruby, Python, Node.js and Meteor. Passenger takes a lot of complexity out of deploying web apps, and adds powerful enterprise-grade features that are useful in production. High-profile companies such as Apple, New York Times, AirBnB, Juniper, American Express, etc are already using it, as well as over 350.000 websites.

Phusion Passenger is under constant maintenance and development. Version 4.0.37 is a bugfix release.

Phusion Passenger also has an Enterprise version which comes with a wide array of additional features. By buying Phusion Passenger Enterprise you will directly sponsor the development of the open source version.

Recent changes

  • Improved Node.js compatibility. Calling on() on the request object now returns the request object itself. This fixes some issues with Express, Connect and Formidable. Furthermore, some WebSocket-related issues have been fixed.
  • Improved Meteor support. Meteor application processes are now shut down quicker. Previously, they linger around for 5 seconds while waiting for all connections to terminate, but that didn’t work well because WebSocket connections were kept open indefinitely. Also, some WebSocket-related issues have been fixed.
  • Introduced a new tool `passenger-config detach-process` for gracefully detaching an application process from the process pool. Has a similar effect to killing the application process directly with `kill <PID>`, but killing directly may cause the HTTP client to see an error, while using this command guarantees that clients see no errors.
  • Fixed a crash that occurs when an application fails to spawn, but the HTTP client disconnects before the error page is generated. Fixes issue #1028.
  • Fixed a symlink-related security vulnerability.

    Urgency: low
    Scope: local exploit
    Summary: writing files to arbitrary directory by hijacking temp directories
    Affected versions: 4.0.5 and later
    Fixed versions: 4.0.37

    Description: Phusion Passenger creates a "server instance directory" in /tmp during startup, which is a temporary directory that Phusion Passenger uses to store working files. This directory is deleted after Phusion Passenger exits. For various technical reasons, this directory must have a semi-predictable filename. If a local attacker can predict this filename, and precreates a symlink with the same filename that points to an arbitrary directory with mode 755, owner root and group root, then the attacker will succeed in making Phusion Passenger write files and create subdirectories inside that target directory. The following files/subdirectories are created:

    • control_process.pid
    • generation-X, where X is a number.

    If you happen to have a file inside the target directory called `control_process.pid`, then that file’s contents are overwritten. These files and directories are deleted during Phusion Passenger exit. The target directory itself is not deleted, nor are any other contents inside the target directory, although the symlink is.

    Thanks go to Jakub Wilk for discovering this issue.

Installing or upgrading to 4.0.37

OS X OS X Debian Debian Ubuntu Ubuntu
Heroku Heroku Ruby gem Ruby gem Tarball Tarball

Final

Fork us on Github!

Phusion Passenger’s core is open source. Please fork or watch us on Github. :)

<iframe src="http://ghbtns.com/github-btn.html?user=phusion&amp;repo=passenger&amp;type=watch&amp;size=large&amp;count=true" allowtransparency="true" frameborder="0" scrolling="0" width="170" height="30"></iframe><iframe src="http://ghbtns.com/github-btn.html?user=phusion&amp;repo=passenger&amp;type=fork&amp;size=large&amp;count=true" allowtransparency="true" frameborder="0" scrolling="0" width="170" height="30"></iframe><iframe src="http://ghbtns.com/github-btn.html?user=phusion&amp;type=follow&amp;size=large&amp;count=true" allowtransparency="true" frameborder="0" scrolling="0" width="190" height="30"></iframe>

If you would like to stay up to date with Phusion news, please fill in your name and email address below and sign up for our newsletter. We won’t spam you, we promise.



Building Sinatra with Lotus

Posted 6 months back at Luca Guidi - Home

The beauty of Lotus are its components. Each of them is well designed to achieve one and only one goal. The main advantage of this architecture is that delevopers can easily use and reuse those frameworks in countless ways.

Lotus::Router accepts anonymous functions as endpoints. This feature can be used to build Sinatra with it.

Initial setup

We need to setup a Gemfile with:

source 'https://rubygems.org'
gem 'lotus-router'

As second step, we create an Hello World application (app.rb) with Lotus::Router:

require 'rubygems'
require 'bundler/setup'
require 'lotus/router'

Application = Rack::Builder.new do
  app = Lotus::Router.new do
    get '/' do
      [200, {}, ['Hello, World!']]
    end
  end
  run app
end.to_app

Return value of the block as response body

You may have noticed a discrepancy between the typical Sinatra usage and the example above: the framework sets the return value of that endpoint as the body of the response, here we’re returning a serialized Rack response.

Internally, Lotus::Router uses Lotus::Routing::Endpoint to wrap application’s endpoints. They can be any type of object that respond to #call, and it’s up to us to return a Rack::Response. In our case, we have just a string, if we inherit from that class, we can wrap the body in a proper response:

class Endpoint < Lotus::Routing::Endpoint
  def call(env)
    [200, {}, [super]]
  end
end

The next step is to use this endpoint.

Lotus::Router uses a specific set of rules to understand which endpoint needs to be associated with a given path. For instance, when you write get '/dashboard', to: 'dashboard#index', that :to option is processed and the router will look for a DashboardController::Index class.

Those conventions are implemented by Lotus::Routing::EndpointResolver, which is used as default resolver. If you want to use a different policy, or customize the way it works, pass your own resolver to the router constructor (:resolver option). We want to use the defaults, and only specify to usa of our custom endpoint.

require 'rubygems'
require 'bundler/setup'
require 'lotus/router'

class Endpoint < Lotus::Routing::Endpoint
  def call(env)
    [200, {}, [super]]
  end
end

r = Lotus::Routing::EndpointResolver.new(endpoint: Endpoint)

Application = Rack::Builder.new do
  app = Lotus::Router.new(resolver: r) do
    get '/' do
      'Hello, World!'
    end
  end
  run app
end.to_app

Request params

Now that we have mimicked the simplest Sinatra usage, let’s have a look at the next example: request params. Endpoint is agnostic, it’s part of an HTTP router, that’s why it passes the complete Rack env to the real endpoint that it wraps. Instead, we want to use only the tokens coming from the URL. This is really simple to do:

require 'rubygems'
require 'bundler/setup'
require 'lotus/router'

class Endpoint < Lotus::Routing::Endpoint
  def call(env)
    [200, {}, [super(params(env))]]
  end

  private
  def params(env)
    env.fetch('router.params')
  end
end

r = Lotus::Routing::EndpointResolver.new(endpoint: Endpoint)

Application = Rack::Builder.new do
  app = Lotus::Router.new(resolver: r) do
    get '/' do
      'Hello, World!'
    end

    get '/greet/:planet' do |params|
      "Hello from the #{ params[:planet] }!"
    end
  end
  run app
end.to_app

A step further

What we did until now it’s great but noisy. We want to extract the boilerplate code into a separated file. I’ve prepared a microgem to be used with our Gemfile.

source 'https://rubygems.org'
gem 'lotus-sinatra', git: 'https://gist.github.com/8665228.git'

Now we can leave that beautiful DSL alone.

require 'rubygems'
require 'bundler/setup'
require 'lotus-sinatra'

get '/' do
  'Hello, World!'
end

get '/greet/:planet' do |params|
  "Hello from the #{ params[:planet] }!"
end

Conclusion

This example confirms how valuable is the separation between Lotus frameworks and that Dependency Injection is a virtue.

To stay updated with the latest releases, to receive code examples, implementation details and announcements, please consider to subscribe to the Lotus mailing list.

<link href="//cdn-images.mailchimp.com/embedcode/slim-081711.css" rel="stylesheet" type="text/css"/>

REPL Driven Development

Posted 6 months back at Jay Fields Thoughts

When I describe my current workflow I use the TLA RDD, which is short for REPL Driven Development. I've been using REPL Driven Development for all of my production work for awhile now, and I find it to be the most effective workflow I've ever used. RDD differs greatly from any workflow I've used in the past, and (despite my belief that it's superior) I've often had trouble concisely describing what makes the workflow so productive. This entry is an attempt to describe what I consider RDD to be, and to demonstrate why I find it the most effective way to work.

RDD Cycle

First, I'd like to address the TLA RDD. I use the term RDD because I'm relying on the REPL to drive my development. More specifically, when I'm developing, I create an s-expression that I believe will solve my problem at hand. Once I'm satisfied with my s-expression, I send that s-expression to the REPL for immediate evaluation. The result of sending an s-expression can either be a value that I manually inspect, or it can be a change to a running application. Either way, I'll look at the result, determine if the problem is solved, and repeat the process of crafting an s-expression, sending it to the REPL, and evaluating the result.

If that isn't clear, hopefully the video below demonstrates what I'm talking about.

<iframe width="420" height="315" src="//www.youtube.com/embed/P8SWtYXXOuo" frameborder="0" allowfullscreen=""></iframe>

If you're unfamiliar with RDD, the previous video might leave you wondering: What's so impressive about RDD? To answer that question, I think it's worth making explicit what the video is: an example of a running application that needs to change, a change taking place, and verification that the application runs as desired. The video demonstrates change and verification; what makes RDD so effective to me is what's missing: (a) restarting the application, (b) running something other than the application to verify behavior, and (c) moving out of the source to execute arbitrary code. Eliminating those 3 steps allows me to focus on what's important, writing and running code that will be executed in production.

Feedback

I've found that, while writing software, getting feedback is the single largest time thief. Specifically, there are two types of feedback that I want to get as quickly as possible: (1) Is my application doing what I believe it is? (2) What does this arbitrary code return when executed? I believe the above video demonstrates how RDD can significantly reduce the time needed to answer both of those questions.

In my career I've spent significant time writing applications in C#, Ruby, & Java. While working in C# and Java, if I wanted to make and verify (in the application) any non-trivial change to an application, I would need to stop the application, rebuild/recompile, & restart the application. I found the slowness of this feedback loop to be unacceptable, and wholeheartedly embraced tools such as NUnit and JUnit.

I've never been as enamored with TDD as some of my peers; regardless, I absolutely endorsed it. The Design aspect of TDD was never that enticing to me, but tests did allow me to get feedback at a significantly superior pace. Tests also provide another benefit while working with C# & Java: They're the poorest man's REPL. Need to execute some arbitrary code? Write a test, that you know you're going to immediately delete, and execute away. Of course, tests have other pros and cons. At this moment I'm limiting my discussion around tests to the context of rapid feedback, but I'll address TDD & RDD later in this entry.

Ruby provided a more effective workflow (technically, Rails provided a more effective workflow). Rails applications I worked on were similar to my RDD experience: I was able to make changes to a running application, refresh a webpage and see the result of the new behavior. Ruby also provided a REPL, but I always ran the REPL external to my editor (I knew of no other option). This workflow was the closest, in terms of efficiency, that I've ever felt to what I have with RDD; however, there are some minor differences that do add up to an inferior experience: (a) having to switch out of a source file to execute arbitrary code is an unnecessary nuisance and (b) refreshing a webpage destroys any client side state that you've built up. I have no idea if Ruby now has editor & repl integration, if it does, then it's likely on par with the experience I have now.

Semantics

  • It's important to distinguish between two meanings of "REPL" - one is a window that you type forms into for immediate evaluation; the other is the process that sits behind it and which you can interact with from not only REPL windows but also from editor windows, debugger windows, the program's user interface, etc.
  • It's important to distinguish between REPL-based development and REPL-driven development:
    • REPL-based development doesn't impose an order on what you do. It can be used with TDD or without TDD. It can be used with top-down, bottom-up, outside-in and inside-out approaches, and mixtures of them.
    • REPL-driven development seems to be about "noodling in the REPL window" and later moving things across to editor buffers (and so source files) as and when you are happy with things. I think it's fair to say that this is REPL-based development using a series of mini-spikes. I think people are using this with a bottom-up approach, but I suspect it can be used with other approaches too.
-- Simon Katz
I like Simon's description, but I don't believe that we need to break things down to two different TLAs. Quite simply, (sadly) I don't think enough people are developing in this way, and the additional specification causes a bit of confusion among people who aren't familiar with RDD. However, Simon's description is so spot on I felt the need to describe why I'm choosing to ignore his classifications.

RDD & TDD

RDD and TDD are not in direct conflict with each other. As Simon notes above, you can do TDD backed by a REPL. Many popular testing frameworks have editor specific libraries that provide immediate feedback through REPL interaction.

When working on a feature, the short term goal is to have it working in the application as fast as possible. Arbitrary execution, live changes, and only writing what you need are 3 things that can help you complete that short term goal as fast as possible. The video above is the best example I have of how you go from a feature request to software that does what you want in the smallest amount of time. In the video, I only leave the buffer to verify that the application works as intended. If the short term goal was the only goal, RDD without writing tests would likely be the solution. However, we all know that that are many other goals in software. Good design is obviously important. If you think tests give you better design, then you should probably mix both TDD & RDD. Preventing regression is also important, and that can be accomplished by writing tests after you have a working feature that you're satisfied with. Regression tests are great for giving confidence that a feature works as intended and will continue to in the future.

REPL Driven Development doesn't need to replace your current workflow, it can also be used to extend your existing TDD workflow.

Hobo 2.1.0 released!

Posted 6 months back at The Hobo Blog

We’re proud to announce the release of Hobo 2.1.0 with Rails 4 support!

Take a look at the Download and Installation Instructions.

Many of the changes required in upgrading a Hobo 2.0 application are necessitated by the switch from Rails 3.2 to 4.0. Railscasts has a good guide to upgrading to Rails 4.0.

From Hobo’s point of view, you shouldn’t need to change almost anything :).

Gemfile

Now Hobo uses “will_paginate_hobo” gem, instead of the git repository “git://github.com/Hobo/will_paginate.git”. This should make it easier to install in systems without Git installed (users have reported problems with Windows and Git).

You also need to add the protected_attributes gem to your Gemfile.

Internal changes

In order to make Hobo compatible with Rails 4, these are the main changes that have been done:

Routing

  • url_for does not accept parameters any more
  • Remove deprecated routes system
  • match is no longer accepted in routes.rb, it has been replaced by “get” and “post”

ActiveRecord

  • Model.find(:all) is deprecated
  • finder.scoped :conditions => conditions has been replaced with finder.where(conditions)
  • raise_on_type_mismatch has been renamed to raise_on_type_mismatch!

Other

  • protected_attributes gem has been added to support the “old” way of protecting attributes
  • Domizio has made Hobo thread safe :)
  • Hobo’s custom will_paginate has been packaged into the hobo_will_paginate gem. This should make possible to install Hobo without Git (it seems to be a bit hard under Windows).## Installation

Hobo 2.1.0 released!

Posted 6 months back at The Hobo Blog

We’re proud to announce the release of Hobo 2.1.0 with Rails 4 support!

Take a look at the Download and Installation Instructions.

Many of the changes required in upgrading a Hobo 2.0 application are necessitated by the switch from Rails 3.2 to 4.0. Railscasts has a good guide to upgrading to Rails 4.0.

From Hobo’s point of view, you shouldn’t need to change almost anything :).

Gemfile

Now Hobo uses “will_paginate_hobo” gem, instead of the git repository “git://github.com/Hobo/will_paginate.git”. This should make it easier to install in systems without Git installed (users have reported problems with Windows and Git).

You also need to add the protected_attributes gem to your Gemfile.

Internal changes

In order to make Hobo compatible with Rails 4, these are the main changes that have been done:

Routing

  • url_for does not accept parameters any more
  • Remove deprecated routes system
  • match is no longer accepted in routes.rb, it has been replaced by “get” and “post”

ActiveRecord

  • Model.find(:all) is deprecated
  • finder.scoped :conditions => conditions has been replaced with finder.where(conditions)
  • raise_on_type_mismatch has been renamed to raise_on_type_mismatch!

Other

  • protected_attributes gem has been added to support the “old” way of protecting attributes
  • Domizio has made Hobo thread safe :)
  • Hobo’s custom will_paginate has been packaged into the hobo_will_paginate gem. This should make possible to install Hobo without Git (it seems to be a bit hard under Windows).## Installation

Phusion Passenger 4.0.36 released

Posted 6 months back at Phusion Corporate Blog


Phusion Passenger is a fast and robust web server and application server for Ruby, Python, Node.js and Meteor. Passenger takes a lot of complexity out of deploying web apps, and adds powerful enterprise-grade features that are useful in production. High-profile companies such as Apple, New York Times, AirBnB, Juniper, American Express, etc are already using it, as well as over 350.000 websites.

Phusion Passenger is under constant maintenance and development. Version 4.0.36 is a bugfix release.

Phusion Passenger also has an Enterprise version which comes with a wide array of additional features. By buying Phusion Passenger Enterprise you will directly sponsor the development of the open source version.

Recent changes

  • [Enterprise] Fixed some Mass Deployment bugs.
  • [Enterprise] Fixed a bug that causes an application group to be put into Deployment Error Resistance Mode if rolling restarting fails while deployment error resistance is off. Deployment Error Resistance Mode is now only activated if it’s explicitly turned on.
  • Passenger Standalone now gzips JSON responses.
  • Fixed some cases in which Passenger Standalone does not to properly cleanup its temporary files.

Installing or upgrading to 4.0.36

OS X OS X Debian Debian Ubuntu Ubuntu
Heroku Heroku Ruby gem Ruby gem Tarball Tarball

Final

Fork us on Github!

Phusion Passenger’s core is open source. Please fork or watch us on Github. :)

<iframe src="http://ghbtns.com/github-btn.html?user=phusion&amp;repo=passenger&amp;type=watch&amp;size=large&amp;count=true" allowtransparency="true" frameborder="0" scrolling="0" width="170" height="30"></iframe><iframe src="http://ghbtns.com/github-btn.html?user=phusion&amp;repo=passenger&amp;type=fork&amp;size=large&amp;count=true" allowtransparency="true" frameborder="0" scrolling="0" width="170" height="30"></iframe><iframe src="http://ghbtns.com/github-btn.html?user=phusion&amp;type=follow&amp;size=large&amp;count=true" allowtransparency="true" frameborder="0" scrolling="0" width="190" height="30"></iframe>

If you would like to stay up to date with Phusion news, please fill in your name and email address below and sign up for our newsletter. We won’t spam you, we promise.



Episode #434 - January 24th, 2014

Posted 6 months back at Ruby5

Command line fuzzy finding, workers in go, consolidating your docsites, interviewing front-end developers, tracking upcoming ruby conferences, and a long-awaited update to PhantomJS all in this episode of the Ruby5!

Listen to this episode on Ruby5

This episode is sponsored by New Relic

New Relic is _the_ all-in-one web performance analytics product. It lets you manage and monitor web application performance, from the browser down to the line of code. With Real User Monitoring, New Relic users can see browser response times by geographical location of the user, or by browser type.
This episode is sponsored by New Relic

Selecta

Selecta is an open source fuzzy text finder for the command line. It is easy to work with an integrate into your existing workflows!
Selecta

Goworker

Have slow Ruby workers? Goworker is compatible with resque and might process your background tasks much faster than your existing Ruby workers.
Goworker

DevDocs

DevDocs combines multiple API documentations in a fast, organized, and searchable interface.
DevDocs

Front-end Job Interview Questions

A list of helpful front-end related questions you can use to interview potential candidates.
Front-end Job Interview Questions

rubyconferences.org

Wondering what conferences are coming up in the Ruby community? The recently launched rubyconferences.org site has all the details!
rubyconferences.org

PhantomJS Update

PhantomJS got an update that removes those pesky CoreText performance warnings in your log. Brew update today and all that ugliness will go away!
PhantomJS Update

Introducing Lotus::Router

Posted 6 months back at Luca Guidi - Home

For me, the first step in the long path of building a web framework was an HTTP router. By understanding requests coming from an user, it pays back with an immediate gratification: start it, open a browser and see a result.

My hope was to embark on a short journey, and reuse as much as possible existing libraries. But I soon discovered that the biggest problem of Ruby web frameworks is reusability of components. Rails uses journey, which is coupled with ActionPack code base. Sinatra has its own hardcoded routing system. Plain Rack apps require the developer to fiddle with low level details of env.

All those solutions work great for the narrowed problem they are solving: HTTP routing for a given system. What if I wanted to build an high-level router, not just for a specific framework, but for all the Ruby web apps?

That’s where the idea of Lotus::Router came in.

Lotus::Router is an HTTP Router for Ruby, it’s fast, lightweight and compatible with the Rack protocol.

It’s designed to work as a standalone software or within a context of a Lotus application, and provides features such as: fixed and partial URL matching, redirect, namespaces, named routes and RESTful resource(s).

Usage

During the design process of this software I had in mind two main goals: simplicity and employ well known ideas. Ease of use is crucial to software adoption, but also meet a developer’s acquaintance with what he (or her) already utilize is critical as well. This is a pattern that you will notice often during the discover of Lotus: on one hand, it leverages on well established concepts, on the other one, it adds value by bringing fresh ideas.

require 'rubygems'
require 'lotus-router'

router = Lotus::Router.new do
  get  '/hello', to: ->(env) { [200, {}, ['Hello, World!']] }
  get  '/dashboard',   to: 'dashboard#index'
  get  '/middleware',  to: RackMiddleware
  get  '/rack-app',    to: RackApp.new

  redirect '/legacy', to: '/'

  namespace 'admin' do
    get '/users', to: UsersController::Index
  end

  resource  'identity'
  resources 'users'
end

For those who are unfamiliar with this (I hope none of you), let me explain the basic usage.

We have an HTTP verb as method, #get in the example. This method is invoked with a string which is the relative URL to match ("/hello"), and with an endpoint (to: #...) that is where a request will be routed to. Thanks to the Ruby’s weak typing nature, an endpoint can be a proc, a string, a class or an object. According to simple conventions, Lotus::Router is able resolve that option in a Rack endpoint, which must be provided by your application.

I would like you to notice that the DSL is implemented with a block accepted by the constructor, and it uses public methods of the object, there is no magic here. I could write the previous example like this:

router = Lotus::Router.new
router.get  '/', to: ->(env) { [200, {}, ['Hello, World!']] }
# ...

Another aspect that is important is that we obtain a router object. Instead of being relegated to a secondary role and hidden behind the opaque mechanisms of other frameworks, this is the first time that a router it’s promoted to a first class citizenship. This is a pillar of the Lotus architecture: let components to emerge. In this way developers can be better understand, introspect and test.

router = Lotus::Router.new(scheme: 'https', host: 'host.com')
router.get '/login', to: 'sessions#new', as: :login

router.path(:login) # => "/login"
router.url(:login)  # => "https://host.com/login"

Imagine how much it would be easy &dash; with a system like this &dash; to implement routing helpers.

This is only a taste of what Lotus::Router can do: please have a look at the README and the API doc, for a detailed explanation.

Roadmap

The experiment of releasing a Lotus component on the 23rd of every month is going well. On February will be the turn of Lotus::Controller.

To stay updated with the latest releases, to receive code examples, implementation details and announcements, please consider to subscribe to the Lotus mailing list:

<link href="//cdn-images.mailchimp.com/embedcode/slim-081711.css" rel="stylesheet" type="text/css"/><style type="text/css"> #mc_embed_signup{background-color:#eee; clear:left} #mc_embed_signup form input.email{width:96%} #mc_embed_signup form input.button{background-color:#27ae60} </style>

ActiveRecord's where.not

Posted 6 months back at GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS - Home

Rails 4.0 introduced a helpful new method for ActiveRecord queries: where.not. It can make clunky queries easier to read.

Usage

This query:

User.where.not(name: 'Gabe')

is effectively the same as this:

User.where('name != ?', 'Gabe')

It's "effectively" the same because where.not has some extra juice: it will fully qualify the column name with the table name, continue to work if the table or column get aliased (during a left outer join clause with includes), and will continue to work if the database implementation is switched.

I've usually seen it used for NOT NULL queries:

# Old and busted
# User.where('name IS NOT NULL')
# New hotness
User.where.not(name: nil)

But it works with arrays too:

# Without `where.not`
# Something.where("name NOT IN ?", User.unverified.pluck(:name))
# With `where.not`
Something.where.not(name: User.unverified.pluck(:name))

That example takes advantage of the fact that ActiveRecord automatically uses IN (or in this case NOT IN) if the value you're querying against is an array.

Complex usage

Here's a more complex example:

class Course < ActiveRecord::Base
  def self.with_no_enrollments_by(student)
    includes(:enrollments).
      references(:enrollments).
      where.not(enrollments: { student_id: student.id })
  end
end

You can ignore the first two lines, which tell ActiveRecord that we're going through the enrollments table (student has_many :courses, through: :enrollments). The method finds courses where the course has no enrollments by the student. It is the complement to student.courses.

Without where.not, it would look like this:

def with_no_enrollments_by(student)
  includes(:enrollments).
    references(:enrollments).
    where('enrollments.student_id != ?', student.id)
end

I prefer the pure-Ruby approach of the where.not version instead of the string SQL of the latter because it's easier to read and it's easier to change later.

What's next?

If you found this post helpful, I recommend our post on null relations or a close reading of the official ActiveRecord docs.

Starting and Stopping Background Services with Homebrew

Posted 6 months back at GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS - Home

I love Homebrew, but sometimes it really gets me down, you know? Especially when I have to deal with launchctl.

launchctl loads and unloads services that start at login. In OS X, these services are represented by files ending with .plist (which stands for "property list"). These plists are usually stored in either ~/Library/LaunchAgents or /Library/LaunchAgents. You load them (i.e. tell them to start at login) with launchctl load $PATH_TO_LIST and unload them with launchctl unload $PATH_TO_LIST. Loading a plist tells the program it represents (e.g. redis) to start at login, while unloading it tells the program not to start at login.

This post-install message from Homebrew may look familiar:

To have launchd start mysql at login:
    ln -sfv /usr/local/opt/mysql/*.plist ~/Library/LaunchAgents
Then to load mysql now:
    launchctl load ~/Library/LaunchAgents/homebrew.mxcl.mysql.plist
Or, if you don't want/need launchctl, you can just run:
    mysql.server start

Typing launchctl load and launchctl unload takes too long, and I can never remember where Homebrew plists are. Fortunately, Homebrew includes a lovely interface for managing this without using launchctl or knowing where plists are.

brew services

While it's not publicized, brew services is available on every installation of Homebrew. First, run the ln command that Homebrew tells you about in the post-installation message above:

ln -sfv /usr/local/opt/mysql/*.plist ~/Library/LaunchAgents

For Redis, you'd run:

# `brew info redis` will tell you what to run if you missed it
ln -sfv /usr/local/opt/redis/*.plist ~/Library/LaunchAgents

And so on. Now you're ready to brew a service:

$ brew services start mysql
==> Successfully started `mysql` (label: homebrew.mxcl.mysql)

That bit about "label: " means it just loaded ~/Library/LaunchAgents/homebrew.mxcl.mysql.plist with launchctl load.

Let's say MySQL's acting funky. We can easily restart it:

brew services restart mysql
Stopping `mysql`... (might take a while)
==> Successfully stopped `mysql` (label: homebrew.mxcl.mysql)
==> Successfully started `mysql` (label: homebrew.mxcl.mysql)

Now let's see everything we've loaded:

$ brew services list
redis      started      442 /Users/gabe/Library/LaunchAgents/homebrew.mxcl.redis.plist
postgresql started      443 /Users/gabe/Library/LaunchAgents/homebrew.mxcl.postgresql.plist
mongodb    started      444 /Users/gabe/Library/LaunchAgents/homebrew.mxcl.mongodb.plist
memcached  started      445 /Users/gabe/Library/LaunchAgents/homebrew.mxcl.memcached.plist
mysql      started    87538 /Users/gabe/Library/LaunchAgents/homebrew.mxcl.mysql.plist

Note that the list of services includes services you started with launchctl load, not just services you loaded with brew services.

Let's say we uninstalled MySQL and Homebrew didn't remove the plist for some reason (it usually removes it for you). There's a command for you:

$ brew services cleanup
Removing unused plist /Users/gabe/Library/LaunchAgents/homebrew.mxcl.mysql.plist

Kachow.

Hidden Homebrew commands

Homebrew ships with a whole bunch of commands that don't show up in brew --help. You can see a list of them in the Homebrew git repo. Each file is named like brew-COMMAND, and you run them with brew command. I recommend brew beer.

What's next?

If you liked this, I recommend reading through Homebrew's Tips and Tricks. You can also try out another Homebrew extension for installing Mac apps: homebrew-cask.

Open Data Scotland: a Linked Data pilot study for the Scottish Government

Posted 6 months back at RicRoberts :

digital social map

Last month we launched Open Data Scotland - a pilot site built for the Scottish Government to showcase how Linked Open Data can make for smarter, more efficient data use. Accompanying the site is a report (download pdf) which we produced to explain what open linked data is; how to publish it effectively and its potential use and benefits to the Scottish public sector.

The site is split into three parts:

We wanted to emphasise the potential of Linked Data to a range of users. So, we’re using datasets with topics that have proven popular in other projects, such as deprivation data and we’ve targeted each section of the site to a slightly different audience.

One new concept that we introduced in this project are contextual tutorials, aimed at a range of users: from those working with spreadsheets to those interested in more technical Linked Data wizardry. We love it because it gives a whole new set of people a friendly way in to using the data. We’re introducing a whole new audience to the power of Linked Data.

Something else new to this project are data kits. These kits bridge the gap between the interactive visualisations and the more technical aspects. They also help more advanced users get started on working with the data in the site. This helps to get the right information to the people who want it, in a form that allows them to use it quickly and easily.

We’re really excited about this project which emphasises how interactive, accessible and useful Linked Data can be. Bill introduced the pilot at the Open Data Scotland conference in December. Check it out yourself and let us know what you think.

Brewfile: a Gemfile, but for Homebrew

Posted 6 months back at GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS - Home

Bundler users define dependencies for Ruby applications in a Gemfile and install those dependencies by running bundle install.

Homebrew users can define dependencies for their OS X operating system with a Brewfile and install those dependencies by running brew bundle. Let's write a basic Brewfile:

# Brewfile
install openssl
# a comment
link --force openssl

Note that Homebrew will treat lines that start with # as comments. Every other line will be passed to brew. So this:

install openssl
# a comment
link -f openssl

is run as these commands:

brew install openssl
brew link --force openssl

Usage

I can think of a few places where a Brewfile would be welcome:

  • In dotfiles, either yours or your company's. For example, we use it in our excellent dotfiles repo.
  • A setup script for your app (bundle install && brew bundle)
  • A setup script for a new machine. I often forget to install one of them (like rbenv-gem-rehash).

It's a neat encapsulation for non-programming-language dependencies like phantomjs.

What's next?

If you found this useful, I recommend reading through the source of the brew bundle command. For more Homebrew tricks, read through our OSX-related posts.

Scrolling DOM elements to the top, a Zepto plugin

Posted 6 months back at mir.aculo.us - Home

There’s bunches of plugins, extensions and techniques to smoothly scroll page elements, but most of them are convoluted messes and probably do more than you need. I like “small and works well”, and it’s a good exercise for those JavaScript and DOM muscles to write a small plugin from time to time.

My goal was to have an animated “scroll to top” for the mobile version of Freckle—normally the browser would take care of that (tap status bar to scroll to top), but in a more complex layout the built-in mechanisms for this quickly fail and you’ll have to implement some of the interactions users expect (like tap status bar to scroll to top) yourself. Specifically, this is for the native app wrapper (Cordova) I use for Freckle’s upcoming mobile app. It’s hooked up so that taps on the statusbar invoke a JavaScript method.

During development of this I needed the same thing for arbitrary scroll positions as well, so “scrolltotop” is a bit of a misnomer now. Anyway, here’s the annotated code:

<script src="https://gist.github.com/madrobby/8507960.js"></script>

Often, writing your own specialized plug-in is faster than trying to understand and configure existing code. If you do, share it! :)

Episode #433 - January 17, 2014

Posted 7 months back at Ruby5

ActiveSupport Notifications, RailsBricks, DotEnv, Builder, Decorator, Chain of Responsibility, and null object patterns

Listen to this episode on Ruby5

NewRelic
NewRelic recently posted about what Nonlinear Dynamics Teach Us About App Stability

Instrumenting Your Code With ActiveSupport Notifications
We've been having hack lunches at CustomInk | Tech to level up our rails knowledge. Find out what we learned about ActiveSupport Notifications

RailsBricks
RailsBricks will setup Bootstrap 3, Font Awesome, Devise, Kaminari and build out the basic models and views for those gems

Composable Matchers in RSpec 3.0
One of RSpec 3’s big new features is composable matchers. This feature will help make your tests more powerful with less brittle expectations

DotEnv
One of the tenets of a Twelve-Factor App is to store configuration in env vars. They are easy to change between deploys without changing any code; and unlike config files, there is little chance of them being checked into the code repo accidentally.

Code Show and Tell: PolymorphicFinder
You just need a quick refactor to use the Builder, Decorator, Chain of Responsibility, and null object pattern

We're NASA and We Know It (Mars Curiosity) Song
Thank you for listening to Ruby5. Be sure to tune in every Tuesday and Friday for the latest news in the Ruby and Rails community.

Rails + Angular + Jasmine: A Modern Testing Stack

Posted 7 months back at zerosum dirt(nap) - Home

When I started on my first Angular+Rails project around 12 months ago, there wasn't a lot of guidance around code organization, interop, and testing, and we got a lot of these things wrong. Since then, I've worked on several additional projects using the same tech stack and have had several more chances to screw it up all over again. After a few of these, I feel like I've finally got some conventions in place that work well for better code organization, interop, and testing.

This morning the team over at Localytics (hi Raj!) wrote up a good retrospective on their use of Angular + Rails over the past year, including lessons they learned and ongoing challenges. They touch on several of the same issues that my colleagues and I have run into, and the writeup inspired me to dust off my old busted blog to document some of my own findings.

Testing Your JavaScript Has Never Been Easier

One area that I felt like needed some further clarity was testing. In particular, how a Rails-centric application can cleanly and easily integrate tests around Angular frontend logic. Fortunately, once you figure out how to set this up, you'll find that unit testing Angular code in Jasmine -- especially controller and factory code -- is surprisingly easy to do. It's really the first time I've been sufficiently happy with a frontend testing configuration.

To see a working example for yourself and hack around with it, go snag the sample project I pushed up to GitHub. Bundle and run it, and play around with the shockingly awesome todo list application. Because the world really needed another one of those. When you've had enough of that, take a look at the contents of the spec/javascripts directory.

We're using the jasmine-rails test runner with CoffeeScript here, because that's what works for me (sorry Karma). Pay close attention to the spec_helper.coffee, which does much of the dependency injection needed to provide clean and intuitively named interfaces in our example controller spec.

<script src="https://gist.github.com/8480021.js?file="></script>
<noscript>
<html><body>You are being <a href="https://github.com/gist/8480021">redirected</a>.</body></html>
</noscript>

This gives us nice ways to interface with the factories and controllers we're defining, as well as Angular's own ngMock library (super useful for stubbing server-side endpoints), the event loop, and even template compilation for partials and directives. A couple of these are illustrated in the sample controller spec shown here:

<script src="https://gist.github.com/8480013.js?file="></script>
<noscript>
<html><body>You are being <a href="https://github.com/gist/8480013">redirected</a>.</body></html>
</noscript>

Jasmine's syntax should be very familiar to anyone who does RSpec BDD work, and the work we've done in our spec helper really cleans up the beforeEach setup that's required in each individual controller spec. These particular tests make heavy use of ngMock, which you won't always need to use, and the calls to flush() are required to fulfill pending requests, preserving the async nature of the backend but allowing the tests to execute synchronously.

Testing Continuously With Guard

Although the Jasmine web interface is nice, but I'm a big fan of using Guard in order to watch for filesystem events and kick off automated test runs from the command line. By including the guard-jasmine gem and updating our Guardfile we can continuously test both our server-side RSpec logic and the Jasmine unit tests all at the same time through a single interface:

One thing I haven't addressed here is directive testing, which can be a bit more difficult. I'll try to address that in a future post, or if you have your own recipes, feel free to link em up in the comments.

Special thanks to Mark Bates for working with me on early versions of this approach, and convincing me that Angular was worth looking at in the first place.