Showing posts with label web. Show all posts
Showing posts with label web. Show all posts

Friday, 9 November 2012

Font Size Units

I've always used points (pt values) for sizing fonts on web pages, e.g.:

body {
    font-size: 12pt;
}

Those of you who know me know that I'm a developer, not a designer (in the web designer sense; I design systems, but that's different). I couldn't visual-design my way out of a paper bag. (Okay, maybe that's a bit harsh.) I don't think I'm a one-trick pony, but I'm definitely much more left- than right-brained. The engineer in me says, I'm setting a font size, right? And fonts are measured in points, so I use points. Or at least, I used to.

Chris Coyier, on the other hand, is a designer. And he gives some good reasons even an engineer can understand why using pt values only makes sense for print stylesheets, not screen stylesheets. And apparently he's just recently been converting himself to using ems rather than pixels. Both articles are interesting reads.

Wednesday, 31 October 2012

Blitz.io Updates Pricing Model

Early this month I was checking out blitz.io and although it looked like a cool tool (and fun), the pricing model stopped me looking at it too closely, for reasons I explained to them:

Hi folks,

Was just checking out blitz.io, which looks really cool (and fun), but I was stopped pretty early on by the pricing. I don't understand why the length of a rush is tied to the number of concurrent users (for pricing purposes). 1-minute tests are basically useless, other than checking if the site's going to just immediately fall over at a given load. I don't even trust 10-minute tests. To adequately determine the capacity of a system, I'd want to run a test for at least half an hour and ideally an hour, as the various components of the system go through their various operations (GC, for instance). I don't always need 50,000 concurrent users, but I do want the ability to choose longer rushes. Do you have a mechanism for that? If not, could I suggest you add one?

Best,
--
T.J. Crowder

Less than half an hour later (nice), Michael Smith from blitz wrote back to tell me new pricing was on the way.

Well, it's here, and it makes so much more sense: You buy credits (they start at $1 USD = 1 credit), and one credit is worth 1 minute of 1,000 concurrent users. No longer is the length of a rush tied to the number of concurrent users, you control those variables completely independently. A 20-minute rush of 1,000 concurrent users costs 20 credits. 20 minutes of 10,000 concurrent users, 200 credits. And instead of being clock-on-wall time for a set period (which apparently it used to be), you're only charged for the time the rush is actually running; if something goes wrong you can stop it early to avoid spending credits unnecessarily.

As part of this, they did discontinue their old free level in favor of topping up all accounts to 10 credits each month (even accounts that haven't bought credits). There's some discussion about what that means for their continuous integration clients, which is probably worth a read.

But fundamentally, well done blitz for listening to your customers (clearly it wasn't my note that got them working on a new model, that was just happy timing for me). Now I can take a closer look.

Wednesday, 3 October 2012

You can contribute to caniuse.com

I'm sure most of us have referred to (and probably cited) caniuse.com at some point. It's probably the most comprehensive collection of browser feature support around. Want to know the status of CORS support? Here you go.

Well, now if you spot an error or want to add further information, you can do so fairly directly: caniuse.com is now on GitHub.

I should probably note that caniuse.com is monetized (in a very minimal, unobtrusive fashion at present), and perhaps you don't want to contribute to someone else's monetized project on the theory that, well, they're getting paid for this (assuming the ads cover the hosting). Fair enough. For me, barring big changes to the site, I'd be happy to add to the data there if I happen to know something that's not covered. It's a great resource, well-managed.

(Side note: I'm not affiliated with caniuse.com in any way, something that may not be obvious from the above.)

Tuesday, 13 October 2009

A better way to hide .htaccess, WEB-INF

If you use Apache as your web server of choice, you may wish to have files or directories that Apache pretends are not there. For me, this is because I like to have Apache proxy a servlet container backend, but I'm too lazy to separate out the files, and so I just point Apache and the servlet container at the same directory and tell Apache to pass on the relevant requests to the servlet container (e.g. JSPs, servlets, etc.). The only problem is, that common directory will tend to contain things like the WEB-INF directory and its subdirectories, which I kind of don't want Apache to serve up to the public! If you use .htaccess files, you'll have the same sort of situation.

The usual answer is to simply deny access to the file or directory in question, as in this default rule from the Apache2 config:

<Files ~ "^\.ht">
Order allow,deny
Deny from all
</Files>
That sends a 403 (Forbidden) reply when someone tries to access .htaccess. And the same sort of thing can be applied for WEB-INF using the DirectoryMatch directive:
<DirectoryMatch "(^|/)WEB-INF($|/)">
Deny from all
</DirectoryMatch>
And that's great, but I'm a bit paranoid -- why does the outside world need to know that the thing is there at all? I'd much rather it sent a 404. And huzzah, mod_rewrite to the rescue!
<DirectoryMatch "(^|/)WEB-INF($|/)">
RewriteEngine on
RewriteRule .* - [L,R=404]
</DirectoryMatch>
Since the RewriteRule is already inside the DirectoryMatch that will only match what we want, its own regex can just match everything. The L flag says this is the last rule, but the R flag is the magic: It forces a redirect, and if you use the R=xyz form, it redirects with the given code; in this case, a 404. This does the right thing even if you have a custom error document (and you have custom error documents, right?).

Voilà! As far as the outside world is concerned, there just isn't a WEB-INF directory there at all.

If you like, you can have a general rule that works whether mod_rewrite is loaded or not:
<DirectoryMatch "(^|/)WEB-INF($|/)">
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteRule .* - [L,R=404]
</IfModule>
<IfModule !mod_rewrite.c>
Deny from all
</IfModule>
</DirectoryMatch>
This will do a 404 if mod_rewrite is loaded, but fall back to a 403 of not.

Final note: If you're letting Apache generate directory listings for you by not including a directory file, the above won't hide the WEB-INF diretory (or whatever you're hiding) in those listings. It's easy enough to do it, though: Inside the relevant directive for the directory being listed, just use IndexIgnore to tell the mod_autoindex module to ignore it:
IndexIgnore WEB-INF
In my case, since I want WEB-INF to be hidden everywhere, I can just include it inside my main Directory directive. I never let Apache generate listings for me anyway, but it's nice to have a backstop if I blow away my index file.

Thursday, 16 October 2008

Minimizing Download Times

Hello all,

That's right, first post since...wow, since April. And it's not even a post, it's sort of a link-post.

I've been doing some work helping build the Prototype user community (moderating the user discussion group, creating an unofficial wiki, that kind of thing) and as part of that I've been doing little mini-articles, much like the ones I expected to do here.

So if you're writing web applications or web pages and you're interested in minimizing the download times for your scripts, check out this article I posted over there: Tip - Minimizing Download Times