Sweet Linux Air

From the RIA Cowboy himself. Yeehaw. While we're waiting for Air to be officially available on Linux...

*** WARNING - THIS IS TOTALLY UNSUPPORTED, UNENDORSED, AND A COMPLETE HACK ***

...

All I need is ADL - the testing tool for AIR applications. So I gave it a try on a Salesforce.com project I’m working on:

jamesw@dos:~/projects/mavericks/examples/air/AccountTracker/bin$ wine ~/flex_sdk-3_b1/bin/adl.exe salesforceTest-app.xml

And to my total surprise the AIR application loaded and ran on Linux! Sweet!

The one component that truly needs Windows or Mac right now can run on Wine on Linux. The degree the API is mapped to the Linux environment is probably limited, but for at least some things, developers can currently use Linux for Air.

Squeak by Example

(via James Robertson)

A nice looking new book for getting started with Squeak Smalltalk, pdf is free online, or you can order it print-on-demand from lulu. They also accept donations for the pdf.

Co-authored by local Portlander Andrew Black.

The book seems comprehensive for getting started, covering the development environment (including the Monticello package tool) as well as the language, the GUI classes, "meta" classes, etc.

This is a good year to learn Smalltalk and Erlang, with two of the best programming language books ever now available for two of the most distinguished programming languages. Every programmer would be better at whatever they do by knowing a good bit about these languages.

ONLamp: an Introduction to Erlang

From Gregory Brown at ONLamp...

I consider myself someone with a middling grasp of concurrency at best, and though I'd likely be scratching my head trying to write this in many other languages, I hacked this together in about 20 minutes with only a beginner's level of experience in Erlang. This certainly says a lot for the possibilities of the language to make parallel programming very easy.

A Scalable Distributed Data Structure for P2P

Google Tech Talk

Robust Composition: Unified Access and Concurrency Control

Mark S. Miller's PhD dissertation, "Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control"...

When separately written programs are composed so that they may cooperate, they may instead destructively interfere in unanticipated ways. These hazards limit the scale and functionality of the software systems we can successfully compose. This dissertation presents a framework for enabling those interactions between components needed for the cooperation we intend, while minimizing the hazards of destructive interference.

Great progress on the composition problem has been made within the object paradigm, chiefly in the context of sequential, single-machine programming among benign components. We show how to extend this success to support robust composition of concurrent and potentially malicious components distributed over potentially malicious machines. We present E, a distributed, persistent, secure programming language, and CapDesk, a virus-safe desktop built in E, as embodiments of the techniques we explain.

Performance of Selective Receive

Pascal Brisset explains (on erlang-questions some time ago) a scenario where Erlang's selective receive can fall behind...

The system is dimensioned so that the CPU load is low (say 10 %). Now at some point in time, the backend service takes one second longer than usual to process one particular request. You'd expect that some requests will be delayed (by no more than one second) and that quality of service will return to normal within two seconds, since there is so much spare capacity.

Instead, the following can happen: During the one second outage, requests accumulate in the message queue of the server process. Subsequent gen_server calls take more CPU time than usual because they have to scan the whole message queue to extract replies. As a result, more messages accumulate, and so on.

snowball.erl (attached) simulates all this. It slowly increases the CPU load to 10 %. Then it pauses the backend for one second, and you can see the load rise to 100 % and remain there, although the throughput has fallen dramatically.

Here are several ways to avoid this scenario...

...

Add a proxy process dedicated to buffering requests from clients and making sure the message queue of the server remains small. This was suggested to me at the erlounge. It is probably the best solution, but it complicates process naming and supervision. And programmers just shouldn't have to wonder whether each server needs a proxy or not.

I'm not sure how it really complicates naming and supervision so much. I think it is the best solution. The problem is not in selective receive, per se, which has a lot of benefits that outweigh this specific scenario. Especially wrong would be to gum up the Erlang language and simple message passing mechanisms just for this.

The problem in this scenario is *coupling* too closely the asynchronous selective receive with the backend synchronous service. This is not an uncommon scenario in all kinds of "service-oriented architectures" and the solution, generally, should be the one quoted above.

A programmer should legitimately wonder whether some kind of a "proxy" is needed when they see this kind of a combination.

This is related to the blogs going round not so long ago among fuzzy, Bill de hÓra, Dan Creswell, and others.

Receptionists for Shared Resources

Carl Hewitt, et al.'s Linguistic Support of Receptionists for Shared Resources (MIT AI Memo 781 -- pdf).

exmpp

Back in December, Mickaël Rémond wrote on the erlang-questions list...

Jabberlang for now rely on ejabberd. You need ejabberd to use it. The shared object you are mentionning comes from ejabberd. That said Jabberlang is a client library that rely on a server implementation which seems strange. That's why we are currently doing some code refactoring. Our target is to have:

• exmpp: A common XMPP library that is used by ejabberd and Jabberlang
• Jabberlang: Relying on exmpp.
• ejabberd: Relying on exmpp.

We are in the middle of this refactoring currently.

Recently, elsewhere, he updated:

Jabberlang will be replaced soon by a much better and easier to use library called exmpp. Stay tuned. It will be published here: http://www.process-one.net/

The Killer App for Multi-Node

From Many Core Era, the question: what's the killer app for many-core?

The true "many core" era will have arrived when we realize this is the wrong question.

By the time we get to a significant number of cores we shouldn't care much about cores any longer.

So You Flip The Common Torch Around

This google tech talk by Van Jacobson on networking is great.

Fun game: the video has closed captions in english. Watch for the phrase around 28 min. into it, where the captions that reads "so you flip the common torch around" and catch what Jacobson actually says. (Answer below.)

Was the caption written by a human or a machine? Was it proofed and edited?

.

.

.

.

.

.

.

.

.

.

.

.

.

.

Answer: "so you flip the combinatorics around"

On The Web

Douglas Crockford at the Rich Web Experience conference...

AJAX applications are highly interactive, highly social, easy to use, and offer great network efficiency, according to Crockford. "The big problem is that it is too damn hard to write these apps," he said.

"The most interesting innovation in software development in 20 years has got to be the mashup," which shows the benefits of distributed programming. "Unfortunately, mashups are insecure [in the browser]," said Crockford, with components unable to be protected from each other.

The model in the browser is fully broken and needs to be fixed, he said. "The Web is an exploit waiting to happen," Crockford said.

Crockford then went through a critique of various Web technologies.

"[JavaScript is a] deeply flawed language," with an unpopular programming model. "But to its credit, it's working really, really well in an environment where Java failed," said Crockford.

The planned JavaScript 2 upgrade also has problems. "It will make the language considerably more complicated," Crockford said.

Good so far, but then...

If the Web is unable to repair itself, it could be replaced with a proprietary system such as Microsoft's Silverlight or Adobe's AIR (Adobe Integrated Runtime), Crockford said. Proprietary systems do present advantages, such as having only one source of new bugs and presenting a simpler upgrade story. But people like open systems and are suspicious of proprietary systems, he said.

Em, AIR is like any other programming language and framework -- it can be used "on the web" or it can be used to route around the web. We need better ways than the browser to be "on the web" but we certainly don't need to route around the web per se.

The modern-day web browser is not the only client that can be "on the web". Look at blogging tools like Bottomfeeder. BF is a great example of an end-user application that is (1) not based in a popular web browser like IE or FF, and yet (2) is "on the web".

On the Road...

We were all delighted, we all realized we were leaving confusion and nonsense behind and performing our one noble function of the time, move.

List Comprehensions

Merlyn Albery-Speyer rewrote my morse code example using erlang's list comprehensions. It's posted on the pdx.erl site. Here I have reproduced it but I'm using the same variable names from my earlier example to make the comparison easier on the eye.

It's doing essentially the same thing in fewer lines of code because the list comprehension syntax is so concise. Not that the previous example was so long in the first place, but coming from an older Lisp world where we wrote out our recursions in "long form" ;-/, I need to remember to keep list comprehensions in my toolkit.

-module(lcmorse).
-export([codes/0, decode/1]).

-import(lists, [prefix/2, reverse/1]).
-import(string, [len/1, substr/2]).


codes() -> 
  [{$A, ".-"},   {$B, "-..."}, {$C, "-.-."}, {$D, "-.."},  {$E, "."}, 
   {$F, "..-."}, {$G, "--."},  {$H, "...."}, {$I, ".."},   {$J, ".---"}, 
   {$K, "-.-"},  {$L, ".-.."}, {$M, "--"},   {$N, "-."},   {$O, "---"}, 
   {$P, ".--."}, {$Q, "--.-"}, {$R, ".-."},  {$S, "..."},  {$T, "-"}, 
   {$U, "..-"},  {$V, "...-"}, {$W, ".--"},  {$X, "-..-"}, {$Y, "-.--"}, 
   {$Z, "--.."}].

decode("") -> [""];
decode(String) ->
  [[Char | Rest] ||
    {Char, Code} <- codes(),
    prefix(Code, String),
    Rest <- decode(substr(String, 1 + len(Code)))].