Posted by Rick DeNatale Tue, 14 Aug 2007 15:03:00 GMT
The first Ruby Hoedown, sponsored by the Raleigh Ruby brigade, has finally come and gone. I had a great two days, saw some old friends, and made lots of new ones.
Here are my initial thoughts after more than a bit too litle sleep after a night trying to root out werewolves.
Read more...Posted by Rick DeNatale Tue, 07 Aug 2007 19:24:00 GMT
Not long ago while working on an existing Rails application, (i.e. code I hadn’t written). I was mystified when a logical expression seemed to be returning an odd result. The expression had been written with not, and, and or, and was the right hand side of an assignment statement. ventually I changed to using !, &&, and || which fixed the problem. I never completely understood what was going on, until I encountered this blog entry by Jay Fields.
One of the big differences between Ruby and Smalltalk is the use of operator precedence. In Smalltalk, the grammar is very simple, unary message selectors bind tighter than binary selectors, which bind tighter than keyword selectors. The assignment operator binds more loosely than any of these. This is often a stumbling block for newcomers to Smalltalk when they find that in Smalltalk 3 + 5 * 2 evaluates to 16.
Ruby in comparison has quite a rich and flexible syntax. Usually, it’s quite intutitive, but, depending on where you come from there can be some surprises.
I understood the relative precendences of, say && vs. and in Ruby, but the fact that and had weaker precedence than = escaped me, until Jay’s article turned the light on for me.
As they say, you learn something new everyday, or at least you hope you do. I don’t expect that I’ll forget this little corner of Ruby in future
Posted by Rick DeNatale Fri, 03 Aug 2007 00:11:00 GMT
This looks interesting.
I wish I had a nickel for every time I’ve typed something like:
grep whatever -R . | grep -v .svnPosted by Rick DeNatale Wed, 18 Jul 2007 19:45:00 GMT
At first, I did a fairly simple hack which monkey patched the system methods Time.now, and Date.today. This worked until I got into some testcases of code which was triggered off of updated_at fields in various ActiveRecord models. Since I had to deal with these implicit dates, I found that I needed to have finer control than my simple patch gave.
The code has now evolved to the point where I think that it shows some interesting aspects of basic Ruby metaprogramming.
Read more...Posted by Rick DeNatale Sat, 14 Jul 2007 19:28:00 GMT
The other day I was working on adding support for user selected time-zones to an existing rails app for a client. As usual I was doing test-first development. One of the things that makes rails such a pleasure is that a good set of tests give confidence that you aren’t breaking “legacy” code.
I also use, and really like, the rails plugin for vim which does lots of nice things like making navigation between the files of rails apps much easier. It also has a nice feature which adds a :Rake command to vim which “does the right” thing contextually. For example if you are editing a migration and enter :Rake, it runs rake db:migrate. If you are in a test file it runs just the single test selected by the cursor, or just that test file if you aren’t positioned to a particular test.
I was doing the latter, and my test was failing, and I was having a hard time debugging it. I tried executing just that single test from the bash command line with:
$ruby test/unit/my_test.rb -n"test_mytest"So I figured I probably should test everthing so:
And, surprise of surprises, but every test worked. Not only my failing unit tests, but the functional and integration tests as well.
To make a long story short, the problem turned out to be that the tests were failing because, now that the particular model was sensitive to the user’s timezone, it needed access to it’s associated user model, and I hadn’t told the testcase that the users fixture was needed. Running the testcase in isolation, the users table wasn’t being populated for the test case. But running rake test, or rake test:units meant that other tests run before had left the data I needed behind.
Just a little thing that makes fixtures less than ideal.
Posted by Rick DeNatale Fri, 22 Jun 2007 14:29:00 GMT
Recently on gluttonous, Kevin Clark announced that Powerset is going to launch their front-end on Ruby. It seems that they were already pre-disposed to a major ruby comitment having built a sizable Ruby talent pool for their internal applications.Prior to making the final decision to go all out with ruby for their front-end launch, the did some due diligence which included investigating the facts behind the recent furore caused by an interview with one of Twitter’s developers.
So they went to Twitter’s lead developer, Blaine Cook to get the straight dope.
Quoting Kevin:
The simple fact is that Ruby wasn’t the source of Twitter’s woes. As it often happens with rapidly growing sites, they ran into architectural problems. Some design decisions don’t hurt until they reach a massive scale and at that point you have to rethink your approach. In an email he writes:For us, it’s really about scaling horizontally – to that end, Rails and Ruby haven’t been stumbling blocks, compared to any other language or framework. The performance boosts associated with a “faster” language would give us a 10-20% improvement, but thanks to architectural changes that Ruby and Rails happily accommodated, Twitter is 10000% faster than it was in January
That last sounds quite true and corresponds to my experiences in the past with Smalltalk. I used to tell IBM customers that almost all performance comes not from the language but from application design, and that using a dynamic language which allowed the application to be developed in what’s now called an agile development process allows major performance gains through refining, refactoring, and retuning the system as both business and performance requirements get uncovered/discovered.
That’s as least as true of Ruby as it was of Smalltalk 15-20 years ago.
Posted by Rick DeNatale Thu, 21 Jun 2007 19:06:00 GMT
Maybe I’ve gotten a bit sensitive of late to the perception some Rubyists seem to have of Smalltalk-bred Rubyists like me. So I thought that I might say a bit more of what I think of the current and future of Ruby as a language. What follows is much longer than what I expected it to be when I started writing it yesterday, I hope that some will find it some combination of interesting, useful, thought-provoking, or at least amusing.
Read more...Posted by Rick DeNatale Tue, 12 Jun 2007 21:22:00 GMT
A few days back I wrote this:The metaclass’ superclass is set to the metaclass of the classes superclass.
Since I first wrote it I’ve gotten some feedback that the last sentence is a little hard to digest, so I’ve added an example.
Let’s say we create a class MyNiftyClass as a subclass of Object. The singleton class of the class object referenced by the MyNiftyClass global gets created at the same time as class object, no waiting for one of the things which trigger the creation of a singleton class for a non-class object. Thesuperclass of the MyNiftyClass is set to object, and the superclass of MyNiftyClass’ metaclass is set to Object’s metaclass.Besides the fact that their creation occurs immediately, there is one other difference between singleton classes of objects and singleton classes used as metaclasses. The later can have subclasses, while the former cannot.
I’ve gone back and editted the original post, but I’ve summarized it here in case anyone else has actually already read it.
Posted by Rick DeNatale Tue, 12 Jun 2007 15:24:00 GMT
At the last meeting of the Agile RTP group, I won Michael T. Nygard’s book Release It!
Interpreted languages such as Java and Ruby almost never crash. Sure they get application errors, but it’s relatively rare to see the interpreter or virtual machine crash. I still remember when a rogue pointer in C could reduce the whole machine to a navel-gazing heap.
I remember “back in the day” when there were endless arguments between the C++ and Smalltalk advocates. The C++ folks would often quote Bjarne Strroustrup’s fear of flying in an airplane whose flight control system was written in Smalltalk, and threw a “message not understood” exception.
Those of us in the Smalltalk camp found this amusing, since the alternative was a system crash caused by an invalidpointer.
Now maybe Nygard framing rogue pointers in C as a memory means that the problem has been solved, but I seem to recall having seen it recently.
One point here is that pet-features such as strong vs. dynamic typing or garbage collection vs. allegedly more performant[1] manual memory management aren’t panaceas. They can have a major effect on aspects such as easo of development, or tweaking out the last bit of performance, sometimes in non-intuitive ways.
Making robust software requires more than just choosing a language, it requires craftmanship, adherence to best practices for the chosen language(s) and technologies, and a realistic understanding of the challenges at hand.
And that’s where we come back Nygard’s book. Although I assume that most of my readers are Rubyists, and Nygard is a Java guru, there is much of value here for anyone concerned with producing robust software that can stand up to the real world.
Based on what I’ve read sofar, and skimming the rest, I can recommend it. If you’re interested you can buy it directly from the Pragmatic Programmers, or via the amazon.com link. The later would help feed the duckdogs who run this site, and lower my distraction from their gowling stomachs.
[1] The “allegedly” will no doubt be explained in further posts here.
Posted by Rick DeNatale Wed, 06 Jun 2007 21:00:00 GMT
Robert Dober discovered that the continuation example which I gave in last night’s article behaves badly if you run it with ruby rather than irb.I’ve made note of this in the original article, and I’ve added a simpler example which does work under ruby. I’ll try to come back with a new article which shows an example of how continuations are normally used.
I'm an old Smalltalker to whom Ruby looks like an old friend. To get a perspective on my perspective and credentials, have a look at my mini-memoirs
If you like my blog, you might consider recommending me on Working With Rails.
|
|
 |
|
|
|
 |
|
|
