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 .

nvALT and my ideal capture experience

How would an ideal “capture mode” look like, if I could have it my way?

The short answer – exactly like nvALT on OS X.

For those who are not familiar with it, here’s a short description of the relevant features:

You start with an empty search box, above a list of previously “captured items” (let’s call them notes from now, OK?).

You start typing a title for the note you’re about to capture (right in the search box).

The list of existing notes is instantaneously filtered using your title as search query (really, also for many thousands of notes, and it’s an excellent full text search).

Often, you see a matching note that is relevant to what you want to capture (e.g., append something to an existing running list). In that case, you can select that result and edit the existing note. If you really want to create a new note, you just hit Enter, and a new note with the title as a filename is created.

In both cases (edit existing or create new), the cursor is immediately place at the end of the note body, so you can keep typing the content.

This might sound like more clutter than an alternative that just gives you a blank text box, but it really isn’t.

If all you want to do is to write your note — you just do it (title, Enter, content, done). Ignore the searching that happens – it doesn’t slow you down.

From my experience using it so far, the searching is so useful, that I take advantage of it more often than not.

The amazing thing about nvALT is how fast it is. I know I’m mixing here between “requirements” and a specific solution, but the frictionless requirement can be a subtle beast.

I’d like to use nvALT as an example of how speed is important in removing friction.

Assuming nvALT starts on login, and you configure a keyboard shortcut to activate it (you should!), you’re always less than 1 second away from capturing a note.

It’s hard to put into words how significant it is that hitting ⌘⌥N will reliably put me into capture mode so fast. If it took 3 seconds, or required another operation, or crashed 0.1% of the time, I know I would just do it less. Subconsciously.

Oh, did I mention it’s free?! (but if you like it, consider donating to the developers! They need coffee and/or beer!)

My nvALT set up

Of course, I configured a global “bring-to-front” Hotkey.

To play nice with “everything else”, I changed the nvALT settings to manage the notes as individual plaintext files in a new Dropbox directory (GoPlain/Notes). If you intend to interact with the notes from other apps, it is recommended to uncheck the Confirm note files removed in the Finder checkbox. Otherwise, every time you delete a note from anywhere, nvALT will ask you if you’re sure you want to remove it.

Also, since I mostly work with Markdown-formatted notes, I added the md extension to the list, and set it as the default extension. Setting it as the default will make nvALT save new notes with that extension. This is what I want, because if I open these notes with other applications (such as Sublime Text), I get correct syntax detection.

As a matter of personal preference, I changed the fonts & colors. I chose the AndaleMono 13, and a dark colors theme.

What about mobile?

OK, so what about Android phone, iPad? Is nvALT available on these platforms?

Unfortunately, no… And this is where the cookie crumbles .

I spent many hours and moneys on trying out a bunch of apps on Android and iPad. I didn’t even get to dealing with Windows yet, or testing things under limited connectivity and conflicts.

At least with the nvALT-Dropbox set up I have “raw” access to the notes from all devices and platforms, since Dropbox is available on all. That’s something – I have ubiquitous read/write access, but still with great friction (and no real offline access on Android and iOS).

I’m beta testing nvNotes on the iPad, following a recommendation by Brett Terpstra, and it looks promising. Will update on that after I’m done testing, in a separate post.

On Android, though, I couldn’t find anything that delivers anything close to the experience I’m looking for…

This is so frustrating.

Ideally, I would like an Android port of nvALT. If anyone comes across such a thing, please let me know!

A close second best would be some kind of Google Keep / Dropbox integration. I like Google Keep – it’s nice, simple, and supports quick capture and full text search. If it could do 2-way-sync with a Dropbox directory, it would practically be a nvALT-clone!

Alas, Google Keep, as it is now, is a closed garden. A prison for your own data.

So I submitted a Google Keep feature request, but haven’t heard anything. If you like the idea – please +1 my feature request . If Google Keep had some kind of open API, someone (me?) could even build such a thing independently! But, alas! There is no API! So, also +1 the API feature request .

Simplenote could also be a nice solution. They have Dropbox sync (only in premium, which is not offered anymore, unless you ask for it). tl;dr – it’s not good enough. Dropbox sync requires manual triggering only from the web app. I tested it with just a few notes, and I ran into severe note corruption that was enough for me to lose trust in that service. Credit where it’s due – responsive support team that enabled the premium feature on request, and is investigating the corruption I observed.

So I’m still floating as far as Android is concerned… Open for suggestions! Anyone?

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.

What does it do?

Since it’s pretty straight forward, a demo should do:

itamar@legolas 20:37:06 ~>docker run -it --rm python:3.5 bash
root@292a5eeed6e9:/# pip install --upgrade pip ipython
Collecting pip
  Downloading pip-8.1.1-py2.py3-none-any.whl (1.2MB)
...
Successfully installed ipython-4.1.2 ipython-genutils-0.1.0 path.py-8.1.2 pexpect-4.0.1 pickleshare-0.6 pip-8.1.1 ptyprocess-0.5.1 setuptools-20.3.1 simplegeneric-0.8.1 traitlets-4.2.1 pip-8.1.1
root@292a5eeed6e9:/# pip install ostrichlib
Collecting ostrichlib
  Downloading ostrichlib-0.0.0.dev3-py2.py3-none-any.whl
Installing collected packages: ostrichlib
Successfully installed ostrichlib-0.0.0.dev3
root@292a5eeed6e9:/# ipython
Python 3.5.0 (default, Sep 14 2015, 20:19:17)
Type "copyright", "credits" or "license" for more information.

...

In [1]: from ostrich.utils.text import get_safe_path

In [2]: get_safe_path('foo.bar')
Out[2]: 'foo.bar'

In [3]: get_safe_path('a/b/c/../foo.bar')
Out[3]: 'a_b_c_.._foo.bar'

In [4]: get_safe_path('<1!2:3@4.{5}-6_7(8)9=0>')
Out[4]: '_1_2_3_4._5_-6_7_8_9=0_'

In [5]: get_safe_path("let's dö söme funky Ünicöde? Yeäh!")
Out[5]: 'let_s_do__so_me_funky_U_nico_de__Yea_h_'

In [6]: len(get_safe_path(''.join('a' for _ in range(5000))))
Out[6]: 255

In [7]: get_safe_path(' foo/bar.baz') == get_safe_path('foo$bar.baz ')
Out[7]: True

Essentially, it takes your shiny string, and replaces everything that’s not in a whitelist with underscores. The whitelist includes alphanumeric characters, -, ., and = – which are arbitrary characters I decided should be allowed. Surrounding spaces are stripped before conversions.

Some extra nifty things it does:

1. Unicode NFKD normalization before conversions. This means that evil unicode characters that have ASCII-look-alikes will be replaced with those ASCII’s! (see example 5 above)
2. Truncating resulting string at 255 characters, which is the standard entry name length limit on most common filesystems. (see example 6 above)
3. Make sure that the resulting string isn’t empty, or just a bunch of dots (.) (which may cause path traversal). Such a condition will trigger an exception.

See the tests file for more.

This is all accomplished with very little code, as you can see in the source file (which contains more documentation than code),
while being compatible with both Python 2 and Python 3 (as far as I can tell at least; that’s what Travis-CI says).

Discussion

As I wrote above, I am very interested in review from others, as I want this to be bullet proof.

Beyond that, it is important to understand that this function is still stupid. It takes a string, and returns another string. It has no awareness of files and directories, and does not want to be aware of such things. The fact that a string is safe to use as a filename, does not mean that you should write a file there, or create a directory there. That’s an application decision. Do you want to first check for existence? Create parent directories? Guarantee uniqueness somehow? This is not in the scope of this function – it’s your responsibility.

Specifically, regarding uniqueness, it is important to understand that these conversions make it so that multiple input strings may result the same safe output string, as you can see in example 7 above. Whether this is an issue or not depends, again, on the application.

If your application handles truly arbitrary strings, and needs to map them to truly unique paths in the same namespace (e.g. parent directory), then I can think of two possible approaches:

1. Use my function, but manage a mapping in your application from the safe name to the original name. If the function returns a result that’s already in that mapping, but is for a different original name, then append a '.%d' % n to the safe name for increasing values of n, until the modified safe name is “available”. You can probably wrap this in a decorator to simplify the using code. It’s like a smartass cache for the function result.
2. Why bother with these conversions at all? Just hash the crap out of the input strings!

root@7c65e882b3c1:/# ipython
Python 3.5.0 (default, Sep 14 2015, 20:19:17)
Type "copyright", "credits" or "license" for more information.

...

In [1]: from hashlib import sha1

In [2]: sha1('../foo/../bar.baz?!'.encode('utf8')).hexdigest()
Out[2]: 'a810bb4a5694ef259780b1be1fcb7776dc8d090e'

The downsides of the hashing approach, as I see them:

• You completely lose “visual” relation between the input and output strings. With the normalization approach, the output string usually looks like the input string.
• While collisions are rare, they can happen. Do you want to rely on chance? Or will you implement the safety mechanism I described anyway?

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.

My migration steps

See below for annotated screenshots of most steps as well.

1. Create account on Meteor Galaxy (or use existing Meteor account). I chose the “Basic” plan.
2. Create account on mLab.
3. Create new database in mLab account. Prefer AWS us-east-1, as it is the same zone used by Meteor Galaxy.
4. Create a user for the newly created database (note this isn’t the same as the mLab user – don’t use the same username / password).
5. Write down the MongoDB URI (AKA “connection string”).
6. Create a settings.json file in the root of the Meteor project (e.g. ~/work/kambatz/settings.json), and put in the MongoDB URI for the Galaxy deployment target (replacing the <dbuser> and <dbpassword> and <dburl> with your real details of course). See content below.

7. Deploy the app to Galaxy, using a meteorapp.com subdomain: DEPLOY_HOSTNAME=galaxy.meteor.com meteor deploy kambatz.meteorapp.com --settings settings.json. Fill in your Galaxy username (not email) and password.

8. Done. Go see your app serving on http://yourapp.meteorapp.com.

{
  "galaxy.meteor.com": {
    "env": {
      "MONGO_URL": "mongodb://<dbuser>:<dbpassword>@<dburl>"
    }
  }
}

Summary

That’s how I migrated my Kambatz app from the free (alas, deprecated) Meteor.com hosting to the new Meteor Galaxy hosting.

I did not cover DNS configuration for serving the app from custom domains, since I don’t care about this at the moment. I’m perfectly fine with using the meteorapp.com subdomain for development. For completeness, there’s a support article on configuring DNS on Galaxy help.

Also, since this hosting isn’t free, I am stopping my app when I’m not actively developing it to reduce costs. This means that http://kambatz.meteorapp.com will be up sometimes, but not always. Tough. I’m sure many of you relied on it .

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.

Disclaimer:

This is my personal take on a personal productivity system. As such, it is going to be highly customized to me, my needs, my lifestyle, and my preferences.

I am sharing it here because:

1. I want to
2. I believe my situation is not completely unique, so maybe others may benefit from what I share.

Once I have more pieces of my system in place, I plan to come up with a profile of who I think this should work for, and whom it likely won’t. I can guarantee that no one will be able to take my system as is and apply it smoothly. It will surely require cherry-picking or some kind of adaptation.

Go Plain Manifesto

• Simple is good, friction is bad.
• “Less is More”. Use as few “tools” as possible, but not fewer than necessary to make things work smoothly.
• It’s important to be able to “be productive”, independent of which platform and device I happen to use, screen size and resolution, or online / offline status. This portability deserves a lot of thought and effort, but it has limits. Simplicity should not suffer too much. It is not less important to acknowledge the limits, and prioritize.
• Small tools that do one thing well are usually easier to compose in a system, compared to big multipurpose tools that do many things “OK”.
• Flexibility is an asset. Things will definitely change, in unexpected ways. A flexible, loosely coupled system will be easier to adapt.
• Good search wins over good filing & categorization, every time, on every digital platform.
• Wait before automating. Avoid “forcing automation”. Let it emerge from natural usage.
• Prefer widely adopted services over niche ones. They tend to stick around longer, and have wider platform support. For example, Dropbox over SugarSync for cloud-based file syncing.
• Prefer sticking to the basic, essential, stable & robust feature of chosen services. Esoteric features might be useful for esoteric scenarios, but the features may disappear, or be unreliable for the long run.
• Open source is better than proprietary, but it’s definitely OK to pay for good products and services (“open source” doesn’t have to be “free”).

A bit more concrete principles and requirements

The manifesto is quite high level. This is intended. There are more concrete guiding principles and derived requirements that I feel belong here, but not at the “manifesto” level.

• Ubiquitous capture is essential. Whatever device I happen to use – if I have some piece of information I want to capture, it should be a completely frictionless operation. Ideally, I would use one capture tool (per device?) for all capture purposes. My system will take care of syncing all captured items, given connectivity.
• Plaintext files with Markdown formatting are the basic building block. This seems to strike the ultimate balance (for me) between simplicity, flexibility, portability, and function. Maybe this deserves its own post, if it’s not clear why .

Short term goals

To save myself from my tendency to over-engineer, and try to solve everything at once, here are the things I plan to deal with first, in this order:

1. Set up a ubiquitous plaintext capture solution that meets my expectations. It must be available on all my devices, and sync across all of them. This is where I’m and not willing to settle on friction, since I know that if capturing a piece of information is not frictionless, I will likely just not do it.
2. Come up with a simple workflow for processing captured information. If I don’t have a process in place, I know I will have mental friction in capturing information, because I will think about all those captured items staring me there, waiting, laughing.
3. Add personal short-term task management to my plaintext-based system. The focus here is on the MacBook & Android phone. Windows laptop & iPad are only nice-to-have.
4. Extend the plaintext-based system to accommodate my personal project management, and expand “personal projects” to include also the “work projects”. Generally, a “project” is any group of tasks that strive to a common outcome (such that 1-2 tasks are not enough to accomplish said outcome). I think I want Git-based version control here – I wonder how this works across devices, and whether this can play nice with syncing. The first priority here is the MacBook. I think the iPad and Android phone are tied for second priority.

All along, fight to eliminate friction, and simplify things. Try to accomplish every goal with as few new tools as possible. Prefer the clean, more minimal tools, that do less but do it better. On laptops / desktops, optimize for keyboard-driven operation.

Knowing myself, here are a few things I explicitly will not try to deal with at this time:

• The personal task management will not address long term tasks, recurring tasks, reminders, scheduled events, goals, etc.
• I will not attempt to change the way I use Evernote for saving reference material (e.g. clipping web pages).
• At first, I do not intend to change how I work with Google calendars, Feedly, Pocket, and Inbox by Gmail.
• I will not attempt to change the way I use Evernote for composing and publishing blog posts.

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.

In the beginning of 2014, I went through the following major life changes, all within one month:

• I became a father of twins.
• Left my previous job. After over 7 years of working in one field, in a very strict IT environment. Windows only. No synchronization what-so-ever between my “life” stuff and my “work” stuff (strictly forbidden in said IT environment).
• Started my current DayJob. A completely different field. A completely different IT environment (one I happen to control ). Mostly Linux. Started using a MacBook Pro as my main machine.

My last “productivity porn blitz” was circa 2010, after reading David’s Allen Getting Things Done for the first time. Back then, I tried to adapt the philosophy, and implement a system that worked for me, given my situation at the time. It was Outlook and OneNote-centered. Mobile technology wasn’t even an integral part of the system, as I didn’t even own a smartphone until summer 2011.

With the amount of change come 2014, I had to make some modifications, but it was in survival mode (newborn twins, remember?), not methodological. Maybe I’ll write another post about the current state of affairs, but the point is that it’s been bothering me since then. It reached “critical levels”, and it’s clear to me that time has come to take significant action. I started to fiddle with ideas and tools that completely reinvent my systems, and as any good addict, I’m quite excited about it .

If you’re into such things, I believe you will find it interesting to follow my posts on this topic as I go along, tinkering with my workflows, and reinventing my systems. This is especially true for those who use OS X as their main computing environment, but are not willing to go “all in” on the Apple ecosystem. I require that I can do most things also from my Android phone, secondary Windows & Linux laptops, and iPad Air. Although I have two “Apple ecosystem” devices, I am definitely more into the Google-verse than the Apple-garden.

So far, my intermediate conclusion is that my requirement for wide interoperability is the most challenging one. I could not find any resources out there about effective and simple systems that cover OS X, Android, iOS, Windows & Linux. If anyone knows about existing solutions with such a wide support, I would love to know about that! Please do share via the comments! In the following posts I will go into more details about the specific use-cases and workflows, and it will be clearer what I am trying to achieve, and how I’m trying to accomplish this across all the platforms.

Post thumbnail image from Flickr user neetalparekh, licensed under CC-BY.

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.

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?

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.

Overall, the course was effective. It already proved useful, as I was able to build the first Kambatz iteration starting from my assignment submission.

I have one major criticism towards Coursera here though. This course is part of a 6-part specialization that they are marketing aggressively, but they are also selling the individual courses from the specialization. This implies that the courses are independent, but this is definitely not the case. The course referred to “other courses in the specialization” quite often throughout. I won’t complain much, as I took the free version, but this wouldn’t be fair towards paying students…

Back the the course itself. If you’re also new to Meteor, and considering whether to take this course, or just go through the official tutorial, here’s my advice:

1. If you want to start with Meteor as quickly as possible, just do the tutorial. If you have React background, do the React tutorial. Otherwise, do the Blaze tutorial.
2. If you’re not in a rush, and you’re familiar with modern web development essentials (HTML, CSS, JavaScript, jQuery, Bootstrap), go ahead and take the course. You might be able to go through all of it in a day or two, since all 4 weeks open up as soon as the course begins.
3. If you’re not in a rush, and you’re lacking said web development skills, consider taking the entire specialization. If you’re not afraid of picking up new things on the fly, you might be fine with starting with this course, and filling in the gaps as they come up (this is what I did).

The course was great, but the time investment was much greater than going through a tutorial. The tutorial focuses on Meteor stuff, while the course also deals with building an actual web thingie around the Meteor stuff. As far as “actual Meteor stuff” are concerned, both the course and the tutorial cover similar grounds. The tutorial actually covers more core Meteor, like methods and subscriptions – topics that only the follow-up course deals with. The course covers more diverse topics, like using a bunch of packages beyond accounts (bootstrap, stars-rating, comments, search) that are practically useful for building real web applications.

One particular aspect of this course that I really appreciated is the fact that bugs and errors were not edited out! The instructor would often make code changes “on camera”, and make a mistake or error (most commonly forget a comma, sometimes forget to save one of the files, etc.). Then, when things crash and burn, instead of redoing the scene, the instructor would simply live-debug what’s happening – which is great, because these kind of things are expected in real life, and shouldn’t be hidden and left on the editing floor .

Unfortunately, there were some more subtle issues with the examples that were not uncovered and dealt with by the instructor. Here are a couple of example of issues that were raised by students in the course discussion forums:

1. It appears that the accounts-password package is vulnerable to user ID and password enumeration, as visible from the responses the instructor got in the video when trying to log in using different usernames and passwords.
2. Seems that the gallery rating functionality implemented in week 2 broke by the end of the week, as visible in the videos where sometimes the rating wouldn’t show up. Some students thought this might be because of elements with ID’s that start with numeric characters (when the underlying Mongo ID happens to start with a number). Others pointed to the fact that there are two elements with the same ID as the root cause. I still don’t know what exactly is the root cause, and what should be the proper fix.

As with my point about bugs and errors – I think it is good that there are problems. The “unfortunate” thing here is that these issues remained unresolved, without attention from the course staff. The first issue, concerning the security of a core Meteor package, may be beyond their control. But not addressing the second issue, concerning the core content that they created, is simply unprofessional.

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.

What’s in this iteration?

This iteration doesn’t do much, as far as functionality goes. The focus was more on the layout and plumbing. It includes:

• A responsive bootstrap-based UI.
• A top-navbar, that doesn’t do anything, but includes a neat search box.
• A sticky footer, with copyright notice, and information about the deployed iteration.
• A sign-in widget that actually works, because it’s so easy to do that in Meteor! No point in using it though, as it does not affect the functionality in any way.
• Main area with template that pulls “bills metadata” from a MongoDB collection and displays some data about them.

I borrowed from the course the idea of pushing some mock data into the collection on the server startup event, if the collection is empty. It definitely makes development easier – no need to write input interfaces to get data into the prototype. I also learned how to use Bootstrap in the course. The use of iron:router – also from the course.

As you can see, there’s no actual functionality here. Just rendering a static list of bills.

New things I learned for this iteration

One new thing I learned during this iteration is about the #with template tag.

One of my “bill types” is a “receipt”, that refers to another bill record, by its _id. To render a “receipt”, I wanted to pull the bill it refers to, and use fields from that record. I learned that the way to do that, is to use the #with template tag to set the data context to the referenced bill. You can see this in the kambatz.html template code.

I also learned that I can’t do much logic inside template conditional tags. I wanted to display different things depending on the bill type, so the natural thing was to do things like {{#if (type == 'receipt')}} in the template. That didn’t work. I could write a template helper isReceipt() that returns the result of that logic, and use {{#if isReceipt}} in the template. But I’m too lazy to write helpers every time I need a simple comparison. So I found this StackOverflow answer that taught me to register a global template helper equals that does exactly what I wanted (see here). With that, the template if looks like this – {{#if equals type 'receipt'}} (see here).

The HTML <footer> tag was also new to me.

Summary

That’s all for this first Kambatz iteration. No functionality, but some useful layout and plumbing stuff that I can build on in upcoming iterations.

I hope I will be able to keep progressing in such small iterations. It makes it manageable, and maintains a good balance between building and learning new things.

I am a little disappointed about the lack of resources about testing Meteor-powered projects. The subject of testing, not to say test-driven-development, was not mentioned at all in the learning resources I covered so far. Since I have no clue about frontend testing, and I’m at the prototyping phase, I’m opting to proceed without digging into testing at this point. I just hope that later on I will discover that Meteor have really good testing tools available…

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.

Going through the ToDo App With React tutorial

In this section I document my step-by-step progress through the TODO App With React tutorial. It’s quite verbose . See also my tutorial GitHub repository. Feel free to jump straight to the feedback section.

For each step, I took a partial screenshot of the tutorial instructions (in case the tutorial itself changes in the future), and one or more screenshots of the result.

Step 1: Creating your first app

Direct link

Commit in my repository

Step 2: Defining views with React components

Direct link

Commit in my repository

Step 3: Storing tasks in a collection

Direct link

Commit in my repository

Step 4: Adding tasks with a form

Direct link

Commit in my repository

This step had a troubling “side note” relating to security:

I will get back to that in the feedback section.

Step 5: Checking off and deleting tasks

Direct link

Commit in my repository

Step 6: Deploying my app

Direct link

I can’t say I feel comfortable with deploying a definitely insecure app. But it is in no way an app that handles sensitive or personal data, there is no login support, and it is deployed to the Meteor servers – so if they want me to deploy it, then I guess it’s OK…

I wonder why it took ~20 minutes… (my Internet connection is not that bad!)

Step 7: Running my app on Android or iOS

Direct link

Interesting, but not enough to go into lengthy installations. Maybe some other time.

Step 8: Storing temporary UI data in component state

Direct link

Commit in my repository

Step 9: Adding user accounts

Direct link

Commit in my repository

Now, I didn’t like the way old TODO items look “broken”. Here’s a small tweak for displaying a generic name in that case:

My tweak commit

Step 10: Security with methods

Direct link

Commit in my repository

Step 11: Filtering data with publish and subscribe

Direct link

Commit in my repository

It doesn’t make sense to me that any user can delete and check off public tasks of any other user. So I implemented a little tweak that allows only the task owner to do these operations.

Step 12: What’s next?

Direct link

Post-tutorial tweaks

While working on the tutorial, this way of accessing a text input seemed weird to me:

React.findDOMNode(this.refs.textInput).value

When reading the tutorial, I thought that this.refs.textInput.value should do the trick. Looks like SachaG feels the same about this, so I changed it.

I also noticed there’s an [open pull request]https://github.com/meteor/simple-todos-react/pull/7) to change React.render to ReactDOM.render, so I applied that too.

Tutorial Feedback

As I said above, the tutorial is excellent.

The structure of short and concise steps is clear and instructive. It contains inline snippets of commands that I can copy & paste, and they work. It contains inline snippets of codes with highlighted diffs that I can copy & paste, or manually modify. Every code modification is also an individual git commit, linked to GitHub, which makes it easy to compare what I do to what I should have.

It is clear that I can choose one of three tutorial (Blaze, Angular, React), but there is no clear explanation what it means, and what might be the repercussions of my choice. On the surface, the three choices are equivalent, but some “tutorial” links go straight to the Blaze tutorial (e.g. top nav-bar link, tutorial button from landing page), and the Blaze tutorial is listed first as “TODO App” (and not “TODO App With Blaze”):

This sends a message that Blaze is the recommended flavor, or maybe even default, but not in a consistent way, and with no explanation.

Also, what’s up with the “Official Meteor Tutorial” link in the Resources page linking to the install page, and not to an actual tutorial..?

While going through the tutorial, I found myself copying & pasting some React-specific stuff without really understanding what it is doing. I wonder how much React background is needed to start using Meteor with React. Is strong React knowledge a prerequisite? If it is – it should be clearly stated somewhere (e.g., at the beginning of the tutorial).

The “Running on Mobile” section says I can install the meteor mobile SDK’s by running some meteor commands. But when running these commands, I get links to other documentation about manually installing some other environments for mobile development. If these commands are deprecated, there’s no reason for the tutorial to include them anymore – just send me straight to the other docs…

Security-related Feedback

Insecure defaults scare me. I realize that it allows for superior developer experience, but I’m scared nonetheless. See also what KrebsOnSecurity has to say on default insecurity.

I think this is such a big issue, it deserves its own post later on. I’ll hold on a bit with that post until I know more, so please, do refer me to more resources about Meteor security. Some specific alarm bells that went off in my head so far:

• Insecure defaults are dangerous, because developers are lazy, and convenient defaults tend to remain.
  • When running and deploying my Meteor app, there was nothing warning me about my app being insecure!
• When platform creators (e.g., MDG) make conscious choices that are insecure, it might be telling about a mindset that is prevalent in the platform, the ecosystem, and the development processes. I don’t really know, I’m just raising my concerns…
• I can accept insecure choices that have good reasons. I believe that in this case the reasoning was “developer productivity” or something like that. I don’t think I’m ready to argue about the root reasoning. I do think that these decisions must come with BIG RED WARNINGS, and not little side notes in late tutorial steps.

I’d love to hear from users in the comments! How many Meteor users took notice of the security-related notes in the tutorial? How many remember to disable insecure packages in new projects? In what stage? How many have deployed insecure projects? Would it bother you if Meteor had secure defaults? (meaning you would need to implement publish-subscribe and methods when starting a new project)

Summary

Woohoo! I finished the tutorial! That was fun

Now what?

I think that while I go along with the Intro to Meteor Courser course, I’ll start working on my app. Anyone has input on the Blaze vs. Angular vs. React decision for my app?

Why MOOC?

I don’t usually take online courses to learn things like Meteor (or, more generally, development technologies). From my experience, “just using it to do something” is more efficient. But that experience is based on mandatory C++ courses in undergrad school 12 years ago, so it may not be very up-to-date .

The trigger for me in this case is the timing. The fact that the course started just when I started my learning process seemed like a lucky coincidence that I shouldn’t “pass”.

I think that if I wasn’t doing this documented learning process I would probably skip the course. Documenting somehow motivates me to cover more of the available learning resources – maybe so I can provide wider feedback?

About the course

This course is actually the third course out of six in a Responsive website development and design specialization that Coursera is offering, in cooperation with the University of London. I’m not taking the specialization, just this course, so I might be missing some background from the previous two courses.

It’s a 4-week course, instructed by Dr. Matthew Yee-King, from the Computer Department, Goldsmith, University of London.

Here’s the “about the course snippet”:

Of course, you can read this, and more about the syllabus on the course site.

My impression of the course so far

I completed the first week of the course over the weekend. It included watching videos about installing Meteor, creating projects, running them, and some mocking with templates and template helpers. Every instructional video was ~10 minutes long, with a short follow-up quiz to verify understanding (or listening, to be exact).

The final “week 1 assignment” included a bigger quiz and a programming assignment. The programming assignment involved creating a basic app (just like I did when I installed Meteor), and then performing some changes to the HTML, the template itself, and adding a simple template helper.

The approach to evaluation is interesting. For every step I uploaded a screenshot of my running app, and part of the course requirements are to review submissions of other participants. Each submission should receive 3 “crowd-sourced” reviews. I don’t think this is a good approach to evaluation, but that’s how it’s working in this course (at least so far).

The content so far is really good in my opinion. The instructor is clear and fluent. The rate of information is a bit challenging for beginners, though. I don’t know if this is related to the fact that I skipped two background courses, but I feel that we’re going through tons of new concepts very quickly, and it’s going to be hard to solidify the concepts that way.

I think I have a good grasp of the client-server architecture, but when it comes to the details of the client itself, it gets mushy for me. What’s the relation between Blaze, Spacebars, Handlebars, and who’s responsible for what? When using Bootstrap, how does it fit in the client architecture? Does it interact with Blaze in some way? I saw that Blaze can be replaced with React or Angular – what does that mean, and how does that affect everything else?

Summary

I’m guessing it’s too late to join the course now, if you’re interested, but there probably will be more classes soon.

I’ll update with further impressions as the course progresses.

Are you taking other courses in the specialization? Would you recommend it?