TreeSheets look like a pretty interesting combination of spreadsheet and hierarchical outliners / organizers.
Im sure my answer / comment on What is Gradle in Android Studio? will get downvoted into oblivion with short-shrift fairly soon. (Maybe deservedly).
But I’ll make it here :
At the risk of being discursive I think behind this is the question of why the Android Studio / Gradle experience is so bad.
Typical Clojure experience :
* download project with dependencies listed in project.clj.
* Leiningen gets the dependencies thanks to Clojars and Maven.
* Project compiles.
Typical Android Studio / Gradle experience :
* “Import my Eclipse project”.
* OK project imported.
* Gradle is doing it’s thang … wait … wait … wait … Gradle has finished.
* Compile … can’t compile because I don’t know what an X is / can’t find Y library.
I’m not sure this is Gradle’s fault exactly. But the “import from Eclipse project” seems pretty flaky. For all of Gradle’s alleged sophistication and the virtues of a build-system, Android Studio just doesn’t seem to import the build dependencies or build-process from Eclipse very well.
It doesn’t tell you when it’s failed to import a complete dependency graph. The Android Studio gives no useful help or tips as to how to solve the problem. It doesn’t tell you where you can manually look in the Eclipse folders. It doesn’t tell you which library seems to be missing. Or help you search Maven etc. for them.
In 2016 things like Leiningen / Clojars, or node’s npm, or Python’s pip, or the Debian apkg (and I’m sure many similar package managers for other languages and systems) all work beautifully … missing dependencies are thing of the past.
Except with Android. Android Studio is now the only place where I still seem to experience missing-dependency hell.
I’m inclined to say this is Google’s fault. They broke the Android ecosystem (and thousands of existing Android projects / online tutorials) when they cavalierly decided to shift from Eclipse to Android Studio / Gradle without producing a robust conversion process. People whose projects work in Eclipse aren’t adapting them to AS (presumably because it’s a pain for them). And people trying to use those projects in AS are hitting the same issues.
And anyway, if Gradle is this super-powerful build system, why am I still managing a whole lot of other dependencies in the sdk manager? Why can’t a project that needs, say, the ndk specify this in its Gradle file so that it gets automatically installed and built-against when needed? Why is NDK special? Similarly for target platforms? Why am I installing them explicitly in the IDE rather than just checking my project against them and having this all sorted for me behind the scenes?
qzhuyan responds to me tweeting Emacs on PocketCHIP.
Emacs on pocketchip! Nice man! Then one can have portable org mode! https://t.co/ohzeegFQtD
— qzhuyan (@qzhuyan) August 11, 2016
Which is, er, very true. And wonderful.
Will I one day end up simply falling into Emacs Org Mode? Isn’t that basically everything I really want?
Am I wasting my time with quixotic effort of writing my own software for this stuff when I could be writing something newer and more important?
Another thing that’s pushing me to think about this : this week I’ve been playing with Faust. A wonderful language for writing signal processing networks (ie. synthesizers, audio FX etc.) that compiles to multiple back-ends … including PureData, Supercollider, VST plugins and stand-alone programs.
It’s basically where I imagined Gates of Dawn eventually going.
But rather than a Python library, its a very nice “little-language”, with great operators for describing composition of data-flow blocks. It’s well developed and supported. I’m trying it out for writing small synths / FX units I can run on small boards like CHIP and Raspberry Pi.
I can see myself doing a lot with this. But it’s basically going to kill Gates of Dawn. Maybe there’s room for a Python library for those who don’t want to learn Faust. But for me, Faust is looking extremely viable.
So … another wasted project?
Perhaps I need to look at this positively. I’m not old. But I’m not as young as I used to be. I don’t have so many projects left ahead that I can afford to squander them. Perhaps its time to pivot. Time for a cull. A “spring-clean”. To remove some more cruft projects that occupy too much of my mind, but are actually just weak “me-too” versions of existing things that I would use perfectly happily if I made the effort to learn them. Enough with the Not Invented Here syndrome.
I’m not saying that OWL or MTC are going anywhere yet. I use them, and they work for me. And they are DIFFERENT from OrgMode, or todo.txt or any similar thing out there. They are what I want.
But I need to embrace this change. There are so many exciting NEW opportunities, there’s no point getting hung up on the old stuff.
Dawn is over. For me it’s 2PM. And there’s plenty of work to be done.
OK. So someone has made a Pocket-style Raspberry Pi case.
Very nice. Hope someone starts commercializing these as I think they’ll be very important for the RasPi ecosystem.
You all probably knew where this was going, right?
Of course, it’s been my priority to run the new MTC on the PocketCHIP. And it runs fine, without any special conversion; just needed to figure out how to install a library it depended on without going through drracket.
Now I’m off for my celebratory bike ride. 🙂
Got my PocketCHIP yesterday.
And here it is running Emacs, with a Racket REPL via Geiser.
I have to say, this has been the dream for a long time … a cheap, portable device that runs Linux, has Emacs, git, rsync etc. And I can actually write and run Lisp on it.
It has a keyboard / screen that can be used in emergencies, but can also be accessed via USB-serial and PuTTY from any old Windows PC. (Useful when you want to go somewhere which may have a PC but don’t want to take a laptop with you.)
I’ve been excited by small computers before. I do stuff with Arduinos. I have a couple of Raspberry Pis sitting around. And last year got very enthused by the possibilities of the ESP8266 running nodemcu.
But in reality, the RaspPi and ESP have both proven more awkward to work / play with than the CHIP.
The RaspPi’s problem is its dependency on HDMI. And lack of ability to log in by serial over USB. I don’t usually have an HDMI screen to hand. And not in the same room as a network router I can connect an ethernet cable to. And without one, plus special keyboard / mouse etc. And wired internet connection, it’s hard to do much with the RaspPi. I normally only use it in the local hackspace.
The ESP8266’s issue is dependency on a 3.3v power-supply. Which is awkward. Even with an FTDI cable to connect it to the computer’s USB port, you need EXTRA power of the right voltage to talk to it. I have to use a spare Arduino, just to get that 3.3v power.
It kind of pains me to say it, as I really want to champion the British innovated Pi over the American innovated CHIP, but the CHIP guys have done a magnificent job of making their board easy to use straight out of the box. The PocketCHIP is a master-stroke. I unboxed it, plugged it into a USB charger, switched it on, and was exploring and playing with the CHIP within a couple of minutes. It combines all the extra gubbins you need to do stuff with the CHIP in one, obviously cheap, but pretty usable, package. Even the keyboard is OK for small bursts of typing.
I got a PocketCHIP and two extra CHIPs. Even without the Pocket, being able to communicate with a bare CHIP via a terminal over USB makes it far more accessible than the RaspPi. Once I’d figured out a terminal program (I found cu works well) I was able to log in, set up the wifi, update and upgrade the Debian and install the software I want to play with, without any hardware beyond the USB cable.
I really hope someone comes up with a Pocket equivalent for the Raspberry Pi Zero soon. It makes a massive difference to adoptability. And I don’t really understand why the Raspberry Pi can’t be accessed over serial. It’s got USB sockets. Why can’t we do serial over them?
This looks good : 500 Lines or Less
Fixed a minor, but annoying, bug in MTC Racket today.
There’s an option, when you have a URL in an item, to get MTC to pull it and show the “title” of the page that the URL is pointing out. It’s a quick reminder of what the page is about without opening up the browser (when it’s not obvious from the link itself). You do this simply by typing “a” (for “analyze”).
However, if you typed that in an item without a URL, MTC was blowing up. That is now fixed.
Today I killed the old Mind Traffic Control on Google App Engine. And replaced it with a new, fairly basic, site. (Though one that’s quite pretty, in a Packt Publishing kind of way.)
This is the beginning of a whole new MTC ecosystem.
1) I’m no longer interested in hosting your todos on Google App Engine. The only functionality that’s left on the site is the “export”. You can get the tasks you put into the old MTC in one of .txt, .csv or .opml formats.
.txt means you can use either an ordinary text editor, todo.txt or the new command-line based mtc program on your own machine.
.csv means you can use a spreadsheet if you prefer
.opml can be read into an outliner such as OWL.
2) The site has a new mission. Right now, it’s simply pointing visitors to the two pieces of software that I use to manage my todos and information : MTC command-line (in Racket) and OWL (in its three different versions : desktop, Android and web-served).
These are currently all simply source-code, hosted on GitHub. (Both MTC-racket and OWL are free-software, under the GPL).
It’s a geek view. But going forward, I’m going to be preparing, packaging and documenting these for actual users.
3) Right now, I still don’t know the relationship between MTC and OWL. They’re different programs, with different “mind traffic geometry”, in different languages. But I use both and I’m constantly musing about how they can and should interact.
The only thing which is clear to me at the moment, is that they should be brought together under the common Mind Traffic Control “brand”. As a statement of intent.
The question of 2014 is getting resolved.
4) “What about Project ThoughtStorms?”, you ask.
Well, I tend to think of “Project ThoughtStorms” as the developers’ view on my knowledge management / personal productivity software. While “Mind Traffic Control” is the user perspective.
There’s more to it than that. Project ThoughtStorms covers my experiments and add-ons to the Smallest Federated Wiki and thinking about wiki in general. MTC heavily emphasizes the dynamic flow of tasks. But that’s the broadest overview.
In practice I’ll continue to refer to MTC-racket and OWL within the contexts of both Mind Traffic Control and Project ThoughtStorms.
5) I am VERY happy to be deleting code. And collapsing several different overlapping ideas and codebases into … er … fewer. It’s a therapeutic decluttering that’s clearing space in my mind, and helping me focus and drive the surviving projects forward faster. It’s good.
But there is just a slight twinge of sadness. As I realize that this is a mile-stone in letting go of Python, a language I had a long and passionate engagement with. Both the old MTC code-base AND the server-side PageStore of OWL are Python.
(Actually there is a project that’s still in Python where you’ll see some further development soon … but I’ll leave that to another post.)