Saturday, June 21, 2008
This man is cool ... just cured my headache.
Code-swarm. Nice :-)
Avi Bryant is working to bring Smalltalk scaling technology to Ruby on Rails.
Could Smalltalk / Ruby pretty-much merge with a common VM?
Could Smalltalk / Ruby pretty-much merge with a common VM?
Thursday, June 19, 2008
A while ago on Platform Wars I wrote :
Wildly inaccurate estimate I'm sure. But I'll bet it dwarfs XML formats including RSS. So where's the Yahoo Pipes for CSV and spreadsheet data? The mashing, pivot-tabling, cartesian joining of live grids?
Yahoo Pipes does have a CSV reader ... but I'd like to see more. Particularly pivoting and SQL-like selects, projects and joins.
99% of the world's "semi-structured" data is not in Microformats but in tables in spreadsheets.
Wildly inaccurate estimate I'm sure. But I'll bet it dwarfs XML formats including RSS. So where's the Yahoo Pipes for CSV and spreadsheet data? The mashing, pivot-tabling, cartesian joining of live grids?
Yahoo Pipes does have a CSV reader ... but I'd like to see more. Particularly pivoting and SQL-like selects, projects and joins.
Marcadores:
excel,
feeds,
rss,
spreadsheets,
yahoo pipes
Anyone not worked out how to use #tags in Mind Traffic Control?
All you do is write your tag words with a # as in #work or #food and these items get tagged. Once you have tagged items in your current queue, a select box appears at the right of the "next action" box, allowing you to filter next actions by a tag.
Once you select a filter, only items with the selected tag will be shown. To see all queued items again, simply remove the filter.
All you do is write your tag words with a # as in #work or #food and these items get tagged. Once you have tagged items in your current queue, a select box appears at the right of the "next action" box, allowing you to filter next actions by a tag.
Once you select a filter, only items with the selected tag will be shown. To see all queued items again, simply remove the filter.
Wednesday, June 18, 2008
I'm eavesdropping on a fascinating email exchange between Chris Dent (of Blue Oxen and Socialtext fame) now working on TiddlyWeb and Frank McIngvale who's project is WikklyText.
I haven't had time to take it all in yet. But it looks like Chris has got TiddlyWeb working on the Google App. Engine. And Frank has got a stand-alone TiddlyWiki markup language working.
The main idea of TiddlyWeb continues Chris's focus (since Blue Oxen days with EEKim, I'd guess) on sub-page level elements on wiki. Remember Blue Oxen's thing was Purple Numbers, individual paragraph Ids. Here, he's using "Tiddlers", the individually named, sub-page elements that TiddlyWiki would show or hide, and assembling them in a new, looser collections called "bags".
From what I understand so far, having named tiddlers rather than arbitrary purple numbers is definitely a move in the right direction. (In the sense that it makes the small pieces human-addressable as well as machine-addressable.) In fact each item is addressed by a combination of Tiddler name + bag name (where bag is more a kind of policy or query)
There's long discussion going on right now about URIs (which seem to become almost queries or operations on the bags) to access the tiddlers in a ReSTful way that I'm still absorbing.
Anyway, they're definitely "banging the rocks together" in wiki and breaking pages up into a finer granularity. And, after Twitter's discovery of the virtues of 140 character status updates, now generalized to a theory of micro-blogging, the world is definitely ready for a wiki micro-chunking experiment. Who knows where it will lead?
I haven't had time to take it all in yet. But it looks like Chris has got TiddlyWeb working on the Google App. Engine. And Frank has got a stand-alone TiddlyWiki markup language working.
The main idea of TiddlyWeb continues Chris's focus (since Blue Oxen days with EEKim, I'd guess) on sub-page level elements on wiki. Remember Blue Oxen's thing was Purple Numbers, individual paragraph Ids. Here, he's using "Tiddlers", the individually named, sub-page elements that TiddlyWiki would show or hide, and assembling them in a new, looser collections called "bags".
From what I understand so far, having named tiddlers rather than arbitrary purple numbers is definitely a move in the right direction. (In the sense that it makes the small pieces human-addressable as well as machine-addressable.) In fact each item is addressed by a combination of Tiddler name + bag name (where bag is more a kind of policy or query)
There's long discussion going on right now about URIs (which seem to become almost queries or operations on the bags) to access the tiddlers in a ReSTful way that I'm still absorbing.
Anyway, they're definitely "banging the rocks together" in wiki and breaking pages up into a finer granularity. And, after Twitter's discovery of the virtues of 140 character status updates, now generalized to a theory of micro-blogging, the world is definitely ready for a wiki micro-chunking experiment. Who knows where it will lead?
Marcadores:
chris dent,
eekim,
microblogging,
microchunking,
purple,
purple numbers,
tiddlyweb,
tiddlywiki,
wiki
Sunday, June 15, 2008
I use Subversion source-control (I have one web-hosted repository, one on my pendrive, and I just started using Google Code.)
But I'm tempted by distibuted source-management. The arbitrary decision as to whether I host a project online or on my pen-drive is ... well ... arbitrary, and sometimes needs to be revised. Distributed would be better. And I'm increasingly tempted by Bazaar (bzr).
The other thing that attracts : it's in Python and easily incorporated into an existing python program. I haven't given up on the whole SdiDesk / wiki-like notebook / developing in wiki thing. Perhaps there'll be a bazaar-as-PageStore one of these days.
Meanwhile ... watching the proliferation of repositories (I'd like to check out Folknology's GitHub hosted Reactores) I'm starting to think there's a need for an access-standard. Some kind of lowest common denominator ways of checking out checking in and merging codebases from all these repositories.
Anyone know of anything like this?
But I'm tempted by distibuted source-management. The arbitrary decision as to whether I host a project online or on my pen-drive is ... well ... arbitrary, and sometimes needs to be revised. Distributed would be better. And I'm increasingly tempted by Bazaar (bzr).
The other thing that attracts : it's in Python and easily incorporated into an existing python program. I haven't given up on the whole SdiDesk / wiki-like notebook / developing in wiki thing. Perhaps there'll be a bazaar-as-PageStore one of these days.
Meanwhile ... watching the proliferation of repositories (I'd like to check out Folknology's GitHub hosted Reactores) I'm starting to think there's a need for an access-standard. Some kind of lowest common denominator ways of checking out checking in and merging codebases from all these repositories.
Anyone know of anything like this?
Ouch! Major down for Mind Traffic Control today.
Must be something to do with the fix I posted this morning which I thought was pretty harmless (and worked for me at that moment, honest!)
Anyway, I'm not in front of a machine where I can work on it, this second. But I'll roll back to the previous the moment I am. Probably in an hour or two.
Must be something to do with the fix I posted this morning which I thought was pretty harmless (and worked for me at that moment, honest!)
Anyway, I'm not in front of a machine where I can work on it, this second. But I'll roll back to the previous the moment I am. Probably in an hour or two.
I fixed a subtlish bug in Mind Traffic Control today.
I was trying to pull the email address out of user objects using user.email() ... however it seemed that you might be able to have users who don't have an email address and for who user.email() fails or returns None. Not common, I guess because user id's are based on Google accounts (which is mainly Gmail accounts I'd assume.)
Anyway I've now wrapped all attempts to get user.email() in a try. But next question, what should I do instead? When I find a user without an email, what should I use to identify him or her?
I was trying to pull the email address out of user objects using user.email() ... however it seemed that you might be able to have users who don't have an email address and for who user.email() fails or returns None. Not common, I guess because user id's are based on Google accounts (which is mainly Gmail accounts I'd assume.)
Anyway I've now wrapped all attempts to get user.email() in a try. But next question, what should I do instead? When I find a user without an email, what should I use to identify him or her?
Ohloh is a YASN for free-software writers?
Saturday, June 14, 2008
Thursday, June 12, 2008
Tim Burks talks about his language Nu (seems to be kind of Ruby-like behaviour with a Lisplike appearance (lack of syntax?)
Good references to Brad Cox's Planning the Software Industrial Revolution.
Cool. Didn't know this stuff before.
Good references to Brad Cox's Planning the Software Industrial Revolution.
Cool. Didn't know this stuff before.
Marcadores:
functional programming,
lispy,
programming
Tuesday, June 10, 2008
Dan Bricklin :
Cool ... now, if they could just *also* add network diagramming as another page-type that would really be getting somewhere. (Not, of course, that the grid pages in SdiDesk really achieved "spreadsheet" status ... but that was always a long term hope.)
Ah ... well ...
Actually, there may be some SdiDesk news soon ... you never know.
Update : Bricklin has longer background piece.
Socialtext is announcing today that they are adding integrated spreadsheet capability to their enterprise-level wiki, making use of the new SocialCalc code I've been developing with them. This isn't just a repository of separate spreadsheets, nor a separate standalone system like wikiCalc, but rather a full wiki where a page can be either the traditional paragraphs of text or a spreadsheet grid.
Cool ... now, if they could just *also* add network diagramming as another page-type that would really be getting somewhere. (Not, of course, that the grid pages in SdiDesk really achieved "spreadsheet" status ... but that was always a long term hope.)
Ah ... well ...
Actually, there may be some SdiDesk news soon ... you never know.
Update : Bricklin has longer background piece.
Marcadores:
sdidesk,
social software,
socialcalc,
spreadsheets,
wiki,
wikicalc
Monday, June 09, 2008
Saturday, June 07, 2008
Great talk by Ian Piumarta.
From the fascinating looking Workshop on Self-sustaining Systems (S3) 2008.
From the fascinating looking Workshop on Self-sustaining Systems (S3) 2008.
Friday, June 06, 2008
Mind Traffic Control is ruthelessly useful. Indeed, it kind of strips out everything else *execept* usefulness.
Which is why, if you're thinking of trying it out, here's a hint. Don't try by putting in some random fake items like "test 1", "test 2" etc.
All they do is sit there and remind you to do them. You can't fiddle around organizing and prioritizing them, dragging and dropping or attaching little icons to them etc. (Which is the point.) So MTC looks inert.
In fact it *is* inert, because you don't really need it. MTC does nothing, because you want nothing from it. You don't really have a task of doing "test 1" or "try out mind traffic control" so the computer can't help.
It's as if Mind Traffic Control magically knows when it's being useful and when you don't really care.
So, to get the real MTC experience, put some real tasks in. Just 3 or 4 of the things you actually have to do over the next couple of days, and leave it open in a browser-tab on your machine.
Then MTC feels wanted. And the magic kicks in. ;-)
Which is why, if you're thinking of trying it out, here's a hint. Don't try by putting in some random fake items like "test 1", "test 2" etc.
All they do is sit there and remind you to do them. You can't fiddle around organizing and prioritizing them, dragging and dropping or attaching little icons to them etc. (Which is the point.) So MTC looks inert.
In fact it *is* inert, because you don't really need it. MTC does nothing, because you want nothing from it. You don't really have a task of doing "test 1" or "try out mind traffic control" so the computer can't help.
It's as if Mind Traffic Control magically knows when it's being useful and when you don't really care.
So, to get the real MTC experience, put some real tasks in. Just 3 or 4 of the things you actually have to do over the next couple of days, and leave it open in a browser-tab on your machine.
Then MTC feels wanted. And the magic kicks in. ;-)
Wednesday, June 04, 2008
Aza Raskin dreams of easier Firefox extensions.
Let's hope that he's working on it.
Also, interesting to compare Steve Yegge on the Firefox vs. Emacs war.
Let's hope that he's working on it.
Also, interesting to compare Steve Yegge on the Firefox vs. Emacs war.
Tuesday, June 03, 2008
Loads of nice stuff going on in Squeakland.
Showing Seaside demos to a colleague this week made me wonder whether I need to dive back in. It's been a long time (15 years) since I wrote any Smalltalk. And what with Python, Erlang, GeekWeaver + some C, PHP, Javascript; and Cache ObjectScript (don't ask!) in day-job, do I have room for Squeak?
But PyPy Goes Squeak looks fascinating.
As does this conference.
Showing Seaside demos to a colleague this week made me wonder whether I need to dive back in. It's been a long time (15 years) since I wrote any Smalltalk. And what with Python, Erlang, GeekWeaver + some C, PHP, Javascript; and Cache ObjectScript (don't ask!) in day-job, do I have room for Squeak?
But PyPy Goes Squeak looks fascinating.
As does this conference.
Marcadores:
C,
erlang,
javascript,
php,
programming,
python,
smalltalk,
squeak
Monday, June 02, 2008
Goosh (Google Shell) ... not from Google, but damned cool.
Very interesting history of Nouncer.
Marcadores:
business models,
microblogging,
microisv,
startup
GAE pricing looks reasonable from my perspective.
Or have I not thought through the scenarios? Glad I'm not trying to run some kind of video store of course.
Or have I not thought through the scenarios? Glad I'm not trying to run some kind of video store of course.
Saturday, May 31, 2008
The biggest problem I've noticed people having with Mind Traffic Control is with delegating. They were sometimes delegating without filling in the task description (thinking that the original task description would get copied across - which it wasnt't) or delegating to names of people which clearly weren't email addresses (or Goggle logins).
Now I've trapped this. When delegating a task, it's description gets copied (although you can still edit it), and the system also traps non-email addresses as targets to delegate to.
Keep watching ...
Now I've trapped this. When delegating a task, it's description gets copied (although you can still edit it), and the system also traps non-email addresses as targets to delegate to.
Keep watching ...
Marcadores:
mind traffic control,
mtc,
ui,
usability,
user-interfaces
Monday, May 26, 2008
Om Malik suggests a freemium business model for Twitter that starts charging for tweets per follower.
Sunday, May 25, 2008
Rather great Paul Graham essay on adult treatment of children.
This resonates :
Update : and another good one on the internet as dangerous distraction for procrastinators. Twitter is ridiculously addictive. In the wrong state of mind I can find myself trying to refresh once a minute.
Mind Traffic Control is partly meant to try to harness that dynamic for good ... or at least for work. It gives you something to click manically hoping for new surprises to pop out, but it's only ever work which pops (assuming you only put real work or necessary tasks in).
Note, at some point I may import RSS feeds into MTC ... but remember, it's vitally important you do not connect MTC up to some kind of "news" feed. Don't drink from the fire-hose, as they say.
This resonates :
Innocence is also open-mindedness. We want kids to be innocent so they can continue to learn. Paradoxical as it sounds, there are some kinds of knowledge that get in the way of other kinds of knowledge. If you're going to learn that the world is a brutal place full of people trying to take advantage of one another, you're better off learning it last. Otherwise you won't bother learning much more.
Very smart adults often seem unusually innocent, and I don't think this is a coincidence. I think they've deliberately avoided learning about certain things. Certainly I do. I used to think I wanted to know everything. Now I know I don't.
Update : and another good one on the internet as dangerous distraction for procrastinators. Twitter is ridiculously addictive. In the wrong state of mind I can find myself trying to refresh once a minute.
Mind Traffic Control is partly meant to try to harness that dynamic for good ... or at least for work. It gives you something to click manically hoping for new surprises to pop out, but it's only ever work which pops (assuming you only put real work or necessary tasks in).
Note, at some point I may import RSS feeds into MTC ... but remember, it's vitally important you do not connect MTC up to some kind of "news" feed. Don't drink from the fire-hose, as they say.
Marcadores:
mind traffic control,
mtc,
neotony,
open-mindedness,
procrastination,
smart
I realize there's no defined way of submitting bug-reports or suggestions for Mind Traffic Control. I need to set one up. In the meantime, use the comments for this post.
Thursday, May 22, 2008
Couple of interesting posts on Twitter scaling issues.
Twitter starting a conversation with the community, and some speculation about the issues. It's not the writing it's the "view my page which collates from multiple other users" which is the issue.
If that's the case I wonder what an Erlangish solution would be. There's no real reason for the Twitter *database* to be centralized at all. (In this sense, Winer's thoughts on total decentralization are apt.) Could you not have multiple nodes, each with it's own database of some users. These nodes are going to have to talk to each other only when someone pulls a page out.
You could also, presumably, in the extreme case have entirely separate servers for different users, and only integrate the overview of all people being followed "at the glass" in the browser or RIA client.
Twitter starting a conversation with the community, and some speculation about the issues. It's not the writing it's the "view my page which collates from multiple other users" which is the issue.
If that's the case I wonder what an Erlangish solution would be. There's no real reason for the Twitter *database* to be centralized at all. (In this sense, Winer's thoughts on total decentralization are apt.) Could you not have multiple nodes, each with it's own database of some users. These nodes are going to have to talk to each other only when someone pulls a page out.
You could also, presumably, in the extreme case have entirely separate servers for different users, and only integrate the overview of all people being followed "at the glass" in the browser or RIA client.
Wednesday, May 21, 2008
Adobe Thermo looks interesting.
At first, of course, it looks just like another Visual Basic which is of note only because it targets Flex (and hence the Flash Virtual Machine).
But it's clever in the way that it imports Photoshop files and takes advantage of some of the logical structure.
Not for me, though, obviously.
At first, of course, it looks just like another Visual Basic which is of note only because it targets Flex (and hence the Flash Virtual Machine).
But it's clever in the way that it imports Photoshop files and takes advantage of some of the logical structure.
Not for me, though, obviously.
Sunday, May 18, 2008
Wednesday, May 14, 2008
A very natural conjoining ... spreadsheets become wikis.
Smart Disorganized Philosophy #2
Chatting with BillSeitz I found myself saying this :
MTC needs to have what Udel called the "specialcharmpower" of email ... that groups are spontaneous and form bottom-up from the flow, rather than having to be designed up-front, prior to the flow .... otherwise people keep using email
Marcadores:
email,
group-forming,
mind traffic control,
mtc,
social software
Another list view for Mind Traffic Control
Tuesday, May 13, 2008
OK, somewhat ugly, but they're there by popular demand ... full lists of your tasks.
Don't worry Mind Traffic Control isn't forgetting them. :-)
Don't worry Mind Traffic Control isn't forgetting them. :-)
If you follow @exmosis on twitter you'll see he's busily trying to deconstruct Mind Traffic Control turning it into an untask-list or a barter-market.
@adrianh is constructively sceptical.
Lots here
@adrianh is constructively sceptical.
Lots here
Monday, May 12, 2008
Mind Traffic Control now has #tags.
If you use any word beginning with a # when describing a task, the task gets tagged with this word. And once you start tagging, a filter appears to let you filter your queue to present only those tasks which contain the tag.
Not entirely sure I've got the UI right on this one. It is simple, I think. But maybe not obvious, and maybe not in the right place at the moment.
Comments, bug reports, suggestions welcome as always.
BTW : a good thing about the GAE, it is so simple to add new functionality. This was about three hours of development and another 3 of debugging.
The reason for the longish debugging is what looks like a quirk in GAE.
At one point I was using a user object instead of a user email in a query. (I'm using user email's as user id in the database.) You might assume that this would simply fail with some kind of type error. But interestingly it worked on my local machine (somehow in the SDK it looks as though the user object gets correctly coerced into its email) but not on the appspot server where the query always returned nothing.
Read into that what you will.
If you use any word beginning with a # when describing a task, the task gets tagged with this word. And once you start tagging, a filter appears to let you filter your queue to present only those tasks which contain the tag.
Not entirely sure I've got the UI right on this one. It is simple, I think. But maybe not obvious, and maybe not in the right place at the moment.
Comments, bug reports, suggestions welcome as always.
BTW : a good thing about the GAE, it is so simple to add new functionality. This was about three hours of development and another 3 of debugging.
The reason for the longish debugging is what looks like a quirk in GAE.
At one point I was using a user object instead of a user email in a query. (I'm using user email's as user id in the database.) You might assume that this would simply fail with some kind of type error. But interestingly it worked on my local machine (somehow in the SDK it looks as though the user object gets correctly coerced into its email) but not on the appspot server where the query always returned nothing.
Read into that what you will.
Smart Disorganized Philosophy #1
I've been on a Smart Disorganized Individuals tip for several years, now. Always writing software compatible with that philosophy.
But what is the philosophy? What does this software mean?
In this series I'll start to make some specific notes towards that. Here's the first.
SdiDesk is wiki : a network of texts.
GeekWeaver is a programming language written in an outliner : a hierarchy.
Mind Traffic Control is a multi-user, dynamic queue, a "flow" of tasks.
Each is SDI. Each is completely different. Each is for specific purpose.
SdiDesk excels at capturing ideas and the relationships between them that are static.
Outlines excel at authoring or creating structure which is ultimately intended for a reader.
Flows excel at capturing change and movement.
OTOH, each is bad for something. These are true, even if you might imagine them not to be.
Wiki is surprisingly bad for authoring. Outliners are surprisingly bad for managing todo-lists. Flows are a surprisingly bad place to put ideas that you want to keep forever.
Wiki is great for writing, but awkward for the kind of reworking and structuring needed to polish a document for an external audience.
Outliners fail to match the dynamism of shifting tasks and priorities in the real world. They focus on making a structure of something which needs little structure.
MTC will lose your ideas when they are no longer in the future.
Marcadores:
developing in wiki,
geekweaver,
mind traffic control,
mtc,
outliner,
sdi philosophy,
sdidesk
Saturday, May 10, 2008
Today's Mind Traffic Control update.
The "defer" screen was simple, but not simple enough. Why make the user go through two mouse clicks - select a radio button and then the submit button - when this can be reduced to one? Now choosing how long you want to delay is a single button click.
I was also finding, when defering, that I wanted to remind myself of today's date. Now I've just added a display of today's date for convenience.
In general, I'm going to follow a philosophy of trying to identify and implement small improvements like this to MTC.
All suggestions welcome.
The "defer" screen was simple, but not simple enough. Why make the user go through two mouse clicks - select a radio button and then the submit button - when this can be reduced to one? Now choosing how long you want to delay is a single button click.
I was also finding, when defering, that I wanted to remind myself of today's date. Now I've just added a display of today's date for convenience.
In general, I'm going to follow a philosophy of trying to identify and implement small improvements like this to MTC.
All suggestions welcome.
Marcadores:
mind traffic control,
mtc,
ui,
usability,
user-interfaces
Friday, May 09, 2008
Just remembered Paul Graham's essay from earlier in the year. It really spoke to me (what with my bias towards the agile, experimental, piecemeal, wiki-natured, wabi-sabi way of design).
Of course it's my road-map for the ongoing development of Mind Traffic Control.
Of course it's my road-map for the ongoing development of Mind Traffic Control.
Wednesday, May 07, 2008
Mind Traffic Control roll-out continues.
Nothing spectacular in terms of numbers, but friends are making interesting comments and suggestions; and some strangers are discovering it via the Twitter announcement.
Eikeon pointed to twemes as a place to search for the #tag #MTC on Twitter.
Good chat with Folknology. He's encouraging me to open up the data. Hence I did CSV export of your tasks. Al, likes RSS/Atom but I still need to find out whether feed-readers can do the required Google login to get at a non-public feed.
Rup3rt weighed in with a number of comments starting :
and continuing
Good suggestions. I'll be interested to know what everyone else thinks.
But here are some initial thoughts :
Font issue, yep. Mailing tasks in to Mind Traffic Control would be great; a very useful addition. But I'm not yet sure I can do it on the Google Application Engine.
I might be able to do it using another hosting service but that's introducing a lot of new complexity into the system : running two different hosting services, writing scripts on the old-skool one to pass emails it receives into MTC in some way, being responsible for security (how do I stop spammers mailing tasks to you via the system?) etc. Going to take a while to figure that one out.
Importing other formats and / or entering multi-line, multi-task lists is easier and more likely to appear soon. I'll definitely go for the multi-line input box in the short-term future. I'd be interested to hear what formats readers currently use for to-do lists so that I can import them. I immediately think OPML, of course. But are there others?
Widgets ... actually I've been playing with OpenSocial and Orkut Widgets for my other GAE project. It's cute ... but I'm not yet sure what I'd put in a MTC widget.
Task counts and time estimates I'm ambivalent on. I don't want to make MTC a paranoia inducing space where you arrive on the front page to be presented with something saying "Welcome to Mind Traffic Control. You have 280 outstanding tasks". On the other hand, I see that people would like some sort of overall measure of what they have to do. More thinking on this.
Finally, there's a couple of issues of "philosophy", particularly why I'm resistant to letting you flag tasks with "priorities" but leaving that for the next post when I'll be more coherent.
Nothing spectacular in terms of numbers, but friends are making interesting comments and suggestions; and some strangers are discovering it via the Twitter announcement.
Eikeon pointed to twemes as a place to search for the #tag #MTC on Twitter.
Good chat with Folknology. He's encouraging me to open up the data. Hence I did CSV export of your tasks. Al, likes RSS/Atom but I still need to find out whether feed-readers can do the required Google login to get at a non-public feed.
Rup3rt weighed in with a number of comments starting :
Wow an invisible list machine almost like a gumball/toy dispenser ...
and continuing
I like to see what is ahead but it is good with the delegation - I can line up things for the estagiarios. This is great for non-negotiables like driving instructions, recipes.
* The font for "This task was delegated to you .. may report the sender for blacklisting and delete this task" is a bit big
* I would like a difficult autoaddress (1gg23ff3d3reedd@mindtrafficcontrol.appspot.com) to delegate tasks by email and maybe I could get other tasklists to feed into MTC using this (to just top it up with priority1 or todotoday tasks)
* Maybe paste a list of (line break delimited) tasks that are automatically added
* Maybe show in a widget
* Maybe show total number of tasks
* How would time estimates of task duration fit in? It could be a diversion to see "You have 13 hours of traffic to negotiate")
Good suggestions. I'll be interested to know what everyone else thinks.
But here are some initial thoughts :
Font issue, yep. Mailing tasks in to Mind Traffic Control would be great; a very useful addition. But I'm not yet sure I can do it on the Google Application Engine.
I might be able to do it using another hosting service but that's introducing a lot of new complexity into the system : running two different hosting services, writing scripts on the old-skool one to pass emails it receives into MTC in some way, being responsible for security (how do I stop spammers mailing tasks to you via the system?) etc. Going to take a while to figure that one out.
Importing other formats and / or entering multi-line, multi-task lists is easier and more likely to appear soon. I'll definitely go for the multi-line input box in the short-term future. I'd be interested to hear what formats readers currently use for to-do lists so that I can import them. I immediately think OPML, of course. But are there others?
Widgets ... actually I've been playing with OpenSocial and Orkut Widgets for my other GAE project. It's cute ... but I'm not yet sure what I'd put in a MTC widget.
Task counts and time estimates I'm ambivalent on. I don't want to make MTC a paranoia inducing space where you arrive on the front page to be presented with something saying "Welcome to Mind Traffic Control. You have 280 outstanding tasks". On the other hand, I see that people would like some sort of overall measure of what they have to do. More thinking on this.
Finally, there's a couple of issues of "philosophy", particularly why I'm resistant to letting you flag tasks with "priorities" but leaving that for the next post when I'll be more coherent.
Marcadores:
folknology,
GAE,
mind traffic control,
mtc,
opml,
twitter
Tuesday, May 06, 2008
Softlaunch ... no fanfare ...
This is my first Google Application Engine application. A kind of next-action list for the Twitter generation.
Basic instructions :
1) You need a Google account to login (eg. Gmail) ... it's a GAE app.
2) There's a blue box for inputting tasks you need to do. Once you start entering them, Mind Traffic Control will show you your next action.
3) At which point you have a choice. Say you did it. Delay it (push it to the back of the queue). Delegate it to another user. Defer it to a future date. Or delete it altogether.
4) Keep going.
There are a couple of ideas behind this. First, that people have been getting too hooked up on the idea of "organizing" their tasks and actions into lists. But organization itself isn't really an end, it's a means towards making sure you remember and discover your tasks, as a means towards the ultimate end of getting stuff done. So instead of thinking of tasks as list-management, Mind Traffic Control treats tasks as un-structured flows.
The real focus is on capturing the tasks as quickly and easily as possible. So, inspired by Twitter and Folknology's Rel3, the input box is always there at the top of your page.
The other focus is when the task is presented to you. At this point you need all your options to quickly route the task. In a more static system we might say route into particular "bins" but here it might be better to say "channels" (unless it's the ultimate sink of "done" or "deleted".
Another idea ... it's meant to be the simplest workflow that could possibly work. Just short messages which can be routed. Everything else has to be constructed by humans on top of this. But as, once again, we've seen with twitter, it looks like humans are pretty good at filling out these communication channels.
Anyway, off to bed ... will write more posts here soon ...
please have a try with Mind Traffic Control, and if you have any comments, feel free to post them here.
Mind Traffic Control
This is my first Google Application Engine application. A kind of next-action list for the Twitter generation.
Basic instructions :
1) You need a Google account to login (eg. Gmail) ... it's a GAE app.
2) There's a blue box for inputting tasks you need to do. Once you start entering them, Mind Traffic Control will show you your next action.
3) At which point you have a choice. Say you did it. Delay it (push it to the back of the queue). Delegate it to another user. Defer it to a future date. Or delete it altogether.
4) Keep going.
There are a couple of ideas behind this. First, that people have been getting too hooked up on the idea of "organizing" their tasks and actions into lists. But organization itself isn't really an end, it's a means towards making sure you remember and discover your tasks, as a means towards the ultimate end of getting stuff done. So instead of thinking of tasks as list-management, Mind Traffic Control treats tasks as un-structured flows.
The real focus is on capturing the tasks as quickly and easily as possible. So, inspired by Twitter and Folknology's Rel3, the input box is always there at the top of your page.
The other focus is when the task is presented to you. At this point you need all your options to quickly route the task. In a more static system we might say route into particular "bins" but here it might be better to say "channels" (unless it's the ultimate sink of "done" or "deleted".
Another idea ... it's meant to be the simplest workflow that could possibly work. Just short messages which can be routed. Everything else has to be constructed by humans on top of this. But as, once again, we've seen with twitter, it looks like humans are pretty good at filling out these communication channels.
Anyway, off to bed ... will write more posts here soon ...
please have a try with Mind Traffic Control, and if you have any comments, feel free to post them here.
Marcadores:
GAE,
getting things done,
mind traffic control,
mtc,
python,
rel3
Saturday, May 03, 2008
I've now been playing with GAE for a couple of weeks, and it's still looking pretty good. I've now got an Orkut developer account so I can make Orkut widgets tethered to a GAE based service.
Meanwhile looks like GvR has been doing some cool stuff within Google with internal development tools, and has just released it to the outside world, thanks to GAE giving us access to BigTable etc.
Meanwhile looks like GvR has been doing some cool stuff within Google with internal development tools, and has just released it to the outside world, thanks to GAE giving us access to BigTable etc.
Marcadores:
GAE,
google,
guido van rossum,
mondrian,
python
Sunday, April 13, 2008
The change in mindset needed for GAE
Saturday, April 12, 2008
Thursday, April 10, 2008
Now this is very cute :
See that? A GQL (query language for GAE) query object automatically supports iteration, so you can use it in a list comprehension.
[(f.title,f.key())
for f in db.GqlQuery("select * from Film order by title")]
See that? A GQL (query language for GAE) query object automatically supports iteration, so you can use it in a list comprehension.
Monday, April 07, 2008
OK ... better start finding out about Google App. Engine
Damn! Don't think I was in the first 10,000 applicants for a beta ... got the downloadable development environment though ... watch this space ...
Update : Actually, I did get one ... :-)
Damn! Don't think I was in the first 10,000 applicants for a beta ... got the downloadable development environment though ... watch this space ...
Update : Actually, I did get one ... :-)
Thursday, March 27, 2008
Wednesday, March 26, 2008
Sometimes you need to take a step back from a problem, to see the forest for the trees.
GeekWeaver was being held up by something that seemed a rather complicated knot; one that I've wrestled with a number of times but never really untangled to my satisfaction.
So last night I decided to restart with a clean slate. I didn't look at the existing code or existing unit-tests. Didn't even open my IDE or project file.
I just started up IDLE and in a single file, redid the whole thing from scratch, in a fast test-driven stylee.
Amazingly I think I've come out with a cleaner solution, messing around with fewer classes and no attempt to over-re-use with inheritance. The whole thing took about two hours total. Of course, it's not quite finished, and still needs to be integrated back into the main codebase. But I like it a lot more. It's shorter and easier to understand.
Sometimes (at a certain granularity) old code *is* more of a burden than an asset. Understanding what it does and what you can do it is a cognitive cost that outweighs its value. Don't be afraid to throw code away when you need to.
Caveat for small granularities. Obviously rewriting an entire application from scratch is a different matter.
GeekWeaver was being held up by something that seemed a rather complicated knot; one that I've wrestled with a number of times but never really untangled to my satisfaction.
So last night I decided to restart with a clean slate. I didn't look at the existing code or existing unit-tests. Didn't even open my IDE or project file.
I just started up IDLE and in a single file, redid the whole thing from scratch, in a fast test-driven stylee.
Amazingly I think I've come out with a cleaner solution, messing around with fewer classes and no attempt to over-re-use with inheritance. The whole thing took about two hours total. Of course, it's not quite finished, and still needs to be integrated back into the main codebase. But I like it a lot more. It's shorter and easier to understand.
Sometimes (at a certain granularity) old code *is* more of a burden than an asset. Understanding what it does and what you can do it is a cognitive cost that outweighs its value. Don't be afraid to throw code away when you need to.
Caveat for small granularities. Obviously rewriting an entire application from scratch is a different matter.
Thursday, March 20, 2008
Sweet Expressions ... great idea for making S-Expressions more like other, more readable programming languages
Hat-tip Folknology
without losing their power (such as generality, macros, quasiquoting, homoiconicity, and easily-manipulated program fragments).
Hat-tip Folknology
Wednesday, March 19, 2008
Marcadores:
buildout,
eggs,
installers,
modules,
python
Sunday, March 16, 2008
Very interesting. Recently my "ProgrammingInWiki" page on WardsWiki seems to have come back to life. Along with a companion WikiIDE.
A WikiDE is, of course, something I've been working on in the background for some time. But I'm far from having anything to show yet. So if these guys get there first, good luck to them.
I just want to be able to start working this way.
A WikiDE is, of course, something I've been working on in the background for some time. But I'm far from having anything to show yet. So if these guys get there first, good luck to them.
I just want to be able to start working this way.
Wednesday, March 12, 2008
Sunday, March 09, 2008
I've been wondering what Ward Cunningham's been up to at Eclipse. Jon Udell is on the case : Interesting tools for software developers.
Apparently's Ward's now at a wiki-startup. (Mark Dilley seems to be involved too.)
Apparently's Ward's now at a wiki-startup. (Mark Dilley seems to be involved too.)
Marcadores:
microisv,
starters,
startup,
ward cunningham,
wiki
Saturday, March 08, 2008
Cobra seems to be like Python with optional compile-time type-checking and other quirks removed.
It also has contracts, which ensure certain conditions when calling a function. However, wearing my new Erlangish hat, I wonder what contracts buy you over pattern-matching arguments?
Unit testing built in to functions is interesting. Not sure what I think of that .... yes, it's useful and convenient. But a) it may clutter up clean code (I tend to let a certain amount of messiness leak into my unit-tests, that I don't let into my code); b) it's not so easy to see how it can be used for test-driven development - how can I write my test before my class? And, worst of all, c) I tend to use unit-tests when refactoring and moving functionality from one class to another.
It's very simple to change a :
into
and have my unit-tests already defining the new target I'm aiming for.
But if the test is is actually *part* of MyClass, then that's going to require more premeditated moving stuff around during my experimental refactoring.
It also has contracts, which ensure certain conditions when calling a function. However, wearing my new Erlangish hat, I wonder what contracts buy you over pattern-matching arguments?
Unit testing built in to functions is interesting. Not sure what I think of that .... yes, it's useful and convenient. But a) it may clutter up clean code (I tend to let a certain amount of messiness leak into my unit-tests, that I don't let into my code); b) it's not so easy to see how it can be used for test-driven development - how can I write my test before my class? And, worst of all, c) I tend to use unit-tests when refactoring and moving functionality from one class to another.
It's very simple to change a :
x = MyClass()
self.assertEquals(x.f(4),10)
into
x = MyClass2()
self.assertEquals(x.f(4),10)
and have my unit-tests already defining the new target I'm aiming for.
But if the test is is actually *part* of MyClass, then that's going to require more premeditated moving stuff around during my experimental refactoring.
Thursday, March 06, 2008
I'm way too busy now ... but I'm having some kicking ideas about my own grandiose bid to improve programming ...
... think GeekWeaver in an SdiDesk-alike editor (obviously).
Then imagine that *everything* is a template.
That's the way that GeekWeaver is already going. Everything is a template (ie. has named slots that can be filled). Function calls are just the injection of a data-block into that template. Another way of putting it, all objects know how to handle the "call" message with a data-block as argument, even if they don't do anything very useful with it.
But now imagine that all the types of things you can get in SdiDesk ... text pages, grids, network diagrams, are also templates. And you can plug and pipe them together any way you like. One page can hold a table, another a network diagram-shaped template, and a third can be specified as the result of injecting the first into the second.
Hmmm ... this definitely looks like it's going in the right direction.
... think GeekWeaver in an SdiDesk-alike editor (obviously).
Then imagine that *everything* is a template.
That's the way that GeekWeaver is already going. Everything is a template (ie. has named slots that can be filled). Function calls are just the injection of a data-block into that template. Another way of putting it, all objects know how to handle the "call" message with a data-block as argument, even if they don't do anything very useful with it.
But now imagine that all the types of things you can get in SdiDesk ... text pages, grids, network diagrams, are also templates. And you can plug and pipe them together any way you like. One page can hold a table, another a network diagram-shaped template, and a third can be specified as the result of injecting the first into the second.
Hmmm ... this definitely looks like it's going in the right direction.
Marcadores:
developing in wiki,
geekweaver,
programming,
sdidesk
Monday, March 03, 2008
Saturday, March 01, 2008
Here's a question ... why is Erlang so ugly?
I don't mean that in a pejorative way (not much, anyway). I mean, I really love what it does. I'm totally impressed with Erlang's power and simplicity. I'm writing simulations which are about a quarter of the size of the Python equivalent. So this is not to be taken as a criticism of Erlang which I'm definitely committing myself to, this year. Rather this is some random speculation about programming language aesthetics.
Erlang is wonderfully concise. And yet, somehow, unlike Python, unlike Haskell, it just doesn't come across as beautiful. It's confusing. It looks cluttered.
A couple of lines look fabulous. But the simplicity doesn't scale.
At first guess, there seem to be three issues.
a) As people have noted, the record type is ugly. It is. And counter-intuitive to use in patterns (although I may just be stupid).
b) In general I think it's good and brave thing to take a stance *against* objects. But I haven't figured out how to do encapsulation (data-hiding, abstract types)
Sure, I can define polymorphic functions (one clause at a time per input type) which is a lot shorter and more powerful than overloaded methods in Java. But it has the effect of jumbling all my data-types together. Which just feels *wrong* to me. (Of course, maybe that's some residual OOness in my thinking.)
But I think that may be part of the bigger issue :
c) erlang doesn't seem to have resources for "programming in the large". And, ironically, because erlang is so powerful, that problem becomes visible at a smaller scale - precisely because in erlang "large" programs are actually "small".
Or rather, the only resource is "modules" (which means breaking up into multiple files - always an extra overhead.)
But if you avoid breaking things up into files, the opposite problem becomes apparent. I can do the equivalent of a small Java class (let's say something around 50-80 lines) in about 6 to 10 lines of Erlang. But 10 lines of erlang is too small for a separate file. So I'll add the next 10 line packet of functionality to the same file. By the time I'm up to 4 or 5 packets that would be handled as different classes in Java or Python I may have written only about 50 lines of code ... but it's all running together!
There's no higher level of organization to distinguish and separate the code. In Python I often put 5 or 6 small-medium classes in a single file or around 300-500 lines. But the indentation and editor make these reasonably distinct and identifiable. In contrast, my equivalent 200 lines of Erlang have no visual cues to break them up. I can't use functions as a visual element because pretty much every line is a new function (except when I'm doing I/O, which has its own "issues").
I'm left with using comments but my editor (Komodo), excellent in many ways, doesn't actually know Erlang and so doesn't colour them differently. And, in general, because functions are powerful, they *are* short : one or two lines. But those lines are typically much denser than Python. Even if a dedicated editor would colourize them, I'm not convinced that's such a big win at this density. On the other hand, I don't want to artificially scatter them out into multiple lines. I'm not trying to recreate Python with a slightly less appropriate syntax. I want to take advantage of Erlang's power and conciseness.
But I wonder what the right aesthetics for a language as high level, dense and abstract as Erlang is. Haskell looks cleaner to me - maybe because it does abstract data-types right. But can it solve the problem of organizing your larger-scale things? Lisp is no role-model. ML and its offspring have always repelled me visually. (Nothing can be more ugly, dispiriting and patronizing in a programming language than an explicit "begin" statement.)
Suggestions, anyone?
I don't mean that in a pejorative way (not much, anyway). I mean, I really love what it does. I'm totally impressed with Erlang's power and simplicity. I'm writing simulations which are about a quarter of the size of the Python equivalent. So this is not to be taken as a criticism of Erlang which I'm definitely committing myself to, this year. Rather this is some random speculation about programming language aesthetics.
Erlang is wonderfully concise. And yet, somehow, unlike Python, unlike Haskell, it just doesn't come across as beautiful. It's confusing. It looks cluttered.
A couple of lines look fabulous. But the simplicity doesn't scale.
At first guess, there seem to be three issues.
a) As people have noted, the record type is ugly. It is. And counter-intuitive to use in patterns (although I may just be stupid).
b) In general I think it's good and brave thing to take a stance *against* objects. But I haven't figured out how to do encapsulation (data-hiding, abstract types)
Sure, I can define polymorphic functions (one clause at a time per input type) which is a lot shorter and more powerful than overloaded methods in Java. But it has the effect of jumbling all my data-types together. Which just feels *wrong* to me. (Of course, maybe that's some residual OOness in my thinking.)
But I think that may be part of the bigger issue :
c) erlang doesn't seem to have resources for "programming in the large". And, ironically, because erlang is so powerful, that problem becomes visible at a smaller scale - precisely because in erlang "large" programs are actually "small".
Or rather, the only resource is "modules" (which means breaking up into multiple files - always an extra overhead.)
But if you avoid breaking things up into files, the opposite problem becomes apparent. I can do the equivalent of a small Java class (let's say something around 50-80 lines) in about 6 to 10 lines of Erlang. But 10 lines of erlang is too small for a separate file. So I'll add the next 10 line packet of functionality to the same file. By the time I'm up to 4 or 5 packets that would be handled as different classes in Java or Python I may have written only about 50 lines of code ... but it's all running together!
There's no higher level of organization to distinguish and separate the code. In Python I often put 5 or 6 small-medium classes in a single file or around 300-500 lines. But the indentation and editor make these reasonably distinct and identifiable. In contrast, my equivalent 200 lines of Erlang have no visual cues to break them up. I can't use functions as a visual element because pretty much every line is a new function (except when I'm doing I/O, which has its own "issues").
I'm left with using comments but my editor (Komodo), excellent in many ways, doesn't actually know Erlang and so doesn't colour them differently. And, in general, because functions are powerful, they *are* short : one or two lines. But those lines are typically much denser than Python. Even if a dedicated editor would colourize them, I'm not convinced that's such a big win at this density. On the other hand, I don't want to artificially scatter them out into multiple lines. I'm not trying to recreate Python with a slightly less appropriate syntax. I want to take advantage of Erlang's power and conciseness.
But I wonder what the right aesthetics for a language as high level, dense and abstract as Erlang is. Haskell looks cleaner to me - maybe because it does abstract data-types right. But can it solve the problem of organizing your larger-scale things? Lisp is no role-model. ML and its offspring have always repelled me visually. (Nothing can be more ugly, dispiriting and patronizing in a programming language than an explicit "begin" statement.)
Suggestions, anyone?
Marcadores:
aesthetics,
design,
erlang,
functional programming,
language design
Wednesday, February 27, 2008
And I thought I was ambitious, trying to write a programming language!
My friend Oli has decided to reinvent programming as we know it. Details are still trickling out via his web-site : Semantic Programming. And I'm in frenzied skype conversation with him, trying to figure out what it's all about.
In outline, it starts from some intuitions behind the Semantic Web : that there should be a massively parallel, distributed graph-shaped database of facts (relational assertions) represented on different machines across the world. But it then layers programming on top of that. Instead of a passive data-structure crawled by scutters, SemProg agents (roughly, the servers which manage different data-nodes) are active. There is message passing between the facts themselves, and agents may have hardwired interpretation to act on some facts (what Oli is calling "axiomatic" understanding), or a "deductive" understanding (I guess rather like Prolog inference), and even a "behavioural" understanding via (I guess again) learning from observing other agents.
I'll keep following this here on Smart Disorganized. Very interesting if it works out.
Would GeekWeaver support Semantic Programming? It seems like Oli is thinking of multiple editors for different types of information, all of which compile down to the same underlying graph-structured format so that the data can be combined. (Rather like Language Oriented Programming.) It seems quite possible that GeekWeaver could output something like his graph-format. I'll certainly be experimenting.
I'm also trying to persuade Oli to look at Erlang as a potential implementation language for the distributed virtual machine. I'm increasingly impressed by Erlang. Finding it very powerful and concise.
My friend Oli has decided to reinvent programming as we know it. Details are still trickling out via his web-site : Semantic Programming. And I'm in frenzied skype conversation with him, trying to figure out what it's all about.
In outline, it starts from some intuitions behind the Semantic Web : that there should be a massively parallel, distributed graph-shaped database of facts (relational assertions) represented on different machines across the world. But it then layers programming on top of that. Instead of a passive data-structure crawled by scutters, SemProg agents (roughly, the servers which manage different data-nodes) are active. There is message passing between the facts themselves, and agents may have hardwired interpretation to act on some facts (what Oli is calling "axiomatic" understanding), or a "deductive" understanding (I guess rather like Prolog inference), and even a "behavioural" understanding via (I guess again) learning from observing other agents.
I'll keep following this here on Smart Disorganized. Very interesting if it works out.
Would GeekWeaver support Semantic Programming? It seems like Oli is thinking of multiple editors for different types of information, all of which compile down to the same underlying graph-structured format so that the data can be combined. (Rather like Language Oriented Programming.) It seems quite possible that GeekWeaver could output something like his graph-format. I'll certainly be experimenting.
I'm also trying to persuade Oli to look at Erlang as a potential implementation language for the distributed virtual machine. I'm increasingly impressed by Erlang. Finding it very powerful and concise.
Thursday, February 21, 2008
Paul Graham's Arc Challenge . Examples in Lisp, Smalltalk Seaside, Ruby, Perl and Python (using generators instead of continuations)
And an Erlang response.
And an Erlang response.
Monday, January 28, 2008
@adrianh suggests looking more at Parrot Compiler Toolkit ... which is very cool.
I'm finding that language design is hard. Not just the implementation part (although that's hard too) ... but just figuring out how to make a syntax that allows all the things you'd expect to be done in an elegant way.
I'm starting to appreciate how clever certain common design patterns are in language design, and how hard it is to deviate from them. More on this soon ...
I'm finding that language design is hard. Not just the implementation part (although that's hard too) ... but just figuring out how to make a syntax that allows all the things you'd expect to be done in an elegant way.
I'm starting to appreciate how clever certain common design patterns are in language design, and how hard it is to deviate from them. More on this soon ...
Marcadores:
geekweaver,
language design,
parrot,
programming
Thursday, January 17, 2008
I'm playing with pipelining in Python over on Composing.
Wednesday, January 16, 2008
Here's an interesting question (after reading this).
Why does anyone want to write "large" programs? Everyone knows large programs are difficult to build and maintain. Want we want is *small* programs that happen to be powerful (do a lot) and scale over large numbers of users. Is there any reason to think that "large" program correlates with either of these things?
Supplimentary question. Are 10 programs of 1000 lines each, which have to nevertheless interact (via pipes or XML-RPC calls etc.) actually any easier than one 10000 line program?
Update : Folknology has been making a pretty decent case for Erlang as a language optimized for writing software as a swarm of small programs.
Why does anyone want to write "large" programs? Everyone knows large programs are difficult to build and maintain. Want we want is *small* programs that happen to be powerful (do a lot) and scale over large numbers of users. Is there any reason to think that "large" program correlates with either of these things?
Supplimentary question. Are 10 programs of 1000 lines each, which have to nevertheless interact (via pipes or XML-RPC calls etc.) actually any easier than one 10000 line program?
Update : Folknology has been making a pretty decent case for Erlang as a language optimized for writing software as a swarm of small programs.
Sunday, January 13, 2008
Discipulus, patterns for programmers.
Tuesday, January 08, 2008
LOLCODE IZ IN UR COMPUTR RUNNG THINGZ
Monday, January 07, 2008
Sunday, December 23, 2007
Wednesday, December 19, 2007
Looking at some slides about Perl 6(pdf) ... some cute features.
Sunday, December 16, 2007
Monday, December 10, 2007
The impotance of being earnest :-)
Update : which reminds me of a discussion I'm having with Sig
Update 2 : Seems like a lot of ongoing discussion around the place. Joel Spolsky explains.
Update : which reminds me of a discussion I'm having with Sig
Update 2 : Seems like a lot of ongoing discussion around the place. Joel Spolsky explains.
Thursday, December 06, 2007
Update : for people wondering how the whole new-SdiDesk-in-Adobe-Flex? thing is going. I solved something I thought was a problem yesterday.
I now have a (very fragile) Flex front end which can pass plain-text GeekWeaver programs to a web-server with GeekWeaver embedded, and get a compiled chunk of GeekWeaver out.
That's very cool ... unfortunately it also revealed yet more problems with the GeekWeaver compiler which need fixing before I can release the next version.
Still, it looks promising. The signs are better and better that something interesting is coming out in the next 3 months. :-)
I now have a (very fragile) Flex front end which can pass plain-text GeekWeaver programs to a web-server with GeekWeaver embedded, and get a compiled chunk of GeekWeaver out.
That's very cool ... unfortunately it also revealed yet more problems with the GeekWeaver compiler which need fixing before I can release the next version.
Still, it looks promising. The signs are better and better that something interesting is coming out in the next 3 months. :-)
Monday, December 03, 2007
Restless Mind Syndrome (propaganda for the ultra-cool looking LiveScribe)
Wednesday, November 28, 2007
He he! Perhaps NooRanch is NooVictorian ....
(I know, bad, bad pun)
(I know, bad, bad pun)
What's this?
An HTML list that came out of GeekWeaver, when I called this recursive function :
on a chunk of OPML.
That's pretty much how it's going to look, folks.
::rec defines the recursive block (or function)
.<ul> creates the UL tag
:for x,, #__
is creating a loop through all the anonymous (unlabelled) children of the tree which is being passed to the call. (This list is represented by the symbol __)
Note that I'm trying to keep GeekWeaver as functional as possible so there's no real "assignment". x is scoped so that it only exists inside the block of the for-loop, it's bound once before the block is evaluated, but can't be updated after that.
${x/=}
This is the new way of accessing variables. x is actually bound to a sub-tree (Almost everything in GeekWeaver is a sub-tree, except a couple of weird cases like __ which is a list.)
Although a simple $x still works if you want the whole of a tree flattened into a string, ${} expressions give you a way to pull data from a single path in the tree. In this case we're just getting the text content of the root node of x.
But it's also possible to write stuff like this : ${company/employees/__3/name} which means from the symbol "company" get the labelled child "employees" from which get the non-labelled 3rd child, from which get the child labelled "name".
:hasChild, like :for, is a build-in function. If the tree in x has any children, it evaluates the body of the :hasChild tree. If not, it returns nothing. This tests for our "base-case" when we've hit a leaf of the tree we're recursing through.
The final line :
:rec ++ #x__
is the one which I've been struggling with for the last three months, ever since I started trying to figure out how to support recursion. I'm still not 100% happy with the solution I've come up with, but it's getting there.
:rec is calling the recursive block again. And obviously I need to pass the children of x as arguments. However the way the function is written, it is working on the anonymous children (inside the default variable __)
How am I going to get the children of x into the __ variable inside the next call of :rec? That's what ++ does. Not sure what I'm going to call this, I may call it a "pivot" although that may confuse as much as help. It captures something of the idea that I need to swing the anonymous children of x (#x__) around so that they can go into the next call of :rec as though they were children of the calling node
Like I say, don't know if I like this name or the ++ symbol being used for it. So consider both as provisional for now.
OK, I'm too tired to make the build with this stuff working tonight. I'll try to get a build together in the next couple of days, but meanwhile, if this looks interesting to you and you can't contain yourself, send me an email (interstarATgmail.com), say hello and I'll see what I can do.
- 1
- 2
- 21
- 211
- 22
- 21
- 3
- 4
- 41
- 42
- 43
- 431
- 4311
- 431
- 5
An HTML list that came out of GeekWeaver, when I called this recursive function :
::rec
.<ul>
:for x,, #__
.<li>
${x/=}
:hasChild x
:rec ++ #x__
on a chunk of OPML.
That's pretty much how it's going to look, folks.
::rec defines the recursive block (or function)
.<ul> creates the UL tag
:for x,, #__
is creating a loop through all the anonymous (unlabelled) children of the tree which is being passed to the call. (This list is represented by the symbol __)
Note that I'm trying to keep GeekWeaver as functional as possible so there's no real "assignment". x is scoped so that it only exists inside the block of the for-loop, it's bound once before the block is evaluated, but can't be updated after that.
${x/=}
This is the new way of accessing variables. x is actually bound to a sub-tree (Almost everything in GeekWeaver is a sub-tree, except a couple of weird cases like __ which is a list.)
Although a simple $x still works if you want the whole of a tree flattened into a string, ${} expressions give you a way to pull data from a single path in the tree. In this case we're just getting the text content of the root node of x.
But it's also possible to write stuff like this : ${company/employees/__3/name} which means from the symbol "company" get the labelled child "employees" from which get the non-labelled 3rd child, from which get the child labelled "name".
:hasChild, like :for, is a build-in function. If the tree in x has any children, it evaluates the body of the :hasChild tree. If not, it returns nothing. This tests for our "base-case" when we've hit a leaf of the tree we're recursing through.
The final line :
:rec ++ #x__
is the one which I've been struggling with for the last three months, ever since I started trying to figure out how to support recursion. I'm still not 100% happy with the solution I've come up with, but it's getting there.
:rec is calling the recursive block again. And obviously I need to pass the children of x as arguments. However the way the function is written, it is working on the anonymous children (inside the default variable __)
How am I going to get the children of x into the __ variable inside the next call of :rec? That's what ++ does. Not sure what I'm going to call this, I may call it a "pivot" although that may confuse as much as help. It captures something of the idea that I need to swing the anonymous children of x (#x__) around so that they can go into the next call of :rec as though they were children of the calling node
Like I say, don't know if I like this name or the ++ symbol being used for it. So consider both as provisional for now.
OK, I'm too tired to make the build with this stuff working tonight. I'll try to get a build together in the next couple of days, but meanwhile, if this looks interesting to you and you can't contain yourself, send me an email (interstarATgmail.com), say hello and I'll see what I can do.
Sunday, November 11, 2007
Hey! I like NeoVictorianism.
There's a movement I can sign-up for :
There's a movement I can sign-up for :
Built for people
Built by people
Crafted in workshops
Embracing irregularity
Inspired
Thursday, November 08, 2007
Just spent the last few hours downloading and playing with the beta of Flex 3, Adobe's IDE for Rich Internet Applications (ie. applications running on the Flash Virtual Machine) which is based on Eclipse and has an XML-based UI / form description language more or less like HTML.
I'm having two thoughts about it. One is a kind of sigh of relief. This is, after all, finally, The One. After years of fruitless searching I'm pretty sure here's a framework I can settle down with and commit to, and start making babies with. At least, it's more or less mature enough, handsome enough and well endowed enough to put these thoughts into a girl's head. A browser and a desktop? Holidays in Windows, Mac and Linux? Own grid and canvas. Tabbed notebook and some cute chunky buttons.
And it's all done in a way that's pretty self-evident when you look at a few examples. Forms and input widgets are described in XML. They layout nice; and you can start banging them in and prototyping the look of your interface in a couple of minutes. The round-trip from coding to running and testing is a bit slow on my poor 512MB Vista laptop, but it's going to be bearable. And the Eclipsyness of it all is comfortingly familiar if a trifle overblown.
As long as my next experiments turn out right (the one where I try to find a tutorial example of pulling data off a server over http, and the one where I try to compile with AIR into a stand-alone application) then I'm sold.
But there's another part of me going, "huh? Is this all there is? WTF?"
I mean, it's 2007 and I'm happy because I've finally found a way to make GUIs that's sufficiently lower than my pain threshold that I might actually get a piece of software released again. Zowie! But that's what I had with Visual Basic 6 - which came out in about 1997!
In fact, I was already a Pythonista before I started writing SdiDesk in VB. And I only pulled out VB (a language I thought I'd left behind for good) because I got impatient to see what the UI of an SdiDesk could look like and thought I'd prototype it. As often happens, the prototype spiraled out of control as I kept thinking, "maybe I can just also add ... " and within a month or so it had already started to grow into a real program. Another phase of development with some serious refactoring and cleaning up the internal architecture, and it was a quite respectable and powerful bit of software (If I say so myself; I'm talking about the time I made the tutorial screen-casts.)
(Then, of course, I hit the crisis of not wanting to be on the Microsoft treadmill and forced to upgrade to .NET; even though it was obvious that VB6 was as extinct as a very extinct thing from the Lower Devonian period. But also of not having any viable alternative. )
So there's a sense that Flex smells extraordinarily similar. I can see how you can knock out your prototype interface and start building backwards from it. That feels good. That's why it seems like this is plausible option to get development rolling again.
But, like I say, it *is* basically what I had 10 years ago. Except with javascript dressed up in Java's suit and tie to look more grown-up and respectable. And XML.
In fact, I was gchatting to Zbigniew earlier today, and realizd that all of this stuff is hardly a big advance on Hypercard back in 1985. Or perhaps Smalltalk 1972. Why the hell haven't we progressed further? Why am I struggling on each new platform to rediscover the level of comfort I had on the previous one? What's going wrong here?
I suppose it could just be that the idea of quick GUI builders is inherent in the idea of a GUI?
Or maybe we programmers of the noughties need to get our acts together and start coming up with serious new, cool shit. Stuff which couldn't have been thought up in the 60s and 70s. Stuff which is radically easier and more productive than something we had 10 years ago. Something likereinventing Lisp with a cleaner (non)syntax ... erm ... well anyway, I'm off to do more experiments with Flex and try to get it to talk to some kind of server.
If I succeed, then expect to see some interesting developments along the lines I mentioned earlier today ... steps towards a new SdiDesk, possibly a GeekWeaver development environment ... maybe even the long fabled, but never released SystemSketch. Or even the more outré things I've got buzzing around in my fevered imagination like "SexyCells" and "FlowerBrush".
Of course, it still sucks that Flex / Flash seems to have no musical ability whatsoever so Gbloink! doesn't look like an option. Which is a double pity because I think it would make a great Chumby widget and that would have justified me buying one.
:-(
I'm having two thoughts about it. One is a kind of sigh of relief. This is, after all, finally, The One. After years of fruitless searching I'm pretty sure here's a framework I can settle down with and commit to, and start making babies with. At least, it's more or less mature enough, handsome enough and well endowed enough to put these thoughts into a girl's head. A browser and a desktop? Holidays in Windows, Mac and Linux? Own grid and canvas. Tabbed notebook and some cute chunky buttons.
And it's all done in a way that's pretty self-evident when you look at a few examples. Forms and input widgets are described in XML. They layout nice; and you can start banging them in and prototyping the look of your interface in a couple of minutes. The round-trip from coding to running and testing is a bit slow on my poor 512MB Vista laptop, but it's going to be bearable. And the Eclipsyness of it all is comfortingly familiar if a trifle overblown.
As long as my next experiments turn out right (the one where I try to find a tutorial example of pulling data off a server over http, and the one where I try to compile with AIR into a stand-alone application) then I'm sold.
But there's another part of me going, "huh? Is this all there is? WTF?"
I mean, it's 2007 and I'm happy because I've finally found a way to make GUIs that's sufficiently lower than my pain threshold that I might actually get a piece of software released again. Zowie! But that's what I had with Visual Basic 6 - which came out in about 1997!
In fact, I was already a Pythonista before I started writing SdiDesk in VB. And I only pulled out VB (a language I thought I'd left behind for good) because I got impatient to see what the UI of an SdiDesk could look like and thought I'd prototype it. As often happens, the prototype spiraled out of control as I kept thinking, "maybe I can just also add ... " and within a month or so it had already started to grow into a real program. Another phase of development with some serious refactoring and cleaning up the internal architecture, and it was a quite respectable and powerful bit of software (If I say so myself; I'm talking about the time I made the tutorial screen-casts.)
(Then, of course, I hit the crisis of not wanting to be on the Microsoft treadmill and forced to upgrade to .NET; even though it was obvious that VB6 was as extinct as a very extinct thing from the Lower Devonian period. But also of not having any viable alternative. )
So there's a sense that Flex smells extraordinarily similar. I can see how you can knock out your prototype interface and start building backwards from it. That feels good. That's why it seems like this is plausible option to get development rolling again.
But, like I say, it *is* basically what I had 10 years ago. Except with javascript dressed up in Java's suit and tie to look more grown-up and respectable. And XML.
In fact, I was gchatting to Zbigniew earlier today, and realizd that all of this stuff is hardly a big advance on Hypercard back in 1985. Or perhaps Smalltalk 1972. Why the hell haven't we progressed further? Why am I struggling on each new platform to rediscover the level of comfort I had on the previous one? What's going wrong here?
I suppose it could just be that the idea of quick GUI builders is inherent in the idea of a GUI?
Or maybe we programmers of the noughties need to get our acts together and start coming up with serious new, cool shit. Stuff which couldn't have been thought up in the 60s and 70s. Stuff which is radically easier and more productive than something we had 10 years ago. Something like
If I succeed, then expect to see some interesting developments along the lines I mentioned earlier today ... steps towards a new SdiDesk, possibly a GeekWeaver development environment ... maybe even the long fabled, but never released SystemSketch. Or even the more outré things I've got buzzing around in my fevered imagination like "SexyCells" and "FlowerBrush".
Of course, it still sucks that Flex / Flash seems to have no musical ability whatsoever so Gbloink! doesn't look like an option. Which is a double pity because I think it would make a great Chumby widget and that would have justified me buying one.
:-(
37 Signals on why enterprise software sucks
Quick Note : I just had a revolution in my thinking, triggered by Enso but influenced by several other recent trends.
You write Enso "extensions" as XML-RPC servers sitting on your local machine, register them with Enso and it calls them using XML-RPC. I tried the example from the tutorial and it's very cute and simple. So I've decided this may be a way forward for the dilemma which has kept the "new SdiDesk" on hold for several years(!!!)
If you remember, the issue has been whether the new SdiDesk should be a "web"-application (accessed through the browser) or a desktop application? And how to implement the UI.
The problem with the "browser" answer has always been : "but how to do the network diagramming bit?" - which requires interactive vector graphics. SVG doesn't seem quite stable or cross-browser enough. Canvas isn't cross-browser. Flash is proprietory.
The problem with the "desktop application" is, well, the many rival Python GUI libs with different degrees of maturity. And the question of getting them to work cross-platform.
A meta-problem : I just don't have time and energy to go through learning lots of different GUI frameworks to decide which I want to use. And the ideal answer to the browser / desktop question is probably "both" which doubles the amount of work.
In fact, one of the motivations for GeekWeaver is to see if I can use it define a higher-level UI description that can be compiled down into both XHTML and a GUI widget-set.
Of course, with XUL, Open Laszlo, Adobe Flex, XUML etc. lots of people have been looking at something like HTML for defining desktop apps. too, but the free Python frameworks don't seem to have caught up with that yet. XUL sounds most promising especially with the open sourcing of Active State's Komodo ... but that's also a big complicated thing to even start looking into.
Anyway, inspired by the Enso extensions and Bruce Eckel's interesting example of hooking up a Python XML-RPC server behind an Adobe Flex application I've been wondering about blowing the project apart entirely into a number of services connectd only XML-RPC or something more ReSTful.)
So there'll be a WADS (SdiDesk PageStore) service, a GeekWeaver interpreter service, a "user navigation history service" etc. Even the glue which ties all this together will be another service that's neutral about the user-interface. Effectively the model, view and controller will be completely separate programs. (I know, I know ;-) )
Then there'll be a variety of different types of access with different UIs.
Now that Adobe's AIR has put Flash on the desktop and made it a serious rival to the Java virtual machine - I *am* tempted to put some time into learning it. It would give me a reasonable GUI widget set (including TreeGrid, yay!) and the vector graphics needed for networks. It will run both on the desktop and in the browser and on Linux, PC and Mac. The tools are free-as-in-beer (Flex beta) or free-as-in-speech (Open Laszlo). It's also possible to imagine generating the Flex XML or the Open Laszlo format directly from GeekWeaver. (Aside : I wish ActionScript hadn't borrowed quite so much from Java, but still, I'd only be using it for the front-of-the-front-end UI stuff.)
Then I want to experiment with Enso access - for example, Enso commands like "page HelloWorld" or "pagehistory ChocolateCake"
And there'll be web-browser access probably through a "gateway" that accepts http requests and spits out HTML for a browser. The only thing I don't know is whether I *really* should be using WSGI somewhere here.
Anyway ... that's a quick update of my thinking this week ... tune in soon for the next GeekWeaver release (really, it's coming together, and gonna be very powerful). Then it's back to work on this larger project.
You write Enso "extensions" as XML-RPC servers sitting on your local machine, register them with Enso and it calls them using XML-RPC. I tried the example from the tutorial and it's very cute and simple. So I've decided this may be a way forward for the dilemma which has kept the "new SdiDesk" on hold for several years(!!!)
If you remember, the issue has been whether the new SdiDesk should be a "web"-application (accessed through the browser) or a desktop application? And how to implement the UI.
The problem with the "browser" answer has always been : "but how to do the network diagramming bit?" - which requires interactive vector graphics. SVG doesn't seem quite stable or cross-browser enough. Canvas isn't cross-browser. Flash is proprietory.
The problem with the "desktop application" is, well, the many rival Python GUI libs with different degrees of maturity. And the question of getting them to work cross-platform.
A meta-problem : I just don't have time and energy to go through learning lots of different GUI frameworks to decide which I want to use. And the ideal answer to the browser / desktop question is probably "both" which doubles the amount of work.
In fact, one of the motivations for GeekWeaver is to see if I can use it define a higher-level UI description that can be compiled down into both XHTML and a GUI widget-set.
Of course, with XUL, Open Laszlo, Adobe Flex, XUML etc. lots of people have been looking at something like HTML for defining desktop apps. too, but the free Python frameworks don't seem to have caught up with that yet. XUL sounds most promising especially with the open sourcing of Active State's Komodo ... but that's also a big complicated thing to even start looking into.
Anyway, inspired by the Enso extensions and Bruce Eckel's interesting example of hooking up a Python XML-RPC server behind an Adobe Flex application I've been wondering about blowing the project apart entirely into a number of services connectd only XML-RPC or something more ReSTful.)
So there'll be a WADS (SdiDesk PageStore) service, a GeekWeaver interpreter service, a "user navigation history service" etc. Even the glue which ties all this together will be another service that's neutral about the user-interface. Effectively the model, view and controller will be completely separate programs. (I know, I know ;-) )
Then there'll be a variety of different types of access with different UIs.
Now that Adobe's AIR has put Flash on the desktop and made it a serious rival to the Java virtual machine - I *am* tempted to put some time into learning it. It would give me a reasonable GUI widget set (including TreeGrid, yay!) and the vector graphics needed for networks. It will run both on the desktop and in the browser and on Linux, PC and Mac. The tools are free-as-in-beer (Flex beta) or free-as-in-speech (Open Laszlo). It's also possible to imagine generating the Flex XML or the Open Laszlo format directly from GeekWeaver. (Aside : I wish ActionScript hadn't borrowed quite so much from Java, but still, I'd only be using it for the front-of-the-front-end UI stuff.)
Then I want to experiment with Enso access - for example, Enso commands like "page HelloWorld" or "pagehistory ChocolateCake"
And there'll be web-browser access probably through a "gateway" that accepts http requests and spits out HTML for a browser. The only thing I don't know is whether I *really* should be using WSGI somewhere here.
Anyway ... that's a quick update of my thinking this week ... tune in soon for the next GeekWeaver release (really, it's coming together, and gonna be very powerful). Then it's back to work on this larger project.
Marcadores:
device swarm,
enso,
flash,
geekweaver,
python,
sdidesk
Tuesday, November 06, 2007
Next installment of the must-read series on FogCreek's Wasabi.
Fascinating to see the problems they've come up against and the solutions. What Stefan calls "picture functions" sound close to GeekWeaver "blocks".
Fascinating to see the problems they've come up against and the solutions. What Stefan calls "picture functions" sound close to GeekWeaver "blocks".
Marcadores:
geekweaver,
lispy,
littlelanguages,
wasabi
Monday, November 05, 2007
Over at Platform Wars I'm tracking Google's "square circles" (hierarchical tags)
Thursday, November 01, 2007
Very interesting ... seems that FogCreek's Wasabi is a language to compile into the various parts of a web-app in ASP or PHP.
So kind of a competitor to GeekWeaver. :-) Better take notes.
I wonder if it's gonna be released to the public.
So kind of a competitor to GeekWeaver. :-) Better take notes.
I wonder if it's gonna be released to the public.
Tuesday, October 23, 2007
DAn McWeeney has a great post on what he calls "synthesizers" : which seem like generalist / hacker / blogger / communicator type.
Personally I think the existence of the web is pushing us all in the direction of being synthesizers.
Personally I think the existence of the web is pushing us all in the direction of being synthesizers.
Saturday, October 20, 2007
This story about rejecting Rails in favour of PHP is very interesting to me now I'm on a PHP-tip.
Thursday, October 18, 2007
Important statement (actually essay / braindump) on my thoughts on widgets and YASNS over on my personal blog.
Wednesday, October 17, 2007
Mark Bernstein has a great post (and sounds like a great talk) on NeoVictorian Computing.
Wants to return software development to the personal and to making meaning.
Via Bill Seitz
Wants to return software development to the personal and to making meaning.
Via Bill Seitz
Marcadores:
art,
arts and crafts,
mark bernstein,
neovictorian,
software,
tinderbox
Tuesday, October 16, 2007
Marcadores:
geekweaver,
language oriented programming,
lop
Good weekend for GeekWeaver development ... you can now pass arguments to functions that are more or less table-shaped - like this :
It's not public yet, but it will be available in the next installer.
Also, although GeekWeaver is designed to be written in an outliner, I'm close to a plain-text mode which will look something like the above.
But I have a problem which I'm still not sure of how to solve. GW has to preserve literal text. So using spaces for indentation like Python is not so easy.
could mean either a node "abc" with a child "xyz" or two nodes at the same depth : "abc" and " xyz". How can we tell the two apart?
Currently my plain text parser works with code that looks like this :
Which keeps the continuity with wiki-markup and disambiguates from
But it's pretty ugly if you really were going to do any serious programming with it.
Suggestions welcome.
:f Fruits
apples,, oranges,, pears
grapefruit,, passion-fruit,, grapes
bananas,, lychees,, mangos
It's not public yet, but it will be available in the next installer.
Also, although GeekWeaver is designed to be written in an outliner, I'm close to a plain-text mode which will look something like the above.
But I have a problem which I'm still not sure of how to solve. GW has to preserve literal text. So using spaces for indentation like Python is not so easy.
abc
xyz
could mean either a node "abc" with a child "xyz" or two nodes at the same depth : "abc" and " xyz". How can we tell the two apart?
Currently my plain text parser works with code that looks like this :
* abc
** xyz
Which keeps the continuity with wiki-markup and disambiguates from
* abc
* xyz
But it's pretty ugly if you really were going to do any serious programming with it.
Suggestions welcome.
Thanks to Zby for turning me on to Behance which seems to be an interesting combination of social networking for creatives backed by a GTD-style how-to-organize methodology for disorganized creatives, and has special stationery too. Yay!
Could fall between a lot of stools, or could be the next-big-thing (more fun than Linkedin, more serious than Bebo, easier to use than degenerate art)
I do like the explicit emphasis on trying to solve the problems of disorganized people.
I don't like that "software architect" is a creative label you can attach to yourself but "programmer" isn't.
Could fall between a lot of stools, or could be the next-big-thing (more fun than Linkedin, more serious than Bebo, easier to use than degenerate art)
I do like the explicit emphasis on trying to solve the problems of disorganized people.
I don't like that "software architect" is a creative label you can attach to yourself but "programmer" isn't.
Thursday, October 11, 2007
Monday, October 01, 2007
Just commented on a topic dear to the hearts of all smart, disorganized individuals over at Ward Cunningham's Vision Thing.
Subscribe to:
Comments (Atom)