Thursday, September 22, 2011
Monday, September 12, 2011
HOW DO WE MAKE THIS HAPPEN
Or, for the nerdier caption, "I hope this is in IPv6."
(source: uh, tumblr. all of it.)
Thursday, September 8, 2011
Why don't we learn programming by example?
A lot of the past year I spent in a highly concentrated study of programming. I've been learning both the semantics of programming languages and the high-level art/philosophy of coding.
And there's a lot of advice flying around. It doesn't take you long to discover that programming is a field whose inhabitants are keen to look at it not just as a job, but as a highly important zen/philosophical/artistic way of life. They care a lot about how you code. Comment your code, don't overcomment your code, use top-down design, use bottom-up design, code for readability, code for efficiency, use descriptive variable names, refactor often, modularize everything, and don't break out of a loop early unless you turn around three times and spit first.
I'd certainly like to follow all of it. I'm trying to synthesize it all into some idea of the right way to do it. But something I notice is that there are terribly few examples to go by. I find it odd that the experience of learning programming, be it from a school, a book, or a website, is not full of examples of other people's real-world programs.
I've realized that learning to write well-written code is very similar to learning to write well-written English. It's hard to declare rigid rules that you can just follow to get there. There's plenty of advice, but advice in a vacuum isn't extremely useful. You need positive examples of good writing. A lot of what makes effective writing is that it's easy to follow for people used to it being laid out in a certain way. It also uses constructions that are efficient and effective. That's for both written English and written programs.
You learn to write English well by reading books and essays written by the masters. But you're supposed to learn to write code well by.. writing code. I find it strange that there aren't far more examples of well-written programs in books and university classes. There are whole books and websites of collections of essays and stories! Why not programs? There are certainly enough people who care about it, let me tell you.
This post was prompted by reading an essay by Steve Yegge on overly-commented code by novice programmers. I'd always heard people putting an emphasis on well-commented code, so it was interesting to hear the arguments for why it can get cumbersome. I thought it was compelling, and I'd like to put the advice to use in my coding. I want to learn, Steve Yegge! Really! So please, just show me how it should be done! I want to be an E.B. White or Christopher Hitchens, but I can't do it without examples!
And there's a lot of advice flying around. It doesn't take you long to discover that programming is a field whose inhabitants are keen to look at it not just as a job, but as a highly important zen/philosophical/artistic way of life. They care a lot about how you code. Comment your code, don't overcomment your code, use top-down design, use bottom-up design, code for readability, code for efficiency, use descriptive variable names, refactor often, modularize everything, and don't break out of a loop early unless you turn around three times and spit first.
I'd certainly like to follow all of it. I'm trying to synthesize it all into some idea of the right way to do it. But something I notice is that there are terribly few examples to go by. I find it odd that the experience of learning programming, be it from a school, a book, or a website, is not full of examples of other people's real-world programs.
I've realized that learning to write well-written code is very similar to learning to write well-written English. It's hard to declare rigid rules that you can just follow to get there. There's plenty of advice, but advice in a vacuum isn't extremely useful. You need positive examples of good writing. A lot of what makes effective writing is that it's easy to follow for people used to it being laid out in a certain way. It also uses constructions that are efficient and effective. That's for both written English and written programs.
You learn to write English well by reading books and essays written by the masters. But you're supposed to learn to write code well by.. writing code. I find it strange that there aren't far more examples of well-written programs in books and university classes. There are whole books and websites of collections of essays and stories! Why not programs? There are certainly enough people who care about it, let me tell you.
This post was prompted by reading an essay by Steve Yegge on overly-commented code by novice programmers. I'd always heard people putting an emphasis on well-commented code, so it was interesting to hear the arguments for why it can get cumbersome. I thought it was compelling, and I'd like to put the advice to use in my coding. I want to learn, Steve Yegge! Really! So please, just show me how it should be done! I want to be an E.B. White or Christopher Hitchens, but I can't do it without examples!
Tuesday, September 6, 2011
Visa's post-credit-card-fraud strategy a bit odd
I recently got notified by Bank of America that they'd detected fraud on my account. Meaning someone nasty got a hold of my info. They told me they were changing my card number and mailing a new one to me.
So today I got it and noticed that they'd only changed the last four digits. Having spent a lot of time this year thinking about security (thanks, Security Now), this struck me as strange. Have you noticed how the last four digits are the ones everyone seems to just give away anyway? On receipts, online banking, mailings, etc., they always indicate your card by writing "XXXX XXXX XXXX 1632."
I used to think they accepted the lowered security of those last four because you still had the other twelve that are never given out (ignoring the fact that the first ~4 are entirely deterministic). But now I can assume there's someone out there with my old number, and the only thing Visa gave me to protect against them is those last four, weakly guarded digits.
Now, I know the chances of this person ever finding those last four are vanishingly small. It's probably not even someone close by, and they're not going to be going through my receipts or mail. Plus, I omitted the part where the CSC (those 3-4 digits on the back) is also different. So I'm not actually worried.
It's just funny that while cybersecurity people are arguing about researchers who figured out how to break AES encryption in 190 quadrillion years instead of 760 quadrillion years, in the credit card world they're pretty much saying "Hey c'mon, what're the odds someone finds all four of these digits?"
And hey, maybe they're being a bit more realistic.
image credit: clanao.com (Google Images)
Subscribe to:
Posts (Atom)
