I really like Firefox. It's been a real solid browser with lots of development support for the things we do at OpenLogic. Firebug in particular has been awesome and Selenium is nice too. Since upgrading to Firefox 2.x, my linux machine has been dog slow. For a long time I couldn't figure out what the problem was. I typically run Eclipse 3.2.x, NetBeans 6.x, a shell with multiple tabs, a browser with multiple tabs, MySQL, a web server, and sometimes a DB browser tool like DBVisualizer. Now, I know that NetBeans can be a memory problem, but I have to run it for Ruby coding, and the slow down stuff happens even when I'm not running NetBeans. I tracked down one problem which was the Xfce terminal 0.9.x that has documented memory leaks. This was causing the box to grind way more than it should, so I switched shells and things improved. But still, with all this stuff open, as the day progressed, response times got slower and slower. Eventually, everything would grind to a halt and my cursor would spin until something released enough cpu cycles for me to keep working in whatever program I was in. Then one day, I had a little conversation with a friend at work and he mentioned that Firefox 2.x seems to have a problem because he's noticing the same stuff that I am. Now, this is important because my friend is super knowledgeable about Linux and is able to tweak the kernel so much he gets super performance out of lesser hardware. So, I stopped running Firefox and switched to Opera and all has been great. I have not had the slow downs like before and Opera displays pages much faster than Firefox. It is unfortunate that Opera does not render every little thing correctly like Firefox, and has some quirks with JavaSrcript, but I really like the browser and most importantly I like the fact that it doesn't impede my development process.

So I decided to go my own way since I don't really like installing via a package manager. IMO, package managers are good for installing shared libraries and the like on Linux, but major apps like Subversion and PostgreSQL and stuff like that I like to install where I want them so I can maintain them easier and have them all in one place. So I understand that I made things harder for myself from the get go since I didn't want to use the "opinionated" way of doing things, and still I think it's worthwhile saying that I find it ironic that the technology intended to make one's web development life so easy and fun is not easy and fun to install on Linux. This is the common statement I found on the web and in books about how to install Ruby and Rails and MySQL: "On Windows, Instant Rails provides a self-contained Rails environment… On the Mac, Locomotive is a self-contained Rails environment… If you are running Linux, you know how to suck bits off the Web. Start with the Rails Wiki, and find instructions for your flavor of Linux." Not a good sign. It took me forever to find releases of the projects out on the web since I was looking for binaries and they just don't exist. This *really* bothered me. I love Linux for doing work, but the compile-from-source thing just drives me bananas. There are always problems and it takes forever to compile and make and make install and understand all the options on each of the commands and finally after 3 days of research you can finally get the stupid project installed. So I had to compile Ruby from source. Then I had to go find RubyGems and compile it from source. At this point I was ready to pick up my computer and throw it off the 4th story of the building where I work. So I succumbed to the "opinionated" recommendation to use RubyGems to install Rails. That worked thankfully. And now all I had to do was install MySQL. So off I went to find the source since I quickly discovered that MySQL doesn't like to make the source easily accessible anymore so I had to really search around for it. Finally, I found it at: ftp://ftp/mysql.com/pub/mysql/src/. Once again, back into the weeds trying to get MySQL to compile and install. So here are the steps I did to get this stuff installed - which took me approximately 4-5 hours. 1. Ran the adept package manager to install libraries such as irb, rdoc, etc. In a shell: 2. Found and untarred the Ruby 1.8.5 source distro. (http://rubyforge.org/frs/?group_id=426) 3. Renamed the directory to ruby-setup and created a new ruby-1.8.5 directory. 4. Cd into the ruby-setup dir. 5. Ran ./configure –prefix /path/to/ruby-1.8.5 dir. ran make and make install. 6. Added RUBY_HOME to my path. 7. Found and untarred the RubyGems 0.9.4 source distro. 8. Renamed the directory to rubygems-setup. 9. Cd into the rubygems-setup dir. 10. Ran sudo /path/to/rubybin/ruby setup.rb. (I just discovered there is a better way to do this. http://rubygems.org/read/chapter/3) 11. Ran sudo /path/to/rubybin/gem install rails –include-dependencies. 12. Added RUBYOPT=rubygems to my profile. (This is necessary to have ruby run apps with rubygems loaded automagically) 13. Found and untarred the MySQL 5.0.42 source distro. (ftp://ftp/mysql.com/pub/mysql/src/) 14. Renamed the directory to mysql-setup and created a new mysql-5.0.42 directory. 15. Cd into the mysql-setup dir. There is a very helpful file called INSTALL-SOURCE that outlines all the necessary steps - including a nice section on the configure options. 16. Did all the MySQL steps - about 10 in all. Finally everything was installed - this took me the entire morning. After coming back from lunch, I actually started a sample app using the book Rails for Java Developers. Amazingly, there was a mistake in the instructions and when I got to the part about running the stubbed out tests, I got a bunch of failures which the book did not mention. If you get some errors running rake the first time after creating an app in Rails, check that the .yml file has the correct named variables for the test to use. The test referred to :first, but the .yml file had one: as the variable. Sort of close, but not close enough. So could someone please package a self-contained Ruby on Rails environment of binaries for Linux like the Mac and Windows versions? I would buy you a case of barleypop. '8~)

First, a little background for non-users of open source: Because users have access to the source code (for most projects), when users encounter problems, bugs, or just unexpected behavior, they can inspect the source code to see what's going on under the covers. This visibility is extremely useful for developers to learn new techniques and concepts from other developers, but it also helps to ensure that the code is as good as it can be. When users encounter bugs they are able to modify the source code and fix the problem. Once the fix or enhancement works, they can then submit that back to the project maintainers, and once the new code is incorporated into the project's code base, the code base is stronger for the change. I have officially made my first contribution to an open source project: Groovy. I encountered a bug and after looking at the JIRA issues for Groovy, I decided to fix the code myself since it didn't look like they were going to address the issue anytime soon. As I was looking at the issues, I noticed a request by a user that would affect the code I was going to work on, so I thought I'd address that as well. So, to make a long story short, I fixed the code, made the enhancement, and submitted my changes. After review, the enhancement was incorporated, and the bug I fixed had already gotten done by one of the main Groovy contributors so that portion of my code was not incorporated. Ironic, no? Nevertheless, I contributed, and I'm very happy about the whole process. It was all done via the Internet, looking up the issues in JIRA, submitting the code changes, adding comments and notes about the code, etc. Then I was notified via email that the issue had been closed and the code incorporated into the code base. The technology made the contribution process easy, and rendered my physical location unimportant. I could have been in Tokyo or Kathmandu. It really shows how a diverse community of people all over the world can come together to work on a common goal - useable tools for software development.

I like to see the similarities in things. I find it interesting to find connections and look at things from that point of view. It is certainly not a unique habit, but I do find that many people, (and particularly engineers) do not think that way. Things are specific and even small differences mean that 2 related objects or concepts are still completely different. (Don't misunderstand, I'm an engineer, so I have this view of things as well.) So when I spoke at a career day at a local high school and highlighted the fact that my current job is exactly the same job that I had when I was building sets for TV and Film, it's a comparison that most people shake their heads and look at me like I'm nuts. But really, in my experience, it's true. These are the things that a set builder does: Works alone or in pairs on tasks that are given to him/her/them and has a certain amount of time to complete the task. The time is determined by several factors: difficulty of the task, the remaining time in the schedule until the set is going to be used in the shoot, and the experience of the workers. Specifics of the task, such as construction techniques, tools used, what to build first, etc. are left up to the workers to determine amongst themselves. Workers are encouraged to collaborate and ask for help as needed to figure out quirky or unusual parts of the task. The environment is most often open, creative, flexible, and workers have to be well-motivated and able to work without a lot of supervision. It is a male-dominated environment in the sense that mostly men work as builders but the overall environment of a film crew is usually a well-mixed environment of people (gender, race, sexual orientation, age, etc.). Now, let me describe what a software developer does: Works alone or in pairs on tasks that are given to him/her/them and has a certain amount of time to complete the task. The time is determined by several factors: difficulty of the task, the remaining time in the schedule until the iteration/release is complete, and the experience of the workers. Specifics of the task, such as algorithms used, what classes to write first, etc. are left up to the workers to determine amongst themselves. Workers are encouraged to collaborate and ask for help as needed to figure out quirky or unusual parts of the task. The environment is most often open, creative, flexible, and workers have to be well-motivated and able to work without a lot of supervision. It is a male-dominated environment in the sense that mostly men work as developers but the overall environment of a software development company is usually a well-mixed environment of people (gender, race, sexual orientation, age, etc.). As you can see there are some very specific things that are different, such as that developers work with computers and builders with power tools, but the thought process and daily work is very much the same. I had not completely realized it before the career day and talking with my friend who asked me to speak that the two jobs were so similar. Being a set builder was one of the best jobs I have ever had, and I stopped doing it because I decided that physically I wouldn't be able to sustain myself over 35-40 years of work. So, I transitioned into other jobs, and finally landed in software where I am now the happiest I have ever been at a job. So, you may still think I'm nuts, but to me, my job combines everything I loved about set construction without the worry of physical injury on a daily basis. And that's a good thing.

What is it about technical support that support personnel think that if they simply provide an answer, even if it's wrong, they have done their job? I find it really odd and a sad comment on the state of our society that this passes for customer service. First off, a caveat. Our company blog site is managed by the marketing department and they act as the in-house support liason to those of us who are blogging. The marketing people then route our support questions to technical support from the company that designed our website because they did the WordPress install for us. (WordPress is the software we use to host the blogs.) Our in-house marketing people are really helpful and responsive, and I know they are only telling us what the tech guys are telling them. So, this blog in no way includes the in-house support staff in my general comments about technical support. So, here's the scenario. For my very first blog, I wanted to write about Groovy and include a code snippet. Well, the editor page for WordPress mangled the formatting. So, I called tech support to figure out the problem. Now as I mentioned, the in-house support has been great (Thank you Greg!), but unfortunately still hasn't been able to solve the problem in a satisfactory way. The techs said that I can't use the <pre> tag. In my opinion this is a bizarre answer to the problem. It's like the old joke where a man goes to the doctor and says, "It hurts when I lift my arm like this." And the doctor responds, "Then don't do that." Considering that a blog is just an html page, and the <pre> tag is a perfectly valid tag, why can't I use it? It seems to me the problem is with the WordPress blog editor, especially because this is not the only problem with the editor. The editor barely works on Linux and Mac, both of which I use, and many of the developers in our company use. The editor page itself doesn't display correctly. It doubles up the Post text area. Fortunately, the functionality still works basically, so what I write in either Post box does get published, but it's rather annoying that the page doesn't operate as it should. Additionally, most of the tools such as inserting a link or indenting text, etc. don't work and the html formatting is bizarre and reformats things in unexpected ways. It reminds me a lot of MicroSoft Word. And that's never a good thing. So, how did we solve the problem? First, our in-house support made a jpg of the code snippet and inserted that in the blog. That's a great short-term solution, but is not really a workable long-term plan. Second, I went out and bought a blog editor. I know, I know, I never thought I'd say something like "I bought a blog editor", but for 18 bucks I got this program called ecto. (In fact, I'm using it to write this blog right now.) It's great. It works. So, I fixed the code snippet and used a <pre> tag even. And this makes the WordPress editor smell even more, since, the published post works just fine with the <pre> tag. So the WordPress editor is clearly the culprit. Which gets me back to technical support. The tech gave me the wrong answer, didn't own up to the fact that the WordPress editor is lame, and I'm sure he clearly felt his job had been done, even done well. It's no wonder that most people hate technical support. I work in a software company as a developer, and so I at least know enough to know when the techs are trying to pull a fast one, and it still makes me angry. It's really just sad. So, to all of you non-technical people out in the world, you are *not* alone. Tony

Hi all, I'm new to the blogosphere, although not a new blogger. I used to write blogs way back when they were called op-ed back in my salad days. So, I may be a little rusty, but here goes.

I'm so excited and I just can't hide it, because Groovy has really added so much to what we do here at OpenLogic. It is such a handy utility that I don't understand how we lived without it. For anyone who doesn't know what Groovy is, I recommend checking it out. It is my first consistent experience with a scripting language, and admittedly, I use it more in a Java-like way rather than in a purely scripty way, but the conventions and convenience it provides have quickly moved from cool to indespensible. (The File io additions in the GDK are enough to cause me to go out and proselytise like the "new" NHL should be doing.) And that's one of the things that I really like about Groovy, the fact that I can use it just like Java. It provides a great mechanism for learning because as I get more comfortable with the syntax and shortcuts, I get more groovy in how I think about the code and what it's going to do.

So what do we do with Groovy? Lots, but mostly xml parsing and construction, file io - reading and writing, regex, and list/array object manipulation. And all of these things are built into the language and just work! I know at first blush, these things don&#39;t sound so incredible, but let me give you an example, I wanted to read each line of a file and compare it against a regex. Instead of stream buffers, pattern matchers, try catch blocks and all that garbage, this is what I wrote:

List list = new File(resourceBundle).readLines() list.each { line ->     if( line =~ /^(\#\n\s\r)/ || line.length() < 1 )    {       code …    }}

As you can see, it's faster, easier, cleaner, and still understandable to other developers. Plus, now that I know a little more, there are ways to condense what I wrote even more and it still would be readable.

Additionally, it makes actual scripting so much easier because you are writing in familiar old Java but you can run groovy scripts on the commad line. And don't get me started about the Ant integration. Essentially, you can write Ant code in Java. There is a project called Gant that's supposed to do increase Groovy-Ant integration, but it's so simple in Groovy as it is, I don't know how Gant could improve things.

So, by now I'm sure you're reacting with skepticism, expecting Groovy to be just like a meal at most Italian restaurants in Denver. It starts off great when you sit down and the menu sounds awesome and then the food comes, and you discover that the chef was trained in the Catskills slinging cheap hash to cheaper old folks. So what's wrong with Groovy? Here are the 2 big things we've discovered:

1. Memory Issue: Groovy caches methods in memory to speed up use at runtime, but there's a bug in that process so that the memory is not released. This becomes a problem quickly if you load a lot of classes on a continuing basis, which our software does. We have found a workaround, but this needs to be fixed before Groovy can really move into prime-time wide adoption in production code.

2. Error handling: While much improved in jsr06 - the error stack traces leave a great deal to be desired. There's too much of the actual Groovy code in the traces to sort through and find where in your code the problem lies. Fortunately, line numbering in jsr06 is much more accurate so that helps. The biggest thing I would love to see is that all the Groovy invoke_method and reflection object stuff would get filtered out, leaving just the relevant information. Also, the stated error types are often not related to what the actual problem is. For example, if a variable has not been initialized in scope, Groovy throws an IncompatibleClassChangeError which doesn't help you find the variable. I'm sure that under the covers to Groovy's internal logic, the fact a variable is not in scope is an IncompatibleClassChangeError, but it's pretty cryptic if you ask me.

Really though, the boys over at Groovy have done a bang up job so far, and based on the level of improvements that happen with each release, I expect Groovy to take over the world in about a month or two.

And with that, ciao bella!
Tony