Showing all entries for: February 2016

Plain Text Notes

After bouncing between various note-keeping apps, I finally settled on a very simple solution that is flexible, cross-platform, freely available, and will surely stand the test of time: plain text.

Journal entries. Recipes. Work log. Grocery lists. Things I need to quickly pull up on my phone when I’m on the go. Ideas for gifts I want to buy my wife and kids. Anything, and everything. Digital notes have been an absolutely essential part of my personal and professional life. What I use to manage the notes essentially serves as my secondary brain.

Without putting a lot of thought into it initially, I started out using the stock Notes app on iOS and the OS X, which worked until I took a detour into the land of Linux and it suddenly became annoyingly painful to access my notes. In my frustration, I began thinking about my mobile needs. If I were to move away from iOS in the future, even if temporarily (be it Android or something else), what would I do then? I often need to access my notes when I’m on the go, so this was a big concern.

It was clear that I needed a cross-platform solution that could withstand my (admittedly erratic) computing habits over time. I don’t think vendor lock-in is an acceptable option for me.

Runner-ups

Evernote

Evernote was the first contender, but I ultimately decided against it because, like Apple Notes, it stores notes as Rich Text. I really dislike WYSIWYG editing, and that is the bread and butter of Evernote. Not necessarily a bad thing, but not for me. I’ll admit that being able to embed media and adding attachments to notes is really nice though.

Simplenote

Simplenote was next in line, and I almost went with it as it was very similar to what Apple offers, but notes are plain text and the service is cross-platform due to being web-based. However, there were some concerns that kept me at bay.

3rd-party app selection. I don’t like being tied to the web app and wasn’t completely happy with the available 3rd party clients (I did like the first-party iOS app, however). There is a script that can be used to sync notes to a local folder, but I didn’t really want to have to go through that, and more importantly, I wasn’t confident enough that the script wouldn’t wipe my notes on accident, or be maintained long enough to withstand any API changes that Simplenote might introduce in the future.

Limited ways to organize my notes. I really want better organization for my notes, such as a “Work” folder for work-related notes, a “Journal” folder for journal entries, and so on. I know I could use tags instead of folders, but that leads me to my next point…

Is it future-proof? What happens if Simplenote shuts down before I no longer need to keep notes (in other words, before I die)? Simplenote does have an export option, but it gives each note a crazy, random filename and the tags don’t seem to be preserved (there goes any work I put into tag-based organization).

Evernote is pretty great about allowing you to organize notes into separate “Notebooks”, and I’m sure there are other services that do something similar, but the other two points mentioned could easily apply to just about any app or service.

The thought of relying on my chosen note-keeping to outlive me makes me a little uncomfortable, so the only remaining option seemed to be manually handling the notes myself via locally saved, old-fashioned plain text.

The Setup

All of my notes live in a single, top-level folder on my computer’s hard drive. I have sub-directories for Work, Personal, Journal, Projects, Media and Attachments. The notes themselves are just plain text files, saved as Markdown.

Sync and backup

Since I need to be able to access my notes from multiple devices (my laptop, desktop, and phone), syncing is a huge requirement for me. I already use Dropbox, so my top-level “Notes” folder lives in my Dropbox folder. Any changes I make to notes are automatically synced (and backed-up online).

If Dropbox ever goes away, or I want to stop using it, I can just turn my notes folder into a Git or Mercurial repository and host it privately on GitHub or Bitbucket. I’m tempted to go this route now for the ability to track changes and revert notes to an older state (if necessary), but what’s holding me back from this approach is mobile. While there are many great mobile apps for viewing and editing Markdown files in a Dropbox folder, I haven’t yet found the same for a hosted repository.

Editing and viewing

This is where “everything as plain text” really shines. I spend most of my day in a text editor (BBEdit), so it’s just comfortable for me to edit my notes in the same app. BBEdit also has a nice Projects feature, so all I need to do is open Notes.bbprojectd and all my notes are there, nicely organized in the sidebar. I can now take advantage of BBEdit’s robust search capabilities for all of my notes, which is a huge plus.

As far as mobile goes, all I needed was a text editor that could link to Dropbox. I’m pretty happy with iA Writer, but there are other options as well (some of which are free). My requirements for mobile aren’t that extensive, however, as I rarely do any significant editing of notes on my phone, but I often need to view them.

Media and attachments

This is one of the big selling points of Evernote, and is surprisingly easy to duplicate with my current setup. In my top-level folder, I have sub-folders for Media and Attachments. Since I save my notes as Markdown, I can easily embed images, videos, and links as I would when writing a blog post.

![My Image](../Media/2016-02-12-my-image.jpg)

In fact, if I really want to get fancy, I could turn my notes into a private Jekyll blog, but I digress (that’s probably overkill anyway). In any case, BBEdit has a Markdown previewer (as well as iA Writer), so I can just use the built-in viewers when I want to see embedded media and links.

Conclusion

All in all, this plain text setup has been working out really well for me, and I don’t feel like I’m missing out on any features by not going with a dedicated app or service. If you’re in search of a note-keeping service, or feel like a change, I recommend giving the plain text approach a shot!

Ignore the Noise

Whether you’re new to the JavaScript ecosystem or have some experience, unless you’re super-human, you’ll inevitably become overwhelmed at the sheer number of frameworks, libraries, build systems, preprocessors, template engines (the list goes on and on) that are available.

What’s worse, as you put a significant chunk of time into a certain stack, there will inevitably be other libraries, frameworks, and tools that gain more popularity than the ones you chose, and likely brand new projects that became the shiny new thing while you were busy getting things done. Before long, you start to feel like you’re suddenly becoming irrelevant.

Joe Gregorio argued in 2014 that we should abandon all frameworks in favor of plain HTML+CSS+JS in his zero framework manifesto:

I think it’s time to rethink the model of JS frameworks. There’s no need to invent yet another way to do something, just use HTML+CSS+JS.

The landscape has only gotten more cluttered since then, so I don’t think the web development community as a whole agrees, probably because that approach may not be practical for everyone and for every project. Still, I think it’s a good starting point. More on that later.

A couple of years ago, I invested quite a bit of time into Backbone.Marionette, and once I had some breathing room and took a step back, I saw that Angular was actually the cool kid on the block. I also used Less and Handlebars (for CSS preprocessing and HTML templating, respectively), although tons of shops prefer Sass and there are many other popular alternatives to Handlebars. It’s easy to feel like you’re not keeping up, and that your skills will soon become irrelevant if you’re not sprinting at top-speed, 24 hours a day. Unfortunately, no matter what you do, at least when it comes to web development, you’re going to be “behind” in one way or another.

All this to say: it doesn’t matter. Ignore the noise.

But that begs the question, how can you determine what path to choose when there’s this vast sea of choices out there? Fortunately, depending on your personal situation, there’s a way through this.

Your Own Projects

For personal projects where you have complete control over your technology stack, I recommend starting with just plain HTML+CSS+JS (which have standards that don’t become outdated very frequently), and only add libraries that fit your needs—as needed. In other words, let the requirements of your project determine its dependencies. If you do want to go with a full-blown framework, take a look at some of the more popular and stable options out there and just go with the one that matches you and your project best and proceed full steam ahead.

Don’t worry about falling behind. Just do some research, choose something, and move forward with with your decisions. The important thing to remember here is that you don’t need to be a pro at everything, or worry if you chose the best thing out there (that’ll change anyway, and probably next week). You’ll end up learning a ton about your chosen stack and that experience alone will be valuable.

I mentioned research, but it’s worth emphasizing. Last year, Jimmy Breck-Mckye wrote about the “State of JavaScript in 2015” and cited “framework churn” as a major problem. Angular, one of the most popular front-end JavaScript frameworks, was used as an example:

At the close of 2014, it’s difficult as a JavaScript developer to back a particular library or technology with confidence. Even the mighty Angular, which seemed set to establish itself as the One True Framework of Single Page Applications, looks destabilized by recent events.

I’m not in the Angular camp, at least not currently, so I have no comment on that in particular, but it’s an interesting perspective from someone who obviously was.

I personally tend to favor the “pick and choose small libraries to fit your needs” over the the “one size fits all” approach of monolithic frameworks, but your mileage (and requirements) may vary. If you do go the monolithic framework route, it’s worth making sure what you choose is actively maintained and has a healthy community around it—unless of course, you plan on maintaining it yourself, which is probably not likely.

Work Requirements

If you’re employed and your company has chosen the stack for you, then you already have your answer. If you don’t have a say-so, you don’t need to worry about drowning in choices because you won’t have one! Spend time learning and improving your skills in Marionette, Angular, React, Backbone or whatever it is your company uses. With your own time, you can choose to develop other skills or improve on your work-mandated ones.

On the other hand, if you’re in a position to have some say in these kinds of decisions, then tackle it as you would with your own projects. Research the actively developed, mature options out there and choose the frameworks and/or libraries that fit your project and team best, ignoring the others (no matter how new and shiny they are) until there’s a problem you can’t solve—or solve well—with the decisions you’ve made.

Developer for Hire

The more difficult scenario is if you’re trying to build up your skills in hopes of getting hired as a JavaScript engineer, and need to decide what the best course of action is to achieve your goal. Unless there’s a specific role you’re targeting, in which case what to learn should be a little more clear, I recommend starting your own open-source project, making it public, and stick with it through completion. When you’re done, you can always choose a different stack for your next project, swap out the pieces that didn’t work well for you, and go from there. Over time, you’ll gain some valuable experience and you’ll not only know enough to be relevant, you’ll be agile enough to adapt to any other stack that’s thrown your way by a future employer. Without a doubt, doing is the best way to learn anything, and that absolutely applies in this field.

Make a Choice

Today, as JavaScript developers, we are flooded with choice. Fortunately, if you can block out the excessive noise and commit to making some decisions, you’ll find that having an abundance of choices can actually be a benefit: there is something for just about anyone, and any project you can think of. The worst choice you can make is no choice at all, allowing decision paralysis to prevent you from getting any meaningful work done out of fear you’ll make the wrong choices and waste a bunch of time.

Don’t fall into that trap. Make decisions. Stick with them. Adapt as needed. Keep moving forward. That is how to stay relevant as a JavaScript developer in today’s tumultuous environment.