Been busy hacking .net MockMaker

Been busy hacking .net MockMaker again today. Its messy at the moment, and there are no real tests (gasp!) yet but I think most of the guts is there. It won’t deal with overloaded methods or parameter modifiers yet. I have to learn how they work first 🙂

Modularising and unit testing tomorrow, unless I get bored of C# and do some Java instead.

Free Open Source Kills

Free Open Source Kills Markets.

Free Open Source Kills Markets

Open source, as a meme, is a successful one. It is also a confusing one because open source often means free software. I am for open source, but I am against wholesale adoption of free software because I believe it harms the health of software industry.

Free open source software devalue commercial software and poisons the marketplace. If some talented individual started giving out free Microsoft Word clone with source code, not only will Microsoft stock drop by 25%, entire word processing market will disappear. Once buys starts thinking that something should be free, there is no turning back.

One might argue that adding new features could revive markets decimated by free software. New features has leverage only during early half of a product category’s lifecycle. Word processing market is already well past the halfway point. I measure halfway point as the point where 20% of product feature set meets 80% of user’s needs. Past that point, users start caring less about new features.

[Don Park’s Blog]

If its possible for a talented individual working in their own time to produce a viable free alternative to a commercial product, doesn’t that offer some indicatation as the the true value of that product? If I can get a free Word clone from the net (and I can) instead of paying 100 pounds for Word, then chances are I will. If however, Word had sufficient added value in terms of reliability, ease of use, extra (useful) features, and good quality support to justify the price differential, then I might choose Word. The key issue is that the choice is mine to make. Competition, whether from Open Source or commercial products is a good thing.

If a commercial product is in competition with a cheaper commercial product, it must have sufficient added value over and above the lower cost alternative to remain competitive. Competing with Open Source is merely a more polarised example of the same issue.

AOP, aka multiple inheritance? Rickard’s

AOP, aka multiple inheritance?

Rickard’s recent descriptions of his activities in AOP have been very interesting. From my (probably flawed) understanding, it seems that the runtime behaviour extension framework he talks about bears a striking resemblance to an implementation of multiple inheritance. Even more cool than that, a dynamic, runtime adjustable form of multiple inheritance.

We like that.

In an alternative view, it almost resembles a return to modular, function based programming, where cross-cutting behaviour (such as logging) is encapsulated in a single location, and applied everywhere the application requires it. Interesting.

What I’d really like to

What I’d really like to attempt is a port of MockMaker to .Net. That would be interesting.

One thing I’ve noticed is that porting heavily test-covered code is incredibly easy. It helps that C# resembles Java’s long lost twin brother in many ways. What’s really good is that the test code can generally be copied almost verbatim as it tends to be quite simple, and it lets me drive the production code into existence in the .Net idiom, as I’m duplicating the intent rather than simply pasting Java into C# and fixing all the syntax errors.

Woohoo, two weeks off. What

Woohoo, two weeks off. What will I be doing? Probably sitting behind a keyboard coding 🙂 Sort of an open source busman’s holiday. When I’m not slumped on the sofa that is.

Started contributing to the .Net MockObjects project this weekend. It’s still in the early stages but the fundamentals are there. I can’t take any credit for that, Griffin has gotten off to a great start. All I’ve really done so far is convert the unit tests to NUnit 2.0. Watch this space though.

Following on from where sleep

Following on from where sleep interrupted me…

Having thought about it some more, I’m not sure a dynamic proxy would be needed in this case.  If the app. container wrapped the component object inside a simple non-dynamic decorator object and handed that to anything that needed it, swapping the implementation could still be done on the fly just by changing the decorator’s reference to the implementation.  Wouldn’t be as cool though 🙂

JMX and dynamic proxies.  This

JMX and dynamic proxies.  This could be interesting.  One of the things I’m not fully up to speed on with JMX is how you actually interact with the MBeans.  Having managed, pluggable components is great, but my POJOs (plain old java objects) still need to access the things, and having the entire API exposed in the management interface sucks.  I’m having the seed of an idea, but can’t quite verbalise it yet (not at my best at half-midnight).

Let’s see.  Wrap the component in an MBean, and expose its management properties.  Fine.  Register the MBean in the server.  Expose a management operation that returns the implementation of your component.  (This is where it gets sketchy).  Place the implementation inside a dynamic proxy, and have the application container pass the proxy to any objects that need the component (inversion of control).  Do something with notifications so that the implementation object or app. server itself can be called back whenever a managed property is altered.  Retrieve the new component instance from the JMX server and place that inside the dynamic proxy, replacing the old one.  Any clients that have a reference to the proxy instance should now be calling the new component.  Hot swapping.  Hot damn.

Am I making any sense?