Founded in 2004, NYC.rb is the place for experienced Ruby and Rails programmers in New York City.
Explore Blog posts about everything we are up to, Tech Talk videos covering a huge range of timely topics and Event listings to keep you current on happenings at the Labs.
Founded in 2004, NYC.rb is the place for experienced Ruby and Rails programmers in New York City.
We have a Sinatra app mounted on Rails. If we raise an error in the Sinatra app, it doesn’t show anywhere. Can we attach the Rails logger somehow?
http://blog.codeclimate.com/blog/2013/03/27/rails-insecure-defaults/
Check out the release announcement here: http://blog.jetbrains.com/ruby/2013/03/rubymine-ichii-early-access-is-open/
This release also includes a small feature requested by the CloudPlanner team here at Pivotal Labs! When you create a new localization property from a view, the dialog will now default your localization file to the last one used: http://youtrack.jetbrains.com/issue/RUBY-13368
Thanks to the two Pivots who up voted our feature requests (Ken Mayer and Justin Richard)! And if you never got around to up voting our team’s RubyMine feature requests, please do so now! It only takes a sec:
http://youtrack.jetbrains.com/issue/RUBY-13332
http://youtrack.jetbrains.com/issue/RUBY-13341
http://youtrack.jetbrains.com/issue/RUBY-13327
http://youtrack.jetbrains.com/issue/RUBY-13326
http://youtrack.jetbrains.com/issue/RUBY-13366
http://youtrack.jetbrains.com/issue/RUBY-13374
A group of NYC Startup CTOs, VP of Engineering, Tech Leads, and technologists whowould like to become leaders.
The Apache Cassandra Project develops a highly scalable second-generation distributed database, bringing together Dynamo’s fully distributed design and Bigtable’s Column Family-based data model.
More here: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/47201
The March 27th Founder Showcase will feature top expert speakers discussing the theme: “The Future of Funding.” Stop by the Pivotal Labs table to hear what our experts think.
The community appears to be converging on .ruby-version as a standard way to convey a project’s Ruby version. This as opposed to .rvmrc or .rbenv
If you use RVM you can also use .ruby-gemset to specify a gemset.
See https://gist.github.com/fnichol/1912050 for more info.
I’m not a huge fan of Rails view helpers, which is a post for a different day, but put simply I prefer to encapsulate presentation logic in a presenter object rather than mix it in globally across all templates. There’s a few ways to do this, the simplest being the Good Ol’ Plain Ol’ Ruby Object:
class FooPresenter
def description_for(foo)
Date.today.tuesday? ? "50% off! #{foo.description}" : foo.description
end
end
Usually, I’ll instantiate the presenter in a controller and then call it within the view:
class FoosController
def index
@foos = Foo.all
@foo_presenter = FooPresenter.new
end
end
<% @foos.each do |foo| %>
<%= foo.name %>
<%= @foo_presenter.description_for(foo) %>
<% end %>
Everything is simple and feels where it should be, but we’ve gotten this at the cost of losing view helpers mixed in from Rails. One of the helpers I find particularly helpful is strip_tags. If we want access to strip_tags we can do as Rails does when mixing it into the view scope and include it in our presenter:
class FooPresenter
include ActionView::Helpers::SanitizeHelper
def description_for(foo)
description = strip_tags(foo.description)
html = Date.today.tuesday? ? "50% off! #{description}" : description
html.html_safe
end
end
This feels a bit wrong as well. For one, we’ve increased the number of public methods on our presenter by at least 4, and only really needed one of them. Two, we have little control over how we are stripping the tags, and so any unit tests we’ve written for our presenter must integrate and essentially test parts of Rails. What we really want is something that can do what strip_tags is doing. Luckily, and due Rails becoming more modular, we already something to do this for us in the Rails library html-scanner. Under the hood, strip_tag is, unless configured differently, passing your string down to the sanitize method on an instance of an HTML::FullSanitizer object. We can do something similar in our presenter:
require 'html/sanitizer'
class FooPresenter
def initialize(sanitizer=HTML::FullSanitizer.new)
@sanitizer = sanitizer
end
def description_for(foo)
description = @sanitizer.sanitize(foo.description)
html = Date.today.tuesday? ? "50% off! #{description}" : description
html.html_safe
end
end
Now we have an object that is easy to test purely as a unit, and also has the ability to be extended with different sanitizers.
While this works well with strip_tags, unfortunately not every helper in Rails is as nicely decoupled. The work being done in the number_to_* methods, for instance, are written completely in modules. It may be nice at some point to pull these into corresponding objects, but a short term solution could be to just have an object that includes the module:
class NumberCruncher
include ActionView::Helpers::NumberHelper
end
> NumberCruncher.new.number_to_currency(1)
=> "$1.00"
I asked my pair on my first day here at Pivotal.
That’s on purpose. A user story is a promise to have a conversation. When we start a story, we’ll have a discussion with the client to fill in the details.
Ok. So we’ll just ping them on Skype or something?
No. They’re sitting at the desk right over there.
In XP, the onsite customer is a domain expert that is part of the development team. Their responsibility is to answer questions, resolve disputes, and set small-scale priorities [1].
In past projects, contacting a client involved emails, IMs, or phone calls. My stories needed detailed descriptions. Description-less stories risked building the wrong thing. So I labeled them “blocked”, and project velocity suffered.
In my current project, having an onsite customer has made a huge impact.
Eliminating story descriptions has simplified iteration planning meetings. Just write down a short title and move on. Discuss the details later.
Constant client communication has helped avoid misunderstandings. Not once has a pair built the wrong thing. Developer time isn’t wasted.
Delivered stories rarely go untested for longer than an hour. A quicker turnaround has shortened system feedback time.
An onsite customer was one XP practice that was missing from my past projects. What client would be willing to give up one of their full-time employees? After four weeks of working on a team with an onsite customer, to me, the answer is clear: a client that wants their product to succeed.
[1] Kent Beck, Extreme Programming Explained: Embrace Change (Addison-Wesley Professional, 2000), 60.
Not a great deal of changes compared to 0.9x – mostly small behavior adjustments on Collection#set & Model#save.
Upgrading instructions: http://backbonejs.org/#upgrading