audionerd

So, more often than not, you'll catch your state machines attaching behavior directly to your objects. Which sometimes bugs you, because you want your states to be less about "nouns" and more about "verbs".

And eventually you notice that, in most cases, you crave coordination across those "nouns" (e.g.: "a transition in model A provokes a transition in model B"). The real workflow now lies "at the intersection of two models". You start to wish for the equivalent of "process management" in addition to state management.

So this, coupled with general unhappiness for the sort of anti-modular/anti-abstraction problem you see in state machines, might incite you to look at "workflow engines" like Ruote.

http://ruote.rubyforge.org/

TL;DR I am drinking the 'ruote' kool-aid right now. Augment your state machines with a great coordinator in the sky, a few levels higher in the architecture stack.

(BTW: I'm paraphrasing this argument from John Mettraux's "state machine != workflow engine" post, and Kenneth Kalmer's Ruote presentation from this year. Really changed my thoughts on the matter recently.)

If you're hesitant to be an early adopter (AKA "guinea pig") Rails 2.3.x is very stable, and most of the useful plugins in the Rails ecosystem are still maintained for Rails 2.3.x.

Many big names are still on Rails 2.3.x, too. Forgive me if I go astray here, but GitHub and DocumentCloud are two examples that come to mind.

You might want to check out RQL, which builds on JsonPath:

  http://www.sitepen.com/blog/2010/11/02/resource-query-language-a-query-language-for-the-web-nosql/

It would be great to see a standard emerge here. I've watched with interest as JSONPath and JSONQuery proposals have been presented, JS ports of Linq, and this latest proposal: RQL –

http://www.sitepen.com/blog/2010/11/02/resource-query-langua...

There's an Arel-style JS implementation to build RQL strings using chained methods, which makes it quite conducive to composition and makes it feel more like functional programming.

Along those lines are D3's selections:

  http://mbostock.github.com/d3/#selections

... and jLinq

  http://www.hugoware.net/Projects/jLinq

NEAT. Now I want to hook this up to Maildir...

I've been digging into RailsAdmin for a project recently as well, and really liking it so far.

A couple things I'd like to see addressed from the author:

- How is Active Admin's approach different?

- Why would someone choose Active Admin over RailsAdmin?

I wonder why they went with many <div>'s, instead of a single <div> with JS controlling the background-position and clip?

Right, you can't project from Earth and get that kind of broadly visible image. You'd have to setup projection via satellite orbiting the Moon.

I would disagree with the statement "nobody can afford to burn a huge logo onto the Moon". If the only constraint is who can "afford" it, the advertising world has some pretty deep pockets.

Yes, the Moon Treaty was never ratified by the US. I think it's worth noting to show both the historical precedent of respect for the preservation of the Moon's environment, and that such respect is widespread throughout the world.

In 2009, David Kent Jones proposed “shadow shaping” / “shadow farming” technology, in which robots would alter the moon’s surface in such a way that shadows from sunlight on the moon would form company logo’s and advertising messages.

This method, however, was clearly banned by 2005 legislature on “obtrusive space advertising” (see: 49 U.S.C. 70109a) and potentially violates the “Agreement Governing the Activities of States on the Moon and Other Celestial Bodies” (that prohibits “disruption of the existing balance of its environment”).

The Moon Treaty of 1979 specifically bans “altering the environment of celestial bodies”

To advertise on the Moon, its environment would have to remain unharmed.

It's implemented in the Ruby version, and part of the spec:

https://github.com/mustache/spec/blob/master/specs/sections....

https://github.com/mustache/spec/blob/master/specs/interpola...

This is a good point.

Most programmers are familiar with the common notations for nested structures (e.g.: a dot, or a slash). Mustache's solution requires a programmer to explicitly reference the parent context: https://github.com/defunkt/mustache/issues/issue/6#issue/6/c...

https://gist.github.com/3c91441597ac650146b9

Maybe this was to keep Mustache "pure", and avoid introducing a dot- or slash- syntax. "Turtles all the way down"?

I agree the syntax is clunky. But it does have some internal logic.

I'd argue that the bigger problem is: most people don't know the feature exists.

I like the term "Mockup-Driven Development". This is a problem I've been thinking about for quite some time, and I think the author describes it well. There's clearly room for progress in the integration between client-side HTML/CSS designers and server-side programmers.

I've found two things help integration greatly: "Super Templates" and "Logic-less Templates".

Super Templates: e.g.: building a single page template for the entire site

This a technique I learned from Nicole Sullivan's "Object-Oriented CSS" https://github.com/stubbornella/oocss/wiki/FAQ (see the section: "Why have a single template?"). A colleague of mine has nicknamed them "super templates".

Building everything in a single template provides essentially an "integration test" for your HTML components. CSS conflicts are made visually obvious.

Most likely, you would build each HTML component in isolation, and stitch them together into such a "super template" via {{< include}} or similar. To avoid CPU overload, you toggle on/off HTML/CSS as needed for a given test.

Logic-less Templates: e.g.: {{mustache}}

http://mustache.github.com/

Mustache templates are language-agnostic. You only have to build them once, and you can use them everywhere.

Mustache views provides a Mustache template with content. So within one app you might use the same Mustache template server-side (with a Ruby view), and client-side (with a JavaScript view).

Because of this flexibility, the Programmer and Web Designer can use the same mustache templates, using a view appropriate view for their needs (either the real view or a "stub").

The Web Designer would use a "stub" view. It has fake data structures, dummy lorem ipsum. Just enough to build a template.

The methods of this "stub" define an interface which can later be implemented in the real view, at the Programmer's convenience.

This results in the same "Mockup-Driven Workflow" the author describes, with no additional libraries required. The Web Designer works (in the browser) on the templates, using JavaScript view stubs. The Programmer uses the SAME templates, coupled with his server-side views, in the actual application.

I agree with your arguments when the purpose of a mockup (Photoshop or otherwise) is for visual concept / art direction / client presentation.

But when you move past that stage, and begin to integrate HTML/CSS with server code, things get messy real quick, and that's the problem I think this article is proposing to solve.

I think the terminology may be confusing. For example, in the vernacular I'm familiar with, "mockups" are in Photoshop, "templates" are static HTML, and "views" run on the server. And even so, I find these terms are often used interchangeably.

Nanoc has excellent, comprehensive documentation with great typography and style in the layout:

http://nanoc.stoneship.org/docs/

backbone.js docs are concise and easy to follow, also well designed:

http://documentcloud.github.com/backbone/

Why stop at five??

I recently saw a comparative review of budget standing desk options, and I wish I would have bookmarked it. It was from someone who had evaluated a ton of them, put them up as his own personal opinion.

Anyone know what I'm talking about?

Many clever alternate designs (and parodies) have been posted on the ISO150 blog:

  http://blog.iso50.com/2010/10/06/gap-redesign-contest/

If you've never used a "tracker" before, hit the "Disk Options" button, hit "\modules", choose a track, and hit "Playing" to start.

Here's a bit of background:

http://createdigitalmusic.com/2010/09/28/a-powerful-music-tr...

It's frustrating to be told your browser is unsupported, and not be given a list of the browsers that are.

http://spoon.net/UnsupportedBrowser.aspx

  > Do the recent changes mean we can use MacRuby to write iPhone apps?

  Well, iOS is not supported by MacRuby, yet. Be patient, we work on it :)
  Laurent

via: http://lists.macosforge.org/pipermail/macruby-devel/2010-Sep...

“[..] The next afternoon, instead of a new iteration of the calculator, Chris unveiled his new approach, which he called "the Steve Jobs Roll Your Own Calculator Construction Set". Every decision regarding graphical attributes of the calculator were parameterized by pull-down menus. You could select line thicknesses, button sizes, background patterns, etc.

Steve took a look at the new program, and immediately started fiddling with the parameters. After trying out alternatives for ten minutes or so, he settled on something that he liked. When I implemented the calculator UI (Donn Denman did the math semantics) for real a few months later, I used Steve's design, and it remained the standard calculator on the Macintosh for many years, all the way up through OS 9.”

via: http://folklore.org/StoryView.py?project=Macintosh&story...

I've been meaning to read more of Alan Kay's work. This makes it easy.

  http://academic.research.microsoft.com/Detail.aspx?entitytype=2&searchtype=2&id=2276768

The text-shadow hack stopped working when Snow Leopard was released.

-webkit-font-smoothing seems to be a specific solution to the same problem.

via: http://orderedlist.com/our-writing/resources/html-css/thinni...

The recommendations from html5boilerplate.com actually include this:

  html { -webkit-font-smoothing: antialiased; }

My point being: be sure to read and understand resets/boilerplates before including them in your own code.

I'll forever have the phrase "sometimes behaves so strangely" stuck in my head --

Radiolab interviewed Diana Deutsch on her research a few years back, and it's one of my favorite episodes.

http://www.wnyc.org/shows/radiolab/episodes/2006/04/21/segme...

I know non-coders might downvote me for this, but github's recently open-sourced Gollum engine might be a good basis.

  http://github.com/github/gollum

Contributors could write their articles independently, send a pull request, and have their writing merged into the central wiki.

There's also a (minimal) web UI for easy edits, or for users who aren't comfortable with git.

Tried to find it, but unfortunately the video link is dead:

  http://www.creativityworldforum.be/view/nl/6432289-Sessions.html#session1

There is a PDF though with a bit more background:

  http://www.flandersdc.be/static/content/CWF08-day1-John_Cleese.pdf