Sarah Allen's Weblog

pipes, redirects and awk -v

I wanted to take the output of a command and put it in a temporary variable so I can append a string to it. (Trying to script perforce to append something to my client spec without interactive involvement.)

First attempt:
$ p4 client -o > $CLIENTSPEC
c:\cygwin\bin\bash: $CLIENTSPEC: ambiguous redirect
I later learned that redirect is only for files.

Next attempt:
$ TEST=`p4 client -o`
$ echo $TEST
//depot/apps/diamond-calendar-preview/... //sallen-LENOVO/svn/openlaszlo/branches/pagan-deities/diamond-calen //depot/apps/diamond-amaranth-ms2/... //sallen-LENOVO/svn/openlaszlo/branches/pagan-deities/diamond-amaranth- //depot/sandbox/my-webtops/... //sallen-LENOVO/svn/openlaszlo/branches/wafflecone/diamond/client/my-webtops/. ..
which seems to have swallowed line endings and only provided the last few lines of output.

My colleagues at Laszlo, Trebor Fenstermaker and Chris Pettitt and ptw, showed me the error of my ways and provided some good tips. Trebor noted that there is a length limit for shell variables and that line endings will get lost. Chris introduced a combination of pipe and awk -v which did the trick. At first I thought Tucker's simple echo solution wasn't working, but he pointed out that I just needed to properly parenthesize my commands.

What worked:
p4 client -o | awk -v append=" //depot/apps/test/... //sallen-test/svn/openlaszlo/branches/pagan-deities/test/..." '{ print $0 } END { print append }' | p4 client -i

Even simpler:
(p4 client -o; echo " //depot/apps/test/... //sallen-test/svn/openlaszlo/branches/pagan-deities/test/..." ) | p4 client -i

Notes:

• Redirect only works for files, there are lots of different types of redirects (> is a simple redirect of stdout to a file, >> will append to a file, 2> will redirect stderr)


• awk -v will define a variable which can then be used in the awk script


• You need to properly parenthesize your commands:

  ( p4 client -o; echo "Thing to append" ) | p4 client -i

  The parens will execute the p4 and echo commands in a sub-shell so the output of both will be piped to the next. Without the parens you have said:

  p4 client -o; ( echo "Thing to append" | p4 client -i )

  I.e., run the client command, then run echo to a pipe.



• Pipe will let you take the stdout of one command and send it to the stdin of another:
  

bash: xargs is your friend

For some reason, since I set up my new machine, when I p4 sync I would get directories that aren't writeable. This means that lzx files won't compile since the swf needs to be written into the directory.

To work-around this, I tried to just set permissions on all the directories. My first attempt (below), didn't work.... anyone know why? the second one is more verbose and did work.

$ find * -type d | chmod a+w
chmod: missing operand after `a+w'
Try `chmod --help' for more information.

Verbose work-around:
$ for i in * ; do if [ -d $i ]; then chmod a+w $i ; fi ; done

A better answer: the chmod command does not accept arguments on stdin, so you can't just pipe a file list to it:

$ find . -type d -print0 | xargs -0 chmod a+w

xargs is your friend

Yahoo's BrowserPlus sneek peek

I checked out Yahoo's sneak peek of BrowserPlus this morning -- looks like there is some interesting stuff there. It think they have a good approach by getting feedback from people using apps before they open up the APIs to developers. I have always believed that to get the UI right, you need the user experience to drive the APIs not the other way round.

Key Features
* Drag-and-drop from the desktop to the browser (my favorite!)
* Upload to FlickR
* Desktop Notifier (integrating with Growl on the Mac and Snarl on Windows)
* Image editing: rotate, crop, and effects: 'sepia', 'swirl', 'solarize', 'oil_paint', and 'grayscale'.
* Text-to-Speech
* PStore (local storage: I wonder what the limit is here)

Geek Features
* Ruby Interpreter
* JSONRequest
* IRC Client

The API documentation is available, but right now you can only use it if you work for Yahoo. However, with the documentation out there, including a slick doc browser, they seem pretty serious about opening this up to external developers.

BrowserPlus also has a plugin architecture, so the features can be updated without restarting the browser or even refreshing the page! This will put them in a very good position when it comes to adoption, but the way they present the plugins is a bit odd from an end user perspective. I can dig allowing Yahoo to install an image editor, but do I really care that the app I'm using is written in Ruby? I've got a little security geek background and I don't even understand implications of allowing a "RubyInterpreter" to be installed -- is it sandboxed? does it allow file system access? This is weird territory from a usability perspective. How's a normal person to tell what's safe or not? Hard to tell what the model is here... am I trusting the site or trusting the software vendor? Right now they are the same for BrowserPlus, but they'll need to clarify this before they open it up

Installation Experience
Continuing with my series evaluating the initial experience for Adobe Air and Gears, here's a click-through slide show of getting started with BrowserPlus:

| View | Upload your own

Privacy Policy

To learn more, please read our BrowserPlus privacy information at http://info.yahoo.com/privacy/us/yahoo/browserplus.

Certain sites may request the you download a corelet? Are you kidding me? How about you just use an English work like "extension" or even to quasi-english "plugin" -- I think it just confuses people to create new language for an old concept.

Conclusion
BrowserPlus is a promising new contender in this space with a new angle. Even though AIR and Gears have been out (at least for developers) for a while, there is no clear winner and I don't expect that to be decided for a while yet. BrowserPlus worth watching. If you are going to check out one demo, I'd recommend the flickr uploadr.

js meetup: ScrewUnit

Nick demonstrated ScrewUnit at the JSMeetup last night. My notes:

• behavior-driven development, particularly popular in the Ruby world with the RSPEC framework


• organize your tests, share setup


• global befores and afters let you effectively test the DOM


• nested describes, nested example groups in RSPEC

What about continuous integration? there's a ScrewUnit server, navigate URLs - only run those in that directory. There are callbacks when a suite ends/begins -- integrated into CruiseControl

on GIT hub, MIT license

support for async libs? unsolved problems, most people at the company stub out async.

What about user interactions? serious attention on event and DOM testing. Nothing in particular to facilitate that except before and after. JQuery is a good approach...

js meetup: keyboard shortcuts

Alex from Acunotes (?) demonstrated a cool library for adding keyboard shortcuts to your site. They use gmail conventions, which are essentially borrowed from vi, but the feedback from their non-geek users is very positive. (Some browsers eat control keys, so we can't use standard desktop shortcuts. They can do key-combos with shift)

My notes:

• competitive advantage for them, users like it


• open source, MIT license, GIT project


• 8k including comments :)


• nice intuitive interface, with concise scripting

js meetup, paul sowden, client-side storage

Paul Sowden of meebo talked about client-side storage options at the JS Meetup last night.
Great info! Here are my notes:

Client-side storage... more options than cookies
3 examples:

• halfnote [Update: thanks Paul!]


• gmail


• sticky notes

• Gears: sync'd db, SQL interface, search over the DB, unlimited storage (at least in the beta)
• WHATWG, fr HTML5: Safari 3.1+, WebKit, at least two MB, bit more code,
• FF2+ IE8, WHATWG Global Storage, when values change events are fired, in FF you get up to 5MB, in IE its XML, in FF its an SQLLite DB (allows potentially browser-desktop app) -- pretty clean simple code
• userData HTML Behaviors in IE 5.5+, up to 1MB per domain -- simplest code
• Flash Cookies, 100KB by default, but youcan ask the user for more (clunky little Flash interface), you'll need to use SWF wrapper and Javascript bridge

On meebo, they checked out how many people had which available

• 87% Flash (they checked for v8, but this has been available since Flash Player 6, so ymmv)


• 74% have native storage


• gears in the single digits

Libraries available

• Dojo.storage


• Persist.js - normalize API, just key-value gears

Note: global storage has widest adoption, but global storage actually has been taken out of the specification!
[Update: slides from this talk have been posted on slideshare]

| View | Upload your own

js meetup, jon boutelle: Flash or Ajax?

Jon Boutelle of slideshare.net spoke at the JS Meetup last night. He reported a refreshing perspective about the choice between Flash and Ajax on websites today: you quite possibly need both. He made the analogy to having a hammer and a saw -- you need both to build a house. (By the way if you haven't checked out slideshare is is way cool. See a collection of Jon's presentations or mine). Notes below:

Keep Flash on a leash, only use it for what its really good at

• you have to work extra to get SEO -- slideshare puts the transcript of slides at the bottom of the page


• Jon finds that load time on average is worse in Flash (He note: Javascript can be fat too. I find it depends what you are doing -- raw script execution and http requests are much slower than the browser, but you can bundle up a bunch of code & graphics in a SWF and get better performance. Still I wouldn't choose one or the other based on performance.)


• advocates Flash nuggets -- I love this term!


• Full screen is nice -- use it for good, not for evil


• invisible Flash -- you might not even know you are using Flash. Used in some Javascript libs


• - graphics goodies: fonts, vectors, multimedia, recording audio/video, multimedia editing, widgets (don't worry about layout, but SEO sucks)


• - upload progress bars


• - sockets! comet is cool, but server-side push -- libraries w/ Ruby (443)


• - local dataObjects "super cookies" -- you can ask the user to save 1GB


• - Flex: 125KB download for the framework

Javascript cheap tricks (not quite AJAX). Javascript 101 -- you don't even need to hit the server (although maybe you should if obscured stuff is seldom used)

• tabs (conserve real-estate)


• Accordians (aks Tab sliders) -- like tabs only sideways


• Microlinks - expando-tabs


• One second mutation -- animated transition: control the user's attention, they see that the small thing becomes the big thing


• Popups -- use with discretion, since you occlude part of the screen

• Malleable content (e.g. edit in place)


• progress indicators


• One second spotlight, famous yellow fade popularized from 37signals, tests well, makes people happy


• Temp message: show message, fade away: don't leave a permanent mark on the page (sometime doesn't test well since people miss it)



Conclusion:
What the world needs is Ajax/Flash cross-over artists. Flash doesn't kill people, people kill people. Can't we all get along?

Q&A
Q: geni.com -- could that be done in Javascript?
Answer from the audience: zooming would be hard in javascirpt

Posted by Sarah at 5:50 AM | Comments (0)

extreme programming vs. interaction design?

In January 2002, Elden Nelson wrote "Extreme Programming vs. Interaction Design: When two development design visionaries meet, there's room for consensus--but not much (via The Sticky Bit and the Internet Archive). This fabulous interview with Kent Beck and Alan Cooper contrasts two modern methodologies for getting software right. These challenging questions are no less relevant six years later. I believe that we should take guidance from both philosophies, and that they are not mutually exclusive.

Alan is absolutely right that there needs to be up front design. He talks about designing human behaviors before you even consider defining an interface, thinking about what buttons go on the screen. He notes that interaction design focuses on the behavior of complex systems, of humans and of organizations. He comments: "I think XP has some really deep, deep tacit assumptions going on, and I think the deepest tacit assumption is that we have a significant organizational problem, but we can't fix the organization." In my experience, sometimes we can fix the organization and sometimes we can't. Usually we can just nudge it in the right direction, but some of the age old problems will exist. It's easy for a management team to just remove design from the process in the name of XP.

Alan would keep engineers away from customers, fearing that engineers lack insight into human processes and will merely "automate the pain." He draws an analogy with an architect and a builder; however, I believe architects study construction and the engineering principles behind building a lot more than most interaction designers study the technology they work with. After much discussion, Alan agrees that needs to be a back-and-froth and that engineers need to be involved with the design.

The major contention in this article seems to be about whether the engineers start work day 1 or day X, but afterwards both believer they should work together. I'd like to see a project with Alan and Kent both on board where Alan's team was doing interaction design while Kent's team was writing stories. I love Kent's ideal of writing code that is flexible and becomes more resilient over time not less, but it is clear that Alan just doesn't believe it, and I agree that ideal is pretty tough to achieve.

Here are some quotes from the interview which I enjoyed....

Cooper: It's my experience that neither users nor customers can articulate what it is they want, nor can they evaluate it when they see it.

Kent Beck:
One of my goals in XP was creating teams that even in highly constrained and emotionally charged business environments could produce programs that didn't lose their ability over time but, in fact, gained capacity over time. As components are factored out, as configurations emerge from the customer team--which you might call the interaction team--the program is still getting better and better in five years. The team gets the attitude where they go back to the customers and say, "You're giving us easy stuff. Give us a hard one." The customer team is actually challenged, over time, to think bigger and bigger thoughts as development goes on.

And here's my favorite exchange, following where Alan Cooper was talking about how the right design up front keeps the requirements from shifting, since you get them right upfront (which I don't know if I agree with, I suppose it depends on the length of the development cycle):

Beck: Yeah, but I would say exactly the opposite. For all its Dilbertesque qualities--and I'm still proud of having said "Embrace Change" in the title of the first XP book. I've consciously decided to give up the ability to predict the future.

Cooper: I see that in XP. It's an abdication.

Beck: Is Zen an abdication?

understanding engineers

Charles Miller describes how engineers express the level of difficulty of solving a problem (via Ron K. Jeffries). He has some great descriptions of each level of difficulty, which I found quite accurate:

* Impossible
* Unfeasable
* Non-Trivial
* Very Hard
* Hard
* Trivial

I've added "straightforward" to my language, which describes trivial problems that will still require some time to implement. I find it helpful in talking to non-engineers and to other engineers who might argue with my characterization of a given problem as "trivial."

software is challenging

I just read a couple of interesting Salon articles about Scott Rosenberg's book "Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software" which tells the tale of OSAF's Chandler project.

The excerpt "Words Fails Us" describes the classic naming problem we face when writing software. We name a concept before we've precisely defined it and as the code and designs evolve definition can drift, even when the team had a single concept to begin with. Naming is important, which is one of the reasons software re-factoring tools have become popular. Software is language. Once we precisely define things, they exist. One solution to the software challenge is to work in teams small enough that you can resolve communication problems without a glossary on the wiki.


Andrew Leonard's interview with Rosenberg "Software is hard" talks about the underlying theme of the book. I guess it isn't really about the Chandler project, but about all software projects gone awry, which, I suppose, is about all software projects. They all go awry, every day, in unexpected, amusing and frustrating ways. While the struggle resonates with my experience, I found myself startled by disagreeing with a few points that Rosenberg presents as accepted facts:

"And programmers, as I quote Larry Constantine in my book, programmers are programmers because they like to code -- given a choice between learning someone else's code and just sitting down and writing their own, they will always do the latter." This "truism" is in stark contrast to the "programmers are lazy" adage. Most engineersI know who are looking for a compression algorithm or encryption technique will go dig up a popular library, rather than implementing their own. No one needs to prove that they can write the very best TIFF to PDF converter if there's some available, already working code that does that. Perhaps this has gotten more prevalent with the rise of open source, and certainly web technologies tend to leverage existing shared code more than traditional software development. When it comes to innovation, reuse is hard, if not impossible, hence the challenge of writing new software.

"There is this raw fact in the field that the best way to create software would always be to have just one person write it." A significant caveat to this "fact" is that the one person must have a complete and accurate vision for what the software needs to do, which usually only works well when that person is both author and audience. I do think software is best developed when there is a lead developer who can keep the whole system in his or head, but it helps to have other co-creators who can validate that you are building the right thing.

Although I may nit pick with some of his points, it is always interesting to see someone try to capture the struggle that of the software development experience -- maybe when it comes out in paperback, I'll read the whole thing. I am always amazed at how we consistently set out to do something novel, that we've never done before, somtimes somthing that no one has ever done before, and that we expect to be able to accurately predict how long it will take. I do believe software is challenging, but I swore to myself when my son was 3 weeks old that I would never again say "software is hard." It is amazing how problems can be simplified and creative solutions can be envisioned after a good night's sleep.

Q&A with great programmers

Jarosaw "sztywny" Rzeszótko decided to ask ten questions to the programmers he admired the most and then posted the questions and answers on his blog (via slashdot). I enjoyed reading the Q&A, but what I find most wonderful and inspiring is to see someone take the initiative to connect with both famous and less known role models and then publish his findings to share with public. And to see the great folks and thoughtful leaders who responded to his questions.

Some highlights...

What do you think is the most important skill every programmer should posses?

Steve Yegge: Written and verbal communication skills. You’ll never make it very far as a programmer in any field unless you can get your ideas across to people effectively. Programmers should read voraciously, practice writing, take writing courses, and even practice at public speaking.

Linus Torvalds: It’s a thing I call „taste”.

I tend to judge the people I work with not by how proficient they are: some people can churn out a _lot_ of code, but more by how they react to other peoples code, and then obviously by what their own code _looks_ like, and what approaches they chose. That tells me whether they have „good taste” or not, and the thing is, a person without „good taste” often is not very good at judging other peoples code, but his own code often ends up not being wonderfully good.

But hey, it’s not the only thing. One thing that is very useful, especially in an open source project, is simply the ability to communicate well what you want to do, and how you are going to do it. The ability to explain to others _why_ you do something a certain way is very important, and not everybody has that ability.

That said, in the end there are also the people who just churn out good code. They may not be good at explaining it, and they may not even have great taste, but the code works well. Sometimes you need another person (one that _does_ have that hard-to-define „taste”) to maybe massage the code into a form where it’s useful in the bigger picture, but just the ability to write clear code for difficult problems is obviously a fairly fundamnetal part of any programmer.

David Heinemeier Hansson: A strong sense of value. The ability to ask yourself the question: Is it worth doing what I’m doing right now? So many programmers seem to waste oceans of time on stuff that just doesn’t matter. And not enough on the stuff that does.

Peter Norvig: I don’t think there’s one, but let’s say concentration.

Dave Thomas: Passion.

Guido Van Rossum: Your questions are rather general and hard to answer. :-) I guess being able to cook an egg for breakfast is invaluable.

James Gosling: To be self motivated. To be really good, you have to be in love with what you do.

Bjarne Stroustrup: The ability to think clearly: A programmer has to understand problems and express solutions.

Tim Bray: Ability to prefer evidence to intuition.

What do you think makes some programmers 10 or 100 times more productive than others?

David Heinemeier Hansson: The ability to restate hard problems as easy ones.

Peter Norvig: The ability to fit the whole problem into their heads at one time.

Dave Thomas: They care about what they do.

James Gosling: They think about what they do. They don’t rush in and slap things together. They have a holistic picture of what is to be built.

practical web 2.0

Admittedly, I'm one of the techcrunch crowd, I have accounts on all the new calendars, rich web mail, video sharing sites and social networks. I've been watching this stuff before it was THE web... in the 80s Intermedia allowed multiple "webs" of links to overlay documents and way before that, in the 60s, Doug Engelbart's Augment system enabled dynamic outlining and references to anywhere in the document. It's good to remember that our ideas stand on the shoulders of our predecessors. Tim Berners-Lee's ideas about the "semantic web" are a great new twist on Ted Nelson's Xanadu and Vannevar Bush's Memex.

In the Web 2.0 era, we keep chasing after this dream of a web that is more than just a sea of static documents. Let's create some APIs or dynamic document snippets and mash 'em up together. Until now, I've felt that this was only theoretically useful and had yet to be useful to the folks who don't have several email addresses that they need to sync up to their Blackberry.

Last year I volunteered to make a website for my son's school. It's not that I need one more project to do, but I felt that it was just not right for a school in San Francisco to lack an on-line presence. It's a relatively new school, just ten years old, and there are surprisingly few parents who are also web-geeks (or maybe I just haven't found them yet). I had a vision for the web site that included a blog, so that content could be updated by non-techie volunteers, but that hasn't yet appeared in my first implementation. It's a basic web site with a number of pages that describe the school and its various programs. I've got a number of perpetual drafts of stuff that needs to go up, but I felt it more important that there be a website, than there be a complete website. All good websites are a work-in-progress, no?

The remarkable web 2.0-y tech that I ended up including was Google calendar. The most important part of the website that absolutely must be kept fresh is the dates of upcoming events. I had this vision of a calendar with a human interface that could be kept up by any volunteer. This implementation is a compromise. It doesn't look exactly how I'd like it to look and there is no obvious link to the full calendar as I would like. I'm one of the rare folks who could actually code that up in not too much time using Google's public APIs, but the point is, I'd rather spend that hour doing something else on my infinitely long to-do list.

So, one Saturday afternoon, after the summer Kindergarten playdate when I'd found a dad to volunteer to enter calendar data, I invited my alter-ego, the school webmaster, to create a google account, and added the published calendar to the website. I had created a classic "inclusion" by Doug Engelbart's definition -- innovative in the 1960s, still ground-breaking today. By the end of the weekend, James had entered every date in our school calendar, and the website was automatically updated (and would continue to be throughout the year.) Now, James is a little more technical than the average parent, he used to use Yahoo calendar and works in medicine where you need to be fairly techno-savvy; however, he is pretty far from the web 2.0 in-crowd.

Two things are happening: 1) technology is getting easier to use and more useful; and therefore 2) more people are using technology in their work and in their lives. The result: a website that doesn't need to be updated till next year, but more importantly, the few hours that I have to devote to it can go towards making it better, not simply maintatining it.

the coding offsite

We just had a fine day at the Atlas cafe on the first day of our development offsite. We've got an agenda, but mostly we spent the day coding. One of the engineers noted that that a day of pure coding was nothing new, but as a manager, personally, 8 hours straight of uninterrupted code feels downright decadent. It's fabulous to have everyone close by. When you need a code review, there's an engineer at your elbow. When you have a question, someone across the table has an answer. Sometimes you just need to talk something through with another human being who can nod knowingly and ask the odd question. The whole team is there when you are wondering the best pattern for a new API. Sure, it really ought to be this way at the office, but with business booming some of us are frequently called into meetings. There's a need for that, but we also need to balance it with a need to create our next gen products.

It feels good to be part of a small company. I proposed the idea of this offsite on Wed night and by Thursday aftenoon it was a reality. Kudos to the management for letting us make it happen. Today we had a great time, being hugely productive, building some awesome apps using OpenLaszlo. Every now and then what you do for work scarily coincides with what you might do for fun. Today was one of those days.

Of course, all things being equal, it would be fun to spend the day at Zeitgeist. As it was, we just spent the evening there. (Sorry no picture to incriminate the team -- my camera battery ran out.)

By the way, we're hiring.

innovation can only come from the bottom

"In my experience, innovation can only come from the bottom. Those closest to the problem are in the best position to solve it. I believe any organization that depends on innovation must embrace chaos. Loyalty and obedience are not your tools; you must use measurement and objective debate to separate the good from the bad." (Greg Linden talks about "a project I was explicitly forbidden to do and did anyway.")

I enjoyed reading Marc Hedlund's latest Engineering Management Hack where I found the link to Greg's story (via an email from Laszlo colleague Scott Evans). I loved the story about David Packard's award for "extraordinary contempt and definace beyond the normal call of engineering duty." We're not all cogs in a great machine, and it's wonderful to hear about top level managers who know and appreciate that.

This is an extension of the old: sometimes it's easier to get forgiveness, than to get permission. I definitely believe in a management style that puts more power and autonomy in the hands of the people who do the work. (Not that management isn't work, but you know what I mean.) You hire the right people and give them responsibility and they make magical things happen. It's important that I know what's going on, and often I like to be consulted, but I've been known to reprimand employees for doing what I told them to do when they knew better. I hire people who know what they're doing, who are smart, who I can trust.

I think it creates an enviroment where good people like to work, but I'm not driven by purely altruistic motives. I think it makes people more productive and effective, but I don't just do it for the bottom line. I, personally, have other things I'd rather be doing. If I trust people and let them do their jobs (and define their jobs to be big enough to take on real responsibilities and take initiative), then I have time to write code myself. People have remarked that it is a great thing in for an engineering manager to be deeply in touch with the tech, but that's not the real motivation. I, personally, want the simple joys of coding and practical, tangible problem-solving to be an everyday part of my life. It's not enough to be the "idea guy" -- I also want to be "at the bottom" where the real innovation happens.

Ease at Work (Kent Beck)

I went to hear Kent Beck speak on Tuesday and he asked: "when was the last time you were comfortable in your skin as a programmer?" ...and when did you last have that feeling at work?

My answer was: last week. It hasn't always been that way for me, and sometimes there'll be months in a row where it doesn't happen at all (of course, lately I blame that on being swept into management, but that's a topic for a different post).

Kent Beck surprised me by talking about what he called the "genius-shithead rollercoaster," where one day you are the a wizard, all-powerful, master-of-the-universe because you wrote some magnificent piece of code or found and fixed some harrowing bug, but two or ten days later you are an incompetent idiot who can't solve the basic problems that confront you. I used to describe this as the "manic-depressive product development cycle."

The odd thing is that I thought this was a gender issue. Here I was amidst a group of bright, young men who often showed their genius in their code (or at least thought they did). I never saw that they had any dark moments of the soul when they questioned their competence or wondered if they belonged in this profession. I thought it was just me, being female. I worked very hard to overcome these bleak periods of doubt. I found the ability to laugh at myself when I felt like a superhero. And now, most of the time, I can find deep moments of joy in the process of solving problems and writing code whether I'm successful at this moment or struggling with a not-yet-solved issue.

I listened to Kent, as he described in detail what he meant by finding "ease" at work: not freedom from difficult, not freedom from constraints, not taking it easy, but a state of comfort, freedom from worry, pain or agitation, freedom from embarrassment. It's a good way to look at it that "maintaining illusions is a waste of energy" and that "awareness offers choices."

Kent talked about responsible development:
- My code works
- My code matters
- Accountability
- Public commitment
- Appropriately valuing feedback
- Acknowledge my contributions

I took notes and I thought: right on! While at the same time, I thought: "oh my god! poor Kent -- he's going to become known as the Stewart Smalley of Agile Development" (my code's good enough, and gosh darn it people like me). Is this roomful of men really going to buy this? And after the talk, listening to the questions, it appears that they did. What he was saying resonated with them. They asked insightful questions. I kept trying to form my shocked observations into a question, but I couldn't quite turn it around.

Upon reflection, there have been a number of guys, more recently, who have mentioned this pattern. I was just so wed to my own gender bias that I assumed they were the exception. I'm not quite sure what to learn from this, except I'm glad Kent's talking about it. I'll end with my favorite quote of the day:

"Programming so that you'll feel like a hero is quite different from programming so that you have a program."

What do you think?

is software engineering?

Nice (lengthy) article about by Jack Reeves about the whether software development is engineering. If its too long for you skip to the bullet points at the end. I enjoyed much of the prose. I thought he made some interesting points...

The final goal of any engineering activity is the some type of documentation. When a design effort is complete, the design documentation is turned over to the manufacturing team. This is a completely different group with completely different skills from the design team. If the design documents truly represent a complete design, the manufacturing team can proceed to build the product. In fact, they can proceed to build lots of the product, all without any further intervention of the designers. After reviewing the software development life cycle as I understood it, I concluded that the only software documentation that actually seems to satisfy the criteria of an engineering design is the source code listings.

...There is one consequence of considering code as software design that completely overwhelms all others. It is so important and so obvious that it is a total blind spot for most software organizations. This is the fact that software is cheap to build. It does not qualify as inexpensive; it is so cheap it is almost free. If source code is a software design, then actually building software is done by compilers and linkers. We often refer to the process of compiling and linking a complete software system as "doing a build". The capital investment in software construction equipment is low -- all it really takes is a computer, an editor, a compiler, and a linker. Once a build environment is available, then actually doing a software build just takes a little time. Compiling a 50,000 line C++ program may seem to take forever, but how long would it take to build a hardware system that had a design of the same complexity as 50,000 lines of C++.

I found this article while noodling around on the old software engineering as building architecture analogy. Despite Christopher Alexander's views on building patterns that we borrow for software patterns, I tend to agree with James Shores' reflections on That Damned Construction Analogy:

In the software world, there is no reason for us to follow the practices of an industry limited by Newtonian laws. We have no gravity. There is no inertia. Lines of code have no weight.

If we want to dig a metaphorical hole after pouring metaphorical concrete, there's nothing to stop us. If we want to flip the software upside down and build a foundation after we've built the building, we can do it. Our only limits are in our heads. Once we stop thinking that software development is like construction, we'll have one less limitation to struggle with.

His words inspired this silly cartoon which was much cooler in my mind's eye than it came out in pixels, but I include it here to break up the large number of words that are referenced by this post :)

how it looks from the outside

A couple of conversations recently have caused me to reflect on how my normal, everyday life as a creator of software looks rather odd to people outside of the profession.

Conversation with my 7 year old after the usual attempts at getting him to actually talk about what he did at school that day, and his claims that he doesn't remember:
me: I remember everything I did today and could tell you all about it. But I'm probably more interested in your day at school than you would be in my day at work.
him: I already know what you do at work
me: really? what do I do at work?
him: you just type on your computer all day long

Conversation with a good friend of mine (profession: folk singer)
him: did you invent anything today, Sarah?
me: Not today.
Some days I can claim to have invented stuff. In a conversation last week, I related that we finsihed up two different versions of our software on the same day.
him: I'm always interested in what exactly it is you do since it is so mysterious to me. What did you do today?
me: There are people who work with me, whose job it is to find everything that is wrong with what we make. Then they make a long list of problems. Today I went through that list and figured out when things needed to get done and assigned them to different people.

It's my birthday today, so I suppose it is natural to reflect on what the heck I'm doing with my life.

As I get ready to leave for the office, I choose not to think of my work as incomprehensible to my friends and family. Today, I choose to think of what I do as mysterious.

evolving development style

Over at the Laszlo Mail blog, I've written about a development style for the new millenium. I've tried to bring what-has-worked in the past into the light of new requirements and opportunities. An appropriate year-end post, I reflect on our most recent release and how our development style reflects what we've learned over the year, as well as old software management lessons.

That article might have appeared here as easily as there. Unexpectedly, I find myself a contributing author to four blogs (and the sole author of two of them). I don't think having more places to publish makes me write less in each, but rather creates more reason to write. Flying Paperclips is a simple notebook of science experiments. Some notes which might otherwise have been emails or checkin notes, now are published on the OpenLaszlo weblog.

With the Laszlo Mail blog, I'm experimenting with what has been called "the obligatory development blog" of web software. I grew up writing software in an atmosphere of secrecy, where one dare not discuss development methodologies for fear of violating NDAs and revealing trade secrets to a competitor. Nowadays companies are more comfortable being open about how software is developed, or perhaps there was no danger before and my fear caused unnecessary self-censorship. In any case, I appreciate the developers who have created a well-trodden path, as I venture into this unexplored territory in my personal landscape. I'm still unsure what is a daring revelation vs. a mundane, even uninteresting detail of private software development. Every new release brings fresh challenges as well as familiar obstacles. I enjoy reading how other people go about this act of creatng and publishing software. It is fun to add my stories to the mix.

paint-on computing

Harry Chesley writes about when eveything computes in his new blog Meme Motes. In this recent blog entry, Harry challenged himself to make a prediction about the future:

"Once paint-on computing is a reality, user interface as we know it becomes freed from virtually every limitation. You don't have to sit at a computer screen any more. You don't have to use a mouse. You don't need a keyboard unless you decide it's the best way to input data. There's enough computing power to do anything you want in terms of graphics and animation. In short, the UI is limited only by your imagination and human psychology. You can paint the computer onto a piece of 8.5x11 paper, onto a business card, onto a wall, onto a desktop, or onto your own skin. All those separate pieces are connected to be one interwoven, interactive, real-time computer system."

Now that he mentions it, it seems inevitable. The other day, my six-year-old boy said to me: "I forget, what's a nanobot?" After telling him a bit about the scale of a nanometer and discussing robots of that size and what I little I know about state-of-the-art nanotechnology, I asked him how he knew about nanobots. Of course, this technology is an everyday phenonmenon on the Power Puff Girls, Jimmy Neutron and Totally Spies. Our kids are growing up with wild expectations for computing and technology. It will be interesting to see what they invent.

debugging

Back at my day job last week, I was faced once again with a mystery bug. This bug seemed to defy logic and the physical laws of the universe. The whole system behaved correctly, except for the undesired behavior.

I was tired. It really felt like someone else's bug. It would take me a half hour just to write an isolated test case. (I could hear Kent Beck's voice reminding me that developer testing really does save time.) Everyone on my team is supposed to write unit tests. Of course there wasn't one for this particular unit. I considered chastising the developer in question and investigating the bug another day. Unfortunately usability testing was scheduled for the next day, and this bug was ...ahem.. bugging me, and I felt it would affect the usability of the app.

A long time ago when I was working on a solo project and dispairing of ever finding a particular bug. I had been hunting for this bug on-and-off for days. It was a large, not particularly wonderful code base that I had adopted from an acquistion. There really was no one at the company who knew much about it. I was alone in my SF office and I was at my wits end. I remember calling my long-time friend and co-worker David Simons and asking "what if I never find this bug?" and he asked me "Has there ever been a bug you haven't fixed?" Well sure, we always have to defer some bugs. "No," he said, "one that had to be fixed." Begrudgingly, I admitted, that I had actually fixed every bug I had ever set out to find. I hung up the phone, took a deep breath, and hunted it down.

At times like this when debugging seems bleak and hopeless I always ask myself that question and I reflected that this bug is not likely to be any harder to find than the most difficult bug I've ever fixed. In fact, this bug was likely to not even rank my top ten.

Also for this bug I did have a good clue. A colleague of mine had taken a look at it in the late afternoon and had discovered something I hadn't noticed. I instrumented the code a bit and saw the same odd behavior.

I spent hours examining the state of run-time, puzzling over variables that did not have the appropriate value. I kept thinking I had discovered that cause of the bug, but my code changes had no effect on the sympton. I had found 8 different variables that proved that the state of the app is disastrously incorrect. After while, I noticed that the symptoms had changed from my original observations. The app was more broken that it was initially. I removed my instrumentation and voila the bug was fixed. I had actually fixed this bug an hour before, but I had introduced another problem with my debugging statements.

Aha! A Heisenbug, so called from the Heisenberg uncertainty principle. From quantum mechanics: "The more precisely the position is determined, the less precisely the momentum is known." And more generally, Heisenberg introduced the notion that when you measure something, you change its behvior.

I find that the more experience I have debugging software the more I see patterns in the kinds of problems I find. Most of the patterns are not so delightfully named as the Heisenbug. I wonder... does anyone else have good names for common bugs?

Software and Picture Hanging

Colin R. MacDonald has written a good essay about the challenges of giving a task to a junior engineer. As a manager or project lead, I've run into pretty much every situation he describes. When it happens on a software project, it can be very frustrating. As Colin describes it with a picture hanging project, it's quite amusing:

"Why can't we get a nail gun?"
"We don't have the budget for it."
"So we can't afford to do things right?"
"There's nothing wrong with driving nails with a hammer."
"But aren't we trying to do things better and faster? Are we going to keep using hammers just because we've always used them? It'll pay off in the long run."
"We don't spend enough time driving nails around here to justify buying a nail gun. We just don't."

Every day I need to make decisions about how much time to spend talking about or writing down the details of a task. You don't want someone to feel micro-managed, but you don't want to leave them clueless. Sometimes there's a surprisingly small difference between the two.

At the moment, I'm leading a team and also writing code for the project, so there's additional balance between how much time I spend giving direction and how much time I spend on my own work. Its more of an art, than it is a science. I know the project will benefit if I write up checkin guidelines and best practices and write down all that info about the project that is floating around my head, but the project will also benefit from the code I would write in the same amount of time. The larger the team is the more benefit there is for written documents. I find that our culture of frequent code reviews provides a good time for reflection on whether I've got the balance right. Live feedback can be fun and low overhead, but if I find myself saying the same things over and over, its time to write them down. Also, no one wants to hear in a code review something that they needed to hear before they started to type.

ok, ok, I'll go write that best practices document...

change is inevitable

I'm at the Grace Hopper Celebration of Women in Computing (note that its not just a conference, its a celebration!). There was a great panel today on Open Source:

* Danese Cooper, Sun Microsystems and Open Source Initiative
* Mitchell Baker, Chief Lizard Wrangler, Mozilla.org
* Leslie Proctor, Gnome
* Katie Parlante, OSAF

It was postively inspiring for a gal who comes from a background of proprietary coding and is embarking upon a brave new journey into open source with Laszlo's recent announcement. I particularly liked the answer that Mitchell Baker gave to the question of how the industry was changing in response to open source initiatives. She said that the industry is overdue for a change and open source is one response. We have a relatively young industry that sells products that are very hard for people to understand how to use and that often need to be combined in ways that are seldom documented and sometimes incompatible. In addition, people pay real money for this software that comes with licensing agreements which expressly do not guarantee that the products work at all, let alone work together. She's right. The software industry is crazy. Maybe open source will help.

Its inspiring to be amongst over 800 technical women, knowing that this is just a small group of women in the field. I'll never get used to the occasions when I am the only woman in the room. I hope that we'll achieve Anita's goal of 50/50 in 2020. Whenever it happens, I believe change is inevitable in this respect as well. It was both amazing and unsurprising to hear that of people contributing to open source projects, women represent only 2%. It seems to me that open source projects represent a great opportunity to write code, get involved, and make a difference. Danese Cooper talked about quilting by early American women who would create masterpieces that would be passed on for generations. They took the time to craft these works of art because they were something that would live on beyond their time. This is a wonderful analogy to open source software. Unlike proprietary software which often becomes obsolete in a few years, open source software is a contribution to the greater community and can live on beyond our individual participation. In addition to the practical value of writing source code that you can show to a prospective employer and prove your cred without a hiring manager as a gatekeeper, open source appeals to altruistic ideals and offers community values that are traditionally appealing to women.

on gardening and code

Ned Batchelder writes about pulling weeds (via HMK) and I agree wholeheartedly.

Most people don't like weeding. In a garden on a sunny day with good tools, it can be enjoyable, but planting is really the fun part. The same goes for software. You want to be making new stuff, not maintaining old cruft. With habitual pruning and weeding, you can maintain the code while you are working on the fun stuff.

My garden began with a few seasons of digging dandelions in the company of a three-year-old who was happy enough to dig in the dirt while I dug up the long tap roots. I now garden with a six-year-old who knows that the weeds we don't dig up today will come back next year with brothers and sisters and nephews and cousins.

The native plants grow well and survive when we go on vacation. I don't know where pansies come from, but they need an unnatural amount of water (relative to the other plants in my garden). The colors are pretty, but I probably won't plant them again. In software, some parts of the code seem to need an unnatural amount of maintenance. Andy Hunt and Dave Thomas talk about software as gardening and how when it is difficult to maintain it may be an indicator that the requirements are incorrect. Are you trying to plant an orchid in a desert? Sometimes that feature just doesn't belong. If it is required, maybe the rest of the ecosystem needs to be developed.

Declarative GUI comparison

I've been meaning to learn more about XAML and was interested to see a very approachable app demonstrated in a tutorial by Joe Marini (via Sam Wan).

Since I left my msdn subscription at the office, I decided to write the app in LZX (from Laszlo Systems) to see how the two compare.

The Laszlo app is 39 lines of code, while the XAML version is 70. While I don't believe that brevity is all important, I do think it helps.

LZX app

LZX code

Independent of the academic interest in the comparison of the two languages. The Laszlo app will, of course, run in your browser today without the need to install extra software or wait for an OS upgrade.

roots of ambition

This is the second part of my response to Anna Fels' thought-provoking, yet unfortunately titled article that was discussed in my last post.

Psychological Foundations of Ambition

Fels introduces a psychological basis for ambition, citing a wide range of research. This provides new insights into how the different treatment of women and girls leads directly to gender imbalance in the workplace. Fels asserts that ambition is fueled by a drive for mastery in the context of recognition:

Approximately half a century after Freud postulated his drive theory of motivation based on sex and aggression, researchers and theoreticians alike realized that a huge portion of behavior simply could not be explained in those terms. Jean Piaget and other developmental psychologists who focused on children's need to master both intellectual and motor tasks discovered that children would repeat a task over and over until they could predict and determine the outcome. Theorists such as Erik Erikson began to posit that at a certain stage, children develop a "sense of industry," or the need to do things well, even perfectly. Robert White, one of the seminal investigators of motivation, named this drive toward mastery "effectance." "It is characteristic of this particular sort of activity," White noted, "that it is selective, directed, and persistent, and that an instrumental act will be learned for the sole reward of engaging in it."

Multiple areas of research have demonstrated that recognition is one of the motivational engines that drives the development of almost any type of skill. In the typical learning cycle, recognition fuels the next stage of learning. The early-learning theorist Albert Bandura was clear on this point: "Young children imitate accurately when they have incentives to do so, but their imitations deteriorate rapidly if others do not care how they behave."

Naturally if someone does not receive positive feedback it is likely to dampen their ambitions. It has been well-documented that in our society girls and women are not encouraged (or actively discouraged) from pursuing many careers and even from many areas of learning.

Luke Hohmann talks about a similar topic in the context of how people become software architects:

"Humans are failure machines. We're not success machines. We're failure machines. We fail all the time. And it's only through processing the feedback of our failure that we learn how to correct for them and do better. That is why it is important to stick with the choices you make and understand how well they worked." -- Becoming an Architect by Bill Venners via HMK's "stciking with it"

One of the wonderful things about software, once you stick to it long enough to get hooked, is that it provides its own feedback. We all need social feedback as well, and it was good to read that Hohmann acknowledges the social aspects of being a software architect.

Call me an optimist. I believe that if we all keep working at treating each other well and fairly, one of these years we'll have a generation that can pursue their ambitions without regard to attributes of birth such as gender and race -- attributes that should have nothing to do with the likelihood of success.

GUI Programming is Hard

Yeah, but so is anything worth doing.

Humans are so finicky -- they want everything done for them, but still have all the control. What's up with that? We're all waiting for that semantic network to lead us into internet nirvana. With a WSDL description for enough SOAP web services and we can write software that will do anything you want, but ... um... you want it to be useful without a 3 day training session or your very own geek to assist you? uh...

I enjoyed Eric Burke's rant (via Evan Williams) and a few more points from HMK. I think it's true that a good GUI just looks so easy that some folks don't value it. It's like a movie soundtrack. To most folks when it's good, the movie just seems like a better movie, and when it's bad, the plot drags and the characters seem to lack depth.

Here's a few more points from my list:

* Good GUI involves interaction design. You can't draw a picture or a flow chart of it. To know if it's going to work you have to prototype it or even fully implement some of it.

* GUI seems more subjective than it is. Unlike a crash or some part of a program that gives an incorrect result, a usability bug can be hard to classify. I've known many folks who would say that if it's just pixels on the screen, the bug is cosmetic, and therefore unimportant. A good UI engineer will classify it as simply "broken." If the pixels are in wrong place, the end user loses confidence and the UI stops working.

* Human interfaces require soft edges. Whether graphical or not, any thing that interacts with humans must be tolerant of mistakes. Unlike machine-to-machine interaction which can be programmed to stay within safe boundaries, humans cannot be expected to do so. There can't be an edge condition which causes you to fall of a virtual cliff. Interfaces which are not resilient to unexpected user behavior often fail to be useful.

creativity and play

"It is the essence of play that a new relation is created between the field of meaning and the visual field -- that is, between situations in thought and real situations." -- Vygotsky Mind in Society

"most of us are so busy trying to solve problems that we fail to notice that in solving problems we sometimes rob ourselves of the opportunity to learn something new." Michael Hamman offers an interesting equation:

Creativity = competence + a desire to create a problem.

I agree that creativity requires competence, or at least confidence. I have observed in the development of software that I experience two extremes. One is where writing software is work. I relentlessly chase a bug. I perfect a piece of code through sheer persistence and fortitude. It can be satisfying, but it is not fun. The other extreme is where writing software is play. I can't imagine that someone pays me for such challenging entertainment. Experimentation yields unexpected solutions. The patterns revealed by the trail of a bug lead to insights. Crafting a solution is a tangible, creative experience.

I often wonder what key factors create the experience of play. When I capture that way of working, I am undeniably more productive. I can see no down side to taking that approach all of the time, except that its not a state consciously achieved. One could argue that some things are just no fun. However, I don't believe that the level of play is inherent to the task.

why is XML good for GUI?

Dan Shafer asks a very good question about Laszlo:

"Instead of direct manipulation of graphical objects to create pleasing interfaces, i get to write XML code (with its extreme overhead burden) to describe how I want the graphical experience to look and feel. And that's a good thing because...???"

I agree that it is counter-intuitive that XML would be a good format for developing graphical user interfaces. I always felt that XML made a mighty fine interchange format -- it's human-readable, almost self-doumenting, and these days if you are working on a large software development project you probably have at least one or two XML parsers already linked in. So... why use it for developing applications?

There are a few attributes of graphical user interfaces that map well to XML:

Graphical user interfaces are inherently hierarchical
Screen real-estate is naturally divided heirarchically. It is convenient for that heirarchy to be represented by the development environment.

Graphical user interfaces evolve
While a hierarchy could be effectively represented in a visual tool, arguably more effectively than it is in an XML file, it is the managing the evolution of a application where XML really comes in handy. It is natural for a design to change over time. In response to user feedback, bugs, or simply by realization of the author, an application needs new features, gestures, or an altered composition. When your design is caught in a visual tool with an opaque file format, you lose the magic of a diff. What happened between then and now?

Graphical user interfaces are often built by a team
XML files are simple text files. Media files live separately and can be linked in by name. Designers and coders can work together on separate pieces of an application without the need for complex group-ware solutions. Coders use the tools they are used to for editing and archiving files. Designers can use the tools they are used to for creating and editing art assets and media files.

Graphical user interfaces require structure
Graphical user interfaces need to be split into pieces to be manageable. XML provides a structured framework which makes its fairly easy to divide your work into bite-sized chunks. A common problem in a visual tool is that people "lose" things. It may be hard to figure out what object a script is attached to. An object that is invisible can be hard to discover or manipulate. In a system where all objects and code are encapsulated in simple text files, anything can be found. The inherent structure of an XML file helps organize an application. There are lots of visual tools that offer a tree-view of XML files which make this structure more approachable.

As an aside, for Dan who "still doesn't get Laszlo," there's a whole lot more to Laszlo than XML. What makes Laszlo cool is its constraints system, animation geared to UI design, client-server data model, effective class re-factoring, and more.

Someday there'll be a GUI tool for creating and editing Laszlo applications. Let's face it: typing in pixel coordinates and RGB values is no fun. Ideally there would be a layout tool that directly created and edited LZX files. Most folks at Laszlo design in Illustrator or whatever and transfer pixel and RGB values to the XML files. By the way, this is often what folks do when building UI for desktop apps.

knowledge is the asset of the future

"Knowledge is the asset of the future, and as companies transition to a knowledge basis, everyone in a company will start to move their knowledge into an executable software form."
-- When Executives Code by Phillip Armour via .NET From India

This interesting article in the latest Communications of the ACM can be found on-line by those who subscribe to the ACM's digital library. Phillip Armour reviews a class for executives who have found that their manufacturing businesses have turned into software enterprises. Software drives processes which have moved off-shore. Modern innovation is in the business process which are encoded in software. He notes that "software development is primarily a knowledge acquisition activity."

Many of the conclusions in the article resonated with me. In particular, I agree with the observation of "the two greatest motivators of the software developer: to learn and to create."

"In businesses where software is the business or the means by which the business is conducted, the job of executives is not to stifle learning and creativity under a blanket of control and process and metrics and status reports. Their job is to create an organization that focuses these powerful forces, and fosters a climate in which they are nurtured and realized."

anonymous programming

I often think about programming as an exercise in naming. By naming functions and objects we can use them elsewhere. Defining a term gives you the power to create other more interesting verbs and nouns. Eventually we provide an end-user with a complex or simple vocabulary composed of mouse gestures or type-written characters.

I'm used to object-oriented programming in C++ or Java. Both languages are driven by procedural code. Objects are created in a series of statements. Everything has a name, even temporary variables, loop iterators, and transient objects that are created to support other objects. I generally have a hatful of conventions which spares me from having to think too much about unimportant names.

Lately I've been working with a declarative object-oriented language (LZX from Laszlo Systems). Objects are created within an XML hierarchy. Many objects that appear on the screen or control other objects are anonymous. I only create names for objects when I need to reference them. It turns out that most objects don't need names.

Since I have gotten used to this unusual declarative style of programming I have found it refreshingly easy to whip up a graphical user interface. Its not that I ever thought that Javascript or even C++ was that hard, despite some cumbersome or awkward aspects of each language. Sometimes, it can be challenging to create software. I didn't ascribe that difficulty to the language itself, but rather to the solving of a particular problem.

LZX allows you to mix in Javascript. Where it is more appropriate to solve a problem with procedural code, you can define methods or include a snippet of Javascript to handle an event. Recently I solved a few problems by writing quite a bit of Javascript. I reflected on why it feels so much easier to declare a program with XML tags, depite the seemingly verbose syntax. Part of the ease of declarative XML is that common patterns are encapsulated in tags, but I think there is more to it than that. It seems that there is a certain intellectual overhead in creating even boilerplate names for transient variables. For me this was an unexpected observation.

processing

I've enjoyed experimenting with the "alpha" relase of processing (via Sam Wan). It's a fun new programming environment which is good at creating freeform animations and playing with colors in space. (There are examplefs of sound and camera input in the exhibition area, but I haven't gotten that far myself.)

Here are two interactive pieces that I made. It was fun to remember trignometry. It has been a long time since I wrote code to animate a simple bounce. Processing let me focus on the core of the pattern without worrying about the mundane details (at least until I had to draw a button). This will be a great teachnig language, and it is quite impressive for an early release.

language is the vehicle of thought

"Thought and language are intimately associated. The expression of a thought is not merely a postscript to the process of thinking the thought in the first place. It's not as if our thoughts exist and grow in some pure, ethereal "thoughtworld", devoid of any manifestation, until such time as we choose to pluck one out of the mist and condense it into base words. No! The act of expressing a thought is part and parcel of the thinking itself. Language is the vehicle of thought." (Chris Crawford)

I have always felt that the ways that we communicate affect how we think. When I was in high school I spoke 3 languages (English, Spanish and German) and had studied a bit of Latin and French. I choose which college I wanted to go to because I was impressed that they taught 13 foreign languages. I was intrigued by the observation that some languages have multiple words for something that another language covers in a single word. It wasn't till much later that I realized that I probably wanted to study cognitive science, rather than spoken language fluency.

In the meantime I majored in computer science. It was practical, yet interesting. (It balanced my impractical other-major of visual art.) I added C++, Pascal and assembly language to my collection. One way of thinking about programming is that it is the act of naming things. In writing classes and methods, we define nouns and verbs. Writing code is the perpetual evolution of a specific language, customized for describing the task at hand.

I agree with Chris Crawford that communication develops thought. The passage above is from his book You Should Learn to Program. I already know how to program, but enjoyed his first chapter. It reminded me of why I like to keep a web log. Writing about a topic causes me to think more clearly about it. I realize that I have more questions and I make connections in my mind. Thought doesn't just happen in your head.

"A clearer view of human intelligence and cognitive development emerges if human-class intelligence is recognized as inherently a socially distributed phenomenon." (Daniel Bullock)

read more top ten reasons for a web log

loosely connected collaboration

For the last few weeks I've been participating in a project that involves multiple people, yet has no meetings, no rules and is a great deal of fun. The process is facilitated by real world conversation and e-mail, but it wouldn't be so practical and so easy without blogs.

It all started back in July - August when Marc Canter suggested that Laszlo build something that bloggers could use, and Oliver Steele prototyped a laszlo blogging widget. Although Marc talked about the project on his blog and we had a few meetings about it at the office, I didn't have a lot of time to dive in and build it. So we talked and I waited for the time that the project would appear in my schedule or get handed off to someone else.

Meanwhile Mark Davis was working on something completely different for his blog. A nav toy that could be paramterized to display a list of links. The project included one hand-painted gradient png and about a hundred lines of LZX code. Dan Lewis spotted it and handily provided some new gradients and a "powered by Laszlo" footer.

I thought it was neat and and wrote about it. Then I noticed an opportunity. I saw a small improvement that would cause me to want to put it on my blog (adding an XML config file). I set out to make that one change, then got excited and added a few others. Later that night I had morphed it into an OPML viewer. Since I was coding quickly I took out all the parameterization and hard-coded the colors.

Marc Canter sees it and e-mails me: "I want one of those - NOW! I can't wait. What do I have to do?" Lyndon Wong tells me that he wants one too.

Meanwhile, Mark Davis has adopted a few changes but wants to keep his HTML parameterization and extolls its virtues in a hallway conversation. I realize that it would be cool to let the other folks pick their own colors, so I go ahead and put that back in.

So Canter puts my OPML viewer on his page, and Lyndon puts Mark Davis's nav toy on his page. Now Marc has ideas of how to glue it into Topic Exchange and the PeopleAggregator.

Its latest incarnation was inspired by David Temkin's suggestion that we should put a "view source" button right in the app so folks can easily get a glimpse of LZX, the language of Laszlo applications. Peter Andrea whipped up some art. Mark Davis came up with a name. What's next?

We're collaborating, but everyone is doing something different. It's really faciliated by the fact that that we're working with a couple of text files and some linked art assets. Each of us is doing not much work, but it builds up gradually. It seems this little project is a microcosm of what a lot of folks are doing with larger prpjects, using blogs as a communications medium for facilitating loosely connected collaboration.

I was interested using TopicExchange, so I thought I would track the history of this project so far as seen in blog posts. I dug up links to various posts and started adding them to a blogbox topic. After 6 entries, the form won't respond. I don't know if its just this topic or a general issue. Yet another work in progress :) I'll check back later. In the meantime, I've posted the thread of conversation as html, if you are interested.