Jon Allured

Johnson on :before and :after in CSS; Clayton on Rails Config

2012-02-13T00:00:00-08:00

Johnson on :before and :after in CSS; Clayton on Rails Config

published Monday, February 13, 2012

Joshua Johnson writing for Design Shack explains how the :before and :after CSS pseudo-elements work. I was confused about why he was calling them pseudo-elements and not a pseudo-class like :hover or :active, so it was nice that he anticipated this confusion and started out by addressing it. The difference between these two parts of CSS turns out to be pretty simple:

pseudo-classes target an entire element, think a:hover – the entire link is styled
pseudo-elements target a part of an element, think p::first-letter – just the first letter of the p is styled

In the CSS3 spec, pseudo-elements use two colons and pseudo-classes just need one – prior to this clarification both types would use just one. Johnson then tells us that he usually sees :before, not ::before and explains that its because IE8 doesn’t understand the double-colon syntax and since the single-colon version still works, most developers use that form.

So, with these distinction out of the way, Johnson goes into what :before and :after are. They allow one to add content either before or after an element without having to actually add this content to the markup. You use this selector and then use the content property, like so:

.phoneNumber:before {
  content: "&#9742;";
}

This would add the phone glyph (☎) before any element with the phoneNumber class.

And then :after is the same way. This is a neat example that gives a simple idea of why one would use the pseudo-elements, but then his next example shows how fancy one can get with this technique by styling a button with just the barest amount of markup. The button example actually seems a little crazy to me but its impressive nonetheless.

Johnson finishes up by showing a couple obscure uses of :before and :after. First, using them to clear floats and second, to create pure-CSS shapes. This was a good write up and I appreciated the time he took to find out a little more about these selectors.

I’ve recently been thinking about configuring Rails apps mostly because I’m tired of having a file full of environment variables for all the apps I run locally that has to be loaded in my shell to match those at Heroku. What I wanted to move to was a setup where the config file for each environment could decide if it should use environment variables (production) or just parse them out of a YAML file not checked into the repo (development).

So, when I saw the post Josh Clayton did on injecting Rails configuration into tests the thing that stood out most was actually how he was using the config:

Doit::Application.config.default_creator

I’ve been doing this same thing another way – using the Rails object, so like this:

Rails.configuration.default_creator

Reading Josh’s post I realized these are both ways to accomplish the same thing.

But his point was more about testing with these configuration settings. What Clayton is saying is that you shouldn’t be stubbing at the application config level, instead inject a dependency on this information into your model and then test that. There are some good examples and I liked how he approached this.

Marston on Sinatra's Halt; Jones on Sinatra vs. Rails; Bernhardt on Learning Vim

2012-02-08T00:00:00-08:00

Marston on Sinatra’s Halt; Jones on Sinatra vs. Rails; Bernhardt on Learning Vim

published Wednesday, February 8, 2012

Myron Marston did a quick write up on why halt is so awesome in Sinatra. I’ve actually used it before, but its been a while, so this was a good reminder. Also, the way he demonstrated it with the different status codes depending on the error that happened was pretty sweet.

Darren Jones writing for Ruby Source explores the differences and similarities of Sinatra and Rails by asking around and writing up what people say. Having used both and experienced the pain of choosing Sinatra and regretting it later when things got more complex, many of the comments rang true. My main take away from this post and my own experience is that Sinatra can be a great tool to build an API or do a quick prototype, but as the scope and complexity increase you’ll quickly want some of the niceties of Rails.

Watched Destroy All Software 30: Some Vim Tips and really enjoyed it. Gary Bernhardt goes through some things that he thinks might help someone learn Vim and some strategies for pushing yourself to get better. One of his first pieces of advice is to look at the keyboard and find keys where you can’t name what they do in Vim and then find out. Go from the keys themselves to shifted keys to controlled keys.

He also talks about trying to train yourself to recognize when you are repeating yourself and practice pausing to think of a better way. I’m definitely guilty of repeating myself, I usually do press “j” over and over to move down a page, so I need to work on that.

Making URLs Pretty; Uncle Bob on SRP; Grimm on ActiveRecord Associations; Heilmann on classList

2012-02-07T00:00:00-08:00

Making URLs Pretty; Uncle Bob on SRP; Grimm on ActiveRecord Associations; Heilmann on classList

published Tuesday, February 7, 2012

Watched RailsCasts 314: Pretty URLs with FriendlyId and learned that Rails uses a method on its Models called #to_param to decide what to put in a show path. This means you can override it and use something besides an id:

class Post < ActiveRecord::Base
  def to_param
    post.title.parameterize
  end
end

# gives you this path:
/posts/title-of-post

But if you leave off the id, then your ActiveRecord#find is going to be a pain – this is where friendly_id comes in. You extend your model with FriendlyId and then you can use the friendly_id method to set which column to use in the url.

There’s an option to create slugs for your objects that will make your friendly urls even more friendly by taking that column and applying some formatting rules to it. You can also store the history of a slug’s value so that when you change it the old values will still work.

I was reading Uncle Bob’s post about running a retrospective on an app that’s partitioned into services. Its an interesting walk through of what happened and how it caused pain for the developers. He gets to a point where he’s reminding us about what the Single Responsibility Principle means. I usually think about that principle when I’m looking at a Class that does more than one thing, but as I was reading his definition I realized that there’s another side to it: grouping together things that change together. Kind of an “ah-ha” moment for me: I was only internalizing half of the principle.

Avdi Grimm reminds us of just how awesome #scoped is, this time in the context of wanting to define a method on a collection of ActiveRecord associations. Pretty neat.

Learned about the HTML classList property from a write up by Chris Heilmann. Its not implemented in every browser, IE being the glaring problem, but its still interesting.

This property is an array-like object with the classes on a given DOM node and it comes with a handful of helpful functions:

element.classList: returns an array of classes
element.classList.add('some-class'): add ‘some-class’ to element
element.classList.remove('another-class'): remove ‘another-class’ from element
element.classList.contains('some-class'): does element have class ‘some-class’ (returns boolean)
element.classList.toggle('some-class'): either add or remove ‘some-class’ on element, depending on whether its already on there

Hadn’t heard of this one before, so it was fun to play around with it in the console, works much better than the days of managing classes by hand!

Klabnik on Moving from Sinatra to Rails and Acceptance vs. Integration Tests

2012-02-06T00:00:00-08:00

Klabnik on Moving from Sinatra to Rails and Acceptance vs. Integration Tests

published Monday, February 6, 2012

I recently had a conversation with fellow Rocketeer Brian Dunn about the difference between Acceptance and Integration testing. I’ve always been a little fuzzy about what the two terms meant, but Steve Klabnik’s post about moving from Sinatra to Rails prompted me to finally bring it up.

What he helped me see is that Acceptance and Integration tests are similar in that they are written at a higher level than a Unit test, but Acceptance tests aren’t meant to interact with code at all. When you use Cucumber for this level of testing, that means an Integration test might look like this:

Given a translator that has been assigned a task
When I navigate to the assignement list
Then I should see an assignment for that task and translator

And the maybe its defined with something like this:

Given 'a translator that has been assigned a task' do
  @translator = Fabricate :translator
  @task = Fabricate :task
  @translator.assign @task
end

That would be a reasonable Integration test for this step, but wouldn’t cut it if we were writing an Acceptance test. For that type of test, we’d need to create the Translator, the Task and then assign it using only the interface, maybe something like this:

Given I create a new translator
And I fill out the translator creation form
And I create a new task
And I fill out the task creation form
And I create a new assignment
And I fill out the assignment form
When I navigate to the assignement list
Then I should see an assignment for that task and translator

And then you’d have a bunch of work to do to define these steps using only Capybara.

Or something like that, anyway – the point is that what is one easy step in an Integration test turns into a lot of steps taking nothing for granted in an Acceptance test.

Its no surprise that in the context of moving from Sinatra to Rails, Klabnik tells us that our Acceptance tests are our most valuable tool to make sure our code works the way we intend for it to work. In fact, he suggests evaluating how well your Acceptance tests cover the app and writing a few more of this type of test where you see spotty coverage.

He mentions that he normally writes only happy path Acceptance tests and then uses a term I hadn’t heard before: the sad path. Can’t believe I hadn’t run into that before.

I’m very much a fan of this idea that you should get quick wins and use that momentum to get to bigger problems later. I always find myself wanting to do the hardest stuff last and then when I get to it, I’ve built up a head of steam and I feel like I get it done better than if I had started it first.

Another thing that jumped out was his note about how Rails and Sinatra have different redirection methods – I’ve always been annoyed by this.

Klabnik advises us to resist the urge to simultaneously move code over and convert it to the Rails style – he’d rather see you move it over with as few modifications as possible, get it working and then refactor.

I’ve never had to make the move from Sinatra to Rails, but I think his ideas are pretty sound and would try this approach if this did come up in my work.

Hagemann on Testing Rake Tasks; SPDY in FireFox 11; RVM Using Git Flow

2012-02-05T00:00:00-08:00

Hagemann on Testing Rake Tasks; SPDY in FireFox 11; RVM Using Git Flow

published Sunday, February 5, 2012

Stephan Hagemann had a good post on testing Rake tasks. What I liked about it was the “before/after” structure of the post – first he shows the anti-pattern and then he describes the approach he prefers. This is a good model for technical posts of this nature and I will try to remember it for my own writing.

The content was great too – I’ve always been a little lost when it comes to testing Rake tasks, but Hagemann’s suggestions seem like good ones.

SPDY just landed in FireFox 11. SPDY is a protocol for transporting web content. You’ve probably heard of HTTP, another protocol for transporting web content, so what makes SPDY different? Its the way it prioritizes and multiplexes the downloading of web page elements such that only one connection is made to the server. The exact technical details are over my head, but this is good work that could make some headaches for web developers a little easier. I’m especially excited about it for mobile devices where server connections aren’t cheap over lousy 3G connections.

I first heard about it on an episode of Hypercritical and thought it was neat but maybe just a wacky Google experiment that would never go anywhere, so I was fairly surprised to see that Mozilla took a run at it for their Browser.

Its not an official spec yet, but its going that way – it will be interesting to see if its implemented by Opera, Microsoft or Apple, but I think its something to watch.

The RVM team switched to using the Git Flow approach to structuring their project and have finished the transition, so now you can run:

$ rvm get stable

And you’ll stay on the stable branch. Neato. Check that post for a few other changes to the behavior of RVM.

I had heard of Git Flow before, but took this as an opportunity to read up about it. After reading Vincent Driessen’s original post about Git Flow (above), I found Jeff Kreeftmeijer’s post on why he likes this approach so much. He talks about using the git extensions and how he uses them in various situations. I enjoyed thinking about another workflow and would be interested in trying this system in a future project.

The Simpleton Pattern; When to Include, When to Extend

2012-01-31T00:00:00-08:00

The Simpleton Pattern; When to Include, When to Extend

published Monday, January 30, 2012

After my post on the Singleton pattern, fellow Rocketeer Stephen Caudill directed me towards Steve Yegge’s post on the Simpleton Pattern. Its a fairly snarky post, but there’s real insight to be had. I think his main point is that the Singleton pattern is overused and that its usually bad design to use it because of its global nature.

Yegge says that the Singleton is actually a throwback to non OO programming, that it is an escape hatch one can use when OO gets too intense. He talks about how he loved this pattern and used it quite a bit until he realized that all he was doing was using these classes as namespaces for global functions. Its great to read criticism like this, helps me have a more well-rounded view of things.

I haven’t had much experience with writing Modules in Ruby and so I’ve always been a little confused about the difference between include and extend, but Aaron Lasseigne’s write up on the topic was really helpful. He starts out by giving us the common definition of when you use one or the other:

You include a module to add instance methods to a class and extend to add class methods.

He goes on to explain why this isn’t the whole story, staring with how instance and class methods are stored. So, given this class:

class Klass
  def foo; end
  def self.bar; end
end

You can find #foo and .bar like this:

Klass.new.methods - methods # => [:foo]
Klass.methods - Object.methods # => [:bar]
Klass.singleton_methods # => [:bar]

I had never seen Object#singleton_methods before and I got curious what else was out there, so I jumped over to irb and ran:

Object.methods.select {|method| method.to_s =~ /single/}
# => [:singleton_class, :singleton_methods, :define_singleton_method]

And this is when I remembered some conversations Brian Dunn (another Rocketeer) and I have had about the eigenclass. I went hunting for more information to make sure I was putting this together correctly and found a write up from Andrea Singh that confirmed it.

When .bar is defined for Klass, its actually being defined on the eigenclass of Klass, thus the singleton_methods method inspects this for methods and that’s what its returning.

Lasseigne then defines include and extend with this information in mind:

include: adds methods from the provided Module to the object

extend: calls include on the singleton class (eigenclass) of the object

Reading these two posts and their diagrams really helped clarify that the Eigenclass is just another name for the Singleton class that’s created when you define methods on an object and the relationship between Module instance methods and class methods with the thing that’s getting them mixed in.

Brown on Creational Design Patterns in Ruby

2012-01-30T00:00:00-08:00

Brown on Creational Design Patterns in Ruby

published Monday, January 30, 2012

I’ve read Gregory Brown’s post on structural design patterns in Ruby and I’ve also spent some time with a couple of his write ups focusing on just the Singleton pattern. Next I wanted to finish the rest of the creational patterns - as in the post on structural patterns, his aim is not to explain each pattern as much as it is to show some examples of the patterns in real Ruby code.

Multiton

This pattern shares some similarities with the Singleton, if fact its really just a Singleton where you want to have unique instances for each key used. The example Brown uses from Prawn was pretty clear and I was able to see the pattern shine through.

I hadn’t run into Hash.update before - its called on a hash and passed another hash and it combines them with the key/value pairs from the argument overriding those of the hash its called on.

Factory Method

To help describe this pattern, Brown starts by walking us through some code a student of his was writing. This code started as a typical Ruby class that had a boolean as an argument. It was quickly suggested that instead of this, a hash be used:

# starts this way
class AdjacencyMatrix
  def initialize(data, directed=false)
    # some code
  end
end

undirected_matrix = AdjacencyMatrix.new(data)
directed_matrix   = AdjacencyMatrix.new(data, true)

# refactored with an options hash
class AdjacencyMatrix
  def initialize(data, options)
    directed = options[:directed]
    # some code
  end
end

undirected_matrix = AdjacencyMatrix.new(data)
directed_matrix   = AdjacencyMatrix.new(data, :directed => true)

Having an options hash like this is a good start, but in this case it made sense to use the Factory pattern:

class AdjacencyMatrix
  class << self
    def undirected(data)
      new(data)
    end

    def directed(data)
      new(data,true)
    end

    private :new
  end

  def initialize(data, directed=false)
    #...
  end
end

undirected_matrix = AdjacencyMatrix.undirected(data)
directed_matrix   = AdjacencyMatrix.directed(data)

So the #undirected and #directed class methods are builder methods. Rather than calling #new, you call one of these and they instantiate your object in the desired state.

Abstract Factory

This one was harder to deal with. From what Brown says, this pattern doesn’t really make that much sense in Ruby because of “the flexible nature of Ruby’s type system”, whatever that means. All I really got from this one is that I probably don’t need to worry about it and that’s fine by me.

Builder

The Builder pattern is another one where Brown feels Ruby’s dynamic nature means its not necessary for some formal construct. Instead there’s a spirit of the Builder pattern that can be used:

[C]reate an abstract blueprint describing the steps of creating an object, and then allow many different implementations to actually carry out that process as long as they provide the necessary steps.

He gives us an example from code he’s written and it made sense, but didn’t really jump out at me as something I’ve had to deal with in my own code.

Prototype

The last pattern is another one where Brown doesn’t have much concrete to say. He talks about it in a theoretical way, but admits that he can’t come up with a meaningful example where it might be helpful in Ruby.

Reflections

With that Brown goes into some notes about writing this post and what he’s taken away from it. He talks about how he feels design patterns are an advanced topic that can be challenging for beginner and intermediate developers. I don’t know how Brown would judge me, but I felt like some of the patterns are pretty easy to get and others are vague and hard to get much out of.

For me the main thing is to be exposed to this stuff so that when it comes up on conversation with other developers, we have the same vocabulary with which to discuss design and Brown seems to agree with this.

Brown on the Singleton in Ruby

2012-01-27T00:00:00-08:00

Brown on the Singleton in Ruby

published Friday, January 27, 2012

I read the second post Gregory Brown did on design patterns in Ruby first, but I wanted to go back and read the first one on creational patterns. I ended up spending a lot of time working through just the Singleton pattern because he updated his thoughts there with another write up that was equally insightful and thorough.

A singleton is used when you only need one instance of a class. There is official support for this pattern in Ruby with the Singleton module in standard lib. I took a look there and saw this:

class Klass; include Singleton; end
a, b = Klass.instance, Klass.instance
a == b # => true
Klass.new # => NoMethodError - new is private ...

This shows what it means to be a Singleton in Ruby - once #instance is called and an instance of Klass is created, then all variables pointing to it are pointing at the same thing and you can’t new up another one. Note that when you call #instance the first time, #initialize gets called as if you had called #new.

Brown notes two main benefits of using the Singleton module:

instantiation is lazy evaluated
Ruby enforces the single instance limitation for you

And explains them:

The former provides a potential performance and memory bonus when the object never ends up getting used, and the latter helps prevent accidental object creation. Both of these things are nice to have, and it only takes a bit of extra effort make them happen.

I get the benefit of letting Ruby prevent you from accidentally creating another instance, but I don’t really see how there’s much to be gained from “a potential performance and memory bonus”. Seems like one object isn’t going to affect performance or memory that much and if it would, then maybe that’s a smell that you’re doing something wrong.

Next Brown talks about how he likes to implement this pattern in Ruby. He thinks the Singleton module is fine, but also maybe too literal; he prefers to just use a module and then define methods off of it.

Had to be reminded about what he was doing on line 2, with extend self - this is just a shortcut like class << self:

class Klass
  class << self
    def foo; :bear; end
  end
end

Klass.foo # => :bear

module Mod
  extend self

  def foo; :bear; end
end

Mod.foo # => :bear

So, both class << self and extend self are doing the same thing: we can write our Classes and Modules without having to preface our method definition with self.

Brown finishes up this section by reminding us that the Singleton pattern should be used sparingly because of its global nature:

[A Singleton’s global nature] makes them more difficult to test, easier to corrupt, and harder to isolate when it comes time to debug issues with them.

Then, after all that I went back and read his updated thoughts on Singletons. In this write up he explores seven ways to implement the pattern:

Using the Singleton module provided by the standard library
Using a class consisting of only class methods
Using a module consisting of only module methods
Using a module with module_function
Using a module with extend self
Using a bare instance of Object
Using a hand-rolled construct

I’ve discussed the first method above. Methods 3, 4 and 5 are close to the other method I described above with 2 being a slight variation on it. But then he goes into a couple strange areas, like using a bare instance of an Object or hand-rolling a new Ruby construct. My takeaway is actually that I prefer the 5th method, the one described second above: defining methods right on a Module and then just using it directly. It was a fun thought experiment to contemplate his Universe construct, but being that its purely theoretical, doesn’t really offer any practical help with Singletons.

Brown’s comments on avoiding Singletons and his reflections on writing about this pattern were very insightful. He talks about how there’s actually very little practical difference between these fancy approaches to Singletons and just newing up an instance of a normal Class and that really rings true to me. Seems like unless I’m in a very particular situation, I’ll probably just write a class and use an instance of it. If I need more than that, I’ll probably try the Module with extend self approach and see how far that gets me.

Oh and he describes modules like Math module as “Function bags”, which actually made me laugh out loud.

Helms on Imprecise Floats; Carroll on Services

2012-01-24T00:00:00-08:00

Helms on Imprecise Floats; Carroll on Services

published Tuesday, January 24, 2012

I’ve heard about Floating point numbers being flaky and I knew there was a perfectly logical reason for it, but I’ve never really groked it until reading Clemens Helms’ write up on the topic. I really like how he articulates this concept: Float numbers are a binary format, implemented right on the processor of your computer, this is why they’re so fast. When you use this format with a decimal number, its going to be converted from base 10 to base 2. This conversion can produce imprecise numbers in the same way that some decimal numbers aren’t precise.

And by precise numbers I’m talking about the difference between 1/3 and .3333 - the former is a number that can’t precisely be represented as a decimal, its an infinitely repeating series of the number three, but we usually just round it to some number of them, say four. So, to understand why Float isn’t always precise, you just have to remember that when some decimal numbers are converted to Float, they result in an imprecise binary number that’s going to get rounded.

Helm then goes on to give us a couple ideas about what to do when you need precision, one way is to pick a delta you can live with and another is to use BigDecimal, another number format in Ruby’s standard lib. I took a look at BigDecimal and in the documentation there’s a really easy way to see how Float can break:

(1.2 - 1.0) == 0.2 # => false

But this would return true if BigDecimal was used instead of Float.

Jared Carroll explores services and a service layer in Rails. He concludes that services can be helpful, but service layers are really only necessary when you need to support clients other than HTTP. I had never heard about these things, so I found the topic interesting, he starts out by reviewing what he means by a service:

[A] service is an action, not a thing. And instead of forcing the operation into an existing object, we should encapsulate it in a separate, stateless service.

There are three kinds of services, taken from what Eric Evans says in Domain-Driven Design:

Application Service: A service that provides non-infrastructure related operations that wouldn’t come up when discussing the domain model outside the context of software, i.e., in its natural environment.
Domain Service: A domain service scripts a use-case involving multiple domain objects. Forcing this logic into a domain object is awkward because these use-cases often involve rules outside the responsibility of any single object.
Infrastructure Service: An infrastructure service encapsulates access to an external system. Infrastructure services are often used by application and domain services.

Application Services are things like a report being generated - this code would be properly extracted to a service object and I’ve just this. I always wondered if there was a idiomatic way of doing this, what I’ve done is just call the object something like “Exporter” or “Reporter” and then hang methods off of that object that corresponded to the different exports or reports.

The Domain Service stood out to me as something that I’ve grappled with quite a bit in my own work. There are those times when what you’re working on involves different objects and the action doesn’t belong to any of these individual objects. At times I’ve just picked one and stuck the stuff there anyway, but more recently I’ve been creating a new object to deal with them and I guess those were services.

The two examples Carroll gives for the Infrastructure Service are emailing and message queueing, so had me thinking about ActionMailer and Delayed Job. This pattern type seems closest to a service layer, which is where we go next:

[A] service layer as an application’s boundary and set of available operations from the perspective of interfacing client layers. In other words, it’s your application’s API.

Carroll points to HTTP and JSON as the standard ways of communicating and feels that unless you need some other method of communication, you really don’t need a service layer. I know I was having a hard time thinking of a case where you’d need another method, so I’m just going to believe him.

Kellum on Pixels; Shaughnessy on Shared Strings

2012-01-23T00:00:00-08:00

Kellum on Pixels; Shaughnessy on Shared Strings

published Monday, January 23, 2012

Scott Kellum explores how devices where a pixel is not always a pixel are making the lives of designers even harder than they already were. He starts out by establishing some vocabulary:

The truth is that there are two different definitions of pixels: they can be the smallest unit a screen can support (a hardware pixel) or a pixel can be based on an optically consistent unit called a “reference pixel.”

[A hardware pixel is] the smallest point a screen can physically display and is usually comprised of red, green, and blue sub-pixels…it cannot be stretched, skewed, or subdivided.

The w3c currently defines the reference pixel as the standard for all pixel-based measurements. This new pixel should look exactly the same in all viewing situations.

Hardware pixels were clear to me, but I had a harder time understanding reference pixels until I took a look at Figure 1. A hardware pixel is the actual pixel bounded by the physical pixel square on the device while a reference pixel is used by the hardware pixels to draw things.

Next he talks about how you can use the device-pixel-ratio media query to identify devices with scaled pixels. He is able to use some media query magic to normalize two devices with the same number of hardware pixels, but different scaled pixels. Pretty neat and also, I’m glad I don’t have to deal with this stuff.

Pat Shaughnessy discusses how the Ruby interpreter uses an optimization called “copy on write” by diving deep into its code.

He starts off by outlining an example he used in another post he did on Ruby and Strings and shows us using a debug script that Ruby will try not to duplicate a string if it doesn’t need to. He is able to get down to the hexadecimal values and show the relationship between two Ruby variables that point to the same RString structure that itself points to one Heap String.

Then he shows how Object#dup will make two RString structures that are pointing to one Heap String. This is what a “Shared String” really is, so if you have this:

str = "Lorem ipsum dolor sit amet, consectetur adipisicing elit"
str2 = String.dup(str)

Then str and str2 both point to different RString structures and those in turn point to the same Heap String. But the RString structure that str2 points to is actually different from the RString str points to. The former has a pointer to the latter. So far, so good.

Next he goes into what happens when you start modifying that duplicate string. Turns out when you modify str2 the first thing that happens is that Ruby creates a copy of the heap data and removes the pointer connecting the two RString structures. Once that’s done, then it performs the modification. This is true for a modification like upcase, but it also applies to slice - it will create new heap data for the substring.

But this isn’t always true: if your slice is less than 24 characters long then you’ll get an Embedded String. Also, if your substring is longer than 24 characters, but includes all of the remaining characters, then Ruby does something else cool. Say you do this:

str = "Lorem ipsum dolor sit amet, consectetur adipisicing elit"
str2 = str[1..-1]

Then str2 will point to a different RString structure, but that structure will point to the same heap data, its just that its ptr value will be advanced one position.

He concludes by reminding us that in most cases, Ruby developers shouldn’t worry too much about these details, that the interpreter is there to do this stuff for us. Its interesting to know what’s going on behind the scenes and in certain edge cases, this knowledge could help you write faster programs, but mostly this feels like an academic exercise and its one that I really enjoyed.

JavaScript Everywhere; The Value of Thinking Aloud; 3D With Just the DOM; Bernhardt on Unix

2012-01-21T00:00:00-08:00

JavaScript Everywhere; The Value of Thinking Aloud; 3D With Just the DOM; Bernhardt on Unix

published Saturday, January 21, 2012

Luke Wroblewski does a great job articulating why JavaScript is so hot right now. It didn’t occur to me that MongoDB is really just JavaScript, but that’s the “J” in JSON, right? Reading this really makes me want to work on something with Node.

Nielsen talks about the value of thinking alound and reiterates something he’s said before:

Thinking aloud may be the single most valuable usability engineering method.

I know in my work, encouraging people to think aloud while they test something for me has always gleaned a lot of insight into things like positioning of elements on the page or flow of screens or even just labels that might not make sense. I’m a big believer in this idea. Here’s Nielsen’s official definition:

In a thinking aloud test, you ask test participants to use the system while continuously thinking out loud — that is, simply verbalizing their thoughts as they move through the user interface.

He goes on to note that its not always very natural for people to keep up a monologue of what they’re doing and helping them do this is one of the jobs of a test facilitator. I’ve actually seen this is action and can attest to both the truth of that assertion and the value of a good facilitator.

This is a fantastic write up on one of my favorite techniques for getting feedback on a project.

Steven Wittens does a write up for his blog’s most recent redesign and the tech he used to achieve the most bad-ass header I’ve seen in quite a while. But before I got to that, I had to look up a solid definition of parallax:

Parallax is a displacement or difference in the apparent position of an object viewed along two different lines of sight, and is measured by the angle or semi-angle of inclination between those two lines.

As with most visual things, its easier to see the definition than to read it, so check out the sweet animated gif on the Wikipedia page for parallax where this definition comes from.

Ok, so some of the details are over my head, but basically Witten wrote a CSS 3D Editor that he uses to create 3D effects with nothing but native HTML elements and some JavaScript, no WebGL required. Its cray-cray - go play around with the CSS 3D Editor he built (click and drag to move around, keyboard controls defined in the write up).

Oh, and if you have both Safari and Chrome, check out the page in both and see if you can detect a performance difference, I sure could.

Watched a great presentation from Gary Bernhardt on Unix where he talks about how to compose the command line. The first thing that jumped out at me was this great quote:

Half-assed is OK when you only need half of an ass.

Here he’s letting us off the hook on completely solving problems that aren’t our concern.

Then he goes into talking about what it means to be a programmable system and throws another quote at us:

The language used at each level of a stratified design has primatives, means of combination and means of abstraction appropriate to that level of detail.

So, there are three things needed for a truly programmable system and in the case of Unix, these break down like this:

Primatives:

Files
Binaries

Means of Composition:

Pipes
Loops
Subshells

Means of Abstraction:

Functions
Scripts

He walks through each giving examples and talking about how this all ties together. Made me think about the command line in a whole different way.

Something that I picked up was how Bernhardt was making shell functions and I didn’t know you could do that. I searched and found a write up that talks about shell functions:

$ bamf { echo 'still alive?'; }
$ bamf # => still alive?

So, that’s pretty cool and kind of obvious, but I never knew it before.

Back to the talk - after Bernhardt finishes going through the three sections on what makes up a programmable shell, he gives us a couple things to avoid:

Tar pit of immediacy
Proficiency fatalism

The tar pit is about getting stuck doing something one way and never reevaluating whether its the best way to go. He offers pair-programming as a way to keep you from getting stuck in this way.

Proficiency fatalism is where you see someone that’s great at something and think that you could never do what they can. This one is something that I’ve experienced and struggle with. Heck watching Bernhardt’s Destroy All Software series is an example of something that causes me to feel this way. But looking back helps me - I think about where I was at before I taught myself Rails and got serious about web development and its clear that I can pick this stuff up and there isn’t anything intrinsically different between me and someone that knows more than I do. Its actually quite liberating.

Then he gives us two things we should do:

Use more pipes and functions
Pay attention to how much ass you need

The first is about how sometimes its worth writing stupid lines just to learn and sear into your brain better ways of composing the shell. Maybe not appropriate while doing billable work, but on your own, try to come up with wacky one-liners because it will get you better at the shell.

The second is about quality and completeness, which he affectionately refers to as “ass” and I think its a great point. He talks about how there is actually a spectrum of quality, with something like the Software Craftsmanship movement on one side and something like Lean Startup on the other. Neither are right or wrong, but its up to us to know where we should be on this spectrum for the project we’re working on, or even just the problem in front of us at the moment.

Brown on Structural Design Patterns in Ruby

2012-01-20T00:00:00-08:00

Brown on Structural Design Patterns in Ruby

published Friday, January 20, 2012

Gregory Brown considers how the classic design patterns pertain to Ruby and explores how one could interpret them by giving some examples. This is the second part of a two-part series, this time focusing on the structural patterns. I’ve heard of the Design Patterns book, we have a copy at the office, but I’ve not read it. And I’ve read a little about the patterns, but I took this post as an opportunity to get a little better acquainted with them.

Adapter

This pattern made sense right away and had me thinking of places where I’ve seen. The example was really clear: there are a bunch of different Markdown libraries for Ruby, Mitko Kostov wrote Marky to sit in between them and your code. What you get is the ability to change which Markdown processor you use under the hood without actually needing to change any of your code. Marky abstracts away the details of each Markdown library’s implementation and instead you just write to the Adapter.

If you look at Marky’s README, there’s a list of “Adapters”, just pick one and you can convert some Markdown to html like this:

Marky.adapter = :maruku
Marky.to_html("Hello, Marky")

Easy, but it seems strange to me that Marky calls Maruku an adapter. Its Marky itself that’s the Adapter and Maruku is the library it sits in front of. I would have expected to see a list of Processors and would pick one like this:

Marky.processor = :maruku
Marky.to_html("Hello, Marky")

Either way, this is a neat little gem that serves as a nice example when explaining the Adapter pattern.

I was thinking about this pattern from the point of view of someone writing an Adapter and it occurred to me that this pattern has a side-effect: it encourages an Adapter author to only support the super-set of library features. If you have five libraries, but only two of them implement a certain feature, then it would be natural to ignore it when writing an Adapter for these libraries. Either they’ve all got a feature and your Adapter exposes it, or they don’t and you ignore it.

The other approach would be to only let clients of your Adapter who’ve picked a library with that feature use it. You’d have to maintain some code that knows which libraries support which features and raise when a client tries to do something that’s not implemented. This seems counter to the spirit of an Adapter to me.

Which leaves me thinking that the sane way to design an Adapter is to support only the super-set of features. That means that when you choose to use an Adapter rather than picking one of its underlying libraries, you should probably be doing it because you really need the ability to switch out the underlying library. If that’s not important to you, then its possible that just picking a library with the features you need would actually be better.

Bridge

I think its funny that Brown describes a bridge using the word “physically” - how exactly does a programming pattern physically do anything? Anyway…

I got far less out of this one. The SourceMaking article he linked to had a bit about describing a bridge by making a comparison about light switches and that did help build a mental model for this.

Then he goes on to give an example he feels is contrived and complain that its hard to figure out a purpose for this pattern in Ruby. Didn’t get much out of this one.

Composite

I was unsatisfied with the example here. As Brown said towards the end of this section, the example was pretty intense and I couldn’t see the pattern properly. I searched for another example and found a write up from Jim Weirich that gave an example that was much easier to wrap my head around.

Weirich uses Robert Martin’s programming problem called “Mark IV Coffee Maker” to help define the Composite pattern. He describes how a Boiler object is a composite of both a Heater and a Relief Valve. Then he says:

The Boiler becomes a single object to the brewer which just issues on/off commands to the boiler. The boiler is responsible for making sure all its subcomponents (the heater and the relief valve) are properly operated.

So the Brewer can just issue its on/off commands to our Boiler composite object, then the Boiler can handle the grunt work of figuring out how to talk to the objects that make it up.

This one is really interesting and I’ll be on the lookout for places where I can use it in my own work.

Proxy

As with the Adapter pattern, Brown gives us an example for this pattern from Rails and as such it wasn’t too hard to understand. A Proxy object sits in front of another object and in this way its similar to an Adapter. But this pattern implies that the Proxy can do some mutating where an Adapter is just abstracting the implementation.

The example here is how ActiveRecord does association collections, like has_many. So if a post has many comments, then you can do:

post.comments # => array of post's comments
post.comments.class # => Array

But you can also do:

post.comments.create(author: user, body: "Great post!")

And Array definitely does not implement #create, so what’s going on here is that #comments is actually a Proxy. It acts like an Array when it needs to, but is also able to do its own thing.

Brown shows us a couple ways to implement this pattern, the first uses delegate from standard lib and the second uses method_missing. He prefers using delegate, but wonders if Rails uses the method_missing approach.

I took a little dive into the Rails code and found ActiveRecord’s HasManyAssociation, which ends up using a CollectionProxy and sure enough, you’ll see method_missing implemented in there. Its worth reading through that code a little and seeing the trickery that gets these Proxies all their magic.

Decorator

These are similar to Proxies, but are typically used to add or extend the behavior of the object. Decorators are hot right now with gems like Draper and are something I have already been thinking about. Since Brown basically skips this one, I will too.

Facade

The Facade pattern is used when you want to abstract something to act like something else. So, he uses open_uri as his example because it acts as a Facade for File; its aim is to abstract working with a url into feeling like working with a file. I really liked this line:

It’s worth keeping in mind that pretty much every DSL you encounter is a Facade of some form or another.

This pattern also made sense right away and seems pretty easy to grok.

Flyweight

This pattern seems to be about optimizing memory. You can use this one to store what seems like a lot of data in a lighter weight way. The example given was about storing the font information for each letter separately and then when creating a string just look up each letter’s font info by the letter instead of re-creating it.

So given a string like “Hello World”, the font information for “l” would only be stored once, but the lighter weight character “l” appears three times. Brown concedes that this might not fit Flyweight exactly, but that its a good way to think about the higher level concepts.

Reflections

Brown’s reflections talk about how design patterns should help us have a common vocabulary when we’re talking about code, but that it might not be possible without creating new ones specifically for Ruby. I know that when I hear people talking about patterns, I often feel like the hardest part is making sure we’re talking about the same things. The ideas aren’t the hard part, its the communicating about them that can be difficult.

Delayed Job hits 3.0; Marston on Deprecating Legacy Code

2012-01-12T00:00:00-08:00

Delayed Job hits 3.0; Marston on Deprecating Legacy Code

published Thursday, January 12, 2012

Delayed Job went 3.0 recently with two major changes: named queues and callbacks on the lifecycle of a job. They also changed it so that the ActiveRecord backend is provided by a gem, which means one could provide another backend if they were so inclined.

I think the named queues are the only thing I’d use. This could give you a way to segment jobs and assign a different number of workers based on the importance of the jobs. Maybe you’d have a “normal” queue and an “important” queue and have more workers per job on the important one. Looks easy to use:

object.delay(:queue => 'important').method

Then if you’re using rake to work your jobs, just start your worker like this:

$ QUEUE=important rake jobs:work

They also fixed a couple bugs, but none of them were familiar to me.

Really excellent write-up of Myron Marston’s experience refactoring some legacy code. He gives us some great insight into the techniques they used, which were totally new to me. I love this idea that you could add a field to your user indicating if they should be using the old or new code and then the surprisingly few places in Rails where they needed to use this flag. Very clean and organized.

Blocks in JavaScript; HATEOAS in Rails; Davey's turbux; watchr for Ruby Koans; Using a Single Ampersand

2012-01-11T00:00:00-08:00

Blocks in JavaScript; HATEOAS in Rails; Davey’s turbux; watchr for Ruby Koans; Using a Single Ampersand

published Wednesday, January 11, 2012

If Yehuda Katz has it his way, JavaScript would get blocks and he supports his position with some examples.

A lot of this was over my head because the most interesting things I’ve done with JavaScript mostly involve DOM manipulation and some effects. I’ve never needed to work with JavaScript prototypes and have just a little experience with making an Object to encapsulate functionality. Still, this was an interesting read.

Actually the thing that stood out the most here was the use of try...finally in JavaScript - never knew you could do that! Looked it up and this clause works just like the ensure in Ruby’s begin...rescue statements.

Klabnik demonstrates how to implement HATEOAS in a Rails app using the Draper gem for the Presenter Pattern.

Fellow Rocketeer Josh Davey just released turbux and wrote up a post announcing it - with a video and everything! We’ve been using this for a while in the office and I really like this workflow. If you use tmux this is a must-have.

Another Rocketeer Adam Lowe reminded me about watchr and at the same time points out that its use would make doing the Ruby Koans much more pleasant. Good call.

Pan Thomakos explores the uses of the single ampersand operator, divided into two categories: the Binary Ampersand and the Unary Ampersand.

For the Binary Ampersand, most of the uses he reviews are weird and seem pretty theoretical. Not sure where one would use most of them. But the second example was pretty neat:

[1, 2, 3, 4, 5] & [1, 2, 6] # => [1, 2]

So, this returns a collection of the common elements between the two collections. Its just defined on Array, but I guess I never noticed it.

Then shit gets pretty real with the Unary Ampersand. He actually starts by describing Blocks and Procs in a way that I found really easy to understand. Again, some of this was pretty heady for me, but I did find something that I though was really cool. If you have a thing that you’re doing as a map you can use a Proc with the Unary Ampersand to reduce duplication:

# this
[1,2,3].map{ |x| x*2 }
[4,5,6].map{ |x| x*2 }

# can refactor to this
multiply = Proc.new{ |x| x*2 }
[1,2,3].map(&multiply)
[4,5,6].map(&multiply)

So that’s pretty cool. You can also define to_proc on an object and then pass that object.

Releases for Both Rspec and Rails

2012-01-10T00:00:00-08:00

Releases for Both Rspec and Rails

published Tuesday, January 10, 2012

Rspec recently got bumped to 2.8, a minor version release with some cool stuff.

rspec-core now has an option where you can run things in a random order:

$ rspec --order rand

This option “tells RSpec to run the groups in a random order, and then run the examples within each group in random order”.

We also get an init:

$ rspec -init

Which makes a .rspec file, a folder called “spec” and a helper file: “spec/spec_helper.rb”, so that’s neat.

Then the next day rspec-rails got a patch for a bug in Rails 3.2.0.rc2.

Speaking of which, Rails 3.2.0.rc2 was released.

What caught my eye here was that Rails 2.3-style plugins are being depreciated and will be removed from Rails 4.

Shaughnessy Explores Strings; Klabnik on What's Wrong With MVC

2012-01-09T00:00:00-08:00

Shaughnessy Explores Strings; Klabnik on What’s Wrong With MVC

published Monday, January 9, 2012

Pat Shaughnessy spent some time exploring how MRI actually processes strings and wrote up those results. He found that under the hood there are actually three types of Strings used:

Heap Strings
Shared Strings
Embedded Strings

A Heap String is one where the Ruby Interpreter saves the actual value of the string in something called “The Heap”. A Shared String is easy, its created when you do something like this:

string_one = "Some awesome string"
string_two = string_one

Ruby is smart enough to know that when you create string_two you really have the same string value as string_one, so rather than creating a new Heap String, it just points the second variable to the first Heap String.

The third type of string, the Embedded String is different from the first two because it avoids “The Heap” and instead embeds the value of the string right in the C Struct using a character array. But there’s a limit set for the size of this character array - the value stored can be no larger than 23 characters.

When a Heap String is created, a call to malloc happens and this is far slower than the creation of a character array, so Embedded Strings are faster than Heap Strings. Shared Strings are faster than either because all they are is a pointer to another string.

He’s got some benchmark data with nifty graphs, but that’s about it. He also acknowledges that it would be ridiculous to optimize any code for this quirk. Mostly I think he just enjoyed learning more about the internals of the Ruby Interpreter and I loved reading about his exploration.

Steve Klabnik takes a look at a few Rails components and shares his views about how they can mess up someone’s understanding of good Object-Oriented programming. He sees a few problems and discusses each in a different section.

ActiveRecord

Here he’s talking about how clunky it is to separate a Model name and its table name in the database. He points out that this coupling means that its “impossible to de-couple your persistence mechanism from your domain logic”.

The thing that jumped out at me in this section was the bit about how it took him a couple years to realize that you could have a model in your app that didn’t inherit from ActiveRecord - me too!

ActionController

The bad habits pointed out here are instance variables and logic in templates. I wonder what he’d think about how decent exposure doesn’t litter instance variables anywhere, is that better? I know I like it better.

Also, I’m not sure its fair to criticize ActionController for having 200 line method when you just said that ActiveRecord has encouraged skinny-controller, fat-model. This doesn’t seem like a strong argument to me because I don’t think anyone is arguing for 200 line methods in the controller.

ActionView

I didn’t think there was support for logic in templates - I thought we were all trying to minimize this as much as possible. Maybe what he’s really talking about is going even further and getting more Decorators in your code? Not sure what he’s talking about here, I think he had point, but didn’t spend enough time fleshing it out.

MVC

At this point he’s hit each initial in the MVC acronym, so really he’s unhappy with the whole.

Steve closes by reaffirming his love of Rails and saying that its because of this love that he feels compelled to criticize it. He acknowledges that his post is light on examples and promises more on the topic which is awesome because I’d like to know more about what he’s thinking here.

Preston-Werner at RubyConf 2011 on GitHub Flavored Ruby

2012-01-06T00:00:00-08:00

Preston-Werner at RubyConf 2011 on GitHub Flavored Ruby

published Friday, January 6, 2012

I just watched the video of Tom Preston-Werner at RubyConf 2011. His video was called “GitHub Flavored Ruby” and it was broken down into five parts that I took notes on individually.

Relentless Modularization

Here Tom’s talking about keeping your software small and the benefits this provides. One benefit that stood out was smaller software is cheaper to change. This is something that I’ve been struggling with on the project I’m currently on, so I enjoyed thinking about how this could resolve some of the things causing pain on that project.

When you sense that a component of your system might make an interesting open source library, extract it. Even if you have no intention of open-sourcing the library. This is de-coupling.

Readme Driven Development

Cowboy coding: the answer to Waterfall! Both approaches can produce software that doesn’t solve the problems they were created to solve.

Tom’s middle-ground for this is writing the README first, Readme Driven Development. What this technique does is force you to think about the end user of your library before you write any code so that you can make good decisions about its design. You’ll find yourself thinking about how it will work in code first, then you write that code.

So as to not confuse anyone, one thing you can do is to pick a point where your Readme.md looks pretty fleshed out and then move its contents to Spec.md. Then, as you actually code portions of the project, you can move content from the Spec file to the Readme file. This helps the person who comes to your half-implemented project see what’s done and what’s still left to do. Very interesting ideas. I had read Tom’s initial post on this linked above, but I enjoyed hearing him talk about what he likes about this approach.

RakeGem

A dependency-free template for making gems. Gives you some rake tasks that solve common needs of gem authors. What’s nice is that its just code in your repo, so you can change whatever you want about it.

TomDoc

He talks about the four levels of documentation:

line
code (methods and classes)
API
book

A distinction is made between documentation at the code level and at the API level. The audiences of each are different; the former is aimed at those in your code and latter is aimed at those trying to use this project.

TomDoc is code-level documentation.

Things to document:

what params does this method expected and what type are they
what does this method return
examples

I like these ideas, but I wish TomDoc was called something else…

Semantic Versioning

The goal of Semantic Versioning is for the three numbers representing each release of your software to communicate something about what was changed. For example, say you have version 1.2.3, then each number is:

1: Major
2: Minor
3: Patch

When you look at what you have to release, use this guide to decide how to increment your version number:

Major: backwards incompatible, big changes
Minor: backwards compatible, new functionality, big internal changes, may contain bug fixes
Patch: backwards compatible, bug fixes only

He called ~> the “spermy operator”, then clarified how it works, so if you have this:

gem fabrication ~> '1.2'

Then you’re saying that you require version 1.2 and any version up to but NOT including 2.0. If gem authors stuck to Semantic Versioning, then you’d know that your code wouldn’t break because any minor change should be backwards compatible and not change the methods you rely on. Those types of changes would be major and thus require a bump that your Gemfile wouldn’t allow.

Rails 4.0 Will Drop Ruby 1.8.7; Croak Evaluates Decorators

2012-01-03T00:00:00-08:00

Rails 4.0 Will Drop Ruby 1.8.7; Croak Evaluates Decorators

published Tuesday, January 3, 2012

Rails will stop supporting Ruby 1.8.7 with the 4.0 series. DHH notes, however, that they intend to keep to a 2-year release cycle, thus don’t look for 4.0 any time soon.

I watched Jeff Casimir’s talk on Decorators, then read about them a couple more times, but I really enjoyed Dan Croak’s evaluation on the topic.

He does a roundup of the four different types of Decorator implementations and that was helpful for getting a clearer idea of what exactly we’re talking about when we refer to the “Decorator Pattern”.

I also loved the places where Dan shares how he’s thinking about this area of Rails. In his conclusion he goes as far as outlining his plan for when to use which types of Decorators. He also notes other questions he’s still struggling with, like if we’re going to embrace Decorators, is there a use-case for classic Rails view helpers anymore?

Kosman on Better jQuery Code

2012-01-02T00:00:00-08:00

Kosman on Better jQuery Code

published Monday, January 2, 2012

24 Ways had one on writing less sucky jQuery and in the intro Scott Kosman talks about how its really easy to use jQuery to write spaghetti code. I’ve heard this term before, but never really knew what it meant other than the obvious implication that its something to avoid.

Wikipedia had this to say about spaghetti code:

Spaghetti code is a pejorative term for source code that has a complex and tangled control structure, especially one using many GOTOs, exceptions, threads, or other “unstructured” branching constructs.

There’s also an example there written in BASIC that shows an IF statement and a GOTO being used where a FOR loop makes much more sense. So the term spaghetti code is really just talking about hard to follow control flow.

With this distraction resolved, I got back to the article and learned some cool shit.

There are two ways of writing jQuery selectors that are always much faster than other ways:

$('#id');
$('p');

Under the hood these selectors are able to rely on native Javascript functions and thus are super quick. The former uses document.getElementById() and the latter uses document.getElementsByTagName().

The $('.class'); selector is going to be slow in browsers that don’t support document.getElementsByClassName(), so that’s IE8 and below. Use it when you are free to be a browser snob.

There’s more to it that Scott goes into, but my take-away was: try to write selectors that find your elements using native Javascript functions. If you can’t, at least try to use these faster selectors to get at a parent element and then throw a .find() on that to drill down further.

Oh and he reminds us that these selectors return a jQuery object that can be “cached” by setting it to a variable. So don’t be a dick and write the same selector three times causing three DOM lookups, either chain your actions on the first lookup or save the first lookup in a variable and use it instead.

Then he goes into his second topic, Event Delegation. Here he demonstrates how one might use delegation to improve performance by reducing 100 event listeners to 1 with the .on() event listener method introduced in jQuery 1.7. Cool stuff.

Finally, he goes into DOM Manipulation and we get a reminder on a much more performant way to iterate through a collection of image urls, create an element and append it to the DOM.

Edit Files in TextMate from a Remote Server

2011-12-24T00:00:00-08:00

Edit Files in TextMate from a Remote Server

published Saturday, December 24, 2011

TextMate 2 now includes a Ruby script that will allow one to edit files on a remote box locally in TextMate. The script needs to be installed on that server and then you need to do some configuration locally. I don’t know, seems like a lot of bullshit to go through.

Cowboying Some Code

2011-12-22T00:00:00-08:00

Cowboying Some Code

published Thursday, December 22, 2011

Just watched Destroy All Software 23: Spiking and Continuous Spiking, or as I’ll now refer to it, The One About Cowboying.

I liked his advice about knowing when to stop spiking. His suggestion is to choose a constraint like number of lines in the file and hold yourself to that. When you go over the number of lines, force yourself to throw something away and TDD the implementation from scratch.

Later he says something about how its fun to Cowboy some code and I totally agree. TDD is very satisfying, but so is just writing the damn thing.

Another choice bit was when he identified that spiking can help you know where to go next when you hit a spot in your loops where the next step is unclear.

Rails 3.2; Command Reuse; Fixed Position on Mobile; Ruby Metaprogramming

2011-12-20T00:00:00-08:00

Rails 3.2; Command Reuse; Fixed Position on Mobile; Ruby Metaprogramming

published Tuesday, December 20, 2011

DHH announced Rails 3.2, RC1 and highlighted a few of the cool new things that landed. What stood out to me was the bit about Active Record Store. More details please!

Jakob Nielsen reviews why command reuse or overloading a command is often confusing to users. The example about two search fields on the same page is something I’ve actually seen first-hand in user studies and worked very hard to eliminate at Allured.

I also found the part about confusion in Android with the home and back buttons pretty compelling. He gives the example of a magazine app that has a home button that will send you back to the app’s list of issues and another home button at the system-level that takes you back to your phone’s home screen.

This is exactly why I never liked Android, the best things about iOS is that when you’re in an app, the whole screen is for that app and the only way out is the one and only hardware button. This design side-steps lots of confusion and lets the app be in total control of what a user sees.

PPK does a nice little roundup of position: fixed implementations, with video! I’m not sure how I feel about this, but I do know its getting better. It wasn’t that long ago that you’d git a site with one of those goofy ‘toolbars’ that would just sit there covering up part of the screen.

I recently found out about the dynamic find_by methods from the great Matt Polito, and while reading a post by Pat Shaughnessy, I found out about the scoped_by dynamic methods.

There was more in his article about metaprogramming, for instance, I saw Enumerable#zip and didn’t know what it was, so I found out: it can merge two arrays:

[:a, :b].zip([:c, :d]) # => [[:a, :c], [:b, :d]]

So that’s neat. Worth a read also for his reminder about how to metaprogram so that ‘future-you’ wont be pissed at ‘present-you’.

Multiple Carets in TextMate 2.0; Default Scope

2011-12-19T00:00:00-08:00

Multiple Carets in TextMate 2.0; Default Scope

published Monday, December 19, 2011

Don’t get me wrong, I’m quickly learning to love VIM since that’s all we use at Hashrocket, but TextMate will always be the first text editor that I loved. I haven’t been following the Alpha that closely, but I did read about the new Multiple Caret features and I’m really excited about it, I think it looks pretty great.

Found out about default_scope on Destroy All Software 21: Coupling and Abstraction. When you do:

User.all

And you’ve got:

class User < ActiveRecord::Base
  default_scope where(active: true)
end

Then the all method will use that default and only return active users. Pretty neat.

Gregory warns though, that you can easily become coupled to this behavior in a bad way and advises that if you actually want to use this default, you might want to try using an alias instead:

class User < ActiveRecord::Base
  default_scope where(active: true)

  class << self
    alias_method :all_active_users, :all
  end
end

And then you can use User.all_active_users instead. What’s nice about this approach is that if you later want to change the default scope, you’ll notice that the all_active_users is using it and can make a better choice about your change.

Bigg on Debugging; Shaughnessy on Rails Commits; OmniAuth 1.0; Videos from Windy City Rails 2011

2011-12-18T00:00:00-08:00

Bigg on Debugging; Shaughnessy on Rails Commits; OmniAuth 1.0; Videos from Windy City Rails 2011

published Sunday, December 18, 2011

Watched this great screencast from Ryan Bigg on debugging. He goes through his steps to find the source of a TypeError: wrong argument type Module (expected Class) error and I really enjoyed watching it.

The first thing I picked up was a reminder that a Class cannot inherit from a Module, so this doesn’t work:

module Foo
end

class Bar < Foo
end

That exception mentioned above will get thrown. It was interesting watching Ryan find this problem and I learned a little about how Rails works along the way.

Another cool thing I took away was that you can do bundle show [gemname] and Bundler will spit back a path to that gem. This is a handy way to open the source for a gem in your editor. Try something like this:

vim `bundle show fabrication`

And you can follow a stack trace or try messing with something in the gem, whatever. Really easy.

Pay Shaughnessy takes us through some of his favorite Rails commits, trying to point out some things to keep in mind as you work on projects. I found Jose’s commit the most interesting, I really liked seeing this peek at how he approaches deprecation.

Oh, and we see that DHH loves us and added Array.preprend and Array.append to ActiveSupport, which is also cool.

OmniAuth recently went 1.0 and Ryan Bates takes us on a tour of using the Identity strategy for an app. You’d support this strategy when you want to provide users a way to log into your app separate from other providers. Maybe you’ve got a user that doesn’t have or doesn’t want to use their Twitter, Facebook or Google account with your app - this strategy allows them to just create an account with your app.

It occurred to me while watching this screencast that when I see ERB view templates now, they look really noisy and I actually have a hard time reading them. HAML has completely spoiled me.

Went through a few of the Windy City Rails 2011 talks. Watched a bit of the presentation Aaron gave about Regex and saw that he did a good job and was well received by the audience.

Then I watched most of Steve Klabnik’s talk about Literate Code and pulled out this quote:

“It seems like every time I type ‘git blame’ the asshole that wrote that terrible function is me.”

Thought that was funny. But I really did love his point that when we write software we have four audiences:

the computer
ourselves
the other (the person who will later maintain our code)
the user

And the fact that we have these different audiences with different needs means that we aren’t free to focus on and optimize for just one of them.

As an aside, I liked the bit where he was talking about how a definition of technical debit could be “screwing with future you”. I have definitely cursed “past-Jon” for some garbage he wrote that was in my way at the time. “Present-Jon” tends to think “past-Jon” is a lazy asshole and too often he’s right.

I liked the part where he talked about how much people who make websites have to know. He mentioned all the things we have to know as developers: HTML, CSS, JS, Ruby, CoffeeScript, LESS. Validates my feelings that the web is just a really interesting place to be working right now.

Another quote I liked was:

If you’re doing reg-green-refactor, you fail thousands of times a day.

He was talking about how terminology can trip you up. The example he gave was working with some English Academics and their take vs a developer’s take on code being “broken”. I’ve seen this while working in the Publishing industry as a developer, but the thing I liked was how deftly he articulated something that’s interesting to consider: developers that test are used to failure and have, in fact, embraced it as a means to write good code. There’s something poetic about that.

Notes Help You Learn; Changing Directories

2011-12-17T00:00:00-08:00

Notes Help You Learn; Changing Directories

published Saturday, December 17, 2011

I read about the value of taking notes and was inspired to try taking notes while I read. This topic reminded me of that part of Junior High where we were taught note taking styles. One thing I remember was folding a paper in half and then writing stuff on one side or the other.

I struggle with retaining all the shit I read, so if this help, then great. And I’m going to post these notes here.

During my audition week at Hashrocket I saw someone type this at the command line:

$ cd ..; cd -

They were working with RVM and they had just cloned down a repo, but the --create flag wasn’t in the .rvmrc file so they had the right Ruby, but no Gemset. You can fix this by creating the Gemset, but its better to add the flag to the rc file. Once you’ve done that, you can run the command above and you’ll cd up a level and then back down and trigger the .rvmrc file again. I could look at it and know that’s probably what it did, but I never really knew what that last bit was all about.

But to take a small step back, the first thing to know is that ; can be used to input a series of commands to run in sequence. Then, while reading a list of unix commands I noticed the last bit. The cd - command returns you to the previous working directory. Mystery solved.

There were some other interesting things in there, have a look!

Playing Around with Content Editable in Rails

2011-11-28T00:00:00-08:00

Playing Around with Content Editable in Rails

published Monday, November 28, 2011

I recently tried working with the contenteditable attribute on an internal project at Hashrocket with my pair Dave Lyon and wanted to share what I thought about the experience. Our use case was simple:

In order to remember things about a Project
As a Project Manager on the list of Projects page
I want to make or edit a Note

Said another way, we’ve got a Project list page, each Project can have a Note and we want to be able to create a Note for a given project or edit an existing Note. For such a case you might make a bunch of <textarea> tags and then wrap them in forms or maybe bind to blur and either create or update a Note all AJAXey.

But this was an internal project and we wanted to try something different. We went through a couple different ideas, starting with something like this:

<p contenteditable="true" class="note">Note content here!</p>

We created an event handler to fire on blur and sent the content of the <p> tag to the server. But it wasn’t long before we hit enter while editing that <p> tag and found that new <div> tags were being created. That didn’t work like we wanted, so then we wrapped the <p> with a <section>, like so:

<section contenteditable="true" class="note">
  <p>Note content here!</p>
</section>

This way when you hit enter and create more <p> tags, they’d be contained inside the parent and we could send the content of <section> to the server. That was closer, but didn’t feel quite right. Next we had the idea to just use a <ul>, like this:

<ul contenteditable="true" class="note">
  <li>Note content here!</li>
</ul>

We liked this because then we’d just store the <li> tags in the database and it was nice and clean. I threw together a little demo page you can use to play around with our different approaches.

My take away here is that contenteditable is really only suitable for cases where you actually want HTML nodes to be created. Its perfect for something like a WYSIWYG editor or the Mercury Editor, things that aim to allow editing of a page right in the page. But for something like what we were doing, I think it was overkill.

Also, I’m not completely comfortable with its cross-browser support. I don’t have access to IE anymore, but I was able to experiment with Chrome, Safari and FireFox. From what I could tell the two WebKit browsers were fairly consistent in how they implemented the details of this attribute, but FireFox does some different things. For instance, <br> tags seem to be added at the end of everything.

Still, contenteditable is a cool attribute and I was glad to learn a little more about it. Give that demo a whirl and consider it the next time you need something like this.

Keeping a Live Website in Sync with a Local Version, Part Two

2011-08-08T00:00:00-07:00

Keeping a Live Website in Sync with a Local Version, Part Two

published Monday, August 8, 2011

This part covers the technical aspects of a project I worked on to keep a live website in sync with a local version, the first part covers it from a business-level perspective.

I created a system for keeping a live version of a website in sync with a local one. I use a Ruby script activated by Cron to compare and sync the two versions and then get this out to everyone using the site by sharing a DropBox folder. A xml file, dubbed a Castlist, is used to compare last updated dates.

The Castlist File

In order for the Ruby script to be able to compare assets in the live and local versions of the site, I used an XML file - here’s an example:

<?xml version="1.0" encoding="UTF-8"?>
<castlist>
	<templates>
		<template id="223349" updated_at="2011-04-27 16:05:03.0" name="dmk_bottom" />
		<template id="224294" updated_at="2011-06-09 11:04:20.0" name="dmk_castlist" />
		... [ more templates ] ...
	</templates>
	<assets>
		<asset content_type="html" id="100466409" updated_at="2011-04-28 12:29:30.0" path="http://mediakit.skininc.com/index.html" />
		<asset content_type="html" id="102168174" updated_at="2010-11-04 08:45:03.0" path="http://mediakit.skininc.com/about/index.html" />
		<asset content_type="html" id="100467204" updated_at="2011-06-14 10:44:22.0" path="http://mediakit.skininc.com/advertising/index.html" />
		<asset content_type="css" id="020" updated_at="2007-07-07 02:00:00.0" path="http://s3.amazonaws.com/abm-assets/css/base.css" />
		<asset content_type="css" id="021" updated_at="2007-07-07 02:00:00.0" path="http://s3.amazonaws.com/abm-assets/css/si-brand-mini.css" />
		<asset content_type="js" id="026" updated_at="2007-07-07 02:00:00.0" path="http://s3.amazonaws.com/abm-assets/js/dmk/behavior.js" />
		... [ more assets ] ...
	</assets>
</castlist>

There are two types of things I need to compare - templates and assets. Assets are the html, css and js files that make up the site, but the templates are a little more complicated. If I only had to compare the assets, then I actually wouldn’t need the XML file at all, I could probably use the Last-Modified html header and be good to go.

The problem is that I don’t want to rely on my CMS for anything, I want my solution to be independent from anything I haven’t written. I can’t write Java (its a Java-based platform) or anything fancy like that, but I can use their templating engine to report on the state of the templates themselves, so that’s what I did. The Castlist file serves as the API of the CMS so that the script knows where things stand.

Ruby Gems Used

To write the Ruby script I used just two gems: Nokogiri and Dropbox. Nokogiri to make parsing the XML castlist files easy and Dropbox to work with the Dropbox API.

Script Overview

The main classes are Comparer, Syncer and Fixer. The overall flow of the script goes something like this: initialize a Comparer and a Syncer and see if there’s a major change. A major change is something at the template level (like maybe something in navigation or a header image) that would require all pages to be refreshed. If not, then just look for stale or new pages.

Then the Syncer we initialized earlier makes a Fixer object and uploads fixed files through the DropBox API.

Finally, we use the Comparer to update the local Castlist as a record of what’s been changed (so we don’t do the same thing over and over).

The Comparer Method

When the Comparer class is initialized it sets two instance variables called live and local to Nokogiri documents representing the live and local version of the Castlist files. These attributes are used by other instance methods to detect major changes, stale files and new files. The major_change? method is the first that’s called and it looks like this:

def major_change?
  @live.root.css("template").detect do |live_node|
    local_node = @local.root.css("template##{live_node.attributes['id']}").first
    live_node.attributes['updated_at'].to_s != local_node.attributes['updated_at'].to_s
  end
end

So, we just iterate over the live Nokogiri document looking for templates that don’t have matching updated_at dates. If one is found, then we have a major change and need to drop all the content and crawl the live site all over again. We use the live\_urls method for that:

def live_urls
  @live.root.css("asset").map { |node| node.attributes['path'].to_s }
end

Not too much here, we’re just finding all the assets in the live Castlist and then using map to convert them to a list of urls, which is what we’ll be passing off to Syncer later.

But normally we wont have a major change, so then the next things to look for are stale files (files whose live version is newer than its local version) and new files that aren’t in the local version. The stale_urls method looks like this:

def stale_urls
  stale_nodes = @live.root.css('asset').select do |live_node|
    local_node = @local.root.css("asset##{live_node.attributes['id']}").first
    if local_node
      live_node.attributes['updated_at'].to_s != local_node.attributes['updated_at'].to_s
    else
      false
    end
  end

  stale_nodes.map { |node| node.attributes['path'].to_s }
end

We’re iterating over the live Nokogiri document once again and as in major\_change we’re interested in the difference between the live and local version updated\_at dates. The files where these don’t match are thrown into stale_nodes which we then map to just the paths.

Last thing to check for are new urls, here’s that method:

def new_urls
  new_nodes = @live.root.css('asset').select do |live_node|
    @local.root.css("asset##{live_node.attributes['id']}").count == 0
  end

  new_nodes.map { |node| node.attributes['path'].to_s }
end

Similar to the above methods: we’re iterating over that same list of Nokogiri documents and once we find the elements we want, we use map to get just the paths of the files we’re interested in. The only difference here is that we’re using the result of the Nokogiri css method to decide if this file already exists. If not, then its picked.

So, these four methods are used to come up with an array of urls that need to be updated. In the case of a major change, this is really all of them and in the other cases, its just a subset of them.

The Syncer Method

The Syncer class is what connects to DropBox through their API and actually does the uploading. Upon initialization, it creates a instance variable called session that uses Dropbox::Session.deserialize to reestablish the connection. Once connected, we wait for Comparer to feed us a list of urls and then the upload_files method gets to work:

def upload_files(urls)
  fixer = Fixer.new

  urls.each do |url|
    file_path, filename, extension = /com(.*\/)([\w\-]+\.(\w+))/.match(url).captures
    clean_data = fixer.clean(url, extension)
    upload_file(clean_data, @local_path + file_path, filename)
  end

  fixer.found_files.each do |url|
    file_path, filename, extension = /com(.*\/)([\w\-]+\.(\w+))/.match(url).captures
    clean_data = fixer.clean(url, extension)
    upload_file(clean_data, @local_path + file_path, filename)
  end
end

I’ll get into Fixer in the next section, but for now just know that it takes our data and spits it back out cleaned up. The other thing that Fixer does is look for more files that will need to be uploaded. This is important, so I’ll go into that more now.

The Castlist is a manifest of sorts. Its a list of the assets that make up a website, but its not exhaustive and it shouldn’t be. If we were limited to only those assets that appear in the Castlist, then every time a new image is needed, we’d need to add this to the Castlist. On a brochure website meant to sell ads, this would make running the site too slow. Further the people working on the content of the site are not programmers and know nothing about how CAST operates. All they know is how to edit pages in the CMS to make changes on the live websites.

And that’s all they should care about. The Castlist is kept to just the elements of the site that are fairly stable. Things like the webpages and the css and js files that make it up. The exact elements on those pages can change without any affect on how CAST works. To support this, CAST must crawl the pages that make up the site and that’s what fixer.found_files is all about.

The upload_files method is merely a controller here - it instantiates a Fixer, iterates over the urls it gets from the Comparer and the urls Fixer finds and then gets this content uploaded. The actual work happens in the Fixer class.

The Fixer Method

Since we can’t rely on the Castlist to be a complete list of all assets on the site, we have to crawl pages and look for new things to download. But while we’re crawling we should also change all absolute paths to relative ones. These are the two things the Fixer class does - we’ll start with a method used to fix paths.

The path problem is pretty straightforward: on the live website, I make all paths absolute so that CAST can take the URL and retrieve the asset, but that’s not going to work on the local copy where you don’t have an internet connection, so the asset needs to be downloaded and the path needs to be altered to be relative. To do this I wrote the find_relative_path method:

def find_relative_path(url)
  steps = url.gsub(/http:\/\/mediakit.\w+.com\//, '').split('/').count - 1
  '../' * steps
end

We take the url of the file we’re working with, remove the host and then count how many slashes we see. Subtract one from that number and use the juicy string multiplication we get in Ruby to return a string that’s just a bunch of path changes. This is then used while we crawl.

When Fixer is instantiated it creates an instance variable called found_files that’s going to be where we put assets we find while crawling. The crawling starts with the clean method:

def clean(url, ext)
  data = Net::HTTP.get URI.parse(url)
	
  case ext
  when 'css'
    scan_for_images(data)
  when 'html'
    relative_path = self.find_relative_path(url)
    data.gsub!(/(http:\/\/mediakit\.\w+\.com\/|https:\/\/s3\.amazonaws\.com\/)/, relative_path)
    scan_for_files(data, relative_path)
  end

  return data
end

The clean method is acting as a controller here - its job is to fetch the data using url and then call the right crawling method based on what type of file it is. Along the way we address paths using the relative path we found earlier.

Since our crawling is going to be slightly different depending on which type of file we’re working with, we fork the code here using the file extension. For a file that’s html, we use the scan_for_files method to crawl:

def scan_for_files(data, relative_path)
  while data =~ /(href|src)\=\"(http:\/\/media.\w+.com\/([\w\-\/\.]+))\"/ do
    @found_files << $2 unless @found_files.include?($2)
    data.sub!($2, relative_path + $3)
  end
end

The idea here is to find all nodes with a href or src attribute, add that attribute’s value to our found_files array and then update the path using our relative path.

If we’re working with a css file, then we use the scan_for_images method:

def scan_for_images(data)
  data.lines do |line|
    if line =~ /url\(\"\.\.([\w\-\/\.]+)\"\)/
      url = 'http://s3.amazonaws.com/abm-assets' + $1
      @found_files << url unless @found_files.include?(url)
    end
  end
end

As with the other scan method, we’re looking for assets we don’t already know about but in the CSS we’re using relative paths already, so we just have to add them to the found_files array.

Deploying the Script

While writing this script, I would just jump into Terminal and run it as I needed to check something, but once I was ready to actually start depending on this thing, I needed a way to run it on a schedule.

We happened to have a spare MacMini in the office that wasn’t being used for anything important, so I commandeered it to serve as our CAST server. After a quick install of Git and RVM, I just cloned the repo, installed the couple Gem dependencies and got Ruby 1.9.2 installed.

For running the script on a schedule, I turned to my old frenemy Cron. I had never attempted something like this, so after some research (Googling), I found that I could run Bash commands as easily as anything else I’ve done with Cron and you could even run a series of commands by separating them with semicolons. Here’s how I’ve got Cron running this script:

0 * * * * /bin/bash -l -c 'rvm 1.9.2-p180@cast; cd /Users/jon/Projects/abm/cast/; ruby cast.rb > logs/result.log'

Every hour, on the hour with results logged to a log file that just keeps over-writing itself, all within the comfy confines of RVM with a suitable Gemset for this project. Easy in retrospect, but quite a pain to figure out at the time!

Fire and Forget

This project went through one re-write about a year in, but has mostly been a fire-and-forget type of project. I remote into the MacMini every once in a while to run Software Update, but other than that its very hands off.

If you’re interested in finding out more about the business-level strategy about this project, please read Part One.

Keeping a Live Website in Sync with a Local Version, Part One

2011-08-08T00:00:00-07:00

Keeping a Live Website in Sync with a Local Version, Part One

published Monday, August 8, 2011

This part covers a project I worked on to keep a live website in sync with a local version from a business-level perspective, the second part covers the technical aspects of the project.

Each year Publishing companies produce something called a Media Kit (also called a Media Planner) - its an important tool salesreps use to help them sell advertising. Its a marketing piece that is responsible for:

conveying the brand
establishing credibility
describing the audience reached
laying out all the brand’s products
giving price information
detailing some ad material requirements

A Media Kit’s audience is both long-time customers and those that have never done business with the company. It should serve as a document that can be reviewed with a customer in person or mailed out to a prospect. It should be attractive and full of calls to action. Its one of the most important documents to come out of the Marketing Department and its typically quite expensive both to print and to mail.

Allured Business Media wanted to take a different approach for their 2011 Media Kit - they wanted to take the content of the Media Kit and create a brochure-style website that reps could use just the same way they’ve used the physical Media Kit. They wanted to digitize their printed Media Kit.

The Hidden Requirement

The digitizing process was started by deconstructing the piece and building an Information Architecture. We identified that good content always seems to get cut from the printed Media Kit due to size or money constraints and thought about what made sense to add back in now we no longer had these types of constraints.

A card sort helped us think about how different pieces of content were related and revealed what primary navigation to use. Wireframes were developed and final content was written, edited, and rewritten. What we ended up with was a great brochure site managed by our existing CMS system. Easy.

But during the planning phase we discovered a hidden requirement: reps don’t always have an internet connection when they need to show their Media Kit to customers. Take tradeshows as an example: wireless internet access is often expensive and flaky when its offered at all, especially internationally. But tradeshows are an excellent opportunity to interact with customers, so not having something to work with in this situation wasn’t acceptable. It was imperative that whatever we ended up with was available without an internet connection.

Let’s dig into this requirement a little, we needed this site to be:

available when the internet isn’t
updated along with the live version
as transparent as possible to both the salesrep who uses the site and the Marketing team who updates the content

What I came up with to solve this problem was really two things:

a Ruby script that crawls the live version of the site and once the site is uploaded, continues to ping the live version looking for changes
a shared DropBox folder that accepts these uploads using their API

A CAST System

I call this solution CAST - Compare and Sync Tool. It compares the live and local version of a site and keeps them in sync. To facilitate the comparing I came up with a type of file called a Castlist. A Castlist is just XML and is a list of the assets on a site with the last updated date of each. Consider the Castlist an external API from the CMS meant to be consumed by the Ruby script.

The Ruby script parses the Castlist from the live site and compares it to a Castlist that represents the current state of the local copy. When it detects that these lists are out of sync, it grabs the updates, posts them to the shared Dropbox folder and updates the local Castlist. Then whenever any DropBox user that’s included in that shared folder connects to the internet, these updates are automatically downloaded to their computer and their local copy of the site is updated as well.

A Seamless Experience

The reps love the fact that when on the road they have access to this backup site. They don’t always know what they are walking into when they arrive at a customer’s office, but they know that even if they aren’t going to be able to connect to the internet, they’ll be able to go over their Media Kit website.

Its a very seamless experience for reps and those in Marketing and I haven’t had a single compliant - it just works.

If you’re interested in more of the technical details, please read Part Two.

Using Devise for Admin Accounts

2011-04-30T00:00:00-07:00

Using Devise for Admin Accounts

published Saturday, April 30, 2011

I use Devise on almost every Rails project I work on and wanted to share some things I’ve learned about using it - specifically, how I use it for Admin accounts. Devise is a gem that creates user models and handles all the authentication that goes along with them. It also does things like password retrieval and account confirmations and it does all this in a very friendly, modular way where you can pick which parts your app needs. The team working on it has done a fabulous job with not only the code but also the documentation. I can’t recommend it highly enough or thank them enough for what they’ve contributed to the Rails community.

One thing you’ll probably run into while building a typical app using this gem is needing a way to protect screens so that only administrators can get to them. Many CRUD screens, reports and anything related to the content are all prime candidates to get some admin love. There’s a page on the Devise wiki explaining two techniques you can use to create Admin accounts and you should start by reading that.

You Really Need an Admin Model

The two techniques described are:

create a separate Admin model
add an admin boolean to your existing User model

There are always exceptions and I’m glad they mention the second approach, but I find it completely unrealistic. Your project doesn’t have to get very complicated before you’ll wish that you had your own model.

Its clean to start with something like if current_user.admin? and I think that clarity and the ease of just running a quick migration could be attractive to someone starting out, but its not long before you find yourself with a mess like this:

if current_user.admin? and !current_user.reports_only? and current_user.edit_content?

My advice is to take the plunge and do an Admin model right off the bat. You might feel like its a waste, like its more than you need, but if requirements change (don’t they always?) and a little more complexity is introduced, you’ll be glad you have a separate model.

You Might Need a Permission Library

This piece talks about light permission needs - I’m talking about like three cases here, nothing crazy. If you have really complicated permission needs, you’ll want to pursue other options, something like CanCan. There’s even a page on the Devise wiki to help you get started, so check that out.

But here, we’re just talking about basic permission needs.

Different Kinds of Admin

Its just going to happen, you’re going to end up with different kinds of Admin accounts. It happens because there will be people that should have access to one thing but not another. You’ll have people in the Marketing department that need to edit content, but they shouldn’t see your CRUD screens for managing User objects or maybe you’ve got raw scaffold pages for some objects that expose ids or something like that.

You’ll have someone from Accounting that just needs to run a report every month or a manager that wants to see a list of new accounts and they shouldn’t be let anywhere near content, not to mention your screens.

You’ll continue to create screens that are easier than the command line for things you do frequently and you aren’t going to want anyone messing around in there besides people that know what they are doing.

You could create a different Devise user type of each of these, but I find that approach ends up being too much. And when there are overlaps about who can see what, its weird to code. Before we move on, lets summarize:

its important to have an Admin model so that as things get more complex you have something to hang some logic on
there are different kinds of admin users, but don’t go crazy and create a model for each type
the easiest type of admin is the business person who just has access to run reports
then you’ve got you: you have access to everything
finally, you’ve got the normal admin, they don’t see your screens, but they can edit some content and run reports too

Generating Your Admin

This is the Rails Generator command I use:

$ rails g devise Admin god_mode:boolean reports_only:boolean

I use god_mode to indicate that its me or another programmer and I use reports_only to indicate a user that shouldn’t be editing stuff, just running reports. If an Admin has false for both of these then they are the normal Admin that can edit content and run reports but don’t have access to programmer stuff. Easy.

The Admin Model

The suggestion from the wiki is to use the :trackable, :timeoutable and :lockable modules, which I think its too much, but review each and see what’s right for your project. Choices like this are what’s great about Devise - if you have a need for these things, then you can easily mix them in.

But for me, I end up with a model that looks like this:

class Admin < ActiveRecord::Base
  devise :database_authenticatable, :rememberable
  attr_accessible :email, :password, :password_confirmation, :god_mode, :reports_only
end

So, I do add the :rememberable module because I like it and more importantly the Marketing and Accounting people like it.

I think its important to point out something here: we’re not including the :registerable module, which means routes like /admins/sign_up aren’t going to work. This is one of the ways you are protecting yourself. Admin accounts can only be created from the command line with a command like:

>> Admin.create(:email => 'user@domain.com', :password => 'shhhhh', :god_mode => true, :reports_only => false)</code></pre>

The Admin Migration

Almost there, but before we run the migration that the Generator created for us, the wiki guides us to remove a few things. I like to add defaults for the two booleans, so my migration looks like this:

class DeviseCreateAdmins < ActiveRecord::Migration
  def self.up
    create_table(:admins) do |t|
      t.database_authenticatable :null => false
      t.rememberable
      t.boolean :god_mode, :default => false
      t.boolean :reports_only, :default => false
      t.timestamps
    end
  end

  def self.down
    drop_table :admins
  end
end

With your migration updated, you should be all set to run a rake db:migrate and then go to the console and create an Admin account for yourself.

You Will Need Views

Just a couple more things to finish. I like to go verify that Devise added the route correctly and actually I usually end up shifting things around because I like to see the Admin route right next to the User route. Not a big deal, just make sure everything’s cool in your routes.rb file.

Next its time to talk about views. Lets assume you’re reading this before you implement, that’ll mean that you haven’t generated any views yet and you can issue a command like this:

$ rails g devise:views admins

The Devise README covers this under the aptly named Configuring Views heading - go read all the juicy details. What you want is for all your User views to live under /app/views/users and all your Admin views to live under /app/views/admins.

If you are reading this while in the middle of development and you’ve already generated views for your User model, they will be under /app/views/devise, but that’s ok, you can still issue the above command and you’ll get your Admin views under /app/views/admins - just remember where each set of views lives and you’ll be all good.

Now Use It

The obvious way to use all this is to add the default Devise before filter:

before_filter :authenticate_admin!

Any controller protected that way will redirect to the sign in page unless an Admin is logged in. You can always use either the only or the except keywords to pick out controller actions that aren’t Admin only. This level of protection lets Marketing, Accounting and you all in.

For your stuff you could add another before filter like this:

before_filter :ensure_god_mode

def ensure_god_mode
  redirect_to admin_root_path unless current_admin.god_mode?
end

That’ll make sure only you and your fellow programmers have access.

For the Accounting people, I tend to use a different approach. For them, I end up blocking things at the view level. I’ll have an Admin dashboard kind of page that lists things Admin can do and this is how I block them:

<p>Here are the things you can do:</p>
<ul>
  <li>[something every admin can do]</li>
  <% unless current_admin.reports_only %>
  <li>[something business people shouldn't mess with, maybe a link to edit content?]</li>
  <% end %>
  <li>[another thing any admin can do, maybe a report?]</li>
</ul>

There are lots of ways to use your Admin model and the booleans, theses are just a couple patterns I’ve seen myself using.

One Last Fun Thing

Hopefully these notes will help someone figure out how to create Admin accounts that work for their project, I know I’ve been happy with this approach. I like to keep things fun with my code, so the last thing I wanted to share is an addition I make to the application layout file:

<%= "<p id=\"godModeNotice\">GOD MODE ACTIVE!</p>".html_safe if current_admin.god_mode? %>

You’ll need to tuck it into an if admin_signed_in? block, but it should get a snort of appreciation from the programmer sitting next to you when he sees it. And its fun when normal Admins see it too.

Quicksilver on Snow Leopard

2009-12-30T00:00:00-08:00

Quicksilver on Snow Leopard

published Wednesday, December 30, 2009

I’ve been lost and sad ever since I upgraded to Snow Leopard and couldn’t run Quicksilver, so I spent a little time today poking around and found this post in Quicksilver’s Google Group that talks about how you can get it to work. Looks like all you have to do is run a beta version and the post identifies a particular preference file that you should delete - I had to actually delete the entire Quicksilver folder (~/Library/Application Support/Quicksilver) in order to even get it to open. This was the trick for me. I had installed this version before, but when I fired it up, nothing would happen. I had to actually delete this entire folder before it would do anything.

But now Quicksilver is back and running on my machine and I’m very happy! Quicksilver is such an important part of my UI that I was really annoyed that I couldn’t run it anymore and really disheartened to find out that Blacktree hasn’t addressed this issue. In fact, from what I can tell, they aren’t actively developing Quicksilver anymore and its been taken over by a group of developers that have moved it over to a GitHub repo.

If you’ve never used Quicksilver, I strongly encourage you to check it out - its a really nice application launcher that goes way beyond that one feature to change how you interact with your computer. If you prefer to keep your hands off the mouse and on the keyboard, you’ll love Quicksilver.

Finding the Mouse Position When an Event Fires

2009-12-25T00:00:00-08:00

Finding the Mouse Position When an Event Fires

published Friday, December 25, 2009

We recently had a project where we needed to find out where the mouse was (its coordinates) when an event fired (hover). I wanted to create a little example page that I could play around with to see how this worked.

The markup is really simple and just creates four divs in red - on over their background color is changed to green and then its changed back on out. We’re using jQuery here, so the syntax is based on the hover documentation and the solution as inspired by their Mouse Position tutorial.

The magic is really just the bit where you define the hover functions and then the pageX and pageY attributes of e:

$('div.block').hover(
   function (e) {
      ...
      var msg = 'ON! x=' + e.pageX + ', y=' + e.pageY;
      ...
   },
   function (e) {
      ...
      var msg = 'OFF! x=' + e.pageX + ', y=' + e.pageY;
      ...
   }
);

If you pass the hover functions a variable, it will give you access to the event object through which you can determine the mouse’s position by using its pageX and pageY attributes - slick, huh?

So, I really liked this and wanted to see it in action - I thought logging the info to the FireBug console would be a nice way to see it, but later I realized that I wanted to run this code in other browsers (IE), so I made my own console div and then wrote the coordinates to it.

When I tested this out, however, I didn’t like that I had to keep scrolling the div to the bottom, so I found a nice technique to keep it at the bottom:

function (e) {
   ...
   var consoleDiv = document.getElementById('console');
   consoleDiv.scrollTop = consoleDiv.scrollHeight;
}

The div element’s scrollTop is set to its scrollHeight so that it will remain scrolled to the bottom as its size grows. I had never heard of these attributes, but they are nicely documented in Mozilla’s Developer Center: scrollTop, scrollHeight.