Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
everyone my name is James garlic I go by let me just make sure this thing is on so I go by James garlic everywhere online Twitter github Instagram freenode my blog is James Bala comm very easy to find online and I work 24/7 so you can always reach me there
I work for a company called compute ology we make a product called package cloud where we do apt yum and ruby gem repositories as a service if you have a need for public or private package repositories or both definitely check us out come talk to me if you
want to talk about packaging I would venture a guess that I will probably get more excited than anyone else in this room about talking about packaging so people say this right somewhat often programmers say this right and there's been a lot of talk on
my Twitter recently and on some blogs and stuff about whether we should stop saying this or suggesting that we should stop saying this and I think it's important to distinguish between people who say this in sort of a moment of frustration and outburst
of frustration because what we do for a living can be very frustrating right there's pressure on you got to ship something something's broken you get frustrated you tweet something whatever and people who who actually legitimately believe that everything
is terrible right I was gonna pull my eye phone out of my pocket right now but I'm not allowed to have it on stage and show you my iPhone and be like I have a supercomputer in my pocket that can literally sum in nearly any media that was ever created via
the air that's not terrible that's awesome right but as much as I think that you're wrong if you legitimate ly believe that everything is terrible I think that you're probably at the very least naive and possibly being a little bit disingenuous
if you don't admit that everything is broken and I don't mean that nothing works obviously stuff works right but the reality is the software is buggy and it's flaky and it's unreliable despite our best efforts to make it better and this actually
makes sense right we're innovating really fast we software the software engineering is a relatively new field we're still figuring out how to do it and we really just haven't caught up with the pace of innovation and growth in our industry and
you know we're still working on it right so it makes sense that everything's broken and as a result of everything broke it being broken when you get engineers together in a room or online one of the big topics of discussion is always well how do we
write better code right how do we how do we actually how do we produce software that's less unreliable or that's more reliable or rather that's that's more correct that that works better that handles edge cases better so all these different
techniques for doing that right there's you know testing obviously very popular in the Ruby world static analysis and then you know stuff like what MRB was talking about this morning where with new languages that have more sophisticated type systems that
are capable of more accurately expressing the constraints of different units inside of our programs but one thing that we don't talk about that much or at least in my opinion that we don't talk about enough is how do we cope with and what are what
are the strategies for dealing with software when it doesn't work whether it's our code or someone else's code I said this the other day on Twitter if you want to deploy high quality software that performs you should expect to fit fixed bugs at
every level there's a very simple reason why bugs exist at every level and so given enough time given enough complexity you're gonna run into those bugs and either you're gonna fix them or they're still gonna be broken so over the last few
years I fixed a bunch of bugs and a bunch of different levels of the stack obviously lots of bugs in my own code but bugs in the Ruby VM bugs in memory allocator is my sequel all kinds of places and I always get this question people asking me like law how
did how did you find that bug how do you go about finding a bug in a codebase you're unfamiliar with how do you go about finding a bug in a language that you don't know very well and I realized over the years that the methodology that I use for debugging
is always the same it doesn't matter where in the stack I'm looking it doesn't matter what the language is it doesn't matter whether I even know the language really it's always the same methodology for debugging and it's very very simple
so that's what this talk is about every good debugging session starts with this quote this this is a mantra among programmers so someone maybe it's your boss maybe it's a user maybe it's a friend comes to you and they report a defect in something
[ ... ]
Nota: se han omitido las otras 2.309 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.