October 13, 2005
In defense of the nearly tautologic diagram
Aristotle Pagaltzis rallies against pattern hype in general, and Martin Fowler's dependency injection article in particular:
Where was the meat? I read and reread the definition, examined the flimsy code snippets carefully, stared at the nearly tautologic diagrams for roughly 10 minutes, trying to grasp the deeply profound idea but failing.
Aside from having snorted coke through my nose over Car extends Vehicle OOP tutorial.
Aristotle is right when he says that the concept of dependency injection should be so ubiquitously understood that it shouldn't get its own brand name. But at the same time it represents the very essence of object-orientation and most people are not using it. How many times have you hacked around a library because it won't let you inject behavior? Once you've swallowed the pill, the world's ignorance of dependency injection is almost too much to bear.
I also think the more important of Fowler's postulations is not to understand dependency injection, but to use it with a persistence that borders on the religious. Consequently employing DI everywhere is actually a new methodology. Anyone who ever tried dependency injection as their default way of doing business knows that it is plain impossible with vanilla language constructs. Without assistance from a DI container you're just going to die the death of the million parameter constructor.
That time of the year, again
Apple announces a new piece of white hardware. Millions of Apple fanboy bloggers immediately claim bragging rights to having accurately predicted that the new gadget would, indeed, be white.
Meanwhile, my number one newsreader request remains an unfulfilled dream.
October 06, 2005
Help me pick a software license!
I have this one application for which I'd like to find a suiting license and could use your help picking one. Because I don't know the first thing about licensing, here are some general questions first:
- Pretty much all software licenses have the user waive any claims in case the software eats their data or blows up their machine. When the shit hits the fan, does the inclusion or absence of this clause really matter?
- My application is installed by downloading and unzipping an archive and thus has no installation screen. Where do I need to put the license? Mention it above the download links? Display it on the about-screen? Just include it to the documentation? Or must I require my users to click an "Agree" button somewhere?
- If I just expressed my intents in simple words, like "Don't sue me. Don't use for commercial purposes. Yo." What's the downside to that?
About the actual application for which I need a license:
- The core part of the application will remain closed-source for now, but ships with a large number of public API classes for plugin development (these classes also ship in compiled form). I'd like to allow any non-commercial use of the application and the API classes. Which license would do that? I used to think Creative Commons, but Creative Commons licenses are not intended to apply to software.
- The application also ships with a large number of plugins, including the sources of the plugin classes. Again I'd like to allow use for any non-commercial purpose. Do I need to treat the sources different from the binary part of the application?
Any comment that detracts from my state of total cluelessness will be greatly appreciated!
