Technorati Tags: flash, programming, ruby
Monday, April 24, 2006
Ruby / Flash Gateway: Alph
I saw a cool demo yesterday of Alph. Alph allows you to use Ruby to control a Flash movie.
Friday, April 14, 2006
The WELL is Down!
My long-time online home, The Whole Earth 'Lectronic Link has been unavailable for several hours now - the longest unplanned outage I can recall in over 10 years.
I no longer have any staff member phone numbers but I called their office and spoke with Gail Williams, Director of Community and she pointed me to http://www.salon.com/wellstatus/ - where recent status info should be available. She also told me that people have sent flowers and left goodwill messages ("beams") on the WELL's voice mail.
Update: Looks like the WELL's command-line interface came back up just before midnight April 14th, Pacific Time.
I no longer have any staff member phone numbers but I called their office and spoke with Gail Williams, Director of Community and she pointed me to http://www.salon.com/wellstatus/ - where recent status info should be available. She also told me that people have sent flowers and left goodwill messages ("beams") on the WELL's voice mail.
Update: Looks like the WELL's command-line interface came back up just before midnight April 14th, Pacific Time.
Tuesday, April 11, 2006
Wanted: Blogging Platform with Revision History
I'd love to have a blogging platform that supports a Revision History of Published Posts:
Desired features:
I'd be glad to help make this happen.
I've posted this in the BloggerDev group - if you are reading this and agree, please go there and post a "me too" comment.
Desired features:
- Each published version of a posting would be saved.
- Readers would be able to see a list of versions.
- Reader can choose to view a specific version.
- Reader may compare any two versions.
I'd be glad to help make this happen.
I've posted this in the BloggerDev group - if you are reading this and agree, please go there and post a "me too" comment.
Technorati Tags: blogging, revision control
Sunday, April 09, 2006
Making Things is a Fractal Process
/*
* All building and making of things involves a fractal (recursive) process
* like this pseudo-code:
* Takes a set of Requirements and returns something new
*/
public Thing makeNewThing ( Requirements requirements ) {
Thing newThing = ();
while ( requirements.not_satisfied ) {
Things requiredPieces = requirements.whatCanWeMakeOneFrom;
Things piecesWeHave =
this.whatDoWeHaveAlready(requirements,requiredPieces);
Things piecesNeeded =
requiredPieces - piecesWehave;
newThing.assemblePieces(piecesWeHave);
foreach Thing neededPiece ( piecesNeeded ) {
piecesWeHave.add( makeSomething(neededPiece) );
newThing.assemblePieces(piecesWeHave);
}
requirements.check(newThing);
}
return newThing;
}
Technorati Tags: construction, programming, software development
Run Windows, Mac OS X, Solaris, and Linux Simultaneously
See: Parallels Workstation: http://www.parallels.com/en/products/workstation/
The folks at Parallels, Inc. have made a real breakthrough - building upon Intel's virtualization feature of their newest CPUs, Parallels allows you to boot into one operating system, and then run one or more others as "hosted" operating system in windows in the primary one.
In other words: You boot into say, Mac OS X, and then run a real copy of Windows XP, in a window. The hosted OS is not running on a chip emulator - each OS is running as a virtual machine.
For example:
The folks at Parallels, Inc. have made a real breakthrough - building upon Intel's virtualization feature of their newest CPUs, Parallels allows you to boot into one operating system, and then run one or more others as "hosted" operating system in windows in the primary one.
In other words: You boot into say, Mac OS X, and then run a real copy of Windows XP, in a window. The hosted OS is not running on a chip emulator - each OS is running as a virtual machine.
For example:
- Windows XP "guest" on Mac OS X "primary"
- Windows 3.11, Solaris 10.0 on top of Mac OS
See also: - jtl's posting: http://www.jtl.us/mt-main/archives/000602.html
- The official Parallels Blog
- Paul Stamatiou's blog has a discussion comparing Parallels to Bootcamp.
Technorati Tags: Mac OS X, virtualization, Windows
Software Development is like Building Construction
The process of Software Development is a lot like the process of Building Construction, and although they also have important differences, these differences are mainly differences of degree rather than kind.
Software folks occasionally make a big deal of the differences between software development and building construction, and building trades/architecture folks often think you cannot do iterative design on buildings.
The fact is, software development and building construction have many important similarities, and many processes that are effective in both.
Both software development and building construction involves the marshaling of numerous interdependent systems designed, built, and assembled by a variety of highly specialized people.
Dependencies
In the software world we have architecture issues (client/server, message-passing, batch processing, micro-kernel, etc.) data structures (databases), business logic, graphic and other user-interface design, etc.
In the world of buildings we have architecture, foundation, frame or shell, electrical, plumbing, wall coverings, HVAC, etc.
Both software development and building construction have numerous layers of dependencies. There are many variations on the actual stack of what depends upon what, but there are always dependencies.
Typical examples of the stack of dependencies in software are hardware, then the operating system, then the programming language, then some kind of data structure, then something to manipulate the data, etc. Buildings too have their stack of dependencies: connection to the Earth (foundation), the load-bearing frame or envelope, utilities, skin/weather-proofing, etc.
Some might say that software may be "built" in many different ways, but that buildings must be built from the ground up. Well, if you think buildings must be built ground-up, do a search for "Linn Cove Viaduct" and see http://www.dot.state.oh.us/se/SI9/19Freeby.pdf, and consider how a space station can be built in orbit.
Incremental Design
These days (early 21st Century) the concept of incremental design is reasonably well known in the software world, and is arguably becoming more popular. There is a long history of incremental design in building - think of the Wright brothers many iterations on their aircraft design and their invention of and use of wind tunnels to test and refine (shall we say "refactor"?) their designs.
Both mathematical and physical models have been in the repertoire of the making process for thousands of years.
These days (2006) we in the software world try to use intensive tests (such as unit tests) and clever modeling in our design/development processes.
Almost 20 years ago I was building full-scale mockups, tests, and experiments of buildings as part of the design process and it works. I was working with Chris Alexander's Center for Environmental Structure and among many other examples of iterative design, complete with unit tests was the work we did on the exterior walls of the Julian Street Homeless Shelter in San Jose ( see this exterior photo of the main building, and this interior of the dining hall - those are sprayed-concrete trusses, also the results of a test-driven design process.)
The exterior wall system went through many iterations, and there were many kinds of tests, of both the visual and physical composition. In each test we would establish a certain standard or required result - sort of making an assertion about the design or structure, and then make a change or build something to implement the assertion.
Some of the tests were physical such as "Is the cover glaze sufficiently free of cracks?" Probably the most frequent kind of tests were tests to verify that a particular feature or system maintained or improved the life in the overall structure. For example, such a test might be "Check that the way the tiles are embedded creates a tangible border that increases the life of the whole wall." And then we would embed tiles using one or another method and check, if the test passed.
Conclusion
The design and development of software and the design and development of the built environment, like all building processes are iterative processes that involve the repeated assembly of existing materials in new combinations and structures, informed by human creativity and driven by human needs and desires. Humans have been building physical structures for many thousands of years, and some techniques have remained essential unchanged in all that time, while other techniques and materials have come into existence more, or less, recently. Those who build - builders of any kind - would do well to learn from each other as builders, and learn to search for the commonalities in our processes, successes, and failures, and to recognize objectively the differences, which are fewer than is commonly believed.
Thanks to Jeff Thalhammer for 'code review' on this document.
See Also
Software folks occasionally make a big deal of the differences between software development and building construction, and building trades/architecture folks often think you cannot do iterative design on buildings.
The fact is, software development and building construction have many important similarities, and many processes that are effective in both.
Both software development and building construction involves the marshaling of numerous interdependent systems designed, built, and assembled by a variety of highly specialized people.
Dependencies
In the software world we have architecture issues (client/server, message-passing, batch processing, micro-kernel, etc.) data structures (databases), business logic, graphic and other user-interface design, etc.
In the world of buildings we have architecture, foundation, frame or shell, electrical, plumbing, wall coverings, HVAC, etc.
Both software development and building construction have numerous layers of dependencies. There are many variations on the actual stack of what depends upon what, but there are always dependencies.
Typical examples of the stack of dependencies in software are hardware, then the operating system, then the programming language, then some kind of data structure, then something to manipulate the data, etc. Buildings too have their stack of dependencies: connection to the Earth (foundation), the load-bearing frame or envelope, utilities, skin/weather-proofing, etc.
Some might say that software may be "built" in many different ways, but that buildings must be built from the ground up. Well, if you think buildings must be built ground-up, do a search for "Linn Cove Viaduct" and see http://www.dot.state.oh.us/se/SI9/19Freeby.pdf, and consider how a space station can be built in orbit.
Incremental Design
These days (early 21st Century) the concept of incremental design is reasonably well known in the software world, and is arguably becoming more popular. There is a long history of incremental design in building - think of the Wright brothers many iterations on their aircraft design and their invention of and use of wind tunnels to test and refine (shall we say "refactor"?) their designs.
Both mathematical and physical models have been in the repertoire of the making process for thousands of years.
These days (2006) we in the software world try to use intensive tests (such as unit tests) and clever modeling in our design/development processes.
Almost 20 years ago I was building full-scale mockups, tests, and experiments of buildings as part of the design process and it works. I was working with Chris Alexander's Center for Environmental Structure and among many other examples of iterative design, complete with unit tests was the work we did on the exterior walls of the Julian Street Homeless Shelter in San Jose ( see this exterior photo of the main building, and this interior of the dining hall - those are sprayed-concrete trusses, also the results of a test-driven design process.)
The exterior wall system went through many iterations, and there were many kinds of tests, of both the visual and physical composition. In each test we would establish a certain standard or required result - sort of making an assertion about the design or structure, and then make a change or build something to implement the assertion.
Some of the tests were physical such as "Is the cover glaze sufficiently free of cracks?" Probably the most frequent kind of tests were tests to verify that a particular feature or system maintained or improved the life in the overall structure. For example, such a test might be "Check that the way the tiles are embedded creates a tangible border that increases the life of the whole wall." And then we would embed tiles using one or another method and check, if the test passed.
Conclusion
The design and development of software and the design and development of the built environment, like all building processes are iterative processes that involve the repeated assembly of existing materials in new combinations and structures, informed by human creativity and driven by human needs and desires. Humans have been building physical structures for many thousands of years, and some techniques have remained essential unchanged in all that time, while other techniques and materials have come into existence more, or less, recently. Those who build - builders of any kind - would do well to learn from each other as builders, and learn to search for the commonalities in our processes, successes, and failures, and to recognize objectively the differences, which are fewer than is commonly believed.
Thanks to Jeff Thalhammer for 'code review' on this document.
See Also
- Review of Christopher Alexander's "The Nature of Order", in Katarxis Nº 3
- A contrary opinion: http://www.agilemanagement.net/Articles/Weblog/ConstructionAnalogyAgain.html
- Another contrary opinion: http://www.jamesshore.com/Blog/That-Damned-Construction-Analogy.html in which James Shore argues that "Ultimately, construction is about dealing with physical objects.", which I disagree with: In my view, ultimately construction is about making things. I suspect that Mr. Shore has never built a building.
- How Buildings Learn: What Happens After They're Built (Viking-Penguin, 1994; in the UK, Orion Books). The author, Stewart Brand says "It was written (and designed and laid out in detail) to change the practice of building and the use of buildings the way Chris Alexander's A Pattern Language and Jane Jacobs's The Death and Life of Great American Cities have done."
- Martin Fowler's Refactoring Home Page
- Here's another disagreeing post - this one from Johanna Rothman.
- George Dinwiddie ponders this issue.
Technorati Tags: buildings, construction, programming, software, software development
Saturday, April 08, 2006
The WELL Gopher
UPDATE - (June 2009) The WELL's Gopher server was decommissioned some months back, but the content is still available via a web server at: https://www.matisse.net/the-well/gopher/
The WELL is an online discussion system that started in 1985. At the very end of 1991, in fact, on New Years' Eve, The WELL connected to the Internet (via 56K connection to BARRNet, router configuration by Erik Fair.)
In those days I was the Customer Support Manager at The WELL and I wanted us to give something back to the Internet community. In those days "anonymous FTP" sites were a common way for organizations to share information with the public over the Internet. I suggested that The WELL create an anonymous FTP site where we would provide access to interesting information, drawing heavily on our association with The Whole Earth Catalog (The WELL was half owned by The POINT Foundation, publisher of The Whole Earth Catalog, and we were in the same building with the catalog staff.)
I recruited a small group of volunteer WELL users to be the editorial staff of the new site: Jerod Pore, Eric S. Theise, Jon Lebkowsky, and Paul Holbrook, and we started discussing what should be in the new site. During this (online) discussion a WELL user who was very involved with the Internet, Ed Vielmetti, suggested we check out this cool new rodent-based technology developed at the University of Michigan Minnesota (the "Golden Gophers"). This new thing was called "gopher", and I immediately saw that it was much easier to use than FTP.
Eric Theise and I had a bit of a fight over that - Eric felt that FTP was the widely used and well known standard and we'd be cutting out all the people who didn't yet have access to a gopher client. I was all steve-jobsian about it "the interface is so much better, people will get a gopher client, this is the future, blah blah blah". I think it was the one place where I strongly asserted my WELL-staff role. We went with gopher.
The content in The WELL Gopher was a direct outgrowth of the WELL's connection to The Whole Earth Review - part of my evil plan was to bring the editorial approach of WER to cyberspace - in fact the top-level categories in the gopher were originally taken directly from the categories that the Whole Earth Catalog used.
There was a point when the WELL gopher and the spies.com gopher were the two hottest places in gopherspace. This all came down to three really important factors:
Notes:
The WELL is an online discussion system that started in 1985. At the very end of 1991, in fact, on New Years' Eve, The WELL connected to the Internet (via 56K connection to BARRNet, router configuration by Erik Fair.)
In those days I was the Customer Support Manager at The WELL and I wanted us to give something back to the Internet community. In those days "anonymous FTP" sites were a common way for organizations to share information with the public over the Internet. I suggested that The WELL create an anonymous FTP site where we would provide access to interesting information, drawing heavily on our association with The Whole Earth Catalog (The WELL was half owned by The POINT Foundation, publisher of The Whole Earth Catalog, and we were in the same building with the catalog staff.)
I recruited a small group of volunteer WELL users to be the editorial staff of the new site: Jerod Pore, Eric S. Theise, Jon Lebkowsky, and Paul Holbrook, and we started discussing what should be in the new site. During this (online) discussion a WELL user who was very involved with the Internet, Ed Vielmetti, suggested we check out this cool new rodent-based technology developed at the University of Michigan Minnesota (the "Golden Gophers"). This new thing was called "gopher", and I immediately saw that it was much easier to use than FTP.
Eric Theise and I had a bit of a fight over that - Eric felt that FTP was the widely used and well known standard and we'd be cutting out all the people who didn't yet have access to a gopher client. I was all steve-jobsian about it "the interface is so much better, people will get a gopher client, this is the future, blah blah blah". I think it was the one place where I strongly asserted my WELL-staff role. We went with gopher.
The content in The WELL Gopher was a direct outgrowth of the WELL's connection to The Whole Earth Review - part of my evil plan was to bring the editorial approach of WER to cyberspace - in fact the top-level categories in the gopher were originally taken directly from the categories that the Whole Earth Catalog used.
There was a point when the WELL gopher and the spies.com gopher were the two hottest places in gopherspace. This all came down to three really important factors:
- Content: We had great editors like Jon, Jerod, Eric, and Paul choosing great stuff. See this great story, "Forces Adrift, a Tale of Our Forces Afloat", by Chuck Charlton.
- Content: We were choosing from a pool of ideas that mapped very well onto the population using cyberspace. Roger Karraker's "Highways of the Mind" article is still relevent.
- Content: We had exclusive content - no offsite links for the first year or so. With maybe a couple exceptions the WELL gopher was the exclusive online location of all the content. This made us editors think more, and choose less.
Notes:
- Gopherspace is part of webspace. "The web", at least circa 1993 was all the resources reachable via (at least) the FTP, gopher, and HTTP protocols. You could throw in WAIS, telnet and maybe a couple of others.
- The WELL gopher used a server that responded to both the gopher and HTTP protocols, so you could reach it with the URL gopher://gopher.well.com/ or http://gopher.well.com:70/ Initially the server only handled the gopher protocol but was soon switched to the GN server which handles both protocols, so even if you mistakenly think that a web site must utilize HTTP, the WELL gopher still qualified.
Saturday, April 01, 2006
The WELL Turns 21
Jennifer made this excellent post about The WELL:
http://fierce.jnfr.com/archives/2006/04/the_well_turns.html
I've been using The WELL since 1987, and it's been around since 1985. If you want to read about it on the web, read this, but if you want to use it, learn to use the command-line interface and and connect to The WELL via SSH, not with a web browser.
http://fierce.jnfr.com/archives/2006/04/the_well_turns.html
I've been using The WELL since 1987, and it's been around since 1985. If you want to read about it on the web, read this, but if you want to use it, learn to use the command-line interface and and connect to The WELL via SSH, not with a web browser.
Tags:
Subscribe to:
Posts (Atom)