In the month since, I was still running it on my laptop. To make it work best, it should run on a dedicated server. That way, it would push emails even if I’m away from my laptop, and I could read them on e.g. my phone. But before committing to setting this up on Amazon EC2, I wanted to be sure I liked the approach.
Maybe you want to contribute something to Racket: You’d like to improve the documentation, or you’d like to add a small feature.
Maybe you’re comfortable with Git, but haven’t made a pull request before.
Maybe you’ve made a one-off pull request, but haven’t tried to contribute to the same project over time and stay in sync with the upstream project.
If so, you may find my guide helpful. I was hopelessly confused about how to handle the branches and merging. After I figured it out, I wrote this down in a Gist as a note to my future self. Today I figured I’d dust it off and make it into a blog post.
Racket parameters let you manage stateful global variables in a way that feels more functional and is also thread- and continuation-safe. A convenient parameterize form lets you change and restore them. I’ll discuss this and show how I map parameters to a configuration file.
You don’t need to migrate data when you buy a new computer or mobile device.
You don’t spend a bunch of time updating apps for security or improvements. Doing so may be easier on a mobile device than on a desktop. But there are days when my phone does more work updating apps than me actually using it.
Synchronization sucks. Using multiple native apps with local stores requires synchronizing state. Essentially this is N/A with a web app because the data is stored in one place. (Note: Caching doesn’t suck; just synchronizing.)
Developers can iterate and experiment — “release constantly”. This may sound like it’s an advantage for devs, but to the extent it makes better apps and saner feature accretion, it’s good for us, too.
Easier to hack, by which I mean customize for individual needs and preferences.
Easier (and generally safer) to use hacks created by others (in the form of browser extensions).
So great. But obviously the Google Reader shutdown brought me up short. Shook my faith. Am I wrong to prefer web apps?
On reflection, there are two reasons why it’s still OK to prefer web apps.
I wanted Frog to provide a “preview” feature: Launch a local web server with a version of the site, and open a web browser.
This local web server simply needs to serve static files. No server-side applications. (Not even features you’d likely want in a production static file server like gzip compression or If-Modified handling.) It just needs to start quickly, and preferably not be a lot of work to code.
Although I’m using Google Analytics for this blog, I’m not using FeedBurner. But imagining what feed readership stats I might want, I came up with a short list, and thought about how to get them without FeedBurner.