Rodney Waldhoff: Bookmarks

some bookmarks

Wed, 19 Nov 2003 17:14:23 GMT

Laurent Bossavit: From blog to print
PLEAC, the Programming Language Examples Alike Cookbook, translates the Perl Cookbook into a variety of programming langugaes.
Jeremy Zawodny: CVS Commit + Weblog = Changeblog

The impotence of functional programming (by Sjoerd Visscher)

Wed, 12 Nov 2003 01:12:06 GMT

Sjoerd Visscher writes:

"Take for example the function zip (or zip3, zip4, exponential ugh-ness), a very popular function in f.e. Haskell. Firstly, if you have two lists, with values that go pairwise together, those values shouldn't have been apart in the first place. Secondly, what you end up with is a list of tuples. Values in a tuple always have more context than just being together. All this information is lost."

[Via Sjoerd Visscher's weblog]

Beyond Blogging (by Elizabeth Lane Lawley)

Wed, 05 Nov 2003 18:05:57 GMT

Beyond Blogging by Elizabeth Lane Lawley is, as Sam writes, "an excellent look at the entire ecosystem of blogging".

[Via Sam Ruby]

The Selfish Class

Wed, 29 Oct 2003 22:08:02 GMT

Foote and Yoder's The Selfish Class provides a pattern language for software artifacts that survive.

[Via Ted Leung]

"Almost is a synonym for not in project management"

Wed, 03 Sep 2003 11:49:14 GMT

Almost is a synonym for not in project management.

- Scott Johnson via Ward's Wiki

Everything new is old again

Thu, 28 Aug 2003 01:26:57 GMT

Recently, Daniel, Ted, Andy and James all point to a post by Tom Lord over on the arch-users mailing list.

Tom's comments are made in the context of Red Hat's agreement to distribute Sun's JVM as part of their "Enterprise Linux" offering, a story that (although I regularly program in Java and I'm writing this post on Red Hat box) quite frankly I haven't been following at all. Much of what is interesting about Tom's comments may be a function of reading them outside of this context.

I find this a striking post, among other reasons, because it raises several distinct responses from me:

1. What are we building?

Tom suggests:

There has been a sort of tension in the commercial free operating system world:

(a) Are we building a free alternative to proprietary software?

or

(b) Are we building a commodity, $0-price OS component to lower the cost of proprietary applications?

For my part, this is a false dichotomy. In my open source efforts I'm not trying to do either of these, but rather to simply build something useful. Whether this something is an alternative or adjunct to proprietary software is incidental at best. For that matter, whether this something is truly innovative or just a more useful variation of a component that already exists isn't terribly significant either (although the utility of copying something that's already readily available is limited of course).

I wonder if this a symptomatic of differing perspectives between the BSD-style and GPL-style camps of open source development.

2. How do we build it?

Tom writes:

If the goal is (a), then we need an architect. We need to come up with an inexpensive-to-develop architecture that, nevertheless, contains viable solutions for the needs of our markets.
If the goal is (b), then we need an anti-architect. We need to come up with impossibly-expensive-to-fully-develop clone projects of proprietary software to draw off the energy of volunteer contributors who might otherwise undermine the value of the proprietary applications we expect to drive revenues for our distro.

Here option B is obviously a straw-man, so of course I'll follow option A. But while I agree we need "an inexpensive-to-develop architecture", and the word "architect" appears in my job title, I'll suggest a evolutionary approach is the best way to get there. Inexpensive-to-develop systems of any interesting size, let alone federations of such systems, are rarely "architected" in a traditional sense. What we need is an environment where diverse ideas are allowed to compete, cooperate and breed.

3. How hard is a Java implementation, really?

Running throughout Tom's post is the notion that a reasonably complete Java environment is simply too complicated to implement in an open source fashion:

For example, under (a), we would probably have to admit that trying to clone all the Java libraries _and_ build a competitive Java implementation is too expensive a course of action. While we might be perfectly happy to ship a low-end, incomplete implementation to help the low-end of the market, in the long run, we'd want to look for a more clever solution: something that can compete with Java and Java libraries on functionality, but that is cheaper to build in the first place (and cheaper and more effective to apply, of course).

[...]

[Y]ou can also make things expensive to develop by structuring them as an object oriented framework that you then spend zillions on filling out with subclasses, or by making really hard components (like finely tuned JIT compilers and garbage collectors) critical to implementations.

[...]

Some architectures, such as the Java environments and the view-tree/component-based GUI frameworks, are ideal for large proprietary software companies with large command-and-control armies of developers and QA practitioners. Those architectures are a terrible fit for the loose confederation of generally underresourced developers in the free and open source software world.

Putting aside questions of productivity and effectiveness, and the "enterprise" libraries for the moment, how hard is the core Java environment to implement, really? More difficult than a Lisp implementation, for example, but I suspect it's not substantially more difficult to implement than, say, a C implementation, and probably on par with something like Ruby.

4. Where are the alternative Java implementations then?

Well, there are several actually, although relatively few complete or robust ones. Why? Perhaps one compelling reason is that proprietary yet free (as in beer) Java runtime environments are readily available for most platforms.

Besides, who really wants another Java platform anyway...

5. "Yep, time to stop copying"

Like Daniel and Ted, I find the general call for innovation dead on:

For a long time, the right strategy for GNU was to build a basic unix replacement differentiated primarily by licensing. [...]
Well, that part's done and the strategy won.
[...]
If the goal is still "(a) build a free alternative to proprietary software", then a new strategy is called for: competition on software architecture, not just licensing.

Here Tom and I are in violent agreement. If I were building an open source compiler and/or language-platform, I'd certainly think twice about doing it on Sun's plantation--not because it's too hard; in part (as before) because the utility of copying something that's already readily available is limited; but mostly because I think you could construct more useful environments.

It's worth applying this, independently, to the "enterprise libraries" I set aside earlier. Are J2EE implementations like Apache Geronimo or JBoss building something "useful" or a "$0-price OS component to lower the cost of proprietary applications"? From my perspective, I've found some pieces of the J2EE suite to be quite useful, and others seem to fit Tom's "proprietary vendor" strategy.

6. Except when it isn't

It's interesting to observe how quickly the arch-users thread evolves from "we need a new architecture" to "we need a Lisp platform". (It's doubly interesting to note how often that seems to be the case.) And perhaps that really is what we need. But there's a big difference between "time to stop copying" and "time to stop copying Java".

(Actually, although I think one could do much better than to copy Java, you could also do much worse. It would be naive to think that Java's success is purely coincidental or purely the result of marketing muscle. They must be doing something right.)

More generally, it would be naive to think that what we need is innovation for innovation's sake, and I think deciding we need to resurrect a 40 year old platform is evidence of this fact.

7. What are we building, revisited.

Tom writes:

Nowadays, the proprietary competition is about databases, and productivity apps, and browsers, and middleware layers. The software we're competing against is not like unix: it isn't simple; it wasn't built by a small number of people; it's a moving target. It isn't a tractable project to clone this proprietary software under different licensing.

This point is puzzling. Certainly we don't mean to assert that it is impossible to successfully build open source databases, web browsers, or middleware servers, do we? Do we assert it is a bad idea to do so?

While I certainly think we should look for innovative ways to solve the sorts of problems these projects do, it would be a mistake to believe that the existing approaches don't offer something of value simply because they have strong proprietary implementations as well--just as it would have been a mistake for the GNU project to reject a pipe-and-filter architecture simply because a strong implementation was once controlled by Bell Labs. I don't think it is tractable to create a wholly new software paradigm--one that doesn't contain variations of n-tier, database and web technologies--out of thin air. We need new ideas, but we need old ones too.

The Social Life of Paper

Fri, 22 Aug 2003 21:30:29 GMT

The Social Life of Paper: Looking for method in the mess, an essay by Malcolm Gladwell, is fascinating from a number of perspectives. [Via Jay Fienberg's iCite.net]

Don't ask yourself what the world needs...

Fri, 22 Aug 2003 18:29:53 GMT

Don't ask yourself what the world needs. Ask yourself what makes you come alive, and go do that, because what the world needs is people who have come alive.

An anonymous quote cited by Condredge Dole on Ward's Wiki.

David Byrne on PowerPoint

Tue, 19 Aug 2003 17:06:05 GMT

Via Wired, David Byrne on PowerPoint:

Having never used the program before, I found it limiting, inflexible, and biased, like most software. On top of that, PowerPoint makes hilariously bad-looking visuals. But that's a small price to pay for ease and utility. We live in a world where convenience beats quality every time. It was, for my purposes, perfect.

I began to see PowerPoint as a metaprogram, one that organizes and presents stuff created in other applications. Initially, I made presentations about presentations; they were almost completely without content. The content, I learned, was in the medium itself. I discovered that I could attach my photographs, short videos, scanned images, and music. What's more, the application can be made to run by itself -no one even needs to be at the podium. How fantastic!
Although I began by making fun of the medium, I soon realized I could actually create things that were beautiful. I could bend the program to my own whim and use it as an artistic agent. The pieces became like short films: Some were sweet, some were scary, and some were mysterioso. I discovered that even without text, I could make works that were "about" something, something beyond themselves, and that they could even have emotional resonance. What had I stumbled upon? Surely some techie or computer artist was already using this dumb program as an artistic medium. I couldn't really have this territory all to myself -or could I?

Reporting is Code Smell

Mon, 11 Aug 2003 18:47:10 GMT

Reporting is Code Smell. Six reasons why writing applications that mostly produce reports may indicate flaws in analysis and design.

Reporting is a code smell because:

It's an indicator of incomplete or vague user needs. Essentially, a request for a report means "Gather a bunch of data and show it to me nicely formatted". Fine, but what exactly do all the pretty rows and columns tell you? Discover the true "why" for the report, and the need for the report evaporates.

Reporting tools often cast domain objects in the role of dumb data containers. Instead of having useful business-oriented behavior, classes that otherwise would define suitable behaviors are diminished to just carrying around values from one location (usually an RDBMS) to another location, a piece of paper.

There is a certain implication that the reports, once defined and written, never change and will always be what is necessary. Stories of reports that continue for years being generated and sent to people who never use them or even know why they are getting them are not uncommon.

The typical reporting run, being a batch-and-queue process, can wreak havoc with the functioning an interactive system while the reporting is occurring. Reports against databases often do expensive table scans, killing performance for users doing transactional work. They exercise the object model in ways that are different enough from live transactional usage, and the tradeoffs between what's right for reporting and what's right for interactive are difficult to resolve.

The request for a report is often a sign of an implicit idea that the computer can only do "data processing", and that the real analysis can only be done by hand. While that is still true for many classes of problems, the ability of programmers and systems to simulate and analyse is well advanced.

Reports are often artifacts of times before the user interface hardware and software had reasonable formatting capabilities. Low-resolution screens and the limited ability of a screen print to a low-quality local printer, for example, compared to the capabilities of generating formatted output to a centralized quality line printer. With modern user interfaces and hardware, the information is often presentable on the visual, and if not, printing from the application in suitably formatted and high-quality manner is quite easy.

[via Artima Agile Buzz]

I'm not sure that's 100% accurate, but it's thought provoking.

Clover Plug-in for Eclipse (and NetBeans)

Fri, 08 Aug 2003 12:45:59 GMT

Matt Quail writes "We have just released (beta) an Eclipse plugin and a NetBeans plugin for Clover, allowing you to instrument your code and view coverage results all from with the those Java IDEs."

Haven't tried it yet, but the screenshots look like exactly what I was hoping for. Sweet.

Assorted Quickies

Sat, 02 Aug 2003 04:43:38 GMT

Whiteboard Photo cleans up digital photographs of things like whiteboard diagrams.
TestDox is neat but fairly trivial. I wonder if the "agiledox" project name implies more to come.
The NYT's top 25 emailed articles
Journal of Object Technology
"spikes should take about four hours" said Ron Jeffries in this old post.

Version Numbers and You

Wed, 30 Jul 2003 01:33:35 GMT

Version Numbers and You

My best advice to anyone thinking of starting such a project: put together a road-map now. List the features you want to see in your program, and then cull it down to three milestones:

The bare minimum you would need to implement before you let anyone see your code.

The bare minimum functionality you would need to implement before people could legitimately make use of your code.

As above, but stable and well-documented enough to be used in a production system (for libraries), or by non-programmer end-users (for applications)

Milestone 1 is your v0.5. Milestone 2 is v0.9. Milestone 3 is v1.0.

[Via The Fishbowl]

The Real Underground

Tue, 29 Jul 2003 17:20:53 GMT

The Real Underground shows the iconic contemporary London Underground map, Harry Beck's original 1933 version, and a geographically correct version, with a very pleasing morph between the three. Cool toy. [Via Small Values of Cool]

Java Case Studies

Thu, 24 Jul 2003 18:19:23 GMT

A listing of Java case studies on Jack Shirazi's java.net blog

You must be the change you wish to see in the world.

Wed, 23 Jul 2003 00:57:28 GMT

"You must be the change you wish to see in the world." - Mohandas Gandhi

J2ME Development With Eclipse and Antenna (HOWTO)

Mon, 21 Jul 2003 23:34:12 GMT

J2ME Development With Eclipse and Antenna (HOWTO)

Here are the steps I compiled for developing Midlets using Eclipse, the J2ME Wireless Toolkit, and Antenna.

Create new Eclipse Project (java)

In the Libraries tab, remove JRE 1.4.

In the Libraries tab, add the J2ME libraries. The J2ME libraries (midpapi.zip, mmapi.zip, and wma.zip) are located in the lib sub-directory of the directory you installed the wireless toolkit.

Configure the project's source directory. Instead of using the projects root directory for the source code, I recommend configuring the source files to be located in the source sub-directory of the project (ie. Project/source).

Configure the project's output folder. I recommend the bin subdirectory. (ie. Project/bin)

Add the antenna task definitions to Eclipse. In the Eclipse (Window-->Preferences-->Ant) tab, add antenna-bin.jar to additional classpath entries.
Create the code for your midlet.

Copy the ant build script (build.xml) from the antenna samples in CVS.

Modify the build script by removing wtkmakeprc section. Unless you are testing on a Palm, you don't need this section.

Add the "fork" and "executable" properties to the wtkbuild task as follows:

In eclipse, Right click on the xml file and select "Run Ant...".

When you click "Run" on the build window, the emulator will pop-up and you will see your application running.

[Via Niel Eyde's Weblog]

Curly braces, Pipes, Escape and other characters on the Zaurus

Mon, 21 Jul 2003 18:56:30 GMT

If you've ever tried to type code, pseudo-code or shell scripts on the Sharp Zaurus, you may have noticed that the little slide-out keyboard is missing some useful keys. If you've done much typing with this thumb-keyboard, you may have noticed that when you fat-finger a couple of keys, you can get some of those extra characters. For my reference as much as yours, here's a short list:

keys	character	unicode value	name
[Fn]+z		0x005A(?)	undo
[Fn]+[Shift]+c	€	0x20AC	euro symbol
[Fn]+[Shift]+[Backspace]	[	0x005B	left square bracket
[Fn]+[Shift]+,	]	0x005D	right square bracket
[Fn]+[Shift]+.	{	0x007B	left curly brace
[Fn]+[Shift]+[Enter]	}	0x007D	right curly brace
[Fn]+[Shift]+'	^	0x005E	caret/circumflex
[Fn]+[Shift]+[Space]	`	0x0060	tick/backquote
[Shift]+[Space]	\|	0x007C	pipe
[Shift]+[Tab]	\	0x005C	backslash (note that this is listed incorrectly in the sharp doc)

In the table above, "[Fn]" means the purple "function" key, "[Shift]" means the arrow-up "shift" key, "[Backspace] means the white back-arrow/delete key, "[Enter]" means the purple "return" key, "[Space]" means the space bar, "[Tab]" means the purple tab key, and a "+" means hit these keys in combination, typically by holding down the "meta" keys first.

Also notice that the "Cancel" button works like "Escape", which makes VI usable without resorting to the on-screen (virtual) keyboard.

There's a full keycode mapping table available on Sharp's site.

CL-WHO: XHTML Generation Package for Lisp

Fri, 18 Jul 2003 18:34:03 GMT

CL-WHO.

Edi Weitz announced his new little XHTML generation package, CL-WHO. (Edi is also providing further evidence that lisp software pages don't have to be hideously ugly and poorly organized.)

[lemonodor]

Norman Richards: So, you want to be an author

Tue, 15 Jul 2003 20:49:53 GMT

Norman Richards on So, you want to be an author.

How Not to be a Sharecropper

Mon, 14 Jul 2003 12:59:03 GMT

Tim Bray on How Not to be a Sharecropper for the Microsoft plantation.

this is a spider on drugs

Sat, 12 Jul 2003 07:19:30 GMT

Pictures of webs spun by spiders drugged up on caffine, mescaline, LSD, etc.

Fascinating.

Do What You Love

Thu, 10 Jul 2003 12:07:00 GMT

In 1960, a researcher interviewed 1500 business-school students and classified them in two categories: those who were in it for the money – 1245 of them – and those who were going to use the degree to do something they cared deeply about – the other 255 people. Twenty years later, the researcher checked on the graduates and found that 101 of them were millionaires – and all but one of those millionaires came from the 255 people who had pursued what they loved to do!
Now, you may think that your passion for Icelandic poetry of the baroque period, or butterfly collecting, or golf – or social justice – might consign you to a permanent separation between what you love and what you do for a living, but it isn't necessarily so. Vladimir Nabokov, one of the greatest novelists of this centurey, was far more passionate about butterfly collecting than writing. His first college teaching job, in fact, was in lepidoptery. REsearch on more than 400,000 Americans over the past 40 years indicates that pursuing your passions – even in small doses, here and there each day – helps you make the most of your current capabilities and encourages you to develop new ones.
The other 90% by Robert K. Cooper, Three Rivers Press 2001

From [Via Bruce Eckel's 7-9-03 entry "Do What You Love"]

Conference Presentation Judo

Wed, 09 Jul 2003 12:19:41 GMT

Conference Presentation Judo: "If you look around for advice on public speaking, you'll find that most of it says the same things: face the audience, speak clearly, don't put too much text on a slide. My talk is about tricks you won't hear elsewhere" - http://perl.plover.com/yak/presentation/

Lessig's Cognitive Style

Tue, 08 Jul 2003 19:18:35 GMT

Despite what Edward Tufte will tell you, Lawrence Lessig's presentation entitled <free culture> (other formats) shows that you can do a great presentation with PowerPoint. (Granted, it's not PowerPoint that makes it great.)

[Via VentureBlog]