Back dat platter up

"Time to install Windows 8 on this old laptop. Oh crap what will I do with my old docs?"

I finally came across a backup service that was cheap and from a company I can be sure will be around for awhile. I'm talking about Amazon Glacier. You may or may not have heard of it, since it was released just two months ago, and it's heavily developer focused. Meaning there's an API but no official GUI or console.

Thankfully there's FastGlacier which is a free-for-home-use Windows program to make uploading and downloading easy. I should mention Amazon puts a fee on downloads that surpass 5% of what you've stored there; the service is meant for long-term infrequently-accessed archival storage, completely unlike Dropbox.

There are a few command-line programs for Linux. Look on github or this Quora thread. I tried one of them, glacier-cmd, but couldn't figure out how to do directory uploads other than "find | xargs glacier-cmd upload". Maybe I just answered my own question. Oh well. I ended up copying my files to Windows first and then using FastGlacier's nice and intelligent GUI.

The service is extremely cheap for typical home backup. Uploading 1000 files costs 5 cents, with a recurring cost of 1 cent per GB per month. For me, I stored about 20 GB of files, many of them tiny metadata and random small text files. It came out to an upfront cost of $4.08, and I'll pay $2.40 a year(!) to keep those files there. That's literally pocket change. I can do pickup at the Thai restaurant instead of delivery and make that money back and then some.

Compare with another well regarded backup service, Backblaze, which costs a flat $3.96/month for unlimited storage. I haven't used them but I hear good things. I'm sure they include a nice GUI too. But to justify the cost I'd have to store nearly 400 GB first. I'm sure a lot of people do store that much data. Someday when I have Ultra-HD family videos that I want to back up, I can shop around for new options. But by then who knows what companies will still be around; maybe computers will be obsolete and we'll encode all our data in DNA converted to dark matter.

Day 12

I've been working on a new project lately. Since I believe it'll demotivate me to give away any details or raise any expectations about it, I'm just going to say I'm on Day 12 of it.

Actually, looking back on the past 12 days, I am pretty disappointed in the progress I've made. The first 5 days or so were great, then I fell into the trap of moving very slowly. Probably because I have no accountability for this project. That's why I'm writing this blog post. I hope to make blogging a regular occurrence and eventually show some real progress on the blog, once I have something cool to show.

Maybe I'll even keep a gigantic private post, and only make it public after the project is finished.

lolcommits

Today I started to use this great little program called lolcommits, which takes a webcam picture as a hook for every git commit. It's nice to have a record of my face while programming!

Initially I wanted something to help with accountability, so each week I could show people my progress. I'm not sure if lolcommits is that "something," but it's sure fun to have the photos!

A couple of my favorites from today:

Looks a bit mischievous. "untested" indeed

Facial expression seems to match "do not bother"

UPDATE July 7: After 12 days of using lolcommits, I uninstalled it. The photos mostly looked the same, and the 5-10 second delay after every commit was finally getting on my nerves.

Setting up GNUstep in Windows

GNUstep is a wonderful project that aims to replicate Cocoa APIs for a variety of Unix-like OSes and Windows. In effect this lets you get started playing with Objective C and a coding environment similar to Xcode, without owning a Mac or resorting to illegally running OSX on non-Apple hardware.


I've only just begun, but the whole GNUstep project seems more solid than I expected (although about as ugly as I'd expect from a GNU project).


It wasn't completely clear where to begin, since there are several different pages talking about GNUstep, ProjectCenter (the visual project builder), and Windows. So here is what I ended up doing to get started. I'm on Windows 7 64-bit.

1. http://www.gnustep.org/experience/Windows.html has good instructions on getting started on Windows. (Unfortunately to use ProjectCenter, you can't use the latest GNUstep versions since they're incompatible. As of this writing, GNUstep 0.29.0 stable was released very recently in Nov 2011, while ProjectCenter 0.60 was released December 2010. Since I mainly cared about using ProjectCenter, I chose the GNUstep versions that were released prior to ProjectCenter 0.60.)
2. Download from http://ftp.gnustep.org/pub/gnustep/binaries/windows/
1. gnustep-msys-system-0.25.1-setup.exe (July 15, 2010)
2. gnustep-core-0.25.0-setup.exe (May 15, 2010)

3. gnustep-devel-1.1.1-setup.exe (July 15, 2010)
4. SystemPreferences-1.1.0-1-setup.exe
5. gorm-1.2.12-setup.exe
3. Install the exes in the order downloaded, shown above. I used the default C:\GNUstep target.
4. Download ProjectCenter 0.6.0 tar.gz from http://ftp.gnustep.org/pub/gnustep/dev-apps/ into e.g. C:\GNUstep\home\Andrew
5. In your Start menu, run "Shell" under GNUstep. (I renamed this to "GNUstep Shell" to be more sensible for Windows 7 start menu autocomplete.)
   Note: Non-administrator users must right-click and choose Run as Administrator (thanks Winston Lee).
6. Install ProjectCenter
1. Untar ProjectCenter--from the shell: tar xzvf ProjectCenter-0.6.0.tar.gz
2. cd ProjectCenter-0.6.0
3. make
4. make install
7. Run ProjectCenter from the shell (just type ProjectCenter)
8. Run gorm from start menu.
9. Follow tutorial at http://www.gnustep.org/experience/PierresDevTutorial/index.html
1. ProjectCenter doesn't recognize gorm for some reason, which is why I have to run gorm separately.
2. Also, builds don't work from within ProjectCenter, but thankfully GNUstep generates makefiles for everything, so from the GNUstep shell you can just type "make" inside your project, and it'll generate a ProjectName.app directory for you. Inside that directory, you'll find Windows binaries to run the app.

I'm really excited about this, because although I do intend to do a bit of development, and of course builds, for iOS apps using a Mac, GNUstep gives me a bit more choice where I want to do development from.

One more thing: there are other projects that go along with GNUstep. See https://github.com/ANindie/cocos2d-GNUstep for a work-in-progress cocos2d port. Given that cocos2d-GNUstep is written and tested on Ubuntu, maybe I'll want to use Ubuntu instead of Windows for this stuff.

backbone.js nice new logo

I just noticed the new backbone.js logo (edit 2016-12-05: old link was http://documentcloud.github.com/backbone/). Very professional looking!

Old logo:

New logo:

Brainstorming Aesthetics

Yesterday I posted[1] about "writing it down" as an obvious and simple methodology that should not be skipped. Well, looking through my EverNote notes I realize I did start writing things down at the beginning. One problem with those notes, though, was that they're just stream-of-consciousness, mixing different levels of detail in too many words. Reading the notes from start to finish makes them understandable, but they did not serve to add structure to my thoughts. Instead they only served the purpose of leaving a record.

A better, structured brainstorming approach does the following things:

1. Uses concise wording.
2. Uses symbols and pictures, avoiding prose, when appropriate.
3. Breaks out levels of detail into separate groups. Programmers should be adept at this.
4. Lays out ideas to facilitate reorganization. One reason electronic brainstorming is very powerful.
5. Gives multiple "entry points" for re-examination. If your brainstorm requires reading from top to bottom to make sense, then it's not as good as it can be. More entry points mean more opportunities for additions and updates in the future.

As an example of #3, breaking out levels of detail into separate groups: if a server needs to generate a token and send it to the client as part of some process, that's all I need to say for the top level. How the token is generated may belong to a different level of detail. Writing both together muddles the intent, and makes the notes difficult to read.

That's all I can think of now. If you have more suggestions, let me know.

[1]: http://blog.andrewshu.com/2011/10/write-it-down.html

Write it down

Recently I was thinking through a programming problem in my free time, for several days. (Authorization of purchases and content delivery.) After a week passed, I knew I had considered all the different cases, but couldn't get the whole flow pictured in my head. At each step of the authorization process, different issues come up where either a legit customer may lose data, or a pirate gains unauthorized access to content.

I was reluctant to write things down on paper (or electronically), since I felt I needed many changes to get it right. Writing it down would only add more overhead as I changed the design around. Unsurprisingly, I have a similar sentiment towards test-driven development, where in many cases the project being built out is too uncertain in requirements, and new features may be desirable later on, such that writing tests up front only adds overhead later on. Unit testing in general, though, is highly desirable.

After the week passed, I was at the point where I wanted to write down the design, so I could pick at it without spinning my wheels thinking about the same scenarios over and over. As you've probably guessed, writing it down helped me immediately see a couple problem spots and get the design down from start to finish. It also helped to have visual separation between the components of the process. In my head I would jump back and forth between components, like initial purchase versus restoring purchase history, trying to think "where can I reuse this security token and when do I need to generate a new one?" and things like that. Writing it down, even in just simple numbered lists, helped me split up concerns and stop wasting mental energy juggling different pieces.

The message of this post is hopefully obvious to most people, and even for me it is something I've learned and relearned many times over the years. It's just times like these, when my pride creeps up on me and makes me believe I can handle thinking all the way through moderately complex designs in my head, that I disregard an obviously useful methodology.