I’ve been interested in REST as a principle for Web service design for a while now. Rather than reimplement pre-WWW methodologies for network communication over the web, REST offers a way to use the power and resilience of the web itself to guide the way we develop applications. Ever since Ruby on Rails 1.2 brought “RESTful” into the vernacular of web developers, it’s seemed as though the triumph of REST was imminent. It’s seemed that way for a long time now, however, and I’m beginning to wonder whether we developers will ever find ourselves working with robust hypermedia formats, controls, and affordances as frequently as we work with JSON representations of CRUD operations. Has REST peaked in its degree of implementation and influence on developers? Is hypermedia too complicated or unnecessarily sophisticated for the future of applications that communicate over the internet? Are there market forces that discourage RESTful API design? Or is there still a RESTful future for applications that communicate over the Internet?
As someone who makes a living writing software, I experience the nature of my work and the opinions of the communities of programmers I encounter as generally consistent: programming is hard; tools help a bit; but there are no silver bullets, only lead ones. But there are remarkable discontinuities in this experience. From time to time, I meet or hear about someone doing something with software, using tools or techniques I’ve never heard of, that makes it all seem simple. I don’t know whether this appearance of simplicity (and mastery) is deceiving or genuine, but it plays a big part in my imagination of how programming could be, and I expect I’m not alone. I’m becoming convinced that there are people whose intellects, or even genius, are honed or engaged or unlocked by a technology that they completely get. It is perhaps not the tool but its joining with the hand that wields it that blesses the wielder with extraordinary abilities. This person programs in another world, one I may only glimpse. I don’t know whether to be encouraged or depressed about it.
What follows here is my encounter with the rumor of one of these programmers from another world.
I think I finally understand the atomicity of time in Clojure’s modeling of state. Function application constructs time in Clojure: there is the value of an identity before a function’s application, and there is the value of the identity after the application. The timeline of a program, as far as state is concerned, is not measured in nanoseconds or any other periodic unit, but in the applications of functions that divide time into before and after. The higher-order functions that compose updates to Clojure’s mutable state references actually mark the ticking of coordinated time.
I love Twitter. At first I thought it was a fad. Fluff. Then I realized it puts you in a virtual room with a lot of people you respect and lets you follow their thought processes in real time. And as you try hard to tweet something worthwhile, every now and then you might actually interest, or inform, or entertain, someone else out there. You meet people, have conversations, learn things before anyone else does. It’s addictive. Really, dude, I need this.
That’s why it’s such a major bummer that for the last 48 hours, this has been Twitter’s status update form, for me at least:
I’m not the first person to complain about not being able to use Twitter. However, I’m not angry so much as scared. Jittery. Shaking a bit, man. I need my Twitter. So I’m willing to propose a drastic solution.
I keep a text file open as I work, and when I learn something, or fix a bug, I make a note of that in the text file. I call it my journal. It’s pretty low-tech, but text search turns out to be a sufficient way to look up past experiences when I find myself thinking “this problem seems so familiar”. There’s another benefit too: I find keeping simple notes about what I’m doing—what problems I’m solving, what approaches I’m using, what’s working and what could work better—keeps me focused on my goals. It turns out learning a programming language or a web framework is not as hard as training your mind to solve programming challenges efficiently.
Here are some things from my journal: I’m working on a Rails 3 app right now, something I plan to flog and promote mercilessly in upcoming posts. I’ve encountered some mysteries for which there was no simple HOWTO information easily available via web search. I thought I’d share the answers I cobbled together:
- How to get RSpec and RSpec-Rails for Rails 3;
- How to make devise routing work with related nested routes;
- How to spec controllers that use devise to restrict access to logged-in users;
- How to get
verify :methodto work in Rails 3.
I need to clarify my interests. I keep getting calls from recruiters who want to hire me to do Perl or database management. So, I am trying out an experiment in self-analysis by describing my enthusiasms as they relate to specific programming languages. I am currently interested in the web software applications of Ruby, JavaScript, and Clojure.
It isn’t all about programming languages. There are topics and concerns that span software development and computer science. But PLs are one great way to summarize one’s experience and efforts. And I’m a language nerd, so I like PLs as ends in themselves. So, here is my little essay on the 3 languages I like most right now, and, more importantly perhaps, what I want to do with them in the coming months. This is my summer of hustle, and this post is part prelude, and part wishful thinking, about all the things I’d like to tackle.
I sure am glad I went to the Bmore on Rails hack night yesterday. I got some invaluable help from Paul Barry hacking together a working template handler for mustache in Rails 3.
At RailsConf, Jeremy McAnally noted that no one had built a new-style Rails generator for the mustache template system. So I’m giving it a try. You can see my progress so far on github. I’ve forked the rails3-generator project started by José Valim and carried on by several contributors, and I’ve added just a little bit of support for mustache file creation in controller and scaffold generators. I was greatly helped by Paul Barry’s post on adding a Haml generator to the same project.
The next steps are to flesh out the generator templates and try to get a working mustache template engine. Mustache and Rails don’t officially work together yet. That’s a goal for mustache 1.0. I’m excited, however, about Martin Gamsjaeger’s promising implementation.
I’d like to see a gem that gives you complete Rails support for mustache: the template engine, generators, helpers, and documentation. I’d also like to see the gem work with Tilt, which claims to provide a generic interface to mustache already.
If you’re interested in helping, well… fork me!
Giles is right. As usual. In my recent post, I included a passage from Giles’ blog that I disagreed with. Except… Giles didn’t author that passage, Seth Godin did. Giles was just quoting it.
I’m sorry, Giles. I’m correcting my post now.
Nothing stings quite like announcing your own brilliant close reading and then discovering you weren’t reading closely at all. Actually, being accused of going to Harvard might sting more.
I read an interesting article by Dave Fayram (kirindave) contrasting monkeypatching in Ruby with protocol extension in Clojure. The article compares two of my favorite languages, but I think it was unfortunate to present monkeypatching as the main way to “associate behavior and data in a flexible way.” In fact, Ruby has a number of safer ways to extend types and single objects. (And in Ruby even monkeypatching doesn’t have to be dangerous.)