Whole Team

I am going to bring together two of my loves: baseball and software. Why? Because the College World Series is over, and I am suffering withdrawal. Also because the OSU Beavers won the CWS for the second straight year not because they had any particularly premier individuals, but because they *practice* "whole team".

When you play "small ball" you have to play as a team. OSU often scores runs with two outs, and the just as often prevent other teams from scoring with two outs, and prevent teams from scoring as many as they expect with runners on base with less than two outs. OSU also gets results from up and down the lineup and all around the field. They win on team fundamentals: their luck is too good and consistent to be attributed to luck. Their confidence that flows from their solid *team* fundamentals simply destroys their adversaries from within.

I wish I could draw some fantastic analogy between "small ball" and software development. The best I can do right now is that software development also depends on the whole team *practicing* together the team fundamentals.

...judging by crowd reaction and amount of orange worn in the stands, Oregon State seems the local favorite.

"They play small ball, and they do all the little things right - that's why," said 25-year-old Blake Armanees of Kansas City, Mo. "I didn't go to Oregon State or anything thing like that. But I've watched them for the past few years, and they've been dead-set on doing the little things right." (www.cstv.com)

Part of OSU's success is also keeping the end in mind: knowing where you need to head as a team and dedicating yourselves to getting there. After OSU won their super-regional match...

The Beavers didn't greet the end of the game - on a double play - with the euphoria of a big pile at midfield. They merely walked through their own handshake line, then one with Michigan, and disappeared in the locker room.

"We figure," Canham said. "you only get one dogpile a year. We're not going to waste it until the big one." (Photos below.)

"Whole Team" is an agile software development practice that is given short shrift. Practicing test-driven design is a snap compared to practicing "whole team". The main reason is we don't understand what it means, and so there is little hope of practicing it. The following phrase from "Getting to Whole Team" captures "whole team" better than any other I can recall...

On a good team, a business problem feels like everybody's problem, and a technical problem feels like everybody's problem. Regardless of my individual problems, I can rely on the whole team to help me solve them.

That article concludes...

In the software world, without a Whole Team, we really don't have anything. We're dead on square one. We should treat the creation of a Whole Team as vital and primary. We should get out of the habit of talking abstractly about the nature of a Whole Team, and talk and think about it more concretely, in terms of the practices that produce it, and in terms of how we can measure its quality in the reactivity and equanimity of individuals and groups of programmers and customers.

OSU Dog Pile 2006...

OSU Dog Pile 2007...

Several team members new this year said a signature event that sealed their decision to join the OSU team was seeing the 2006 team's dog pile. And they all noted that during their regular-season slump, they never lost sight of that vision even while those outside the team gave up hope of the team even getting into the 2007 post-season at all. This year's repeat champion is the only team with a losing conference record to win a national championship. They were the last team selected to participate in the post-season. Stumbling along the way may be *good* for your team!

Even after a string of losing seven of nine Pac-10 games late in the regular season, the Beavers maintained a family atmosphere, providing support for one another.

“Everybody doubted us, but we didn’t doubt ourselves,” shortstop Darwin Barney says. “I hope teams in the future can learn from this, that it takes belief to make it happen. This club really showed that.”...

When Oregon State fell behind in the first inning of Sunday’s North Carolina game, it was the first time the Beavers trailed since the second inning at Virginia on June 5. The deficit Sunday lasted for a half-inning, meaning the Beavers were behind for a half-inning over the last 70 they played in the postseason. (portland tribune)

And...

Asked to explain their postseason success after a 10-14 Pac-10 season that left them in sixth place and barely eking out an at-large berth to the NCAA playoffs, both Ogata and Barney pointed to their team’s ability to focus and stay calm.

“We really felt like we were home there, on the field and in the dugout,” said Barney, one of only two returning starters among OSU’s position players on the 2006 World Series championship team. “There was an amazing calmness on our team and throughout our dugout.”

“It was our mindset, that special feeling — we were just going to go and win,” Ogata said. “The guys on this team are people you want to go to war with. You just knew people were going to come through.”

Teamwork

Fuzzy wrote about the final game of the College World Series. The Beavers won. I write this in case your corner of the world is not rejoicing as loud as ours. I've got the games on Tivo and I've been going back for the third and fourth time watching the double plays, the throws to home, the clutch scoring with two outs. So many firsts for the Beavers in this series, even more incredible than last year's team, which had a few of its own.

This photo goes back a few games in this year's College World Series, but it's a great shot of a fantastic double play. The kid is a freshman. Look out.

As it turned out I was on the Oregon State campus Monday. I was in a building across the street from the site of the celebration when the team arrived back from Omaha. The people leading the meeting wanted to be at the rally, and so did most of the attendees. So we headed over there, and here I am.

Ruby Porn (Safe For Work)

Tom Ruminates...

Ruby has many cases in the parser where a construct can be just about anything. Check out this default value abomination...

I don't display pornography on this site. You'll have to follow the link!

Actually, you'll have to decide if it *is*, in fact, safe for work.

Actually, the spec work taking place via the JRuby effort will prove its worth. CRuby may not be strictly compliant when the spec'ing is all done.

Beautiful Vision

I'm assuming you've seen the guided tour. I love this quote...

Try telling your CEO the iPhone doesn't play well with your IT systems.

The design that went into this device is simply beautiful.

I love my company-paid crackberry with unlimited data plan. But, wow, it's hard not to get in line for an iPhone on my own dime. I guess I can let it shake out for a a bit.

Making It Stick

Pivot looks cool, and Joe's kid, creative if not non-violent. :-)

God I Love Lisp

link

Open Comments

FYI -- one no longer has to "register" to comment on my blog.

AMQP

That ACM Queue pdf I linked to in my next-most-recent post also has an article on messaging with the AMQP standard. I've not read it yet though. In case you are interested, here it is..... the PDF file.

Stonebraker

Get it while it's hottt... a simply dazzling and entertaining interview with Michael Stonebraker about all kinds of database topics and more. (Here is the pdf, other formats apparently not available yet. This may be a hole in their subscription service for current issues? Anyway.....)

One of the things I find fascinating is that we’ve been writing software for 30 years and the tools we have to create reliable software are not significantly dissimilar from what we had a long time ago. Our ability to write reliable software is hardly any better now than it was then. That’s one of my pet peeves.

Unstable At Any Speed

Just a reminder to make all our future software of all stripes more resilient. We have to make that easier. Microsoft Watch captures a crashed kiddie ride at some store...

XMPP DevCon 3

XMPP DevCon #3 is in a few weeks, down the street from my office, coincident with OSCON.

"Bonjour, XMPP."

From http://blog.xmpp.org/...

Today we advanced XEP-0174: Link-Local Messaging to Draft in our standards process. This specification defines how to send XMPP messages in a serverless mode via zero-configuration networking (a technology created by Apple Computer, originally called Rendezvous and now called Bonjour).

To be clear for us newbies to Bonjour, there are implementations like the one from Apple, but it is also a standard, or maybe more accurately a set of conventions for using some IP standards. So it is not like "using something from Apple" which may be less appealing to some than "using some IP networking standards".

Anyway, that said, this is kind of interesting. We've been looking at various intersections of grid computing and messaging. If you have a number of processes coming and going, not too far from each other, and some of them need to find each other to exchange some information, this might be a way to do that.

Common Solutions To Common Problems

Stefan Tilkov and Marc de Graauw debate the advantages to rest.

Here's another aspect to the question: no matter how much caching is used (now or perhaps later) there is a lot more to HTTP, and there is a lot of open and high quality software for HTTP. So why not use common solutions to common problems?

iPhone and Safari SDK

Stefam Tilkov notes...

Had Apple chosen to build a ‘real’ SDK (i.e. using Objective C/Cocoa), only Mac developers would have been able to build iPhone applications — this way, and with the accompanying release of Safari for Windows, there are millions of developers who can (and will) build them...

I fail to see what’s wrong with this, because Safari will allow interaction with the iPhone’s features — you can make calls, access contacts etc. What more could one ask for?

Purt near brilliant, really.

Wish iPhone would support Flex though. :-)

Beavs Return to Omaha!

How'd they do it? Pitching. Defense. (Amazingly the Michigan team batted over .300 through their lineup, top to bottom. Until this super-regional series, where they hit below .200.)

And Small ball. (Read the same summaries below to see how they scored the last two games!)

The Oregon State Beavers are the defending national champions in NCAA baseball. But they lost all but four players from last year. Only two of those four were starters.

This year they went into a three week slump within their Pac-10 schedule, and slid way down those standings. No one really expected too much from them. Their overall record (and perhaps recent history) got them into the regionals as a three-seed.

But just as they clawed and scratched their way last year to the national championship up through the loser's bracket, this year they found their way back to the College World Series in Omaha for a third straight year. (Portland Tribune, ESPN)

Previous year champions often do not return to Omaha. The Beavers are clawers and scratchers.

They won three games in 24 hours to win their regionals. Then in the super-regionals against Michigan they won a *fantastic* game on Sunday 1-0, scoring in the ninth on their only hit, a single to the opposite field.

Today they just clobbered Michigan, 8-2. (Well, sort-of -- the Michigan pitchers gave up some really bad bases on walks, hit pitchers, and balks. And hits.) The College World Series starts on Friday. The Beavers are a long-shot, but last year they were as well.

Go Beavs! Thanks for all the great baseball. And thankfully there is more to come this season. If you want to watch fun baseball, watch the OSU Beavers in the CWS on ESPN.

Flex 3 Deep Linking

The new beta of Flex 3 takes another step or so to resolve webbiness issues. One is becoming more open. Still it's not HTML, but heading in the right direction.

More immediately pragmatic is "deep linking" so the problem of Flash/Flex being a blob of unlinkable bits is significantly less of a problem.

Neet-o. I still think it's better to view a Flex app as kind of like a "browser executable" that reads webs of resources as would any other web client. But doing this *and* being able to deep link to within that "browser executable" is something.

This is most useful when the application is is behaving in ways not easily implemented in Ajax.

Epidemic Algorithms For Replicated Data(base) Maintenance

Fun reading via Werner Vogels via Dan Creswell.

Dinosaurs Online

Also from IEEE... http://dsonline.computer.org/

Is it kind of telling when a publisher puts the phrase "online" in their url? And then the lead article for the June 2007 issue is the best paper from some conference in 2006.

I'm just sayin.

From The Horribly Slow Lead Time Department

IEEE publishes something about an Enterprise Service Bus.

Whew. Just in time! ;-/

I'm just sayin.

Mac Attack

I need to sms my son before he buys Windows for his new MacBook Pro. He was doing so for certain games, but may not need to after all...

Citing that EA customers were moving to the Mac in droves, EA announced that it would once again begin developing games for the Mac platform with simultaneous releases as their Windows counterparts. Command and Conquer 3, Battlefield 2142, Need For Speed Carbon, and Harry Potter & the Order of the Phoenix are coming in July 2007, with Madden 08 and Tiger Woods 08 to follow.

The world keeps nibbling away at the empire. Oh, there's that thing about Safari being released for Windows too.

Microsoft Watch asks if we need another browser on Windows. Yes, if it is from Apple. Maybe IE and Office will whither away due to suckage. Apple moving software to Windows can only help. Maybe Keynote will be next? Competition is *healthy*, remember?

Apollo, Now AIR, On Tour

I just signed up for the July 12 AIR thingy in Portland.

Here's the whole tour page.

All kinds of news about Apollo/AIR, Flex, etc. from Adobe today.

Making The Point

Stu Charlton makes a strong case for why WS-SOAP will never get beyond its current level of development.

The entire fiasco should go down in computing lore as an epic tragedy.

But the most interesting statement from his post is this...

WS-Eventing isn't really implemented or ratified. So there's still a lot of room for MQ, JMS, TIBCO/RV, etc.

Apparently some lessons are hard to learn.

We've now all learned no one in their right mind, vendor or customer, should be investing in WS-SOAP. Furthermore, we should all *immediately* begin extrapolating the lessons learned over the last few years.

Why would anyone, vendor or customer, invest in *any* of the above listed messaging technologies?

OK, if I ran a trading floor with a lot of value moving around constantly I would give RV a look. But under no other circumstances.

If I had any of these already in my data center I would already have a plan in place for isolating and ultimately obsoleting them. Any minor investments would fall under the category of "regret".

HTTP, XMPP, maybe AMQP, and very few others would be on the short list.

Cheaper Than Tibco

Bill de hÓra observes...

it's probably not the kind of message bus you have in mind

Plus he's given us the over/under on Scala hitting Google's front page. (It's not on mine yet either.)

From the referenced post by David Pollak...

In many ways, Scala is blend of a lot of these good worlds. I like that I could choose to blend Actors, servlets, and all the other stuff that's part of the Scala world. It means that I have a choice about how I solve a problem. I hope you've enjoyed my solution to the "scaling Twitter problem." I hope you'll enjoy how the Erlang/Erlyweb folks solve it with their chitter project.

It's Too Wii-alistic

Is the combination of "mature" rated games and the Wii's "naturalistic" controller just too much realism? Some think so, as reported in qj.net. One person calles it "a murder training device".

M-rated games coming to the Wii are expected to be criticized and contested. Manhunt 2, in particular, is receiving much word from anti-game lawyers. In an interview by Fox News, Florida Attorney General Bill McCollum talked about the game's Wii version requiring players to slash and stab using the Wiimote...

Looks like Super Smash Brothers Brawl will take some heat too, since it encourages kids to beat the crap out of their friends and throw them out the stage. Nintendo is not fazed, stating that games simply have different audiences just like movies, televisions, and books. Don't let the kids touch Manhunt 2, problem solved.

Let's not bring common sense into the equation, shall we? Or maybe we should force the players of "mature" games to use those old fashioned controllers with mini joysticks and all kinds of buttons so they remember *It's Just A Game*!

Open (and Linux) Wins The Home Again

I learned about this cool device reading Edd Dumbill's blog.

I've been astounded at the applications people have devised for this little box. Being fairly cheap makes it a great candidate for home automation projects. It's a great example of how limiting resources fosters innovation. Remember how games on 8-bit microcomputers were so much more ingenious than those on their more well-resourced successors?

The NSLU2 is another one of those Linux-based devices for the home and small businesses. They always seem to cost about $100 USD which makes them fairly easy to buy for people (at least me) running home networks already. Fry's has this one, which is just down the road a bit from my house.

I don't really *need* another network storage device, but this one has some really useful hacks, which Linksys acknowledges to be OK and not completely out of line.

Open (and Linux) wins again. Companies that find ways to leverage (and contribute to) common, open platforms appeal to me.

Companies that don't, don't. And so I was also pleased recently that my son chose a new MacBook Pro as his high school graduation present. Although he will be spending his own hard earned money to run Windows on Boot Camp for some games. His choice. I sure am envious of that laptop though. Nice choice!

Watching Out For Lolcats

Learning is fun generally. Learning about the APP and the Atom format can be fun specifically. For example, did you know...

valuable formats - ones with media types, and not just the usual blogging suspects - are properly supported in APP. Lolcats won't be a problem.

See what I mean? This is good news even for us dog lovers. :-)

Finally a general observation that has nothing to do with cats or dogs, but is worth repeating at every opportunity...

Going custom will up the overall design and engineering dollars spent. Companies, even big ones, are resource bound so each engineering dollar spent on publishing infrastructure is a dollar not spent on a cool feature a user might care about. You want to be sure it's the right thing to do. For those integrating against such a provider you probably want to keep custom formats/protocols at the edge and convert them to open models for that internal use.

Can iTunes Accomplish What Jini Couldn't?

Frank Sommers reflects on Walter Mossberg's. First Mossberg...

Out of the box, each copy of iTunes looks for other shared iTunes music libraries on your local network. It doesn’t share your library unless you authorize it to do so...

If you use Sharing, you’ll see in iTunes’ left-hand panel a list of shared libraries on other iTunes-equipped computers on your local network, whether they reside on Windows or Macintosh computers...

[As] I write this on a Mac laptop in my home office, I am playing a song that resides on a Windows Vista desktop PC in another room. To achieve this feat, I didn’t have to fiddle with the often confusing network settings... I just had to use iTunes on both machines and click a couple of buttons.

In effect, each copy of iTunes, with the user’s permission, broadcasts a sort of beacon that signals its presence to other copies of iTunes on a local network, regardless of the operating system underneath. It makes the operating system irrelevant.

And now on to Frank Sommers...

The notion of network services advertising and discovering each other, forming spontaneous, often impromptu, relationships, was at the heart of the Jini vision. While Jini may well experience a resurgence due to Sun recently donating the Jini codebase to the Apache Foundation, Jini itself never gained the wide distribution that Apple's similarly-purposed network technology already enjoys. The Jini community has debated for a long time Sun's role in Jini's general acceptance, or lack thereof. While licensing may have been an issue, in my opinion there have not been compelling enough Jini services to entice users to install and use Jini. By contrast, iTunes users who care only about being able to listen to or purchase music online, have downloaded and installed Bonjour to the tune of several hundred million hosts.

In addition to all those PCs, and every Mac, hundreds of different types of devices provide Bonjour-based networking capabilities, and new Bonjour devices come to the market all the time. Perhaps the most anticipated one will be Apple's own iPhone. Given all these devices, including a large number of PC desktops, it seems that a widely available spontaneous networking platform is now available. The question now is what developers will do with this new platform...

Adobe's Creative Suite 3 and Skype, to mention two examples, started to use Bonjour to facilitate local-area collaboration and discovery.

As Bonjour inventor Stuart Cheshire demonstrated in an hour-long Google TechTalk presentation (Flash video), Bonjour can be used to advertise and discover networked services over the WAN as well...

Bonjour simply extends the existing DNS mechanisms, and uses a service's protocol type, defined as a string, in service discovery. There are now several hundred service types described this way, from HTTP and SSL to the MYOB accounting software and the Sybase database server. If a client can talk a certain protocol, it can use Bonjour to discover and invoke services capable of communicating over that same protocol.

Bonjour goes beyond Jini's registration and lookup... Bonjour is zero config. Have you seen the Jini configuration mechanism?

Perhaps the next major revision of Jini, should there be one, would use Bonjour at least as an alternative to much of the Jini registration and lookup, and other configuration such as the various HTTP ports, etc. Bonjour uses DNS SRV records to indicate what port to use for what service, and so there is no fighting over port 80, or 8080, etc.

Stuart Cheshire points out in the video linked above, AppleTalk had all this zero configuration for network addressing, naming, and discovery. Bonjour is the result of figuring out that IP has the same capabilities...

And that was the breakthrough: realizing that we can do service discovery using the semantics of DNS queries, and we don't need to invent a new protocol. And then we can run that DNS over the multicast DNS support that we've already created.

Bonjour has each service run just a wee bit of DNS and negotiation among peers to avoid having a DNS server and configuration, etc. Amazing. It's probably time to begin incorporating this stuff into our systems.

And the WAN / unicast stuff can work the same way via the DHCP or other static information. Fun. We can accomplish what Jini couldn't, or hasn't yet.

Scala Implicits

I am continuing on my Scala learning curve. Scala continues to feel like a pragmatic sweet spot among programming languages. My most recent find is "implicits".

One of the pleasing aspects of dynamic languages like Common Lisp and Smalltalk (and so Python and Ruby) is the ability to extend objects that the system or some other programmers implemented, as if they were your own.

Languages without this capability force programmers to create "utility" classes. These extensions would have been in Object or String or Whatever, but the language would not allow extensions, so, here, take this StringUtils class or WhateverUtils class and use that with a String argument or a Whatever argument.

Scala is compile-time type checked (with type inference along the lines of ML and Haskell), so getting into the guts of a class and mucking at runtime is not so desirable from a type-safety point of view, and not so easy to make type-safe from an implementor's point of view. (Or maybe it's just not a priority for the language designers.)

Yet Scala does provide extensions of a sort, via a mechanism called "implicits". Extensions are defined in "wrapper" classes and an implicit type conversion is defined such that when an undefined method is encountered on an object, the defined implicit conversions are searched for a definition of that method. The object is essentially "wrapped" in an instance of that other class, and the method is invoked on the instance.

While this is type safe, it is not nearly as powerful as those mechanisms in the popular dynamic languages. (For one small example, it does not allow wrapping or replacing existing methods, as far as I can tell.) Still it does provide a fairly simple extension mechanism and so makes a fairly common situation much more pleasing than for the most popular type-checked languages.

Scala

As an erlang fan, and a jvm critic, a few people have asked me whether or not I have tried the programming language scala which compiles to the jvm and integrates with java. I had not, and was not motivated in spite of their attempts.

Then fuzzy came across scala and asked me the same question last week or so. I gave him the same reply, and felt no more motivation to do so than ever.

But you see, fuzzy is my boss and (moreover?) one of my co-workers and collaborators. This week I went on one of those web-based hunts for something unspecified that lead here and there. This time, almost out of time, and remembering fuzzy's email about scala, "there" led to http://www.scala-lang.org.

OK, playing with scala for just a couple of hours forces me to take back all the crap I have dished out about the futility of the jvm when it comes to erlang-like programming, which I think we all should be doing. (Note: I said we all should be doing erlang *like* programming, not *erlang* programming per se!)

Someone suggested some time ago I should look at scala's actor library. Now I am deeply sorry so much time has passed since I followed that suggestion. Maybe I should have given some credit to the primary author, Martin Odersky, since years ago (nearly ten???) I used his pizza language extension / compiler for java quite a bit.

I am not a terrific fan of ML-like, Haskell-like type-inferencing, etc. languages. OK, but I never got over the curve enough to feel up to my level of ease with the smalltalk/lisp-like approach. Scala is along the lines of ML and Haskell, but that is not really a turn-off for me, more of a "so what".

Like some implementations of Haskell (at least the one I used the most, hugs), scala comes with a read-eval-print loop. That helps me a *lot*. Also scala supports the conventional unix syntax for writing executable scripts. Well, it is a *little* unconventional.

Scala feels pretty good even without its actors library. But actors...

Scala's actors (and remote actors) implement a pretty good chunk of erlang-like processes, process management, and message passing. And the performance on an unmodified jvm is beyond impressive. I guess it makes sense since event-oriented java library implementations have done the same. Scala takes that somewhat clumsy approach (in java) and wraps it up in a much nicer language and a richer erlang-like library.

Nicely done. Nice mix of objects and modern functional programming with pattern matching, etc. Message passing, pattern matching, and scalable "actors" -- that's a good mix for the future.

Scala is fairly new and mature: hopefully more people will take a look at it without hestiating like I did. The lift web framework is another reason to look, although not what I am after at this point.

Offline Problems

Now that Apollo, Gears, etc. will finally bring disconnectedness to the forefront of applications, here's a useful reference. I've used Paul Dourish's ideas in several settings both for hands-off and hands-on divergence and synchronization. It's not just about "offline" and "online" -- there are all kinds of divergence and synchronization in distributed systems.

The basis of this model is the explicit management of divergence between potentially simultaneous streams of activity over a shared workspace. Streams of activity correspond to user and system actions at one user’s node. Divergence occurs when actions across the shared workspace are unsynchronised, and hence two user’s views (or copies) of the shared workspace differ. Cooperation and coordination is achieved through the periodic synchronisation of streams. In the model, a collaborative system regulates divergence and synchronisation through the use of general consistency guarantees. The mechanisms by which divergence is admitted, consistency guarantees made, and later synchronisation achieved, are points within this model where a different strategies can be adopted. This openness leads to a wide range of resultant tools applicable in different situations, and supporting different working styles.

Competing With Fun

From Cory Foy (corrected spelling, sorry!), in response to Martin Fowler's recent "Microsoft and Ruby" observation...

Just like it is hard to compete with Apple because they are cool, it's hard to compete with Ruby because it is fun.

A funny comment to that post though...

I think Fowler time is over. It was about time, frankly I think he has lost it.

Let's hope not. His message, as usual, was "spot on" for Microsoft.

ws-bandwagon-decision-making

No surprise, but I have problems with Mike Champion's recent argument in favor of WS-*...

WS-Management is widely used today in situations where the web-scale alternatives really don't fit, such as deep within operating systems or in the firmware of chips.

My main problem with his argument is this: I do not believe technical reasoning was used in the decisions to use WS-* in these apparently "non-HTTP" situations. To some degree my beliefs are based on direct conversations with people involved with WS-Management.

The decision to go WS-* in this case was made like this: WS-* is the future for integration, system management requires integration, so we'll use WS-*.

This is not to mention the fact that ws-management is essentially a shell of a solution with little agreement on what goes in that shell.

Other problems with his argument include no explanation about what "where the web-scale alternatives really don't fit". I am not necessarily of the sort that everything has to be HTTP, but then again, HTTP has been implemented on some pretty tight spaces and processors. I'd like to see the evidence that HTTP is not suitable for certain ws-management scenarios. I assume ws-management still specifies a fair bit of verbose XML over those supposedly tight spaces. Hmm.

It is precisely this lack of rigor that has failed ws-* from the start. There's nothing new or significant in Mike's argument that I can see.

Reminder

Peter Fisk observes...

Lisp is like “executable XML”. Much more powerful and flexible than Xaml.

In the very early 1990s, Lisp was actually used to define at least one standard information exchange notation, EDIF: the Electronics Design Interchange Format.

The someone latched onto this overly complicated angle bracket element and non-bracketed attribute stuff.

Now we are getting back to sanity with JSON, in some ways even better than Lisp. It is almost as easy to parse and arguably more readable (e.g. easier to distinguish pure lists from property lists).

TestDriven.Net

(via James Robertson)

Along the lines of Martin Fowler's recent expression of concern, here's this row about MSFT vs. TestDriven.Net

I am not a big IDE proponent (other than those typically found in Smalltalk). But when I was teaching and coaching agile development mainly to developers on the MSFT platform I did have Visual Studio installed, and the best thing about it was the plugin for TestDriven.Net.

It Runs

Linux, of course. Palm Folio.

Developing in the Sunlight

Martin Fowler on a potentially huge Microsoft / Ruby / FOSS conundrum... too good top-to-bottom to figure out what to quote here.

Apollo Gears

The Apollo folks talk about how they and Google Gears are both using SQLite and how they are working toward the same APIs to help code work with either.

Cool. More openness from Adobe.

Breaking Out

ars technica relays...

future versions of Windows would have to be "fundamentally different" in order to take full advantage of future CPUs that will contain many processing cores.

The concept of an "operating system" generally will have to change, even go away. Think "system" in a way that is unconfined to a "box" somewhere.

So, yeah, Windows would have to be "fundamentally different". It's not about "cores". Any specific silicon wafer will be just a host to *some* of the processes in the system. The rest will be elsewhere. Who cares, unless your revenue stream is an "operating system"?

If you are going to fundamentally redesign your system, you'd better aim for a technology landscape that is further than five years out. Ten years out will probably be as different to five as five is to today.

Messaging Only

(via Bill de hÓra)

I agree with the observation...

Messaging APIs are dying on the vine, ws-* stuff just redefines the existing APIs with ws-* APIs and transports but does nothing to simplify the life of a programmer.

...but not the cure...

Messaging is just state, state should be managed the same way whether its state from a message or state from an inmemory database like ObjectGrid or state from a relational database... messages should not be orphans in your data model

I think there is a time and place for in-stream, "continuous query" capability, but those a few and far between. Rather a simple Javaspace-like or Erlang-like pattern matching on individual messages should be sufficient for messaging, keeping the query stuff out of the stream and in memory or disk-based database-like thingies.

The biggest problem with messaging for Java (sans Javaspaces), and most other non-Erlang languages, is that creating and using even the simplest of inter-process message queues is a relative pain in the tush. Just creating another process is painful.

JSM and locking messages matched by queries joined from other (mutable) objects? Ugh. No.

Better?

How about making it easy to create a new process and automatically giving each process its own inbox and outbox supporting simple pattern matching? Some of these inexpensive processes could be storing up data and doing all kinds of queries over that using JPA or whatever floats your boat.

In Erlang and in Gambit Scheme, every thread (in Gambit, process in Erlang) automatically has its own inbox and outbox. In Gambit those are not automatically inter-process. Unix processes are the same way, but still not as easy to do, esp. remotely, as in Erlang.

Someday we'll look back and say, "Remember when starting a process was hard, and communicating with them was harder?"

Microsoft Surface

(via Don Box)

Looks good on the surface: Microsoft Surface.

Bad pun. Interesting device with a lot of potential: I need to read more to understand how it is programmed. It looks like a machine with Windows Vista. But how well can it act like a programmable client device for other machines to interact with?

What is the cost? Their current market seems to be positioned fairly "exclusively", listing restaurants, hotels, and casinos. The future direction is positioned more mass market. A lot of fun and useful potential for all kinds of applications.

(Oh, but that Adobe Flash web site is not very Restful! Please use *real* links!)

Pot-Kettle-Black

From cnet on the need for more concurrent programming...

Intel's Borkar said that Microsoft and other large software makers have known this shift is coming and have not moved fast enough.

"They talk; they talk a lot, but they are not doing much about it," he said in an interview following his discussion. "It's a big company (Microsoft) and so there is inertia."

Intel's main problem... they should have started becoming a software company a long time ago. In some ways, they have, but just not good enough.

Look at Sun. Sure Intel in significant ways has been and will be in a better position that Sun. But in other significant ways, I have to wonder: is Sun a software company or a hardware company? What about Intel? Which is better, for the long run?

There is no clear answer to me, except that Intel would be in a far better position if they were to take on more of Sun's strengths.

Maybe I am jaded as a former software developer for Intel. But there is so much more Intel could be doing to control their own destiny.

Borkar writes...

"Software has to double the amount of parallelism that it can support every two years."

Don't fall for this. I hope this was a meaningless aside attempt to make a fluffy analogy.

There is no Moore-ish path for software. Hardware essentially took the same von Neumann design and compressed it along Moore's predicted path, including increasingly more concurrency over time. The reduction in size and increase in performance was essentially due to better technology being applied to the same design up until the internet, heat, etc. forced more significant design changes.

And even now the design changes are essentially taking the same von Neumann design and replicating it on a chip.

Software? This is a different beast that will require more radical rethinking. Taking the internet and shrinking it down to everything, more or less.

Design & Test

People like Tim Bray and Fuzzy are speaking out in favor of a Rest specification language. I've not tried it, and barely read about it, so I won't comment on it.

I will say this though... specifications are good, especially if they are simple and simple tools can support them.

I hope this specification and especially these tools don't get too elaborate though. Tools are often used to hide complexity and prevent developers from really understanding and improving their designs.

Even more, though, is this: I like examples at least as much as I like specifications. Specs make understanding complete. Examples (such as out-of-the-box executable test suites) make understanding practical.

So specify your service all you want -- but please give me a suite of tests as well.

Changes

Dan Creswell on learning from others...

Notice how the monolithic single database architecture hasn’t just confined scalability and performance but the speed with which new features could be added. As an enterprise one might certainly argue that the level of scale of amazon is irrelevant to them but the ability to add features or change? That sounds like something we should all be interested in.

This is the number one problem (and yet often the least recognized) in software organizations I am familiar with: the inability to change as desired because of unnecessary dependencies among components.

Software tends to "accrete" (in the worst way) rather than change, because we developers tend not to pay attention to the limitations we are imposing on our systems. The ability to change has to be deliberately designed-in and maintained with extreme attention.

Surprising me, Bill de hÓra apparently disagrees.

That's much too convenient. It's tedious to incessantly see developers or "IT", as groups, get the rap for shortsighted upstream decisions. Plenty of developers understand exactly the limitations they're imposing, but imposed schedule pressures dictate they have little or no choice. This notion that the "business" is the set of stakeholders that are not technical is something to be questioned. Non-technical stakeholders are often worst placed to make decisions about what software should and should not do.

If you build bad stuff it is *your* fault. Period.

I've run into too many developers who've not taken the steps they could've to maintain some ease of change. Even in the most difficult of schedule pressures, or whatever, I often find it's the lack of attention on the developers' part that could still make a significant difference.

Related to this is that developers (and especially development managers) tend to be pushovers. I believe this to be so to a large extent because they don't have a high enough regard for the principles of their craft. If you are a developer working with an overbearing "business" person, it's your responsibility to stand up for the system and make the case for the consequences of bad decisions (past and present).

I'm not saying there aren't other problems in the software business. But bad development decisions leading to exorbitant "cost of change" down the road is a huge problem from what I've seen.

Links

More questions I'll keep trying to give my take on...

Can I link from my blog to content or data within a RIA app?

Can you link from your blog to content or data within a browser app? Only if that content is being served somewhere over HTTP or some other common protocol.

Same is true with a RIA app.

Flash sites where links can go out but they can't come in?

Your choice. AJAX is the same way.

An AJAX app can run in a browser and display things that are not served by links to other clients, so can a RIA app display things that are not served by links to other clients.

Dang It

That blogger tool. It seems easy to accidently reject a comment, or something. Anyway, Christophe Grand commented...

While reading this post one hypothesis came to me: the angst created by rich internet applications environments isn't about rich internet applications, it's about web pages. Will rich internet applications IDEs lead the user who doesn't care about "the values of the web" to create a web site which isn't "on the web" (ie turning websites in something akin to badly designed flash sites)?

Sure they could. Web browsers did the same thing. I have encountered *many* web pages and entire sites that do not follow standards and so require one specific brand of browser (usually MSFT's Internet Explorer). We didn't need Flash to do that.

Actually if an average user picks Dreamweaver or Frontpage his websites will be on the web.

Where on the web will it be? Does the average user *know* this?

AJAX (beacuse of all its quirks) tends to favorize simple (as in KISS) solutions.

Even if I accepted this argument, would that be a *good* thing?

Will RIA environments do the same?

Well the one I am in love with so far does not seem to have as many quirks. Do you *want* your tools to be quirky in order to somehow steer you in some unintended-yet-better direction?

RIA environments appear to be good for RIA but will they be good for the whole web-things continuum (from dumb web pages to RIA)?

Apollo seems to be deliberately aimed in that direction. That won't (and probably shouldn't) prevent people from making other uses of it. But I think the message of "the web" is front and center in all that I have seen about it.

I Guess It's Me

People who I consider a good bit smarter and more knowledgeable about "the web" than I am continue to write warnings about "rich" applications. I am thinking about giving up on this budding romance I've been having with Flex and Apollo. I must be missing something. Sean McGrath writes...

I do know... that the design constraint whereby taking inevitably involves giving is being eroded over time. It can, for example, be argued that emerging Rich Internet Application platforms give you everything you need to take cents without ever giving any cents back - if you see what I mean.

I am so confused. I've been under the impression that for the last decade or so most web users *have* been taking without giving. That most web users have control over a browser, but very few have any kind of control over a service. That very few browsers have the inherent ability to create and maintain links, as opposed to relying on a service somewhere else to do the creating and the maintaining.

Have I missed a whole revolution that already exists somewhere on the web?

Where is this web in which the majority of people even come close to a 25:1, or even a 100:1 ratio of takes to gives in the link department?

How is it that all of a sudden "rich" application developers will take that ratio to even more disproportionate numbers?

The days of "Give a link. Take a link." may be numbered. In years to come, we may look back on the birth of Rich Internet Applications as the moment when community finally had to give way to commerce: for good or ill.

Really?! Just when even Microsoft is understanding open data over simple protocols, I don't see how it can get *worse* than it has already been.

And a richer client with an easier programming model is somehow going to screw this web up? I need to get out more.

WS-* is finally dead on the server, but there is that pesky more-usable, more-maintainable client on the horizon. Woe is us. And all this time I thought it was about making services easier to create and more available to *multiple* kinds of clients that can use the HTTP methods, standard mime types, and other conventions like microformats.

I guess it's me. I guess I have a lot to learn.

Effort?

link

Visio?

link

Trade Offs

I'm enjoying Pat Helland's blog...

It is essential to approach computing as a means to support business, not a religious fervor. I don't think that it is "wrong" to relax consistency, I think it is important to understand the business trade-offs and apply the technology realities to support the business effectively.

Pioneering

Ward Cunningham on open source, wikis, etc. as he joins AboutUs...

I'm fortunate to have been closely involved with a number of important shifts in our industry. I try to keep track of developments in patterns and agile but have chosen to focus my day-job attention on open source. This is not out of casual interest. The rationale for open source goes well beyond cost sharing to the very means by which we create knowledge, a theme that runs through all my work.

I bring this up now because there is one more shift with my finger prints on it that has been developing nicely and now demands more of my attention. Wiki is the tail that wags me. It is the little thing created in service of programming that grew bigger than programming itself.

In a week I will join AboutUs, a wiki company founded in 2005, as Chief Technology Officer. I’m honored to join their team. This company understands the power of the wiki concept and how to put it to productive use.

A Two-Run Home Run

Interesting that the MSFT soap/indigo folks are coming to jesus at the altar of restful web services just at the same time they are coming to jesus at the altar of dynamic languages.

"Contracts" are good. Over-specified, up-front specification checking is not.

PDF Creator -- PDF Print Driver for Winders

I just came across, and started using, PDF Creator. Now when someone sends me a MSFT office document, I can easily save it as PDF for all to use, anywhere, more efficiently. This still happens a lot at large, enterprisey places.

I've bought PDF print drivers for low cost in years past, but this is open source and seems to work fine. It uses ghostscript, and there is an installer with and without ghostscript, depending on if you need that too.

Pick up gsview while you are at it.

Apollo

It's here where I'm probably getting caught up. Do you envision such an Apollo client to be a sexier, slightly more functional version of the app that renders in my browser? Or does the Apollo app contain sufficient functionality that it is the only meaningful client?

I see apollo as a platform for more capable clients that are easier to develop, but that consume the same restful web services that other clients consume. Those services may dish up html, etc. perhaps with microformats, or they may dish up "pure informational" resources in xml, json, etc. and the clients would provide some other, non-html-based display/interaction engine.

If the latter, then that is what I, at least, have a problem with. If it's the former, then that tracks with your argument, but it seems there's a very fine line between a somewhat better client and the only client--a line too easily (even accidentally) crossed.

"Only client" would be bad, generally. Of course people *will* do this, they do it today. Many people were doing something even worse when they were on the WS-Deathstar. Fortunately the whole world seems to be disavowing they were ever even remotely in that camp. (Let the record show I never was.)

So the world seems safe now for new clients that can actually play on the web with truly restful web services. That's the whole point, what allows evolution of clients and servers to take place.

It would also help if you can describe how you're using Apollo today, and how you're keeping from making Apollo-only apps.

We're just starting to use Flex today at work. I am kicking the tires at home. In both cases I hope we keep moving more in the direction above. Without getting into specifics, my work is currently in the insurance industry, which is obviously drowning in data, under-automated, burdened by layers of "legacy" systems, etc.

Word

Via Pragmatic Dictator, I read recently Pat Helland's "Life beyond Distributed Transactions" (pdf).

Via Sean McGrath, I recently read Pat Helland's "Memories, Guesses, and Apologies".

Nicely done. Subscribed. Would that Pat Helland were working in the open world.

Unfounded Panic Ensues

The panic continues from really smart people (more than one), for some unknown reason...

how is that different than the bad old days when a site was developed for one particular browser?

I really have trouble understanding the concern. When I read about Flex and Apollo the first and most important aspects that caught my attention was the *emphasis* on being web compliant.

The point *is* to write web compliant services and run them through many kinds of web clients. Apollo is just one and should not be leading to locked in service providers.

That would be dumb and missing the point of the web.

Disconnected

Sean McGrath writes about the new world...

Software people need to realize this new reality and go visit with the hardware people.

The processor will stop doubling in speed and halving in cost. Instead, you will find more and more processors shipping in each computer.

This is the future because the hardware people are creating it that way. The software people need to realize that fact and start figuring out how to use all the processors. This future does not just involve just re-compiling your software. It involves turning it on its head in most cases.

Things are different now.

Disconnect your software: share nothing.

The Simplest Processes That Could Possibly Work.

We Are Evo -- Mostly

Congratulations Indiana, North Carolina, and South Carolina. I would not have guessed, and I apologize for that. Gold states: go green! Orange states: hello?

Even More On The Web Again

More responses to comments as I struggle to communicate -- I am glad to be receiving these comments because maybe there are things I am not getting, and maybe there are things I am not communicating effectively.

"visit the URL of the Apollo/Flex application. What, I need a plugin!" -- ok, then, what is the URL of your firefox executable? Actually the URL of the Flex / Apollo application, if you want one, can be on the web.

More important, however, is to recognize the Flex or Apollo app's URL is not as important as the URLs of the *resources* that app consumes. Especially since those resources can, and should, be fully restful, and so any app can access them.

One more time: Flex / Apollo apps can access *restful* services. Nothing about those services is specific to the Flex / Apollo runtimes. Take or develop any *restful* service and access them in any capable client. Flex / Apollo is just one specific set of components that can access these via URIs. It's just that once you use Flex / Apollo then that client "engine" is much easier to develop and much more expressive for the user than is a current Ajax toolkit. That is all I am saying.

"proprietary runtimes - that do not have the reach ordinary HTML, CSS, and JS do" -- well..

1. Flex / Apollo to me are *signposts* of the future for building these apps.
2. Flex / Apollo are becoming *more* open with hints of that continuing.
3. Apollo specifically supports all these, just like any other browser. Both support CSS. Actionscript is JS-like. (I am not crazy about the AS extensions, but oh well.)
4. Apollo apps can have HTML *or* Flex components. And the one can embed the other as desired. This is often overlooked I have found. Apollo uses the same open HTML components as Safari.

"what's planned for Firefox 3.0" -- I have looked a bit, and like what I see. Offline, etc. is good. I have *always* stated that I see Flex / Apollo as *directions* for RIA web clients, not the be-all-and-end-all-for-all-time. However from what I've read of FF 3.0 it will still have an Ajax + Canvas and some SVG. I think a rich, structured, retained, vector graphics capability in Flex is better than those things I think will be in FF 3.0. that said, I am interested in Flex / Apollo pushing FF and other web clients to be even better. Convergence could be good, but competition to some extent could be even better.

"I think you drastically underestimate what can be done with current browsers, even in a cross-browser manner." -- maybe, but it seems awfully painful and unnecessary. The key is, I believe, to get services more restful, less UI-oriented, and then various kinds of clients can interpret them in their own ways. Restful services are more important to me than semi-compliant HTML web browsers.

"it's better to evolve the browser rather than replace it" -- the browser is *stale*. As I said above, Flex / Apollo is useful for pushing the current browsers to the next level. Meanwhile it is also a hell of a lot nice to develop Flex / Apollo based apps than Ajax. With restful "data" services you have more choice in client components per se.

"WS-Deathstar" -- N/A -- misunderstanding on my part.

"Apollo and (especially) Silverspoon aim at replacing the deployed infrastructure, when they cd have enhanced existing browsers instead (as apparently Mozilla intends to do)." My response...

I agree, although arguably MSFT's and Adobe's current approach is more expedient for them. I would hope they are participating fully in the WHAT-WG or whatever (pun) that workign group is that's trying to push the browser forward.

A fairly good signal so far -- Adobe has donated their VM to open source, in particular Mozilla. The Flex API is opening sooner rather than later. The Apollo folks have said this is a likely direction for them as well.

Apollo did choose the HTML component used by Safari and others rather than Mozilla's. But they are using an open, popular one. I imagine they have valid technical reasons for this choice over Mozilla's.

All things considered, I think the state of the web client is moving in a positive direction by having many various clients. Given the browser stagnated for so long, this seems to be a time to expand choices and think creatively.

Thanks again for the comments! I hope this is helping all of us.

On The Web Again

Responding to comments from earlier posts, here are some qualities I think are part of being "on the web".

"hypertext and hyperlinking" - yes. And so Flex/Apollo applications can get resources that have links, can display resources that have links, and can respond to the results of following those links. So that is part of what makes them able to be "on the web".

Flex is a library of Actionscript. Apollo is an extension of that. Those libraries include the ability to do these "on the web" things. These things (and the web itself) can, and will, go *far* beyond what the current browsers can do. Don't get locked into thinking the only true web client is this unfortunately limited web browser you've been using for a decade or so. So yeah, ok.

"bookmarkability" - I don't put this in the "on the web" category per se. Although since Flex/Apollo apps can do linking and link-following then being able to save and recall these in various cirumstances would be useful. And so since they can be "on the web" then they can use bookmarking services that are also "on the web". Other kinds of bookmarking are possible as well, up to and including Apollo's ability to use a local (or other, really) file system. So yeah, ok.

"hypertext as the engine of state" - yes, well this gets back to linking, but the emphasis in this comment seems to be on the "engine" part. Flex/Apollo apps can provide an "engine" very much like a browser is an HTML "engine" or they could be used to implement other kinds of "engines". HTML is not the only fuel for "engines on the web". So yeah, ok.

"view source" - I don't put this in the "on the web" category per se, but it certainly helps the web evolve, so let's include it. Flex/Apollo apps are compiles to binary, but can also provide a "view source" capability if the developer desires. So yeah, ok. I would recommend using this in almost all cases.

But this is similar to "meaningful URIs" - are these required for the web? In some cases opaque URIs are more desirable. The developer gets to choose.

Misunderstanding RIA Some More

Peter Lacy is pitting Apollo/Flex vs. the web. Please don't. That is mistaken.

Adobe "gets" the web. These components run "on" the web, and are "of" the web. Yes, they have ways to use things in a non-web way, just as Java and C# have. But they fully support the web, just like Java and C# do. They are on, of, and for "the web".

Here's how you do it: write the server as if any kind of web-able client could consume it. Write the client in Apollo or just Flex to consume that server's resources.

OK? That is not "versus" the web in any way, shape, or form.

Boycott

The marketplace is the only place that will end this MSFT patent fiasco any time soon. The sooner people and organizations *stop* buying MSFT products, the sooner this ends.

I have trouble seeing any other resolution to this. Anyone giving them another dollar is a fool. It wasn't worth it a year ago, and it's certainly not worth it today.

Which of their products is indispensible, again?

What's that? You've completely built your data center to be dependent on Microsoft? Ha, ha, ha!!! You're *kidding*, right?

MSFT Goes SCO On Us

From Fortune magazine...

Microsoft is pulling no punches: It wants royalties. If the company gets its way, free software won't be free anymore...

Microsoft General Counsel Brad Smith and licensing chief Horacio Gutierrez sat down with Fortune recently to map out their strategy for getting FOSS users to pay royalties. Revealing the precise figure for the first time, they state that FOSS infringes on no fewer than 235 Microsoft patents.

It's a breathtaking number.

I guess they are ready to start their war of attrition and tangle some folks up in the courts for a while. I'm betting they'll "lose", not SCO-like since they have a ton of money and a big, ol'revenue stream. But still, they're now firing direct shots at their biggest competitors, not to mention many of their customers.

Of course they have lost already, and this is just the next big milepost of that path. Now it is about how much trouble they can cause as they struggle to find what they should become.

Tim Bray wishfully thinks... Litigate or shut up.

Of course the strategy is to drag out the FUD as long as possible while also racking up legal fees all around. The last thing MSFT wants is to settle or in any way resolve. They know they've lost. There is nothing to do but gum up the works.

The sooner people and organizations wean themselves from MSFT the sooner this will end. Nothing else will be as effective.

On and Of the Web

Apollo is like Emacs and people are thinking all you need is Notepad.

From an interview with Mitchell Baker of Mozilla...

Dan Warne (APC): One does wonder why Microsoft would bother with Silverlight when it is so late into the game.

Mitchell Baker: But it is so critical, I mean we're doing the same thing and we're doing the same thing because Flash - yes it's proprietary so to us that's kind of a problem, but why does it really matter? Well it doesn't live - it is on the web, but not of the web, it's not searchable, it doesn't share all the features of the browser, you can't operate it, it lives in a little box.

That's not the point. The point is a flash (flex) application can access data that *is* on the web, searchable, etc. by any kind of web client software. It's just the flash (flex) application will be easier to develop and more capable than the typical ajax application.

I hope mozilla gets this before too long. The current state of the browser is, well, poor. Before too long, apollo will be a much better platform for writing browsers and other web-based systems than mozilla/xul.

Reading this...

I imagine there are probably efforts to move it out of the box, but to really integrate with the rest of the web, some of those capabilities ought to be in the web client, which is the browser. And so we continue to hope on that front, but also to develop graphics capabilities ourselves.

...I just don't think she *gets* it. Apollo is like Emacs and people are thinking all you need is Notepad. Apollo subsumes the browser. It is not some other thing.

(Aside: The swf file itself (actionscript byte code) is not searchable, etc. unless you choose to provide the source -- it has a "view source" capability, a co-worker showed me the other day. But that's not a good way to provide web resources unless the resource is a swf file you want to execute in a flash vm.)

SlideAware Apologia

The SlideAware folks explain why they chose Erlang, including...

Who needs Oracle/Mysql when you have Mnesia, a free, distributed, in memory database ? The ability to store native Erlang structures out of the box is so liberating: suddenly the need for your object-database mapping layer almost vanishes (well, not 100% to be fairly honest, but a big chunk of it: no need to create a 1-to-n relationship or a n-to-n relationship and a mapping table in many simple cases)

Not to mention that Mnesia supports table replication and is fully distributed, with the ability to add new 'nodes' on the fly. All of this out of the box ! (did I mention it was free too ?) This makes scaling up almost a joke. Compare this to the usual nightmares (and cost) of trying to implement a distributed Mysql/Oracle...

We just introduced the ability to have live review sessions for PowerPoint slides. You basically see other people currently reviewing the same presentation, you can leave real time notes and also have to ability to send quick IM messages. Think about what really happens in the background for a second. Because all of this is real time, every user is constantly going to the server asking "is there any new note/IM message to display" ? Now, we decided to go with a simple polling approach (== no Comet). This means we have to handle a lot of tiny requests/responses. This would be almost suicidal in any other language (or you would need to start adding plenty of servers to support any decent number of users). But not quite so in Erlang since the language was designed for this type of workload... It just scales beautifully (and yes, we still need to add extra servers as well to handle a large load, but just not as many...)

Even pragmatic programmers like it...

This book presents Erlang and functional programming in the familiar Pragmatic style. And, it's written by Joe Armstrong, one of the creators of Erlang.

It includes lots of example code you'll be able to build upon. In addition, the book contains the full source code for two interesting applications:

• A SHOUTcast server which you can use to stream music to every computer in your house, and
• a full-text indexing and search engine that can index gigabytes of data and run either on a single computer or collaboratively on a parallel network. The indexing engine is specially written to illustrate how to maximize throughput on a multi-core CPU.

Mnesia, written *in* Erlang, for Erlang, is a testiment in itself to the benefits of building distributed systems in that language.

Too Up Close and Too Personal

John Wiseman's photos of the fire in LA near his home, including...

ASSQL

This is kind of cool, plus I just wanted to publish a post on something called ASSQL.

It's ActionScript (AS3) code for accessing MySQL.

Cement And Such

From the P.D....

It’s fascinating to note that we spend a massive amount of time focusing on making software malleable at compile/build time (Spring anyone?) but considerably less effort on ensuring similar flexibility post deployment making for brittleness in face of failure, upgrade, configuration changes, scaling etc.

Free Data

You have to be real careful when you invest in some vendor's technology. Will they help or hinder getting you where you want to go.

Microsoft I gather is *real* scared of google, and so they try emulating a bunch of googlesque capabilities. As usual I have not read a lot about them, but this one about "live data" and "data wants to be free" caught my attention.

See, calendar information seems to me to be the data that *most* wants to be free, but isn't yet as free as it should be. Is calendar information now free from Microsoft?

Or is there motto: "Data wants to be free, and will be, unless we can lock it up in a proprietary server, obfuscate it in proprietary formats, and extort you to pay for a lot of client licenses to get to it using tools of our choice"?

Maybe things have changed -- please correct me if I am wrong, or explain why you don't need fully functional calendar information to be free.

Take Five: Processes

Guido van Rossum (via Joe Gregario) (via Sean McGrath) on "threads"...

The difference is, for an OS kernel, there really isn't any other way to benefit from multiple CPUs. But for Python, there is -- run multiple processes instead of threads!

Yeah, I don't like threads one bit.

How much support does Python have (in the distribution or from other contributions) for starting and stopping processes on the same or other machines? And for communicating with them?

I am all for this approach, but little attention is being paid that I know of to programming this way, regarding "all the little things" that are needed to develop, test, and deploy concurrent, distributed systems. Not to mention "post modern" systems using various languages.

The "common language runtime folks" (clr/dlr and jvm, etc.) are salivating over using each others classes. We should be more interested in using each others processes.

Just because Java was once aimed at a set-top box OS that didn't support multiple address spaces, and just because process creation in Windows used to be slow as a dog, doesn't mean that multiple processes (with judicious use of IPC) aren't a much better approach to writing apps for multi-CPU boxes than threads.

Even in the same address space it's better to pretend you're not. Java applets, etc. were aimed at the everyday developers, so why did the language designers give them such things as threads and locks? More out of habit and lack of questioning their hidden assumptions than anything else, I'd bet.

Yeah, it will be a good thing when we can do all our cross-platform, distributed process management stuff in IronicPython and/or Jython! (This might have been more interesting even five years ago. Now we know we could have been, and should be running in the *opposite* direction. Instead of running at full speed, we're still docked, with the steamliner facing the *wrong* direction.)

"Common Language Runtimes" -- phooey. Think broader. Patrick Mueller points to his investigations with Java in a comment to this post. Is Microsoft's CLR/DLR going to do a better job at cross-platform, distributed process management???

Hyperflux

Hugh Winkler says... (via Sean McGrath)

But if you're not pushing a bunch of hypertext down to my browser, you're not helping me explore the space.

I agree with this. Nothing about the server should be specific to the client. Adobe promotes FDS (Flex Data Services) and there may be a time and place to use it (or not), but that's not "on the web".

I don't think developers should slide into the mode of piece-wise assembly of a bunch of widgets and wiring them up to the automated updaters keeping objects-in-sync across networks.

But taking a more web-oriented approach doesn't preclude using client stuff that's a bit more expressive than current popular browsers. There're good ajax apps and there're bad ajax apps. Same with other "RIA" technologies.

RIAs built on something like Flex and possibly Apollo, but using the web in the right way is appealing to me. Finding more simple ways to build the RIA part *and* get the most out of the web is an interesting challenge.

Jini Panic

Fuzzy relays the state of the Jini world... great Java technology. Community is awful. Not easy to invest in that direction, when the signs of community since River started have been no better, or worse, than prior to that event.

Sad, really.

On Thursday an email went out to arrange a get together on Monday at JavaOne. I will be down in SF on Thursday and Friday, but too late to change plans for Monday.

Sigh.

chromatic on silverspoon

chromatic wonders about duplicating silverspoon on linux...

I’m not sure that making the life of the marketing department of a convicted monopolist which just loves to embrace, extend, and extinguish competition is the best way to spread freedom through software.

Here's my deal: the MSFT community seems to hang on every word of every potential innovation from Redmond. The same is true to some extent in the Apple community, but to a far lesser extent. In part this could be so because MacOSX is based on Unix, and so the culture and innovations can cross over much more easily.

By and large Linux, Java, and the other various language-centered communities have the tools to innovate and the culture to innovate and *do* innovate more (in my preception - not formally measured) than the MSFT community.

And so would you rather your world be based on the governed pace of innovation from one large bureaucracy? Or would you rather have more freedom to move in directions and at a pace best suited to your market?

I can count all kinds of devices running Linux in my house, from several vendors. Not so for Windows. Getting silverspoon running compatible, not getting incompatible, etc. is not a good choice when given the choice to be more innovative, whether based on Adobe Flex/Apollo or anything else.

"Anything but MSFT." seems to be the most logical choice unless your market is already so caught up in MSFT's and your interests are so closely aligned with theirs.

They will *not* give you the tools you need unless that meets their needs. You choose.

Better to ignore them or force them to play your game, than try to play theirs.

Making Us Stuck

Intel is concerned about their multicore roadmap. Chips could potentially have 32 cores within three years, but Intel may have to find other things to do with all their transistors until software can catch up and take better advantage of so many cores. This is not the first time software has failed to keep pace with hardware.

Next questions: What effects might the Sapir-Whorf hypothesis have on software evolution? (As interpreted by Ken Iverson re: programming languages. (pdf))

What contraints or propels software evolution vs. hardware evolution?

What Goes Around

Is the actor model on the list of foundational topics in CS programs today?

Is the actor model about "objects"? Why or why not?

Is the actor model relevant today? Why or why not?

Are today's systems becoming more or becoming less like actor systems? Why or why not?

Why Unix?

Why ask?

Bungle

Something screwy happened with blogger. I cannot tell, but I may have lost several comments from today. If you don't see yours and you are so motivated, please try again. Sorry.

Flair

Sun gets in the game of replacing java, at least on the desktop. I would *never* make the mistake of underestimating Dan Ingalls, now a Sun Distinguished Engineer and previously the primary implementor of Smalltalk at Xerox PARC, Apple, HP, and elsewhere up through and including Squeak.

"AJAX deals with all of the old way of doing things. It makes it simpler, which is great, but underneath it’s still all this junky HTML, Document Object Model, cross site scripting, all that stuff, where 30 years ago, we knew how to do that stuff cleanly with a dynamic programming language and a simple graphics model," Ingalls said.

I Love This

Adobe and MSFT going head to head, competing for the most appealing, most open, next-generation web client technology. All of a sudden the web is a lot more interesting than just tracking what ajax toolkits run in which versions of what browsers in order to get us more than green screens of zzzzzzzzzzz.

Browsers and HTML were great because they got the UI out of the widget builder era. All of a sudden there were no rules for how pleasingly creative a UI could be. But that was the 1990s.

Now the new tools are putting back good things from the structured graphics era, including those widgets, but they retain the creative flair of the HTML era.

Let the atom, json, structured graphics era begin!

Apollo May Become The Best Ajax Platform

James Robertson writes...

Microsoft is trying to create the kind of walled garden they stumbled into on the desktop out on the net. The problem is, a lot of us would rather develop/deploy on Linux (because it's easier to manage a Linux server remotely). At present, Silverlight is completely uninteresting if that's where you are, and they aren't likely to change that...

Adobe's Apollo, on the other hand - it's going to end up inside and outside. It's the game to watch, IMHO.

James on silverspoon vs. ajax...

Ajax doesn't limit you in the same ways.

And the cool thing about apollo is its support for flex *and* ajax. Apollo may become the *best* ajax platform. One, because it has all the other apollo features. Two, because it will be the *same* ajax environment on all platforms.

I think the ball is solidly in adobe's hands. It is their ball to drop. They can leverage their proprietary components and their open source directions into quite a sweet spot.

Pilgrimage to Someplace Better

Mark Pilgrim rants about something to do with Apollo, Flex, Flash, etc.

Not that Apollo is the final destination, but it is a helluva better step towards something useful than the place browsers seem to be going anytime soon.

These things *are* becoming more open and they are "on the web". And they are a helluva lot more programmable than browsers.

How long as SVG been around? And it can do what, again? With how much complexity?

Have fun. Fuzzy explains it.

HTTP Is Pushy

There's a lot of rest-related stuff about push vs. pull, and how pull is just fine. I really like Sean McGrath's recent explanation of rest. I am wondering about this one thing, though...

Is there a dramatically simpler solution to the push-centric, transactional, reliable once-and-only-once one that human language has a way of veering us towards?

Just a thought: rest emphasizes that "push" does not have to go hand-in-hand with "enterprisey". Looking at the Atom Publishing Protocol, isn't the big point of APP that it *is* about "push"?

We pretty much all *get* GET, hmm? It's the other stuff we don't really *get* yet, like "A and B pushing changes into the URI space" as Sean puts it. That's good stuff.

The Do What I Say Dept.

(Via Steve Dekorte), comes this...

George W. Bush, 4/9/99, Houston Chronicle:

"Victory means exit strategy, and it's important for the president to explain to us what the exit strategy is."

George W. Bush, 6/5/99, Scripps Howard/Seattle Post-Intelligencer:

"I think it's also important for the president to lay out a timetable as to how long they will be involved and when they will be withdrawn."

Cross Platform Development -- Is Java The Loser?

From an article on silverspoon...

The outstanding question is whether Microsoft plans to offer Silverlight support for Linux. Although support for Flash for Linux lags behind Windows and Mac, Warriner noted that his company can still count on Flash Web applications running on Linux.

Yeah, but here's the other thing about cross platform internets...

I want to *develop* on other platforms than Windows. Not just deliver. (Moot point for silverspoon -- it neither delivers nor develops on Linux, apparently.)

The difference between using Windows and Linux for software development tools, etc. is *immense*. (Well, maybe *you* like futzing with cygwin to achieve a fairly lame ersatz unix.)

Although a Flex Builder tool for Eclipse on Linux would be worth trying, I sure don't miss it now. I use the SDK and a command line very well inside Emacs.

The one thing I noticed today though, is a co-worker is using Flex Builder's "suggest" capabilities and found a method on DisplayObject I was looking for. Good command line tools would help, but such is the way of the IDE these days -- use it or lose it. In lieu of really good search tools, using "suggest" only as a search tool is an option - my co-worker had his second screen set up for this.

Apollo is *clearly* the internet platform to beat at this point. Given that Adobe has also donated Flex and the Actionscript VM to open source, esp. Mozilla/Firefox, I wonder how long before Firefox becomes an open source, cross platform browser with built-in Flash/Flex and oh by the way has Apollo-ish desktop capabilities right there, USB access, OS, User Profile access, and so on. And apparently SQL in the not too distant future.

Cross platform. Virtual machine. Development tool. The works. -- Peter Fisk has interpreters running in Flash, but the Flash VM will give people access to the byte codes so they can run all kinds of languages directly ultimately.

Microsoft is not about to take their WPF-lite into the cross platform desktop domain. Competition is good - Adobe and MSFT can push each other on into the future -- fine with me.

With all this MSFT Silerspoon vs. Adobe Flex/Apollo the real loser on the desktop is *java*. Adobe is heavily into Java on the server, but Flex/Apollo works at least as well with all kinds of servers. (Flex Data Services notwithstanding -- that's not a huge enticement to me even for server-side Java.)

No Thanks Netflix

I use Linux. I've been thinking about Netflix, but also considering other services such as the one from Tivo and Amazon, since I already have Tivo. But I also have iTunes and a video-capable iPod, which I love dearly, so I am kind of watching where Apple TV is going. I would have to buy a Mac *and* Apple TV. I got rid of my last old Mac a while back. But that's a net positive. I almost have Windows out of the house entirely and do not want to build any more dependencies on the one my wife still uses.

But now that Netflix has declared my business to be unimportant...

Netflix plans to adopt Silverlight as the foundation for its instant-viewing feature; a demo showed off high-quality streaming video overlaid with DVD-like menus and controls.

My decisions just got one step easier. Maybe next time, Netflix, when you decide not to rule me out of your internets.

The Simple Things You See Are All Complicated

Note: IronicPython actually *adds* to the CLR to achieve a DLR.

Step forward? Whatever.

Maybe Knot

From http://astoria.mslivelabs.com/...

The goal of Microsoft Codename Astoria is to enable applications to expose data as a data service that can be consumed by web clients within a corporate network and across the internet. The data service is reachable over HTTP, and URIs are used to identify the various pieces of information available through the service.

But, em, er, to find out more about Microsoft's "data service... reachable over HTTP" you are expected to download several Microsoft Word documents.

Bzzzt. Next?

On The Other Hand: Don't Fidget With Widgets

Peter Fisk puts the net in its place. Well, he makes reasonable parallels anyway.

As for "newer" things like flex, xaml (silverspoon or something?), hey, the same ideas have been around quite a while too. Sending GUIs and graphics over a network was not unheard of in dynamic languages in the late 1980s.

If only someone had made NeWS a bit more available.

Don't fidget with widgets, draw!

When run on workstations with 10 MIPS or faster processors, interactive response is excellent, indicating that ezd’s simple structured graphics drawing model can be widely applied.

Short Stack

Don Box on books...

I’ll read the shortest book on the topic.

Let me repeat that.

I’ll read the shortest book on the topic.

Amen. I just saw a pre-announcement for a book on Continuous Integration. The book is supposed to run at 320 pages. That seems kinda big for a book on CI. Either the book is incorporating a lot of related topics, which I'd rather not have included, or there is a lot more to read on CI than I'd imagined.

And I'm doubting I want to *know* that much about CI, let alone *read* that much on it.

Reality Based

Tim Ewald...

Building something real has a way of focusing your decisions about technology.

Adobe to Open Source Flex

That's kind of cool, in a way.

:-)

(Not) On Top Of The Web?

Mark Baker says Adobe Apollo would be...

so much better had they simply innovated on top of the Web

I don't understand how Apollo is not "innovating on top of the web". Sure, it is not *solely* on top of the web. But the browser is not *solely* on top of the web either, is it? I mean the browser accesses the desktop. Apollo apps can do the same, only as a developer I can use Apollo's desktop abilities to go beyond the browser's desktop abilities.

Is one (the browser) a good "web" use of the desktop, but the other (Apollo) not a good "web" use of the desktop? Why or why not?

Apollo simply points out how badly the browser generally sucks and essentially stagnated. Working groups or whatever, there is some catching up to do, on top of the web or not.

Over time I expect to be able to browse in Apollo as well as run all kinds of other, more expressive applications that are "on the web" or even off. At some point down the road turning off Firefox could be an option.

Actionscript Loses Eval

Like Javascript, previous versions of Actionscript had eval(). The latest, Actionscript 3.0, does not.

Peter Fisk's Smalltalk and Lisp in Flex is a treasure in its own right. But in light of Adobe taking away eval(), the desire to have some kind of language interpreter at runtime goes exponential.

I could do with evaluating Actionscript at runtime. There are legitimate reasons to have a fairly-Javascript-like language for customizing interactive applications, although Lisp and Smalltalk appeal to me more, personally.

But Adobe appears intent to make Actionscript as much a static language as possible, and one that has a fairly strict boundary between development-time and run-time. Sadly.

I don't think this can or should be chalked up to security. There are better solutions to security than to throw out run-time evaluation altogether.

Oh well. As Peter has demonstrated, reflection still works fine, so you just build your own eval() for whatever language you desire.

Dependencies

Tim Bray writes about IT...

But the real take-away is this, and it’s something that worries me more and more. I’m convinced that, increasingly, the proportion of enterprise software development based on dynamic languages and AMP technologies and Rails and rapid-iteration continuous-beta “Web 2.0” thinking will increase for the foreseeable future. But that doesn’t mean that Java or .NET or even COBOL are going away, and the brutal truth is that we don’t really don’t have anything like industry consensus on the best practices for integrating Rails and PHP and Java EE and .NET/SQLServer and Cobol/IMS and Ada and all the other weird old shit that’s out there doing boring vital business functions.

It's worse than that.

I've worked on all kinds of systems for design, manufacturing, collaboration, and more. These systems were written in Lisp, Smalltalk, Modula-like languages, C++, C, Java, and more.

The systems that caused problems were those that had unnecessary dependencies among the components. Some of these couplings were all in the same language, designed roughly together. Others of these were in different languages, designed at different times by different people.

Most of the Lisp and Smalltalk systems had as many problems as the others. The nature of the languages made them somewhat easier to deal with. Somewhat.

IT systems are parallized for several reasons. First and foremost is that past systems have so many unnecessary dependencies that they are nearly impossible to disentangle. Significant, ongoing, incremental improvements are few and far between.

Yesterday's best practices did not circumvent this, except in rare circumstances. Tomorrow's likely will not either, except in rare circumstances.

I would almost always choose a dynamic language over a static one, even over those that have implicit and/or optional type checking. (Oh, no. Don't comment on that here.) I would also lean towards rest, atom, "web 2.0", etc. Those are the ways to go.

But incredible diligence will be required to turn those into long-term, evolvable, systems that continue to meet the needs of the business with reasonable investment. (I'm not sure how to measure "reasonable investment", but the cost of change should be somehow proportional to the difference between the business functions already built and the business functions to be built.)