Last Saturday night, I bumped into Pure Evil while at a party thrown by a neighbor. I didn't think I was going to meet Pure Evil, and didn't even realize who it was until we had chatted a bit. But there he was, with a wine glass in his hand. He (and I won't mention his name for reasons you'll see in just a bit) is a former executive of several software companies and has been (and is currently) a consultant. He is now engaged in 2 lines of business: the first is to act as expert witness in dubious patent lawsuits for software patents that should have never been granted. The company he works for finds outrageous patents (they have found someone who has allegedly patented ecommerce -- the whole process) and sues major software companies. While ethically a little shady, this is not illegal. And I know that some smart people agree that you can patent software and processes. The ambulance-chaser way they are doing this, however, is a little creepy.
Turns out that this was just the appetizer. His other line of business is to sell small to medium sized business on as much enterprise software as possible. Things like SharePoint, PlumTree, Biztalk, etc. He really, really likes Microsoft back-office software because, as he puts it, "it's very easy to install". I asked him if most of his clients really need that much stuff -- wouldn't a wiki or something lighter weight solve the problem more elegantly? He was dumbfounded at the question because he can't charge big money for the care and feeding of that kind of software. He also professes to like .NET a lot because it is so extremely RAD. I asked him if doing development like that didn't cause problems during the maintenance phase of the application. After all, that's where you pay for rampant RADism, trying to find all that code you've sprinkled throughout your user interface in event handlers. His response: "We're generally through with the contract at that point, or leave for other reasons, so we don't have to worry with that too much". To summarize: sell them as much software as possible (that we don't have to understand very well), slam together applications that quickly become un-maintainable, then get out of Dodge before the repercussions hit. Clearly, this person and his company are trying hard to make sure that consultants are universally loathed.
People like this have the ethics of slave traders. Back in the day, slave trading was legal, and I'm sure it was very profitable...and morally repugnant. Mr. Pure Evil was also bragging about how much money he made last year ($350K). But how does he sleep at night? It made me realize first hand that you can randomly bump into people like this, who care for profit at the expense of ethics and brag about it. Excuse me, I've got to run take a shower...
Monday, March 28, 2005
Friday, March 25, 2005
Robert Fripp's Aphorisms
Robert Fripp's Aphorisms
If you recognize the name in the title, it is unlikely for the reasons I'm going to write about today. Robert Fripp was (and is) the guitarist and de-facto leader of the only surviving original progressive rock band, King Crimson. While the others (like Yes, for example) still tour in a Dinosaurs Roam the Earth mode (still playing their music from the 70's), King Crimson still tours with new music, and it is very new music indeed. Robert Fripp also founded a school for guitarists called Guitar Craft. It is not a permanent school, but one that moves from place to place, holding week-long classes for all levels of guitarist. I haven't been to one, but I've read about them. Really, they are as much about attitude and discipline as about playing music. There have been several graduates that have gone on to careers in music, most notably The California Guitar Trio.
However, this post isn't about that either. One of the rituals of Guitar craft is the recognition of aphorisms, or quotes that have special meaning in a specific context. The dictionary definition of aphorism is "a concise statement of a principle". Like:
The attitude that life owes us something, if not everything, encourages life to thwart our endeavors.
Taken in the context of guitar craft, these aphorisms relate to (at the macro level) life in general and (at the micro level) about the craft of playing the guitar.
We begin where we are.
However, there is another context with which to read these aphorisms. Fripp is legendarily disciplined, and there are numerous published examples of this trait, perhaps best is his own on-line diary (established before the term "blog" was coined). Another is the (unfortunately) out of print biography by Eric Tamm. These aphorisms, being "concise statements of principle", apply broadly to life and particularly leading a disciplined life. And that is something to which everyone should aspire. Reading and pondering these random aphorisms over the years has helped me write (or, more precisely, finish) books. And they have helped me finish arduous endeavors like Ironman.
Process is Intelligence getting to know itself.
Until you understand Fripp's context, some of the aphorisms don't make much sense. However, over years of reading, you understand the context and draw meaning from all of them.
Relaxation is never accidental.
If you want to see some Fripp aphorisms, go to the Discipline Global Mobile web site. At the bottom of the page is a random CGI script that randomly show aphorisms while you are on the site. One of my favorites (I have part of this engraved on the back of my iPod now) is one about the relationship between music and silence (in many ways, music frames a particular kind of silence):
Music is the cup that holds the wine of silence. Sound is the cup, empty; noise is the cup, broken.
In many ways, software development relates to music: a creative endeavor facilitated by dexterity, tools, and discipline. And, correspondingly, many of the aphorisms apply eerily to software development.
Address the process rather than the outcome.
Then, the outcome becomes more likely.
Enjoy!
If you recognize the name in the title, it is unlikely for the reasons I'm going to write about today. Robert Fripp was (and is) the guitarist and de-facto leader of the only surviving original progressive rock band, King Crimson. While the others (like Yes, for example) still tour in a Dinosaurs Roam the Earth mode (still playing their music from the 70's), King Crimson still tours with new music, and it is very new music indeed. Robert Fripp also founded a school for guitarists called Guitar Craft. It is not a permanent school, but one that moves from place to place, holding week-long classes for all levels of guitarist. I haven't been to one, but I've read about them. Really, they are as much about attitude and discipline as about playing music. There have been several graduates that have gone on to careers in music, most notably The California Guitar Trio.
However, this post isn't about that either. One of the rituals of Guitar craft is the recognition of aphorisms, or quotes that have special meaning in a specific context. The dictionary definition of aphorism is "a concise statement of a principle". Like:
The attitude that life owes us something, if not everything, encourages life to thwart our endeavors.
Taken in the context of guitar craft, these aphorisms relate to (at the macro level) life in general and (at the micro level) about the craft of playing the guitar.
We begin where we are.
However, there is another context with which to read these aphorisms. Fripp is legendarily disciplined, and there are numerous published examples of this trait, perhaps best is his own on-line diary (established before the term "blog" was coined). Another is the (unfortunately) out of print biography by Eric Tamm. These aphorisms, being "concise statements of principle", apply broadly to life and particularly leading a disciplined life. And that is something to which everyone should aspire. Reading and pondering these random aphorisms over the years has helped me write (or, more precisely, finish) books. And they have helped me finish arduous endeavors like Ironman.
Process is Intelligence getting to know itself.
Until you understand Fripp's context, some of the aphorisms don't make much sense. However, over years of reading, you understand the context and draw meaning from all of them.
Relaxation is never accidental.
If you want to see some Fripp aphorisms, go to the Discipline Global Mobile web site. At the bottom of the page is a random CGI script that randomly show aphorisms while you are on the site. One of my favorites (I have part of this engraved on the back of my iPod now) is one about the relationship between music and silence (in many ways, music frames a particular kind of silence):
Music is the cup that holds the wine of silence. Sound is the cup, empty; noise is the cup, broken.
In many ways, software development relates to music: a creative endeavor facilitated by dexterity, tools, and discipline. And, correspondingly, many of the aphorisms apply eerily to software development.
Address the process rather than the outcome.
Then, the outcome becomes more likely.
Enjoy!
Wednesday, March 23, 2005
Mourning Superior Dead Technologies
I was thinking this morning about buying a Macintosh, which lead me to ruminate on the fate of sometimes superior technologies that nevertheless fade away (not that I think that's happening to the Mac -- honest!). I can think of a bunch of examples off the top of my head: NextStep (I only heard about it, never got to use it), Magellan (the greatest navigation aid for a file system ever, never made it to Windows), Sprint (the best Word processor, never made it to Windows), and the list goes on and on. Even something like IntelliJ, which is creepy smart (side note: today, I realized that it will generate default variable names for you, based on the class type, even make good guesses -- for
So, I reached a conclusion: don't mourn dead technologies. Use the best while it's available, but don't lament what could have been. I'll support Apple, IDEA, and the other technology stuff that I think exemplify good design. But, if market forces deign that they not survive, I won't fret -- just move on the find the next best thing. Besides, the really great ones sometimes live again, in different guise: OS X is really just NextStep reborn, Ruby is SmallTalk with some differences. Now, excuse me while I go shopping at the Apple site, with my iPod firmly implanted in my ears...
JButton, it offers both jButton and just button) -- I wonder if it can withstand the onslaught of Eclipse?So, I reached a conclusion: don't mourn dead technologies. Use the best while it's available, but don't lament what could have been. I'll support Apple, IDEA, and the other technology stuff that I think exemplify good design. But, if market forces deign that they not survive, I won't fret -- just move on the find the next best thing. Besides, the really great ones sometimes live again, in different guise: OS X is really just NextStep reborn, Ruby is SmallTalk with some differences. Now, excuse me while I go shopping at the Apple site, with my iPod firmly implanted in my ears...
Tuesday, March 22, 2005
Software "Engineering"
It seems like every time someone talks about the job/craft/calling of writing software, they tend to end up with a bunch of tortured metaphors (engineering, woodworking, rock climbing, gardening, etc.). None of these analogies hold up past just superficial scrutiny. I think that it's a reflection on how different it ultimately is.
But to use one of these tortured metaphors for a moment, think about bridge building. I had someone at No Fluff, Just Stuff Philly say that her company had starting outsourcing much of their coding to India. I asked her how they judge the quality of the software. She said that she looks over it, and they have a software architect that comes to look at it periodically. Unit tests? None.
What if you decided to build a bridge? You outsourced all the design to guys who say they can build bridges, and you have someone who has built a few bridges look over the design when it comes in. Would you drive over that bridge? What makes bridges safe? It's the engineering science behind the bridge -- the mathematics of structures, derived over a great many years. So, why don't we apply the same rigor to software? We can't. We don't understand enough about it to quantify it in that way (and may never -- that's where the engineering metaphor breaks down again).
So, what's a poor developer to do? Actually, we do have a great option -- testing! It's extraordinarily difficult to build all the parts of the bridge and test them individually, then test it as a whole. However, because software is so soft, you can test everything. And you should. That's as close as we can get now to the rigors of a "real" engineering discipline. So we'd better damn well start doing it!
But to use one of these tortured metaphors for a moment, think about bridge building. I had someone at No Fluff, Just Stuff Philly say that her company had starting outsourcing much of their coding to India. I asked her how they judge the quality of the software. She said that she looks over it, and they have a software architect that comes to look at it periodically. Unit tests? None.
What if you decided to build a bridge? You outsourced all the design to guys who say they can build bridges, and you have someone who has built a few bridges look over the design when it comes in. Would you drive over that bridge? What makes bridges safe? It's the engineering science behind the bridge -- the mathematics of structures, derived over a great many years. So, why don't we apply the same rigor to software? We can't. We don't understand enough about it to quantify it in that way (and may never -- that's where the engineering metaphor breaks down again).
So, what's a poor developer to do? Actually, we do have a great option -- testing! It's extraordinarily difficult to build all the parts of the bridge and test them individually, then test it as a whole. However, because software is so soft, you can test everything. And you should. That's as close as we can get now to the rigors of a "real" engineering discipline. So we'd better damn well start doing it!
Sunday, March 20, 2005
Toogle
I read about (and tried) an interesting new site today, Toogle. It performs a search for whatever you type in and returns it as an image generated from the words of the search, using different colors to mimic the colors (and therefor reproduce) the item you searched for. Trying to explain it is fruitless -- just go try it. I still haven't figured out how it decides what to return (a search for my name returns the JBuilder 3 Unleashed book, which is ancient history, not my most recent book), but it's still a fun idea.
Thursday, March 17, 2005
Slowly Turning XMLese
Quote of the week, appearing on several other blogs (and in the March 14 issue of eWeek), attributed to Chris Maden:
"XML is like violence: if it doesn't solve your problem, you aren't using enough of it"
Nuff said.
"XML is like violence: if it doesn't solve your problem, you aren't using enough of it"
Nuff said.
Wednesday, March 16, 2005
Favorite New Eclipse Plug-in
Generally, I'm at the mercy of the client as to which IDE I use for Java development. Consequently, I try to find tools in each IDE that replicate favorite features in my favorite IDE (currently IntelliJ). Right now, I'm working on a project in Eclipse (the 3.1 M5a version, which has pretty good Java 5 support and isn't too buggy). One of the features I miss the most is the "Go incrementally find this thing", where "this thing" is a class name, part of a class name, or even some special versions of a class name (for example, to find TuPopupMenuManager, you can search for TPMM and it will find it). IntelliJ has this, and, no matter how many times you whack the side of the monitor, Eclipse does not...
...Unless you install my favorite new plug-in, GotoFile. It does just what I want it to, just like IntelliJ. And it even has preferences. Works with any version of Eclipse back into the dim and distant past. And, it's the Eclipse feature I use most during the day.
...Unless you install my favorite new plug-in, GotoFile. It does just what I want it to, just like IntelliJ. And it even has preferences. Works with any version of Eclipse back into the dim and distant past. And, it's the Eclipse feature I use most during the day.
Tuesday, March 15, 2005
Aspects and Undoing
I was talking to Ramnivas Laddad (the person who knows the most about Aspects than anyone I know) at the Philly No Fluff, Just Stuff conference, hoping to dazzle him with an idea I had recently about a cool use for Aspects. My idea: using aspects to implement the Memento pattern for undo. The plan: use attributes in Java 5 to flag which fields are undoable, then write an aspect that injects the appropriate code into an inner class of the undoable class (side note: I prefer to use inner classes when implementing Memento, because they meet all the requirements of the Memento but don't break encapsulation because the inner class has a reference to the outer one's private fields).
Of course, someone has already had this idea, which Ramnivas kindly pointed out (check out Jon Tirsen's blog entries here and here). My only contribution to this discussion is the use of attributes in Java 5 to flag the undoable fields -- the rest had already been figured out. Just when you think you have a clever idea, inevitably, someone else has beat you to the punch. I do think this is a great use for Aspects, though.
Of course, someone has already had this idea, which Ramnivas kindly pointed out (check out Jon Tirsen's blog entries here and here). My only contribution to this discussion is the use of attributes in Java 5 to flag the undoable fields -- the rest had already been figured out. Just when you think you have a clever idea, inevitably, someone else has beat you to the punch. I do think this is a great use for Aspects, though.
Monday, March 14, 2005
No Fluff, Just Stuff Philly
Just got back from No Fluff, Just Stuff in Philly (my first NFJS of the year). I had a lot of talks this time (4 in Java, 4 in .NET), spread over 2 days. That was too bad because, as usual, there were a bunch of talks from other speakers that I really wanted to see. That's almost always the case.
No Fluff, Just Stuff attendees continue to surprise me with the level of discourse that occurs, both in the sessions and out. You are hard pressed to find someone to talk to that doesn't have something interesting to say. The expert panel was interesting (if for no other reason than to hear Ted Neward bicker with everyone). And the Birds of a Feather that I did with Scott Davis and Eitan Suez was also very interesting (we were supposed to just talk about Web Frameworks and User Interface stuff, but we ended up in a fascinating, wide ranging discussion covering outsourcing, certification, dynamic languages, and, oh yeah, web frameworks).
Fun stuff.
No Fluff, Just Stuff attendees continue to surprise me with the level of discourse that occurs, both in the sessions and out. You are hard pressed to find someone to talk to that doesn't have something interesting to say. The expert panel was interesting (if for no other reason than to hear Ted Neward bicker with everyone). And the Birds of a Feather that I did with Scott Davis and Eitan Suez was also very interesting (we were supposed to just talk about Web Frameworks and User Interface stuff, but we ended up in a fascinating, wide ranging discussion covering outsourcing, certification, dynamic languages, and, oh yeah, web frameworks).
Fun stuff.
Sunday, February 27, 2005
Woot!
My favorite new "Why Didn't I Think of That?" site is Woot! (www.woot.com). It is a shopping site that only features 1 item a day. They have a limited number of that 1 item, and when they are sold out, nothing happens for the rest of the day. Generally, it's something that is very deeply discounted. The next new item appears at midnight (central time) for the next day. How cool is that? The items vary widely, from robots to blenders (and that was just this week). Check it out. If you really get caught up, you'll end up staying up until midnight to see what the next item is going to be. The really good ones sell out fast (I'm not quite at that level yet -- I wait until the next morning...and end up missing out a bunch of times).
Wednesday, February 16, 2005
Instant Wiki
One of the best collaborative tools I've found in a long time for development projects is a Wiki because it is lightweight and free-form enough that everyone will use it. We've had one for a while at DSW and I'm stunned at how useful it is. There are lots of overblown document sharing systems out in the world (recently, I had the displeasure of using Microsoft's SharePoint -- ugh!), but the simple Wikis Just Work.
The one we've used for a while at DSW is Very Quick Wiki from SourceForge, a quick, simple, J2EE based Wiki. It took all of 15 minutes to setup and has run flawlessly for months.
I recently discovered an even easier one to set up -- Instiki. The instructions are so complex I'm going to reproduce them here:
Step 1. Download
Step 2. Run "instiki"
Step 3. Chuckle… "There’s no step three!" (TM)
OK, it's slightly more complex (you have to have Ruby installed), but not much. It stores everything in the filesystem (in a single portable directory if you have to move it, back it up, etc.), includes its own web server, and it Just Works. It is now officially my new favorite ultra-lightweight Wiki. And, it's Ruby based, which makes it even dearer to my heart!
The one we've used for a while at DSW is Very Quick Wiki from SourceForge, a quick, simple, J2EE based Wiki. It took all of 15 minutes to setup and has run flawlessly for months.
I recently discovered an even easier one to set up -- Instiki. The instructions are so complex I'm going to reproduce them here:
Step 1. Download
Step 2. Run "instiki"
Step 3. Chuckle… "There’s no step three!" (TM)
OK, it's slightly more complex (you have to have Ruby installed), but not much. It stores everything in the filesystem (in a single portable directory if you have to move it, back it up, etc.), includes its own web server, and it Just Works. It is now officially my new favorite ultra-lightweight Wiki. And, it's Ruby based, which makes it even dearer to my heart!
Tuesday, February 15, 2005
Environmental Overcompensation
I travel a lot, and I've noticed a universal trend in places with inclement weather -- they always try to overcompensate for the temperature. For example, if you are in Houston in August and walk into a store, the air conditioning will have the temperature at 60 degrees. At first I thought what you are thinking now -- it just seems cooler because it is so hot outside. But, that's not the case -- I've looked at thermostats. Conversely, if you are in Grand Rapids in January and walk into a restaurant, it will be 90 degrees.
In each case, it seems that the people who live in weather-challenged places are trying to overcompensate. Almost like they are ashamed of the weather and they're trying to make it up by showing that they don't really like the ridiculous heat, they would rather shiver in July...
In each case, it seems that the people who live in weather-challenged places are trying to overcompensate. Almost like they are ashamed of the weather and they're trying to make it up by showing that they don't really like the ridiculous heat, they would rather shiver in July...
Thursday, February 10, 2005
Aspects of Aspects
When I learned about Object-oriented programming, I thought it was about the coolest thing I had ever seen. The canonical example back in 1989 was shapes, so that you could create a polymorphic draw() method (this example still pops up a lot). So, I learned about OOP as a way to model problem domains. However, the only examples I saw for years out in the real world were all frameworks, like GUI frameworks or persistence stuff -- it was generally in the form of components to make constructing applications easier. Gradually, people started using OOP the way that I thought it should have been all along -- to model problem domains.
I think the same thing is happening right now with Aspects. While not as revolutionary as OOP, aspects still represent a key shift in thinking. But most of the examples you see these days are all in the boundary layers again -- logging, persistence, dependency injection, security, etc. Like OOP, once developers really grok what's going on with aspects, we'll start seeing it show up in the problem domain layer in places where it makes sense. Just like the really advanced OOP practitioners were doing it right early on, the aspect guys who are pushing the state of the art are pushing aspects into the problem domain right now. In 15 years, it will be as natural as polymorphism.
I think the same thing is happening right now with Aspects. While not as revolutionary as OOP, aspects still represent a key shift in thinking. But most of the examples you see these days are all in the boundary layers again -- logging, persistence, dependency injection, security, etc. Like OOP, once developers really grok what's going on with aspects, we'll start seeing it show up in the problem domain layer in places where it makes sense. Just like the really advanced OOP practitioners were doing it right early on, the aspect guys who are pushing the state of the art are pushing aspects into the problem domain right now. In 15 years, it will be as natural as polymorphism.
Wednesday, February 09, 2005
TV is the New Campfire?
Speaking of cavemen (as in my last blog entry), a friend of mine made an interesting observation. This is while we were camping (and those of you who know me and my policy on camping will understand what a rare occurrence that was), sitting beside the campfire. As you know, there is a hypnotic effect when you sit and watch a fire, either of the camp variety or in a fire place. Wright's observation was that the hypnotic effect may be genetic. Back when we lived in caves, it benefited those that sat around the fire at night -- more warmth, more personal interaction with the other fire-likers, and less likely to get eaten. And that TV is the modern campfire.
When you think about it, there are definite similarities. Both are flickering lights that encourage you to sit and stare. Maybe that explains the ease that some people have sitting and watching TV for hours on end. And, that may explain the default behavior of many people I know when they watch TV. They don't find a good show to watch (because there aren't any), they find the least worst thing and watch it. When a commercial or some other distraction comes along, they find the next least worst thing and watch it. I propose that most of the TV being watched isn't because it's really good, it's because it's there. A lot of TV isn't much more entertaining than a fireplace. Both seem to encourage that passive, vacant stare.
Maybe you could get the best of both worlds by setting fire to your TV?
When you think about it, there are definite similarities. Both are flickering lights that encourage you to sit and stare. Maybe that explains the ease that some people have sitting and watching TV for hours on end. And, that may explain the default behavior of many people I know when they watch TV. They don't find a good show to watch (because there aren't any), they find the least worst thing and watch it. When a commercial or some other distraction comes along, they find the next least worst thing and watch it. I propose that most of the TV being watched isn't because it's really good, it's because it's there. A lot of TV isn't much more entertaining than a fireplace. Both seem to encourage that passive, vacant stare.
Maybe you could get the best of both worlds by setting fire to your TV?
Monday, February 07, 2005
Team Sports and Tribes
'Tis the season...
What with the SuperBowl just having passed like a storm, I started thinking about why people are so zealous about sports. Like the comedian said (I'm paraphrasing and sanitizing), oppressed people riot about the condition of their lives, while civilized people riot when their sports team wins!
I think this is a perfect example of deep-seated primate behavior leaking through the facade of civilized society. When we were in tribes on the African plains, it was a Good Thing to support your tribe, and behaviors evolved to reinforce that activity. The guys that didn't care for the tribe were off in the woods, acting as appetizers for saber-toothed tigers.
Today, this tribal tendency leaks out in the more or less harmless outlet of team sports. We've decided that countries as tribes is a bad idea (it took several wars, and some still aren't convinced). So, now we have our teams where we can attach our savanna baggage.
What with the SuperBowl just having passed like a storm, I started thinking about why people are so zealous about sports. Like the comedian said (I'm paraphrasing and sanitizing), oppressed people riot about the condition of their lives, while civilized people riot when their sports team wins!
I think this is a perfect example of deep-seated primate behavior leaking through the facade of civilized society. When we were in tribes on the African plains, it was a Good Thing to support your tribe, and behaviors evolved to reinforce that activity. The guys that didn't care for the tribe were off in the woods, acting as appetizers for saber-toothed tigers.
Today, this tribal tendency leaks out in the more or less harmless outlet of team sports. We've decided that countries as tribes is a bad idea (it took several wars, and some still aren't convinced). So, now we have our teams where we can attach our savanna baggage.
Wednesday, January 26, 2005
Query Your Code
Lately, I've been doing a handful of code reviews for clients. I have access to all sorts of sophisticated tools (like OptimizeIt and TogetherJ), but I find that one of the tools I use the most is the *nix "find" utility combined with regular expressions. Sometimes, simplest is best.
If you had to analyze some data that lived in a relational database, would you look at all the records one at a time? Of course not -- you would execute a query that looks for troublesome records. I've been using the same technique against a body of source code. Curious about who is firing constructors on your boundary classes?
[Find all files named "*.java" from the current directory down and send each of these files into the grep command, which looks for the regular expression for constructor calls to any class with "Boundary" in the name.]
Or what about this:
[Find all non-Db Java files that fire constructors on DB classes. In other words, determine the coupling between the boundary classes and all other classes.]
This technique depends on consistent naming patterns for your files. If you can rely on this, you can query your code base for analysis.
One of my common themes is to avoid drowning in impressive but unsuitable tools. If you go rabbit hunting, you can use a shotgun, a bazooka, or an atomic bomb. One of these tools is better than the others. Similarly, using a simple but effective command line tool beats the expensive ones for some tasks.
Treat your code as data and apply the same techniques you use on data analysis on your code base.
If you had to analyze some data that lived in a relational database, would you look at all the records one at a time? Of course not -- you would execute a query that looks for troublesome records. I've been using the same technique against a body of source code. Curious about who is firing constructors on your boundary classes?
find -name "*.java" -exec grep -V "new .*Boundary.*(" {} \;
[Find all files named "*.java" from the current directory down and send each of these files into the grep command, which looks for the regular expression for constructor calls to any class with "Boundary" in the name.]
Or what about this:
find -name "*.java" -not -regex ".*Db\.java" -exec grep -H -n "new .*Db" {} \;
[Find all non-Db Java files that fire constructors on DB classes. In other words, determine the coupling between the boundary classes and all other classes.]
This technique depends on consistent naming patterns for your files. If you can rely on this, you can query your code base for analysis.
One of my common themes is to avoid drowning in impressive but unsuitable tools. If you go rabbit hunting, you can use a shotgun, a bazooka, or an atomic bomb. One of these tools is better than the others. Similarly, using a simple but effective command line tool beats the expensive ones for some tasks.
Treat your code as data and apply the same techniques you use on data analysis on your code base.
Sunday, January 23, 2005
Friends Don't Let Friends Use VSS
Andy (of the Pragramatic Programmers) writes in his blog today that he has heard that Microsoft's VSS is "Unsafe at Any Speed", based on other developer's experiences. Let me add some first person experience that validates this.
We used VSS for quite a while at DSW (for no good reasons). And, we have many clients who use it because it seems to be free (you get it with the big Microsoft box with an MSDN subscription). Thus, we have lots of experience with it. And it is absymal. The archives reliably spontaneously corrupt themselves when they reach about 2 Gb. When this happens, you always lose some data (of varying amounts). That's part of the entertainment of using VSS: "Gee, the repository is corrupt again -- I wonder what has entropied into the universe at large this time?"
My advice if you are using VSS or thinking about using it is
If you want a straigthforward, easy to use (once you understand its metaphors), solid, stable, genuinely free version control system, use Subversion. We have been using it for most projects for several months now and couldn't be happier. In fact, I recently set up a repository at home, tunneled through my router, so I can get to my personal repository anywhere. I couldn't be happier with it. The Pragmatic Programmer's series is coming out with a best practices book on Subversion which should be the last piece of the puzzle for everyone to start using it. It Just Works.
We used VSS for quite a while at DSW (for no good reasons). And, we have many clients who use it because it seems to be free (you get it with the big Microsoft box with an MSDN subscription). Thus, we have lots of experience with it. And it is absymal. The archives reliably spontaneously corrupt themselves when they reach about 2 Gb. When this happens, you always lose some data (of varying amounts). That's part of the entertainment of using VSS: "Gee, the repository is corrupt again -- I wonder what has entropied into the universe at large this time?"
My advice if you are using VSS or thinking about using it is
- don't use it
- really don't use it
- keep your repositories below 2 Gb
- didn't I tell you not to use it?
If you want a straigthforward, easy to use (once you understand its metaphors), solid, stable, genuinely free version control system, use Subversion. We have been using it for most projects for several months now and couldn't be happier. In fact, I recently set up a repository at home, tunneled through my router, so I can get to my personal repository anywhere. I couldn't be happier with it. The Pragmatic Programmer's series is coming out with a best practices book on Subversion which should be the last piece of the puzzle for everyone to start using it. It Just Works.
Wednesday, January 19, 2005
The High Price of High Coupling
I read an interesting quote today in the latest Newsweek (January 14th issue, page 14). In the article "A Fox in Bill's Henhouse", Bill Gates is quoted as saying to the author last October: "Explorer is going to be the primary browser used on Windows, and for anyone to suggest otherwise is just irresponsible".
Irresponsible. What an interesting choice of words, given that Internet Explorer is such an abysmal piece of software. I generally try to avoid militancy on software and tools, because, after all, they are just tools. However, at some point, I think that geeks must start weaning their friends off this particular tool. Would you let your friends and family use a bank that has a security record as stellar as IE on Windows? Most of my non-technical friends and family don't understand what a browser is -- they just think that the way to get to the Internet is click on the blue "e". I've started taking the time to explain to them that they have a choice and that they should stop using the dangerous choice.
What really galls me is the clear choice of high-coupling as a business decision by Microsoft. Software developers know that high coupling is a bad idea for lots of reasons. The developers at Microsoft are smart guys, so the only conclusion I can make is that the decision to snake IE code throughout the operating system was a business decision. Thus, you cannot actually uninstall IE even if you try. If you type a URI in the address bar in Explorer, it will launch (in place) an IE window to view the site. How often have you crashed IE and therefore the entire shell? Even if IE were as secure as Fort Knox, the high coupling to the underlying OS would still be bad. Given its myriad security problems, it compromises the integrity of the entire operating system, and there is nothing you can do to fix it except wait for the steady stream of service packs and new vulnerabilities.
Of course, other software has security problems, including other browsers and operating systems. It is the deadly embrace between Windows and IE that makes it such a dangerous combination. This is the high price of allowing a business decision (i.e., IE cannot be removed from Windows to allow a competing browser) to create a compromised architecture for the whole operating system.
Irresponsible. What an interesting choice of words, given that Internet Explorer is such an abysmal piece of software. I generally try to avoid militancy on software and tools, because, after all, they are just tools. However, at some point, I think that geeks must start weaning their friends off this particular tool. Would you let your friends and family use a bank that has a security record as stellar as IE on Windows? Most of my non-technical friends and family don't understand what a browser is -- they just think that the way to get to the Internet is click on the blue "e". I've started taking the time to explain to them that they have a choice and that they should stop using the dangerous choice.
What really galls me is the clear choice of high-coupling as a business decision by Microsoft. Software developers know that high coupling is a bad idea for lots of reasons. The developers at Microsoft are smart guys, so the only conclusion I can make is that the decision to snake IE code throughout the operating system was a business decision. Thus, you cannot actually uninstall IE even if you try. If you type a URI in the address bar in Explorer, it will launch (in place) an IE window to view the site. How often have you crashed IE and therefore the entire shell? Even if IE were as secure as Fort Knox, the high coupling to the underlying OS would still be bad. Given its myriad security problems, it compromises the integrity of the entire operating system, and there is nothing you can do to fix it except wait for the steady stream of service packs and new vulnerabilities.
Of course, other software has security problems, including other browsers and operating systems. It is the deadly embrace between Windows and IE that makes it such a dangerous combination. This is the high price of allowing a business decision (i.e., IE cannot be removed from Windows to allow a competing browser) to create a compromised architecture for the whole operating system.
Monday, January 17, 2005
Suspicious Training Locations
How do you know that you've ended up at a bad training location?
The classroom was on the 3rd floor. Riding the elevator twice a day made me very cognizant of who was breathing on me!
The classroom was on the 3rd floor. Riding the elevator twice a day made me very cognizant of who was breathing on me!
Thursday, January 13, 2005
Perfect Numbers
One of the topics I must teach from time to time is how to use JBuilder to build EJB's. This isn't a class on EJB, but rather how JBuilder helps you build them. The problem that arises is how to create an exercise for the students that doesn't rely on specific infrastructure (like a particular database server, network details, etc.). Recently, I found a fun topic.
According to ancient Greek numerology, every number may be clasified as deficient, abundant, or perfect. These classifications are based on the sum of the factors (excluding the number itself). Thus, 9 is deficient (1+3 = 4 < 9), 12 is abundant (1+2+3+4+6 = 16 > 12), and 6 is perfect (1+2+3 = 6 = 6). The perfect numbers are the interesting ones. The exercise is to write an application where the user provides a seed number, and the application finds the next perfect number. Here is a list of the first 8 perfect numbers:
What's nice about this exercise is that it is a nice distraction from the boring plumbing-type coding required to get the application working. This happens several days into the class, so it provides a great outlet. Inevitably, students start doing research and get caught up in this topic. There is a great entry that describes the origins of perfect numbers on the Wikipedia site.
As much as I'd like to take credit for this, it came from an exercise in my first Pascal programming class. Dr. Head had us create lists of numbers that were perfect. On the Apple ][e, finding 496 took about 5 minutes. A simple, non-optimzed Java console application finds the first 4 almost instantly, and takes about 20 minutes to find the 5th. This is always a fun topic.
According to ancient Greek numerology, every number may be clasified as deficient, abundant, or perfect. These classifications are based on the sum of the factors (excluding the number itself). Thus, 9 is deficient (1+3 = 4 < 9), 12 is abundant (1+2+3+4+6 = 16 > 12), and 6 is perfect (1+2+3 = 6 = 6). The perfect numbers are the interesting ones. The exercise is to write an application where the user provides a seed number, and the application finds the next perfect number. Here is a list of the first 8 perfect numbers:
- 6
- 28
- 496
- 8,128
- 33,550,336
- 8,589,869,056
- 137,438,691,328
- 2,305,843,008,139,952,128
What's nice about this exercise is that it is a nice distraction from the boring plumbing-type coding required to get the application working. This happens several days into the class, so it provides a great outlet. Inevitably, students start doing research and get caught up in this topic. There is a great entry that describes the origins of perfect numbers on the Wikipedia site.
As much as I'd like to take credit for this, it came from an exercise in my first Pascal programming class. Dr. Head had us create lists of numbers that were perfect. On the Apple ][e, finding 496 took about 5 minutes. A simple, non-optimzed Java console application finds the first 4 almost instantly, and takes about 20 minutes to find the 5th. This is always a fun topic.
Subscribe to:
Posts (Atom)
