xentac

I helped edit the first 4 chapters. One benefit of the book is it's short. All the information you need is condensed into 150 pages.

It starts out being immediately applicable (Chapter 2: Write Tests First), giving you systematic methods to measure various happiness qualities. After that, it helps you define what would make your life happier. From there it talks about specific ways to address the types of problems people run into when trying to improve their happiness.

Throughout the whole book, it tries to relate the concepts to programming ideas (testing, specs, debugging, etc). This isn't a general public self-help book, it's specifically for people who program or are technically minded. That's what makes it unique.

If I had to knock the book, I'd say that some of the metaphors are stretched a little bit. Overall the concepts map well, but every so often you're kind of like, "huh... yeah, I guess those are the same things..."

Edit: Added something negative to say.

I'm not sure you actually understand my phrase 'quantifying their happiness'. It uses tests derived from The Feeling Good Handbook, Dr. David Burns and Beck Anxiety Inventory, Dr. Aaron Beck to track emotional well being over time.

It makes it possible to compare how you feel with various points in the past to track an overall improvement or regression.

This book is by a programmer, for programmers, to help them quantify their happiness and take action to improve it, instead of focusing on churning widgets (GTD) or whatever it is you focus on.

Oprius Software - Victoria, BC, Canada - Full Time, remote

Position: Chief Technical Officer

Oprius' Chief Technical Officer is responsible for the maintenance and development of the Oprius web-based software.

Oprius is a CRM web app designed specifically for individual sales people.  It is designed to be approachable by people without a lot of computer experience and yet still powerful.  It tracks contacts, appointments, calls, tasks, and emails; lets users create complex sales processes; and includes a powerful phone assistant for use during calls.

This position is a work-from-home/telecommute position.

Find out more and apply at http://oprius.theresumator.com/apply/ZuOK64/Chief-Technical-...

I know it's a little belated, but here's the code. I haven't written the blog post yet.

https://github.com/xentac/colorwar

It just reads mouse move events, so there are only so many per second. If you send me more events than I allow, I drop the rest of them on the floor.

That's actually not a bug, someone wrote a bot that plays in every position that someone else plays.

Not yet, but I plan on doing a little blog post about it and posting the code.

Yeah, I limit the number of moves you can make per second, but mice/multi-touch move pretty fast...

I did do some stuff to try and limit scripts. We'll see if they can figure it out.

Also, it's multi-touch enabled...

Written in Node.js, hosted on Amazon EC2, uses Socket.IO.

Try to make the screen all one color while your opponents do the same.

> 2) each version has permissions

Side-loaded apps still have permissions.

I agree on all your other points, though I don't know how a project like this could be made to work with the android market model.

I feel like the OP misconstrued things like "doesn't work out of the box". What he meant was, "I needed to install the package to get my video driver and sound driver working".

Generally Arch doesn't install something until you ask it to.

I think the comment meant that, apart from installing the package, everything else worked fine.

I would probably say something like, "isn't available after initial install" and that "you need to install all the packages you want to use".

It is one of the Arch philosophies that you don't need any packages on your system that you don't want to use.

You should have seen the community 7+ years ago! They've done a lot to make the community more friendly and inclusive.

I think this is a little disingenuous. The Arch developers do their best to make sure that nvidia and amd drivers work with new kernels.

Sometimes updated drivers are needed, but not released for months, and the developers have to make the choice between holding back the kernel update for that small minority or releasing it to the benefit of everyone not using that driver.

It does, but instead of giving you a library/API access, like Mercurial, it gives you command line access. I feel as though one is a little more black box than the other.

They can do interop at the level DAG level, but higher or lower level abstractions aren't really supported (hg branch information isn't accessible in git, git doesn't have access to mq information, etc).

I guess the big difference is the level of interaction. A Mercurial extension has access to all the functionality that Mercurial offers: applying patches, creating commits, history walking, etc. But it doesn't really modify the underlying representation of that data (queues store their data in the working copy, for example).

Git doesn't give you access to its functionality but instead gives access to its data model. Stashes are just references, commits are created or destroyed at will, notes are just objects that point at commits and are stored in a different set of references, etc.

You are correct. They aren't a linear history. In fact, the key is the @{#} syntax (man git-rev-parse). Each stash commit is a single commit pointed to by a ref/stash reference. Because of the reflog, we can see what ref/stash used to point at, that is @{1}, @{2}, etc.

Git and Mercurial both suffer from this "problem". Because manifests/trees must have contents (file hashes) to exist, you can't track an empty folder.

I suppose git's tree objects could point to the empty tree to record an empty folder, but most of the git code is comparing file blobs not trees.

Fair assessment. This is where my bias towards git shows through. I use git and understand what it's capable of and why mercurial does it differently. The opposite isn't true.

If you give me some examples, I can probably roll them into a followup post later on.

When I was twelve, I decided to do that. No one else thought it was as good of an idea as I did...

These days I don't reserve 40 days to give it up, I give it up all year round!