Personal Question

Question : Hey Phil, do you actually do any programming these days?

Answer : Yes. Quite a lot at the moment. Though it's a bit all over the shop.

I'm dipping a toe into Android programming. (And, hmmm ... Java .... I thought I'd got over my Java hangups by doing a lot of Processing, but it turns out that Processing just hides the crap and Android doesn't. Why hasn't Google picked up on Processing to turn it into a first-class Android art / game app. development environment?)

I'm mainly writing CoffeeScript. Some stuff related to my ongoing 3D modelling / desktop manufacturing projects. (Did I forget to mention those? I'm sure there's a half-written blogpost somewhere.) Some work towards an SdiDesk-derived network diagramming plugin for Smallest Federated Wiki (held up by silly problems). Some other bits and pieces. I've recently been playing with Jison, which rocks. And I'm about to investigate angular.js which looks pretty good.

There's a project for small stand-alone web-servers that I'll talk about more if / when it takes off.

I've been trying to compile example VST instruments  (C++) for some of my work with the Brasilia Laptop Orchestra, but it's driving me crazy. (I may go back to Pure Data which can be embedded in a VST.)

A bit of PHP, just simple small web-services.

I'm going to be teaching an Arduino course soon. So I'll be writing a bit of C and I want to try Occam-Ⲡ.

I'm still writing Python too. Mainly for short file transformation scripts or to prototype algorithms that later get translated into CoffeeScript.

Some of this stuff is headed for GitHub soon.

Project ThoughtStorms

As mentioned previously, I've been looking into Ward Cunningham's "Smallest Federated Wiki" concept. And I'm increasingly impressed.

So much so, that I've re-oriented a lot of my projects around it.

What do I mean? A decent follow-up to SdiDesk has been promised for an embarrassingly long time. Over the years I've struggled with exactly what it should be and how it should be implemented. Largely whether it should be a desktop application or something you access via the browser. The browser has always been the logical answer but, until recently, the network diagramming aspect of SdiDesk was not really an option in mainstream browsers. OTOH, desktop GUIs open a can of worms. Which OS? Which GUI framework? How do I write installers and distribute? (And, frankly, what is my, as a non-Mac owner / developer, attitude towards the iPad?)

In 2012 though, HTML5 and CoffeeScript have become extremely plausible options for the client. And the server can become a simple wrapper around a basic PageStore. That's an architecture I've been meaning to get down to write. But it's the architecture that already exists for the SFW.

So, great! By hooking onto that project, I get my basic server / PageStore / client architecture free.

Furthermore it's extensible via plugins. So I can embed special types of paragraph data and special renderers. That's exactly what I wanted to do with the new SdiDesk - instead of having *pages* that were network diagrams or grids, have these as individual components of pages. This is perfect. I can concentrate on what interests me - the special plugin types - and Ward's team can do the infrastructure. :-)

Not to mention, Ward and co. are doing amazing plugin wizardry already : hooking data-feeds from Arduinos, graphing it, bytebeats, calculators. It already has a lot of what looked nice about QEDWiki.

The multi-panel view surprised me initially, but it's really useful for refactoring. And that's going to help me considerably with wiki-composting.

Finally, the "federated" part of the Simplest Federated Wiki is the answer to a bunch of problems I didn't even know I had. Or, at least, didn't conceptualise well. How do I have a private wiki (like a local SdiDesk, where I like to draft things before they go public) AND a public wiki (like ThoughtStorms) and make it easy to move newly public stuff from one to the other? How do I balance the desire to have special project focused wikis (like the OPTIMAES one) with wanting to refer to that stuff from the main wiki? How do I balance contributing to my own wiki and contributing to other communities' wikis?

So, I'm sold. As Dave Winer likes to say, it's the second mover who makes the standard. And that's what I want to help with. There's enough overlap between the SFW and the things I've been wanting to do over the last few years that it makes sense for me to implement my ideas as plugins for the SFW, to port my wikis over to to it and to go around shouting about how wonderful it is. Because, actually, it is pretty damned wonderful.

So, Project ThoughtStorms is where I'm putting the code: so far, converters from the ThoughtStorms UseMod and the SdiDesk formatted pages, and plugins to render the markup. I'll be porting ThoughtStorms over to a SFW server soon. Then I'll be doing some serious refactoring and cleaning up the actual writing. Trashing a lot of the ephemeral junk and dead-links. TS has become a bit of a museum, which it shouldn't be. It should be a living, learning, and forgetting thing.

After that, I'll be sitting down to do some of the other things I've wanted to do in a wiki context but not had the platform to do justice to.  Now I think I have one.

Smallest Federated Wiki

I can't believe I haven't looked more carefully at Ward Cunningham's Smallest Federated Wiki. I did glance at it before, but am now making my way through the videos. Lot's of absolutely perfectly pitched ideas working together.

Three.js

Bloody hell! Three.js is cool. And CSG.

What can't you do in the browser these days?

Rails Off The Rails

Seems like the same thing has happened with Ruby on Rails as happened with, say, Zope.

Giles does a pretty good analysis. The key point is that as frameworks mature they start supporting legacy users and applications who, in turn, have different requirements and values from those looking for a quick way to build new applications.

CoffeeScript

Just a note. I am really, really liking CoffeeScript now.

It's reminding me both of freedom that Python gave me when I first turned to it after Java. And bit of my experience with Erlang. ( If only it had Erlang's Actor model and pattern matching arguments ... )

The other good effect of this, CoffeeScript is making me more comfortable with investing my time writing serious logic on the browser-side. Which is where it should be, given the requirements of modern applications and that the browser is becoming the default GUI. 

CoffeeScript and Raphael.js

I've been working on a project based on some of my recent artistic works. I thought I'd do it using a Processing sketch embedded in a web-page. It's not that I was particularly happy with Java applets (in 2011!) but I figured I'd make use of the Processing code I already had.

After a whole lot of faffing around trying to get the applet talking to my server, I'm realising that this is really NOT going to fly for a whole bunch of reasons. I wasn't really seeing Java as my long-term future anyway, but I've realised that it isn't even going to be the quick, dirty but workable prototype that I'd hoped. So, if I have to make a break, I might as well do it now and quickly. And look to the future rather than the past. So I've made a decision to rewrite with CoffeeScript and Raphael.js. (I'm generating SVG designs anyway, so Raphael is ideal.)

After a spending a couple of hours today, that's feeling like good decision. There's still the hassle of having to convert a lot of code, and it's a bit of a fiddle going backwards and forwards between the editor, the command-line compiler and the browser. But CoffeeScript feels like a good language. Obviously meaningful whitespace indentation is comfortable for a Pythonista like me, and I'm getting used to the Rubyisms without too much pain.

Not much in the way of debugging information, which hasn't bitten me yet, but might. Still, I'm positive.

I certainly like the look of CoffeeScript.

Not quite sure what it's for yet. Is it just a nicer looking syntactic sugar on top of javascript? Or are there some powerful abstractions that simplify doing larger scale js work? (a la jQuery?)