Tuesday, September 30, 2003
The Guy Responsible For Ctrl-Alt-Del
According to this article, the Ctrl-Alt-Del key sequence (aka the three finger salute) was invented by David J. Bradley as a way to reset early PCs without turning them off. There's a video clip with Bradley explaining how he "invented [Ctrl-Alt-Del] but Bill Gates made it famous". BillG's reaction is priceless. (Via SlashDot)
Lua
There are a lot of programming languages floating around but only a small percentage are in active use. Here's a programming language I hadn't heard of before that appears to have a growing user community. It's called Lua. The main aim with Lua is easy extensibility.
The language core is implemented in standard C and has been ported to lots of platforms. There's a draft of a book on Lua. I'm going to add Lua to the (growing) list of languages I want to try out.Lua is a powerful light-weight programming language designed for extending applications. Lua is also frequently used as a general-purpose, stand-alone language
GPS will pinpoint Coke prize winners
No need to worry about being followed by black helicopters anymore. Your soda can is giving away your location. But don't worry, it's just so Coca-Cola can track you down to give you the keys to your new Hummer H2. According to this article, Coca-Cola is planning a promotion next summer to use satellites to find U.S. buyers who happen to purchase special cans of Coke products. (Via BoingBoing)
Monday, September 29, 2003
Measure The Speed of Light With Chocolate and a Microwave
I haven't "tried this at home" so I'm not sure of the veracity of this approach to measuring the speed of light. It sounds like a something from the old MacGyver TV show: "A desperate physics student goes off the deep end when his science competition entry goes awry. Armed only with a Microwave oven and a chocolate bar, MacGyver must help the student determine the speed of light and win back his father's love.". 
Maven
Maven is an open-source Java project management and project comprehension tool. Maven 1.0 should be coming out soon -- the first release candidate was just announced. Looks pretty cool. I can definitely see a need for something like this. Here's an example report generated by Maven on 1.0 RC1 code. Note: this Maven is unrelated to Maven Networks.
@deprecated and backward compatibility
The @deprecated JavaDoc comment means a method or class is still usable, but you should not use it. It will gradually be phased out. Usually it means that a new method or class has been added to do the same thing. But exactly when is the old method or class removed, if ever? As it currently stands, @deprecated is an "idle threat". There's no timetable that support will ever be dropped. If a method or class was actually removed and code broke would that be okay? Would it be sufficient to say: "We told you back in JDK 1.1 that this was going to go away. You were sufficiently warned". That's impractical. Breaking running code is rarely, if ever, acceptable. So what happens? The JDK libraries get bigger over time and nothing ever goes away. That's the price we pay for backwards compatibility. At least @deprecated can trigger a warning that, for new code, you should consider other options but if the deprecation warning is in a sea of hundreds of other deprecation warnings, it's unlikely that you'll even notice it. Sigh.
Note: there's a discussion on this topic on the Sun Developer Network Forum.
Note: there's a discussion on this topic on the Sun Developer Network Forum.
Sunday, September 28, 2003
Readable Java 1.5
Not everyone is happy with the readability of Sun's proposed syntax for new features in Java 1.5. Good thing I only suggested adding named and optional parameters and didn't recommend a syntax. It's easy to ask for the features, much harder to get everyone to be happy with the syntax changes.
Is It High Time To Get Rid Of Classes?
Carlos Perez asks whether it's time to get rid of classes in reaction to an article written by James Coplien.
In Coplien's article he mentions prototype-based languages (also called delegation-based languages) as an alternative. Guess what? If you're doing web development you've probably already using one -- JavaScript. The NewtonScript language which was used to develop software for the Apple Newton MessagePad was also a prototype-based language. Even James Gosling, the father of Java, has mentioned that if he had it to do over again, he might design Java with a delegation model.
I have to admit that classes sometimes make me queasy. Using interfaces as the external exposed view with factories has been a successful design alternative but there's only so much you can do in a class-based language. I haven't considered how interfaces play in a prototype-based world but I believe that they fit into that model. The funny thing is that prototype-based systems can be used to construct class-based systems. People do this all of the time in JavaScript. The solution can't be to throw the baby out with the bath water -- we've got too much invested in what we've done in class-based languages. And we shouldn't just dump class-based languages because they don't always fit well. And besides, we don't have an adequate replacement yet -- although I know a developer who says that if we all just wrote everything in JavaScript we'd be a lot happier
In Coplien's article he mentions prototype-based languages (also called delegation-based languages) as an alternative. Guess what? If you're doing web development you've probably already using one -- JavaScript. The NewtonScript language which was used to develop software for the Apple Newton MessagePad was also a prototype-based language. Even James Gosling, the father of Java, has mentioned that if he had it to do over again, he might design Java with a delegation model.
I have to admit that classes sometimes make me queasy. Using interfaces as the external exposed view with factories has been a successful design alternative but there's only so much you can do in a class-based language. I haven't considered how interfaces play in a prototype-based world but I believe that they fit into that model. The funny thing is that prototype-based systems can be used to construct class-based systems. People do this all of the time in JavaScript. The solution can't be to throw the baby out with the bath water -- we've got too much invested in what we've done in class-based languages. And we shouldn't just dump class-based languages because they don't always fit well. And besides, we don't have an adequate replacement yet -- although I know a developer who says that if we all just wrote everything in JavaScript we'd be a lot happier
Objective-C
Objective-C has been getting attention in the past few years because the Cocoa application environment on Mac OS X is written in it. Cocoa is the descendant of the NeXTStep AppKit environment.
The Objective-C language was developed by PPI in the 1980s. It added Smalltalk-like object-oriented extensions to ANSI C -- a more conservative approach than C++. Objective-C has full metaclasses like Smalltalk and all method invocations are dynamic. The PPI compiler generated ANSI C and included a small runtime to do method dispatching. NeXT licensed the language from PPI and extended GCC to support Objective-C natively. In 1993, NeXT got out of the hardware business and NeXTStep morphed into OpenStep which was supported on a variety of different platforms including Solaris. In 1997, Apple acquired NeXT and the NeXT AppKit was transformed into Cocoa.
But what's cool about Objective-C? The main distinction is that, unlike C++, types are preserved at runtime and method calls use dynamic binding. The Cocoa runtime needs this type of dynamism to work. Also, Objective-C, like Java, has a single-inheritance hierarchy but supports a mechanism called protocols which allow classes to define the interfaces that they support. It's not a big surprise that Cocoa supports both Objective-C and Java as development languages. In fact, the folks at Apple pushed for Java to get type introspection features like those supported in Objective-C in order for Java to be a useful language for developing Cocoa applications.
The Objective-C language is "good enough" for building dynamic applications. But if that was all that was there, it would have remained an intellectual curiosity. What really makes the language useful is the Cocoa environment itself. The NeXTStep AppKit heritage comes through (note that most of the class names use the prefix "NS" for NextStep). The NeXTStep AppKit was the nicest GUI application framework I've used. It did a great job of hiding complexity and was a natural "fit" for the language. Kudos to Apple for recognizing the value of this technology and keeping the AppKit and Objective-C alive.
The Objective-C language was developed by PPI in the 1980s. It added Smalltalk-like object-oriented extensions to ANSI C -- a more conservative approach than C++. Objective-C has full metaclasses like Smalltalk and all method invocations are dynamic. The PPI compiler generated ANSI C and included a small runtime to do method dispatching. NeXT licensed the language from PPI and extended GCC to support Objective-C natively. In 1993, NeXT got out of the hardware business and NeXTStep morphed into OpenStep which was supported on a variety of different platforms including Solaris. In 1997, Apple acquired NeXT and the NeXT AppKit was transformed into Cocoa.
But what's cool about Objective-C? The main distinction is that, unlike C++, types are preserved at runtime and method calls use dynamic binding. The Cocoa runtime needs this type of dynamism to work. Also, Objective-C, like Java, has a single-inheritance hierarchy but supports a mechanism called protocols which allow classes to define the interfaces that they support. It's not a big surprise that Cocoa supports both Objective-C and Java as development languages. In fact, the folks at Apple pushed for Java to get type introspection features like those supported in Objective-C in order for Java to be a useful language for developing Cocoa applications.
The Objective-C language is "good enough" for building dynamic applications. But if that was all that was there, it would have remained an intellectual curiosity. What really makes the language useful is the Cocoa environment itself. The NeXTStep AppKit heritage comes through (note that most of the class names use the prefix "NS" for NextStep). The NeXTStep AppKit was the nicest GUI application framework I've used. It did a great job of hiding complexity and was a natural "fit" for the language. Kudos to Apple for recognizing the value of this technology and keeping the AppKit and Objective-C alive.
Should Java support named and optional arguments?
Java 1.5 will extend the language with a number of nice features such as generics, autoboxing, enums, etc. Unfortunately, named and optional arguments aren't on the list. That's too bad. I believe that they would make the language easier to use and would not substantially increase compiler or runtime complexity.
Named (or keyword) arguments are supported in quite a few programming languages. They address shortcomings of so-called positional arguments. It's easiest to show the distinction with an example. First positional arguments in Java:
Named arguments are especially useful when combined with optional arguments (e.g. arguments with default values). C++ has support for optional arguments but not named arguments making them less useful. When a language only support optional arguments, and you want to specify the value of the second optional argument of a method that takes two optional arguments, you have to specify values for both optional arguments. When you combine named and optional arguments, you would only need to specify the second one.
Named and optional arguments are syntactic sugar. That's one reason I think they would be easy to add to the language. Maybe I should petition Sun to get them into Java 1.6 In the meantime, we can simulate these features. Optional arguments can be simulated by overloading a method with two different signatures. For example:
Named arguments can be simulated somewhat but they're a little trickier. The simplest technique is to create a value object to hold the arguments rather than pass them explicitly. Not as slick but the net effect can be similar. Another approach would be to use a HashMap as a general argument container. The downsides to this approach are that you lose type safety and you'd need to document the keys and types of the expected values. Pretty messy.
So what do you think? Should Java support named and optional method arguments?
Named (or keyword) arguments are supported in quite a few programming languages. They address shortcomings of so-called positional arguments. It's easiest to show the distinction with an example. First positional arguments in Java:
widget.handleIt( 1, 2, true, false );Next, named arguments in a hypothetical extension to Java:
widget.handleIt( x: 1, y: 2, show: true, enable: false );Because the arguments are no longer positional, this invocation would be legal as well:
widget.handleIt( show: true, enable: false, x: 1, y: 2, );Lots of programming languages support named arguments (e.g. Python, Ruby, Lisp). Even C# supports named arguments. But not Java.
Named arguments are especially useful when combined with optional arguments (e.g. arguments with default values). C++ has support for optional arguments but not named arguments making them less useful. When a language only support optional arguments, and you want to specify the value of the second optional argument of a method that takes two optional arguments, you have to specify values for both optional arguments. When you combine named and optional arguments, you would only need to specify the second one.
Named and optional arguments are syntactic sugar. That's one reason I think they would be easy to add to the language. Maybe I should petition Sun to get them into Java 1.6
In the meantime, we can simulate these features. Optional arguments can be simulated by overloading a method with two different signatures. For example:public void aMethod(int value) {This works okay but when you have a lot of arguments the number of methods can grow to a ridiculous number. And each calls the other in turn, filling the callstack with noise.
aMethod(value, true);
}
public void aMethod(int value, boolean flag) {
// do something useful
}
Named arguments can be simulated somewhat but they're a little trickier. The simplest technique is to create a value object to hold the arguments rather than pass them explicitly. Not as slick but the net effect can be similar. Another approach would be to use a HashMap as a general argument container. The downsides to this approach are that you lose type safety and you'd need to document the keys and types of the expected values. Pretty messy.
So what do you think? Should Java support named and optional method arguments?
Saturday, September 27, 2003
Blog spammers
Comment systems on most blogs have wide open access. Anyone can add a comment; no authentication needed. It looks like a spammer has decided to exploit this by spamming blogs with one of those *cough* *cough* body part enlargement offers. Such weasels.
Friday, September 26, 2003
Smalltalk report archive
This is cool. An archive of the Smalltalk Report is available online here.
When I attended the first OOPSLA conference in 1986, most of the papers were on Smalltalk. Lots of companies (including IBM) got on the Smalltalk bandwagon in a big way. Commercial Smalltalk environments were available from ParcPlace Systems, Digitalk, IBM, etc. on everything from DOS to Macintoshes to Unix workstations. Other OOP languages, especially C++ came into their own a few years later.
Smalltalk started a slow decline in usage through the mid 90s, especially when Java came along. It could be argued that Smalltalk had a longer and more viable commercial life than other dynamic languages such as Lisp but it never "broke through" as a general-purpose language. A revival of interest in Smalltalk seems to be happening, especially as a result of Squeak programming environment. If you're looking to read about Smalltalk, the best place to start is with the classic book Smalltalk-80: The Language. This book on Squeak is pretty good as well. (Via . Lambda the Ultimate)
When I attended the first OOPSLA conference in 1986, most of the papers were on Smalltalk. Lots of companies (including IBM) got on the Smalltalk bandwagon in a big way. Commercial Smalltalk environments were available from ParcPlace Systems, Digitalk, IBM, etc. on everything from DOS to Macintoshes to Unix workstations. Other OOP languages, especially C++ came into their own a few years later.
Smalltalk started a slow decline in usage through the mid 90s, especially when Java came along. It could be argued that Smalltalk had a longer and more viable commercial life than other dynamic languages such as Lisp but it never "broke through" as a general-purpose language. A revival of interest in Smalltalk seems to be happening, especially as a result of Squeak programming environment. If you're looking to read about Smalltalk, the best place to start is with the classic book Smalltalk-80: The Language. This book on Squeak is pretty good as well. (Via . Lambda the Ultimate)
Escape from... High Tech
Jeff Anderholm was the product manager for Lotus Improv. When I joined the project we had 25 people - the right size to show the Birthday Paradox in action (the odds of two people in a group having the same birthday exceeds 50% in a group of 23). Not only do Jeff and I share the same birthday, we were born in the same year as well. Jeff has made a career change that a lot of us consider from time to time. He bailed out of high tech. He and his wife bought an Inn in Bar Harbor, Maine and are becoming innkeepers.
Vanity domain names
I wanted to own a domain even before I knew what I would do with it. Ownership can be like that. I registered bobcongdon.com a few years ago after discovering that all of the common top level domains for my surname had already been taken. I decided that I would own my full name in the .com domain. Fortunately my name is not particularly common so no one else had already grabbed it. I don't like the fact that domain registration is basically a "land grab" and there's little to prevent someone else from registering thousands of domain names in speculation that someone might want them in the future.
I've registered a few other domains for other purposes. Domains definitely can come in handy for web site and email redirection. The latter has been especially useful for giving out stable email addresses and setting up group email aliases.
I've registered a few other domains for other purposes. Domains definitely can come in handy for web site and email redirection. The latter has been especially useful for giving out stable email addresses and setting up group email aliases.
DB2 SQL Cookbook
Relational databases are conceptually simple but complex in detail. SQL is an industry standard but you need to be aware of vendor-specific details. If you're working with DB2 on Windows or Unix platforms you should download a copy of Graeme Birchall's DB2 SQL cookbook. The latest version covers DB2 UDB 8.1. Note: a lot more information on DB2 including Redbooks, documentation, articles, etc. can be found here
Thursday, September 25, 2003
Early Adopters or Trend Surfers?
Good thought piece on Hacknot about how we (software developers) willingly embrace the latest software technologies but balk at using software development "best practices".
Lost In Translation
I saw Sophia Coppola's Lost In Translation this evening. It's a terrific film. Bill Murray plays an American movie star (Bob) in Tokyo to shoot a whiskey commercial. Scarlett Johansson plays Charlotte, the wife of a workaholic photographer also in Tokyo. Bob and Charlotte cross paths in the bar of the hotel they both are staying in. They are both sad, lonely characters, lost in a strange place. There are some funny scenes but this is not a comedy. The relationship between the two characters evolves slowly, and not in the way you might expect.
By the way, if you go see the film, the NY Times has a translation of what the Japanese director is saying to Bill Murray's character.
By the way, if you go see the film, the NY Times has a translation of what the Japanese director is saying to Bill Murray's character.
The Great Boston Molasses Flood of 1919
Anyone who grew up or has lived in the Boston area has heard something about the "molasses flood" in Boston's North End. It sounds like an urban legend but it really happened. According to this article , a tank filled with over 2 million gallons of molasses ruptured, killing 21 people. A book about the disaster, Dark Tide : The Great Boston Molasses Flood of 1919 has just been published.
Cheeseburger Fries
I had my cholesterol levels checked recently. Everything is good, thanks for asking I don't eat meat (a personal choice). Even if I did, here's something that I'd stay away from. To quote Homer Simpson:"You mean grease is money?!? Woo hoo! my arteries are filled with yellow gold!"
I don't eat meat (a personal choice). Even if I did, here's something that I'd stay away from. To quote Homer Simpson:"You mean grease is money?!? Woo hoo! my arteries are filled with yellow gold!"
Google Search by Location
Google has a new "search by location" feature. You should try it out. Note: according to the FAQ it's still a "work in progress" and so it may be down from time to time.
Wednesday, September 24, 2003
24 x 80
Back when dinosaurs roamed the earth, the 24 lines by 80 column "dumb" terminal was how most people interacted computers. It was crappy but compared to punch cards and teletypes, it was "interactive" computing. But why did terminals have 80 columns? Because a standard IBM punch card had 80 columns. Then why 24 lines? I'm not as sure of this but I believe it was related to the aspect ratio of the displays used in terminals. Video displays capable of even this resolution were quite expensive. A DEC VT220 cost something like $2K brand new. Of course, around the same time a 1200 baud analog modem cost about $700 (!).
vt100.net is a web site dedicated dumb terminals produced by DEC including, of course, the classic VT100. There's also information on a variety of other terminal vendors there as well. (Inspired by Ned's discussion on Proggy fonts)
vt100.net is a web site dedicated dumb terminals produced by DEC including, of course, the classic VT100. There's also information on a variety of other terminal vendors there as well. (Inspired by Ned's discussion on Proggy fonts)
You can call me Ray, you can call me Jay...
Comedian Bill Saluga had a bit that he did on TV variety shows. If you watched television in the late 70s you'll remember it. A zoot-suited character named Raymond J. Johnson Jr. would appear. If you called him "Johnson," he launched into a tirade:
I was reminded of this bit when I met someone the other day. He introduced himself as his first and middle initial (e.g. RJ). As someone who prefers Bob over Robert I can appreciate the need to clearly state a preference up front. When someone insists on calling me Robert after I've told them that my name is Bob I can get a little irritated. Our preferences can change over time. My sister was known as Kathy growing up and requested that we start calling her Kate when she was in her 20s. Sometimes we have different names for different contexts. I known several people who are known by a diminuitive to parents, siblings and old friends (e.g. Joey) who would cringe if a co-worker used the same name.
It was one of those routines that was funny once or twice but became tiresome when it was trotted out for the 100th time to get a cheap laugh. Also, I'd imagine, it was a tough way for Saluga to make a living. Squeeze in as many appearances as possible before your agent stops getting calls.Ahh, ya doesn't has to call me Johnson! You can call me Ray, or you can call me Jay, or you can call me Johnny or you can call me Sonny, or you can call me RayJay, or you can call me RJ... but ya doesn't hafta call me Johnson
I was reminded of this bit when I met someone the other day. He introduced himself as his first and middle initial (e.g. RJ). As someone who prefers Bob over Robert I can appreciate the need to clearly state a preference up front. When someone insists on calling me Robert after I've told them that my name is Bob I can get a little irritated. Our preferences can change over time. My sister was known as Kathy growing up and requested that we start calling her Kate when she was in her 20s. Sometimes we have different names for different contexts. I known several people who are known by a diminuitive to parents, siblings and old friends (e.g. Joey) who would cringe if a co-worker used the same name.
Tuesday, September 23, 2003
Oakum
My first project at Lotus was a multi-dimensional spreadsheet called Lotus Improv. The first release didn't include a programming environment (e.g. anything like Office VBA) but one was in the works. The language for this environment was called "Oakum". The main developer was enamored with building wooden ships and "oakum" is a material used to caulk the seams in ships (kind of like glue).
Oakum's syntax was similar to HyperTalk / HyperScript which looks less like a traditional programming language; more chatty like Logo. It was pretty slick. Unfortunately for Oakum, Lotus decided that it would be better to standardize on a single embedded programming language / IDE for all desktop products. That language was LotusScript which first shipped as part of Improv 2.0 for Windows. LotusScript eventually shipped with all Lotus products including Notes/Domino. It was a better business decision than going with Oakum since LotusScript is relatively easy to learn if you already knew Visual Basic. But I thought Oakum was a such cool name for a scripting language.
By the way, the original name for the Java programming was Oak (so called because there was an oak tree outside James Gosling's office window). Oak came a few years after Oakum's conception, development and demise. They're unrelated except for having similar names.
Oakum's syntax was similar to HyperTalk / HyperScript which looks less like a traditional programming language; more chatty like Logo. It was pretty slick. Unfortunately for Oakum, Lotus decided that it would be better to standardize on a single embedded programming language / IDE for all desktop products. That language was LotusScript which first shipped as part of Improv 2.0 for Windows. LotusScript eventually shipped with all Lotus products including Notes/Domino. It was a better business decision than going with Oakum since LotusScript is relatively easy to learn if you already knew Visual Basic. But I thought Oakum was a such cool name for a scripting language.
By the way, the original name for the Java programming was Oak (so called because there was an oak tree outside James Gosling's office window). Oak came a few years after Oakum's conception, development and demise. They're unrelated except for having similar names.
Mainsail and garbage collection
I was thinking about a garbage collector issue earlier today and was reminded of the Mainsail programming language. When I worked at Cognition, we wrote a Mechanical CAE product in Mainsail. It looks like an object-oriented dialect of Pascal but is a bit older -- it's in the ALGOL / Simula family. Mainsail has a number of cool features, dynamic loading, modules, garbage collection, dynamic strings, etc. and it's extremely portable. The unusual thing about Mainsail garbage collection is that it's a hybrid. You can let the GC kick in and reclaim space or you can call delete on an object that you no longer need. It was beneficial to do explicit deletion since allowed us to reduce the frequency of GC. But, if you used delete you had the same downside of a non-GC language. If you called delete you needed to make sure that you had no other references to the object, otherwise... Crash!. I can't think of another language that has this type of hybrid approach to memory reclamation.
Monday, September 22, 2003
Maven Networks
Maven Networks released its Maven Media System today. A few friends and ex-coworkers from Lotus and Iris are working at Maven. I wish them well. As with any startup venture it's a crap shoot but Maven's software looks pretty cool. Jeremy Allaire is on their Board of Advisors and has written his impressions on his weblog
Sunday, September 21, 2003
Superpowers and The Segway
I listened to an old episode of This American Life the other day. It was the one about Superpowers. In one segment they asked people whether they'd rather have the power of flight or invisibility. The answers were interesting. Some people gave it a lot of thought and tried to interpret what it meant to pick one or the other. Not a single person said anything about wanting to "fight crime" with their superpower. Personally, I wouldn't pick flight. It sounds cool but I don't like to call attention to myself. I'd definitely pick invisibility. Yeah, it's kind of a sneaky power but I'd use it only "for good". I promise.
On a related note, while driving through Winchester Center earlier today, I saw someone "driving" down the street on a Segway. It was a beautiful sunny day and he looked happy but everyone was gawking at him. Despite the fact that it only goes 5-10 mph, there's a definite coolness to the Segway. But I don't think I could take the gawkers. So, yes I'd definitely pick invisibility over the power of flight.
On a related note, while driving through Winchester Center earlier today, I saw someone "driving" down the street on a Segway. It was a beautiful sunny day and he looked happy but everyone was gawking at him. Despite the fact that it only goes 5-10 mph, there's a definite coolness to the Segway. But I don't think I could take the gawkers. So, yes I'd definitely pick invisibility over the power of flight.
Windows to Power ATMs in 2005
Several years ago I saw a technician working on an ATM. With the front cover removed I could see the screen inside displaying OS/2 Presentation Manager. It turns out that most ATMs today still run OS/2. That's going to change soon. According to this article on Wired News, by 2005 65 percent of bank ATMs will use a stripped-down version of Windows. Wow. Let's hope they strip out all of the "bad" parts
Refactoring Catalog
I was reading Ned's link to Martin Fowler's entry on Technical Debt. Great term. We incure "technical debt" all of the time -- sometimes the debt is short term and we recover quickly, other times we're saddled with crippling interest payments (bad design) and curse the short-sighted decisions made by our earlier self (or a predecessor).
I started reading the rest of Martin Fowler's blog. Good content and links including a updated version of the Refactoring Catalog from his book.
I started reading the rest of Martin Fowler's blog. Good content and links including a updated version of the Refactoring Catalog from his book.
Refactoring for everyone
Good article on using Eclipse's refactoring tools on IBM's developerWorks web site.
Robert Cringley has been ranting about refactoring in a couple recent articles:Eclipse provides a powerful set of automated refactorings that, among other things, let you rename Java elements, move classes and packages, create interfaces from concrete classes, turn nested classes into top-level classes, and extract a new method from sections of code in an old method. Becoming familiar with Eclipse's refactoring tools is a good way to improve your productivity. This survey of Eclipse's refactoring features, with examples, demonstrates how and why to use each.
Certainly the term "refactoring" has been overused. It should not be applied to arbitrary "code cleanup". Martin Fowler's response to Cringley is good and makes the distinction clear.Refactoring means monkeying with working code. If the program isn’t working, you don’t refactor it. Refactoring is supposed to be IMPROVING code, not fixing it. By definition, you only refactor code that is already working, which where I come from is scary. Working code is a valuable asset since it is hard to get right (at least for me) and takes time. Touching working code is always a risk and so there should be a darned good reason for doing it. Adding features, worthwhile refactoring, or bug fixing are all possible good reasons. Tinkering with code or cleaning it up is not.
Pete Lyons
Pete Lyons, a friend and co-worker, has been working on his blog for a while but hasn't told many people about it -- mostly just me . I've made a couple of links to it here and thought that I'd make an "official" announcement. Some folks may remember Pete from his work on the Domino Designer. Pete has broad technical interests and a great sense of humor. Plus he has a much cooler blog name than mine: DevelopingStorm. Check it out.
. I've made a couple of links to it here and thought that I'd make an "official" announcement. Some folks may remember Pete from his work on the Domino Designer. Pete has broad technical interests and a great sense of humor. Plus he has a much cooler blog name than mine: DevelopingStorm. Check it out.
Change your programming perspective
Sometimes it's healthy to change your perspective a bit. To give your brain a different spin on how the world works. A number of years ago I traveled to England on a business trip. I stayed for a month and rented a car to get around. My first experience driving on the left side of the road (from Heathrow Airport to Cambridge) was a little unnerving but I got the hang of it pretty quickly. I had to deal with a lot of smaller differences as well: traffic flow, navigating through roundabouts, understanding the traffic signs, etc. Occasionally there was a moment of panic when my brain tried to revert to American driving. In one case I was trying to quickly pull over to the side to let another car pass in a narrow street; in another I was pulling up to a toll booth to pay. Fortunately, I recovered before making a mistake. When I returned to Boston and got into my car and started to drive and thought "which side is it now?" but I was able to rely on my "muscle memory" of American driving without too much difficulty.
Programming languages can be good at changing your perspective too. If you've been coding in one language (e.g. C/C++ or Java) for a while, it's worth the trouble to learn another language. And not just to make yourself more "marketable". A different programming language can change the way you think about solving problems, especially when you embrace the new language's style and idioms.
Which language to pick? In some ways it doesn't matter as long as it's sufficiently different from what you use now. It helps to know someone else who's already fluent in the language (although with the web you can find language communities). A language that you might find useful for other things (e.g. a scripting language such as Perl or Python) might be a good choice. I'd also recommend trying one of the more "classic" languages such as Lisp or Smalltalk. Excellent open source / freeware environments exist for nearly any choice you make. For example there's an wonderful open source Smalltalk environment called Squeak that runs on just about any platform you can imagine.
So go ahead, change your programming perspective a bit.
Programming languages can be good at changing your perspective too. If you've been coding in one language (e.g. C/C++ or Java) for a while, it's worth the trouble to learn another language. And not just to make yourself more "marketable". A different programming language can change the way you think about solving problems, especially when you embrace the new language's style and idioms.
Which language to pick? In some ways it doesn't matter as long as it's sufficiently different from what you use now. It helps to know someone else who's already fluent in the language (although with the web you can find language communities). A language that you might find useful for other things (e.g. a scripting language such as Perl or Python) might be a good choice. I'd also recommend trying one of the more "classic" languages such as Lisp or Smalltalk. Excellent open source / freeware environments exist for nearly any choice you make. For example there's an wonderful open source Smalltalk environment called Squeak that runs on just about any platform you can imagine.
So go ahead, change your programming perspective a bit.
Saturday, September 20, 2003
Olympic Security English
Beijing has created a 252-page Olympic Security English textbook for their police to deal with foreigners during the 2008 Olympics. The book includes such useful English phrases as "Shut up, so we can finish our search".
Friday, September 19, 2003
Talk Like A Pirate Day
Today is Talk Like A Pirate Day Arrh!
RSS Feed
I added an RSS feed for this blog. This is experimental for now. Let me know if it works for you. 
The Google Vanity Search
Google now lists me first among all of the Bob Congdons in the universe. Take that Bob Congdon of Bob's Old Buildings and Connecticut State Representative Bob Congdon.
My fan club
I got some feedback in my blog comments from someone named "jen":
Clearly, not everyone is going to be interested in what I have to say. Jen may have followed the link from Bloglet which isn't just a list of geeky blogs. Oh well.this site really sucks and is boring..i found no helpful information
Thursday, September 18, 2003
Matchstick Men
Just saw Matchstick Men. I think I'm going to avoid movies with con artist / "one last heist" plotlines for now. Especially since they all seem to conclude with incredibly implausible "twist" endings. There have been a lot of these recently (e.g. The Score, Confidence, The Italian Job, etc). Matchstick Men has a good cast: Nicholas Cage, Sam Rockwell and especially Alison Lohman. And the first two-thirds of the film are enjoyable but I hated being led down the primrose path in the third act. My advice: go rent Adaptation and see Nicholas Cage in a much better movie.
Note: in this movie Matchstick Men is a term for con artists. I hadn't heard that usage before. The first thing that came to mind was the song Pictures of Matchstick Men which doesn't seem to be related. In fact, it's hard to tell what that song is about. Sounds like a bad acid trip...
Note: in this movie Matchstick Men is a term for con artists. I hadn't heard that usage before. The first thing that came to mind was the song Pictures of Matchstick Men which doesn't seem to be related. In fact, it's hard to tell what that song is about. Sounds like a bad acid trip...
Wednesday, September 17, 2003
Bloglet
I'm probably going overboard with blogging cruft on this page. I just set up this blog to work with Bloglet, an email subscription service for blogs. It uses XML-RPC under the covers and only works with certain blogging tools (including Blogger). If you'd rather get notified via email when new content shows up here, scroll to the bottom of the page, enter your email address and give it a try.
Who died and made you Elvis?
Ben Langhinrichs has a weblog entry with this wonderful title. The entry concerns how browsers and Notes/Domino handle HTML table rendering. I worked on the Domino web server from the beginning until R6. We wrestled with these issues all of the time. The choice of how to render something often boiled down to whether to generate HTML that looked similar to the Notes client or more in the spirit of what things commonly look like in a browser. Usually we chose to make things look more like Notes. That made developers who wanted to deploy Notes applications to the web happy; it made web-focused developers less happy.
Over time, it became more and more difficult to the change the way Notes documents were rendered as HTML. Designers and developers had become dependent on each detail of how our CD record to HTML translation behaved. Whether we liked it or not, we were painting ourselves into a corner. Sometimes it was possible to "find fresh unpainted floor" by inventing new concepts but existing behavior had to be preserved.
The Elvis comment is appropriate to the developers of the Domino engine. We were making King like decisions all along. How dare we? Well, we had no idea at the time. We would likely make some different choices if we were writing one from scratch now. But would the choices we make now be the right ones in five years? Who knows. It's not easy being the King sometimes.
Over time, it became more and more difficult to the change the way Notes documents were rendered as HTML. Designers and developers had become dependent on each detail of how our CD record to HTML translation behaved. Whether we liked it or not, we were painting ourselves into a corner. Sometimes it was possible to "find fresh unpainted floor" by inventing new concepts but existing behavior had to be preserved.
The Elvis comment is appropriate to the developers of the Domino engine. We were making King like decisions all along. How dare we? Well, we had no idea at the time. We would likely make some different choices if we were writing one from scratch now. But would the choices we make now be the right ones in five years? Who knows. It's not easy being the King sometimes.
Brozilla is staring at you
While cleaning out some old email, I found a reference to Brozilla, a totem we used at Blue Ripple. It was a plastic Godzilla toy. If you checked in code that screwed up the build, Brozilla was put on your desk as a "scarlet letter" so you wouldn't do it again. You got stuck with Brozilla until the next person screwed up. This was inspired by something we had done at Applicon years ago. An coconut carved to look like a gorilla head was hung outside your cubicle if you broke the build.
In both cases, it was all in good fun but I have to admit that the last time I got Brozilla on my desk I was pissed. I had just worked on some new feature, carefully checked my changes multiple times and the build broke because of an overlooked classpath problem. I worked hard on the code and felt that getting Brozilla as a result was bogus. I vented by writing an email missive about how Brozilla seemed to be against the spirit of working as a team (or something like that) and that I was going to keep Brozilla and not pass it along again. Yeah, it was just me venting. I rarely do that via email. I calmed down and Brozilla got passed around for few more months until Blue Ripple went under. Brozilla lives on as its own web site. You can see our obscure piece of failed Dot Com history here. (Btw, I think Brozilla is standing on a copy of our Beta Release plans!).
I currently work on a much larger software project. Builds break on a regular basis. We don't have a Brozilla equivalent - it would be pretty difficult to pass around anyway since w
In both cases, it was all in good fun but I have to admit that the last time I got Brozilla on my desk I was pissed. I had just worked on some new feature, carefully checked my changes multiple times and the build broke because of an overlooked classpath problem. I worked hard on the code and felt that getting Brozilla as a result was bogus. I vented by writing an email missive about how Brozilla seemed to be against the spirit of working as a team (or something like that) and that I was going to keep Brozilla and not pass it along again. Yeah, it was just me venting. I rarely do that via email. I calmed down and Brozilla got passed around for few more months until Blue Ripple went under. Brozilla lives on as its own web site. You can see our obscure piece of failed Dot Com history here. (Btw, I think Brozilla is standing on a copy of our Beta Release plans!).
I currently work on a much larger software project. Builds break on a regular basis. We don't have a Brozilla equivalent - it would be pretty difficult to pass around anyway since w