An interesting graph of jobs related to some relatively hot programming language...
"I have a mind like a steel... uh... thingy." Patrick Logan's weblog.
(still beats the pants off all that crap we call integration
technology today. -me)
"TDD provides two important benefits
* Driving the design.
* Building a suite of automated regression tests. "
But another important benefit of a good collection of tests is communication.
Clojure is a fine Lisp in many ways. I personally would hesitate to
use it for anything in which I had a significant investment given the
maintainer's stand on testing. At least not without a good deal of
evidence that Clojure will continue to be maintainable and understood
(at the implementation level in particular) by more than one person.
Maybe his approach will work over a long period of time, and for a
user community that will rely on Clojure for many heavy-duty, valuable
production uses. I cannot say that it won't.
I can only say that for _me_ this would be a significant reason to
hesitate before taking too significant of a plunge.
And that's saying something because I am a veteran of programming in
various Lisps for 29 years, and Lisp generally is my favorite
language. I love that Clojure has rejuvenated interest in Lisp.
Chris Sterling and Michael Tardiff are coming to Portland and will be
running April's XPDX session:
"We know about items on the product backlog, and getting them to
"Done." We know about impediments, and removing them as soon as
possible. And agile methods lead us toward shipping software with zero
defects, we hope. But bugs remain, for now, and we think of and treat
them quite differently from stories, tasks, and other work
items—perhaps to our, and our project's, detriment.
Buy why? We need your help finding an answer, or posing better questions.
In this interactive session, we'll explore the wealth of thoughts,
opinions, and especially the strong feelings behind the things we call
>>> Pizza is sponsored by YesMail <<<
Pizza arrives at 6:30pm, the session starts at 7pm, and at 9pm we move
on to a local bar.
"Jeff Patton is giving a one-day workshop on user-centered design and
agile methods, organized by CHIFOO. The notice is below, in case
Come join the Computer Human Interaction Forum of Oregon (CHIFOO) for
a full-day workshop with two leading UX designers and Agile
All Together Now: Blending Interaction Design and Agile Development Techniques
Lane Halley and Jeff Patton will lead a fast-paced day of fun and
learning. Through a combination of lecture and hands-on exercises, you
will increase your understanding of both User-Centered Design (UCD)
and Agile methods and gain useful techniques you can use immediately.
In this full-day workshop, you will learn how to:
• Choose appropriate UCD and Agile development techniques for your needs
• Successfully collaborate with diverse teams
• Understand who your "user" is, and what he or she values
• Create compelling design concepts that are shared by the entire team
• Iteratively sketch solutions as a group
• Translate design concepts into smaller user stories that can be implemented
• Prioritize and sequence product construction, without losing sight
of the "big picture"
This workshop is appropriate for people working in the UCD field, as
well as people curious about UCD or Agile.
Register Now for Lane Halley and Jeff Patton's Workshop
Registration is now open for Lane Halley and Jeff Patton's May 7, 2009
Workshop, "All Together Now: Blending Interaction Design and Agile
CHIFOO members receive a $50 discount off the price of the workshop!
I started playing with Erlang and Haskell around 1998. Wow. Over ten years ago. I recently came across a post that may be my first on Erlang. It's to the Squeak list, suggesting Erlang might be seen in the same "message-passing" family of languages as Smalltalk. Someone had written, "I would like to create an application which runs seamlessly across multiple machines and platforms, but it's too hard because the communication and coordination is a bitch.". I replied...
Another approach is the simple message passing approach. This would be interesting to consider, given Alan Key's recent email to this list about "messages" vis-a-vis "objects".
Consider the programming language named Erlang from Ericsson. It is a concurrent and distributed language with no shared memory. All communication is by sending high-level messages. Receivers can pattern match on messages with time outs, etc. What Erlang calls "processes" can be linked to each other for high level process control and reliability.
There are several production-quality communications programs built with hundreds of thousands of lines of Erlang code, so it seems to have some practicality, which may meet the "lots of gain" requirement. The simplicity of it seems to meet the "little pain" requirement.
This was sitting in a tab in Safari. I don't remember how it got there. It is a pdf of an Apollo document from 1985. Maybe it was from reading Steve Vinoski's latest RPC, etc. stuff - Steve worked at Apollo.
Maybe you're interested in reading it, maybe not. Apollo workstations were the first true "the network is the computer" computer, predating SunOS. I used them at Boeing and at Mentor Graphics in the 80's and 90's.
The CAD tools I worked on at Mentor Graphics used mailboxes to communicate between components, e.g. back end simulation engines and front end graphics. Note that Pascal is the systems programming language for Apollo.
Jesus: "Dear god, we cannot use lisp. It has parentheses! Please
deliver us from evil."
God: "OK, my son. Here's ruby. It's a hack. Try writing a correct
parser! There's no 'there' there. St. Peter and I gave up. We found it
more soothing to go back to lisp."
Clojure? Yes, a new generation.
PHP? Ruby? They're now parents. Smalltalk and Lisp are grandparents.
"The 5th Dynamic Languages Symposium (DLS) at OOPSLA 2009 is a forum for
discussion of dynamic languages, their implementation and application.
While mature dynamic languages including Smalltalk, Lisp, Scheme, Self,
Prolog, and APL continue to grow and inspire new converts, a new
generation of dynamic scripting languages such as Python, Ruby, PHP,
Some of our ﬁndings are as follows: (1) Around one third of the examined non-deadlock concurrency bugs are caused by violation to programmers’ order intentions, which may not be easily expressed via synchronization primitives like locks and transac- tional memories; (2) Around 34% of the examined non-deadlock concurrency bugs involve multiple variables, which are not well addressed by existing bug detection tools; (3) About 92% of the examined concurrency bugs can be reliably triggered by enforcing certain orders among no more than 4 memory accesses. This indi- cates that testing concurrent programs can target at exploring possi- ble orders among every small groups of memory accesses, instead of among all memory accesses; (4) About 73% of the examined non-deadlock concurrency bugs were not ﬁxed by simply adding or changing locks, and many of the ﬁxes were not correct at the ﬁrst try, indicating the difﬁculty of reasoning concurrent execution by programmers.
"Slideware on my proposal for an Apache Cloud Computing Edition; an
application stack from Apache to provide the app layer for all the low
level infrastructure-on-demand hosting services. Someone has to do it,
and who else is up to it?"
Dan Ingalls on simple, dynamic languages and systems like Smalltalk or Lively Kernel vs. the typical language and "API" stratification...
Lord knows you can get the Google Web Toolkit and start cranking out Java code for doing these things [browser-based applications]...
...You can't go in a grab hold of part of it and pull it out or change it the way you can in our system...
Now at times you don't want that. You don't want people accidentally pulling the scroll bar off their mail system. But my philosophy has always been: Make it first dynamic and malleable and then you can always turn off those capabilities. But you're in much less of a position to go forward in the world if you start out with stuff that can't be changed.
Pair Programming has many benefits for a team above and beyond coding,
yet it's still one of the hardest XP practices to get into. Ping Pong
pairing is a lot of fun and is my favourite way to pair. It has a
game-like style that instils good pairing and TDD practices. So come
along to the next XPDX meeting to try it out. It doesn't matter if
you've been pairing for years or want to try it for the first time. This
will be a chance to learn from each other. We'll spend a little time
getting to know the mechanics of Ping Pong pairing, do a brief
demonstration, and then all pair up for over an hour of practice.
Absolutely positively bring a laptop with you. We'll be using Java,
JUnit, and Eclipse. A big time saver will be to ensure that you have the
Java *SDK* installed beforehand.
>>> Thanks to VersionOne there'll be pizza for thirty! <<<
Be there at 6:30pm for the pizza. We'll start at 7pm. At 9pm we'll move
on to a local bar.
Wednesday, March 18, 2009 @ CubeSpace. Details on Calagator:
OK, type fanatics, get beyond my inflammatory headline already!
Actually, LtU points to an interesting paper (for some) on a bit of progress toward type systems for describing the correct use of resources.
Globals! Memory! Files!
As one comment points out, the pragmatic benefit of this work is sometime out in the future. Type systems will be good when they add more than they subtract.
They're not there yet, but there's (some) progress.
Also listen as various audience members pronounce if correctly... "Jay-SAHN".
Of course I am kidding - can't you PLEASE stop pronouncing it "Jay-SAHN"???
But why doesn't this bug Douglas as much as it does me???
TweetDeck is an Adobe AIR desktop Flex application.
Wait a minute. Doesn't AIR *hurt* the web? Hmm.
Oh, right. AIR is simply a cross-platform application runtime with useful capabilities for running from and working with the web. Imagine.
Martin recently wrote an update on "observations"...
Interesting problems are hardly ever simple. Finding simplifying
patterns and (relatively) simple solutions to complex problems is
As this article points out, "simplifying" can mean finding the essence
of what is important without being "simplistic".
I recently started exploring FitNesse for the first time. This began when someone pointed out the relatively new Slim protocol for using Fit tests with Systems Under Test. The primary benefit of Slim, as seen in the diagram below, is reducing the footprint of the framework in the SUT, and sharing a single implementation of the table interpreter. Improvements to the Fit interpreter do not have to be duplicated across multiple Fit implementations by multiple Fit f/w implementors.
I enjoy learning about various wiki implementations, generally. And FitNesse as a wiki has some interesting features. Mostly these seem geared toward supporting the wiki as a home for tests for multiple projects and multiple developers. I am always torn between the simplest wiki structures, such as the original c2 flat namespace, and structures such as confluence's spaces and hierarchies.
FitNesse has its own (as far as I know, unique) structure of subwikis. Essentially any page can begin its own sub-hierarchy, and the page name syntax allows for navigating and searching across the hierarchies above and below. This seems like a good thing, but I've not really used it yet.
Since I'd like a Fit tool for some fun projects, but I don't have modern Fit tools in the languages I'm using, Slim is the quickest path, and the whole FitNesse wiki comes along for free. I'd done a wee bit of integrating Fit and confluence along with http://twitter.com/ecopony and Slim FitNesse holds more promise for less effort.
I was listening to, or trying to, Zooey Deschanel sing "Lonesome Town". I started feeling a bit queasy, until hopping over to the youtube to find this much better rendition by the great Rick(y) Nelson...
And here's "Hello, Mary-Lou" for good measure...
Now doesn't that make you feel so much better?
One of the "adds" we came up with in our host's retrospective last
Thursday was to add a page (on the wiki, in the packet, somewhere) on
facilitation skills for people interested in hosting a session at the
next AONW event.
Looks like Merlyn's got a good start, and hopefully we can get him to
help as we work on this... maybe a session during or before an XPDX
I knew some people at Nintendo have been doing something with Squeak Smalltalk. At least this aspect of that was not something I'd expected...
Using commandsFrom the command line shell, you can use the programs like below. Most of the commands are written in ECMAScript:
Command Name Description cat [file ...] Prints the contents of files to the screen cd [dir] Sets the current directory to dir clear Clears the canvas for drawing graphics date [-u] Displays the current date and time. echo [arg ...] Prints the arguments to the screen edit [file] Edits text files exit Exits the command line shell figure Draws chars using the CanvasRenderingContext2D interface (A demo script) ls [dir ...] Lists names of objects in the directory rm [file ...] Removes the files squeak Squeak - a Smalltalk programming environment
Constraint Satisfaction Systems were a hot topic of research in the
80's -- famous constraint systems include Ivan Sutherland's Sketchpad,
Alan Borning's ThingLab (built on top of Smalltalk), Guy Steele's
constraint language, and James Gosling's Magritte. These systems were
used for computer graphics, design, and general numeric problem
solving, but most of these solvers were domain specific and thus of
Bertrand is an equational programming system whose purpose is to build
constraint satisfaction systems using simple equational rules.
Bertrand has an purely declarative semantics and an absurdly simple
syntax, yet it is a powerful and expressive language, capable of
solving problems in a large number of domains including graphics, word
problems, electrical circuits, or -- with the right rules -- virtually
any mostly-linear domain.
Since this is the Functional Programming Study Group, this talk will
cover the underlying equational programming language of Bertrand and
ways in which it could be extended to make it more powerful.
visit this group at http://groups.google.com/group/pdxfunc?hl=en
I was recently reminded how much I love the Original Hotcake House on Powell Blvd. here in PDX. Really, really, "diner" good. As captured in this review from alt.portland...
The hot cakes were absolutely hot cake-like, doused in some butter-like substance, and then served with something that is heated, but probably not pure maple syrup. Hell, it may contain no maple syrup for all I know (I saw some patrons bring in their own)!The coffee, like everything else, is great. It's just sitting in a pot over there, and you go up and pour yourself a cup, then squirt some milk into it from this big squirter thing.
The coffee looks scary—we didn't go there.
Now I have to plan a trip there soon.
"I often tell teams that apparently my purpose in life is to tell
people that the sensation in their butt is called "pain", and that
they should get rid of it."
Jeff Sutherland, co-inventor of Scrum, says he has never seen a Scrum team become hyper-productive without adopting the XP practices. Less elegantly, I have said that teaching Scrum teams how to get Done-Done is why I have such a lovely blue convertible...
Well, my dear little children, I’ve got bad news for you. It is your precious context that is holding you back. It is your C-level Exeuctives and high-level managers who can’t delegate real responsibility and authority to their people. It is your product people who are too busy to explain what really needs to be done. It is your facilities people who can’t make a workspace fit to work in. It is your programmers who won’t learn the techniques necessary to succeed. It is your managers and product owners who keep increasing pressure until any focus on quality is driven out of the project.
I get frustrated listening to smart people talk about things they are only marginally familiar with. Part I of this recording was interesting... people talking about their own experience with specific systems and practices.
Part II of this recording is frustrating because they've not called in anyone with experience with XP, and so debate XP as they understand it. Not that they don't have good experiences and smart things to say here and there. Just that this one could have been much better.
Good software development evolves from a team's conversation about what's working for them. The heart of XP in my experience are practices that foster a teams conversations. Those practices should themselves evolve from those conversations.
This recording has some good conversations, but mostly I am frustrated because I'd love to be a part of their conversation.
We've had two great AONW open space conferences, 2007 in Portland, and 2008 in Seattle.
This year we are back in Portland, close to the MAX, and as low-cost as ever: $125. There's still a bit of room to sign-up if you don't wait. The conference is Feb 10-11.
Agile Open Northwest 2009, the best open space conference in the world. Learn from each other at AONW 2009...
"These two-day Agile Open Northwest conferences are an extremely good value. ..[Y]ou learn directly from practitioners in the agile community what works and what doesn't. I attended the first two of these conferences, they were stunningly good... loads of practical, useful stuff and stimulating discussions." -- Ian Savage, PNSQC Program Chair
On the Scheme Language Steering Committee Nominees page, Will Clinger writes...
The R6RS has given us the option of writing programs in the new and more static language it describes. Two implementations of the dynamic language most recently described by the R5RS have added support for this new mode of execution, and four brand new implementations of R6 Scheme are well under way.
That represents a partial success, but this process has disappointed users of the language formerly known as Scheme...
As demonstrated by ERR5RS, the major new features of the R6RS could have been added without forbidding... the dynamic language paradigm of IEEE/R5 Scheme...
John Dowdell writes about recent internet-ready TV news from CES, and extrapolates...
We've got to start designing to the range of inter-cooperating display screens a person may use throughout a typical day in 2012.
And we've really got to work hard at bringing in your friends' and teachers' understandings of what's worth your attention onto those varied screens.
Future applications will be multi-screened, using the cloud, to connect with your friends. That's where the highgrowth markets are going.