Just a quick note to say that The Rubyist is a fantastic read for anyone interested in modern Ruby development. The magazine format lends itself to a mode and tone that blogs couldn’t reproduce — obviously the articles can’t cover what is happening right now, so instead we’re treated to more general software topics and ideas.
I’d love to have a hard copy, but it appears that is only an option in North America right now.
Anyway, highly recommended!
Subversion ignore commands drive me up the wall. Git’s ignore is much easier to use, and consistent.
Here is the process I followed to add svn:ignore to a newly added directory that hadn’t yet been committed to the SVN repo. The magic here is the “-N” flag on the add command, since that stops the recursive add (which would add the git directories), and you can then set svn:ignore afterwards.
svn add active_scaffold_list_filters/ -N
svn ps svn:ignore ".git" active_scaffold_list_filters/
svn add active_scaffold_list_filters/*
svn ci
Simon Brown has some excellent commentary on the idea of “Technical Project Managers”:
In essence, teams get in a Technical Project Manager because they think people in this role can successfully undertake the project management *and* architecture roles on the project. Unfortunately, my experience suggests that this isn’t always the most successful approach.
I’ve seen this several times over the years — one can do the Project Management, or one can do Architecture, but almost without fail it seems impossible to do both at the same time on a reasonably sized project. One role will be more emphasised than the other, at the detriment of the background role.
Both these roles are of such importance that crossing concerns is asking for trouble. At a pinch, I would recommend using part time resources for each role, rather than one resource trying to cover both roles.
Yesterday I hosted a small team of programmers in our first Crossroads sprint — a day of working through issues the dedicated team at the Crossroads charity in Hong Kong have found in using some of their internal systems. The idea being that as Rails experts, we could donate some of our time each month to helping our friends in Hong Kong out.
Brad, Adam, Nick and myself (with Matt and Steve online at Crossroads to answer our questions) spent most of the day getting setup and working on some small issues, that gave us a good introduction to the system and the coding approach over at Crossroads, and coordinating with the ThoughtWorks product Mingle, we were able to resolve several issues.
All in all, a good start to our relationship with the Crossroads team. It felt fulfilling to be donating our time to such a worthy cause.
Last month, I gave a talk at the Ruby on Rails Oceania (RORO) Sydney meeting about a charity that a good friend of mine is involved in, Crossroads. They’re based in Hong Kong, and began moving their systems to Rails earlier this year.
So I’ve acted as a facilitator in trying to get a few local Rails developers together to do some charitable work for Crossroads. Last night we had our first meeting, and all systems are GO! We’ve decided provisionally to meet perhaps one day a month to work on some Crossroads code. As Matt from Crossroads says, the help we can give is very highly leveraged in that every hour we volunteer is actually worth many times that, since we will be helping create more efficient systems for delivering tens of thousands of tonnes of charitable goods around the world each year.
This is the beginning, and I hope to report back in the future with news of some very good and useful work done for our friends in Hong Kong.
Great quote from Steve Yegge (in a much longer transcript on javascript):
JSON and XML are muscling in on each others’ space, and there are bristles, OK, and it’s so silly! It’s silly. The whole thing, right? I mean, XML is better if you have more text and fewer tags. And JSON is better if you have more tags and less text. Argh! I mean, come on, it’s that easy. But you know, there’s a big debate about it.
I’ve just made my first contribution on GitHub:
http://github.com/lightningdb/activescaffold/
Basically, I forked Active Scaffold, patched it to work with Rails 2.1, and committed back to GitHub, then sent out “pull” requests to others with related forks. Now I’ve been notified that my patch has been pulled into other forks, excellent!
Getting my head around Git hasn’t been a priority, but even with my scant knowledge, this was relatively painless. And colloborating on GitHub (even from my early impressions) just seems so natural and easy, even brilliant.
For a trip down memory lane, Jeff Atwood’s latest blog post about growing up with BASIC is a must read.
I grew up with GW-BASIC in the mid-80s. I loved programming, and I actually made some reasonably complex software. I’m convinced the accounting software I created was what landed me a scholarship to a prestigious private school here in Sydney. Other software: a graphics program, many, many games (culminating in a loderunner type game with *a level designer*), a text editor and many others. I even built an interpreted language *IN BASIC* (these days the cool kids would call it a DSL, and yes, I was crazy and young).
There’s an interesting article on running Rails on Glassfish and why this could make sense for you. And it’s an easy sell to me: one of the things that bother me most about Rails is resource usage, so database connection pooling is an instant winner in my book. But I’d love to know more about the performance characteristics of such a setup.
Ideally I’d have a few hours on a weekend to play around with Glassfish and Rails, but the coursework for my Masters is starting to bite. Maybe in a couple of months…
I wouldn’t normally participate in this sort of thing, but …
64 ls
62 svn
41 cd
40 rake
39 rdebug
24 ss
18 exit
17 rm
17 ./script/server
15 cap
I really should alias cd & ls together huh