I've had the idea for WritePhobia for a few years now. In fact, the idea first came to me about a decade ago while I was listening to the Radiolab episode "You v. You". That episode featured a woman who was struggling to quit smoking. She ended up making a pact with her friend where, for each cigarette she smoked, her friend would take $5,000 from her and donate it to a hate group. She never smoked again.

That works because smoking has vague, long-term negative effects. Smoking a cigarette today won't kill you. Smoking cigarettes for twenty years might. Her solution was to make the negative effects of smoking immediate, obvious, and painful.

I figured the same approach could be applied to any habit. If you want to write more often, one thing you can do is to make the negative effects of not writing immediate and obvious.

So that's what WritePhobia does: you set writing goals for yourself ("500 words on weekdays"), and for each goal you miss, WritePhobia immediately charges you a dollar and donates it to a writing charity.

So far WritePhobia has a handful of users and it's working great! I plan on building more community features into the app as more people sign up. If you're reading this, and interested in writing more, go sign up for WritePhobia. It's free... if you never miss a goal.

Today I'm launching Scrumsheet, a Scrum workflow app. Unlike other apps, Scrumsheet keeps all your data in a single Google Sheet.

Does this count as a "serverless" app? Probably; if you consider apps built on Firebase to be serverless, then Scrumsheet is too.

What excites me most about this project is the fact that I don't need your data to give you a good Scrum app. Asana, Trello, Pivotal – why do they need to know about your tasks and todos? Why do they need to store them in some centralized server?

By using Google Sheets as a Database, the user gets to control their data fully. If the app ever stops working, you can continue to use the Google Sheet. If one person on your Scrum team hates the app, they can use the Google Sheet. If you ever decide to export all your data, great – it's right at your fingertips! You can also import a ton of data with ease; it's just a spreadsheet.

How it Works

Scrumsheet is an Electron app. I quickly discovered that the Google Javascript Client Library does not work in an Electron environment, so all API requests must be made via REST/HTTP directly. Fortunately, the Google APIs are easy to work with.

Authentication

The first challenge is setting up Google Authentication. Normally, the client library would help you with this, but instead we need to use HTTP requests directly.

Using Google's OAuth guide works, but with one trick: in an Electron app, the "redirect URI" is meaningless. Therefore, when managing the authentication window, you must add some event listeners to your new Electron BrowserWindow to capture redirects and trap the authorization code.

SheetDB

I wrote a lightweight Javascript library that keeps the Google Sheet in sync with the application state. This helper class needs to be able to manage a handful of tasks:

• Read worksheets in a spreadsheet, parse their data, and determine if the worksheet contains "People", "Stories", "Standups", or "Retros".
• Ensure worksheets with a given schema (eg, "ensure the People sheet with the columns: id, name, email, role).
• Append a row/record to a worksheet
• Edit an individual row in a worksheet, by predicate
• Reorder rows in worksheets

Reading worksheets and parsing them is a simple task; appending rows is simple too. We simply use the Google Sheets API for these tasks. The more interesting item here is what happens when you edit a row or reorder it.

Google Sheets' API provides a 'batchUpdate' endpoint, which works similarly to database transactions. This is very useful when running the combo action of updating a story's status (ie, moving between board columns), while also changing its ordering (ie, moving up or down, placing between items). When the user takes this action, the app builds a batchUpdate that first edits the row's cell values, and then moves the row to the proper position. Just like database transactions, this will rollback the entire editing process if there's a failure anywhere in the batch.

SheetDB also interacts with the Google Drive Comments API to power the "discussion" features of Scrumsheet. When you add a comment to a scrum project, that simply adds a Google Drive comment to your spreadsheet!

UI Around Data

It's a common adage that most apps are simply CRUD UI wrappers around databases. Scrumsheet, to me, is the purest expression of that adage. We start with a database – doesn't matter what, but in this case it's a Google Sheet – and then wrap its functionality with a beautiful UI.

The difference here is that, unlike with a SQL database, using a Google Sheet allows the user to interact "safely" with the data both through the UI and through the database directly. Sure, some developers do maintenance through a SQL prompt, but it's rare to be able to do your daily work interacting with data directly – no longer!

Get Scrumsheet

Visit Scrumsheet's homepage to learn more and download Scrumsheet.

When you just need to Slack from the command line: "Slacker" is a simple weekend project CLI interface to Slack. Slacker isn't a production-ready tool, but perhaps it will be one day. If you live in tmux or the command line like me, you might find this a fun, curious little project.

Check out Slacker on github

The Botanist -- a long-term side project of mine -- is a 2D fantasy RPG intended for release on multiple platforms, including web, Android and iOS. The game features an immersive universe with deep supporting mythology and lore; a relative rarity among mobile games.

The Botanist has its own site and blog, as well as a post on the project's motivation. Releases mid-2016.

Perhaps the only of its kind, morsecode.me is a live, online Morse code radio; the most arcane of chat rooms. Users can communicate with one another only by keying Morse. Fortunately the site also comes with a cheat sheet and live translation.

I built morsecode.me after I learned Morse and later realized I had nobody to geek out with. The morsecode.me community continues to thrive, and I still actively maintain the project.