Go Plain Ubiquitous Plaintext Capture, Part 1: nvALT

In my Go Plain manifesto, I said that the first thing I plan to deal with is ubiquitous plaintext capture solution.

So here I am, trying to deal with it, having some success on the Mac, mostly failing on mobile…

This post is part 1 of several posts on the subject of plaintext capture. I am dividing it to parts because it is still work-in-progress, and I wanted to share as I go along.

To reiterate and elaborate, my expectations for a “ubiquitous plaintext capture solution” include:

  • Available across all my devices. To prioritize: MacBook, Android phone, iPad, Windows laptop.
  • Sync “captured items” across all said devices, given connectivity. Handle poor connectivity with dignity – we are talking about plaintext files here. Handle sync conflicts gracefully.
  • The act of “capturing a piece of information” must be totally frictionless. This means as few clicks and taps as possible to get to “capture mode”. No messing with filing and categorizing a “captured item”. It should just be there, waiting for when I’m ready to deal with processing it.

A tl;dr version of where I am with this, at the time of writing:

  1. Decided that “captured items” are plaintext Markdown-formatted files in my Dropbox GoPlain/Notes directory. Flat structure (e.g. no sub-directories) to force simplicity. Filename is note title, file text is note content.
  2. Decided on nvALT for capturing notes on OS X. Been using it for a couple of weeks. It’s perfect!
  3. Became frustrated with the options I evaluated on Android. Remained unsolved for now 🙁 .
  4. Got overwhelmed with options on the iPad (iOS in general). Got to join nvNotes beta testing. Loving it so far!
  5. Didn’t do anything with my Windows laptop. It just sat there, streaming my Google Music library. Just as important for my productivity 🙂 !

In this part, I go into some detail about nvALT and my “ideal capture experience”. If you stick around, there might also be a mobile rant 😉 .

Get Safe Paths From Arbitrary Strings In Python

Sometimes, all you want to do with an arbitrary string, is to use it to create a file or a directory. Really, that’s all. Nothing too special about it, right?

Alas! This is the root of all evil!

Arbitrary strings are dangerous, and should be handled with the utmost care, as if they were explosives, or Frank Underwood’s new liver! (sorry)

Wait, but, how exactly are they to be handled? And why should you reimplement this apparently basic, but practically risky, functionality every time you need it?

This is exactly what my ostrich.utils.text.get_safe_path() OstrichLib function set out to solve once and for all 🙂

It’s already available in Ostrich Lib in release v0.0. It’s also released to PyPI, meaning you can get it now with pip install ostrichlib. It’s tested (using Travis CI) against Python 2 & 3, and requires only the future library as an external dependency (which makes everyone happier with Python 2 / Python 3 compatibility). Detailed library documentation are available via Read the Docs. Hurray!

I would love to get some review from others for my solution, given the risky nature of the problem.

Migrating Kambatz Meteor App to Galaxy

A few months back, MDG announced Meteor Galaxy, their “cloud platform for operating and managing Meteor applications”. It was only for development teams and enterprise at the time. Earlier this month they released One Galaxy for Everyone, including a basic “pay-as-you-go” plan for $0.035/container-hour.

Now, I can’t say I was unhappy with the free hosting on meteor.com, but along with this Galaxy release they also decided to shutdown the free hosting on meteor.com. So I had no choice, but to migrate my Kambatz app.

I am aware that there are multiple Meteor hosting options out there. I am going with Galaxy, for now, because:

  1. It looks like the path of least effort 🙂
  2. I did not see other viable free options, and this seems to be affordable.
  3. When Galaxy was launched on October 2015, I watched a talk by MDG’s Matt DeBergalis on AWS re:Invent about the Galaxy architecture. It’s built on top of AWS Elastic Container Service (ECS), and it was fascinating. If I can have a chance to experience it from some perspective (e.g., an end-user), maybe I can learn more about it. In any case, the alternative I had in mind is to set up my own Meteor-in-Docker on AWS-ECS, to minimize costs, so this seems pretty close to that. Maybe if I later transition, it will be smoother 🙂 .
  4. Supposedly, since I migrated before March 25, I should get a $25 credit on my Galaxy account 🙂 . Haven’t seen it yet though.

One thing to keep in mind is that Galaxy does not include MongoDB hosting. You’ll need to find another place to host your MongoDB, like mLab.

Go Plain: My Simplicity-Driven Personal Productivity System

In the previous post, I announced that I am ready to reinvent my personal productivity system.

Today, I present Go Plain: My simplicity-driven personal productivity system. Well, it’s not yet a “personal productivity system”. It’s the working title for my work-in-progress system, and this post is a high-level “manifesto” for this system. I use “manifesto” here loosely, and mostly mean “high level roadmap and requirements”. Just thought it was a fun word to use 🙂 .

You can refer to the Go Plain project page for an always up-to-date list of posts related to this project.

My Productivity Porn Season Has Begun

My name is Itamar, and I’m an addict. My addiction is hardcore productivity porn (don’t worry, it’s SFW).

I do my best to keep my addiction controlled. Under normal circumstances, I don’t tamper with my “productivity system”, beyond minimal maintenance, and the occasional incremental targeted workflow improvement.

The issue with the statement above is an underlying assumption that “the system is mostly good, and fits my current situation in life most of the time”. That assumption has been overwhelmingly false for a little over two years now.

My Python 3 & Python 2 Dual Development Wishlist

I want to use Python 3 in my new Python-based projects. I really do.

It is clear that Python 3 is the future (present?), and is probably the “better language” compared to Python 2. Why not use the newer language?

Raymond Hettinger would probably say that Python 3 allows you to write more beautiful, idiomatic Python. I’m all in favor of that!

These days, I use Python 3 without much thought for small scripts that are intended for personal use, with few dependencies. This works fine, as long as I don’t reach a point that I want to use that library that doesn’t support Python 3, and then it’s a PITA…

If I want to write something that I want to share, on the other hand, choosing Python 3 is not so obvious. I want to use Python 3, because it’s the “Right Thing To Do”. I don’t want to be that “library that doesn’t support Python 3 and is someone’s PITA”. But I also want to have my stuff accessible to the masses that are still working only with Python 2, for whatever legitimate reason they may have. Like this, and to some extent this.

I wish there was an easy way to do just that – write beautiful, idiomatic, Python 3 code, while maintaining Python 2 compatibility.

I want to write beautiful, idiomatic, Python 3, and maintain Python 2 compatibility – it this too much to ask?

Yes, you can say that Six library is a solution for writing dual Python 2 & Python 3 code. But would you argue that it grants my wish for “beautiful, idiomatic, Python 3 code”? If you think it does – please show me some examples!

Maybe you can also claim that 3to2 is a viable solution. I don’t know – I haven’t tried yet with complex real-life use-cases. Have you? Can you say this is a feasible path to take? How well does it handle the newest shiniest Python 3 stuff? What’s the development workflow around it? What do you do to catch and fix the edge-cases it doesn’t handle well, without ruining the original code with version-aware crap?

Are there other viable options? Anyone doing this with a large-scale projects, and is willing to share the approach and experience?

Intro to Meteor Coursera Course: Final Thoughts

I completed the Introduction to Meteor.js Development course two weeks ago, after submitting the final assignment – my social website aggregator. I waited with this “final thoughts” post, because the course officially ended just now.

I also joined the follow-up course, Web Application Development with JavaScript and MongoDB, as it seems to keep digging into more advanced Meteor subjects. It just started this week.

Kambatz App: First Iteration

I finally started building Kambatz – my bills management app.

It’s a refreshing change, after weeks of just learning, by taking an online course, or going through an official tutorial. I finished the course, in case you’re curious. I plan to write my thoughts about the course once it formally ends.

The course served me well. I was able to use my submission for the final assignment as a reasonable starting point for my Kambatz app. I changed most of it, but it was useful nonetheless!

This iteration of the app doesn’t really do anything. It’s just some plumbing and layout to get me started. Read on for more about what it contains, and the new things I learned while working on it.

You can see the latest prototype at kambatz.meteor.com, and follow the code on the GitHub repository 🙂 .

A snapshot of this iteration is available at 20151213.kambatz.meteor.com, and the code for this iteration is tagged in the GitHub repository.

Official Meteor Tutorial: TODO App With React

I installed Meteor, and joined a Coursera introduction course, but I still want to go through one of the official Meteor tutorials.

The Meteor site has a tutorial around building a “ToDo App”, in one of three flavors – Blaze, Angular, and React.

I’m not quite sure what it means to choose one of these flavors (see more in the feedback section). It looks like Blaze is some sort of a default, or the recommended one, based on some links pointing directly to it, and the fact that it is the first in the list. I’m already using Blaze in the Meteor intro Coursera course, so to spice things up, I randomly decided to go with React for this tutorial.

Do read on for the an exciting and detailed accounting of my step-by-step experience with the tutorial! 🙂 For your convenience, I have shared my tutorial implementation in a GitHub repository. It shouldn’t be very different from the official Meteor tutorial repository, but I took the liberty to add some tweaks of my own.

tl;dr: The tutorial was excellent. It is well structured. Things worked as expected. It is clear and concise. I feel I learned a lot in a short time. I do have some feedback to share, about the lack of clarity about Blaze vs. Angular vs. React, the mobile section, and the insecure defaults that are built-in.

I Joined the Intro to Meteor Coursera Course

After installing Meteor, I thought I will continue with the tutorial, in my learning process. But then I found out that Coursera is offering a free Introduction to Meteor.js Development course that just started last week. Since the course was approaching the end of week 1, I decided I’d go ahead and join the it!