November 30, 10:56 | Comments (7)
While Sun has probably done a great many good things in the tech world, I can't stand the mixed signals coming out from the company lately. Love us, love us not. Be open, be closed. Linux good, Linux bad. At least Microsoft is somewhat consistent (of course except when they're not).
The latest star goal is the harassment of Ted Neward for running JavaGeeks.com. A site that in no sane person would confuse with as Sun-powered entity. Unless you're part of the IP attack squad at Sun, of course:
Your web site provides information to consumers of information and thus constitutes a "service." Whether or not the site is interactive in nature or whether it sells anything to consumers is not the point. Your use of "JavaGeeks" in connection with such a site may cause consumers to be confused as to whether your site is connected with or somehow sponsored or approved by Sun.
Oh my. Please don't talk about our products, you may confuse the customers! No problemo, maestro. Which almost the conclusion of Neward:
Personally, I'm beginning to wonder if I shouldn't just take up Ruby, Python and .NET and leave Java to the lawyers. Nothing like good legal interaction to sour one on a technology, eh?
Please do come on over, Ted. There's lots of fresh water in the Ruby tank. And no suit-clad lawyer sharks to spoil the flow.
Hopefully this will give pause for thought under the Sun. When the voluntary evangelists aren't feeling welcome, it might be time to loosen the noose. Smart people won't stand for frivolous intimidation.
November 30, 0:24 | Comments (7)
Last night, I rode as a passenger of a car from one part of Copenhagen to another — online with the Powerbook through the 3G connection on the phone. Speed was excellent, the connection was almost instantaneous, and there wasn't a single drop for the entire ride. I arrived pretty darn impressed and more the believer in 3G (at least for city slickers) than ever.
Tonight, I returned from dinner in honor of Christina Wodtke arranged by Lars Pind (lots of interesting talks and ideas around that table!). Anyway, waiting for the bus and going home I...
- finished reading the October archives of elegant hack
- checked my email reading up on issues surrounding the launch of SSL for Basecamp
- listened to a new playlist I had prepared just before I left (until I get my 1GB card, one playlist is all it'll hold)
- sms'ed the girlfriend that I was on my way home
- played the best version of Tetris ever made (the Gameboy Color edition, of course!)
This is indeed the first phone that I truly feel realizes the smart phone potential. I'm pretty darn psyched, so let me repeat the conclusion from the review: Best. Phone. Ever.
November 28, 13:48 | Comments (15)
After a surge in sales starting in Spring this year, 3 now has enough customers to make every problem instantly visible and of interest to the mass media. That's indeed a mixed blessing.
A few days ago, they starred the leading consumer watchdog program on DR1 (national TV station). Unfortunately, the important issues (spotty coverage, wrong billings, long waiting on support calls) were mixed in with silly complaints about consumers with less than a clue couldn't figure out how to use their phone and the price of dialing support from a landline.
On top of that, the tone was unfortunate in the "new tech is only bad tech" key. New technology does indeed have its share of problems. 3 has been the only player in Denmark with 3G for over a year despite the fact that there are two other active licenses here (to TDC and Orange/Telia).
So the tech isn't perfect. The rollout of GSM wasn't perfect either. 3 could and should do a better job explaining that, though. Unmet expectations are the worst customer confidence killer. But if you approach a 3G phone as an early adopter, you're actually likely to be pleasantly surprised.
Personally, I've found that the 3G network works most of the time and that the 2G backup does a pretty decent job of kicking in when it doesn't. In other words, I'm willing to trade a bit of stability for a killer connection. If that's not a trade that sounds like a good deal to you, do get a 2G phone while the tech matures.
I sympathies with people who either had particularly bad tech (like phones that doesn't switch between 2G and 3G without dropping the connection) or a bad customer support experience. Hopefully they can find consolation in sarcastic humor and either upgrade to better tech (did I mention I love my Nokia 6630?) or quit 3 with a message that their segment won't be ready for mass adoption before the kinks are ironed out.
Disclosure: I've written two articles for the Danish 3 Magazine, appeared on national television praising 3, love downloading at upwards 35 kb/sec, and think that the Nokia 6630 (a 3G phone) is the "Best. Phone. Ever."
November 26, 15:02 | Comments (268)
 Ever since I got my Motorola A925 in the Spring, I've secretly been longing to go back to a Nokia. And when the 6630 was announced almost six months ago, I knew that was the phone that would take me back to Finnish mobile engineering. The specification read 3G, 1.3 megapixel camera, 1 hour video records, more RAM, smaller size, and lots of other goodies.
Recently, though, my longing for Nokia had grown into despise of my A925. Russel was spot on with Smart Phones Are One Handed Devices. What I wanted was a smartphone, what I had was not:
If you can't use the phone with one hand, it's not a smart phone. Got it? It's pretty simple. It's a PDA Phone or a Communicator or something. Whatever it is, it's not a smart phone. It's a relic. An elecronic organizer with an antenna. An anachronism. A soon-to-be market failure. Get the idea?
Let's go over this again: If it doesn't have a keypad? It's not a smart phone. If you have to use a pen? It's not a smart phone...
The Motorola A925 is not a smartphone. It's successor, the A1000—that I tested for the Christmas issue of the Danish 3 Magazine—is not a smart phone either. I had to learn that fact over a couple of months. When you have to stand still and use two hands to SMS or when you need either really baggy pants or a bag to carry your phone around, something is just not right.
Continued...
November 19, 14:43 | Comments (18)
After looking closer at the dependency injection proposal by Jamis Buck and talking to Dave Thomas about his hesitations with full-blown DI, I had all these thoughts spinning and flying around my head. The first representation of these thoughts are that requires should be made part of the domain language, so from the next release it'll be possible to scrap almost all your explicit require statements.
I've added three new words: model, service, and observer. The first two will just do a regular require, but will then also enable you to introspect the controller for its dependencies. The latter will also instantiate the observer, so it's active:
class MsgController < AbstractApplicationController
model :post, :comment, :attachment
service :notification_service
observer :comment_observer
end
MsgController.dependencies_on(:model) # => [ :post, :comment, :attachment ]
MsgController.dependencies_on(:service) # => [ :notification_service ]
MsgController.dependencies_on(:observer) # => [ :comment_observer ]
This it not only shorter and more expressive, it also opens up to a world of interesting automation and scaffolding when you can programatically inquire about the dependencies of a controller. A simple example would be that fixtures for functional testing the controller could automatically be managed and setup.
I've also went ahead and improved associations, so they now too automatically will attempt to require the class they need. So instead of repeating yourself with:
require 'comment'
class Post < ActiveRecord::Base
has_many :comments
end
You can now leave out the explicit require and just rely on Active Record to follow your association specification and do the require:
class Post < ActiveRecord::Base
has_many :comments
end
This should also spell an end to all those annoying errors you get when you forgot to require a class before starting to use it. Just like I was thrilled to be rid of the semi-colon at the end of each line when I ditched PHP for Ruby, this will further swift the burden of repetition over to the framework.
Do the Mocking
But this is not all! In companionship with Dave Thomas, I've relieved the primary pain that got me interested in dependency injection in the first place: How to inject mocks in hard to reach places? Specifically, how could I replace my FTPServer, PaymentGateway, and Notification services in Basecamp with mocks that didn't rely on external machines and that I could inquire about how they were called?
In the next version of Rails, that'll be incredibly easy. There's a new directory called test/mocks where you can drop in any class that you'd like to see replaced with a mock under the test environment. So if I want to mock out the PaymentGateway in Basecamp, I'll create the following file in test/mocks/payment_gateway.rb:
require 'models/payment_gateway'
class PaymentGateway
def commit
SuccessfulSubmission.new
end
end
I require the original payment gateway first, then I re-open the class (Ruby has open classes, you can reopen anything — even core classes!) and mock out the behavior that I want to change. In this case, it's the commit method that would otherwise start to talk to the Authorize.net server.
You could also forgo requiring the original class and just use a straight mock, but it's often much nicer to rely on as much "real" functionality as possible. Just mock out the few methods that would otherwise make testing hard to do.
Anyway, these latest breakthroughs does cast some doubt in my mind on whether full-blown dependency injection is needed in Rails. All of the additions above where created with an absolute minimal amount of code. They give zeroconf dependency injection for mocks and the conceptual complexity of Rails doesn't go up one bit.
I'll be sure to revisit Jamis' proposal and look for other advantages of integrating with Needle, though. These improvements, however, have cured my immediate needs for injection. I got my fix, so to speak.
UPDATE: If you want to try out these new features, the beta gems have them. Upgrade with gem update -s http://gems.rubyonrails.org.
November 19, 10:53 | Comments (7)
The seven-man shop from Seattle known as The Robot Co-op have revealed a sliver of their grand idea: 43 days until the New Year — What do you want to do with your life? This single narrative of the full story have been christened 'Twinkler', which Erik introduces with:
The basic idea of Twinkler is this: it’s a well known fact that by writing down your goals you greatly increase the chances of actually completing them. Part of it is just knowing what your goals are. Another is being able to hold yourself accountable. Here’s a place to write down some things you want to do with this life, look at what other people want to do, and generally think about what makes life exciting for you.
I've started my list of things I want to do with my life. Please do get on with yours!
Oh yeah, Twinkler is built using Ruby on Rails. So is "real" site. The Robot Co-op have four great developers, a systems administrator, and two inspirations working on software powered by Ruby on Rails.
November 18, 1:28 | Comments (9)
Despite the best intentions with release 0.8.0, I still managed to drag this release on for so long that a total of 76 changes made its way in. But it’s all good. This release features yet another incredibly strong showing from the community with some 22 contributors seeing their code in the release. Special notice must go to Jeremy Kemper aka bitsweat that has contributed a third of the changes in this release! And super high quality patches too. Thanks, man. Read more in Release Notes For Eight Five.
November 17, 14:32 | Comments (18)
I've been programming Ruby for just over a year now. When I started out, I was slightly puzzled over why Ruby had so many introspection hooks and runtime dynamics in it. When you would ever need to know programmatically when someone added a method?
My puzzlement has since turned fascination and my fascination turned complete awe. Matz is indeed a golden god for having the foresight to construct such an incredible rich environment for dynamic programming. As a framework extractor, I constantly find new ways to simplify the user experience by discovering the usefulness of yet another hook.
Just yesterday, I improved fixtures handling in Active Record test suites by extending the ever growing domain language of Rails to include the following style:
class PostTest < Test::Unit::TestCase
fixtures :posts, :comments
end
This macro-like construct ensures that the database fixtures are properly setup and torn down before each test case, but they also place the actual fixtures themselves in instance variables ready for immediate use:
def test_comments_to_post
@post_about_yesterday.comments << @fresh_comment
assert_equal @fresh_comment, @post_about_yesterday.comments.first
end
"post_about_yesterday" and "fresh_comment" are the file names of two fixtures. I didn't setup these instance variables explicitly. They simply spring to life when one uses the fixtures :posts, :comments construct.
Although this is terribly nice and Ruby made the implementation trivial (4 lines of code), it wasn't what I wanted to show you. See, the fixtures construct needs to do work in TestCase#setup, but how can I overwrite that without subclassing TestCase and without making the particular setup explicitly call an additional setup method for the fixtures to work?
In Ruby, easily. I take advantage of a object life-cycle callback named method_added that can be overwritten for notification. That is programmatically inform me when someone adds a new method.
With method_added, I stand guard for a user-added setup method, catch the definition, renamed their method to setup_without_fixtures, inject my own setup method that does the fixtures magic, and finally call setup_without_fixtures. All in measly six lines of code:
def self.method_added(method_symbol)
if method_symbol == :setup && !method_defined?(:setup_without_fixtures)
alias_method :setup_without_fixtures, :setup
define_method(:setup) do
instantiate_fixtures(*fixture_table_names)
setup_without_fixtures
end
end
end
This new fixture feature will be part of the upcoming Rails 0.8.5 release.
Thanks to Xal on #rubyonrails for suggesting the form for fixtures :posts and thanks to Nathaniel Talbott for pointing me in the direction of method_added.
November 15, 22:20 | Comments (11)
I'm in contact with a company in the San Francisco Bay area that are starting up development using Ruby on Rails. They'd like to get in contact with at first one developer local to that area. Later on, possibly more.
Do you have experience with Ruby on Rails development and are you in the area or close enough by? Drop me a note and I'll hook you up with the firm.
They bring prior "smash hit" experience to the table and are describing their new venture as "...very exciting and should have wide appeal".
November 14, 19:54 | Comments (16)
Jamis Buck has an incredible detailed exploration of how an dependency injected world would look for Rails. We could be cute and call it Rails on the Needle, but we won't — the metaphors are already fairly fuzzy.
I'm much intrigued by the whole dependency injection game. I've been following along from the sideline since JAOO '03 where I hung for a while with ThoughtWorkers Hammett and Aslak for chats about Ruby, testing, and of course Inversion of Control/Dependency Injection talks. Hammett introduced it as the Hollywood Principle and while fascinated, I wasn't really seeing the applicability at the time.
Martin Fowler's defining article on IoC Containers and the DI pattern brought all the concepts into focus, but I still wasn't really feeling the hurt that this approach would be solving in any of my Ruby work.
I am now. Writing functional tests for Basecamp is at least a little painful when there's no easy way to automatically inject mocks for my GatewayService (talking to Authorize.net) and my ActionMailer. The latter is getting souped up for better testing in the next release (so you don't even need a mock), but I'm still getting the picture. DI is great for injecting mocks in hard-to-get-to places.
But I've never been comfortable with the explicit registry lookups or method assigns. Especially for class methods, like Account.find_all. So that turned me off Jamis' first proposal. But a few talks with Dave Thomas brought up the idea of transparent DI:
So I suggested to David that we could make Rails more explicit. Rather than having some random instance variable containing the model’s class, we could declare that such-and-such a class represents a model that the controller is using, but have that class actually injected by the framework.
I like this idea a lot. It's basically business as usual with DI for free. So you wouldn't even have to choose whether to do DI or not up front. Just as soon as you're feeling the pain, you start injecting.
So I got the hots for this proposal. The major thing still holding me back is what it'll do to the complexity of the internals of Rails. I think it'll even decrease the amount of code used, but the conceptual complexity will go up. I'm just starting to get to terms with DI, so I can definitely relate to those fears that other contributors have voiced.
But I think the proposal Jamis has put together goes a long way to dispel those fears. It's centered purely around wiring controllers and models together and if you're uncertain of the value of injecting mocks, you can just not use it. And the world will spin around like it did yesterday.
Yes, I'm feeling good about it. And Jamis is about as smart a developer as they come, so when he's excited about something like Rails on the Needle, I'd be a fool not to listen really closely.
November 12, 16:20 | Comments (9)
Vince has a tutorial for getting started with Rails by writing a todo list application. It's a very nice step-by-step approach with screenshots and plenty of hand-holding. So if you're just starting out with or considering to give Rails a shot, it's an excellent companion to the video, reference documentation, and howtos.
Once you've gotten a hold on the basics in Rails, you'll want to move on to testing pretty quickly. Testing runs deep with the Rails from the automated testing files generated by both new_model and new_controller generators to the wide range of assertions available.
Steve Kellock explains all about it in Testing with Ruby on Rails. From unit to functional testing, from why to how. It's all there in his 30-paged PDF on the subject. Oh, and it includes a very nice reference documentation on all the assertions as well with all options explained. Awesome work.
November 12, 15:10 | Comments (7)
Jason just announced that Firefox is the primary browser target for Basecamp. Platform-specific browsers like Safari and IE 5/6 are of course still supported, but Firefox is where markup and looks will be verified first.
Personally, I'm still on Safari for OS X. It feels slightly faster and the form controls are just so much prettier that I haven't been overwhelmed by the urge to switch... yet. But if I was still on a PC, I'd consider myself downright foolish if I was still using an out-dated and security issue-ridden browser like IE6.
Firefox is a great browser on any platform, on Windows it's the only sensible choice. Please do switch if you haven't already: Firefox 1.0. While you're at it, get friends and family on the wagon as well, and let's see Firefox climb to a two-digit market share in no time.
UPDATE: Microsoft says Firefox not a threat to IE from CNet includes a full dismissal of Firefox by Microsoft's Steve Vamos. He claims that IE is just as secure as Firefox, that the Mozilla-based browser doesn't have any important features (otherwise MS customers would have told him!), and that it's no threat to the IE market share. Oh, please, please make him wrong. Download Firefox today.
UPDATE 2: Stefano has even more good reasons for why you should ditch IE.
November 10, 7:19 | Comments (7)
So as if getting grilled at the border wasn't enough, I just learned the hard way that VISA doesn't necessarily mean VISA. Apparently, there's a number of different flavors over here in the US. The flavor accepted by cab drivers and most ATMs outside the Union Square area in San Francisco doesn't take kind to expiration dates in 2012 and fancy chip security — like all European countries are switching to.
So I just had an... uhm... "interesting" experience with an asian cabbie that was going to take me down to a store to do a last-minute purchase for a friend. We get all the way down there before his machine finally rejects the card because of "invalid expiration".
Of course, I only have five bucks in cash, which wasn't going to cut it. So following the directions of the guy at Best Buy we drove a bit further down to some shopping district to a Safeway. I get in to get cash out of their Well's Fargo ATMs, which of course doesn't work either. It offered a kind suggestion that I should contact my financial institution, though — thanks Well's!
I try the register, but that won't let me get money out either (but would let me get a coke, yay!). So I have to go back to the cabbie once more and now he's starting to get really unhappy about the situation. After a bit of back and forth, we decide to head back to the Union Square area to try more ATMs, finally finding one that works.
So $25 lighter, I'm back at the hotel without my intended purchase and actually kind of looking forward to the grueling 15-hour flight back to Denmark tomorrow. It's been great and all, but I'm ready to get home.
November 07, 19:05 | Comments (10)
One thing that surprised me coming to Ruby was how extremely friendly everyone was. On ruby-talk, pretty much everyone doing interesting things in Ruby are hanging out ready to pick up questions and debates when they fall within their territory.
This made the transition from the scattered and fragmented communities of PHP so much easier. One place to look for all the experts and they even bothered to answer my silly questions.
I was equally surprised by the presence of Matz. On several occasions, I'd write a simple question only to see it answered by the creator of the language itself. That's a pretty powerful motivating factor when the creator is still that involved and caring for his creation.
The best part of the friendly welcome is that it's contagious (Daughters will love like you do). I wanted to attempt the same effect with Rails, so since almost the beginning we've had #rubyonrails for the novice and veteran alike. And I try my best to spread the contagious message of friendliness and helpfulness. I doubt think the channel has ever heard the dread of RTFM!
Apparently, it's working too! but she's a girl.. talks about her experience with #rubyonrails:
The people who hang out in the #rubyonrails channel are also fantastically helpful and enthusiastic, and perhaps one of the best possible advertisements for both Ruby and Rails.
I can't say how proud of the community in #rubyonrails I am. It's truly one of the biggest assets to Rails. Just like ruby-talk (and #ruby-lang) is it for Ruby itself.
P.S.: I'm pretty excited to see what but she's a girl... comes up with in her Getting Things Done application. I'm rediscovering David Allen's approach to productivity and I'd love to see what a Rails application could do for it. About the road itself, she writes:
I’m stunned that a framework which can create something as complex and professional as Basecamp can also allow a totally green newbie like me to make something cool and functional, without making me tear my hair out.
November 07, 3:47 | Comments (12)
Michael Koziarski works for the canonical enterprise corporation: A bank. So the day job is all about Hibernate, Struts, Spring, and how to integrate that kind of infrastructure with legacy COBOL applications. Here's what he has to say about Ruby on Rails:
Rails is perhaps the most productive web development environment I’ve ever used. It’s simple, elegant and understandable. I’ve had some configuration files that are bigger than Basecamp (4kLoc)
If I were building an application for myself, or to start a web based business, I’d definitely choose Rails. In terms of time to market and maintenance costs I don’t think I could seriously consider using J2EE or PHP. Similarly, if I were doing contract development for small or medium clients, I’d strongly urge them to consider rails.
Beyond the fantastic endorsement (thanks!), Michael goes on to talk about why Rails probably isn't suitable for his work at the bank. He brings up issues about finding Ruby programmers as easily as in Java and about how DBAs won't let you get away with an easy and understandable schema. While I have no intentions of convincing Michael to push Ruby on Rails at the bank1, I'll try to give my observations anyway.
The perceived problems of finding Ruby talent
The hiring approach seems to commit Hiring Mistake #1: Hiring Tools, Not People, as Johanna calls it. After the week in Vancouver, I feel even more strongly that this is true.
Within a week, the team of three PHP programmers took in test- and domain-driven development, the Model-View-Control separation, and got fairly proficient with Ruby on Rails. Before my stay, they hadn't done any Ruby or even Rails before. I was pretty impressed with their ability to grok it quickly and further convinced that good programmers can adapt to new environments much easier than most people expect.
So stop worrying too much about finding people with x years of experience in y and look for people who are adaptable and good programmers. They'll learn Ruby on Rails easily. It's likely going to take them longer getting up to speed on the specifics of your application than adapting to the environment.
The DBA distortion filter
I have no doubt that there are DBAs out there that know a great many things about what makes a database tick, but every time I discuss their role with other programmers I get the distinct impression that their primary role is as a distortion device.
As a recent example, Jim Weirich was telling at RubyConf about how he'd submit a database schema to DBA process and pray it wouldn't get mangled too badly. Usually it would. Non-sensical prefixes would be injected, additional columns that might be useful some day would get added, and the turn around time would probably be about a week.
This sounds like a similar to what Michael is talking about:
I don’t know many DBA’s who’d let you call primary key’s “id”, or let your name your tables simply, without some whacked ‘standard’.
I wonder if there are any DBAs out there that has yet jumped on the agile principles of Do The Simplest Thing Possible and You're Not Gonna Need It. It sounds like a lot of them are still caught up in Big Upfront Design.
So maybe you need to route around the damage if distortions is truly what you're getting back? So opt out of the DBA (if he functions are characterized above) instead of "perhaps the most productive web development environment".
In the end, it's all about delivering the maximum amount of value to the stake holders. Doing so is usually fairly correlated with productivity. But regardless, I'm really happy to see that there's a discussion going on.
1 My Jedi mind tricks needs at least a few more strokes of confidence before I'd tackle an uphill battle like that
November 06, 19:30 | Comments (6)
I learned my lesson: Don't try explain open source to U.S. customs and immigration officer. Developing free software is obviously a suspicious activity that needs to be examined with tough questions and a highly uncomfortable tone.
I didn't even realize that the situation was getting tense before my chit-chat with the customs officer took the following bad turn (after a somewhat failed attempt at making him understand):
Officer: So how do you make your money?
Me: I do training and consulting on how to use the software
Officer: What do you make doing that kind of work?
Me: It's pretty good
Officer: That's not what I asked you
The guy actually wanted the figure of my last engagement. I was foolishly thinking that we were having a friendly yet polite chit-chat session where they feel you out. Wrong was I.
So the guy types and types and types (I obviously have a SUSPICIOUS status in my hidden US file now) and finally sends me on to my second-round interview. If I thought that the first one was just a bit uncomfortable, then the second one got downright aggressive. Who do you work for? What the fuck is your occupation?
Maybe not fuck, but it was definitely an ordeal straightening out that I wasn't breaking any U.S. laws by contracting and developing open source software.
These two gorillas were of course (stupid) white men to which I tried my best to keep a friendly report. It was not like I was unwilling to answer their questions or tried to hide any thing.
The contrast to the rest of the security checks were startling. I had my bags to through special x-ray, had my computer and camera examined for traces of explosives or whatever, but all that was just getting the security checks done without the tense attitudes. Of course, all of these security people were either Asian or Indian.
What a horrible customer service experience: Welcome to the United States!
November 06, 1:59 | Comments (15)
The December issue of Linux-Magazin features an article called "Programmieren: Webanwendungen mit Ruby und Rails". I was interviewed for the magazine by the writer a while back, so perhaps that article also includes that?
If any of the German Railers have access to buy the magazine, I'd love to see the article scanned from it. I believe this is the first print mentioning of Ruby on Rails. A few more are in the pipeline.
November 06, 1:39 | Comments (1)
Jason has been interviewing a bunch of customers lately to find out more about how people are using Basecamp. These interviews have been made public in form of a series of case studies at the Basecamp HQ site.
I particularly like the story about Marie Thacker from the non-profit organization Donordigital in her Evercrack-inspired tribute to Basecamp:
Our first impresson was: Wow. Our second impression was: Oh my god, WOW. And now? We call it "BaseCrack."
Although flattery is always nice, it's even better to learn that Donordigital has been using Basecamp for more than six months and have been growing ever happier with it every day:
Basecamp has dramatically changed the way our firm gets the work done. It has introduced more efficiency and organization into our project process. We continue to use Basecamp today because, after using it for six months, we would be lost without it!
It's really energizing and motivating to hear about the effects that your software is having on people. Thanks for sharing, Marie!
November 06, 0:06 | Comments (8)
Until now, you've been restricted to the CVS version (called Edge Rails) if you wanted the latest and greatest, which meant giving up the goodness of gems. Those days are over.
Thanks to the help of Chad, I'm now running my own gem server serving up the beta stuff. If you're on Gem Rails, this is all you need to fetch all the beta gems:
gem update -s http://gems.rubyonrails.org
November 05, 23:26 | Comments (1)
November 04, 16:55 | Comments (0)
Vancouver in morning traffic
November 04, 5:28 | Comments (0)
On The Rails is a new and very nice weblog tracking the learning curve of one London-based Railer "...build[ing] a large-scale production-strength Web Application". The last three days have seen daily posts, so it's looking promising indeed. Today the topic is getting authentication running using the form helpers. Good stuff!
November 03, 16:45 | Comments (12)
 Jason has announced our next project following in the foot steps of Basecamp. It's called Writeboard. It has a more narrow focus than Basecamp, but potentially an even bigger reach.
We're adhering closely to our Less Software approach on this project. The first iteration, which provided a first stab at much of the core functionality, has taken just around five hours and resulted in 150 lines of model and controller code in Rails. On top of that, we have a very nice unit and functional test suite exercising all the features.
It's exciting to work on a fresh codebase using Rails 0.8 from scratch and reaffirming as a reminder of just how fast you can get started. I can't wait to finish this application and share it with the world. With the current velocity that should happen pretty soon.
November 03, 16:34 | Comments (10)
Topping seven thousand downloads, Instiki is now the most downloaded application on Rubyforge — the premier place for Ruby projects. The interesting thing is that the most recent version has an almost evenly divided split between .app, .tgz, and .zip downloads, which roughly translates to equal adoption by OS X'ers, Linux/FreeBSD'ers, and Windows people.
Even though I haven't had time to work on Instiki for quite some time, it's very warming to see these numbers climb higher and higher. I've talked to many people who've caught interest in Ruby after using Instiki. So as a trojan horse to increase Ruby adoption, it has been doing nicely as well.
So thanks to all Instiki users for the great interest! I hope that some day I'll be able to give it more attention again, but right now other projects take higher priority.
November 02, 9:26 | Comments (13)
Sean is a "professional Java coder" that has been working a lot with Ruby on Rails, lately. He's not particularly fond of the knee-jerk reactions coming out of the Java community in response to Trails (and the attempt to recreate Rails in Java):
And looking at the comments on TSS, I see the usual and expected condescending commentary that makes me ashamed to be a Java programmer. The most prevalent is the "cute, but too simple and can't possibly handle my manly enterprise needs" crowd. My experience thus far with Ruby on Rails says otherwise.
Before anyone asks or feels compelled to criticize me for obviously not understanding enterprise needs - yes, I do happen to deal with enterprise data. But I don't use it as an excuse to toss out new languages any more than I would insist that an enterprise system needs to stay on a mainframe.
I'm thrilled to have Sean on board. The Java community certainly has tons to teach Ruby on Rails. It already has in form of the inspirations that Rails have drawn from Hibernate, Struts, WebWork, Tapestry, and other great Java frameworks.
If only more of them could come to terms with the fact that J2EE isn't the last stop on the enterprise ride — the rails go on.
| 
