21–30 of 51 posts
Earlier quoted context omitted.
a friendly guy reported to tarsnap that you could sign up without needing the emailed confirmation link by creating that same confirmation link yourself with the cookie/token being hidden, but present in the HTML code. That's a decent summary, but I didn't think I was all that long-winded...
Maybe the guy who found the bug won't get $1000, according to your rules, but he definitely deserves a cookie.
The value of writing comments intended for your future self was confirmed in a strange way for me: I once found myself googling some faintly obscure question of systems programming, and soon found an article that answered my question perfectly. At that point I noticed with considerable surprise that I was reading a web archive of a Usenet posting I had made myself, some 10 years prior - of all the people to randomly…
I take away a different lesson, though: even simple web security is easy to get wrong, even for a very smart, very talented developer. I'm not sure what the solution is, though.
As for the comments, while I don't take a hard line here, I agree with Bob Martin's quote: "Every time you write a comment, you should grimace and feel the failure of your ability of expression." Wherever possible, you are better off rewriting the code and variable names to clarify in the code itself whatever you wanted to say in the comments. It's hard to say how to accomplish that here without knowing more about the code, though. And it may have been so difficult that a comment was the right choice.
I love writeups like this, and enjoyed the level of detail Colin provided. I take away a different lesson, though: even simple web security is easy to get wrong, even for a very smart, very talented developer. I'm not sure what the solution is, though. As for the comments, while I don't take a hard line here, I agree with Bob Martin's quote: "Every time you write a comment, you should grimace and feel the failure of…
$config->{template} = $container->template;
(There's no spec for the file format - all have the `template` key in the `container` section but some also have it in the `config` section. Since I can't change these files, I have to deal with the duality. But you'd never be able to guess that from this code without a comment.)
The value of writing comments intended for your future self was confirmed in a strange way for me: I once found myself googling some faintly obscure question of systems programming, and soon found an article that answered my question perfectly. At that point I noticed with considerable surprise that I was reading a web archive of a Usenet posting I had made myself, some 10 years prior - of all the people to randomly…
I love writeups like this, and enjoyed the level of detail Colin provided. I take away a different lesson, though: even simple web security is easy to get wrong, even for a very smart, very talented developer. I'm not sure what the solution is, though. As for the comments, while I don't take a hard line here, I agree with Bob Martin's quote: "Every time you write a comment, you should grimace and feel the failure of…
I love writeups like this, and enjoyed the level of detail Colin provided. I take away a different lesson, though: even simple web security is easy to get wrong, even for a very smart, very talented developer. I'm not sure what the solution is, though. As for the comments, while I don't take a hard line here, I agree with Bob Martin's quote: "Every time you write a comment, you should grimace and feel the failure of…
Code can only tell you about the implementation - never the intent. Taking an example from my code yesterday: $config->{template} = $container->template; There's not much can be clarified here, I don't think. But it tells you precisely nothing about why it's required in this instance. (There's no spec for the file format - all have the `template` key in the `container` section but some also have it in the `config` se…
Maybe in some purely technical sense this is true, but in a meaningful one it isn't. At an absolute minimum, names reveal intent -- which is why naming is so important.
Regarding your other example, you are always free to wrap what you don't control in objects that have the intention-revealing semantics (read: correctly named behavior) that you desire.
It's impossible to tell from that single line of code if there are other options as well (the surrounding context is missing, and that's where meaning comes from), but you always have some options. I'll grant that in some cases the cure is worse than the disease -- that is, the changes needed to truly reveal your intent in the code would lead to over-engineered complexity. But typically I find that is not the case.
The value of writing comments intended for your future self was confirmed in a strange way for me: I once found myself googling some faintly obscure question of systems programming, and soon found an article that answered my question perfectly. At that point I noticed with considerable surprise that I was reading a web archive of a Usenet posting I had made myself, some 10 years prior - of all the people to randomly…
Heh, I was helping a colleague with some question, and I wasn't really sure about the answer, so we Googled and checked out the top hit on StackOverflow. Wound up being a question that I had answered a couple of years earlier, and forgotten the answer in the meantime.
The only disappointing thing being that due to causality constraints, I was unable to upvote past me's answer or further past me's question, which was a shame as they were both really useful.
Earlier quoted context omitted.
Code can only tell you about the implementation - never the intent. Taking an example from my code yesterday: $config->{template} = $container->template; There's not much can be clarified here, I don't think. But it tells you precisely nothing about why it's required in this instance. (There's no spec for the file format - all have the `template` key in the `container` section but some also have it in the `config` se…
> Code can only tell you about the implementation - never the intent. Maybe in some purely technical sense this is true, but in a meaningful one it isn't. At an absolute minimum, names reveal intent -- which is why naming is so important. Regarding your other example, you are always free to wrap what you don't control in objects that have the intention-revealing semantics (read: correctly named behavior) that you des…
let thisIsAString = 1