Jul 282006
 

I wanted a ruby version of the Java Locale object and couldn’t find one, so i created a project for it. Here’s the address:

http://rubyforge.org/projects/locale/

It is pretty minimal, but it does contain all the current ISO country and language codes as well as a simple class for accessing them. It is also in a rails compliant plugin layout so it can just be dropped into the rails vendor/plugin directory.

The unit tests are failing, but it is just a numbering issue, which I’ll fix this afternoon or next week.

Enjoy.

Jul 262006
 

The Tune-ster
Funny story. Last night I had a sangria craving and so Kenz, Eliot and I went out to buy brandy and some fruit. We noticed that our brand new sidewalks were complete. Our old sidewalk had a HUGE 2′ envraving in it that said “Brian”. Wasn’t me who put it there and I for one liked it and it got me thinking. I thought, “well I’ll just do something really small with Eliot’s initials and then bring him back in 10 years and say, look, those are your initial’s I put there right before we moved.”

On our way back from the store I decided to make it so. I went to work while Kenz and Eliot were walking around and started making my 4″x4″ engraving. All the sudden this crazy biker rides up and says, “oh please don’t do that.” For a second I thought, “you know he’s right.” BUT THEN!!! This idiot said something that just made me pissed. He said, “I’m Alderman Tunney and TOO much money went into this project.” That made me mad. Yeah, MY MONEY YOU KNOB! I pay the Chicago of Chicago so much money in taxes that I think I should own my 4″x4″ square of sidewalk. But, this isn’t the funny part… hehe It gets good.

I look up and notice a lady who has entered our property and is using our hose to fill up some water containers. That’s pretty odd. Then I think, wait a second, this lady is essentially stealing water from us. I know it’s not that big of a deal, but this Tunney moron had spotted us from a few blocks away and rode all the way up to tell us to stop putting a 4″x4″ engraving in OUR sidewalk (which you can’t even see unless you’re right on top of it), but doesn’t bother with the fact that there is some lady stealing right in front of him. Oh, Tunney, the-Tune-ster. You’re an idiot.

Jul 242006
 

Ed Yourdon

I had a great interview with Ed Yourdon last week. Ed has put together a summary of our conversation on his blog.

I’ve also put a post together to respond to the experience Ed had with his Naymz Google ad. This lives over on the Naymz blog. It covers a bit about how Google ads works in general (of course the real system is a black box to us, but we make good guesses at it).

One of the things that I did discuss with Ed was some of my fairly contenous thoughts about the Web 2.0 technology. I’ll be covering that deeper in a post this afternoon as well as my thoughts on what Web 2.0 really is and what I see for Web 3.0.

We also discussed in detail identity management and more importantly identity trust. This is one part of our conversation that Ed skipped over and I think it was mainly because it is a problem that hasn’t been solved yet by Naymz or anyone. It is a tough problem that consumes something like 15-20% of my cycles on a constant basis. One of the major reasons is because I hate SPAM. But more on that later this week I think.

For now, check out Ed’s entry and feel free to send me thoughts and comments with your take on Web 2.0.

Jul 212006
 

First download JDK 1.6 and use that to run jEdit. I also add this tweak to the command line:

Also, remove the -server option. No clue if that is gonna help at all in JDK 1.6, but things are blazing fast without it and I assume Swing likes it without.

Next, download these plugins:

  1. Buffer Tabs
  2. Project Viewer
  3. SideKick
  4. FastOpen
  5. Ruby (http://rubyjedit.org/download/)

Next, follow the ruby plugin directions to get that up and running. If you are using Java, I would assume that you can find lots of help with that out in the ether.

Also, dock the Project Viewer window on the left of the screen.

I turn on the BufferTabs by default and set them on the right.

Okay, now start binding keys. Here are mine thus far:

Plugin: Project Viewer

Command Key
Show Project Viewer Alt+1

Plugin: FastOpen

Command Key
Show Fast Open Window Ctrl+n

Built-in commands

Command Key
Close current docking area escape
Close Ctrl+F4
Find next F3
Go to line Ctrl+g
Global Options Ctrl+Alt+Shift+s
Join lines Ctrl+Shift+j

This is about all I have thus far, but it looks to be pretty good. I’ll add more as I think of new stuff.

Jul 102006
 

I read an old blog entry by Cedric Beust about agile and test driven development (TDD) and I started thinking about some of his points. I agree that tests are not the specification for an application. They are tests. Seems simple.

I think what most Agile folks are missing is that tests form an additional component of the overall application that helps describe the contract of a piece of code. Contract and specification are different. Contracts are used only by developers and help to solidify and harden the code for production. They also help reduce headaches for the next dude who comes along and either:

  1. calls into the contract
  2. or modifies it

The tests help reduce pain for this second dude when he does #2 above. It does not help when he does #1 above. This is what JavaDoc is for. Especially if said dude doesn’t have access to the source (think offshore or decentralized development or open source or architecture nazis or security clearance or whatever).

A specification is used by managers and product dudes and marketing monkeys and everyone in the company who wants a say in the final product. Specification is something that is loosely technical and mostly business. If you want to talk about technical specifications solely, well than that’s different. Those are in depth manuals of how the code, architecture and components work and to me are very RUPpy. But they are still not the tests because they define parts of the application that tests don’t like IP addresses, multicast groups, routers, deployments, infrastructure, DNS and much more.

Cedric’s second point about the speakers statement: “testable code is worthless” I think missed the mark abit. I understand what we was getting at, but his examples and discussion revolved not around untestABLE code but untestED code. There is a HUGE difference.

UntestED code is not worthless. This is simple as well. It just didn’t get tested because of timelines or bad coders or dumb managers or whatever. The ideal solution is just to write some unit tests. Something else that Agile and XP tend to dislike is this notion of going back and writing tests. “Tests should be written first!” Yeah whatever dudes. This ain’t gonna happen with deadlines and customers and press releases about some new alerting system that went out before the code is written. Just live with it and start embracing the possibility that tests written after the code is written are equal if not better than the tests written before the code. You already know the soft spots! You just have to be man/woman enough to break your own code. Most of us have an issue with this and we usually test lightly after the fact because we are scared of the possibility of breakage. Again – grow a back-bone and realize that breaking code is a good thing! You can then fix it and now you have a test for it. I personally love writing tests after the code because I LOVE finding bugs. I love writing tests that just freak code out and make it barf. Then when you fix the code and polish everything up, you KNOW – I mean you 100% KNOW that your code just rocks the house!

Okay, back on track…. UntestABLE code is not worthless either, but should probably be carefully considered and usually rewritten so it is testable. This is really where as engineers we need to focus our efforts, not on writing tests first or even on writing docs or specifications or whatever. We need to focus on ensuring that we can test code when we have time. There are ALWAYS (that’s right kids – ALWAYS as in never gonna stop being – as in for eternity there will be) cases where you have some code that just can’t be tested in an automated fashion. Most folks understand how hard it is to test javascript in the browser and even harder to test javascript that effects CSS that could end up making the page look like crap. Try testing that in an automated fashion. Just not gonna happen unless you build a new piece of software that can understand human esthetic enough to look at a GUI and determine that it looks like dung. Yeah – good luck with that!

So, I think everyone who codes should go write tests and docuementation and the best code that they can under the conditions of the job. Even if it is two unit tests for 50,000 lines of code and four javadoc’d methods, still it is a start. Good luck and may the code be with you.