"One of them
Because this worked *so* well for Gowalla.
"One of them
Because this worked *so* well for Gowalla.
Whut up, yo? Mostly moved to Twitter... You have an account... why don't I see you there much?
I used to swear by LaunchBar, but now the built-in Spotlight is good enough for me.
So, the programming problem posed in the article is:
"Given a data file describing a maze with diagonal walls, count the number of enclosed areas, and measure the size of the largest one."
Who wants to take a stab at an algorithm for that?
"Dusting off" a ten-year-old computer? Pah. Wake me when you get the latest Linux kernel running on a Mac IIfx.
GLaDOS is already in the upcoming Pacific Rim. http://www.forbes.com/sites/insertcoin/2012/12/13/yes-that-actually-is-glados-in-the-pacific-rim-trailer/ Way looking forward to seeing that.
As Wikipedia says, "Be bold." If you see code that needs to be deleted, delete it. Don't just leave it commented out and taking up space.
If you're removing functionality, then make sure you note this clearly in your commit summary, so that it can be found again if that functionality needs to be put back in.
Also, the article talks about rewriting code - throwing out the old and creating it again. This is generally a bad idea, even if you're starting with bad code, because all a rewrite does is exchange a known set of bugs for an unknown set of bugs.
You (and every other development shop) need:
* A coding standards document. Using one from a large open-source project (such as http://framework.zend.com/manual/1.12/en/coding-standard.coding-style.html or http://www.kernel.org/doc/Documentation/CodingStyle) is a good idea. This ensures that you do not have to spend any time being surprised or misled by how a piece of code is formatted.
* Unit tests. They make sure that your code continues to work the same way as you develop it. They also exert pressure to make sure that your units (individual functions to be tested) remain small and concise (or else the unit tests become a bear to write).
* Code reviews. This ensures that more than one person understands how a piece of code was written. It also means that the reviewee learns from your comments and you learn from his code and you both are better programmers for it.
And, most importantly:
* A manager who believes in all of the above and is willing to support and defend it.
If you have all this, then it ceases being a personal "you vs. him" issue, because you can objectively point out (to him, to your team lead, or to your manager) where he's violating the coding standards, where his unit tests are not adequate, or where he is ignoring his code reviews.
The alternative is what it sounds like you have now: cowboy programmers, quickly cranking out code that satisfies a need right now but will take huge amounts of time and money to maintain and extend in the future.
"There there, ship." *pats the hull*
I am a keyboard snob. The keyboard is the part of the computer with which I interact the most, so I hate the mushy feel of membrane keyboards that are based on the same technology as VCR remotes.
If you want to be a keyboard snob too (in a good way), then start by going to wasdkeyboards.com and buying their sampler kit ("http://www.wasdkeyboards.com/index.php/products/sampler-kit-1.html"). For $8, you get eleven keycaps in different colors, four Cherry MX switches (blue, brown, black, red), and fifteen dampeners in three types. This is a cheap way to understand the difference between the four kinds of Cherry MX switches and decide which you prefer. You can then buy a custom-made keyboard from wasdkeyboards.com, choosing the switch, keycap color, and text for each individual key if you want.
I don't use my numeric keypad much, so I opted for a tenkeyless keyboard. wasdkeyboards.com doesn't yet offer these (current estimate is March), so I got it from "http://elitekeyboards.com".
If you want an old-fashioned IBM Model M clacky keyboard, you can get it from "http://www.pckeyboard.com".
"No consequence to dying" - untrue. It's true that you can be resurrected, but dying damages your armor and makes it harder to continue to stay alive until you head back to a town to have it repaired. And if everyone in your party is dead and there's no one left to resurrect you, then you have to go back to the last waypoint. I've seen huge zergs go after bosses and fail by being entirely wiped out.
"Players versus door" - you're missing the fact that the other team is trying to reinforce their door and kill you while you try to break down their door and kill them. Strategy, boy, strategy.
"Complete ghost towns" - I've reached a level 75 PvE area in the game (Malchor's Leap) and there are plenty of people around to join, help, and be helped by. I've seen no evidence that people are abandoning Guild Wars 2; to the contrary, the events they've had so far (Halloween, Lost Shores) have been well conducted and extremely well attended, and a lot of people are looking forward to Wintersday.
It's a beautiful game, I've been enjoying the exploration and the crafting, the Trading Post (auction house) is done right, there's enough challenge to the dungeons to keep me coming back, the world is dynamic with a lot of things to do, and there are lots of other players to help make the going easier.
So, here's the funny thing. I heard the news right after it broke. I saw a discussion thread about it and I wanted to post a link to http://nooooooooooooooo.com/.
Except, at the moment, that site was responding really slowly and took two minutes to load.
I will second "Illusions: The Adventures of a Reluctant Messiah". That got me into a lot of early Richard Bach books, primarily "The Bridge Across Forever" as well as his biographies of piloting a biplane across the midwest. They showed me a different way of looking at life. Also, "Jonathan Livingston Seagull".
Check into it and ask about the impact of retinal remodeling on potential interventions.
The number of computer scientists in a room is inversely proportional to the number of bugs in their code.