Are Googlers Too Smart For Their Own Good? 307
theodp writes "If you're a mere mortal, don't be surprised if your first reaction to Google Storage for Developers is 'WTF?!' Offering the kind of 'user-friendly' API one might expect from a bunch of computer science Ph.D.s, Google Storage even manages to overcomplicate the simple act of copying files. Which raises the question: Are Googlers with 'world-class programming skills' capable of producing straightforward, simple-to-use programming interfaces for ordinary humans?"
That API looks fine to me (Score:3, Interesting)
The only nonintuitive thing is the name "bucket", which might be better called "zone" or "filesystem". Other than that, it looks like it provides just about what I'd expect of a high-level filesystem representation.
Sheesh, just think about what the complaints would be if they provided something closer to VFS-type mappings so people ended up commonly rewriting half of FUSE to get their data where they like.
API is not a UI (Score:3, Interesting)
Explaining American Football to Chinese (Score:3, Interesting)
Things become much more complicated then first impression when you try to really explain something. For example I went to a football game with a group of Chinese grad students and they asked me how a team can score points. I thought to myself this is easy, and began to explain the rules.
1. Touchdowns are worth 7 points... err they are worth 6 points technically
2. After a touchdown the scoring team can decide to kick the ball through the uprights for 1 point
Or
3. The scoring team can decide to run another regular play and if they enter the end-zone again on that 1 play they get 2 points.
4. Fields goals are 3 points and are scored when the team on offense can kick the ball through the uprights.
5. The defense can score points if they can tackle an offensive player in the end-zone while they are holding the football. The defensive team then gets 2 points and gets the ball kicked to them on the following play instead of the normal system where the scoring team kicks the ball to the other team.
6. If the defense can steal the ball and run into the end-zone they are facing then it is a touchdown and rule 2 and 3 apply.
By the end of this discussion they were more confused then when we started. So when you say how hard can it be to explain how to store a file questions like.
1. How to delete?
2. How to rename?
3. How to create folders or other organizational structures?
4. How to move items between organizational structures?
5. How to copy an item already in storage?
6. How to download multiple files?
7. Can security be set or changed?
8. Oh yeah and how to I upload a file in the first place?
The more precision you apply to a discussion the more complicated they tend to get. Just like a touchdown is 7 points is easier to understand, upload a file is easy too.
After skimming the file-copying code... (Score:3, Interesting)
After skimming the file-copying code, I agree with the people who say it's not complicated. I'm not a Python programmer either. The example functions they gave look like good starting points for wrappers that would provide the higher level, "get, send, delete" sort of functionality the poster wants. The only thing that confuses me is why you have to have "config = boto.config" when the config variable isn't used in the rest of the code. To me, it looks like you're only interested in the side effects of retrieving the configuration and not the result. Couldn't you just "boto.config()" or something at program startup? Of course that's probably more of a Python question from somebody who is ony passably familiar with the language. It's nothing complicated about the API.
Re:Hint: "For Developers" Means "For Developers" (Score:5, Interesting)
It isn't slashdot that has become non-nerdy, it's that being a nerd has become "cool", very unlike it was when slashdot started. These days, anybody who knows that you make your computer stop by clicking "start" thinks (s)he's a nerd, even if they couldn't copy a file without a GUI, let alone have ever heard of Linux or BSD or any other non-Microsoft OS (which these days actually have GUIs).
In the old days, a submission like this most likely wouldn't have been posted, but now we have the firehose, where every nerd wannabe can vote a story up. There are still very good, technical stories here (there was one a couple of days ago about mathematics) -- you just have to ignore the ones like this one voted up by the wannabes. That said, I haven't looked at Google's APIs.
God, I never thought I'd see the day when we would be considered cool! Just laugh smugly and enjoy being cool instead of being a wannabe.
That said, sometimes I say stupid things here (probably a lot this week, I've had the flu and it's affected my mental faculties).
How quaint (Score:3, Interesting)
It may seem a bit hilarious, apparently this kind of crap (like having bucket names conform to DNS) happens when you want to use web services as your OS. Not too hard if you just implement this once.
This bit is just silly, good for giggles but are they serious about requiring zone editing to expose a database table? Nooooo....
I didn't quite catch how you copy data to other domains, since it looks like you use a gs:// prefix to reach google storage but you say gs://cats and it is still in your account not at google's root server.. kind of annoying though maybe there's a way around it?
I think the 1024 byte limit is totally bogus, that's pretty short if it has to hold the URI path through your virtually nested buckets. Although I've seen Windows flake out at 255 character paths.. That and the bit about a "flat hierarchy", which is an oxymoron, and how you can't nest buckets but you can do so "virtually" by putting slashes in your bucket names, as if it isn't just a normal URI, they're just joshing you, a little bit of fun y'know. "Bare metal" indeed, more like stripping the metaphor down to bare CGI.
It is funny you have to allocate your own temporary file as a buffer for uploading a file, though of course that's what happens in Perl CGI. Which then makes you wonder why you cannot set a max upload data size for your app.. Of course the GSUtil command line tool looks pretty simple.
Otherwise, Animats' post is to right to the point. It isn't really that great. Kind of a bare minimum is more like it. And they stick with REST... so you should hope for a nearby library to exist that will save you not have to start implementing wierd HTTP verbs.. you have to really want this as implementing it seems as much fun as pulling teeth slowly.
Re:Article Tag (Score:4, Interesting)
It's not about being too difficult. It's about being way too overcomplicated.
Let's look at the code.
config = boto.config
okay here. We need config.
bucket_name = "dogs"
remote dir. So they made a half-assed directories system. Can't be nested, data can't be outside them. Piss-poor but let's say "okay" here.
name = "poodle.jpg"
dir_name = "pets"
so far so good.
src_uri = boto.storage_uri(bucket_name + "/" + name, "gs")
dst_uri = boto.storage_uri(dir_name, "file")
seems logical if slightly redundant. So we need some objects instead of plaintext names...
dst_key_name = dst_uri.object_name + os.sep + src_uri.object_name ...wtf... oh, we are trying to create a local filename... that's some convoluted way to do it.
new_dst_uri = dst_uri.clone_replace_name(dst_key_name)
err... so our local disk file needs to be placed at... "pets/dogs/poodle.jpg". Now that's some way to get there!
dst_key = new_dst_uri.new_key()
oh, that was just the NAME of the new key... so we need the actual "key"... again, what for?
src_key = src_uri.get_key()
again, if we have the URI object, why do we need some "key" object? Isn't the dedicated URI object good enough?
tmp = tempfile.TemporaryFile() ...can't we read directly from a file instead of creating temporary one? So the "uri" of a file is not good enough, the "key" of a file is not good enough, we need a "tempfile" object extra?
src_key.get_file(tmp)
tmp.seek(0)
dst_key.set_contents_from_file(tmp)
I recommend a reading about a hammer factory factory factory [joelonsoftware.com]. This one doesn't overdo factories, just abstraction layers. I can spot four: filename (string), URI, key, file handle within the key. WHO needs that???
Abusing Google Storage for phishing? (Score:3, Interesting)
I wonder if Google Storage can be abused as a way to host phishing pages?
There's a phishing page [phishtank.com] that's been on Google Sites since February. Google is good about kicking off most phishing pages, but this one is different. Here's the phishing page as a web page. [google.com] The actual hostile page (which is a bogus login page for Stickam) is on the "Click here to download your attachment". The actual url is http://2699962600425641406-a-1802744773732722657-s-sites.googlegroups.com/site/stickamcomlogindo/login.html?attachauth=ANoY7cpc6fembideFQyYULstnVDU-XMkgwzNLFkUv77Suh8bUq_LGrFRQ-RtLkw6pEPJb5Vk0XW4JMbOVQtqT_R6CjNCh5N2r29quoFkE5Cq1XQXUFhuegVtr4kQUMN9T3dT3yO1q-FthiahDl45UqMmFfD6gKSYwQP4bsgVoM-N5cQN0hHRvDZskuvmTdy0lqnQqUhmKFYP&attredirects=0. That's probably a page in Google Storage.
This raises the question of whether Google should be running hostile-code checks on publicly-accessible Google Storage pages.
Harder than you think (Score:2, Interesting)
Developing good interfaces and good APIs is harder that you think. This maybe isn't Google finest code but it is not amateur hour either. They may need to bring in some "senior-Google-talent" but for first crack this is not bad.
Lay off these guys unless you can go it better.