OK, I have about five sessions from Agile Open Northwest that should be in my Top Three. One of those is the "Swarming" session, where we discussed "agile" as a system and self-organizing teams.
I wish I could have attended the "Produce a Comic About the Conference" session, but I was doing some official organization stuff and then I joined the Toyota Way session which was close by.
This is Jon Marshall's "Lightning Sessions" session (but that's not Jon -- we all got up to talk many times). One of my top three favorites. This is in the Olympic room, which does not appear too intimate when it is empty, but people in each of the sessions carved out their space. Focusing was not difficult at all, and the acoustics were good.
Jeff Morrow led a great discussion on "Agile and the Toyota Way," i.e. a "lean" and "Toyota culture" angle on agile development.
Maybe we should video sessions (optionally?) next time? This would be one worth having on video. Dagnabbit - I should have brought my Flip video camera.
Rebecca hosting her valuable "Acceptance Criteria" session. This one was in my top three along with "Working Tiny" and "Lightning Sessions".
And here's Arlo hosting his "Working Tiny" session. This diagram is a tool for evaluating story value vs. cost. The Alki room was noisy for multiple sessions, but this corner was fairly isolated. On the plus side the room has a lot of windows and the weather was nice most of the two days.
Monica Yap in front of the "marketplace" of sessions that had just been announced, then scheduled by conference participants. People are seeing the two-day schedule for the first time (many of them just created it over the previous minutes). Monica is a co-organizer, and is from Solutions IQ, a key sponsor of the conference and they put on the Tuesday evening party.
The schedule we made, and some notes and pictures, are on the conference wiki.
Charlie Poole opening the conference. Diana Larsen ("open space" conference guru) and Rebecca Wirfs-Brock, also co-organizers, in the circle behind. About 115+ people in a circle, ready to make a conference schedule together. It worked well, for the second year in a row. Diana hosted last year, and Charlie matched her, both top-notch "open space" hosts. I have each of the co-organizers in at least one picture except for Troy Frever. I also should have snapped a group photo.
The AONW 2008 registration table with Rebecca, et al. (Paul Culling, on the right, handled the badges complements of his company and conference co-sponsor, VersionOne.)(Via Bill de hÓra)
"It's the second generation that's going to be less enthused, that's going to stare in bafflement at these classes that mysteriously spawn methods, and trying to figure out what's going when there's an exception in dynamically generated code. You can monkeypatch code in Python pretty easily, but we look down on it enough that we call it "monkeypatching". In Ruby they call it "opening a class" and think it's a cool feature. I will assert: we are right, they are wrong."I know next to nothing about the specific problems the Ruby and Python folks are encountering with "monkeypatching". However this capability is nothing new for dynamic languages. And it is a frequent desire for me when I program in C-like languages. If you become frustrated using static "utility" methods, for example in Java, that work with "closed" classes (say, String or Object), then you have at least some desire for these "monkeypatches".
See the thing is this capability *is* a cool feature in many Lisp and most Smalltalk systems. Sorry, dear readers who hate my Smug Lisp Weeniness. But it is true. Not only is it "cool," moreover it is *pragmatic*.
The truly good implementations of dynamic languages recognize the advantages of these kinds of extensions, and they've supported them with good tools for decades. Learn from it, don't run from it.
People developing large systems in dynamic languages, and people providing dynamic languages being used to build large systems have to also realize this:
You are no longer working with a "scripting" language. You need to demand and provide really good tools. Examples can be found on the internets, read about the Smalltalk and Lisp environments from way back when. Someday you can become as smug as we are, or maybe as brilliant as the people who made them for us.
Another favorite session was "Lightning Sessions," at AONW this week. Jon Marshall brought this idea to the conference. This is another example of people bringing the "extreme" back to "agile".
Here is how it works: within the hour and a half session, the participants continuously create new 60-second sessions. The only rules:
Over the hour and a half we had at various times eight to ten people participating. That last rule makes the effort much more interesting: your concentration on the current speaker intensifies. For one thing, you never know which sentence will be that speakers last one. For another, if you've got something to say that seems really appropriate for that specific moment, you are kind of in competition with the others to claim the conch.
The result was really productive. The first several lightning sessions were based on recollections from sessions the speakers attended earlier in the conference. About halfway through the topics evolved to be more in the moment and innovative, less about the prior sessions.
Jon attended last year in Portland. There were many faces from last year, and several people from Portland and Seattle who I'd not seen in a while. The conference was full of the familiar and the new, regarding conversations and people. I hope we can gather many of us back next time.
That one will likely end up back in Portland. I wonder where? Last year we were at the Kennedy School, and it worked out really well. But maybe it is too soon to return there.
I had a thought on the drive back home... maybe "offsite" somewhere like Skamania Lodge or the Edgefield. We have a good set of sponsors and a very positive cash flow to help keep the participants' costs down.
I was also wondering whether we could find a way to specifically reach out to the open source community to mix up more folks with that influence into the AONW "community".
This week's conference was at the Seattle Center in the Northwest Rooms. One of our rooms, Alki, turned out to be a great social area, but too much echo for the sessions. Overall a good setting, though, and a good bit of sun brightened everything up. I especially appreciated the windows in the Alki room. And the food from Gretchen's Shoebox Express was really good.
I'd like to thank my friend, and Portlander, Arlo Belshee (of Promiscuous Pairing fame) for once again making "agile" unsafe and going all "extreme" on us. His session at AONW on Tuesday has been my favorite so far.
The sessions have all be great. Agile clearly has a beach head in (nearly?) all software development organizations of any size. (And at least one fantastic non-software, "outdoor start-up", http://trackersnw.com)
So while adoption can still be challenging in many organizations, clearly "agile" is now "safe". So much so that sometimes it feels unsafe to use the term "extreme". I was not crazy about that term in the beginning. Now I kind of miss it.
Arlo's never let go of the ideal: push yourself and your team to its extremes. Can your knobs go to eleven? Arlo's can because he continuously works at it.
His session on "Working Tiny" was excellent, and not just because of him: the group made it great. Arlo made it unsafe enough in that corner of the conference to once again think, and talk, "extreme".
Pictures of the conference are now posted. Track the wiki for more... http://agileopennorthwest.com/wiki
Ted Patrick makes some important points about the meaning of "cross platform", especially when it comes to browsers and performance...
It is great that things work on different operating systems but performance needs to be similar. It is a poor user experience for an application to run 50% faster on a specific platform than another. I know for a fact that lots of engineering work goes into making sure Flash Player performs similarly across different operating systems and browsers. Actually we implemented incremental garbage collection in Flash Player because browsers differ wildly in how and when they allocate memory to a plug-in. On some browsers memory is handed out like candy while on others it is given in 256Kb chunks up to a ceiling of 10MB total. Regardless of the browser in use Flash Player tries to make sure all application behave the same both in start-up time and during use.
Ted Patrick observing that the reach of Adobe AIR has a wider reach across Microsoft operating systems than Microsoft's own "presentation foundations"...
Writing a single application that works across all version of Microsoft® Windows® is often an impossible task. Worse Microsoft deprecates support of certain operating systems as they push new operating systems, tools, and dependencies. For example, WPF is only supported on Microsoft® Windows® XP Service Pack 2 (Must add .NET 3.0) and Microsoft® Windows® Vista® (native) leaving the many XP and 2000 customers without few options for using the latest software. Even Microsoft® Silverlight only supports up to Windows XP Service Pack 2 or higher for browser based applications.Enter Adobe AIR!
A group of scientific-minded people recently held a press conference urging the presidential candidates to participate in science-oriented debates.
I read "Computer Power and Human Reason" 25 years ago, just as the AI boom was getting underway. The author wrote the book at least partly as a result of observing people using his ELIZA program.
In 1962, he published a comparatively simple program called ELIZA which demonstrated natural language processing by engaging humans into a conversation resembling that with an empathic psychologist. The program applied pattern matching rules to the human's statements to figure out its replies. (Programs like this are now called chatterbots.) It is considered the forerunner of thinking machines. Weizenbaum was shocked that his program was taken seriously by many users, who would open their hearts to it. He started to think philosophically about the implications of Artificial Intelligence and later became one of its leading critics.Joseph Weizenbaum died on March 5 of this year. As a Lisp programmer doing some AI programming, but not really being an "AI guy", his book and ELIZA helped me understand not only AI, but AI researchers!
Christophe Grand pointed to the Clojure programming language in a comment on my recent Erlang post.
I'd heard the name but never investigated. My loss. Clojure is a mostly-functional, concurrent Lisp dialect for the JVM. That definitely warrants an in-depth look for me.
Here's some more information I quickly found.
Eric's post on the recent Erlang criticism and his take on the subsequent trail of mail list discussions is fairly accurate in my opinion. I posted a long response on his blog and midway realized it's a blog post of its own. Here.
I'm not going to argue too strongly for "sequential Erlang" because it's really "concurrent Erlang" that stands out. The Erlang syntax is ok by me, but then I still prefer Lisp syntax to anything else I've seen anywhere. Simple.
And I can say nothing for the erlang list, except I've been skimming it too, with not so different reactions as yours.
Anyway...
"in development, the behavior of that existing function often changes thereby affecting all the calling functions"As with all dynamic languages (especially those unlike Lisp and Smalltalk that do no have good refactoring editors), you need good unit test coverage. Which you are doing, right?
"defining dozens of one-line functions has made flow control difficult to follow in some circumstances."This is pretty much the same for all functional languages, and even Smalltalk, which tends to have many small methods, where other OO language programmers tend to write overlong methods.
Good tools, which again Lisp and Smalltalk tend to have, and others don't, are indispensable. Otherwise the only thing that tends to help IMHE are again many good tests to read, "Oh, so this is the thing to call, and how to call it."
I still think that's better than really long methods Java or other languages that tend not to be reusable without a good deal of pain. (For one thing, they tend not to be really well tested.)
"It shouldn't take a committee to help you write good file handling code."I don't disagree completely except that Wide Finder pushed Erlang and its community into a new I/O situation. So most of what happened by the end of it was a core Erlang member adding some new core capabilities to the language. Then also what happened was the exposure of a development process for how to evolve concurrent algorithms generally in Erlang or maybe any concurrent system. I would think both, especially the new core I/O capabilities, will help down the road without requirement the full committee.
"the language is a DSL for networking gear."Which essentially what it is. CouchDB, Yaws, ErlyWeb, etc. will help, but mostly Erlang and its surrounding code is not much more than what the telecom programmers were using in the mid-1990's. that is its upside and its downside.
"I can write a Scala function to make an HTTP POST in four lines of code and have it run screamingly fast"Two points:
Like you wrote...
"actors are so important, it will be amazing when the programming public realizes why we all need to do this"You could also try Gambit Scheme, which I think is better as a sequential language (Lisp) but also has pretty much Erlang-scale thread/mailbox performance on a single CPU. Not much in the way of distributed or multi-core support yet. You get more of those, "shared nothing" threads, and functional data structures if you use the Termite package on top of Gambit. Multi-core is bubbling to the top of Gambit now that a decent package system has been released.
Asus predicts their new Windows XP-based Eee PC will outsell their current Linux-based PC. But buyer beware.
First, it's XP. Will the typical Eee PC consumer understand this is not "Vista" and will likely not continue running newer and newer versions of Windows software for long?
Linux on the other hand will do the job the Eee PC was intended to do, very well. Probably XP does the same job just as well. Until it doesn't.
I have simply found after years of running Linux and all kinds of Windows systems (except Vista, thank you!) that Linux systems tend to just run for years with little corrosion and little maintenance.
I am forever "managing" the rest of my family's Windows-based PCs, currently Windows 2000 and Windows XP. As the Eee PC's XP begins to decay (usually within six months), what then?
Is the Err PC intended to be a simple computer that "just runs" or will the consumer understand that they'll need a Windows technician to clean up the registry, uninstall software correctly, and continually ghost and/or rebuild the OS completely every year?
