...more recent posts
It just occurred to me that I should record distinct useragents who request robots.txt in the database, and then I could run the referrer logs against this list and come up with, I think, sort of okay human traffic numbers. Maybe filter the robot inserts through a black list of real browser useragents to cut down on the chances incorrect robot identifications.
Would any real robots obeying the robots.txt provision identify themselves with actual broser useragent strings? And how many robots don't request robots.txt? And how many human browsers do? (Hackers seeing where you don't want robots to look? noob web developers looking for examples? Can't amount to much.)
Blacklist (of known human browser useragent) could be compiled similarly by inserting distinct useragents of account holders into the database.
Probably not worth it, but as another barier against false robot id you could check if new identified-as-robot useragent subsequently request javascript files, as probably robots don't request those.
And while I'm thinking about this, distinct IP total numbers might be improved by having distinct IP plus distinct useragents within the same IP. So, for instance, a page requested from the same IP by 2 different useragents should probably be counted as 2 people, not 1 as the "by distinct IP" view would give it. This might be wrong, as I could use Safari today and FireFox tomorrow while still being one person, but I think it's at least as possible that I actually am two people behind a NAT. Distinct IP really gives something more akin to number of households (or businesses) requesting, not number of people.
Javascript implementation of the Tiny Encryption Algorithm. Just need a reference to this for an upcoming project.
Really interesting early HTML 5 client side SQL storage work going on in WebKit. There's an example application page, but you need to be running the latest nightly to use it. I can't wait to play around with this. I keep saying it, but javascript is going to rule the world. Not sure I'm completely happy about that but it sure seems true.
External SATA hard drive dock. Genius.
Excellent news: Jobs announces native 3rd party SDK available for iPhone and iPod Touch development in February.
Let me just say it: We want native third party applications on the iPhone, and we plan to have an SDK in developers' hands in February. We are excited about creating a vibrant third party developer community around the iPhone and enabling hundreds of new applications for our users. With our revolutionary multi-touch interface, powerful hardware and advanced software architecture, we believe we have created the best mobile platform ever for developers.Nice. That's exactly what I wanted to hear. I was beginning to worry they were thinking they could do it all themselves.
There are a few details that could still make this slightly less than perfect, but we won't know until February. I don't mind the wait, I just hope it is as open as possible. In any case, great news that Apple still gets it.
The broadest claims in Amazon's one-click patent have been struck down. Score one for the side of reason.
I've taken a part time job - supposedly 20 hours a month - at a fairly large magazine website. Basically I'm tweaking CSS and HTML with a little bit of javascript fixing along the way. Not exactly my strengths, but I think I'm good enough now to get the job done. Eventually they want to do blogs and other things that are a better fit, so hopefully it will morph into that eventually. In the meantime I'll at least have a little bit of standardized income. Living job to job is hard on the brain.
I'm going in this afternoon for a meeting, but mostly I can work from home.
I'm not sure it will work, but this is an incredible idea in the "what really simple thing that could make tons of money has no one thought of yet" sort of way: Vidoop Secure
Vidoop's engineers (led by a CTO who is ex-Microsoft) have developed software that finally improves upon the leaky "user name + password" method, replacing it with a process of image recognition based on a grid of pictures displayed on the screen.That's really brilliant. Again, I'm not sure it really solves a pressing enough problem, and getting people to change the way they log in to sites might not work no matter how clever it is. But damn, that's clever.
But here's the really clever part: Vidoop will monetize the process by selling the images in the grid to advertisers for product placement. Instead of seeing a generic car in the image grid, consumers might see a Ford (F) Mustang, or a Prius (TM) . Instead of a cuppa Joe, they might see a tall Starbucks (SBUX)....
Here is how it works: When you register on a new site, you're asked to pick three categories. Suppose you choose cars, planes and beverages. When you log in, Vidoop's image grid pops up with a display of 12 images, pulled at random from Vidoop's database. You never see the same combination of images twice - but there will always be a car, a plane and a drink.
Inside each image is a letter or number, also randomized. The letters and numbers displayed in the car, drink and plane act as a pass code for that single login. Since images and characters are chosen at random, no two logins are ever the same. This curbs the riskiest kind of hacking, says Sontag: "It is impossible to keystroke-record this," Sontag says.
I what is possibly huge typographic news for the web in general, the latest WebKit nightlies now support the CSS @font-face rules.
Attempt at a short explanation: WebKit is the open source engine that powers the Safari browser (but also Opera, Shiira, and web browser in the Nokia S60 platform.) A "nightly" means the very latest version supports this (with new versions compiled every night,) but not yet the latest stable version (so the version with @font-face support isn't shipping yet, but because it's open source you can go and download it if you're brave.) And finally the CSS @font-face rule is a CSS rule that allows web designers to embed custom fonts in a web page. If the local computer doesn't have that font-face it will go to the supplied URI and download the font so it can render the page correctly.
If that doesn't sound like a big thing to you then you're not a graphic designer.
The reality check here is that only TrueType fonts are supported (that's not so bad actually,) and, of course, only WebKit is supporting this standard so far, so you really can't count on this working when designing for the web at large. Still, you can use it, and your pages can look amazing in Safari (or incredibly bad if you're a bad designer I guess,) and then just fall back to Helvetica or some other boring font-face in other browsers.
A List Apart has a good overview of @font-face.
Obviously I've been following and thinking about Adobe and their plans for web development. At the same time I've chosen a different route, with the open web standards of HTML, CSS, and javascript. Adobe Flash and Flex and AIR are some seriously cool tools that give you access to very rich features and, comparatively, a lot of speed. These two different paths are obviously in competition (if not economic, at least for developer hearts and minds,) but they are also closely related. Adobe has clearly been moving to make javascript a first class citizen in it's environments (for instance, you can build AIR apps with all javascript and zero actionscript.)
And this makes me wonder about Tamarin, which is an open source project that is Adobe's contribution to Mozilla. The basic point is to make javascript really fast. Which is great. And great for Adobe since they are now leveraging javascript in their development world.
But I wonder if they are rethinking their decision in light of the progress that projects like EXTjs have made building a development framework on top of pure HTML, CSS and javascript. Sure it will never have all the rich features of the Adobe environments, but some constraints are not always a bad thing (especially where those constraints force you to use the native widgets people expect to see on the web, and to build regular web pages that work the way people expect.) Plus the technology is all open and free for the developer. But there is a real issue, and that's speed. EXTjs (as well as any of the others like jQuery, YUI, prototype/scriptalicious, etc...) apps are slow compared to their rich Adobe conterparts. Really slow in some cases.
In the future, no doubt, this won't matter so much. Our computers will keep getting faster. And then there is Tamarin out there on the horizon ready to supercharge javascript 2. Which brings me back to my question. Why would Adobe want to contribute Tamarin? Seems like a radical speed up of javascript is going to make EXTjs et al much more competitive with Adobe's projects.