I slipped for three days. Technically I’m slipping now because this post won’t have much to it aside from whines that I’ve been looking for a job and empty promises that I’ll do better.
I did want to share a good quote I read just now from a man named Dave Farell who was quoted on this site saying “The devil is in the details, but exorcism is in implementation”.
Ah, software engineering quotes.
I’ve been playing around with a neat little tip today that I thought I would share. I certainly can’t take credit for the idea but I like it enough that I’ll repeat what can be found elsewhere in the name of spreading the word.
The problem?
In a word: spammers. Grown in Petri dishes, their hideous forms climb directly from their incubation chambers directly to their computer room. Nobody who has looked upon their form has returned without their soul in tatters. Their sustenance doesn’t come from the vitamins and proteins that good, honest creatures take in. They thrive on the suffering of their victims and the hate that they generate. Through the wires of man they pull to them ancient energies long forgotten. Always in search of victims they constantly search for E-Mail addresses.
The solution?
Spammers, so hungry for their daily meal, want to find E-Mail addresses as quickly as possible with the least amount of effort. Therefore they don’t always look very hard. For example take this HTML link markup you might find on a webpage:
<a href=”mailto:jshmow@gullible.net”>Your name</a>
Did you see it? So did the spammer! Another victim’s productivity absorbed into a blob of advertising.
Moving on, the spammer tries another website:
<a href=”mailto:mcsmartpants@cool.com”>Your name</a>
The spammer squints, grunts, and moves on. When your browser looks at it however it says, “Oh my, I see we have a bit of a mess here. Let me just clean this up… there!” and when you click on the link it opens up a new message.
What’s going on?
If you look carefully at the second example you’ll notice a pattern. There is an ampersand (&), a pound (#), a number, and a semicolon (;). Together, they form what is called an HTML entity. In the encoded E-Mail, each character is replaced with an HTML entity. These are nice because they allow you to say you want a certain character just as it is without it being interpreted as something else. For example, the greater-than character (>) can be written in an HTML document as > or, like in the example above, >. These are both HTML entities that will display a greater-than sign without thinking it’s part of the HTML markup.
In the second example, we’re taking advantage of the fact that every character can be represented as an HTML entity because when spammers are looking for E-Mail addresses, they’re looking for at signs (@) and dots (.) and not ampersands, pounds, and semicolons.
Unfortunately this isn’t foolproof. Spammers get smarter all the time and there are almost certainly a number of them out there who know about this and have made the extra effort to interpret these E-Mail addresses properly. The nice thing about this technique, though, is that browsers have understood HTML entities for years so they won’t even flinch. This slows down spammers without slowing down people that want to E-Mail you as opposed to people who just want to E-Mail everybody.
How do I do this?
It’s easy. For each character of your E-Mail address, type &#number; where number is from the “Dec” column of this table.
Or if you’re lazy like me, you can use this script that I wrote. I understand if you don’t want to put your E-Mail address into that form. If you’re like me you don’t make a habit of putting your E-Mail address into strange web forms. If I were you I wouldn’t put my E-Mail address into my form either.
I realized today why I don’t like to drink caffeine. It’s a hack (as in like software). A quick and ugly fix that gets the job done until the time comes that it inevitably fails you and another hack is necessary. Sure, it feels good at the time but you know it can’t last.
On the other hand there are more complete solutions such as getting more sleep, eating healthy foods, and exercising. Just like best practices in software engineering I’ll admit I’m nowhere near perfect in this regard. I realize, however, that it’s a more thorough solution that gets at the root of the problem rather than trying to fix it’s symptoms.
I thought I would comment on a blog entry I read on “Why a career in computer programming sucks” since I’m in the process of looking for my first job as a software engineer. I pretty much agree with him, though I have a couple of comments.
Anybody who’s knows much about the field of software engineering knows that there are a lot of platforms, languages, and other tools out there to use. Generally somebody who wants to develop a product will choose a technology (for whatever arbitrary reasons) and stick with it for the product’s life cycle. This means that when they are looking to hire somebody to work on the project they’ll prefer somebody who has experience with that tool.
The author argues that programmers have “temporary knowledge capital” and that it is temporary because tools change often. This means the engineer has the choice of either learning another language or remaining with a language that grows more obsolete by the day. I’ve felt the pull of a familiar language keeping me from learning another and that feeling will no doubt get stronger as I get older. Nonetheless I don’t think it’s correct to say
“Actual coding is only 10% of the technical side of software development. The other 90% is knowing the the libraries and the idiosyncrasies of the tools”.
It’s my guess from what he says on his blog that he has spent a lot of time over his career learning many new technologies and that it has biased him to thinking that this is much of the work required toward being proficient in one language. The fundamental skills of coding, I would say, constitue 80% of the learning while learning a given language takes the remaining 20%. I can say this fairly accurately as a young developer who has learned the fundamentals of programming within the past decade and have more perspective on the process of learning coding as opposed to learning one language.
“So what advantage does a 60-year-old .NET programmer have over a 27-year-old .NET programmer when they both have, at most, 5 years of experience doing .NET programming? Absolutely none”.
I disagree. A 60-year old programmer has a lot more general wisdom on when a technology or a feature is BS, what things can go wrong when developing a product, and the best structures and practices that can be applied to a given situation. This is the sort of experience that you can only get through a slow process of trying everything and seeing what floats. I certainly don’t have it yet, though I can understand it being easy to underestimate it’s value.
In general, regarding the ever shifting nature of computer engineering and the lack of prestige the geeks get the thing to remember is that general purpose computers are less than 60 years old. The author compares software engineering to law, finance, and medicine which have all been around for centuries and have all needed to stabilize to the standardized, safe, and prestigious fields that they are. I said I agreed (to an extent) with his point that a career in computer programming sucks, but I don’t believe that it will forever. In a couple of hundred years, if not hopefully in a couple of decades with the way the technology industry moves, languages will die, merge, and become compatible with each other ending in a state where the computer programmer can be like any other craftsman or engineer. So sure, it sucks now but I have a lot of hope.
Software engineering isn’t life any other craft or field of engineer, though. I remember my computer science teacher telling me in high school that programming is a multi-disciplinary field. That idea has always stayed with me, though I didn’t realize how true it was until recently. A general purpose computing machine can be wrangled to do any task. Teachers, artists, scientists, and others have taken to learning to coding in order to allow themselves to do more in their chosen profession. A geek who loves nothing more than to hack all day can do just that, but if they are good at programming they should know that the programs are meaningless unless there is a need to apply meaning to it. The geek should therefore expand their knowledge of another field. They should do this not for the sake of having something to fall back on, but because somebody who can, for example, understand both neuroscience and how to use a computer to study neuroscience better than anybody could before is worth more that a person who can only do one of the two.
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
| « Oct | ||||||
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 | 31 | |||
