September 16, 2006

Rails, Grails and Relay

I’ve reworked my build environment on the software that I abandoned last year, for a renewed life in post-Katrina New Orleans.

How do I feel? I feel pleased that I’ve hived off dozens of hideous Ant scripts for a single Groovy script that builds everything. Returning to the code base after a ten month hiatus, it struck me as fully OCD compliant, an attempt to create a build environment in Ant, that built multiple projects, with an awareness of their dependencies, without the benefit of Turing machine.

How I hate Ant. I hate it. It is horrible nonsense. It is wrong. I can’t believe that an industry attempts to develop software with a build environment that lacks the benefit of a Turing machine. You cannot loop. You cannot recurse. Why must I install extensions in order to add my own logic to my own build?

Software should not make a programmer seethe.

Now I like Groovy. The toy language. The language that was not invented here. It’s strangely European. An Anglo-Franco-Deutsche concoction. The EU’s take on an American VM and a Japanese syntax.

The last I looked at it, the hope was that perhaps, it was similar enough to Java, that Javans would adopt it do the things that they’d done with half-assed XML configuration abominations like Ant, Maven, or Jelly.

Why not adopt Ruby? Java is a keeper. Java is a keeper because of ANTLR and Saxon. (I’d like to play with Modern C++, because there lie concepts that are not available in Java or Ruby.) Those are two software packages that I find delightful.

Why adopt Ruby? They have an nice mailing list. It is very friendly and helpful. Like the Perl groups nice people. Javans have no place to congregate as central as Ruby. Javans tend to be annoying pedants and they bicker about stupid, boring things. A lot of dogma for the sake of dogma, so that they can sound as smart as C++ programmers.

Can’t stand to have someone talk about the Singleton pattern for yet another thread. Can’t get a straight answer on all the conceptual problems raised by checked exceptions. Then there is a lot of Socratic-retentive half-answers to questions. Familiar tone from comp.lang.c++, but there I suspect that someone really is telling you about a convention to follow so that your code will port to the most obscure hardware platforms, not simply because it’s more object oriented or some such.

Maybe if I program in Groovy I’ll finally get a change to practice my high-school German. More importantly, there is a community growing up around Grails that has a whip-it-up-a-tude approach to programming. If something is too slow in Groovy, I can implement it in Java, using Eclipse, which I also enjoy. I’ll gladly use a strongly typed language, for all the neat tricks that you get in the IDE. Tricks I miss when I don’t have them handy. But, you’ll excuse me if I pass Object instances around because too much typing kills reuse, and adds too much complexity. They only reason I want a Duck is because I want to type the letter “q” and have Eclipse make it quack. Reminding me what goes into a quack, and what comes out.

Why not JRuby? It’s not OCD compliant. The difference in naming conventions drives me bonkers.

Where have I landed? I’m going to take a peek at Groovy and Grails. Then I’m going to look for more ways to put Groovy in Saxon. It seems like a better way to mesh with XML. Maybe I get Groovy happy, creating Groovy options for libraries I create. Maybe Grails is part of every solution, giving me scaffolding to CRUD my objects while I work on creating more elaborate interfaces.

Relay still comes into play, because I’ve been wanting this XML dependency engine for a long, long time. What I’m prepared to consider, is that Groovy might make an ideal controller, an easier to type expression of program logic or flow, easier than the purist notion that XSLT is the one language to rule them all, pipelines are expressed as XML documents, XSLT creates those pipelines. XSLT is an XML document.

Where does this stream of conciousness lead me? Grails for the sake of the Groovy community. They seem like decent people with some sense. That they are not hamstrung by some adherence to object this or that, it seems like they are likely to be a helpful lot. Grails is nice, because it’s an application. Maybe Relay can be an application, one that is not too terribly parallel to a Ruby project.

Rails is a no go because I have a high resistance to hyperbole, and this burp of investement in browser based software is nothing less than what the W3C, Microsoft and the Mozilla project would have expected, once people realized how effective the browser is as a client. Ajax is one of those things where someone discovers something as it reaches completion, and must think they’ve invented it. I swear this was all at the MSDN web site in 1999. Go look it up yourself.

Anyway, I’d like to put a bow on this and move on with my life. My build environment gives me any more grief and I’ll redistribute with Eclipse and insist that users run my code in the debugger. Really, I don’t care if you can’t build it. I can. Finally. I hate Ant. Oh, how I hate it.

I’m not going to do this anymore, if it makes me unhappy. I used to program in Perl. It was fun.



September 12, 2006

Getting Volutneer Work Done

My days are falling apart without structure. I’m not able to create quite what I wish to create. At this moment, I’d like to call Karen and plan to run out and spend time at NENA, which is something that is very important to me. When we do, we miss Patricia, and nothing gets done. I don’t seem to be able to find the time to do this. Myself, I need a way to get things done, a project planning tool for volunteer projects. It would probably resemble a trouble ticket system in a software application.



September 10, 2006

Duck Typing

The B-Tree has two different types of nodes, an inner node and a leaf node. Both have methods that are similiar, except they operate on different types of objects. The inner node has a branch object, which is a pairing of an object in the container to test, and a pointer to the next node to visit if the sought object is less than or equal to the test object. There is a method called isLeaf to determine if we are at a leaf.

If we are, there are different things that need to be done. How nice it would be to have that be the only indication in the code, that context, and to not have to create different interfaces for the inner node and leaf node. It is turning out to be a lot of thinking about class design, when I’d much rather focus on algorithm design. Is there a magical pattern out there, with an additional level of indirection, can I have one node be both inner and leaf?

Perhaps, but then you have many small functions, which is supposed to be a good thing. It isn’t. At any point I could write a test to assert that a node can be correctly inserted into a leaf, but that does not mean that is makes for a correct B-Tree. Unit testing these tiny functions, I’m not sure the value. In the end, there will be only on real implementation of the leaf node, so a fixture against which new implementations can be tested will cut the other way, requiring that the fixture get fixed, should details of the implementation of the tree change, rather than having it dictated the implementation of new node classes.



 

Blogger Comments Feed

Blogger supports a comments feed for each post. I did not know this. I found the example in Graeme Rocher’s Blog.



September 2, 2006

Test First and Apathy

I have no users for Syndibase, no clients except myself, so I need to not worry about how something will be used outside myself. I must stop fussing, anticipating complaints of people who do not yet exist. In this note to self, I ask you to please be more agile. If only there was a better way to document this stuff, like a Wiki that was attached to the source code. Some place where I could write in English, what I’m trying to accomplish. In any case, I’ll fuss over a functionality that you would expect from an object or library, but one that I have no need for as of yet.

I can see that test first, and test coverage, has pushed me to write a lot of code that exists only in tests. When writing a library or object, I’ll think of a functionality the it ought to have, to round the object out. Let’s say I’ve created a container interface. For some reason, I’ll flesh the library out, adding, say, an immutable decorator implementation, even though their is no call for it in my current project.

I’ll write tests for the immutable decorator. Now, there is code that uses this implementation. Test code.

With a burning desire to release some software, I’m annoyed by all this rounding. When I look closely, a lot of the code that exists only to be tested, is dubious. If I have no need for an immutable decorator now, will I ever have such a need? Will a rounded library attract more users, or will it chase them away, because there are compontents that are unemployed oddballs?

These cheeky monkies like to break their tests. That all they got to do. When they do, it is agony to nurse them, because they stand between me and a commit, and all they do is exist to please some future programmer, to show that I thought of that possiblity.

I care not for this code. Apathy is toxic. I’ve remediated my source.

I do not berate test first. I berate myself.

It was my personal test first mindset of late 2005. It was a cycle of writing tests first, instead of writing code first, that led me to write objects that have no client except for the test.