A friend of mine wrote up a list of the tools he uses on a regular basis. Sometimes it's good to see what others are using to get ideas, confirmation, etc. So, here's my list.
I currently work on two machines. I have an original Mac Pro 2.66GHz Quad Xeon running OS X Leopard for my workstation with a 30" and a 23" display. This provides a lot of real estate for working. I only got the 30" after my wife put me in front of it at the Apple store and asked me how I'd use it. Up until then I thought 30" was too big. Then I got the 23" to go with it.
My second machine is a new 15" Mac Book Pro i7 with the hi-res anti-glare screen and 8GB of RAM running Snow Leopard. I went with the regular 500GB drive rather than the solid state drive. The price delta for the solid state was too much for me to justify. I really love the greater resolution of the new screen and the anti-glare ROCKS! I wish it was standard.
This isn't documented in the Javadoc. (There is not javadoc on this method.) It seems to return the running version of Groovy when called:
Helpful if you really need to know.
Looking at the new iMacs the 27" quad-core looks like it would make a superb pairing station for programming. I've been waiting to see what the update looked like before looking at end of year purchases. Here's how I see it:
I was recently reading Martin Fowler's Refactoring. While I was reading Introduce Local Extension (p. 164) all I could think of was how simple it is to implement in Ruby.
As Fowler says in the motivation section writers of classes and libraries are not omniscient. Inevitably some class that you're using will be missing some feature you want. Using Introduce Local Extension you can add that additional functionality when you need it.
In a statically typed language, like Java, this refactoring would involve creating either a wrapping class or a descendent of the original class. In Ruby we will accomplish the same thing using a mixin.
There are a decent number of books out there on Ruby. In my mind I consider Chapter 11 of The Ruby Way, 2nd Edition the most important chapter you can read. Here's why.
Mastery in Ruby involves moving past regular programming and embracing the dynamic features of the language. The dynamic nature of Ruby goes far beyond dynamic typing. Frequently programmers coming to Ruby from languages like Java, C++/C#, PHP, VB.Net, and other statically and dynamically typed languages think that dynamic typing is the extent of what is dynamic about Ruby. Chapter 11 of The Ruby Way will greatly disabuse them of this notion and put them on the pathway to Ruby mastery.
When running Ruby on Rails in a war using the GoldSpike servlets and context-param jruby.standalone is set to true you will need to use the jruby-complete jar file. Rails requires Gems in order to boot strap. I found that using the jruby jar file caused Rails to fail in initializer.rb when it tried to require 'logger' which is included in the ActiveSupport gem.
Also be sure to copy your required gems into WEB-INF/gems.
[EDIT: Better yet use ruby gem install --install-dir WEB-INF/gems. ]
Today is the first day we have our client's complete staff using Quadran. It's a good feeling. This is a day years in the making. We had our first meeting about this project in the fourth quarter of 2004. That's a long time ago. We started the actual project in July of 2006. Today we have everyone in the business running on Quadran, and using their old system in parallel. There are issues, but nothing fundamental, no burning houses, or staff jumping off the ship. Overall it has been a calm deliberate test.
We have created more automated test cases for this project that any other project I have ever worked on. In the early going I opted for Struts 2, POJO service beans, and JPA, because they were testable. I think this has paid off pretty well, because it's quiet here. I'm not hearing screaming and gnashing of teeth. We'll see what the rest of the day brings.
Create a list of the hardest things to accomplish in software development and I'm sure near, if not at the top of the list, will be replacing an existing system. Especially a system that runs the lion's share of a business' operations. Especially when you can't look at the source of the system you're replacing.
For the past year I've been working on my Quadran project. Quadran is a drop in replacement for a system my client has been using for about five years. Completing Quadran has been just about the hardest things I've ever done. It has felt like an IT death march.
We're in the final push to getting our first release of Quadran out the door. We' implemented a lot of functionality over the past two weeks. The data model has grown and morphed as time has gone on. We look to have a running system up within two weeks.
As I mentioned in another post we're starting to use Scrum to manage our software projects. The transition with Quadran has been interesting. Quadran is a fork lift replacement of an existing system that runs our client's complete operation. About the only thing that isn't in Quadran is invoicing and receivables. This makes the conversion to Scrum a little hard, because we're so close to finishing the first release. And we can't deploy the new system until it does everything else the old system does. (The old system took five man years to develop in the bad old days of EJB 1.1.)
At Vita Rara we're beginning to use Scrum to manage our software projects. Our first pure Scrum project is going to be a SaaS Scrum tool. Stay tuned for more on that as we make progress.
We're currently starting to use Scrum to manage our Quadran project. We have identified a client to act as our model customer, and have explained the Scrum process to them and they have bought in.