The Squeak guys have another interesting looking service deployed - a Monticello based, web accessible source code control system. I can't link to the Seaside blog item directly, due to the fact that SmallBlog doesn't actually provide item links....
Arcterex explains why so many people have Windows Update in the off position:
A font update that may cause me to restart my computer. What the hell? Do they attach that warning to every update these days, or does repacing a font seriously mean that I have to reboot.
Under linux you reboot when you change hardware, update the kernel, or something is completely f***** up and it's causing a hang (normally driver issues, doesn't happen that often, but it does happen).
Under windows you reboot when you change a font. <shaking head> There's that old windows joke about "you moved the mouse, please reboot to continue"... suddenly it's not so funny anymore.
Heck, quitting and updating AIM yesterday resulted in a plea by the installer to restart Windows. I can understand wantiing to restart the app; no problem there. But Windows? Sheesh...
If you have been using the dev stream updates to BottomFeeder, then you may have seen a toolbar related problem. I've had a few people report problems with mode switching - i.e., once they are in "all new" or "alerts" view, they can't switch back to "all". I have a few thoughts on what might be causing this, but nothing definite. In the meantime, here's a work-around. If toolbar options become unresponsive, then open settings, and change the look policy. Then change it back to your preferred policy - that should clear the issue.
Sci Fi Fans have a new series to watch - the new Battlestar Galactica is going forward. The plot looked loads better than the original - I just hope that they get a reasonable effects budget.
As much as I think the Atom effort is a waste, it's going forward, and I support Atom - both the older 0.2, and the newer 0.3 - in BottomFeeder. Dave's torqued because Google (Blogger) is defaulting to Atom feeds now. I think it's a mistake; Atom isn't done, and supporting it this early will simply fragment Atom as effectively as RSS has been fragmented (and we all know how much fun that's been!). Still, the key thing is end users of aggregators - and they don't care. What they want is to be able to subscribe to content, and most aggregators either already support RSS and Atom, or will soon. Google can ship Atom, or RSS, or both - and people won't care so long as they can read the results.
Dare expands on the issues with metadata, and cites a few interesting sources on the problem. Good stuff
Paul Strassman has some interesting conclusions about outsourcing:
- My 1995 assertion that "outsourcing is a game for losers" still stood up in 2002, even though in this case I don't propose to connect the outsourcing of IT with negative profitability. The current findings offer a managerial perspective on the economics of outsourcing.
- My calculations indicate that only 26% of the low profitability results are attributable to outsourcing. Companies already failing for other reasons will tend to outsource increasing amounts of work, thus diminishing their value-added.
- My findings don't support the frequent predictions that U.S. firms will tend to outsource in order to increase profits and thus eventually leave us with a "hollow" economy
It's not that outsourcing causes problems - it's that companies in trouble run to outsource - and such companies, already having process issues, manage the outsourcing as well as they manage everything else (which is to say, not well). Interesting article
Smalltalk Solutions 2004 Is Fast Approaching,
So Mark Your Calendars Now!
When: May 3-5, 2004
Where: Crowne Plaza Seattle
Register Now for Smalltalk Solutions 2004!
To register for Smalltalk Solutions 2004, please visit www.smalltalksolutions.com.
Smalltalk Solutions, sponsored by the Smalltalk Industry Council (STIC), is the premier trade show and conference for Smalltalk users, developers and enthusiasts. This three-day conference and exhibit program will bring together hundreds of buyers and sellers of Smalltalk products and services, while updating the industry on the latest in Smalltalk technologies.
Conference program highlights include:
Key Smalltalk technology exhibitors, including Cincom, GemStone, IBM, Knowledge Systems Corporation, Mission Software, and Silvermark.
Keynote speeches by Avi Bryant of Beta4.com on continuation-based web frameworks, and Lars Bak of OOVM on Smalltalk for extremely small embedded systems. Plus a third keynote that will be announced shortly!
For information regarding sponsorship or to exhibit at the show, please contact Joy Murray or call 1-800-2CINCOM.
For information on participating in the technical program, please contact Alan Knight.
Smalltalk Industry Council
For information on the Smalltalk Industry Council, please contact Allen Davis, Chairman, STIC
For hotel reservations at the Crowne Plaza Seattle, visit www.smalltalksolutions.com/hotel/hotel or call 206-464-1980.
The server got hit with its first dose of comment spam just now - likely though the comment API, but I'll have to take a look at the log files to be sure....
Update: It turns out I was wrong - both were entered via the web form, and both from the same IP address. Which likely means some moron actually went to the trouble to spam two older posts by hand.
So I'm just getting started with my morning catch up on news and email when boom - Eudora up and dies on me. I restart, and it offers to rebuild my inbox index. This is something you have to do, but - if you haven't compacted your mailboxes recently - sucks. I had 2480 messages in inbox - pretty much everything since the last time I compacted. Here's the best part - Eudora, which has some decent filtering capability, won't re-run filtering on inbox. Gah! There went an hour, resorting messages. Grrrrr
The marketing group here has decided that an RSS feed for the press releases would be a good thing. So, I've created a small snippet of Smalltalk code to do that this morning - all I need to do now is get it deployed by the IT guys.
Mark Bernstein comments on the ongoing Atom/RSS silliness, and points to something new:
Have you noticed how little new syndication software is showing up lately?
It's been my contention all along that Atom is nothing but a tax on aggregator developers; it serves no useful purpose as a syndication format, but does manage to create tons of extra work (with more to come - the spec is only 0.3, and people are implementing). Wait awhile, and we'll have as many versions of Atom - and of the Atom API - as we have of RSS. As crappy as the Blogger and MetaWebLog API are (passwords in the clear) - at least there are only two of them....
Resilient releases a preview of their embedded development kit
According to the application filed by Microsoft, the patent involves "systems, methods and data structures for encompassing scripts written in one or more scripting languages in a single file."
"The scripts of a computer system are organized into a single file using Extensible Language Markup (XML)," Microsoft's patent document continues.
The document explained that each script is delimited by a file element and the script's instructions are delimited by a code element within each file element. When a script is executed, the file is analyzed to create a list of script names or functional descriptions of the scripts.
One or more scripts are selected and the code for those scripts is extracted from the file and executed by the appropriate scripting process, the document said. The scripting process that executes a particular script is identified from the scripting extension attribute that is included in the XML format of the file.
Maybe these yahoos should look at the XML based fileouts that VisualWorks has been using since 1999. Just look at the bozo example here - scroll all the way down. Now go file some VW code out.....
BC4J comments on the efficacy of visual cues - pointing out that the 3.5" disk icon is meaningless to his child :) Perhaps it is time to update some of the older icon standards :)
Dare Obasanjo talks about the specs and reality, and the variances thereof, in the encoding of xml docs on the web:
All files are sent with a content type of text/xml and no encoding specified in the charset parameter of the Content-Type HTTP header. According to RFC 3023 which Mark Pilgrim quoted in his article that clients should treat them as us-ascii. With the above examples this behavior would be wrong in all four cases.
He then goes on the list the way a client application actually needs to deal with this conundrum - check for:
- the encoding given in the charset parameter of the Content-Type HTTP header, or
- the encoding given in the encoding attribute of the XML declaration within the document, or
Which is what I stumbled on for BottomFeeder awhile back. I wish Dare had posted this back when I was stumbling in the dark :)
Patrick Logan points to an interesting usage of Squeak by Mitsubishi
This is from one of our internal bug reports:
If you lose your connection (which happens to me a lot), Store will offer to reconnect. In many circumstances this is useful, but if you're in the middle of publishing, it's a very bad idea. In the best case, the publish won't succeed, as you'll almost certainly encounter errors due to data Store thinks it wrote, but which was in a different transaction. Even worse, it might succeed, leaving partial data in the database.
The bottom line is this - if you are publishing to Store and the db connection drops, do not accept the offer the reconnect. Yes, this is an ugly, ugly bug - and it will get addressed. In the meantime, be aware that it's a nasty one...
Martin Fowler discusses the idea of domain specific languages, and relates it to code generation:
I've always used the analogy of creating a DSL to help think about building up a design - developing classes and methods with an eye to making them be a DSL. As much as possible I do this within the language I'm using, but if I can't I'm very ready to switch to code generation. At ThoughtWorks we've used code generation and similar techniques widely on our larger systems. The point at which I pull the separate language DSL lever is clearly different between languages. I never really felt the need in Smalltalk to use a separate language, while it's quite common in C /Java/C#.
I think this is another one of those places were C (etc) developers and Smalltalk (or Lisp, or Ruby) developers talk right past each other. Interesting article; go read the whole thing
Scoble references someone worried about scaling syndication requests:
RSS and Atom feeds are pulled down by news aggregators like the NewsGator I use every hour. Multiply that by 20 million people and that's a bandwidth bill that's many times higher than it is via a web browser (because browsers only visit occassionally, and not every day).
RSS and Atom feeds pull down all the content every time, even content that hasn't changed since last time. Is there a way for him to only send down a feed that's changed, or even better, a partial feed with only new items? (My feed sends down 75 items each time whether new or not).
This is one of the things that already has a stock set of answers:
- Have your server handle conditional-get
- Have your server use mod-gzip
That's pretty much it - it has worked for years to scale the web, and I expect it will work for years to scale syndication as well...
I noticed earlier this evening that my blog page - not any of the other CST blogs - was messed up - the link bar, post footers, and title were all pushed to the right. This was only on IE; I checked with Mozilla, and it looked fine. I was sure that I had dropped a closing tag (or something) in a recent post, so I started looking through the recent ones... and they all looked ok. Finally, I scrolled all the way down the page - and lo and behold, one of the referral links was long - off the right side of IE. I fixed that by having long URLS shortend, and now it's back to looking good again. Yep, HTML and CSS - the replacement for complex client interfaces....
The Buffyverse is closing out - this is the last season of Angel. I've been pretty happy with the way the series has been progressing this year too. This may not be entirely bad news; Buffy lingered at least one season too long, and Boreanaz can't look young forever. Better to go out while it's still going well, but still - one more good show off the air. Can we please have Firefly back now?
Despite that, I'm still not sold on the Traits concept. I'm not sure that sprinkling methods over a distributed set of Mixins would be fun to maintain, on a large scale. The Squeak implementation took advantage of the browser: you only ever see one method at a time in Squeak (smalltalk) code, anyway, and if the browser integrates with Traits, you could view and edit the methods as "part" of the class anyway. With Ruby, without a great IDE, you'd need to flick across files and use a bit of imagination to get a good "view" of your composed class - to even see what methods it's composed of. I believe that traits lose a good deal of their appeal without the Smalltalk browser, or a great Trait-aware IDE.
Interesting that he likes traits in Squeak better, due to the IDE support - one of my issues with traits - or method level namespaces - has been the whole dveloper presentation/understandability issue. It looks like I should grab Squeak and take a look, so that my preconceptions can be addressed with some actual data points :)
Like a lot of people, Sun's Victoria Livschitz confuses strong typing and manifest typing. Here's a quote:
The preventive measures attempt to ensure that bugs are not possible in the first place. A lot of progress has been made in the last twenty years along these lines. Such programming practices as strong typing that allows compile-time assignment safety checking, garbage collectors that automatically manage memory, and exception mechanisms that trap and propagate errors in traceable and recoverable matter do make programming safer. The Java language, of course, personifies the modern general-purpose programming language with first-class systemic safety qualities. It's a huge improvement over its predecessor, C . Much can also be said about the visual development tools that simplify and automate more mundane and error-prone aspects of programming
Strong typing isn't the same thing as manifest typing. Smalltalk, for instance, has strong, dynamic typing - an object simply will respond to an inappropriate message in a completely predictable way. Take Java though - you can make the compiler completely happy with a cast, and then end up with a system that falls down at runtime. Languages like Java and C encourage casting - the rigidity of their libraries, the "final" declarations, the way the collection libraries work - you can walk yourself into trouble with MNU handlers in Smalltalk, but you are picked up and driven there by many existing libraries in Java. Maybe Ms. Livschitz should look at what Sun produces before she makes assertions like the above. Strong typing is a good thing - it's really too bad that Sun doesn't encourage it. What she needs to do is go pick up one of the many fine books on TDD - I'd recommend Beck.
Q: How well do you think modern programming languages, particularly the Java language, have been able to help developers hide complexity?
A: Unfortunately, I believe modern computer science and software engineering have failed to make significant advances there. The syntax of all mainstream programming languages is rather esoteric. Mathematicians, who feel comfortable with purely abstract syntax, spend years of intense study mastering certain skills. But unlike mathematicians, programmers are taught to think not in terms of absolute proof, but in terms of working metaphors. To understand how a system works, a programmer doesn't build a system of mathematical equations, but comes up with real-life metaphor correctness which she or he can "feel" as a human being. Programmers are "average" folks; they have to be, since programming is a profession of millions of people, many without college degrees. Esoteric software doesn't scale to millions, not in people, and not in lines of code.
Fascinating. The current mainstream languages are Java and MS' "Son of Java", C#. Physician, heal thyself. Go download a Smalltalk, Ruby, or Python system. Heck, go back to your very own research labs and look at Self and Strongtalk - see what your company could have been encouraging instead of what it is encouraging. She says she wants to improve things; a trip to Sun's R&D labs, along with some internal evangelism would help a lot.... But wait!
I envision a programming language that is a notch richer then OO. It would be based on a small number of primitive concepts, intuitively obvious to any mature human being, and tied to well-understood metaphors, such as objects, conditions, and processes. I hope to preserve many features of the object-oriented systems that made them so safe and convenient, such as abstract typing, polymorphism, encapsulation and so on. The work so far has been promising.
She really, really needs to visit the Sun research labs. They already have something a lot like that, called Self. It's been around for years, too. Unintentionally amusing, this article... Further down, the "holy grail" of component based development is raised again. I'm not even going to bother quiting that; more tears and virtual ink have been spilled on that subject than anyone can count. I have little faith in positive progress in that direction; reuse is non-trivial, and I just don't see it getting a lot better anytime soon. Take a trip to the Sun R&D labs, and take a look at what Sun has left withering on the vine.
Danny's comments are pretty close to where I came in on the article. I still say that much of what she's talking about exists in Sun's R&D labs, if only she'd go take a look :)
Our marketing folks wanted to put together an RSS feed for Cincom's press releases, but weren't sure how to proceed. All the releases live in a database (SQL Server) with all the info necessary to create a feed - it just had to be put together. This is one of the places that most people would reach for a scripting language like Perl, or something like PHP. I reached for Smalltalk, of course, and it turns out to be pretty simple to support a small job like this in VisualWorks. Here's what I set up
- I created a small, loadable package that reads the data from the DB and dumps it to an RSS file
- The package depends on a small settings file to figure out what to read and where to write
- I created a small (4 MB) Windows executable with the package pre-loaded, and ready to run at startup
On the server in Cincinnati, this thing starts, reads from the db, writes the RSS file, and quits in less than 3 seconds. I was amazed, to be honest. Better yet, it's easily updated from my office in Maryland. If I need to change the code, it can reload the package at startup from an application directory, and then run with the new changes - so if anything big needs to be done (for instance, someone decides we need an Atom feed as well) - it can be updated without my having to make any changes to the executable itself, and it'll "just work" on the next run cycle. It's going to be set up as the Windows equivalent of a CRON job - run every N hours (days, whatever). So brush aside your preconceptions - Smalltalk is easily used for this kind of "small" job!
One of the Planet Lisp guys reacts to the Livschitz article:
I feel like jumping up and down and shout: "Lisp, just use Lisp!". Of course she would't know better. She probably never saw a Lisp Machine, let alone experienced one. It makes me sad/mad just reading it. It's almost as bad as this terrible book by Marilyn vos Savant (the woman with the worlds highest MENSA certified IQ) about Andrew Wile's proof of Fermat's Last Theorem.
Yep. Just like I wanted to hop up and down and yell Smalltalk!
The Red Sox can't close the deal - the Yankees grabbed A-Rod. I love this commentary in the Times sports section:
But what chance do the Red Sox really have of winning on the field? Sure, the teams have to play 162 games, but the Red Sox could lead the Yankees for 161 games and still lose to them. They could have a three-run lead and be five outs from going to the World Series and - oh, right, that happened last October.
Heh. Pack it in, Sox fans :)
We have an update on the keynote speakers for StS 2004 - George Bosworth, one of the architects of the CLR at Microsoft. I'm sure that lots of people in the Smalltalk community would like to hear about the design decisions that have been (and are being) made in the development of the .NET CLR - come on out to Seattle to hear all about it. This year's conference is May 3 - 5 in Seattle, at the Crowne Plaza. Register today - the early registration discount will be expiring soon.
Larkware News has the following rant:
Unification Policy - Alan Shi explains one of the fine points of the CLR's binding policy. I fear I've reached the same point with this stuff that I did with Godel, Escher, Bach: I understand it right after I read it, but my brain can no longer hold on to it. I think .NET has replaced DLL Hell with a binding policy so complex that it might as well be a purely random selection of which DLL to load, for all that an average developer understands what's going on. It is not at all clear to me that this is an improvement so much as just a different set of problems. Or perhaps my brain is just too puny to work at Microsoft.
First, let me state up front that I've not looked at the binding policy in .NET - I will say that the referenced explanatory page is hard to digest. This is not a problem limited to the CLR though - we are in the process of trying to address these issues in Cincom Smalltalk, and it's not a simple set of problems. We are hoping to have the beginnings of an answer out with VW 7.3 (fall 2004)
Scoble worries about outsourcing:
Anyway, Rajesh Jain's weblog points to the New York Times analysis. Do we really need to analyze this? Let's see. Average Chinese worker gets paid about $1000 a year. Yes, that's right. In Bejing the number goes up to $2500 per year. How much are you paid? I am paid a lot more than that. Is there pressure to send my job over to China? You betcha there is.
There's an interesting counterpoint to some of this in the latest ComputerWorld. To answer Scoble's assertion that there's pressure to move a job like his overseas - all I can do is chuckle. He's in a communications heavy job - he's meeting with customers, reporters, and fellow MS staff on a day to day basis as part of his (as I read it) evangelical job. It's far more likely - if MS is successful in India and China - that they'll nee local equivalents of him someday. I rather doubt that a guy in China, many, many timezones away, is hoing to be able to keep up the same communications schedule that Scoble does. Even in the universe of "grunt development" there are issues many people forget:
- Transitory cost increases - from severance costs, declining morale, people jumping ship, travel costs.
- Long term costs - travel to the outsourcers location. If that's China or India, it's not the same thing as a "quick" cross country trip. There's also a soft costs here - what are the spouses of your staff going to think about 2 and 3 week jaunts to the far side of the planet?
- Contract management - if getting agreement on requirements was hard with people a building over, how hard will it be to manage with people 12 time zones and a culture away? Language will not be the only issue here - just the most obvious.
This is not to say that savings don't exist; they do. They aren't going to be as much as most people think though, and there will be communications issues that crop up. Like other trends in the industry this one is no silver bullet - not to mention the fact that we've seen this all before - textile jobs, for instance, went from New England to the south and then overseas. The main difference today is the speed of the transition - software matured and started moving faster than things like textiles did.
It's too bad I'm not in the Triangle Research Park area - I'd love to attend this talk on the Roller architecture - especially the "lessons learned" part. I'm going to be giving a similar talk at Smalltalk Solutions and at the upcoming NYC STUG meeting. I'll be talking about BottomFeeder, but will likely have notes on my blog server as well. I'd be very interested in hearing another blog server author talk about the issues involved in building and deploying a server. Sounds interesting!
Here's a nifty Smalltalk article in JOOP - covering concurrency and how to build new control structures using the BlockClosure class. This is all in the context of the ControlWorks framework, a real-time process control development toolset sold by Adventa. Smalltalk is used in the most amazing places :)
Patrick Logan makes some excellent observations about security, closed source, and open source, ending with this:
Open source that is poorly designed is not safe. Closed source that is poorly designed and then released in the open is even less safe.
That's an excellent point, and - in a nutshell - the problem that MS faces with Windows
There's a 3.3 stream and a dev stream update available for BottomFeeder. I ran across a bug report from Peter, and found an issue in the display logic for feed items that came from Atom with only the summary object filled in. I issued a bug fix, and now his feed can be viewed just fine. Thanks for reporting the bug!
This article goes a long ways towards explaining what's so cool about Smalltalk, without ever even mentioning it. After talking about the Dorado and the Star (and what differentiated them), this example explains it:
At best I think most people ask "What could people do with this computer". That's a very different question from "What people will people do with this computer"... there are so many nifty features that if people pushed themselves they could use, but have a high enough barrier to entry that people don't bother.
Example: I have a nice thermostat in my apartment. Its fairly well designed and has quick push buttons for "Daytime", "Night" and "Vacation". It was even straightforward to set these to my preferred temperatures for "In the apartment, awake", "Out of the apartment or asleep", and I haven't bothered with the vacation button. Now I have noticed that I don't like to get out of bed in the morning because it is sort of cold. In fact, sometimes I'll lie in bed for 30 minutes because its cold, which is a big waste of time (I'm not very rational when I'm waking up). I have noticed that my thermostat supports scheduling changes between day and night temperature. I even looked at the instructions beneath the faceplate, and it looks like it'd be fairly easy to program. But I haven't done it. The device is usable in the sense that if I wanted to, I could program it, and probably get it right on the first or second try. Its not hard to use. But its a little too inconvenient, because I'd have to special case my weekend schedule, I'd have to set several different times using the fairly slow "up", "down", "next item" interface for setting time (on most alarm clocks etc). The point is, its not hard to figure out, but its stills too much hassle. So while I could program the thermostat, I won't. There's always something that seems better to do with my time, and I can't be bothered (even though rationally I know it'd be better overall if I just program the silly thing).
In a nutshell, that explains the difference between the way Smalltalk or Lisp developers work, and the way C, C++, or Java developers work. It's hard to create tools for the environments that curly bracers work in (excepting Emacs - many people working there write elisp macros to help themselves). Sure, you can create Eclipse plugins - but how many developers actually do it? It's a fair bit of work, and takes effort that most people won't expend (like the thermostat). It's not a matter of can't; it's a matter of won't. Smalltalkers are always making little tweaks and additions to the environment - because the barriers are low. This is one of the reasons I favor image based development - it lowers the barriers for productive twiddling.
ISerializable is writing a series on adding scripting to an application. The reasons he gives for it are good ones:
Adding scripting support to your application is one of the most valuable things you can do for your client, letting them add value to your software, and keep it current over time with little or no overhead from the developers. Your users will be able to modify behavior at runtime, change business rules as the market changes and fix subtle bugs as they appear until better fixes come along in the form of compiled code. It is one of the most powerful techniques today employed my many varied business applications. But guess what? Its not very easy to do in .Net.
Now for the punchline - BottomFeeder has scripting support - on all supported platforms - in the same language the application was built in. And I didn't need to do anything to add it. All I had to do was deploy the application without removing the compiler. Here's how you can use it at startup - create a Smalltalk script, and save it in a file called ".btfrc" - put that in the same directory with the application. At startup, that script will be loaded.
I don't have a nice way to pop up a runtime workspace, but it can be done - Vassili explained how. So yeah, adding scripting support is a very nice thing - take a look at what Bob W does with it, for instance. I'll be interested in seeing how one does that in .NET
I saw this in cls and the Camp Smalltalk mailing list - Camp Smalltalk near Portland, OR:
I'm pleased to announce that we will be holding a Camp Smalltalk from July 18-23 2004 in the vicinity of Portland, Oregon, USA.
To finalize our space reservation, we need to place a deposit on a minimum of ten sleeping room reservations. We expect more than that to attend, but we need at least ten definite attendees to step forward and send in a deposit now. We must receive the minimum number of deposits BY MARCH 5. If you want to make a reservation, see below for details.
Camp Smalltalk. Smalltalk enthusiasts spending several days in small groups collaborating on a number of open-source projects to benefit the Smalltalk community. All Smalltalk dialects welcome. For more details, see http://campsmalltalk.com
Smalltalk enthusiasts. All experience levels are welcome, from "Using Smalltalk for more than 20 years" to "Fascinated by Smalltalk, but never really used it."
Afternoon of Sunday, July 18, through midday Friday, July 23
Troutdale, OR, USA
The main cost is the lodging and meals package at Edgefield. You're responsible for getting yourself there. All prices given include room, meals, gratuities, and tax for all five nights, and are in $US.
Single-occupancy King or Queen or Double Queen room: $600 Single-occupancy King or Queen or Double Queen Suite with bath: $952.50
Double-occupancy King or Queen or Double Queen room: $530 per person
Double-occupancy King or Queen or Double Queen Suite with bath: $787.50
There are very few rooms with two beds -- if you want one of these rooms register soon.
We're looking into high-speed internet access, which would have some additional cost. We will not commit to additional cost without the approval of those who have registered.
McMenamins Edgefield, Troutdale, OR, USA
A 15 minute drive east of PDX, the Portland Airport
It's right on the edge of the Portland Metro area, five minutes from the hiking and waterfalls of the Columbia River Gorge. It's easy to reach by public transit from either PDX or downtown.
A private brewpub-based resort at a lovingly and quirkily restored historic campus of buildings -- lodgings, restaurants, brewpubs, winery, gardens, movie theatre, and more. Even a little golf course. Filled inside and out with interesting artwork http://mcmenamins.com/Edge/art.html). Even a working hot glass studio on the grounds. Hillside location with views across the Columbia River.
We'll be in the main ballroom, which is generously sized (36x68 feet, 11x20m), on the second floor of the main lodge, with many windows on three sides and a huge mural on the walls. The view is away from the river.
Mostly European-style rooms, with private baths down the hall. Some suites with bath are available at a higher rate (see above). Most rooms have one bed. A few two-bed rooms are available -- send in a deposit soon if you want one of these.
Meals are included with room. If we eat in fairly small groups in their restaurants, they'll give us vouchers good for up to a specified amount for each meal. The Black Rabbit Restaurant (http://mcmenamins.com/Edge/brabbit.html) is very good, and the Power Station Pub (http://mcmenamins.com/Edge/pub.html) also has good stuff. Voucher amounts will be $10.50 for breakfast, $16.95 for lunch, $26.25 for supper.
On-site: Golf, evening movies, wandering around looking at interesting stuff (brewery, winery, distillery, artwork).
Fairly short drive: The Columbia River Gorge
(http://www.fs.fed.us/r6/columbia/forest), with hikes and viewpoints for amazing waterfalls and volcanic cores, Bonneville Dam, mountain viewpoints and more hikes. About the same distance to downtown Portland.
Longer drive: Mount St. Helens, Mount Hood, boardsailing or kitesailing on the Columbia, etc., etc.
To register, print out the registration form available at http://wiki.cs.uiuc.edu/CampSmalltalk/Camp Smalltalk Oregon 2004 and send it with your deposit to:
1260 NW Waterhouse Ave, Suite 200
Beaverton, OR 97006 USA
To help us reach our minimum, and to guarantee you a room, we must RECEIVE your deposit by MARCH 5.
For details, check the FAQ below, or the latest info at http://campsmalltalk.com
FREQUENTLY ANTICIPATED QUESTIONS ABOUT REGISTRATION
Can I pay by credit card or purchase order?
We are using Edgefield's special "midweek retreat" package, so they cannot accept payment directly from individual participants. We must make lump payments, so an individual is coordinating the payments.
When will the remainder of the payment be due?
Final payment must be received by July 12. Again, check or money order in US$.
What if I can't make a commitment now, but I decide later that I can attend?
We will have a reserved block of sleeping rooms for only the deposits received by of March 5. Some rooms will probably be available until sometime in May or June. After March 5, check http://campsmalltalk.com about room availability and how to send a deposit.
Is my deposit refundable?
If we cancel the planned event on March 5 due to lack of deposits, all deposits will be refunded. If you have to cancel after March 5, we will try to transfer your registration to someone who registers later. If that is possible, you'll get your deposit back. If not, you will not get your money back.
Can I participate in the Camp Smalltalk sessions without staying at Edgefield?
Yes, provided we have enough people in paid sleeping rooms. If you are not staying at Edgefield, you can still buy meals at the Edgefield restaurant or pub. If you plan to attend but not stay at Edgefield, please send email to Martin.
What if I have more questions?
Get the latest info at http://campsmalltalk.com
Blaine Buxton has a few words to say about the all too common perception that developers are interchangeable:
I've always been bothered with the notion that programmers are interchangeable parts. Technical managers that I have had seem to think we are all the same. Cut from the same tree if you will. Am I the only one that thinks this is hog wash? Like anything in life, there will be people that rise to the top of their field and be the best there is. But, it seems people think that programmers are all the same. I find this bothersome. I've known managers that thought they could pull anyone off the street and in 6 weeks have a good programmer. Would we expect to do the same with musicians? Just pick anyone off the street that knows nothing about music and expect them to play a mozart concerto flawlessly after the same period of time? I think the answer would be no! Would we expect to take even a first year english student and expect them to write poems the caliber of William Shakespeare? HELL NO WE WOULDN'T! So, why do we expect the same from programmers?
Blunt, but very much on point. Maybe we should start assuming that senior managers are interchangeable. When that gets the obvious objection, let the other shoe drop...
India's Linux for You magazine spotlighted Smalltalk in the January edition. I can't get a link to that month; their archives seem to be confused. Here's a quote from the article:
If one peers around the Smalltalk classes written entirely in Smalltalk, you would notice the strong Unix base that carries through. For instance, in the sockets code you have a complete re-implementation of the BSD sockets, and process creation is the very familiar fork calls with the simplest threaded call implementation. This makes the language a lot more familiar for the Linux user.
Being platform independent, nearly all dialects of Smalltalk support Linux. The major ones include:
Smalltalk X: A commercial version having an efficient compilation system that can compile to a C level binary code once the development is done.
- VisualWorks: Currently the most aggressive Smalltalk platform. It is supported widely by both enthusiasts and corporate development and is now positioned as a 4th generation application development platform
- VisualAge: The IBM version that has been the industry favourite for over a decade but is now taking a back seat to IBM 19s Websphere.
- Squeak: For open source enthusiasts, academics, and especially school kids, this is the best. It lacks features for corporate level multi-user, scalable solutions but touts the new Morphic UI architecture.
- GNU Smalltalk: An efficient, mature and contemporary implementation.
Very cool to see more trade press notice!
Via Scoble comes news that intel has cried uncle in the 64 bit market - they are unveiling a 64 bit x86 chip:
Intel Chief Executive Craig Barrett said today the chip maker will offer a new version of its Xeon chips for the low-end computer server market that will mimic the capability of chips from rival Advanced Micro Devices.
The company said the new chip currently code-named Nocona, offers the 64-bit capability found in AMD's Opteron family of chips for servers. This spring Intel will offer both a Xeon for low-end servers and a 64-bit version of its Prescott Pentium 4 chip for workstations with single processors.
I like the attempt to salvage their pride over the itanium by claiming that this is only for the "low end" server market...
I'm on my way to NYC to speak at the NYC STUG about BottomFeeder. Like any speaker, I'm doing my slides at the last second (on the train!). I actually had various parts of the presentation "lying around", but they weren't really in a coherent whole for a technical presentation yet - so I spent mch of the ride doing that. That's one of the things I really like about taking Amtrak to the city; I have time to get work done - and I still get to Manhattan faster than I would by flying. I was kind of hoping to find some WiFi on the trip, but I expect that I'm moving too quickly, and too far away from residential areas to boot...