I fly SFO <-> JFK very often. VX34 there and VX27 or VX29 back are my rides of choice, since I hate layovers and prefer redeyes. The wifi is passable too (don't try to SSH over it, though).
Operators and Things, a (supposed) first-person account of a schizophrenic who recovered from the condition and wrote about her experience. The second half of the book is where it really shines, since the author attempts to analyze her experience as a window into the inner workings of her cognition: how it broke down, what she experienced when it did, how it recovered itself, and what led to it. Since the author is anonymous, and talking about one's mind is very introspective, it's hard to take away real science from the book but I found it fascinating nonetheless. While I really dislike pseudoscientific explanations of brain functioning, after reading this I took up the idea that the conscious mind is more of a time-slice scheduler and message-passer than where the actual computation is done. So concentration is about controlling your unconscious indirectly, like training a puppy how to play fetch: you give it suggestions of what to do, and ignore it when it doesn't do that :).
I'm linking to the Amazon page, but IIRC the book is old enough to be in the public domain and there is a free text version somewhere.
A lot of people here are commenting on GitHub being 'overpriced' or 'greedy.' TPW did an interview a while ago that has insight into why their pricing structure is the way it is. It's a pretty interesting read:
(search for 'which metrics') to skip to the pricing part).
Money quote: "That’s like buying a car based on how much it weighs. It’s irrelevant."
I may be biased since GitHub does a lot to foster the developer community in my area (I nabbed a sweet contracting gig at one of their drinkups), but I'm perfectly happy with their pricing.
So I'm not sure if I understand correctly, but let me put it this way: with a little more git craziness, you can crack apart a commit and separate it into two. This is good if you did two unrelated changes to a file, committed that, and realized you wanted two separate commits later.
The basic process is:
1. git rebase -i, and change a commit to 'edit'
2. git reset HEAD^, this 'undoes' the commit and leaves the changes in your directory as if you had written the code but hadn't committed it yet
3. git status
4. git add <filename> -p, this lets you add commits to your file a chunk at a time. first, add all the commits as a part of commit one. skip the parts you want for commit two.
5. git commit (do not do git commit -a here) and write the message for your first commit
6. now your working directory will be all the changes for commit two. git commit -a if you want all of them
7. git rebase --continue
This page[1] has a more concise answer, but leaves out the git commit -p part.
Note that if you mess up in rebase-land, you can always git rebase --abort. If you come out of the rebase and everything looks lost ('oh god I lost my data!'), use git reflog and pull up the hash of where you were before. Your data is still there.
Another note: if your commits are already separate, you can use rebase to selectively squash and reorder them. Read the manual on git rebase -i, if you rearrange commits and only squash some I think you'll get what I'm talking about.
> However, I could use rebase to start combining loosely related commits, trading the time resolution for clarity in the commit history.
In general, your commits should be the smallest atomic operation that makes sense. When people talk about 'clean history,' they're talking about working in the awesome workflow git provides:
1. Write half-written broken code.
2. Fix that code up.
3. Add some more onto that.
4. Fix a typo!
5. Forgot to update the README.
Now, you could push that to master, but then the main master is littered with commit messages like 'oops' and 'typo.' Instead, you can rebase 5-1 onto the latest master, squash them together, and have one 'nice' commit that only has the cleaned up final changes.
This is one of the most powerful things about git: in a private repo, you can commit all kinds of garbage and half-written stuff without caring. When you want to make your stuff public, rebase and squash, then send it out. Be careful though! Only rebase your own private branches, or you're gonna have a bad time™.
> The event-driven concurrency model makes it easier to write servers without worrying about race conditions and thread locks
Well, no, you're just writing the locks yourself in an ad-hoc way. Every time you have a callback calling another callback, you have a lock and all the race condition/deadlock issues associated with that. Of course, writing an application that doesn't have complicated synchronization requirements (streaming fileserver) can often require less boilerplate in an evented system. However, you run into a catch-22 here: by definition it's an application with fewer synchronization requirements, so you'd have to use fewer complicated locks in a 'heavy thread' implementation as well :).
Ultimately it's an engineering tradeoff problem, and you have to weigh lightweight node-style cooperative multitasking with the ability of a traditional thread system to better handle highly complicated scenarios.
Or you can be Russ Cox and argue that this is a false dichotomy[1] and that we should all be using CSP. I'm in that camp.
A SAT solver[1] can automatically figure out a range of acceptable solutions for your conditions. 'I want this goal, is there a way to make that happen?' Security people love this. SMT solvers are even crazier[2] and can automatically determine solutions to linear equations or inequalities (this comes in handy when analyzing loops). Z3 has an online version at [3].
Also, if you have a lot of nasty cascaded if-statements, a K-map[4] and espresso[5] can reduce those down to a minimal set of branches. Note that fewer branches means fewer branch prediction penalties, which means faster code!
I meant a physical wall clock, not an app. I suppose I could mount and iPad on my wall and run the app, but I don't want to spend several hundred dollars on a clock that will sue me.
Mildly unrelated, but I wanted to point out the awesomeness of the K-map[1] for handling simple minimization problems like these.
Unfortunately, once your dimensions get large it becomes difficult for humans to visualize the optimizations, which is where Espresso[2][3] comes in handy.
