After a cross country move to a remote coastal town, my wife and I were left at our destination with only a small portion of our possessions. The rest of our stuff was making its way there with the hired movers.
I got into a strange situation where I needed my Mac Mini for something, but it was still trying to connect to an old wired connection instead of the new wireless one. I didn't have any of my cables or display adapters -- just a keyboard.
Long story short: the Mac Mini has an internal speaker, and OS X comes with a vocoder shell program. I managed to boot into the OS and launch terminal, and blindly typed commands into it, piping the output to the vocoder app until I got things working.
I personally have been using it to document the more complex code that I write -- that is, the code that I have the most trouble explaining to others. I'm quite happy with the results for my collision detection library.  The library itself serves as a basic tutorial on collision detection, and I've used it myself for reference when I step away from the code for a while.
Definitely feels like an improvement on Cuba! I'm not a huge fan of the `is` method here, though. I feel like you could get the same thing from a terser DSL if you treated HTTP methods as terminators and only allowed `on` to filter the path.
This is a great way to explain it. My wife used to suggest that I work on a side project of mine when I had a few free minutes here or there. I had a hard time explaining why it wasn't really worth the effort unless I could work on it for at least an hour. She trusts me on that, even if I didn't do a great job explaining why, but it seems like this explanation would make the reasons easier to convey.
In my years of mentoring and tutoring, I've run into a number of students of programming (and, indeed, teachers) with the same problem.
Programming is about problem solving first, and teaching programming is about teaching someone to look at a problem analytically, and how to use an abstract flow of logic to solve a problem, and how to diagnose issues with your own logic when things go wrong. It's about critical thinking. It's about attention to detail.
It's about all of these things first, and about slapping keys second. But too many people see learning programming as learning the act of typing code, and focus too much on rote memorization of syntax, or teaching tools instead of thinking. Someone should come out of a course saying that they learned how to think in this new way as programmer, not that they learned a new programming language.
> Indeed you can hardly do many things at once - not in a single pure Python process. One thread doing something takes the GIL and the other thread waits.
> You can however wait for many things at once just fine - for example, using the multiprocessing module (pool.map), or you could spawn your own thread pool to do the same.
This paragraph is a bit deceiving. The multiprocessing module does spawn subprocesses by default, so it can indeed be used to workaround a GIL issue and do many things at once. It's not the same as a thread pool (although the multiprocessing module does offer a compatible interface which uses threads).
I see arguments about whether or not Amazon Instant Video is worth the money, but I think that's beside the point, isn't it? The important part of the discussion here is that Amazon Instant Video is not of interest to a large number of existing Amazon Prime subscribers, and they are likely paying the price for those who use it.
It's a bit of a frustrating trend to see companies bundling new technologies like this, often at the expense of their loyal customers. I am an Amazon Prime subscriber, and will continue to be one, but I would love it if Amazon Instant video were a separate subscription that I could choose to pay for on its own merits.
Both? I've been in situations where a company implodes like this, and employees at the company are often already being head-hunted by previous employees (who departed during a prior round of lay-offs, or who left of their own volition before the company fell apart) before they are fired.
While it's often something of a surprise when you finally do get the axe, you usually have a sense of impending doom, and a feeling that bad things are going down, before it happens. Projects stop getting traction. Upper management stops caring as much about what you're working on. Everyone becomes very apathetic. You get a rash of invites on LinkedIn, and people start updating their resumes.
So, it's rarely a complete surprise, and people often already have some idea of where they're going to go, or are ready to start looking.
"You get a rash of invites on LinkedIn, and people start updating their resumes."
When I was working at chumby industries and it was imploding, it occurred to me that somebody could probably write a really good predictor of imminent company failure by scrapping LinkedIn data and watching for sudden surges of activity from people working at the same company.
I'd be surprised if someone (or multiple someones) doesn't already have something like that running, even if just for their own private purposes.
I believe (subscribed) recruiters can already search by which profiles have been most recently updated. Just keeping track of that info plus the linked company would be enough, particularly if they expose it via an API.
I never really looked too much at the LinkedIn API, I suspect for the idea to work well you'd probably need to scrape data from the frontend and preferably be connected to a few "super node"-esque people (recruiters, etc).
(You're welcome for what bits of chumby I touched. Of course I was just one developer in a team of wonderful developers and hardware designers. It was a great job and a lot of fun. I still haven't decided if we were a bit too late (introduction of iPhone and Android) or too early (explosion in hackable maker devices like Raspberry Pi). I guess a bit of both.
Presumably, when a company is laying someone off, ex-employees don't have to worry about non-poaching agreements they might have in place with the employer. The easiest person to hire is someone you've worked with in the past and liked, and the easiest job to pick is one working for/with people you know.