The Danger Of API Development: Making Something Too Good
On CNET, via slashdot: Lendle, a Web site that had helped facilitate the loaning of ebooks among Kindle users, was effectively destroyed when Amazon shut down Lendle’s access to its Kindle API.
Lendle first reported the news via Twitter: “Amazon has revoked Lendle’s API access. This is why the site is down. It’s sad and unfortunate that Amazon is shutting down lending sites…According to Amazon, Lendle does not ‘serve the principal purpose of driving sales of products and services on the Amazon site.’”
According to Lendle co-founder Jeff Croft, “at least two other Kindle lending services” have been terminated from the API.
The problem with Lendle and its cousins is simple: It was too good at what it did.
Amazon does allow one-time loans of an ebook for up to 14 days, but they expect such trading to be among intimates. Lendle greatly expanded the ability for one person to trade with a complete stranger, and as a result posed a serious threat to potential Kindle edition sales.
After all, if I can’t find someone to lend me an ebook, I probably have to buy it. Put me in big enough a room of Kindle owners, however, and I’m likely to find what I am after for free.
I don’t care to get into copyright, the nature of modern publishing, or the like. I’m far more interested in pointing out the problem with using third-party APIs that this illustrates: If you make something too good, there’s usually nothing stopping the API service from cutting you off and stealing your work.
Continue reading: The Danger Of API Development: Making Something Too Good »
Hello, I’ve a question about your post “Using AJAX To Update A Non-Map DIV Via Google Maps API’s GDownload() And GMarker OnClick Event”. Your example is for the V2 version of google maps, so, is it possible to have exactly the same things for the v3 api?
I believe the objects and methods are the same between the two versions of the API, so the answer is probably. Unless, of course, they objects and / or methods have changed. In which case, no.
The Lessons We Should All Relearn From HBGary
Ars technica published a long (by Web standards) story yesterday about the hacking of HBGary by Anonymous. It is absolutely, positively, must-read information for all beginner Web developers — for that matter, for experienced Web developers, too.
For those unfamiliar with the story, HBGary is an information systems security consultancy. It’s not huge, but it’s been successful getting work with the federal government and several other companies.
But HBGary wanted to get bigger; to exploit the headlines and prove itself worthy of major government and corporate contracts. So HBGary hatched a couple of schemes.
One was to help Bank of America discredit WikiLeaks with a disinformation campaign and character assassinations. The other was to “unmask” the Anonymous hackers who set off several DDoS attacks against Visa, Bank of America, and others perceived as having harmed WikiLeaks.
Unfortunately, HBGary boss Aaron Barr decided to go public with his plans to expose the alleged hackers. So Anonymous decided to attack HBGary, and the rest are our lessons for the day.
Continue reading: The Lessons We Should All Relearn From HBGary »
Correcting Permalinks After Moving Content From A Subdirectory To Root
Ran into this problem with the blog:
As previously noted, I moved my WordPress install from a subdirectory to the root of my Web site. I tried the “Giving WordPress Its Own Directory” method, but I didn’t trust it, so I decided to go ahead with a physical move of the software to root.
As a result, all permalinks to the 200+ articles in this blog became broken, since the subdirectory /blog/ was part of the permanent path root. This was bad, because Google has all those old links wrong, and so does my YOURLS install.
So, I needed a fix, stat. Thankfully, Apache has the mod_alias module, which does a better job of rewriting URLs from subdirectories to root directory than mod_rewrite does.
I specifically used the RewritePermanent directive, which allows one to specify part of a URL string, and to where URLs containing that string should be directed. In my case, I wanted to direct all URLs that contained the /blog/ subdirectory to the root of my site. Thus:
<IfModule mod_alias.c> RedirectPermanent /blog/ http://www.dougv.com/ </IfModule>
The first argument after RedirectPermanent is the part of the URL you want removed. The second argument is the URL to which you want found URLs redirected.
This works far better for me than the handful of mod_rewrite rules I tried to accomplish the same basic task.
Your Web server must have mod_alias installed for this to work. Most shared Web hosts will have installed mod_alias, but some might not, or might only enable it for selected domains, as a lot of rewrites and aliases can cause trouble with search engine rankings. Check with your Web service provider.
A hat tip to julianmatz at experts-exchange.com for the tip. All links in this post on delicious: http://www.delicious.com/dougvdotcom/correcting-permalinks-after-moving-content-from-a-subdirectory-to-root
Meta Data For A Web Site's People: humans.txt
CSS-Tricks, a really great Web site that explains in detail how to replicate cutting-edge Web site designs and effects, tipped a new idea: humans.txt, a metadata file to compliment robots.txt.
“It’s an initiative for knowing the people behind a website,” said the proponents, who hail from Spain. “It’s a TXT file that contains information about the different people who have contributed to building the website.”
Like Chris Coyier, the author of the CSS-Tricks article, I like the idea of having a meta data file, outside the code base of a Web site itself, that credits the people behind the site.
I find those “Web sites created by {insert Web design firm here}” links in the footer of a site to be so 2001 (although admittedly, I only stopped putting them on sites about five years ago). And sure, one can add an author meta tag to the head of a Web page, to give credit where it is due. But I revere the head element of a Web site; authors shouldn’t put any old thing in there, and everything in there should serve a specific purpose to the page itself.
So a humans.txt file makes a lot of sense, and I admire the cleverness behind calling it that, in compliment to the familiar and requisite robots.txt file.
I like the idea of being able to give extended credit to site contributors. I like the idea of being able to reveal base technologies behind a site. (But not too specific, mind you; I can just see the script kiddies out there, putting together exploit bots that scour humans.txt files to find unpatched software to attack.)
I think it makes more sense, however, to use XML. The robots exclusion standard came out in 1994, was the brainchild of one person solving a problem specific to his search engine’s needs, and effectively became a standard by fiat.
While it has a kind of schema — at least, its proper formatting is well-known — the structure of a robots.txt file isn’t efficient or elegant; it’s not easily read or manipulated, and it can be repetitive and difficult to manage multiple rules for multiple engines.
An XML document is far cleaner.
Continue reading: Meta Data For A Web Site's People: humans.txt »
