Archive : February 2009

On Maturity, an Immature Response

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.

Continue reading »

Topics:

Bean of the Devil: Why Getters, Setters and Such are Evil

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.

Continue reading »

Groovy 1.6 and Per-Instance Metaclass

Groovy
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.
Continue reading »

Are We Engineering Software or People?

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?

Continue reading »

Again With The Test Driven Development

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.

Continue reading »

Review of fixture_replacement2 plugin – Update

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.

Continue reading »

It’s Only Rack on Rails But I Like It

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?

Continue reading »

Topics:

Performance Optimization for Flash Player

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.

Continue reading »

Grails: Delegating to GORM Persistence in Java

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.

Continue reading »

Topics: , , ,

Estimating Bugs and the Complex Behavior of Simple Systems

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.

Continue reading »

Topics: ,

The Incredible Rising Version Number

Rails_Logo_250x250_White.gif

This week marked the release of Ruby on Rails 2.3 RC 1.

If you're thinking, "Good Lord, that was fast. I just got around to watching the What's New in 2.2 video", you're probably not alone. 2.2, according to the ever-reliable Wikipedia, was released about 10 weeks before 2.3 RC 1. And it's not like 2.3 is a minor tweak -- it includes a major change to the Rails internals (Rack support), a nested form feature that's been a top request for some time, and a bunch of other small, but nice changes.

However, I don't mean to do a "What's New" post -- at least, not this week. This week is a little bit more meta, and might more accurately be called, "How To Deal With What's New".

Continue reading »

Topics:

ZendAMF vs. AMFPHP

So far, of all the AMF frameworks I have been a proponent of AMFPHP and RailsAMF. I still don’t know RoR very well (working on it), but I’ve been using PHP for a long time and have grown to love it so AMFPHP was always my natural choice.

Now we have a new player in Flash Remoting arena - ZendAMF. Why should anybody care when AMFPHP was just fine?

A few reasons.
Continue reading »

Visually Indicate Develpmont Vs. Production Environments

After my BA added "My Test Project" to production, I wanted to try to prevent this kind of behavior in the future.  I added "Environment: Development" in the header of the layout.  This was nice, but it was so subtle, I wouldn't think it would prevent you from making the same mistake.  So, I had the visual designer create 3 separate background images for Development, Staging and Production (well this one was already there).  I then conditionally modified the style in the application layout head section:


<head>

<style type="text/css">
<% if RAILS_ENV == 'development' %>
body { background-image: url(/images/bkgrnd_dev.gif); }
<% elsif RAILS_ENV == 'staging' %>
body { background-image: url(/images/bkgrnd_staging.gif); }
<% end %>
</style>

</head>

Now, whenever I am in development I can clearly tell.  Staging also looks different.  So now, it's really easy to tell that you are in production, right before you add some crappy test data.

IE8 — Another IE6 in the Making?

IE6 was a plague upon the Web landscape; we're still dealing with the hacky CSS, HTML and JavaScript that IE6 forced us to write. And there's a handful of dead-enders who just won't let IE6 die, die, die already. So the nearing release of IE8 should be good news, right? Everybody moves up a notch, even the poor sods whose corporate standard is IE6 (crazy, I know).

Not so fast. What made IE6 so bad is that it's bugs became standards. When your site doesn't work, you don't have time to wait while Microsoft maybe pushes a patch (which doesn't take with 50% of the installed base), so you hack the CSS, HTML and JavaScript to make it work. Before you know it, the bugs and other deviations from the standard have become the standard.

Now there are some worrisome signs around the release of IE8. Tables that don't render correctly, JavaScript calls that crash the browser. It's not just the bugs, it's the fact that the IE8 team seems to be giving these bugs the stiff-arm. If IE8 makes it out with a load of these fundamental bugs, they will become the f*cked up baked potato of a standard. And all of us web application developers will be back in 2003. I hated those IE6 days, and none of my clothes from that time fit anymore.

So, if you want to make sure that IE8 isn't a recap of the horrors of IE6, get yourself a copy of IE8 and start providing some feedback. Also, make sure to vote up those bugs that really need fixing. Even if you don't use IE in your day-to-day work, if you develop web software, this is a matter of sanity.

Topics:

Launch: Pathfinder Newsletter

    Get a monthly update on best practices for delivering successful software.

    Subscribe via email


    Subscribe via RSS      RSS icon

Topics

Search

WordPress

Comments about this site: info@pathf.com