I'll second that. Having only ever used private CVS before in my life, I've never published anything open source ever. In fact, after hearing everything I have about Git, I went ahead and purchased the $7 plan so that I could give it a try, but without having to share anything publicly.

That said, as soon as I started checking code in, I ended up creating 2 (very small) projects and sharing them publicly, as they weren't anything close to even remotely core to the other product that I'm building (that I bought github for), and it seemed silly to use up 2 of my private projects on such trivial applications.

This is exactly the behavior that Github encourages, and as someone who hasn't contributed to open source in a very long time, it was interesting to see how quickly Github re-converted me.

Did your small projects gain any traction?

I just pushed them last week, and they're what I'd call 'entry-level-code' at best, so no. I honestly don't expect them too, but if someone were googling for 'tornado webserver administration', they might find my code, and it might be useful. Beyond that, I don't really have much greater expectation.

Edit: http://github.com/bmelton is the location of the projects. There are currently 2 up there, both in a very fledgeling state:

http://github.com/bmelton/Braveicon is a simple favicon library that will accept a URL as a parameter and find the favicon for a given url. The URL can be fully qualified ('http://news.ycombinator.com) or loose (news.ycombinator.com), and braveicon will step through all of the W3C valid means of specifying a favicon and return the URL.

http://github.com/bmelton/Twister is a server administration framework for starting / restarting tornado web server instances. Since Tornado is typically managed by your app, the app must be (very slightly) modified, but this reduces having to 'ps -ef | grep [myscriptname]' multiple times to kill your app, and gives you 'twister.py restart' instead.

You might want to edit that comment to link to your project since the comment will probably now rank higher than your repo for that hypothetical Google user.

LOL. Done. Hopefully the YC gods don't frown too negatively on my 'advertising' my projects on HN.

For anyone looking for plain JavaScript base64/ascii85 codecs, I wrote a pretty decent (quicker than what I could find, concise & readable) one about a year ago (would need to be modified very slightly to be a node/commonJS module, and could perhaps be a bit shorter with a different style of error handling):

http://pastie.textmate.org/pastes/695197

A slight variant of this base64 codec (I believe suitable as a node/commonJS module) is also used by the http://js.io/ project: http://github.com/mcarter/js.io/blob/master/packages/std/bas...

Sorry, it doesn't work on binary data:

    node> var buf = require('fs').readFileSync('./tests/data/data-png.png');
    node> require('jacob.js').base64.encode(buf)
    Base64CodecError: Input contains out-of-range characters.

Also node.js now has its own base64 encoding and decoding functions right in Buffer, so there is no longer need for any base64 modules.

Well okay, it's intended to work in the browser (note: this was also written before Node had any decent binary data type; I haven't really been keeping track, does it now?) and so "binary data" is just a string where each byte is the lower byte of one character. It could pretty easily be modified to take advantage of better data types in contexts where they are available (or if someone's using a string for "binary data" where two bytes of data are stored in each character, modified to deal with that).

No, it still does not!

I guess I should just go look (though I haven't been using Node for anything for about 8 months), but what does it do for binary data then? When you load a png file, what do you get?

Just char * to a memory block abstracted as the Buffer class.

Peteris: Any particular reason you pushed the book reviews to GitHub, instead of posting them to your blog?

Yes, I could track my own progress easier this way, going chapter through chapter. Just writing a blog post wouldn't feel as productive. Writing long blog posts is very difficult. But pushing a review of a chapter to GitHub every other day is really easy. That's why I also usually split my articles up in n-part series, it's very difficult to write long articles.

Thanks, that makes sense. I don't use GitHub, but I suppose I'll have to start, now, just to get your reviews. Just think: you're the killer app.

I like the image stuff. May fork it when one of my projects matures.

good for you, and yes i agree totally. something about making it public forces you to take a tiny step forward. my first push to github here, for the record http://github/com/irv/tarsnap-backup