Sunday, February 25, 2007

Perl 6: Junctions?

The Perl people are either onto something really fascinating, or have just plain gone nuts.

My latest discovery in the alleged Perl 6 project -- alleged because there's only so long you can go without producing results -- is junctions, which are a datatype which can have any of several specified values.

No, really.

Update -- it turns out that the primary use case for this new language feature is something you already get for free in Ruby.

Do It Now

http://showusthecode.com/

It's Official

"IDE vs. text editor" is the new "Mac vs. PC."

Friday, February 23, 2007

Sun Serious About Ruby On Rails

From: Charles Oliver Nutter (charles...@sun.com)
Reply-To: ruby-talk@ruby-lang.org
To: ruby-talk@ruby-lang.org, ruby.mn@ruby.mn,
dev@jruby.codehaus.org, user@jruby.codehaus.org
Date: Feb 23, 2007 5:05 AM
Subject: [JOBS] Ruby on Rails resources wanted; senior level, aware of other languages and stuff

Hello friends! I'm cross-posting this because it sounds like a pretty cool opportunity. Sun is looking for senior-level Ruby on Rails resources. Yes, you read that right.

This is not just a simple RoR developer job. We're looking for folks that know RoR at a SENIOR level, as well as having experience building larger-scale back-end systems with multiple languages. Experience with other Sun technologies is probably a plus. Yes, this is/are a real position(s).

If I know you, and you don't suck, I'm certainly willing to put in a few good words. If I don't know you, well, help me know you. I'm not the hiring person for this job, so I'm not going to have any final say. But I'd like to know folks that are interested in this sort of opportunity either way, and who knows, maybe I can help make it happen.

As I understand it, the job would be in the San Francisco bay area, probably with a requirement to be very near the Sun offices in Santa Clara or Menlo Park.

I have some actual job reqs I can provide to folks that are interested, and I won't blast them out to these mailing lists. Contact me directly if you want to know more.

- Charlie

Haskell A Superset Of OOP?

If this is accurate, it's pretty remarkable. It comes from a blog post detailing an implementation of Lisp written in Haskell:

Traditional object oriented languages let us abstract ourselves from writing [if-then-else] switches and take the task upon themselves freeing us up to do more important work. Haskell does the same thing, however, it doesn't limit the abstraction to types - we can get the compiler to write such switches based on any component we're interested in abstracting! We can, for example, get the compiler to write code for us that will cause the runtime to only execute a particular function if the first argument is equal to five, or if the second element in a list is equal to three. We could do that in traditional languages with if statements and switches but Haskell does this for us in a much more elegant and expressive way. After all, why are we only allowed to create virtual functions based on the type of the object they belong to? Why can't we define "virtuality" based on the type (or value) of the function's third argument, for example? Interestingly, this is one of the reasons why Haskell isn't object oriented - it's functions don't need to belong to objects because the compiler and the runtime system allow us to abstract over any argument's type and structure (contrast that to being able to abstract only over an implicit this)!

The implication is that from a Haskell perspective, an object-oriented language is one which comes with one (and only one) simple mechanism for abstraction that consists entirely of an embedded this flag variable which every piece of data is guaranteed to have by default. If I understand correctly, Haskell's abstraction mechanism operates as a superset of this paradigm, because it can abstract over other things as well as the implicit flag variable.

Pretty interesting. If I've understood, then I totally understand the appeal of Haskell as well, because that's pretty powerful. The only thing I don't get is why Haskell would be preferred over Scheme or Common Lisp; surely, if Language A wins because Language A's functionality is a superset of Language B's, then absurdly powerful languages are the best. I'm assuming there's something which Haskell is best for, which Lisp cannot do, or can't do as eloquently, and that this is why Haskell exists in the first place. But I'm not sure.

This Is EXACTLY How It Should Be

With all the obsession over REST driving the Rails core team to seriously and sincerely advocate repetitious code like url_for(@person, :person => person), sometimes on the same blogs where they used to dis Java for looking like that, it's nice to see them back on track, doing things exactly right.

Haskell Makes Lisp Look Sane

Actual quote:

What would a programming language look like if Bayes’ rule were as simple as an if statement?

Thursday, February 22, 2007

Form Helpers

Jamis Buck's said that you should never use a plugin you couldn't write. For pretty much the same reasons, form helpers makes me nervous. Nine out of ten times, your life is easier if you just write the HTML. It's not as if writing form tags is such a hard task to begin with. In the trivial cases, you kind of have to wonder what the point of automating it even was.

Perl 6 Roles ~= Squeak Traits?

Perl isn't very popular any more, but if Perl 6 ever actually happens, there could be some pleasant surprises involved. Perl is going to adopt elements of the Traits idea from Squeak Smalltalk. This is actually a pretty idiosyncratic decision -- to quote Larry Wall:

We buy the argument of the Traits paper that classes should not be used both to manage objects and to manage code reuse. It needs to be possible to separate those concerns. Since a lot of the code that people want to reuse is that which manages non-isa object relationships, that's what we should abstract out from classes.

That abstraction we are calling a role. Roles can encompass both interface and implementation of object relationships. A role without implementation degenerates to an interface. A role without interface degenerates to privately instantiated generics. But the typical role will provide both interface and at least a default implementation.

Unlike the Traits paper, we will allow state as part of our implementation.

The class approach to object-orientation is so widespread that many people don't even realize it's an approach to object-orientation. To most of the world, the idea of classes is what object-orientation means. I haven't played with Traits in Squeak yet, but as I understand it Squeak adds traits to the existing class system. Perl 6 is apparently planning to replace classes with traits, or rather, with something similar to traits, called roles. This could make the Perl 6 object system as weird, interesting, and nifty as the Common Lisp Object System (which is very, very odd).

I've grown very skeptical of Perl 6, any time a project takes forever and is supposed to be the best thing in the universe I figure it's never actually going to happen at all, but if the Perl 6 implementers prove me wrong, I think it'll be worth it to brush up on my Perl again. That would be cool.

Wednesday, February 21, 2007

Bitscribe Props

The company I work for invented a term: atomic coding. (James Lindenbaum invented it to describe something Adam Wiggins does.) Quoting Adam:

Last year the term "atomic coding" produced next to nothing on Google, but today it produces over 1200 hits.

Here's a post on atomic coding from out in the big wide world, and here's the original Bitscribe screencast.

Tuesday, February 20, 2007

Programmer Productivity "Doubling Every 6 Years"

This is really interesting and contains a logical fallacy.

The interesting part is that Fred Brooks' "No Silver Bullet" may have in fact been wrong. The silver bullet turns out to be language design. A 2007 programmer can code something in a few minutes that would have taken a 1972 team a few weeks, and the reason is that languages have evolved considerably since then.

The logical fallacy is that the productivity gains are averaged over the intervening years, despite the fact that the language used to demonstrate this has itself been around since 1995.

You can say we've got an 11x increase in productivity since 1972 due to language design. You definitely can say that, although don't blame me if you do say that and the Lisp people immediately descend upon you and eat your head. But you can't say that productivity doubles every six years because you don't have any data on the trend that indicates the continuance you're implying or the consistency you're implying.

Very interesting, but logically unsound.

William Gibson Predicted This

In Virtual Light.

Monday, February 19, 2007

I Found A Bug In Rails!

For some reason this fills me with excitement.

I don't know exactly what's going wrong, so I'm not looking forward to building a test case for it at all, but here's the change I had to make.

I actually suspect the bug in Rails is only visible to me at all because of more serious bugs in my app, but hey, what can you do. Also -- and this is probably a related issue -- the bug seems very difficult to reproduce. (I've reproduced it, but not predictably.)

Jay Fields Article on InfoQ

This article on different ways to use eval in Ruby is probably the best explanation I've read since the chapter at the back of David Black's Ruby for Rails.

Sapir-Worf In Action

One idiosyncrasy I've noticed I have as a coder is referring to various processes halting or failing as being "killed." I've been saying it for years, I noticed about a year ago that I was really the only person I knew doing it, and I just figured out, finally, where it comes from.

In Perl it's very common to use die("some message") as a de facto breakpointer. You think, well, these method names, they're just metaphor -- but somewhere in my brain the metaphor took hold. Fast forward a few years and every bug gets the violent descriptors "this is killed here" and "that is killing it." After a while the habit started weirding me out, so I've basically stopped, but I still do it from time to time when I'm thinking about something else.

It's totally idiosyncratic and anecdotal, but it makes the Sapir-Worf Hypothesis a lot more credible to me.

Calls to mind something Gerald Sussman said:

It is not exaggeration to regard this as the most fundamental idea in programming:

The evaluator, which determines the meaning of expressions in a programming language, is just another program.

To appreciate this point is to change our images of ourselves as programmers. We come to see ourselves as designers of languages, rather than only users of languages designed by others.

In fact, we can regard almost any program as the evaluator for some language...Seen from this perspective, the technology for coping with large-scale computer systems merges with the technology for building new computer languages, and computer science itself becomes no more (and no less) than the discipline of constructing appropriate descriptive languages.

I think this goes a long way towards understanding why people feel studying language design makes you a better programmer. It certainly makes me a lot more interested in RSpec than I've been in the past. I saw Dave Astels speak about this at Canada on Rails, and I was extremely skeptical. I think at this point that I just failed to see the point, but it's a valid point all the same.

Simple But Powerful Ruby Memoization

The simple technique: using a Hash with a default block.

The improvement: constraining the size of the cache.

Sunday, February 18, 2007

Open And Closed Systems

In Martin Fowler's keynote at RailsConf, he talked about "post-modern languages," which is to say, essentially, languages that are designed with the expectation that other languages will also exist. The idea originally comes from Larry Wall, the creator of Perl. You can generalize the idea out to the Unix ecosystem and contrast the Unix design philosophy -- lots of little programs, each of which does one thing well, and numerous glue languages -- with the Smalltalk philosophy of "everything in the box from the hardware on up conforms to one idea." (Or, as it's been well-termed elsewhere, the idea of "Turtles all the way down.")

I've been thinking about this a lot, because it's an interesting question. Unix is obviously more successful than Smalltalk. On the other hand, look at Apple computers, how much better they are than Windows boxes, how much simpler to use than Linux boxes. Whether Apple is more successful than Microsoft or less so depends on what you think Apple's goal is. I think Apple's a lot more successful than Microsoft. Real artists ship.

But go beyond that -- the iPod / iTunes / iTunes Store triad is as much an example of a very successful closed system as any Mac, maybe more so. I got this idea from Steve Levy in a Boing Boing Get Illuminated! podcast, and it's a damn good idea. Most competitors to the Apple music triad have tackled only one of its three components, and Apple pwned them all. None of them had the elegance, the ease of use, or the tremendous downloads catalog. By packaging everything within one excellent closed system, Apple came into a settled market, turned it upside down, shook it really hard, and picked up all the money that fell out.

And the funny thing is, it's no secret that Steve Jobs is a fan of Smalltalk. Even today, the language used in the development of Mac apps, Objective-C, is this weird hybrid of C and Smalltalk. To some extent the same Smalltalk-esque closed-system philosophy that makes Macs such a pleasure to use is also responsible for the colossal success of the iPod. Like so much with Apple, it ultimately all traces back to Smalltalk. Even Jobs' business models are based on Smalltalk.

So this is a powerful argument in favor of closed systems. On the other hand, the Mac was a lot less useful when it didn't run Unix. That's an argument in favor of post-modern ecologies. I don't know.

Personally, for me, the jury's still out on this one.

Bridge Metaphors

Glenn Vanderburg
Coderific

Saturday, February 17, 2007

Why Software Developers Love Legos

Or at least, why this software developer loves Legos:

I have occasional starving artist phases, where I live in the woods studying art, or go back to school for motion graphics, or live in a ghetto writing screenplays. When I want to get back into writing code, I have a trick I use: I buy lots of Legos, and I put them together. (Technic and Mindstorms kits are the best, of course.) I use this trick to re-train my mind in the basic skills of software development, if it's gone all soft and arty at the edges. The trick works marvelously well.

It works because software development is a lot like building Legos. For example, a lot of the time, when you're creating software, you run into some problem. If you're new to development, you blame some component you're working with; if you're experienced, you know it's something you did. Likewise, with Legos, if you're trying to follow the instructions and you can't find a particular piece, it's very tempting to think that they somehow failed to include that piece in the kit, but if you've built a lot of Lego kits -- or you have have good common sense -- you know for a fact that it always turns out that they didn't forget to include a piece, you just failed to see that piece.

What you do in a situation like that is you pick into the pile of Legos, and you start grouping together pieces which are similar to your "missing" piece. There are two reasons to do this: first, if you methodically grab every piece which could be your piece, you're more likely to grab the piece which is your piece. The second reason is that if all the pieces like your piece are in one place, except for the piece itself, that remaining missing piece is more likely to pop out at you visually when you look at the big pile of Legos.

This is a lot like the way that refactoring can expose bugs, design flaws, and similar weirdness. You group similar things together, and this makes the exceptions and the edge cases more obvious and easier to spot.

Another similarity is that there are a few Lego pieces which are almost exactly similar, but not quite, and if you're not paying attention when you put the kit together, putting the wrong piece in place is pretty easy to do. Taking the kit apart to swap out the wrong piece with the right piece is pretty similar to run-of-the-mill debugging, especially when you're dealing with a complicated kit. You take the gears off and put them here; you take the axles out and lay them there. You need them all structured and easy to find, because except for the piece swap, you're keeping everything else as it was. Very similar to fixing a problem in one tiny piece of code smack dab in the middle of an otherwise perfectly good application.

One final similarity, of course, is that putting entirely new designs together is more fun than using instructions, and also harder to do, in the same way that building your own framework is more fun than using somebody else's, and also more work.

Every Coffee Freak's Dirty Secret

McDonald's coffee beats Starbucks in taste tests.

Friday, February 16, 2007

Rails / Google Maps Book (Apress)



Recently Ruby books have gotten much more numerous and yet much less interesting on average. This looks like a very appealling exception. Riding Rails says it'll be released Feb. 26th.

Possible Big Deal: Cellphone Cash

Mobile Paypal

Thursday, February 15, 2007

Latent Semantic Linking

Latent semantic indexing is a very nifty technology with obvious usefulness for search engines. But what would be really cool is latent semantic linking -- where the latent semantics in the content were less analyzed than the latent semantics in the links. Here's why: if you google "Rails 1.1.6 1.2.2", you get pages referencing train rails of 1.2.2 gauge thickness (or something).

Latent semantic link analysis would basically apply AI math to PageRank. Instead of just saying, this page is a popular page containing these terms, LSL would say, this page is a popular page containing these terms, and which is also linked to by pages which are also known to be relevant.

You wouldn't need it every single time, but it'd make a great filter on existing searches. A little link in the search result: "results relevant to this one."

If sites were mapped in subsets this way, it'd be easy to "search all Rails blogs" or whatever.

Should Developers Provide Their Own Tools?

I absolutely agree with this. Do you?

Kathy Sierra Rules

This blog post is so awesome I almost suspect it of somehow violating the laws of physics.

Making Rails A Post-Modern Seaside

OK, this hinges around the idea of post-modern languages, an idea from Martin Fowler. Basically a language like Smalltalk tries to control everything, whereas a post-modern language operates with the assumption that other languages will also exist. Watch Fowler's RailsConf keynote to really understand.

Anyway, I was reading the new TextMate book while stuck in an airport, and it turns out that TextMate has a footnotes plugin (by the extremely smart Canada Duane) which gives you functionality very similar to the functionality which renders a Web app written in Seaside into an IDE for itself. You get links in your Web app which you can click to automagically open the relevant code in TextMate.

What Seaside has is definitely more sophisticated than opening a file in a text editor, but TextMate is an absolutely beautiful text editor, extraordinarily powerful, redefining the category, and footnotes is certainly an excellent plugin. In fact, it's damn near the coolest thing ever. Smalltalk's self-contained nature is usually seen as a plus, but the diverse Unix environment makes similar features possible in a very different way.

Update: another tool for setting up a seamless Rails/TextMate "IDE".

Wednesday, February 14, 2007

Barack Obama Web Team Responds To E-mail

I got sent to a web page for a Barack Obama rally. The page misspelled "Angelenos" (with an i) so I e-mailed the contact address. They responded within about twenty minutes, and this is before 9am. One thing most politicians get wrong is the Web; even the ones who add it to their rhetoric don't seem to understand it's about responsiveness more than anything else. I'm not jumping on the bandwagon, but I have to give him credit for at least getting clueful people on his team.

Tuesday, February 13, 2007

Componentized Elements in Web Apps

OK. Say you've got a complex web app with lots of bits and pieces. Say it's for a company which has clients. Say further you want to create a client login which is a different view on the same data -- one where the client only sees their own data, and none of the company's internal data or of the data which belongs to other clients. So you round up a few bits and pieces, have them filter their output appropriately, and there you go.

If you're working in Rails, you put the same partials on a different page, and alter the find() calls to use with_scope. Worst case scenario, you might have to do a little refactoring. I had to do that today -- and in fact, I've got more refactoring to do. One of the pieces of code used a regular Rails template instead of a partial -- so I had to copy and paste. Another piece used a partial, but built the find into a class method on the model. So I had to write a new find from scratch. It wasn't hard, but it was kind of annoying. It could have been more elegant.

On the class method thing, you could probably call that a design flaw -- and a certain amount of this is just normal work. You can't automate everything; programming languages don't obviate the need for programmers. Nor can they make design errors impossible, and the more I learn about languages, the more it looks as if the worst languages all result from efforts to accomodate bad programmers instead of letting them sink or swim. So a certain amount of this, you just have to deal with it.

But the rest of it? Having to copy existing code because it's in a template, not in a partial? Not exactly DRY, is it? And ask yourself how you'd get around it, in Rails. The best you could do is move the code to a partial and then, in the situation where it's called as a regular template, write a wrapper template around it just so you can make it a partial in the first place. In other words, your options are redundant render() calls -- in the controller and the wrapper template -- or redundant template code.

It's funny, because I hate advocacy, and my Smalltalk-fu is appallingly weak, but this is the first time where I was doing something in Rails, I felt actively constrained by the framework, and I knew for a fact it was easier to do it right in Seaside. In Seaside all you do is write an object which generates the output. There is no difference between a partial and a complete page in Seaside. It doesn't matter. And this makes delivering the same output in a different context much easier. Seaside apps are componentized from the word go, so rearranging the components is easy.

It's funny also because most of the buzz about Seaside centers on its continuations, but the componentized paradigm might actually be a much bigger idea. There might actually be a way to reorient Rails to accomodate this paradigm. All you really need to do is extend render(). Move the partials out of the filesystem and into Ruby objects. The Rails model, where templates live on a disk, puts limits on the componentization your app can have, but if you keep the template system, but move the actual templates out of the filesystem and into the code, so that you can nest them arbitrarily without manually nesting render() calls, then you've got a big big part of what makes Seaside great.

Then again, you could just buck the trend and use Seaside.

Anyway, every time I post something like this somebody calls me a Seaside advocate, so I just want to reiterate, I write Rails for a living, I can barely do "Hello World" in Seaside. Language wars are a waste of time. It's the ideas in the languages that matter, not the languages themselves. (And the same is even truer for frameworks.)

Squeak Tidbits

What with relocating to LA, I've been lagging on blog posts recently. I discovered a couple things that I haven't yet had time to fully investigate, but they're both interesting.

The first is Magma, an open-source object-oriented database. I got a great e-mail about object-oriented DBs from Thierry Thelliez which I'm hoping to post/summarize here; although you don't hear about people using them much in "real life" they do in fact appear to have pretty significant advantages. Chris Muller, Magma's creator, did a podcast interview on OODBs in general and Magma in particular, and apparently Magma is very "ready for prime time."

The second recent discovery is Traits, a new feature in Squeak 3.9 which is kind of like Ruby mixins, but with a cleaner inheritance mechanism (if I understand correctly). I haven't been able to play with these yet, but if you google "Squeak Traits" you'll find all kinds of interesting stuff, including something in the AspectJ community. Apparently the idea's proven very popular.

Missing Gif On Rails Deprecation Page

Intentional ironic comment on the importance of maintaining deprecation? Maybe!

Monday, February 12, 2007

Like Google Summer Of Code, But More Obscure

The OCaml Summer Project

acts_as_polymorphs

DHH's acts_as_taggable plugin is basically deprecated -- in fact it was largely cooked up as a demo:

The plugin was intended as a demonstration of has_many :through, I'm not sure that adding more features gets us any closer to that goal. As with other domain-intermingling plugins, it's unlikely to be able to solve most people's problems without serious hackery. Perhaps it's best left as is, but with the documentation updated to make it clear what the intention was.

(Koz from Rails Core)

Despite that fact tons of people are using it in production.

Evan Weaver has cooked up a nice alternative, and an article describing how to use it.

Saturday, February 10, 2007

Saturday Night Nerdout

It's 8 pm, Saturday night. I just did some consulting on Bayes nets and machine learning while building a Lego Technic kit.

I am a wild and crazy guy.

Friday, February 9, 2007

The Immediate Future of Robotics Is Sessile

In the same way that sessile (non-mobile) lifeforms proliferate all over the globe, and in many cases probably predate the complexity of animal life, I actually think sessile (non-mobile) robots will be more prevalent and more useful, and arrive much sooner, than what people traditionally think of when they think "robots."

The robots used in assembly lines to build cars are sessile. Traffic lights are currently merely automatons, but could very easily become robots -- in fact a network of traffic lights operating in a pseudo-economy, in concert with traffic sensors, would probably be remarkably much more efficient than current centralized and scheduled systems. Gas stations are trending towards becoming sessile robots, and in fact, at night, when nobody's working there, a gas station equipped with cardreaders and automatic pumps is a sessile robot.

One reason I think sessile robots will be more useful than mobile robots -- and one reason why I think they already essentially exist, and are already essentially part of our society -- is because their cost of integration with existing social systems is pretty near zero. Installing cardreaders, switches, and extremely simple brains on existing gas stations is much simpler than building brand new Refuellotrons or whatever. Same with converting an existing traffic light system to harness autonomous agents for greater efficiency, or setting up a car-building robot in an existing factory.

Here's another example:

On-road warning signs

Could real-time traffic information be projected directly onto the road ahead?

Philips thinks so and proposes attaching laser projectors, each with a rapidly-moving mirror that deflects its beam, to ordinary lampposts. These would be used to project images and words onto the road just ahead of approaching cars.

The solution would be cheaper than installing a large video display and safer too, since drivers would not need to take their eyes off the road. Also, a warning about ice or danger on the road ahead would not need a full colour screen, so the projector could use just a single-colour laser.

Each lamppost would have its own IP address and would connect wirelessly, or via a cable, to a central traffic control centre. The projectors could also tap into the power already used to illuminate streetlamps.

As well as providing warning signs, the laser projectors could paint temporary lanes onto the road, steering traffic round an obstruction, or away from the main highway and onto a side road. It's a neat idea, but how well would it work in busy traffic?

(From the New Scientist's roundup of recent patent applications)

Of course the projects to build a self-driving vehicle are much more glamorous -- but if you think about how AI came to be regarded as the huge disappointment of computer science in the 80s by making overly ambitious claims, a simple robot performing a simple task that makes a minor but very useful improvement for tons of people in traffic every day, that's a much more practical thing to do than a robot car -- simpler, much easier to achieve, and useful for everybody, rather than an arbitrary fortunate group.

In a way it's kind of like the difference between agile development and waterfall dev; instead of trying to build an entirely new world, the real successes in robotics will probably come from people who devise simple improvements to existing systems.

Consider how difficult it would be to sell people on transforming the entire international network of roadway and traffic systems to equip those roads with dynamically reconfigurable lanes; that sounds expensive, complicated, and a nightmare of bearaucratic complexity. Then imagine how easy it would be to sell occasional dynamic lane-drawing in emergency situations to drivers who were already used to these laser road-writers. And then how easy it would be to move from occasional dynamic lane-drawing to frequent dynamic lane-drawing in high-traffic areas; and then imagine telling a city council it's cheaper to make lane-drawing even more frequent than it is to pay for new paint on the highway.

One thing software development is really, really good for is it teaches you how to recognize the kind of science fiction that can actually happen.

Thursday, February 8, 2007

Best Screencast Ever

Web 2.0: The Machine is Us/ing Us

Glenn Vanderburg on Ajax Podcast

A very smart guy whose commentary is sometimes hard to find but usually worth the effort. The podcast is about Project Tamarin, a fast JavaScript VM which Adobe is donating to the Mozilla project. Glenn's role seems somewhat tangential, but I'm downloading it anyway.

I Must Obtain This Shoe



I warn you all now, if you stand between me and obtaining this shoe, it could cost you your life.

Ruby != Lisp

Blog superstar Raganwald takes a break from his busy blogging schedule to write some code and discovers (gasp!) Ruby, beauty though it is, still ain't Lisp.

TextMate Book r0x0rz

James Edward Gray's series on higher-order Ruby -- based on the fantastic Mark-Jason Dominus book Higher-Order Perl -- was one of the most useful and interesting resources on the Web for me when I was learning Ruby. He wrote the Ruby Quiz anthology for the Pragmatic Programmers, and his book on TextMate's going to be released next week.

I highly recommend it. Although I've used TextMate before, I've never bothered to really learn it -- it was too easy to depend on my vi skills. As amazed as I am to say this, after going through this book to grep out the essentials, I could actually see myself abandoning vi forever. Don't quote me on that -- old habits die hard. But I could see it. The software's utterly kick ass, and I have to give this book a lot of credit for making it really easy to get to the juicy stuff very quickly.

Wednesday, February 7, 2007

Direct SQL Access from within Rails

Rails is awesome, but as much as it hides the database, there are applications and situations you run into every so often where you really do need direct access to SQL. What do you do?

It turns out the answer is simple. First, any ActiveRecord object will have a connection you can access, and every connection will have an execute method you can use to execute any arbitrary SQL.

It's as easy as ArbitraryModel.connection.execute("some sql where * etc;").

Found this out from (of course) Mr. Jamis Buck, and verified it with a peek at the API docs.

Ah Gots Me A Noo PDF Ta Raid



w00t

Rails Law of Demeter Solutions

This is why Jay Fields is becoming one of my favorite bloggers:

Fix Law of Demeter violations in Rails apps with Forwardable.

It's clean, it's simple, it's easy, and he doesn't explain why it's needed, but he does it make it easy to find out more.

Tuesday, February 6, 2007

Something Expression With Himself

A Y combinator in JavaScript; found in a comment on Raganwald's blog, which also features an alternate implementation in Ruby (which looks a lot cleaner than the Jim Weirich implementation I posted the other day).

Jim Weirich @ OSCON 2006: Google Video

Aqui.

The topic is "TDD meets Design by Contract." It's an introduction to RSpec. There's another good introduction to RSpec on Tim Lucas' blog.

Faux Accessors

Handy Rails technique from Josh Susser.

Basically, it gets around the fact that you can't override #initialize in an ActiveRecord model. The example he gives is actually better design than overriding #initialize anyway, but there's a potential for misuse there as well. The basic idea is, you can't override #initialize, but if you assign any given attribute on creation, you can override that attribute's #attribute= method, so you put your extra logic there.

The risk, of course, is that in some cases, you're doing something smart -- like if you have a #fullname= method assign first_name and last_name attributes based on splitting the fake "fullname" attribute -- but in other cases, in the case of misuse, you could wind up with code where all kinds of initialization stuff is done by depending on side effects. So, definitely a handy technique, but one with an air of living dangerously.

Stuff I Never Built, Part 235

There's a Make blog tip advocating yet another tricky way of outsmarting blog spammers.

The technique is very crafty, very smart, but the idea, I think, is totally misguided. We don't need another cat-and-mouse game. With the advent of Bayesian spam filters, there are a lot of people (myself included) who really just don't even see spam any more.

Obviously, the blog world needs a Bayesian spam filter. I want to build one in Ruby. It might happen -- but I'm posting it here just in case somebody with more time than I have, or quicker Ruby-fu, wants to beat me to the punch. It would be a really good thing -- you'd be doing a favor for all humanity.

Just to underline this a bit, the captcha techniques are defeatable. Open source hackers have done it; academic researchers have done it. Everybody who's done it is currently tight-lipped about how, but it's only a matter of time until the genie escapes the bottle. I actually heard rumors about a company buying captcha-defeat software on some black market here in the US for only a thousand dollars. Spammers bypassing captchas is only a matter of time.

By contrast, Bayesian filters are a much more sound technique, much harder to bypass, and deliberate efforts to bypass them actually make them stronger.

It really is a very good idea.

Monday, February 5, 2007

Oldie But Goodie

Ryan Tomayko: Motherhood and Apple Pie

Mostly commentary on Sir Tim Berners-Lee's original.

Gerald Sussman: Teach Kids Programming

Ramon Leon told me how he went to OOPSLA in 2005 and heard Gerald Sussman (of Structure and Interpretation of Computer Programs) speak. The subject was how schools should teach kids programming, because you really know how to do something when you can program a computer to do it.

I wasn't able to find any audio or video of this talk, but here's the synopsis and here's somebody who figured out pretty much the same idea.

On the other hand, there are some compelling arguments that teaching programming may be essentially impossible.

Astronaut Also Psycho Hose Beast

I always thought that what with all the pressures of life in space, I'd never be able to do it -- that they'd have intense psychological filter exams to keep all but the most normal out of the job. In other words, I always thought I was basically too crazy to be an astronaut.

Turns out I'm not crazy enough. The astronauts have all the crazy anybody could possibly need, and then some.



Who'd have thunk it?

Y Combinator in Ruby

Kind of disappointing; more complex than I thought it would be.

Sunday, February 4, 2007

Gyre

Adam Wiggins at Bitscribe (where I started last week) has created a Rails IDE which is itself a Rails app.

It's at a beginning stage, in fact still a very early stage in some respects, but it already features breakpointer integration with onscreen line numbers, an ActiveRecord-specific object inspector, and of course a nifty screencast.

Of course I have to point out that, like Pat Maddox with his declarative workflow, Adam is making Rails better by making it more like Seaside. These are features which Seaside has had for a while. If we get to the point where you can edit Rails code from the browser directly, however -- the way you already can in Seaside -- that'll be pretty remarkable. Perhaps even incredible. Certainly, this is an interesting project.

I should also point out that Bitscribe is hiring.

The Y Combinator

This thing is as bad for your brain as acid. The only difference is you can put it on a resume.

(If the Scheme is weird, check out this Perl implementation.)

REST in Seaside

Turns out this is possible.

Saturday, February 3, 2007

Absolutely Excellent: Declarative Rails Workflow

The blog post and the screencast.

Pat Maddox's workflow engine. Really, really good idea. Basically it allows you to develop as if Active Resource were the same thing as Object -- which it essentially is -- and avoid writing Rails as if it were PHP. I don't want to say too much about it until I've actually built something with it, so just take a look at the screencast. Both the screencast and the post demonstrate why there's a need for something like this in the first place before going on to show how much easier this approach is.

As somebody who thinks that Rails and Seaside both have compelling advantages over each other, yet totally wtfpwn other frameworks, it's really nice to see this, because it really brings some of the advantages of Seaside into Rails. Pat's workflow engine decouples the requirements of creating or updating "a resource" (an object) from the create or update actions doing the creation or the updating. The reason this is useful is it allows you to juggle these things flexibly, the same way you can in Seaside. Your code has no restrictions on the order that attributes on a (resource|object) are defined, so you can pretty much locate that stuff anywhere in the application you want. Obviously, if you integrate it nicely with Ajax, you've got the capacity to save data as flexibly as a desktop app can.

Again, I haven't actually used it yet, please take this with a grain of salt! However it looks like a very, very good idea.

Thursday, February 1, 2007

Studying The Classics

A year ago Joel Splosky asked, Are pointers and recursion the Latin and Greek of Computer Science?

I don't think so. Bragging time: I could read Latin and Ancient Greek at the college level in high school. And my bragging becomes relevant: I think Smalltalk and Lisp (respectively) are the Latin and Ancient Greek of programming.

(The real reason for the bragging isn't to build my ego. It's to give me an excuse for skipping paragraphs and paragraphs of detail. I'm tired from driving to from northern New Mexico to Los Angeles in less than 24 hours, so I want to say just trust me on this.)

If you learn Latin, every European language with the exceptions of German and Icelandic will become much easier to learn -- yes, even English -- and your understanding of these languages will be much, much deeper. If you learn Ancient Greek, your head will explode, and you will never recover.

If you learn Smalltalk, every object-oriented language becomes easier to learn, and your understanding of these languages will deepen. If you learn Lisp, your head will explode, and you will never recover.

Quod erot demonstrandum. (Which was the thing to be shown.)

Screencasting Insanity

Stop the madness!

Actually I think screencasting is an incredibly cool phenomenon. I've been travelling and am utterly exhausted, but planning to blog a bit more about it soonish.

RIP Molly Ivins

The kick-ass columnist is gone. It's a sad day.