I’m having a Melanio V and one of their draft rootbeers. I just don’t remember it being this good.
I picked up the “Wicked Cool Shell Scripts” book a few times today when I was in B&N before heading out for a bite (a cheeseburger at J. Alexander’s, skip it.) I almost walked out with it a few times; checked the price on amazon (within $2 with the discount at B&N.) But then I realized that there’d really be no reason to use bash over python or perl for most of those things.
It’s a function of designing a low level component architecture that splits responsibilities into multiple individual processes. As long as I’m not walking all over myself with the storage back end, there’s almost no reason not to design this (todo list/project manager) that way. I could take all the analytics and set them up as mixins that run independently and just decorate the damn data. There’s no reason to use a complicated storage format when I can just store the data in flat files for maximum flexibility. Hell, even if I create a little library for storing stuff in a tabular format (a wrapper around csv with some type checking) I’d be in perfectly good shape just building on that.
Then if I wanted to get fancy I could port a tool at a time over to straight C. It’d be golden. Then add a call wrapper that I could use to run mocks or actually just call web services as well, then I could microservice the whole damn thing.
Now if I take that and start drawing out from there, I end up with something that starts to look like a lot of the late 90’s Agent Architecture diagrams. Now, that never really MEANT anything. But the ability to transport asynchronous tasks across architectural boundaries transparently is an awfully useful concept.
The granted flexibility would drop the barrier to entry, from an architectural perspective if nothing else, to near zero. Functional components could be added by banging out a simple script. Worry about where the hell it lives later.
That would be predicated on some kind of minimal service registry, something that’d play the dispatch game. Now of course THAT would be an external service as well.
[Not what I was looking to write about. But as long as it’s sticking to a single topic and is going back and forth with some actual thought, I’ll take it. Writers have the cleanest closets.]
So let’s get down to brass tacks:
- A todo list is a list of tasks, persisted, with (initially) a description.
- There’s an application that can add items to the list.
- There’s a user interaction that can “complete” items on the list, which removes them from the visible list
- The storage format should be text based, easily readable by humans or other programs.
- The storage format must allow for flexibility of future expansion without interfering with minimal functionality. This suggests a simple numeric index of items that can be used as a foreign key to other applets freely.
I’m going to sketch out some minimal implementations of these. They don’t make a WHOLE lot of sense to me without an actual gui front end, web based or otherwise. Actually I quite prefer otherwise. The massive proliferation of web-based guis for everything just makes me kinda crazy. I’d rather a java or other kind of desktop front end, even if the back end was http, local or not.
These are stream of consciousness right now. But I find the first few attempts at putting something down generally involve me sweeping and shoveling out the crap in my head to get down to the good stuff.