iRi pending.en-usWed, 16 Sep 2015 00:35:55 -0000 Not too long ago, flying could be a relatively pleasant experience, but executives focused on ... <blockquote>Not too long ago, flying could be a relatively pleasant experience, but executives focused on cutting costs have stripped away everything flyers associated with luxury or even dignity. Food, baggage handling, boarding in a logical manner: Things once taken for granted now must be paid for or done without. Flights are more crowded than they’ve been since World War II, when they were carrying troops. And on a recent Ryanair flight, I discovered that not even water was free. - <a href=''>Why<br /> Does Air Travel Make People So Grumpy?</a></blockquote> <p>There's a lot of money out there for someone who solves one of American-style capitalism's core problems... how do I signal to a corporation that I'm willing to pay slightly more to get service that doesn't have all the corners filed off? And how do we make this palatable to people?</p> <p>I don't mean premium service. I mean just that... service without every corner cut. If I'm buying a $100 item, I'd rather pay $110 for something where they used metal for the critical component instead of plastic, or quality metal instead of cheap metal. I'd rather pay the pennies more for quality screws that won't rust closed in a year.</p> <p>In theory, airlines have solved the problem. With many companies you can easily pay another ~20% of the ticket price for "enhanced economy" seating, with more legroom and better seats. But that's obviously not preventing the stream of complaints, so obviously it's not a palatable solution.</p> <p>Is there a solution at all? If consumers at scale simply pick the cheapest option regardless of anything else, the answer is no. The market can only go in one direction, and given that that leaves the service providers with no other option, it is hard to blame them in good faith. But I'm not ready to make that call.</p> <p>There are some other ways that seem to at least partially work. You can go to Wal-Mart and get something with <i>all</i> the corners cut off, plus a few bits of the core product, but you can also go to Target and get something that is cheap, but not quite <i>that</i> cheap. Supermarkets also now have so many products on the shelves that you can almost always either buy the cheap olive oil, or a more premium option.</p> <p>But there's still a lot of markets where price is relentlessly driven downward at all costs (pun half intended), and it would be great if there was some reliable way at scale to coordinate a difficult-to-forge signal of quality that said "This has been made cost-effective, but not actualy 'cheap'".</p> <p>Solve that to make a lot of money.</p> (jerf)Wed, 16 Sep 2015 00:35:55 -0000 It is impossible to deeply understand a solution before you have the problem. Let me ... <p>It is impossible to deeply understand a solution before you have the problem.</p> <p>Let me give you an example that probably all my readers can relate to: Mathematics education. Do you remember first seeing the quadratic equation and wondering why you should care? Or even if you were a math nerd like me, can you understand why someone would be asking themselves that at that point?</p> <p>The problem is that the students have not had the problem. For one thing, all the quadratic equations they've been solving were simple ones with integer solutions. For another, even the factoring problems themselves were artificial; they're not factoring because they've encountered a real life problem that requires a factoring solution, they're factoring because they were given homework. It's hard to care about the quadratic equation when it's a solution to a problem you don't have.</p> <p>Also, the problem is recursive in mathematical education... students don't care about the quadratic expression, because they have no quadratic equation problems, except in school. They don't care about the quadratic equations because they only needed to work them to learn about polynomials, which they have no reason to care about, except that it was homework. They have no reason to care about polynomials, except that they were assigned to teach algebraic manipulation, which they have no reason to care about except that it was assigned in school... and so on, recursively, until you arrive at simple arthimetic at which point most people would agree that it corresponds to real life.</p> <p>In some sense this is the complement to the classic <a href=''>Lockhart's Lament</a> in which a mathematician observes current math education is nearly worthless from a pure mathematical point of view; I observe that it is also nearly worthless from a practical point of view. The ideal education would encompass both, an education that at least covered <i>one</i> would be better than what we have now, but we offer neither.</p> <p>As is my way, this theoretical-sounding observation can easily be converted into practice, informing both how I teach myself and others. For myself, when learning something I give the documentation a good skimming to sort of load in the "table of contents", then I just charge in. When I encounter a problem, I go back to the documentation. If what I'm using is solid and the documentation is well-written, I'll find the solution to my problem. It will be in some feature or command that previous did not fully make sense to me (proved by the fact that I had the problem in the first place), but now it will make complete sense, because I've actually had the problem it was trying to solve.</p> <p>At work the amount of time I spend training others is slowly-but-surely increasing, and this observation very strongly informs how I structure my training. The fact is, most "training" fails, because the average training session consists of trying to essentially read out a glossary and then reading out the solutions to some problems. This is a waste of time when the trainees have never had the problems you are giving them the solution to.</p> <p>Solution: If at all possible, give them the problems. Right now I'm training people on <a href=''>git</a> at work, and despite the abundance of tutorials on the topic I still ended up writing my own training course. I find most tutorials consist of huge blocks of text explaining the basics of git, then they offer various solutions to source control problems, then that's the end. And I have found most people's idea of what being "trained on git" means is that we'll pile into a room, I'll stand in front of some slides gesturing wildly reading these things off, and then by presumably Magic they'll all know git by virtue of having heard some words.</p> <p>That is not how I run this training. Instead, I make sure everyone is in front of a computer. We all create a repo and follow along, issuing the same commands to the repo. And I do not cover the happy path of what happens when everything is working properly; in fact I probably spend more of the presentation in error conditions and confusing situations than I do things working correctly. People need to know why adding something before switching branches does what it does. People need to learn how to deal with the "detached head" state. People need to learn what to do when a branch is merged and there's a conflict. They can't understand the solutions until they've had the problem, so if you hope for people to walk away understanding the solution you have to have given them the real problem, too.</p> <p>If you're a programmer, hopefully that makes sense to you. Yeah, the problems themselves are still ultimately artifical, but hopefully it's still enough to trigger recognition when they occur for real. If you <i>aren't</i> a programmer and the last few sentences of the previous paragraph were so much gibberish, well, I ask you to imagine what use it would be to you if I were to describe the solutions here. You can't understand, partially due to glossary issues, sure, but also because you are <i>so far</i> from having those problems that you have nothing to hang a solution on to.</p> <p>It's early going yet on whether this training is sticking, but early results are positive. I'm seeing better uptake on these topics than I was expecting.</p> <p>I also have to admit it's a bit funny to hear how completely unused to being pushed into problem situations people are. I explain up front that I'm going to work us through some problems, but I've found people often still end up surprised when I tell them to type something and git yields an error. It's clearly a violation of deeply-held expectations.</p> <p>At some point I'm going to be delivering security training, which also has its own long, sordid history of failure. For that, I plan on pursuing an even more advanced variation based on this observation: The most important result that security training can have is for the developers to come away <i>aware that they have a problem at all</i>. The vast bulk of security failures can be traced back to that core issue, that the developers didn't even realize they had problems, because they aren't jumping up and down in front of them wearing a sign that clearly labels it as a problem. It is the thinking on that topic that led me to write <a href=''>my previous post</a>. Security issues are about more than just not making the "top 10" errors, it's about realizing that frankly the deck is utterly and totally stacked against you in almost every conceivable way, that dealing with that problem one line at a time is virtually impossible, and that we must start with recognizing these problems before we can even start solving them.</p> <p>Providing solutions in training is a <i>distant</i> second-rate concern in this case; if developers realize they have problems, they'll seek out and create solutions. Solving problems is what they do, after all. It's that first clause of the "if" where the problem lies.</p> <p>I hope this can help you improve your own training, and any teaching you may do for others.</p> (jerf)Fri, 23 Jan 2015 20:18:18 -0000 It&#39;s 2015. Why do we still write insecure software? <p>I've read a lot of programming blogs, and if you're reading this, you probably have too. So let me tell you up-front this is not your usual security rant that boils down to "just try harder!" Let's talk about smart, experienced programmers who are trying to write secure code, even if they are not security "experts" per se. This is an important set of people, because there is more security-related software in the world to write than can be written by security experts.</p> <p>In a perfect world, setting that as the target audience would conclude this essay. As your browser's scrollbar shows in the full view, this essay continues on for quite a while. Alas, decades of experience and a trained reasonably high intelligence are not sufficient to write secure software in the current coding environment.</p> <p>That's also the highest amount of qualifications that can be feasibly brought to bear at any reasonable scale, so in practice that's equivalent to saying it's impossible to write secure software in the current coding environment.</p> <p>Let's talk about why it's so hard. My thesis is simple:</p> <blockquote>We write insecure software because our coding environment makes it easier to write insecure software than secure software.</blockquote> <p>But exploring what it fully means can lead some surprising places. Please join me on a journey as I try to show you why that is not trivially true, but in fact, <i>profoundly</i> true. We do not occasionally pick up insecure tools, like a broken encryption routine or misusing a web framework; we are fish swimming in an ocean of insecurity, oblivious to how steeped in it we are.</p> <p><a href="">Read the rest...</a></p> (jerf)Mon, 19 Jan 2015 15:07:07 -0000 I thought I&#39;d use Prime Music to explore some classical I hadn&#39;t gotten around to ... <p style='text-align: center'><img src='' alt='You are listening to Symphony Number 1 in E Flat Major, K 16. Allegro molto. Customers who bought this song also bought: U Can&apos;t Touch This by MC Hammer' /></p> <p>I thought I'd use Prime Music to explore some classical I hadn't gotten around to yet. You know... Mozart, some stuff by Beethoven I haven't heard yet, Bach, MC Hammer... you know, the classics.</p> (jerf)Fri, 12 Dec 2014 15:12:09 -0000 Only a poor student of history could fail to notice history&#39;s cycles. The future can&#39;t ... <p>Only a poor student of history could fail to notice history's cycles. The future can't be fortold in detail, but asking the question "Where are the cycles taking us?" gives you a better chance of guessing general shapes than anything else I know.</p> <p>So it's easy for a student of history to look out at the United States and guess that we're approaching a libertine peak, and that over the next couple of decades we should expect to see the pendulum swing away from the wild excesses of the Baby Boomers back in a more "conservative" direction.</p> <p>But at my age, I've never <i>lived</i> through a shift. So had I guessed how the counter-libertine shift would occur last week, I would have guessed a gradual cultural waning of the libertines and a gradual cultural waxing of those of a more conservative bent, with the advocates not changing their own views but their relative influence changing over time.</p> <p><a href="">Read the rest...</a></p> (jerf)Wed, 15 Oct 2014 22:33:55 -0000