gemma

When I was 8 or so, a relative gave me a huge pink plastic box full of barbies and barbie accessories. I hadn't asked for it, and I wasn't entirely sure what to do with it, but I said thanks and tried my hand at playing with barbies, because that's what was expected of me. After that, I kept receiving dolls as gifts--plastic dolls, porcelain dolls, dolls on stands, dolls in cases. I tried playing with all of them, because that's what I was supposed to do. I never got it, and I learned that I was abnormal because I didn't really like dolls.

What we tacitly expect of kids does shape them, to an extent.

Not a MOOC, but the Stevens Institute of Technology offers an (online) accredited graduate degree program on the same topic: http://www.webcampus.stevens.edu/Space-Systems-Masters.aspx

KeePass also makes a global keyboard shortcut available (Ctrl+Alt+A by default) that will complete login fields based on the active window title. (The mechanics of the text entry and the window title matching are all configurable, though the defaults are usually fine.) Not as slick as auto-filling without user interaction, but better than manually searching for each entry every time.

I still don't see the "fundamental flaw". Non-reachable commits are automatically deleted by the garbage collection system, which can be also be run manually. Accidental commits with large files or private content can be "modified" (technically copied and rewritten, since individual commits are immutable) with rebase, amend, filter-branch, etc. Those operations make the original commits unreachable, so garbage collection takes care of deleting them.

And like I already said above, data loss can occur when you're working with uncommitted changes, just like in most other version control systems. If the content is not under version control (in this case, not in a git commit), it's not safe.

Honestly, you guys should go watch Linus Torvalds' presentation at Google about Git. The entire point, the massive problem he was trying to solve, was preservation and verification of data integrity.

No, that advice from the article is fundamentally broken. Outside of the garbage collection system (which runs by default after what, 30 days? 90?), Git doesn't delete committed content. Any commit you "lose" through rebasing, amending, resetting, etc. can always be recovered. It's a little more complicated than renaming a directory, sure, but it's important, and it's not something a Git tutorial should ignore.

Git IS safe, and ANYTHING involving changes to history can be undone without resorting to backups. Data loss can occur when you're mucking about with uncommitted changes, but that's a risk in most other version control systems as well.

Wow, massively flawed premise here.

1. Using user stories to define your requirements does not make your process agile, just like writing a traditional requirements doc does not make your process waterfall. It's not about the tools. If you're not capturing the requirements you need to capture, your process is just broken.

2. Design documents do not magically make your project successful. Agile doesn't like design documents because it typically uses more lightweight artifacts to capture design decisions--but it still captures them! Again, if those decisions are not captured at all, your process is broken.

3. Wat? Asynchronous vs. synchronous is a project design decision; how does this demonstrate the failure of agile methods?

Multiple sources ([1], [2], etc.) have reported that the requirements for the system were not known until Spring of this year, and that they were in flux until weeks before the release. That's not a problem that would be fixed with use cases, UML and design documents.

[1] http://www.nytimes.com/2013/10/13/us/politics/from-the-start...

[2] http://www.huffingtonpost.com/2013/10/22/obamacare-website-p...

Other: RamNode

Less surveillance and more hackers/cryptography/NSA origins: Cryptonomicon, by Neal Stephenson.

I think we're evaluating the circumstances with different criteria. You're looking at the story and relating it to a thin-skinned woman who can't handle non-politically-correct humor in the workplace. I'm relating it to a 16-year-old kid who hasn't had the time or experience necessary to develop the thick skin and snappy retorts that would shield her from her peers' disrespect. She's not getting passed up for a promotion; she just wants to learn programming. It's entirely within the job description of a teacher to notice, step in, and set standards for behavior in the classroom. Even when they're not met, they communicate more than tacit acceptance of bad behavior.

I completely agree that people in general, and women in tech specifically, have to be thick-skinned to survive professionally. Nobody's advocating HR thought police--they'd be unnecessary in this case anyway--or politically-correct automatons. We're talking about kids. Kids! Surely it's not totally out of line to suggest that they could learn better behavior than "get in the kitchen and make me a sandwich". Surely there's a better response to the whole situation than "that girl needs to suck it up and learn how the world works".

For what it's worth, I remember the first time those trite cliches were thrown at me, and they felt neither trite nor cliched. They hurt. I thought I was part of a team, among equals, brothers-in-arms, friends, and I wasn't. I was different, I was other, I was less, I was not welcome. It's a paradigm shift that happens in an instant, and it can be pretty shattering--great for killing enthusiasm and developing thick skin in the future, maybe, but not for learning things in a programming class.

> Minority entities will be teased practically any time they exist, regardless of sector or age, and they need to be taught to handle it well.

Yeah? So this high school programming class isn't so much a programming class as a crash course in coping mechanisms for gender-based harassment?

Please. It's the educator's job to create a safe space for, you know, education--for every student in the class, not just the privileged majority. It's their job to track their students' education and interest level, and make adjustments if either starts dropping. It's not their job to facilitate a hostile environment and let minority students flounder in the interests of 'real world training'. It's not their job to decide that since it's hard for women in tech in real life, it should be hard in their class. Education isn't about maintaining the world we already live in, it's about shaping the world our kids will live in.

You want real world training? Show me an HR department in a software company that's fine with comments like "get in the kitchen and make me sandwich". Which real world are you advocating this high school programming class introduce to a 16-year-old girl?

Formal proofs predate how we think about unit testing (check out IBM's 'Cleanroom' process). The concept comes from an age when most programming was a lot more like applied math, and it still has a lot of traction in industries with very high reliability/correctness requirements. Unit testing took over because it's easier and cheaper to do, the results are good enough for most environments.

I just switched to clavid. As @elektronaut pointed out they do support delegation, and their two-factor authentication supports a big list of OTP standards (so it's compatible with the Google Authenticator): http://www.clavid.com/index.php?option=com_content&task=view...

Because I'm not that good.

As a veteran of the USPS software industry, I wouldn't worry too much.

But as a crowdfunder, I know that going in. Donation levels are clearly marked with what returns, if any, I can expect if the project is successful. "Worthwhile" to a VC means "big financial returns"; "worthwhile" to a crowdfunder means "this cool thing gets made". It's exactly the same concept; how it works out in practice is just mechanics.

> I'm really turned off by this model of 'pay us in advance for developing a product that hasn't been market tested or validated'

Isn't that the whole premise behind a huge chunk of the projects on indiegogo and Kickstarter? "I want to make a cool thing, but I can't afford to quit my day job; please pay me up front"?

I mean, I'm truly concerned about online privacy, but there are several barriers standing between me and my solution--not the least of which is the ability to eat and shield myself from the elements while crafting said solution. How is what these folks are asking any different from pitching a business plan to a VC? Sure, if you're going to a VC it's expected you'll actually have a business plan, but the function is the same: Convince people with resources that what you're doing is worthwhile and achievable, so they'll give their resources to you.

This isn't an analysis of Git vs. Mercurial, this is an analysis of Git's documentation vs Mercurial's documentation. Disappointing.

My favorite: git diff --color-words=.

status -sb

Yeah, but the PowerShell output from those "aliases" doesn't match the *nix versions (e.g. ls), which drives me nuts.

"Gmail's security hole"? Really? So "security hole" now means "any opportunity for users to be stupid". In related news, Gmail's other security hole could lead to mass harvesting of accounts when users choose a password of 'password1'!

TortoiseGit gets a little funky with the shell icon overlays on Windows 7--don't expect them to always tell you the truth, the whole truth and nothing but the truth (http://stackoverflow.com/questions/1057734/tortoisesvn-icons...). It's also heavily biased toward SVN users, which will make some of the terminology confusing if you don't come from that background.

For my own workflow I prefer the command line, but GitExtensions (http://code.google.com/p/gitextensions/) is my go-to when I need a GUI (or more often, when I need to show a manager that there are, in fact, GUIs available).

> a) It's not going to kill you.

No, probably not. And yet, from the response of UCSF PhDs, it sounds like there needs to be more research into what the effects will be. Let's get that done before we foist it on the flying public (particularly kids, pregnant women, cancer survivors, etc.).

> b) Naked photos!

We've all seen this one by now: http://bit.ly/9AbQ82. The difference between the two is a software setting--but the resolution/quality of the image isn't really the point:

> c and d) Suck it up, you chose to fly.

I choose to drive, but the policeman who pulls me over for speeding does not have the right to pat me down unless he can prove he had cause. The Constitution protects me from that. I'm not sure why it doesn't protect me from the TSA.

I appreciate Ron Paul's stance, but the introduction of this bill reminds me of the West Wing character Ainsley Hayes and her stance on the Equal Rights Amendment: http://www.youtube.com/watch?v=NXPLirJRGDQ#t=3m54s

The Fourth Amendment should already be protecting us from what the TSA is doing. Why isn't it? And isn't the fact that Fourth Amendment violations are not prosecuted as such a much bigger issue?

The clause that shelters the TSA is from a 1973 court decision: "a warrantless search...is valid under the Fourth Amendment if it is 'no more intrusive or intensive than necessary, in light of current technology, to detect weapons or explosives'" (http://www.tsa.gov/what_we_do/optout/spp_faqs.shtm). Cavity searches aren't far.