The "TODO" flag isn't what's wrong there, the "this" part is. It's obvious that the TODO relates to the nearby code (this, not that). It's still not obvious what needs to be fixed. It could be a lack of performance, error handling, input validation. Some use-cases/states/values might not be covered/tested/identified or implemented. But the answer is always: why. Ask yourself "why am I adding a comment here" and the answer is the perfect comment.

No. You have to be reasonably prepared for it, that's all. It's futile to worry about things you cannot control. Or those you can control, because then you just have to take necessary actions. Worrying is never the right solution.

And those people were right, for dozens of generations to come. What we might achieve in 2300 is not relevant today. Sure, we must try to continue scientific and technologic progress. With both revolutionary discoveries and evolutionary practical solutions. But constructing a planet, as of now, is indeed totally out of reach.

What we have to show for is just a single permanently inhabited construction in orbit, just one dozen of men on the moon in total and an growing but still insignificant number of unmanned landings on other bodies orbiting Sol. While I'm hopeful our descendents could create an artificial planet, I have to agree with GP that we, the humans alive as we speak, will most certainly not.

I wrote find-issues.sh, a script that extracts comments of a certain type within the code and then groups them by file. Downside: your code files change when you register a bug. Upside: when done right, your bug description is next to the code that needs fixing.

Obviously won't work for distributed development, but for single-coder projects, it's really been useful to me.
Note some assumptions and grep magic to exclude third-party files and other non-code files.

#!/bin/sh

LASTFILE=""
egrep -ri "(WARNING|HACK|FIXME|TODO|BUG)" . | egrep -vi "(\.git|debug|/third-party|/locale|/prettify|doc/|/jquery-|lib/s3.php|/jwysiwyg/|^./(.*)\.(txt|conf|xml):(.*))" | while read LINE ; do
        FILE=`echo "${LINE}" | cut -d":" -f1`
        DATA=`echo "${LINE}" | cut -d":" -f2- | cut -d"/" -f3-`
        LEVEL=`echo "${DATA}" | cut -d":" -f1`
        COMMENT=`echo "${DATA}" | cut -d":" -f2-`

        if [ "x${LASTFILE}" != "x${FILE}" ]; then
                if [ "x${LASTFILE}" != "x1" ]; then
                        echo
                fi
                printf "%s:\n" "${FILE}"
                LASTFILE=${FILE}
        fi
        printf "%5s:%s\n" "${LEVEL}" "${COMMENT}"
done

That is not metric, they are imperial values...

True, but the mavens are not motivated by hatred against Microsoft. They are motivated because:

1. iOS and Android have been proven to work.
2. iOS and Android have a large ecosphere of apps. And tech users. And non-tech users.
3. iOS this and Android that.

Apple, Samsung and HTC have repeatedly been on the top of "best phone" lists for years now. Nokia's Windows phone is not being ignored because it is worse or disliked, it is being ignored because no one has one in the first place to offer a recommendation. Under those circumstances it's not good enough to compete, one has to be better. And it's not significantly better.

So, you're not only paying for an OS you'll never use, but also for a drive you'll never use?

Facebook is not just a social network, it's consumer groupware. Compare it to television or telephone, not to Myspace and other previous offerings focusing solely on the social factor.

I expect the following:

- provides ticketing for events.
- a store for media content and app content.
- even a premium subscription model to remove ads (hi Slashdot!).

There is no Berlin wall surrounding the USA. You are free to leave.

Countries like mine (Netherlands) would be happy to have skilled workers from the western world.

Bad idea. There would be no Slashdot left with all the editors posting dupes.

Well done. Pointing out that inability of the iPhone is funny, flamebait and interesting all at once.

Assuming the compromised database had proper hashing with per-user salts, you are right. In any other case, the vulnerability here was the third-party storage and not the password strength. (On top of password re-use, of course).

Or just not send HTTP requests to facebook.com?