Sun 29 March, 2009

RailsConf 2009 is drawing ever closer and it’s going to be one hell of a show worthy of Vegas glitz and glamour. To let you all get more familiar with who’s going to be talking and what they’ll be talking about, Chad Fowler has been doing a series of presenter interviews:
- Michael Bleigh from Present.ly on Twitter apps with Rails
- Obie Fernandez from Hashrocket on Rails entrepreneurs
- Charlie Nutter and Evan Phoenix on alternative Ruby implementations
In addition, Nicke Plante is talking about his Rumble Panel and Marty Andrews about his automated code quality check talk.
We’ve also announced some of the keynoters. In addition to yours truly, we’ll have Bob Martin of ObjectMentor, Chris Wanstrath of Github, and Timothy Ferris of 4-hour work week and lifestyle designs rock it out. We’re also going to have a Rails Core panel of some sort.
It’s going to be a great time. You can follow along with even more announcements from the conference on Twitter by subscribing to @railsconf. See you in Vegas? Of course I will!
add to del.icio.us. look up in del.icio.us.
add to furlSat 28 March, 2009

A Mac Mini, actually. For occasional development work.
Many things are quite nice and well done. Others, annoying. It looks very nice, but I was amazed that my choice of simple desktop background colors was limited to one of 8 shades of melancholy. There’s a difference between subdued and drab, and while I would really want a gradient background (as I have on my Kubuntu laptop), even a solid shade of a vibrant rust or golden green would be nice.
Likewise for “spaces”, the Mac version of multiple desktops. KDE3 lets me give each a unique color—makes it easy for me to place myself. Puzzling that the Mac, which seems to otherwise excel in UI goodness, falls down here. And one more “why isn’t a Mac more like <foo>” complaint: To resize a window you have to use the One True Corner. You can’t (as far as I can see) simply grab any edge or corner and adjust freely. Makes for more work.
When I switched from XP to Kubuntu a few years ago, I had a similar experience. I liked XP as a general OS, and there were a number of apps that did not have suitable counterparts in Linuxistan, but one BSOD too many made me decide that, being a developer, I needed the stability more than the pleasantries. I had been using Linux via VMware for a while so it wasn’t a sudden radical leap, but making it my daily OS (with KDE3 as the desktop manager) was jarring.
I first tried the stock Ubuntu install, which uses Gnome, but I was not able to tweak the UI as I liked. I could not, for example, give each desktop a unique background, and the menu system seemed hard to customize. KDE was more to my liking, but it, too, had a fair share of quirks.
I think KDE3 gives you Dolphin as the default file manger. Dolphin seemed heavy on white space and icons and weak on more useful information, and I ended up using Konqueror instead since it seemed to have more of the better features of the XP file manager. While spending time getting things “just so” I was thinking about the little things that worked or didn’t. Changing your OS + desktop manager seemed to entail swapping annoyances more than a clear move to better or worse. What was annoying depended on what you were used to. I figured someone moving from KDE to XP would be finding the same number of nits to pick.
Over time I just got used to how things worked. I also found things that were so much better on KDE. For example, to move a window, you hold Alt and click anywhere, and drag. Very nice. I sometimes do this on my Vista box with amusing effects. (I tried this on my Mac; no luck.)
I need now to get acquainted with various Mac tools and keyboard shortcuts. I imagine that over time I’ll stop gnashing my teeth over funky Mac UI decisions, get used to the Mac Way, and be enjoying the good parts while ignoring the bad.
I have Synergy running, so I can use the Kubuntu laptop as my base and switch over to the Mac or the Vista boxen as needed. Very handy. Now I just need to install all those extra dev things …
add to del.icio.us. look up in del.icio.us.
add to furl
March 21, 2009 – March 27, 2009
It’s been a quiet week for Rails on the surface: just half a dozen commits over the course of the week. Behind the scenes, though, the work is going on to merge initial Rails 3.0 work into the master branch of the git repository. We’ll have more news on that as it happens.
Fixes
Meanwhile, a few small issues in the 2.3 release have been cleared up in edge:
- Tests with multiple POST requests in the same test block now properly handle parameters. commit
render :filewith absolute paths now works on Windows systems. commit- Template extension parsing is now more robust (if you’ve been having problems with files like show.erb.orig, this one is for you). commit
Just a reminder, if you’re having any issues with Rails 2.3, we’d love to know about them – and we’d love it even more if you’d supply a failing test or a patch. Check out the details in the Contributing to Rails guide.
add to del.icio.us. look up in del.icio.us.
add to furlThu 26 March, 2009

add to del.icio.us. look up in del.icio.us.
add to furlWed 25 March, 2009

我们的跨项目组持续集成方案要用到Hg,我们专门介绍了Hg。之后,我们搜集到了一大堆问题。下面就是一个:
* Hg解决不了我们代码的耦合
没错,Hg解决不了,事实上,没有工具可以解决。因为版本管理和代码耦合是两件独立的事。
但是,为什么这样的问题会提出来呢?
Hg只是我们实施用到的一个工具,这个方案对客户的开发人员而言,是一套全新的工作方式,正是这套工作方式的引入,他们原本一切安稳的工作方式受到了挑战,那些原本不是问题的问题也就暴露出来。
你或许已经想到了,引入我们的方案,对他们而言,绝不是仅仅把工具安上这么简单,甚至不仅仅是工作方式的改变,也许更大的调整在等待着他们。
无独有偶,这不是我们遇到第一次类似的情况。
和我们讨论TDD的时侯,有人和我们说,我承认TDD很好,但是,我们的代码做不了TDD,因为我们的代码耦合太大。
继续讨论下去,就会发现,他们对现状有很多不满,而根源往往就是这种耦合。既然大家都认为这是个问题,那就应该解决它。面对这种耦合,他们通常表现出的是一种无能为力,认为这是历史遗留问题,无法解决。我们所经历过的实际情况是,还没有代码真正糟糕到让人无能为力的地步,只是他们缺少有效的工作方法而已。经过一些历练的我们,面对遗留代码时,会多几份从容。
敏捷,给了我们一个新的思考角度,由此,我们得以发现很多的问题。这不是敏捷的问题,而是既有工作方式存在的问题,只不过,敏捷让它暴露出来而已。借由敏捷的引入,努力消除这些问题,让软件开发向着良性的方向前进。
敏捷,只是一个开始,随着敏捷的深入,我们可以发现更多原本可以做得更好的地方。
add to del.icio.us. look up in del.icio.us.
add to furl
add to del.icio.us. look up in del.icio.us.
add to furl
add to del.icio.us. look up in del.icio.us.
add to furl
add to del.icio.us. look up in del.icio.us.
add to furl
add to del.icio.us. look up in del.icio.us.
add to furl
add to del.icio.us. look up in del.icio.us.
add to furl
add to del.icio.us. look up in del.icio.us.
add to furl
add to del.icio.us. look up in del.icio.us.
add to furl
add to del.icio.us. look up in del.icio.us.
add to furl
add to del.icio.us. look up in del.icio.us.
add to furlTue 24 March, 2009

add to del.icio.us. look up in del.icio.us.
add to furlMon 23 March, 2009

add to del.icio.us. look up in del.icio.us.
add to furl
add to del.icio.us. look up in del.icio.us.
add to furlSat 21 March, 2009

March 14, 2009 – March 20, 2009
The big news in Rails this week, of course, was the release of Rails 2.3. But that certainly doesn’t mean the Rails edge story is over! To the contrary, we’re embarking on one of the more ambitious and exciting Rails projects of all: the creation of Rails 3.0. Read on to see where things stand.
Final 2.3 Changes
A few things went in to Rails 2.3 in the days leading up to release. These include:
- DDL transactions for SQLite databases commit
- Compatibility between
render :fileandPathnamecommit - ActionController class naming conventions for Metal commit
Rails 2.3.2.1
Shortly after the release of Rails 2.3, which was version 2.3.2, it became necessary to make a Rails 2.3.2.1 tag. This is because the tagged 2.3.2 version in the Rails repository is actually missing an important fix (the installable gem version of Rails has the fix). The net result is that rake rails:freeze:edge RELEASE=2.3.2 would freeze a bad version of Rails into your application.
To fix this, the Rails team has re-tagged the master tree at a safer spot, after the critical fix. This new tag is for release 2.3.2.1. So if you’re freezing Rails 2.3 into your applications (as opposed to running it from gems) be sure to use rake rails:freeze:edge RELEASE=2.3.2.1. That .1 makes all the difference.
The Road to Rails 3.0
Now that 2.3 is out, what’s next? Rails 3.0, which has been a distant speck on the horizon for a while, is rapidly getting closer. The Rails core team is discussing exactly how to proceed, but the bottom line is that you are shortly going to see a lot of changes on edge Rails, as work that’s been going on in various forks gets merged back into the master branch. You’ll want to be cautious about using edge on existing applications. In particular, changes to the Rails internals may result in many plugins needing to be rewritten. Rails edge will continue to be the cutting-edge solution, but you’ll need to keep up with the changes and be prepared to work with them if you choose to run on edge.
But this doesn’t mean that Rails 2 is frozen in time either. There’s a new 2-3-stable branch in the Rails repository which will host any maintenance releases to the current release version. There will continue to be some work on making sure the 2.x releases of Rails work well, though the center of gravity of Rails framework development will shift quickly to Rails 3.0.
So stay tuned. We’ll continue to keep you posted with Rails 3.0 developments as they happen: the process will continue, as always, to be transparent and to welcome ideas and feedback.
add to del.icio.us. look up in del.icio.us.
add to furl