 So, let's do this. Let's like the scandal. So, we're going to talk about extreme programming using open source tools. All right. And I'm Matt, and this is Luis. That's our contact infos, if you want to talk to us later, whatever. We're doing two talks at the, Luis is doing three. He's a bigger slut than I am. But we're doing two talks around this kind of area of discussion. So, this one's about extreme programming. We're going to talk about a project that we open sourced from our black hat class that we taught for four days. And this is kind of an introduction to that project from the perspective of how the project was developed. And what we're going to show you is how to write really fucking badass security tools using kind of commonsense engineering instead of like jerking off into a jar and then releasing open source and expecting people to respect you. No names. All right. So, I'm Matt and I have done speaking and writing. Last time I spoke at DEF CON was in 2000 or 99. DEF CON 8, I think. 2000. And at that time, Luis and I did back to back presentations. And so I talked about testing IDSs and firewalls using open source tools and how to find exploitable bugs in firewalls and IDSs and other protocol parsing type things. And not a whole lot has changed since then. But even so, I'm going to talk about something different instead of rehashing the thing I talked about seven years ago, unlike some people. So, in that time, we released several exploitable security advisories. Luis and I worked together a lot of that kind of stuff. One of them was one of them. NetBSD, what was it, ICMP? Oh, yeah. NetBSD, an online ICMP option. We found one packet that would crash. NetBSD, openBSD or freeBSD was one packet. That was kind of fun. IE5 on Unix. Oh, and exploitable bug in Trillion 3.1, or any version of Trillion, really. And so various security advisories. Basically, we know what we're talking about on the exploitable side of the house. And so this might seem a little bit fruity, this whole extreme programming thing, but we're coming from a perspective of deep reverse engineering and very deep technical stuff. And so I've worked a lot on product stuff, on security products. I worked on network security scanners a long time ago. Worked on one of the first hybrid host-based intrusion detection systems. Does a little bit too ahead of its time. And of course, everyone's like, why would I put an IDS on my host? And of course, now, like, that's a gazillion dollar market. I also contribute a lot to open source, and I fund a good deal of open source development. One of the things I'm funding right now is PlayStation 2 emulator, so I can play it on my Xbox, because I don't want to give Sony a dime and I want to play Katamari. So I've been doing extreme programming and natural software development for about a little over four years now, and honing that and getting better and better at it. And so I'm going to talk from the perspective of a lot of experience with, like, seeing what goes wrong and course corrections and things like that. You can talk about yourself. So my name is Luis. I do a lot of reversing work. I'm doing another talk here at DEF CON on how to combine disassemblers and debuggers together to maximize your results, feedback, everything from your debugger back into your disassembly and create this kind of loop of information. And I've done a lot of hardware and software reversing and worked on different projects, some with Matt and other security projects. But really, I'm here today to talk about my experiences just starting out doing agile development. This whole project that we've been working on, we started, I started coding it about four weeks ago. I'd never touched C-Sharp or any type of XP programming before. And I was just giving some customer tests by Matt and based the whole project around that. And I thought XP programming was retarded. Like, when I first started doing it, I just thought it was all these really simple tests and it's just like people wasting time instead of like really doing coding. But as we'll go through this talk, I'll talk about how my opinions have changed and part of it, there's this great quote from Office Space when they're in the car and they just found out that they got like, I don't know, like $300,000 in their bank account and they're only supposed to be taking out pennies a day, right? And the Michael Bolton guy says, I always mess up the mundane details. And that's what this is all about. This gets rid of all those little bugs. So I'm going to hand it back off to Matt. All right, quick, quick, quick agenda thing. I got to like deep through this mic for this, for this to work. It's really strange. Yeah. Anyways, so extreme programming, we're going to talk about stories, which I know sounds really gay, but you'll understand in a second why it's useful to think about features in this way. Pair programming, test driven development, incremental design and continuous integration. And some of the tools that you can use to do remote pair programming and things like that. And these tools are very little bit with Luis leading up to the class when he was basically done with the code. And I've also used them when working with outsourced engineers basically to pair with outsourced engineers and do XP with people who are really far away. And so this is how this can kind of apply to open source projects where there's kind of a time disparity between members of the project. And then we're going to do a quick demo on the involving the code that the open source project we talked about that analyzes a x86 binary code to find exploitable security vulnerabilities automatically. And again, there's a second talk where we're going to go way deep down into that tool. But this talk is more about the process developing that tool, even so you're going to get a glimpse of it. Yeah. So extreme programming. The main thing with extreme programming and all agile software development is you have short release cycles. This is open sourcing of release early and release often, I think is what it is or whatever. That came from extreme programming and agile software development. That wasn't like an incredibly new thing. It seems to work really well in the open source world because you get a tight kind of feedback loop, you find bugs sooner, et cetera, et cetera, your users get a hold of it if they really want to and what have you. I think some people, a lot of open source projects sort of just release without even thinking about it. And so it's frustrating to the users because you go download something that's supposedly fixed. You have to go down like the daily snapshot or nightly snapshot that fixes a bug. It turns out it won't even run because it crashes when it starts because they don't do any testing. So but anyway, that's really one of things agile software development is all about is release early release often. And as a concept of weekly releases and quarterly releases quote unquote. And what they mean by weekly releases is basically you want to plan to have a complete, fully tested working release every week, maybe two weeks or depending on whatever, three to four weeks, but no more than a month. And by doing this, basically, you always make sure the code is always releasable. And basically, you have to maintain a very high level of quality to make this happen. Otherwise, you're going to go to release and you're just going to be tripping over your own dick the whole time, fixing little bugs and other things because you weren't keeping a firm control of quality. And this is the exact problem that commercial software has. This is why it takes people so long to respond to like simple security bugs where you look at the disassembly, you're like, why don't they just release a patch and fix this? It's because they don't have good quality processes. And so hopefully for the love of God, the open source community can like not make the same mistakes that the closed source commercial community makes one would hope quarter releases. So you want to use weekly releases, but you kind of batch things together and kind of like a conceptual continuity package of here we're adding like little features every week to, I don't know, say like add VoIP support to some Java client, let's say. And then at the end of that, you're going to do an official release with everything packaged together and really well integrated, et cetera, et cetera. And so you want to kind of plan like, okay, in three months, we're going to do a release of this Java client with VoIP support, let's say. And then you forget, okay, how are we going to get their release, you know, little release, little iteration by little iteration until we are done. So the other thing with extreme programming, natural software development, documentation that is not in code, i.e. that is not code, i.e. you have to update documentation every time you change your code is a waste of time. Because A, you have to waste time not coding and you have to keep your documentation up to date if your documentation isn't in code. And B, if you don't do that, your documentation is worthless at best and misleading at worst. I don't know if anybody has ever seen some like open source API documentation that's totally wrong or read a book like I was reading a book on cruise control, which is an automated build thing. And the book was wrong because they were going off of the docs of cruise control and the cruise control docs were wrong. And that irritated the piss out of me. So if documentation isn't in code and tests and you're on an open source project and you're trying to move fast, you're basically slowing yourself down if you don't put your documentation in your code. Automated tests show progress basically. So if you have automated system tests, and we'll talk about that in a second, for a feature, you know you're done with that feature when that test passes. Otherwise, you can continue to just like mentally masturbate or whatever and do all kinds of things that have nothing to do with closing the feature down and getting the feature done. It's really irritating when your users are waiting for a feature from open source or closed source project or fix a security bug or a security patch and you can't close it down because there's nothing to focus on. And so we're going to talk about doing the simplest thing that could possibly work and having automated tests focus your work a great deal. The other thing is evolutionary design is the concept of big design up front or BDUF as it is called. And so there's two kind of ways I've seen open source projects go either it's all the design and there's no code whatsoever and you're busy like tweaking a design, this utopian design for God's own whatever it is that you're working on or you should out code constantly and there's no cohesion, there's no coherence, it doesn't make any sense. Either extreme is really bad and so extreme program has an approach that basically an agile development has an approach where you let a design emerge by doing things intelligently. You think about it a little bit, it's not no design, it's the least amount of design that you can do and still have and still produce really good code basically. The other thing is XP and agile development balances short-term instincts and long-term kind of needs basically. Long-term needs are code that's not shit or you know stuff that doesn't crash when you run it or you know happy users or whatever short-term instincts are we have to get this feature done now we have to get the security patch out now and how do you balance these two things in a meaningful way without sort of shirking either one right how do you be responsive without like fucking your design to the point where you're going to have to rewrite it from scratch for instance and also between like all these things like pair programming and test-driven development all those things you have no fear how many people here have worked on code or worked on a product or worked on whatever where people say things like you know I could fix that but I'm afraid I might break something how many people have heard that yeah that's fucking bogus all right that that's a position of helplessness and that's fucked up I don't like to be in a position of helplessness especially when it comes to code I just fucking wrote and so no even an open source project no one should be able to like take away your position of kind of safety or security from that perspective and this is again where a lot of commercial software companies are with like they can't do anything it's not because bureaucracy necessary it's because they they're scared of their code they don't know all the nukes and crannies they don't have automated tests they didn't do a pair programming so the fearlessness makes us a bamfork how many people here know aquatine hunger force aquatine hunger force so so there is a episode called super computer so anybody has anybody seen this episode of aquatine three people all right it's three real fans in the audience so frolock won a name of super computer oogie mctar which is a Klingon name and shake suggestion was to call it bad-ass mother for a thousand twice as fast as your ass when you do XP it'll seem like you're going slow at first but here's the thing with all these things in place you fucking fast like that and you're always coding you're not debugging you're doing like worthless shit it feels really great so it seems slow at first but basically what it is it's actually very very quickly because you don't have any fear you're gonna break something or that you know whatever so stories are a short description of an end user goal and then use the goal like here's a small c program I want to detect the expletible format string bug in this particular program that's a story right and basically what it comes from the perspective is what what is the user what's the user goal what's the user trying to accomplish right in like what's like their primary goal basically and it sounds obvious but if you don't start from this point you're like yeah avoid jabber client never mind how people might want to use it right and then you make it so it's embedded on a USB key and you have to like hook it up to like you know to tin cans connected with string for it to work this is what happens right well-intentioned you know this would be a really cool tool this would be really cool you know whatever or library or whatever you don't think about like how it's actually gonna be used which a lot of people seemingly don't you're gonna produce something that no one wants to use and then you just wasted your time and a whole bunch of other people's time I personally don't like to do that maybe other people do but probably not so you take this story you're like okay how you know how hard is this basically instead of estimating in terms of hours or days or whatever you say how hard is this going to be so XP has a concept of points or you call whatever you want just don't use a time based thing say oh this is one difficulty point this is two difficulty points is three difficulty points right and so over time you start to figure out oh one difficulty point over time you know averaged out took takes about eight hours let's say or whatever but it's all points it's all abstract you want to like force people think oh god I've got to get it done in two days otherwise like I look lame or whatever this is one of the things that this is a total trap of software estimation by days or by hours or whatever because as you get closer and close you start taking more and more shortcuts so you can meet some deadline that doesn't really matter where the thing that matters is delivering working high-quality code as opposed to meeting a deadline of winning a race hypothetically speaking in this varies each story should take one to two days at the most right if a story is like if you if you can't think of like a way that the story might be completed in like one or two days it means it's too big of a story you need to split it up so instead of like the story is we did have a jabber VoIP client that's kind of a big story you're not going to finish that in two days most likely I don't care who you are at least not with high quality and and with tests and what have you so so you have to kind of like learn to break it up what's what's what's the minimal incremental step we could take that would deliver value basically that would be kind of useful right even if it's not releasable to the general public or whatever something we can get started with it's like the seed of whatever right so maybe like how about just like you know connecting to the VoIP network or connecting to the jabber network or whatever or finishing the first VoIP exchange never mind the codex just finishing the handshake or whatever and so breaking things up into these little kind of pieces and then when you like when you have these pieces you're focused on you make sure they work 100% instead of trying to like throw together an entire system all at once that's how you make sure that your code is really high quality and everything works incrementally as a unit instead of trying to throw it all together once and so the other thing that you do with stories is you come up with an automated test away you can automatically test and that test fails and when you are done implementing the functionality that you're trying to do the test passes you so you know when you're done and so you can focus on doing the simplest thing that could possibly work to make that pass sometimes that involves cheating but we'll talk about that in a minute and so in this context how to deal with bugs like here's up here's a problem of bugs bugs are like like fire alarms or whatever it's like stop everything you're doing we're gonna go fix bugs now that's worth it basically and that's not the way to develop good software because if people are gonna keep distracting with bugs and bugs and bugs you're not gonna finish your story you're gonna forget what you're doing you come back to your story and be kind of scatterbrained and that's not good just common sense basically so the way that you deal with bugs is bugs are also stories so if you have like one week iterations and there's like a and there's like a bug or whatever scheduled to the next iteration instead of the story if it's that important usually bugs aren't usually not actually that important when it comes into the grand scheme of things alright pair programming this is the most controversial part of XP for some goddamn reason I really don't know why but basically pair programming you're we're gonna do a demo you're gonna see it is two people programming at the same time you know like how the hell is that gonna work you know try to share the keyboard or is it two keyboards or what the hell will show you in the demo it's a lot easier to show than to describe but basically pair programming is like a constant code review effectively and so the general thing to remember is that code written by one person is readable by one person and code written by two people is readable by at least two people two different people alright how many people here have like worked on an open-source project and somebody contributes a big chunk of code and you can't read it basically okay how many of you have thrown away that code and rewrote it from scratch right that's a big fucking waste of time right you're gonna piss off the person who thought they were doing good right and so wasted your time because like that's a great feature and now you're distracted from working on the thing you are focusing on to fix somebody else's shitty code for the sake of you know whatever and so this helps avoid that problem and so one of the problems with pair programming open source stuff is the geographical disparity sort of time zone disparity like a temporal disparity if you will and so and and kind of like how do you deal with that so we're going to show remote pair programming thing using the VNC and we'll get into that when we get into tools but basically you can kind of like play ping-pong around the world or kind of like pass the torch around the world if you have like somebody who's in like you know on the west coast on the US on the east coast of the US and somebody who's in the UK and then somebody who's an indie and then someone who's an agent someone is whatever you can make sure that that's like everybody's pairing with someone as you go around the world or you don't have to pair all the time right you know you have to pair all the time there's a practicality that comes into play basically you know and so you want to just like kind of make make sure people knew the project or on the right track perhaps or you know make sure that they're always checking in tests TDD test of development which is I think the next slide is probably the most difficult part of extreme programming everyone focuses on pair programming and because I don't know it's the programming less about their ego or I'm not sure what the real sort of social problem is but TDD is much much more difficult to grasp as a technical concept and to execute upon another thing too is that it provides a sort of check and balances between when you have more than one person you have two people so you're not going to write crappy code when someone else is looking at at the same time and it keeps the standards up and you can also be like hey does this look cool am I like smoking crack or is this wrong is this right and you go back and forth and you brainstorm ideas and it works out quite well yeah the code basically ends up really bad ass right off the bat no time wasted no throwing out code like writing and then a re right if you're rewriting code you're fucking idiot if you're like well we're going to rewrite this in six months blah blah blah yeah why don't you just do it right now so that you can move on with your life basically I really don't understand why people choose to like take steps that are ultimately going to waste their time and produce code that no one wants to use or contribute to maybe it's some SNM thing like some kind of kink like you know I want to waste my time that's the only way I can come or something I don't know but anyways and so there's a kind of a pair of programs kind of like a ping pong that goes on basically it's like well and so one of the responses when I had a job ahead it's like something I was like I don't want to pay a program I don't want someone to watch me pair approach program all day I'm like no one wants to fucking watch you program all day all right this isn't about you like his response is like very kind of indicative of his kind of overall megalomania but you know what's a pro one of what nobody wants to watch you program all day you know it's an interaction it's a back and forth basically and you'll see in the demo when we pair program kind of what goes on and so one of the ways to like make sure it's kind of even is one person writes you know test the other person makes a pass right the other than the other person refactors and you kind of go back and forth anti-patterns you want to avoid our only one person the pair writes the tests that's that sucks just as much as watching somebody program basically or or you know or someone's a keyboard hog or whatever and so these issues are easy to get around if you're physically pair program with someone someone's like cogging the keyboard just like poking with the stick and say knock it off if it's remote you have to kind of just say over the VoIP or whatever that you're using and we'll get into that in a second is is this like hey you know why don't you sit on your hands for a second and why don't you tell me what you'd like me to do so I get a chance to type right it's a it's a it's a it's a ping pong thing it's a balanced thing if it's not basically if there's someone's a keyboard hog or I don't want to pair or the thing to avoid the real thing to avoid it's a real big social problem that's just gonna end in tears it's special people who don't need to pair because they're so fucking smart that they're programming dicks are so big that they don't have to pair with anyone but everybody else does that's that's that's fucking bogus that's that's completely bogus it generates bad feelings there's one smart person everybody else is dumb who's a couple smart people everybody else is dumb don't fall into that temptation I've worked at two jobs now that have done that it generates bad feelings about the people who are special and rightfully so someone doesn't want to pair kick them the fuck off I don't care how smart they are there's lots of smart people and you can find some with more humility the problem with people who don't have humility who won't pair is they won't admit to mistakes they'll cover up mistakes because they they have to sort of exude this image of being like the most awesomest programmer on the planet or whatever so these are the people who be who be like yeah select is broken on Solaris right my program's not fucked up select on Solaris is broken select not broken select is not broken your code is fucked up but this is kind of shit you hear from people who don't have humility it can't be my fault my programming big dick is this big right and if I admit to any mistakes yeah right it's just gonna like reduce me in the eyes of my peers this is a real social problem like joking about it but this is a real social problem if you see us on your project open source or otherwise get rid of that person either make them change or get rid of them it's it's ultimately poison test driven development I think is probably one of the best things to happen to software development since I don't know when since like 4gls or something it's really really quite amazing so let me try to go through this relatively quickly so the first thing you do to start with a failing system test like I said you have a feature like the negotiation has to finish right so how let's say it's a joy a joy Vabber client a jabber VoIP clients good thing I didn't drink any caffeine or otherwise it'd be totally incomprehensible so how would you write an automated system test for that well how do I not miss this but what you could start a server background the process a little basic kind of server starts your client basically and have them say hello to each other and you can verify that that works and then when the test is done when the client is done the server exits and etc etc right that's pretty easy so you start with that right and that you're failing sort of your failing system test that's going to do that your main goal in life is to make that test pass anything else is a distraction so once you have a failing system test you go into failing unit tests and this will make some more sense when we get into it when we start programming you have a hope and still no that's okay all right good Luis have been fucking with me all day so I just thought he was screwing with me a little bit so yeah so you have your failing system tests then you start writing failing is a TDD is you you have a you want to write new code to make a test pass basically so you start with a failing unit test that probably with brand new code show the failing you test that doesn't even compile right the method does the function doesn't exist the class doesn't exist etc etc right you start with the simplest test that could possibly work in the case of a stack for instance you make a new stack and verify that it's empty right stack doesn't exist and is empty doesn't exist and so you go and implement those things to do the bare minimum to make it work and so the simplest thing do the simplest thing that could possibly work not the stupidest thing that could possibly work this is not a license to sort of duplicate large swaths of code and to continue to produce shit just because you have tests basically right so you have a failing test you make it pass and then you refactor this is what you have to do otherwise you're gonna have lots of tests first code that is still shitty basically and you can't maintain the code and you can't maintain the test and the system is still very brittle it's a very important component basically you have to kind of do all these things together and so there's kind of a rhythm to TDD and that's like test a little code a little test a little code a little test a little code a little refactor to eliminate duplication etc etc make to make and then make the so it's like failing test passing it's called red green refactor it's called the stop light pattern if you read Kent that's Kent Beck's book red green refactor it's called stop light pattern basically and you just repeat this until your system test passes right so that's a kind of rhythm basically that you get into and once you and it seems really slow to get into the rhythm basically and you're like okay boom boom boom boom and so it's red green refactor because in the tools failing tests it gives you red and passing tests gives you green you talk about the green addiction I think we have to show it okay we'll show it and always will commentate upon that though things really great about TDD is it just works there's none of this like you know spending lots of your time in the debugger trying to figure out what the hell is going on in your program I personally find that extremely tedious and boring I like to write code debugging is not writing code basically like I like to write code like to write very clean code and when I have when I'm in the debugger I am frustrated basically because basically that meant I took too big of a step without tests or something like that and and do you want to talk about that sure go for it so you work in in these small incremental steps and when when I started noticing that that things weren't really going as slow as I had originally thought is because I had an opened up a debugger at all we were coding for I don't know like eight hours straight and not once it have to open up a debugger and I'm not the type of person that is shy about a debugger first time I see any kind of code if I even if I source the first thing I'm gonna do is I open up an IDA I start all idea whatever I look at stuff better in assembly a lot of the time than I do in source so this was really surprising to me and so what we started doing is just do little little incremental changes you add one method and test that make sure that the interface is working and then then that's solid you can move on to something else so it's kind of like you have all these little modules you test this module here everything is working fine you can set it aside you don't have to worry about it anymore then you move on to the next thing and it's like building blocks as you have it like it's like a pyramid you start putting things together one after the other after the other and then finally you have this complete solution and you can if you want to replace a block you can place a block it's not going to all fall down yeah if it does you know yeah your test tell you everything you you do one change you're like okay I'm gonna try to change let's say I'm gonna I'm gonna try a different protocol with with the server and you write that if it doesn't work your tests are gonna tell you and you could just revert it right back any change you make you'll know right away if it affects any other part of the program you don't have to worry about okay if I change the structure here it's gonna affect everything everywhere and it'll never compile again the the very wise phrase I can't remember where I read it it was probably came back around Jeffers if I say the code will tell you what to do the code will tell you what to do if you have a failing system test the code is telling you to implement a feature if you have a failing in a test the code is telling you to do the simplest thing you possibly work to implement that test if all your tests are passing and you make a minor opt would you perceive to be a minor optimization such as like changing a class to a struct or what have you now your tests start to fail you made like two-line change back back you're back to passing as opposed to oh god I guess they have to like figure out how to integrate this or you know just like coded for eight hours straight and now like everything's broken you don't know what to do your blurry eyed the crank that you snorted to program really fast is starting to wear off and you're like shit what do I do fuck I'll just have to revert eight hours wasted fuck that shit I don't like wasting my time maybe some people do again whatever your king happens to be different strokes make the world go around so it just works less debugging more coding if I can hate debugging hate debugging programming by intention the other thing with TD is that since you're like since basically you're writing your tests first you're getting like real a bird real birds eye view of kind of what the code's gonna look like when people other people go to use it basically so if it takes you ten lines of code to make a connection to the jabber server or whatever I keep using this example but run with me here right big if it takes ten lines of code your API is wrong it's design feedback on your API you get that from writing the test first so by starting out with a good API that's clean from a consuming in test kind of perspective you basically get all the advantages of if you had molded in you know now for six months with no code written whatsoever or did like God's own design for a jabber client with no working code it's not only do you have a very clean decoupled really maintainable and extensible design because you had to write the tests first and for things to be testable they have to have those design qualities you don't have that you have working code and regression tests at the same time it's really fucking badass and this is a thing something that people kind of I think don't get when they read about TDD it's more of a design methodology than a testing methodology it's like testing is for QA testing is for whatever blah blah it's like okay so your job is to write shit that doesn't work all right if you want to admit that see how we're see how far they get you in your career like maybe you know I may be in government work actually anyways but probably you know you don't want to say that out loud and so if you kind of like start to think about it yeah I probably should make sure that my code works so I don't waste my peers time right or I don't fuck up this open-source project and look like a complete dunce it only takes a little bit of foresight to sort of like oh if you do like have a little conversation in your head basically and you realize oh why do I think that why do I think testing is for other people and not for me writing the code it's a really bad kind of social thing that's been kind of persisted through the years I don't understand why anyways and so writing things a TD to make sure you're programming by intention things work because you intended them to right how many people here have been writing code and you think that you're not done but all of a sudden things work and you're like why is this working one two three four five six right that's just as bad as if you expect it to work and it does it basically you're no longer one with your code you don't know what's going on that's a bad place to be that is a very slippery slope and when things work when you don't think that they should that that that's just as dangerous as the opposite kind of situation right and that's called programming by coincidence that's a pragmatic programmer thing which is a really great book pragmatic pro the the pragmatic programmer they got programming by coincidence it happens to work I'm real happy yeah right I just happen to not have diabetes does that mean I'm not going to go to my doctor no right so incremental design so TDD can leads an incremental design emergent design as it's sometimes called and this comes down to what I said earlier the code will tell you what to do it's is very simple very wise thing it says by the way I hope you know this is we're talking about like methodology we're talking about code we're not talking about plans and designs and documents and bullshit we're talking about writing code staying in code as much as possible and getting as much done as possible about wasting time if you like to write code and you and you like to not waste time this is really what you should be doing basically anyways so there's a couple things with the emergent design and TDD right and one of the things is that if if you can't test if something's difficult to unit test if you can't test it it's wrong your design is wrong get over it make it testable if you can't test it if you can't mock out the sockets or you can't do whatever you're you're you're wrong basically and you set to own you have to set up that and go okay it's difficult to test that doesn't mean unit testing sucks that doesn't mean that like the unit testing tool is broken which is similar to the select is broken thing you have to go okay this is this is the test code giving me design feedback I need to consider this and figure out how this can be made easier to test right or how it can be made to be testable if it's not testable your design is wrong you have close coupling inappropriate intimacy I know coupling and intimacy that's really funny I didn't make those up those are object oriented weenies came up with that like in the mid 90s and it's in the design patterns book thinking of four book and stuff like that having a design with these problems with coupling problems and appropriate intimacy in circular dependencies means you're in for a world of pain just like in the big Lebowski right if you're a Vietnam Billy this is what happens when you fuck a stranger in the ass you're hitting for a world of pain basically and this is the test telling you right now when it's easy to change once you have a lot of code all based around design changing it becomes much much more difficult especially when you have coupling and like inappropriate intimacy and circular dependencies good luck refactoring that this is what this is where people hit the brick wall they're like shit we have to rewrite everything now we have to start over from scratch maybe reuse some of the code or whatever every every every read I've ever seen has always introduced more bugs and it solves basically because you're not giving yourself the feedback loop you think you've learned your lessons there's less of salient details you have not picked up on as far as the feedback from your design I don't care if it's in UML or whatever the tests tell you what to do the code will tell you what to do as far as your design so the other thing is fake it till you make it right do you need to come up with a complete implementation of the jabber protocol to pass this one test of the handshake finishing no you don't if it's not encrypted do you need to like write use an SSL library or whatever no it's all about scoping scoping your stories down to the point where it's like a small chunk of functionality it's gonna be easy to easy to implement basically and so and so one of things you can do is you can fake it till you make it basically and we'll get into that when we start writing the test but basically doing the simple thing could possibly work like if you're writing out one test that expects a certain method to return zero and just make that method return zero right and then you write another test that expects one or some other return value that's when you that's when you generalize basically don't generalize up front we don't design up front we wait for the code tell us what to do let me see so Lynn eliminating duplication how many people here have seen like probably I don't know entire functions duplicated across a project like maybe 10 plus times yeah how many people here think that's fucking retarded yeah you're right you're not wrong basically and so eliminating duplication that is another thing the code will tell you what to do you have duplication there's two there's two different kind of acronyms there's DRI we just don't repeat yourself and it was once and only once OO AO which are to a programmatic programmer kind of things so don't repeat yourself if the code is repeating it's if there's more than one source of information for a particular kind of information in the system there's something wrong in your design it's it comes down to read to call it to sort of encapsulating responsibility for certain things effectively or coming up with a generalized class design or whatever but sharing code is good for the most part if you don't do it stupidly and so limiting duplication is one of the best things you can do to improve your design this is another that then without tests even forget TDD if you see duplication you factor so there is no duplication the code will tell you what to do to improve your design and improve your code you just have to stop thinking you're incredibly clever and pay attention and listen to the code testing them in a coupling and inappropriate intimacy so coupling is basically if you have like two classes basically right and they call into each other all the time right it's really close coupling basically it's kind of like there's like almost like a a sewing pattern design these two between these two classes and basically they're useless without each other that's coupling basically and it doesn't make for a very versatile design and I'm not going to go into why that's a really bad idea hopefully it's somewhat obvious if anybody has any questions come talk to me later and I'll explain it to you inappropriate intimacy is similar where like basically one component of your of your app knows a little too much about the internal workings of how this other thing works like it knows too much about like it knows that oh it goes eight characters in ads five and does whatever to come up with its with its IV for its encryption or whatever you don't want to have those details spread throughout the system that comes down to once and only once the details of how that is done should be expressed once in the system right and so sometimes you write tests that know a little bit too much about the underlying class or whatever and you want to kind of pay attention and avoid that also for the sake of brevity I'll move on but if you have questions let me know okay so then there's cohesion so I'm talking too much so we're going to skip to the next slide continuous integration build your software all the time you have an automated build it runs once a day run it all the time there's no reason not to why wait until the way wait why wait until 12 a.m. or 5 a.m. or whatever your build runs to find out if that your code doesn't compile your tests are failing if you have an automated build run it all the time it's just kind of common sense basically you don't have to have you don't have to have a dedicated build machine you can have a shell script that does an SVN update compiles the code runs that runs the unit tests and then runs the system tests that's like a four-line shell script let's see yep oh the cool thing is that you know whose fault it is it's like oh there are 50 check-ins that day from a hundred different developers whose fault is it I don't know you could go look at diffs for like eight hours to try to figure it out when you have a continuous build that runs all the time there's probably only a couple of check-ins that have happened since the last build right so you're gonna know who broke it and then you know who to kick in the balls basically so we see so tools basically stories you don't need anything fancy for to do storage you just have a wiki basically orange source for it they have a feature request tracker which is a good place to store stories things like that you don't need a commercial tool or anything fancy some people just have a little text file in their source control repository pair programming remotely you just need a remote desktop software Luis and I like tight VNC rather than tights that's right just like your mom and your dad yeah we prefer tight VNC it's an open-source thing it's got a lot of cool optimizations it just works really well real VNC is still usable and you know you should use it on Mac OS there's a there's a couple of VNCs that you can use tight VNC doesn't run on Mac OS just yet if you're pairing between different Mac developers so here's here's some command line options I found to be useful dash BGR 233 is the best by the way it takes 16 bits 16 bit color information and puts it down into 8 bit color information but it doesn't look really really weird dithering wise and that's really handy if you have if you're pairing with an open-source developer say in India or whatever where they have got kind of limited bandwidth coming into the country or someone's on a dial-up this is still utterly doable that's a little it might look weird depending on the colors and the ID syntax hiding you use and stuff but check it out it'll basically work audio check also do it within a VM wires and so you can you don't have to worry about sharing your whole desktop you can do you can have a VM wire session running and then also tunnel all the VNC over SSH yep it's possible to do this highly securely if you don't trust that developer in India or Pakistan or Germany or wherever or the US for that matter another really key component is audio chat and there's a bunch of free audio chat stuff that you can do basically but kind of pair programming like being in the pair programming and having like switched to an IM client in the middle of writing code like communicate doesn't work I tried it it seems like it would be okay but it kind of doesn't work and so audio chat is really kind of a necessity and so there's free stuff you can use so jabber has a thing called jingle which I guess was developed by Google that developed by Google yeah and so there's a lib jingle and so co-peat with my personal preference 0.12 implements this game 2.0 implements this Google talk is technically not open source but I figured I mentioned it anyway it also implements that if you're not totally worried about completely using 100% open source stuff there's also GNOME meeting which uses H323 or whatever it is and I can also interact with that Windows thing I can't remember what it is net meeting thank you and there's also Skype which is not open source please forgive me but it's still very useful it gets it's still useful tool there's a Linux client as a Windows client et cetera et cetera web cams are not necessary don't waste your bandwidth with web cams what the fuck are you gonna do sign language to each other like if you're working with a dev developer fine but if you're not web cams are waste of time it's a waste of bandwidth you want your typing to be very responsive you want your audio chat to be very responsive all right I talked for too long I'm sorry so we do we have time for questions where's the person where's two minutes four questions do you want to ask questions or do you want to see us demo this real quick Jesus fucking Christ so the rest of the slides kind of document different tools and things like that it is good so the SVN repo for this project is on source forage at that URL right there it's not in the slides because we wanted to release it exclusively a black hat and def con so it's on the printed slide so if you're so interested write it down it's not going to be it's not on the CD so system test failing how are we going to do that let's show you see that's a good idea yeah no work is unreachable all right no problem it's just not at her anymore is it oops all right so what is it it's okay whoops caps lock on sorry about that sorry about that all right cool so for some reason in kubuntu when I do dual monitors they will only do 640 by 40 anybody who knows how to fix this please let me know so that the talk tomorrow is in greater than 640 by fucking 480 but just but just to show like like his his laptop is some ungodly 16 by 9 resolution that's like really huge but just goes to show like I can still see I can still see the code I can still interact in fact I was in the Minneapolis airport stuck because of united airlines who suck balls and Luis was like I have this compile problem not sure what to do I was able to use palm vnc on my trail to vnc into his thing while I was talking with him on the phone and go oh you're using parents and you use less than greater than that's pretty badass in my personal opinion so anyways so we can see the code here and so so this is a a all right it's a vnc connection basically and so the system says that we have our one with a simple python script that will show very briefly for 30 seconds these are the unit tests this is the green you get addicted to the green every time you see more green it's like you're doing something right every time you see the red you're like oh shit that's really what it comes down to and every time you see the green you're like yes everything I just is 100% correct and I know it it's a real ego boost that's basically why there's no other way to work in my personal opinion so the system tests so we'll show the rest later at the next talk which is on Saturday at 8 p.m. assuming that those start on time etc etc thanks