Lately, I've been seeing these odd little signs pop up in storefronts around town.
All the signs have various forms of this printed on them:
Only 3 students at a time in the store please
We took that picture at a 7-11 convenience store which happens to be near a high school, so maybe the problem is particularly acute there. But even farther into town, the same signs appear with disturbing regularity. I'm guessing the store owners must consider these rules necessary because:
I'm just guessing; I don't own a store. But like the "no elephants" sign, it must be there to address a real problem.
When you go into a restaurant and see a sign that says "No Dogs Allowed," you might think that sign is purely proscriptive: Mr. Restaurant doesn't like dogs around, so when he built the restaurant he put up that sign. If that was all that was going on, there would also be a "No Snakes" sign; after all, nobody likes snakes. And a "No Elephants" sign, because they break the chairs when they sit down. The real reason that sign is there is historical: it is a historical marker that indicates that people used to try to bring their dogs into the restaurant
All these signs are enough to make me question the ethics of high school students in groups of 3 or more. Although, to be fair, I've seen some really shifty looking graduate students in my day.
In truth, these kinds of limits are everywhere; they're just not as obvious because there's often no signage trail to follow.
I'm sure you can think of lots of other real world examples. They're all around you.
There are people who act like groups of rampaging teenage students online, too, and we deal with them in the same way: by imposing rate limits! Consider how Google limits any IP address that's submitting "too many" search requests:
Several things can trigger the sorry message.
Often it's due to infected computers or DSL routers that proxy search traffic through your network - this may be at home or even at a workplace where one or more computers might be infected. Overly aggressive SEO ranking tools may trigger this message, too. In other cases, we have seen self-propagating worms that use Google search to identify vulnerable web servers on the Internet and then exploit them. The exploited systems in turn then search Google for more vulnerable web servers and so on. This can lead to a noticeable increase in search queries and sorry is one of our mechanisms to deal with this.
I did a bit of Google scraping once for a small research project, but I never ran into the CAPTCHA limiter. I think that entry predates its appearance. But it does make you wonder what typical search volumes are, and how they're calculated. Determining how much is "too much" -- that's the art of rate limiting. It's a tricky thing, even for the store owner:
Rate limiting isn't always a precise science. But it's necessary, even with the false positives -- consider how dangerous a login entry with no limits on failed attempts could be. This is especially true once your code is connected to the internet. Human students can be a problem, but there's a practical limit to how many students can fit in a store, and how fast they can physically shoplift your inventory. But what if those "students" were an infinite number of computer programs, capable of stealing items from your web store at a rate only limited by network bandwidth? Your store would be picked clean in a matter of minutes. Maybe even seconds!
Not having any sort of rate limiting in your web application is an open invitation to abuse. Even the most innocuous of user actions, if done rapidly enough and by enough users, could have potentially disastrous effects.
Even after you've instituted a rate limit, you can still get in trouble. On Stack Overflow, we designed for evil. We have a Google-style rate limiting CAPTCHA in place, along with a variety of other bot defeating techniques. They'be been working well so far. But what we failed to consider was that a determined (and apparently ultra-bored) human user could sit there and solve CAPTCHAs as fast as possible to spam the site.
And thus was born a new user based limit. I suppose we could create a little sign and hang it outside our virtual storefront:
Only 1 question per new user every 10 minutes, please.
There are a few classes of rate limiting or velocity checking you can do:
I was shocked how little comprehensive information was out there on rate limiting and velocity checking for software developers, because they are your first and most important line of defense against a broad spectrum of possible attacks. It's amazing how many attacks you can mitigate or even defeat by instituting basic rate limiting.
Take a long, hard look your own website -- how would it deal with a roving band of bored, morally ambiguous schoolkids?
[advertisement] Improve Your Source Code Management using Atlassian Fisheye - Monitor. Search. Share. Analyze. Try it for free! |
Read More...
[Source: Coding Horror - Posted by FreeAutoBlogger]
maybe this makes more sense 
In The Sad Tragedy of Micro-Optimization Theater we discussed the performance considerations of building a fragment of HTML.
string s =
@"{0}{1}{2}{3}";
{4}
return String.Format(s, st(), st(), st(), st());
The second act of this particular theater was foreshadowed by Stephen Touset's comment:
The correct answer is that if you're concatenating HTML, you're doing it wrong in the first place. Use an HTML templating language. The people maintaining your code after you will thank you (currently, you risk anything from open mockery to significant property damage).
The performance characteristics of building small string fragments isn't just a red herring -- no, it's far, far worse. The entire question is wrong. This is one of my favorite lessons from The Pragmatic Programmer.
When faced with an impossible problem, identify the real constraints. Ask yourself: "Does it have to be done this way? Does it have to be done at all?"
If our ultimate conclusion was that performance is secondary to readability of code, that's exactly what we should have asked, before doing anything else.
Let's express the same code sample using the standard ASP.NET MVC templating engine. And yes, we render stuff like this all over the place in Stack Overflow. It's the default method of rendering for a reason.
<%= User.ActionTime %><%= User.Gravatar %><%= User.Details %>
<%= User.Stuff %>
We have a HTML file, through which we poke some holes and insert the data. Simple enough, and conceptually similar to the String.Replace version. Templating works reasonably well in the trivial cases when you have an object with obvious, basic data types in fields that you spit out.
But beyond those simple cases, it's shocking how hairy HTML templating gets. What if you need do to a bit of formatting or processing to get that data into shape before displaying it? What if you need to make decisions and display things differently depending on the contents of those fields? Your once-simple page templates get progressively more and more complex.
<%foreach (var User in Users) { %>
<%= ActionSpan(User)%>
<% if (User.IsAnonymous) { %>
<%= RenderGravatar(User)%>
<%= RepSpan(User)%>
<%= Flair(User)%>
<% } else { %>
anonymous
<% } %>
<% } %>
This is a fairly mild case, but you can see where templating naturally tends toward a frantic, unreadable mish-mash of code and template -- Web Development as Tag Soup. If your HTML templates can't be kept simple, they're not a heck of a lot better than the procedural string building code they're replacing. And this is not an easy thing to stay on top of, in my experience. The daily grind of struggling to keep the templates from devolving into tag soup starts to feel every bit as grotty as all that nasty string work we were theoretically replacing.
Now it's my turn to ask -- why?
I think existing templating solutions are going about this completely backwards. Rather than poking holes in HTML to insert code, we should simply treat HTML as code.
Like so:
foreach (var User in Users)
{
[ActionSpan(User)]
if (User.IsAnonymous)
{
[UserRepSpan(User)]
[UserFlairSpan(User)]
}
else
{
anonymous
}
}
Seamlessly mixing code and HTML, using a minumum of those headache-inducing escape characters. Is this a programming language for a race of futuristic supermen? No. There are languages that can do this right now, today -- where you can stick HTML in the middle of your code. It's already possible using Visual Basic XML Literals, for example.
Even the hilariously maligned X# has the right core idea. Templating tends to break down because it forces you to treat code and markup as two different and fundamentally incompatible things. We spend all our time awkwardly switching between markup-land and code-land using escape sequences. They're always fighting each other -- and us.
Seeing HTML and code get equal treatment in my IDE makes me realize one thing:
We've all been doing it wrong.
[advertisement] In charge of a mountain of Windows servers? PA Server Monitor to the rescue! Download the Free Trial!
No, we’re not giving anything away in this post. Instead, we’ve got some work to do, and we need you to play an important role in it. Our most interesting (and important) project for 2009 is something we are modestly calling “The Smashing Book”: a smashingly written, beautifully designed and professionally printed book. It will be created by and for the Web design community. Four key decisions have already been made: the book’s title will be “The Smashing Book”; it will be a paperback; the price is fixed, as is the release date, which is early September 2009.
We want to create a totally unique and exciting book, full of insightful and useful articles; a book that contains only articles that a reader of Smashing Magazine would really want to read. No fluff, no cruft, just hearty meat and potatoes content.
To achieve this, we need the help of our community: your help. And what could be better than working on this important project together with our readers? If you want to participate in our project, please visit the forum (the registration is required for replies) and help in any of the following ways:
First, you can suggest a topic for The Smashing Book. Let us know what you want to read and what topics we should cover. What enticing, creative, useful articles should be written? What should a Smashing Book contain? You can propose any topic you think would be great, but it must fit the small universe of Smashing Magazine and relate to design and Web development.
Once we receive your suggestions, we’ll evaluate them, filter and sort them. If necessary, we’ll open a second and third round of voting, which will (hopefully) help us select the most important and relevant topics.
Afterward, we’ll present the final list of topics to our authors team, discuss the ideas with them and assign topics. Articles for the book can also be written by members of the Web design community. So, if you want to propose an article for the book, please suggest your idea in the Book topics forum.
We want you to decide what The Smashing Book will look like. You can propose ideas for an unforgettable book cover design (any colors can be used), and you can also present your drafts in the Cover design forum. We’d love to see first drafts and invite forum members to discuss them, too! We haven’t decided anything about the appearance of the book yet, so free your imagination.
Help us decide on the perfect layout for The Smashing Book. How should it be designed? What typefaces should be used? What about font sizes, headings, columns, footnotes, image captions, page numbers, markup? What structure should the book have in general? We are open to your suggestions, so please participate in the Book layout forum: suggest your ideas and submit your drafts.
We want you to be part of The Smashing Book. Help us out by designing some outstanding buttons, badges, banners, pins, icons, graphics and whatever else you can think of. We are confident that together we’ll achieve truly outstanding results, even if the process will be a long one and see the inevitable hurdles along the way.
Of course, we will reward you! And as you would expect, we’ll also have small, exclusive rewards to give away to the most active helpers and participants.
Thanks for reading. And now, let’s get to work!
(al)
� Vitaly Friedman & Sven Lennartz for Smashing Magazine, 2009. |
Permalink |
58 comments |
Add to del.icio.us | Digg this | Stumble on StumbleUpon! | Submit to Reddit | Submit to Facebook | Who is linking? | Forum Smashing Magazine
Post tags: book, community, smashing
