gometro33
gometro33 on Hacker News
Out Stealing Horses by Per Petterson
To Siberia by Per Petterson
The Millenium Series (Girl With the Dragon Tattoo series) by Stieg Larrson
The difference between this and true overloaded methods (which, correct me if I'm wrong, is the what he meant by "MultiMethod") is that an overloaded method is created at compile-time and does not incur the added cost of determining the type of the object at runtime.
That being said, I didn't know that Python doesn't have function signatures. Would someone care to comment on how a function is identified?
Being part of __future__, is print() slated for release in 2.7 or is it strictly a 3.x feature?
I just tried it on my Droid (Dolphin HD2 browser) it didn't work very well. The browser itself does a lot of touch/drag so I'm not really surprised.
An interesting way to keep people interested in the game (during a fight, that is) would be to allow players to update the AI on the fly.
I'm thinking each player would submit an AI to start the game. At any point during the game players could "check-in" code (VCS-style) and cells created from that point on (via the splitting described in the article) would have this new code. Players would be allow, for instance, 2 check-ins per game. The upgraded cells would be represented by different shades of the player's color so that they could be kept track of.
I see this being useful for times when a player drastically misuses his cells initially or for an entirely different style of play (a different bracket on the ladder server).
As interesting of a problem as this is, I don't quite understand how a) BP and other oil companies aren't
required to have solved it prior to drilling and b) after more than a month of the world watching, all they could come up with was a solution that
might work.
I'm inclined to call to question the caliber of the engineer s working to resolve the leak. Maybe I'm being too harsh?
EDIT: To clarify point (a), I would have assumed that oil rigs would be required to build-in some sort of kill-switch in the event that even the smallest part of the process didn't go as planned.
A quick search revealed that this title ("...and used by reCAPTCHA") has been reused many times and is likely just a rumor at this point.
I would definitely be interested in seeing evidence of it though.
I've used pairs off and on at work but never long-term. The part I find most useful about coding side-by-side with someone is that there is someone to question (or reassure) every small decision I make (for better or worse!). Particularly in coding, there are always many ways to solve each problem and having two sets of eyes (with even mediocre brains attached) frequently yields a better solution.
I find that a necessary part of pair programming is to switch up the pairs fairly often. Pairs have a tendency to become "comfortable" with each other's habits and can fall into a rut -- pairs should be shaken up to keep each everyone on their toes.
Also, you can learn a lot (about programming, people, life, etc.) when pair programming.
I always enjoy seeing posts like this. Project leaders know more about the code than anyone -- it's like seeing a lecture on a PhD thesis: this person knows more about this topic than anyone, anywhere. Feels good.
While I think you may be right that guilt can motivate, I prefer the idea of being able to finish a project because I want to (rather needing to).
My advice, as others have mentioned, is to start small ("Hello, World!" if you will).
I remember my first UDP packet...
Tell me again why we're listening to this guy?
FTA: "...the gap between software engineers and birthday clowns is almost negligible."
True.