Notes from Andy Peterson

Ew… you got CSS in my Javascript

By on in Development

The other weekend I test drove a little Javascript library to output CSS style rules from within Javascript. I took the most obvious Javascript-literal approach to get the most out of Javascript support in editors. I called it Csster (“sister”), and it looks like:
Csster.style({
h1: { fontSize: 18, color: 'chartreuse' }
});

All it does is insert the rule into the DOM so that H1 elements are, well, chartreuse. There wasn’t initially much code behind this, but I thought it might be useful. It’s pretty much the same as jQuery’s css function, but writes out a rule instead of immediately applying it to all the elements.

I immediately added nesting of rules, similar to how SASS lets you dry-up your stylesheets. Then, with a little help from Alex, I added basic color conversions and functions like “darken” and “saturate”(demo here). I then added support for macros, so you could mix-in behaviors like rounded corners, drop shadows, and of course the ubiquitous (and awkwardly named) “clearfix”. My last pass was to make sure there are reasonable extension points for other developers. Now you can write concise and expressive CSS right along with your Javascript.

Since it’s POJS (Plain Old Javascript), it is a compact language. There’s was no need for me to write math or looping or logic functions, since Javascript’s already got them (unlike SASS). DSLs are the hottest things these days, but even the not-so-forgiving syntax of Javascript works pretty well in this case.

Why would you want to use this? Well, I thought that was the big question, but everyone I show it to has an answer. For me, I am writing pages that generate lots of their HTML markup anyway, so it is awkward to keep a separate CSS file in sync (and drag it down from the server). It works well to write self-contained jQuery plugins, as I sketched out here. I started using on a new initiative (that I can’t share yet) of my latest project, and it made prototyping and initial build-out much faster. It also makes using sprites painless– all our subtitles are in one sprite and I simply add a has: subtitle("Emotion") as one of the attributes and it works. (Previously I’d written some Ruby code to generate a CSS. Ughh.)

Please, give it a spin, and file bugs or send me comments on github.


Javascript Testing Talk in Oakland

By on in Process

Next week at EBig Jonah and I are wrapping up our world tour of talking about Javascript testing. March 17th in Oakland: “Recent evolutions in Javascript testing frameworks now allow creating test suites, test-driving development, and running tests on a continuous integration server. This allows us to support more complex Javascript, have confidence in the implementation, and push more of the logic from the server into the browser, reducing the load on the server.” The focus of the talk is walking through a suite of tests we build for a real-world example.

For those of you who caught it last week at the SDForum, here are the links people requested:

To sign up for next Wednesday, go to the EBig site.


Test-Driven JavaScript with ScrewUnit and BlueRidge

By on in Development, Process

Jonah and I are taking our presentation about Javascript Testing on the road next Tuesday at 6:30 in Palo Alto, at the SDForum

The teaser for it… Recent evolutions in JavaScript testing frameworks now allow creating test suites, test-driving development, and running tests on a continuous integration server. This allows us to support more complex JavaScript, have confidence in the implementation, and push more of the logic from the server into the browser, reducing the load on the server…

Hope to see you there.


Recipe for 5 Whys with an Agile Software Team

By on in Process

5 Whys is a great way to get at the root of quality problems. On my last three projects, when I felt like code quality was dropping, I ran a “5 Whys” session. I have found it adds variety, solves a very specific problem, and plugs right in as an alternative to an agile reflection.

It’s not in every agile software team’s bag of tricks. Asking around our fairy savvy office, I discovered it’s far from universal. In the “State of Agile” report from Version One, which includes survey results from 2500 software developers, it wasn’t mentioned. Since I haven’t seen it show up that much in other agile writings, I thought I’d share my experiences here. Continue reading …


Agile Practices… visualized?

By on in Process

Only pure agile devotees will find it interesting… Revisiting agile methodologies, I wanted to solidify my understanding of the differences between agile, scrum, XP, etc. I went through a mini-research project of reviewing the “canonical” sources of these practices, and then built a quick visualization to clarify my understanding:

http://ndpsoftware.com/agile_methods/agile_methods.html

Hint: Try dragging around the boxes to see how practices are related to each other.

Warning: If it doesn’t draw anything interesting for you, refresh your browser… there’s a large component of “randomness” to the algorithm and it can get stuck easily.

Warning II: Don’t leave it running in your browser, as it’s somewhat sluggish Javascript… this was a demo thrown together in a couple hours.


assert_changes and assert_no_changes in Ruby

By on in Development, Process

Update: This code and documentation is now available on github: http://github.com/ndp/assert_changes/tree/master

The Problem

On our work on gobalto.com, we spend time to have good fixture data for our tests– data that can represent all the important application states that our tests require. As a result, our tests are very dependent on the data. It’s important that someone doesn’t inadvertantly change it in subtle ways. This has led us to write not only asserts at the end of tests, but pre-conditions as well. For example,

    ...
    inotech = companies(:inotech)
    assert inotech.services.public.include?(categories(:a))
    assert inotech.services.public.include?(categories(:b))
    assert inotech.services.public.include?(categories(:c))

    post :edit_services_dialog, :id=>inotech.id,
                                          :service_category_id=>categories(:a).id
    inotech.reload

    assert inotech.services.public.include?(categories(:a))
    assert !inotech.services.public.include?(categories(:b))
    assert !inotech.services.public.include?(categories(:c))

Although the pre-conditions were introduced to guard against accidentally changing fixture data (or just to figure out what’s going on), we don’t necessarily delete them. They provide stronger tests. And in some ways, leaving in pre-conditions make the code more readable by providing documentation of your assumptions to the readers. The code above would be hard to follow without the clarifying pre-conditions. What do we expect to change and what stays the same?

Unfortunately all these asserts make the tests twice as long. And there’s a subtle readability problem: there’s no relationship between the corresponding pre- and post-conditions. In the example above, you have to scan carefully to see that the three assertions are repeated, but negated (b and c only). The reader must mentally put pieces together. And it’s not DRY. Using local variables doesn’t help much.

The Solution

I was inspired by a nice little test helper called assert_difference. It takes a string to evaluate and a block to execute. It’s useful for checking on state changes– especially database changes– during a test:

assert_difference('Company.count', -1) do
    Company.delete_one
end

(Without this method, we rely on a count of all database records, or merely look for specific ones. The former approach leads to brittle tests, and the latter to incomplete assertions.)

A limitation of assert_difference is that it only deals with integers. What if it were generalized? Here goes:

    i = true
    assert_changes 'i' => false do   # read as: i changes to false
      i = false
    end

Continue reading …


Convenient CSS and Javascript in Ruby on Rails

By on in Development

I get tired of hunting through a hierarchy of folders and files, from the views to the public folder, to locate a certain CSS or Javascript file. It’d be convenient to have them right with the markup, but embedding these definitions within your HTML markup is a bad idea for several reasons. For our current project, I proposed we put everything in the view directory so they are easy to find:

app/
  views/
    home/
      index.html.rb
      index.css
      index.js

The convention is clear: to add page-specific CSS code, just create a new file with the same name as the view, in the same folder. Easy to add, edit and remove. The alternative (using the public folder), usually leads to a parallel hierarchy and the inconvenience of that.

I also thought, that this being Rails and all, the files should be included automatically. It turned out to be pretty easy. Continue reading …