Wednesday, December 26, 2012
Well, you already know but I still think wiki has a future, as pointed to by Smallest Federated Wiki. There are some flaws / issues with SFW, mainly I think because not enough people are working on it, but it’s still the signpost for how wiki could evolve.
Would still love to see you and other UseMod / OddMuse people look at ways to engage, even if you don’t switch over.
2012 is the year when it just became more and more clear that we need our own space and shouldn’t be dependent on Fb / Tw / G+ etc.
Fb / Tw / G+ offer two compelling things : 1) an aggregate river of stuff from people we care about, 2) really easy transclusion from various rich media sites.
We could have a distributed river architecture if we took RSS and some kind of pubsub architecture (eg. RssCloud) seriously. SFW has made transclusion protocols central to its philosophy. If we pick up on both, figure out how to get the most important things we get from the mainstream working smoothly, we can create a compelling alternative on our terms. And one of the interesting, overlooked, facts about G+ is that it showed that significant numbers of people are still willing to experiment with alternatives. As long as you can get a critical mass of around 20 people you care about to use it, G+ is as valuable as anything else. You don’t need 1 billion users. You aren’t trying to take over the world at this point, just to have a syndication / discussion architecture which isn’t owned by THEM.
Wednesday, December 19, 2012
Saturday, November 24, 2012
There's something about Vi Hart's recursive video about how she makes her videos which reminds me strongly of the Lispish ideal of having the Lisp interpreter available at write-time, compile-time and run-time.
Friday, November 16, 2012
Saturday, October 27, 2012
Sunday, October 21, 2012
Tuesday, October 16, 2012
Initial thoughts :
Big question is what it compiles to. It's about time we had a programming language that compiles a single program down to parts that run on both server and clients, in a really easy and transparent way.
Building in knowledge of protocols like http and json and making services like twitter at least members of the standard library is a good idea.
Like most programmers, I'm sceptical of the "easy English-like" nature of it. We've had plenty of time to learn that what's hard in programming is the logical thinking not the strange syntax. (Update : See my Quora answer)
But if Dog can become a little-language which makes it easy to configure and administrate social software back-ends then it will be very useful. Particularly if there are ways of compiling the same program down to multiple back-ends (Django, Rails, Chicago Boss etc.)
Tuesday, October 02, 2012
Sunday, September 30, 2012
Nice idea. I'm tempted to buy some of these.
Saturday, September 29, 2012
Friday, September 14, 2012
I just want to say here that I like RSS, for what it is, and what it does, and I like JSON to actually work with, because parsing XML is still a faff. So it gets my vote.
Tuesday, August 14, 2012
Tuesday, August 07, 2012
I used it to build my wonderful Future Manufacturing river. And I want to use it for more things. So I've created a small script to make installing Planet ultra-easy on a linux server.
Four steps and you're rolling :
# clone it
git clone https://github.com/interstar/PlanetBuilder.git planets
# make the planet
# add feeds
# defaults have been set-up, just change and add the feed URLs and names at the bottom of the config.ini file and set your name and contact details (earlier in the file)
# edit the crontab
# and add the following line or suitable variant.
53 * * * * /PATH/planets/MYPLANET/refresh.sh
# note that the line with the correct value of PATH will have been given to you when you ran the create script
Your automatically generated aggregate will start being available at MYPLANET/index.html
Monday, August 06, 2012
We need to defend the principle of a platform independent / open feed of news items from all the companies like Facebook, Twitter, Google and Apple who have seen the future as feeds insided their own proprietory walled "gardens".
Not sure if a garden is the right metaphor for a feed routing system, maybe "walled river"?
Something like this? :-(
Open rivers of news are wonderful things. Recently I've started using the venerable Planet feed agregator to make some public planets (rivers) such as this mind-boggling "Future Manufacturing" one. Glance at that and see exactly how awesome open RSS is. And how it can be way more compelling than the constrained Twitter or your riddiculously cramped Facebook wall. Look at a torrent of exciting information that can actually "breath", where text can be as long as it needs and where pictures are wide-screen rather than crammed into a cage designed to make you look at adverts.
Saturday, July 21, 2012
Friday, July 13, 2012
Friday, June 29, 2012
Wednesday, June 27, 2012
Increasingly when I use the netbook I try to get away with doing things in a ctrl-alt-f1 shell without logging in to the GUI at all. I'm starting to wish more software could be used in this environment so I began to look at Curses, the standard library for text-window UIs. There's a convenient Python wrapper of course. And there's another nice library in Python : Cmd, for creating a command-line driven apps. That is, not programs that literally run as small tools on the shell with command-line arguments, but programs which have their own internal "repl" style loop which you drive by typing in commands. Cmd handily hides the details from you, letting you declare a subclass of the Cmd class which simply defines handlers for specific commands. It's not a million miles away from something I ended up writing to handle the commands in SdiDesk.
For some of my projects it would be useful to combine the two modes : to have Cmd style input driving a 2D textual output using Curses. Unfortunately Cmd and Curses don't obviously play well together. Both of them want to take over the input, with Curses thinking in terms of keystrokes while Cmd still expects full lines.
Nevertheless, after a bit of exploration, and learning about Curses's textpads and Cmd's supplementary methods, I'm starting to get the two to co-operate. As this gist shows :
It doesn't do anything yet. Just handles a "greet NAME" command that prints "hello NAME". And a "quit" command that exits the program. But it has combined Cmd inputs with Curses output.
Sunday, June 10, 2012
My approach is non-standard, but hopefully conveys the message :-)
 Rather like Steve Jobs trying to hide the file-system, some people love to take away anything that it might actually empower you to learn about.
Iterative, "test driven", development.
Break your idea down into a number of simple "stories", each of which describes a single chunk of activity which goes all the way through from the beginning to the end of a user's experience with the software. Importantly a story is not a traditional "component" ... but represents a complete, working but minimal slice through the functionality.
For example, a story could be "the user goes to our site at a URL and sees a page describing our idea" or, for a drawing program, "the user can create and save a jpg file" (even though that jpg file is just a blank canvas).
Once you have some stories, order them by importance. If you could only get one story working, what would be the most valuable? If you could only get two stories, which would those be?
Start on the most important story. As any particular story shouldn't be too complicated, you can probably figure out fairly intuitively the components you need in order to make it happen. (If you can't, you're trying to fit too much into a single story.) Those components might be functions, they might be objects which have several methods (if so, ONLY worry about the methods of the object which satisfy the current story, ignore any others), they might be HTML forms or templates.
Now write AUTOMATED TESTS for the components you need for this story. Unit tests for the functions and objects. Ideally something like Selenium for the web forms.
Write code to pass the tests in a test-driven style ... ie. write test, write code to pass test, refactor your code to eliminate redundancy, write next test etc. When one story is finished, start figuring out how to do the next most important and work on that.
Somewhere down your list of stories you have your minimum viable product: that is, the minimal thing which is worth releasing to your customers in order for them to give you feedback on whether this is useful to them. That is not necessarily just one story, it might be after the first three. Or the first ten. Whatever it is, once you hit it, release your product to the customers and start getting their reaction.
From now on you are in maintenance / iterative growth mode. You'll be taking the feedback from the customer to rewrite and reorder the stories. While continuing to implement them according to your best, most up-to-date, sense of priorities. You'll want to release new development to the customer as fast as reasonably possible so you can collect the feedback on your improvements too.
Don't assume that one story has to equal one release, because you'll be tempted to inflate your individual story to contain more than it should. But try to keep releases down to as few stories as possible so they can happen frequently : which maximizes both your information, and the customer's sense of progress.
Saturday, May 26, 2012
The job was really to take C++, which was a fairly static language, and show people how to write dynamic programs in a static language. That's what most of the patterns in that book were about. And in the process, patterns extended the life of C++ by a decade, which is not what I thought would happen. What I thought would happen is people, when they learned these patterns, would look at them and say, "Wow, these patterns are hard in C++ and they're easy in Smalltalk. So if I want to think in terms of these patterns, I might as well use a language where they're easily expressed." And extend the life of Smalltalk by a decade. But the opposite happened.I always suspected that the patterns everyone got so excited about were basically a way of overcoming static typing. Ward confirms it :-)
Friday, May 25, 2012
Wednesday, May 23, 2012
Tuesday, May 22, 2012
So here's a quick manifesto (in progress) that I'm writing about what's at stake in the new era, how it's the same as and different from the previous one.
Friday, May 11, 2012
First thought. Seems to me that far more important than using the same language for the client and server is being able to write the client and server code in the same file.
That is something I've been waiting for for a long time.
Thursday, May 10, 2012
Is this implemented in the browser? (Bespin? CodeMirror)? Perhaps we're seeing this explosion of innovation as IDE authors move to the cloud.
A Kickstarter project? That's cool. But motivated by early investors getting licenses? Does it also mean that this next wave of software innovation will be abandoning Open Source as a model?
Elements of Jonathan Edwards's Subtext in the tree of updates. Of course, he's paying attention.
Tuesday, May 01, 2012
I love SFW a lot, but it's a bit of a pain to bring a page or large chunk of writing from elsewhere into it. Adding one paragraph at a time is a nuisance.
So here's a quick tool to create an SFW page from an arbitrary large, multi-paragraph chunk of text. Just paste your text into the box, add a title and choose whether you want ordinary paragraphs (of the kind that most SFW installations use) or whether you want "wikish" (the UseMod derived format which is somewhat compatible with UseMod / SdiDesk markup). Hit the submit button, and it will deliver a json file suitable for dropping into the pages directory of your SFW installation.
Update : the source-code for this is part of Project ThoughtStorms on GitHub. (Note: I may have broken other import scripts in the refactoring to make this import script work. Please log an issue if you find this.)
Sunday, April 22, 2012
Here : http://thoughtstorms.info/view/smalltalkunix
Saturday, April 21, 2012
Tuesday, March 27, 2012
Saturday, March 24, 2012
Thursday, March 22, 2012
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.
Thursday, March 15, 2012
Sunday, March 11, 2012
Tuesday, March 06, 2012
Friday, March 02, 2012
Monday, February 27, 2012
Saturday, February 25, 2012
Friday, February 24, 2012
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.
I wanted to experiment creating different permutations of a collection of items. (In fact I'm working on some code for laying out shapes on a surface.)
Prototyping in Python to get my ideas straight I came up with this neat generator solution.
Wednesday, February 08, 2012
These days, I'm thinking a lot about 3D printers, desktop manufacturing and software to create physical things.
Last year I did some art pieces using software to generate drawings for laser cutters and 3D printers, and I'm continuing along the same line. I want to move this stuff into the browser, and the combination of CoffeeScript and Raphael.js is turning out to be pretty good for this. (Did I mention I really, really like CoffeeScript?)
I also dabbled a bit with Prolog, wondering whether it can be used as a high-level description language for machines or other complex objects. The really interesting question is if you can use the built-in inference engine of Prolog to help with the design. (Aside, here's a silicon layout engine in Prolog) I haven't got very far with that yet, but I'm now considering how Prolog can be combined with or made to output OpenScad (or PyScad) code.
A couple of days ago Simon Wardley posted on his blog that he was searching for a SpimeScript :
So, I want to return to ... the formation of Spime Script. We're entering a phase where hardware will become increasingly as malleable as software which leads to a problem of choice - if I want to change the function of something, do I do this in software or hardware? The tendency today is obviously towards software because its more malleable but the future is never the past. However this creates a problem of skill - will I need to become proficient in both software and CAD / electronic design?
In reality both CAD and whatever software language you use, compile down to instruction sets and the function of the device is the interaction of these instruction sets - one which is substantiated physically and the other which is substantiated digitally.
Turning this on its head then why not write the function of what you want, the function of the device? Compilers can therefore undertake the complex decision trees (which is what they're good at) required to determine what element of that function is encoded as physical and what element is digital.
A future language is needed, something whereby the output is both physical and digital and I describe merely the function of what I'm after.
That's a really exciting vision.
Now, here's what I think is really important for a SpimeScript.
It should learn from HTML / CSS.
While HTML / CSS is a pain in many ways, there's a very interesting insight in it about design. That design comes in layers. It's partly about the separation of logical structure and visual style. It's partly about the cumulative effect of the Cascade in Cascading Style Sheets. It's partly about the fact that the browser has reasonable defaults for the geometric properties of logical structure. (Today, those defaults look rather out-of-date but there would be little to stop a browser manufacturer making their defaults look more like Readability or Twitter Bootstrap.)
So here's the main feature request for a SpimeScript. It should be possible to define the logical structure of, say, a machine and have some layout-engine give it plausible default geometric properties. But it should also be possible for designers to layer optional design hints on top of that layout in the form of extra constraints and have the engine deal with fitting them together.
As with the silicon design case, there must be some prior art here, but I'm not quite sure where it is. Electronic Design Automation maybe.
Sunday, January 29, 2012
The nice thing about this : everything is inspectable / hackable. All the way down.
Thursday, January 26, 2012
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.
Saturday, January 07, 2012
Tuesday, January 03, 2012
The main thing I'm doing is to have two wave-tables for a voice, and then slowly swap sample points between them to get a long-term evolution of the sound. I want to get a rich and ever changing timbre cheaply ie. without having to use filters or expensive FFT.