I took part in a Western MA Developers podcast last week. It was a lot of fun and definitely captures the spirit of how our conversations usually go. We cover a broad range of topics including the bug tracker market, refunds in software, whether to be Rich or King in a venture, and a philosophical discussion of Rich Hickey's Time is the new Memory concept.

InnovateHolyoke is the online hub for information about the High Performance Computing Center that is set to open up in Holyoke in 2011.

The GHPCC planned for Holyoke will not only provide an invaluable increase in the computing capacity that would bring all these benefits to the partnering institutions. It would also serve as a showcase of green energy use and green facilities design, be scalable to meet the needs of additional partners and computational demands, and serve as a catalyst for economic, educational, and workforce development in Holyoke and the region.MIT had developed plans in 2007 to locate a high performance computing center in Holyoke due to the region’s quality access to the internet, affordable land, and availability of low-cost and renewable energy. The impact of the global economic recession led MIT to suspend their plans and subsequently reach out to leaders at the University of Massachusetts to jointly address capacity needs for high performance computing.

This is an important development for the region and will help to establish a technology hub in Western MA. I have been appointed to the education/training subcommittee as a member of the Regional Employment Board and will hopefully have more to share as we start the work of the committee.

A couple of friends and members of the Western MA Developers Group have started a PodCast called FounderCast that's worth a listen if you are interested in software entrepreneurship.

The format is a roundtable of technology three company founders (@dougmartin, @cemerick, and @paulhake). In the first three episodes they have discussed the tools they use (development and sales), how they got their first customer, customer service and other topics. The pilot is unedited and rough, so don't judge it on that one -- by the third episode it got signicantly better. You can also follow @foundercast on twitter.

Ben Fry, the creator of Processing and the author of Visualizing Data is coming to speak in Northampton. The event is sponsored by Atalasoft and Snowtide.

When: May 5th @ 6:30
Where: Snowtide Offices, 243 King St (Potpourri Mall, just across from Stop and Shop) Northampton, MA

I'll post more details soon.

If you were there and blogged it, let me know:

Here's what I found so far:

• Adam Scarborough
• Chas Emerick
• Paul Bissex
• Rick Minerich

Last night was our Clojure event with Rich Hickey. BTW, if you were there, regular meeting of the Western Mass Developers Group are every other Thursday at Panera Bread in Hadley (7pm) --- most of the time, we just sit around and talk -- very informal -- hope to see you there.

Back to the presentation -- hopefully the slides/video/etc will be up somewhere soon -- Rich focussed on the concurrency features of Clojure (Vars, Refs, and Agents). First he showed us the state of concurrency support in Java/C# today (locking) and identified the problem as having direct references to mutable objects. Clojure offers only immutable atoms and datastructures so that's how he addresses one part of the problem. However, since the mutability is how the world works, Clojure models change as a change to what a reference points to. So, if you view the world through refs, it will appear to change. Then he introduced the controlled ways in which refs can change.

1. Vars are essentially thread local variables. They are a reference whose changes can only be seen in a single thread -- each thread gets an independent and isolated view of the variable. Like thread-local variables -- they are a very simple way to take code that looks like it's manipulating global state and give each thread its own isolated copy.

2. Refs are mutable references to immutable objects. They can only be changed inside a transaction and all changes to all refs in a transaction appear to have happened at the time the transaction ends (to other threads). Inside the transaction, the changes are immediate. When two transactions are open and change the same ref, the second one to finish is automatically retried (so you should have no side-effects inside of transactions). All Refs read inside of a transaction will return the value that they had at the start of the transaction (so are consistent with each other).

3. Agents (which I have explained before) are for asynchronous changes to a reference. Each agent hold a value and you send actions to it to change the value. Only one action will happen to an agent at a time and you can read the current state of the agent any time. Rich spent a little time to caution us against any comparison to Erlang's actors. They are a different concept with different tradeoffs. Agents have the advantage that they can be read from any thread conveniently (just dereference) whereas actors require sending a message to read (which is asynchronous). Clearly, Erlang's benefit is location transparency (for distributed code) -- which is what it was designed for. Rich hinted that Clojure might have an Actor concept, but it would not be unified with Agents.

What was new to me with agents is that there are two types of message sending mechanisms -- send and send-off (which appear to be undocumented right now) -- Rich used send-off which dedicates a thread to the agent (rather than run the action from a thread-pool). This is how you have to do it if agents block at all (which ants do because they have a small sleep).

Then, he showed us an ant simulation -- I think he will make the code available. In short, there is a square world of cells, each one holds a Ref to what is in the cell (food, ant, pheromones, home base). Ants are represented by agents, which are sent a behave message. Behave picks a random action for the ant to do (move, turn, pick up food, drop food) and then mutates the world of cells in a transaction, then it sends itself another behave action. There is an agent responsible for painting the world, and another which evaporates pheromones in the background.

Anyway, the demo was impressive -- since painting makes a copy of the world in a transaction, it has a completely consistent view of the world. Refs make sure that all changes to them are in transactions, so you have language support for where you need cooperation (contrasted to locking, which is not enforced). Agents also help you model the real world in a way that a coordinated single-looped simulation (calling behave on ants in a loop, then paint over and over again) could not.

And clojure's agent mutating mechanism (sending a function to it), means that agents don't have to have any knowledge of the messages that might be sent to it (again contrasted to Erlang Actors). Finally, various messages can take different times to complete and that would be represented in the simulation --- some ants might complete several small actions in the time it took another to complete one (which would not be the case in a behave loop).

I'll have more on this when the slides, code, etc are available.

I'll be giving the next presentation at the Western Mass Dot Net Users Group on the basics of UML. Details:

Presentation:
Get an introduction to the Unified Modeling Language. Learn the basics of Class, Sequence, and Use Case diagrams.  The emphasis will be on UML sketching, but UML code generation will be discussed.

This session will be platform independent.  Please bring an open mind, your ideas, and experience to share with the group.  Software developers, project managers, students and anyone interested in software development on any platform are encouraged to attend.

Meeting Details:
Tuesday, February 7 at 6:00 PM
Fazzi Associates, Inc.
243 King St. Suite 236, Northampton

The old .NET SAPs is rechristened under the name: Western Mass .NET Users Group  (and a spiffy new website). Tomorrow's meeting topic is XML.

Speaking of XML, I saw this recently: Don't Invent XML Languages by Tim Bray. In addition to pointing to this great list of XML Languages, he introduces "The Big Five" XML Languages and where they should be used.

Suppose you’ve got an application where a markup language would be handy, and you’re wisely resisting the temptation to build your own. What are you going to do, then?

The smartest thing to do would be to find a way to use one of the perfectly good markup languages that have been designed and debugged and have validators and authoring software and parsers and generators and all that other good stuff. Here’s a radical idea: don’t even think of making your own language until you’re sure that you can’t do the job using one of the Big Five: XHTML, DocBook, ODF, UBL, and Atom.