« June 2006 | Main | August 2006 »
Listen to this article
I'm not sure anyone else really bothers but today I decided I'd try listing to the Text-to-Speech version of this blog by clicking on the Listen to this article link. Apparently the software they use hasn't caught up with Plugin as a commonly used variation of the hyphenated Plug-in. I was somewhat amused therefore, to hear about the Ruby on Rails ploojins :).
Listen to this article
Yet another plea: Please don't add foreign-key migrations, schema validations or for that matter acts_as_taggable or any significant number of the myriad plugins that are now available. Leave RoR as lean and as mean as possible. By all means change your assumptions and your opinions but don't allow Rails to become the Micro$oft Word of the Ruby world—bloated and with features that < 1% of the community ever use.
I'm pretty opinionated. DHH is obviously pretty opinionated. That doesn't mean I necessarily agree with his opinions—I clearly think foreign-keys are important—but that doesn't prevent me from using RoR. In fact, quite the contrary. Precisely because DHH is so reticent to adding every new feature under the sun into RoR, the current feature set appeals to most of the developers who use it. This is not to say that Rails is in anyway fully-featured but what is there, most people use. So what about all that neat stuff that we all think is great and absolutely necessary but with which DHH and, no doubt, a non-trivial number of other developers in the community disagrees?
I think my favourite feature of RoR is the very sophisticated plugin model. With a little thought and imagination, it's pretty easy to implement just about any extension imaginable. And this is where the power lies in being lean, mean and opinionated. It's much easier to add features than to take them away—actually it's pretty easy to take them away too but it can get pretty ugly and besides, who wants to spend their time writing plugins to disable functionality? In fact I like plugins so much, I've started thinking about my applications as collections of plugins. Plugins work, there are lots of them, they allow you to add features that no one ever dreamed of and then, with very little effort you can, if you're a good sort, give something back to the development community.
You probably don't want to use much (if any) of the stuff that I think is useful and I sure as hell don't want your manky ideas cluttering up what continues to be my favourite development environment. So, please stop inundating the RoR Trac with every little thing that you believe to be 100% necessary and start building and publishing plugins.
Listen to this article
After listening to Prag Dave's Keynote Speech this afternoon, I was motivated to implement some of the things he'd been asking for. Here's my first cut at it.
As the doco says, the plugin reads some—ok only one at the moment but we'll see how many others I get done before the beer runs out—database column constraints and tries to apply the closest corresponding rails validation. The first one I implemented reads the NOT NULL constraints against columns and generates a corresponding validates_presence_of.
I literally just whipped it up with no tests or what-not and I've only played with it against PostgreSQL, so if it has bugs or behaves oddly for whatever reason, please let me know, send me as much info as possible and I'll make it work. Nothing better than having real people testing it for me ;-)
Update: Ok, so far the beer has lasted long enough to implement validation of numbers (including specific support for integers) and lengths of strings.
Update: Now calls validates_presence_of anytime you declare a belongs_to association for a NOT NULL foreign-key column.
Update: Single-column unique indexes are now converted to validates_uniqueness_of.
Listen to this article
This morning, my brother was sitting at his laptop attempting to get FreeBSD to mount a ReiserFS partition without much success—some permissions problem that means he can mount it as root but not from fstab—when his girlfriend sat down beside him, peered over, and asked "What's that weird devil number?" Naturally we both had a little WTF moment. "See", she continued, "it's even called devil!"
On closer inspection, it seems the file permissions for /dev are, understandably, 666. Riiiiiigghhht!
Listen to this article
Be warned, this is somewhat of a stream-of-consciousness even if a little edited.
I was sitting at work today pondering, among other things, some particularly awful code that we happened upon—so what's new? The code in question relied upon multiple columns in a table to hold configuration information when really what was needed were multiple rows—something like a properties file but in a database. I then started to think that I pretty much always start out wanting my data to be "properly" normalised without regard to performance considerations. As Knuth is oft-quoted as saying, "premature optimisation is the root of all evil."
One thing I really like is when a development environment allows me to easily layer on performance enhancing behaviour such as caching, without unduly interfering in the core design of the system. In a Rails for example, I can build a completely dynamic application and strategically add caching where necessary for content that is, for the most part, static. If the data on which that content relies changes, expire the cache and it'll be re-generated.
At the same time, I was pondering why it is that I like Ruby so much and why I believe it really makes development environments such as Rails possible; in a way that Java just doesn't. Although a topic for another blog entry, one of the reasons I considered was it's dynamic (ie non-compiled) nature. That I can change a piece of code and immediately run it without a compilation step is, IMHO, a big factor. (I'll grant you that Eclipse goes a long way towards achieving this for Java with its continuous compilation but I feel there is more to it than just that.)
It then occurred to me that compilation, or, more specifically, the translation of source-code into some executable form and stored in some more persistent manner (such as files on a hard disk) is really a form of caching.
To see what I mean, imagine you started with a fully, 100% interpreted language where each statement is re-parsed each time it is executed. Ie. no caching. To this you then decide to convert the source-code into an intermediate, in-memory, form to remove the need to re-parse the source-code each time. This is a first-order cache. Finally, you decide to write this intermediate form to a more persistent medium so as to remove entirely the need for conversion from raw source-code to an executable form. This is a second-order caching. You could of course further translate the intermediate form into native machine code or any number of intermediate formats. And, of course, once in memory, the intermediate format could be dynamically translated into machine code—such as a Just-In-Time compiler or Hot-Spot compiler does.
The point I'm trying to make however is not how efficient one can make the execution process but simply that it is entirely possible to execute the raw source-code with a very simple parser and interpreter. The fact that we choose to further translate that source-code to forms specifically designed to improve execution efficiency is an optimisation and, in many ways, not so different to storing the output from a Rails action on the server, or a web browser caching an image or an HTML page.
Where the analogy breaks down of course, is that compilers often provide other benefits such as detecting poor or incorrect use of the langauge. That said, some of these benefits are lost—or for that matter not even useful—when using languages such as Ruby and yet other benefits might be found in static analysis tools.
So, what does this all have to do with anything?
That's a very good question to which the answer may well be "not very much at all" however, I did find it interesting to ponder, as one does ;-)
One thing that I have noticed though, speaking of source-code, is there exists a distinct difference in the way the Ruby versus Java communities treat the sharing of code.
In the Java community, sharing of code is largely done by means of pre-compiled libraries with accompanying documentation. Sure, we have open source projects which make the source-code freely available for (ab)use. But, and I admit to having been guilty of this myself, the general feeling is don't modify the source unless you really need to; treat the binary distribution as a black box. And perhaps for good reason?
In the Ruby (and apparently Smalltalk) community, the philosophy is more one of source-code sharing. Need a Rails plugin? download the source-code into your source-tree; Looking for some missing Ruby functionality? Native extensions aside, what you'll get is a bunch of source-code. In most cases the source-code also comes annotated with RDoc—the Ruby equivalent of Javadoc— but even still, being confident to look into the source-code is, IMHO, a bonus.
Of course, there are those who would argue that sharing of raw source-code isn't always a commercially viable option and perhaps they're right.
In any event, I'm not sure I have enough experience in either yet to have formed an opinion as to which (or even if) one approach is better than the other but I do wonder if the fact that one is primarily treated as a compiled language whereas the other is essentially treated as interpreted leads to at least some of the differences in culture that I see or if I have cause and effect around the wrong way.
Listen to this article
I'm back doing some Java work at the moment and although coding in Java feels somewhat like trying to speak with a mouthful of peanuts—compared with Ruby—I'm rather enjoying it for some perverse reason. That said, my long-time trusty steed in such endevours is really beginning to annoy me. IntelliJ, once the lean, mean, IDE has porked out considerably over the last few releases. It seems that in competing with Eclipse, it is becoming Eclipse: fat, bloated and slow.
IntelliJ has become a bit like Micro$oft Word: I only ever use 5% of the features—and that's just the features of which I'm actually aware; I'm beginning to need the 2GB of RAM in my laptop just for IntelliJ; oh, and SVN+SSH integration just plain sucks. I'll be sticking with the command-line version thank you very much.
It's all very well and good to have all these nifty tools, etc. in the IDE but seriously, I never use them. Nor, for that matter, do I want to get into the habit of doing so for one simple reason: I have command-line build tools so that I may run the build on any machine, at any time of the day, even *gasp* when there is no IDE involved nor a programmer to be found.
So here's a plea to JetBrains: I paid good money for your software and I'll be more than happy to continue paying good money if you'll please oh please let me turn off all those features that make me feel more like I'm using WSAD.
What's next, Perspectives? Gadzeeks!
Listen to this article
I'm usually reticent about making politically motivated blog entries but today I was having a to-and-fro via email with a friend of mine when she made a statement that, especially in light of the hoopla surrounding a certain TV show here in Australia, I felt was too good not to quote:
It's a pity that the people who watch Big Brother don't equally scrutinise the behaviour exhibited on that other reality TV show, 'Parliament Question Time'.
Here, here.
Listen to this article
When I moved to FeedBurner I hardly ever used delicious and I thought it might be interesting to have any new links included as part of my feed. These days however, I find myself adding links to delicious on a regular basis and my feed has been somewhat flooded as a consequence. So, by request, I've removed the links from the feed. You can always subscribe to them using delicious anyway if you really cared (not that you probably did).
Recommend me on Working With Rails
Simian (Similarity Analyser): Rapidly identifies duplication in Java, C#, C, C++, COBOL, Ruby, JSP, ASP, HTML, XML, SQL, Visual Basic source code and even plain text files.
Beginning Algorithms
Powered by
Movable Type 3.2
Subscribe to this blog's feed