Archives

So, a couple of weeks ago Obie Fernandez proposed some kind of Rails Maturity Model (RMM) by analogy to the more generic CMM model for generic software development.

For his troubles, Obie got a lot of guff from the peanut gallery, much of it from developers who have worked at companies where CMM is in place and know what a nightmare that can be.

I suspect this isn’t the last time this will come up in this post, but I did work at a major telecommunications company that pushed many of it’s software divisions to CMM Level 5. We really did have a process in place for evaluating proposes to improve processes. I can’t remember whether we actually had a meeting about reducing the number of meetings, but it was definitely proposed…

My general response to any kind of measurement proposal about programmer or team quality has two points:

• I absolutely understand the problem, and the desire on the part of those of us who think we do good work to be able to point to a metric that validates us. Or, best case, shows us how do even better work.
• I’m very skeptical of any specific attempt to measure individual productivity or team maturity.

Share/Bookmark

I felt like I’d already gotten this rant out of my system, but every time I come across the object oriented wreckage that the Java Bean and it’s decendents have wrought, I get all heated up. The problem is, simply stated, that the getters and setters that get used for things like system boundaries — Hibernate for persistence, Spring for dependency injection, Java Beans for UI components — end up being misused for things that break basic OO principles.

Share/Bookmark

One of the new features of Groovy 1.6 includes support for per-instance metaclasses. This is a nice addition to the language, since it allows to change the behavior of objects without affecting all instances of the class as a whole.

For testing, it is often useful to mock out specific behavior of an object without affecting the class as a whole. While some mocking frameworks already allow this, they usually run through a few hoops (i.e. “partial mocks”). Allowing support directly in the language can simplify this kind of approach.

Another case where per-instance metaprogramming can be useful is in employing template patterns on a per-instance basis. Picture the case where the domain decides that one of its children is no longer in a valid state. Most domain models handle this by embedding some sort of state object within the children, so that any object holding a reference to the children know what the child can or can not do. With a per-instance metaclass, however, the aggregate root can simply add or replace behavior of that instance of the object alone.

Share/Bookmark

I had a nice little vacation this past week in Los Cabos. It’s always sunny, 80 and it never rains. Very nice. My wife and I had another installment of our long running discussion called “Computer Science is not a science.” My wife is a real scientist with a Ph.D. in physical chemistry, and so she has a bit of a chip on her shoulder about the whole “science” thing. It’s a one-sided discussion because I agree with her. Computer science is not about experiments and the scientific method, it’s about three or four different and disparate areas — mathematical computer science, AI or clever algorithms, chips and clock logic, and software engineering.

Then she told me that she thought of me more as an engineer. That got me thinking. Am I really an engineer?

Share/Bookmark

my economics final by “diabetesisfun”

So, if you’re lucky, you’ve mostly missed another Internet pile-up about unit tests and so on, this one started by Joel Spolsky and some comments he made on his podcast.

I’ve already written a little bit about what Joel said, and I don’t want to rehash that. But I have seen a recurring theme in arguments that testing is overrated — namely that the testing that those people are writing about doesn’t seem to be related to the testing that I actually do.

I’m going to put the summary up front:

• “Unit Testing” and “Test Driven Development” are not identical concepts
• It would seem, on the available evidence, that those of use who are TDD or BDD backers haven’t done a great job of explaining this.
• TDD has code quality benefits that are completely separate from whatever function it has as a code verification engine.
• It would seem, on the available evidence, that those of use who are TDD or BDD backers have done a really poor job of explaining this.

Share/Bookmark

UPDATE:

So, after working on my project for months, and getting other developers involved, I need to change my mind.  I still like fixture replacement, but most of my tests require such an elaborate data set, that my tests are PAINFULLY slow.   What was I thinking back in November?  I guess I wasn’t focused due to the Obamathon that was running through the nation at the time.

My application is an internal tool we use for staffing our projects, and is going to manage time entries and invoicing.  There are many other features in the pipeline, but I’m making sure that we keep our eye on the ball, and releasing the most important features first.  The problems I run into, are that most of my model methods are doing complicated queries on a data set that has a lot of possible values.  To test some of my reports, I need to test the cases where there are people on various projects, vacations, holidays, out of office, etc.  To ensure that the method responds correctly with all of these possible values, my data set is complicated.  I have a number of test helper methods that set up some or all of my data set depending on what I am testing.  This has effectively replicated fixtures, and I have lost my speed.

What are my issues:

1. Fixtures are wicked fast.  Fixture replacement is not when you have large data sets.  Why?  Fixtures essentially load the data in the tables, then start a transaction before each test and rolls it back after each test.  Fixture replacement does not get this benefit, as all data is loaded after the transaction is started.  So my tests take forever….

2. Because I need complicated data sets that are reusable, My test helpers set up the data in stages, and I only load what I need.  One of the problems I had with fixtures, was I always had to go the fixture files to see what data was loaded.  When using fixture replacement, my test data is normally defined in a setup context of at the beginning of each test, so i can see exactly what data is on the model I’m testing.  Due to my test helper setup methods, I now am constantly referring to them instead of the fixture files.

My plan:

As my project takes a few minutes to run the tests, I need to fix this, as my application will begin to be used by the entire company for time tracking, and the features will need to roll out quickly.  I can’t have any developer waiting minutes before each check in.  This will only lead to test mutiny (checking in without running rake).  So, my plan is:

1.  Create a new data set in fixtures that includes an updated view of my projects (the current one is stuck in July of last year).  Use mocks to mock out Date.today.  I was setting an effective date as a member variable in my tests, but I like the idea of mocking it out better.  I will also create some sort of visual depiction of my data set, as I am constantly trying to figure out what the application should generate, as I created my data set months ago, and generally don’t have any idea of what it looks like when I am adding new features.

2. Slowly convert my tests to use my new data set.

3. Kill my old fixture replacement setup helpers

4. Only use fixture replacement for small unit tests.  Most of my simple model methods can use a very simple setup with fixture replacement.  The model methods that are crazy complicated can use the fixtures and date mocks.

So – I still like fixture replacement, but It is not good for large data sets.  I think fixtures are still useful and their speed only sweetens the deal…..

Original blog post:

We have been using fixture_replacement2 on some of our Ruby on Rails projects. I am writing an internal application and finally switched over from using fixtures. It took a bit of time to get the tests that I had written modified to stop using the fixture data, but now I am completely fixture free. The tests are a lot easier to write, and I created a few helper methods that setup common datasets. This way, I can call a setup method to configure my data, and then – it’s all good. At first I called the method test_data_blah, and was wondering why I was getting an error running any test, so now it’s called data_blah.  Doh!

At first I didn’t like the fact that I needed to explicitly create the data for what I was working on, but then I realized that (especially for unit tests)  you don’t need much dependent data; usually it’s one or two records. For functional tests, I found that the data setup methods rocked, as I could quickly get the data set up that I needed.I could quickly assert the content of the response, based on the data in my setup. I missed fixtures at first, but now realize that over time, they are a pain.

Share/Bookmark

Rack’s official Logo

One of the signature changes of the Rails 2.3 release is a complete reworking of the Rails internals to be Rack compatible.

If the people I talk to about Rails are any indication, then reaction to this move has ranged all the way from “Wow, that’s really cool” to “I have no idea what you are talking about”.

Here’s a quick look at what Rack is, and what it brings to Rails. I freely admit that I’m only starting to explore this stuff myself, but it’s already starting to change the way I’m thinking about structuring new Rails applications.

What is Rack?

Share/Bookmark

Time and again the same scenario arises. An app is being built and it’s all going fine until the very end when performance issues start to appear.

Optimizing Flash performance is certainly the most boring part of Flash Platform development but it’s a cornerstone without which you, the Flex developer, can not do without.

An app is worth nothing unless you provide that effortless flow of interaction at all times.

There is not too much information on this topic as it is not the most interesting one but here are some simple guidelines that have helped me tremendously over the time, as well as a few great papers.

Share/Bookmark

For a recent project, I needed to plug some Java code into a Grails app. I wanted to use GORM for persistence, but couldn’t introduce the interfaces, proxies, and factories into the java code which is required for existing solutions to this problem.

Basically, my constraint was that the java code itself couldn’t be altered to work inside the grails app. The solution I came up with is pretty simple, but works well.

Share/Bookmark

One of the bitter consolations of mathematical Computer Science is that we can demonstrate that applying algorithms to analyze algorithms is a largely fruitless task. It starts with the halting problem (can we write a program that takes a program as it’s input and determines whether that program halts on all inputs) and goes on from there. The proof is by contradiction and — like most “assume not” proofs — is largely unsatisfying, i.e. it doesn’t construct anything useful that you could apply to other problems. As Professor Herstein once told me in undergrad algebra, “Kappe: assume not assume not.”

That’s one of the theoretical underpinnings of why some software bugs are so hard to detect and fix; in a large system, automatically diagnosing bugs is akin to solving the halting problem. But what if we just try to solve this problem for a really small subset of programs? Well, first, it would have to be a really small subset. And second, even with very simple systems, answering questions about correctness, such as “does it halt,” can be surprisingly difficult.

Share/Bookmark