"I have a mind like a steel... uh... thingy." Patrick Logan's weblog.

Search This Blog

Thursday, May 31, 2007


(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.

Wednesday, May 30, 2007

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.


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?"

Tuesday, May 29, 2007

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!)


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.

Monday, May 28, 2007

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.

Sunday, May 27, 2007


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.


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.

Saturday, May 26, 2007

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.

Sunday, May 20, 2007

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.

Saturday, May 19, 2007


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.

Thursday, May 17, 2007

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.

Wednesday, May 16, 2007


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.


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.

Tuesday, May 15, 2007


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.

Monday, May 14, 2007

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.


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?

Sunday, May 13, 2007


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.

Wednesday, May 09, 2007

Too Up Close and Too Personal

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


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???

Tuesday, May 08, 2007


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.

Monday, May 07, 2007

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.


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.

Sunday, May 06, 2007

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?

Wednesday, May 02, 2007

Why Unix?

Why ask?


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.


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.

Tuesday, May 01, 2007

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.

Blog Archive

About Me

Portland, Oregon, United States
I'm usually writing from my favorite location on the planet, the pacific northwest of the u.s. I write for myself only and unless otherwise specified my posts here should not be taken as representing an official position of my employer. Contact me at my gee mail account, username patrickdlogan.