Slashdot Mirror
Are Googlers Too Smart For Their Own Good?
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?"
So, theodp, if you were a developer you would look at this and see a set of interfaces to web services done in a RESTful manner. You would say, "Oh, my users want to use Google storage but they need more of a drag and drop interface." Then you would spend a couple weeks using Ruby on Rails and Scriptaculous to make virtual folders or buckets or whatever your application calls them and using the elegance of RoR with the UI of Scriptaculous so the user can move their photos or data from your server to the cloud or vice versa. You could really use anything you want to interact with it but I would bet these two GPL compatible tools would result in the most rapid of web application development.
So three sentences with links to Google besmirching them for being smart will get you on the frontpage of Slashdot these days? Really the substance of the 'story' here is essentially "WTF?! So complicated it must Suck!"
Offering the kind of 'user-friendly' API ...
Here's a final hint: API stands for Application Programming Interface is not supposed to be user-friendly. It's supposed to be developer-friendly. I hope I don't sound like a Google fanboy but this is a nontrivial task and I would defend the API they have produced. The documentation is far more than you would get from a CS PhD. You want me to take notice of your mindless drivel, theodp? Get off your ass, code an interface for this API and then point out how the API and documentation is lacking in a step by step post. That would be helpful and deserve a place in Slashdot's programming section. What you have here is not.
My work here is dung.
They wouldn't call it code.
I still cannot find the droids I am looking for...
Soooo, like, some software is hard to use?
Maybe it's the pills I'm on, maybe it's the lack of caffeine, but could someone maybe explain the point of this article to me?
crazy dynamite monkey
I've always thought Google was known for their simple to use interfaces. Just look at their home page or Gmail for a couple examples. Even on a lot of their other services like custom search engines and Google Analytics they have a UI that's simple to use. Sure some of their things start out a little rocky for developers, but that's the case for most services. Given time they'll improve.
Anyone can make complicated (and not so complicated) things look even more complicated. The top programmer is the one who makes complicated things look simple.
In other news: the space shuttle UI is too complicated for regular car drivers! duh.
Whatever happened to simple interfaces, like:
"Would you like to play Global Thermonuclear War? [YES|NO]"
Seven puppies were harmed during the making of this post.
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.
For every problem, there is at least one solution that is simple, neat, and wrong.
Since when does an API need to be user friendly? I found Google's documentation much more user friendly and straightforward than say Microsoft's .NET documentation on File I/O. It's not an end-user product. Just skimming over the contents of the linked sites, it seems very easy to use even if you're not an advanced programmer. If you don't understand what's on those websites after some thorough reading, please hand in your geek card.
Custom electronics and digital signage for your business: www.evcircuits.com
This isn't to discredit the idea of ease of use or good design - god knows Google graphs requires way more hoops than it should (compare, say, Visifire).
I think it's easy to look at the developer's guide and just flee in terror, but honestly if that's your reaction, Google storage API is probably not the droid you're looking for. If you need simple file sharing that a typical user can appreciate without having to read a manual, Dropbox may be more appropriate; Google Storage API is written with developers in mind.. I'm a big fan of some of Google's APIs, Dropbox, and Google Docs for sure.
Something not understood by Slashdotter! Film at 11.
I was expecting something really crazy and complex but what I saw was well documented and made sense. Seriously, how on earth is this front page news on slashdot?? I wont repeat the many well made statements that "API's arent for users" above. I'm just surprised this has made it to the front page as a developers link. I sure hope I don't work with the sub. at any point if he thinks this is an example of people being "too smart for their own good". /saddened
jaymz
As the documents point out, it's the same API used for Amazon EC3 and others. They're implementing someone else's protocol.
If this a storage system to be used as a filesystem, why does it need a API? Write a OS filesystem driver then everything can use it. Easy enough to do in userspace with FUSE on Linux/BSD/OSX and Dokan on Windows. Everything is a filesystem, and this really seams to be a filesystem, so make it a filesystem. But maybe I'm missing something here.....
They were expecting people not to read any of the linked resources and just take a jab at Google, arguing back and forth.
Since when did Gmail have a simple interface. It has a lot of features.... and they have been beating the folder thing to death (Gmail's lack of folders ..).. labels.. labels in labels... yes it is all good.. and hope it reaches somewhere.
The only easy to use simple interface was for Google Search. With Bing's entry - Google seems to be hyperventilating and trying out the clumsy looking links on the left hand side.Android is not an easy interface... maybe it is compared to Motorola and Samsung phones... but that is like comparing stuff with the gunk at the bottom of the barrel.
I love Google for a lot of things - but truthfully, they are no where compared to interface standouts like Apple, which make interfaces hide the complexity of the crap below.
who flood developer-boards with questions that typically look like
" Sir Sir please help sir I have project due sir I need full workking code by tomorrow sir" ??
If so, you would expect everything to be point and click, I guess.
Just a quick FYI, API does not mean UI. I noticed some of the slashdotters were conflating the two.
"Anything tastes good if you deep fry it."
Seriously, Google has a number of products with extremely simple, user friendly interfaces. Their search engine, you know, the reason that they are who they are, the reason that anyone knows about them, is a prime example. Type in what you want, it finds what you need. No special syntax needed, no complex logical operations to try and get results, just key in terms or phrases and you get good results.
What kind of question is that?
You could just set your filter for "mere mortal" appropriately and you won't see these things anymore.
Oh, yeah, it's not easy to pad these out to 120 characters.
Possibly, if they realize how big of morons they are. I mean really? You own major shares of the market and make little attempt at making freeking money? Someone is not too smart.
There's been an awful lot of discussion about what is or isn't simple, and people have gotten a pretty sophisticated notion of simplicity, but I'm not sure it has helped.
-- Ward Cunningham
Colorless green Cthulhu waits dreaming furiously.
I think this is a terrible idea. It violates the principle of "make it as simple as possible, but not any simpler". Some things are just complicated. Even if the UI is nice and clean, what it interacts with is not and the users have to know about that. I don't think any UI could be understood by a 5 year old and I'm fine with that.
It looks like theodp and kdawson actually succeeded in getting a lot of people to really look at this new development, gauging by all of the feedback we're getting. :)
The mere existence of DroidDraw would indicate "no".
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.
As the parent to your post noted: we are talking about an API here. Precisely none of it is user facing.
The fun part is that groups #1 (and sometimes #2) usually can't tell the difference between groups #3 and #4, or worse, actively prefer #3 over #4.
Are Googlers Too Smart For Their Own Good?
No.
Lemmings are silly; dinosaurs are extinct.
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.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
anything that is user facing should be able to be explained to a common 5 year old
Why would an API be user facing? Are you an idiot who doesn't know the difference between a UI and an API?
On the short its an api and not for general user consumption.
The fact that non developers are even talking about this is a problematic symptom of our industry's current overexposure with respect libraries, OSs, dev tools etc....
We have invited the media and everyone else to our internal conflict over things that they should really have no interest in with our current infighting and ranting about mobile tech and the mobile market.
Its are fault that non technical people are commenting on whether or not apis are "user friendly". We invited the world to our dysfunction.
The tag on the article "submittertoostupid" pretty much says it all here folks.
Got Code?
“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”
- Brian Kernighan
It seems Googler's may be smart enough for their own good, but not smart enough to debug the cloud
This looks like a nice low-level API for doing really interesting and complicated things. Unfortunately, they neglected to include a high-level API to deal with what will be by far the most common use cases. Sure, it's not so difficult to implement an upload_file(filepointer, uri) function with this, but given the huge proportion of developers using this library that are going to need exactly this sort of function, do we really need all of them reinventing the wheel?
Powerful and complex functionality is good, but the most common use cases got that way for a reason. Specifically accounting for them, even if only through a set of basic frontend functions, brings major productivity boosts to the programmers that use your library. It is a thing worth doing, and it sounds like the Google folks neglected to do that in this case.
They just had to go and put an embedded playable Pac-Man flash game up as their logo today (30th Anniversary of the game).
Now I won't get any freakin' work done today.
The editors here know what they're doing. This submission was clearly accepted because it'll get fools like you and all of the other Google Defenders here all agitated and posting comments. Then you'll repeatedly check back for the next few hours, to see if anyone has replied to you. Meanwhile, all of this checking generates ad impressions, making Slashdot money.
The API is for developers, not Apple fanatics.
Apparently wizard is not a legitimate career path, so I chose programmer instead.
I tend to think of your taxonomy in terms of design outcomes:
4. Sufficiently engineered
3. Over-engineered
2. Under-engineered
1. Doesn't work or works on accident.
That is to say, average developers tend to nail the common case, but lack the experience or knowledge to spot the corner cases. Your "above average" developer wants to demonstrate his knowledge by optimizing for as many corner cases as possible at the expense of simplicity in the common case. The well-above average developer can balance the common and the exceptional.
Both over and under-engineered solutions are "bad," but the under-engineered solution usually has the advantage of less code to delete when you have to redesign everything. :)
Seriously, how on earth is this front page news on slashdot??
One word: kdawson.
It is not a user facing system, hence the title "for developers".
ALL of it is user facing. That's the very point of an API. The user is the developer.
This is a very, very important concept. As I said in my other post, this is a good API, a usable API. But so many APIs aren't usable. API usability should ALWAYS be considered when releasing a public library/service.
Google has just put the best holiday logo ever on the homepage. A working PacMan! I wonder what's the worldwide economic impact of this joke, in terms of lost productivity. It probably beats most terrorist acts and natural disasters :).
17779 eligible voters in a district, 17779 'vote' as one. This is Russia.
Last time I checked, the Google search page was pretty straightforward. For more complicated systems, get set up on Google Voice. I'm so used to phone-tree hell that I was pretty stunned with how quick and painless that was. They are happy to put user experience as a primary concern when they're trying to acquire users. For a storage API, frankly having granddad want to try it out might not be in their interests.
I'm both, so should I be able to or not be able to understand the API? It all makes perfect sense to me.
"If you do things right, people won't be sure you've done anything at all"
This is about developers. http://www.youtube.com/watch?v=8zEQhhaJsU4
The word you are looking for is "able", not "supposed".
Because, letters in the alphabet are "a code" but we don't refer to them as "codes for wording".
So, everyone who is familiar with "the code" used IS supposed to understand it. Regardless if we are talking alphabet, kanji, C++ or Python.
Unless it is poorly coded and/or a mess - which is a part of the reason why the OP questions the current practice.
Mit der Dummheit kämpfen Götter selbst vergebens
Are you just simply way too “dumb”* for the 21st-fuckin-century?
I know I’m (sadly) a minority here. And I know that I will probably get modded to into oblivion. But except from the stupid overengineering... come on!
How about for a change actually learning something, when it is useful for you?
* I’m not even really saying that people are too dumb. It’s just that most people grew up in a culture, where it made more sense, to complain and feel entitled, to getting spoon-fed, than to understand it themselves. Where intelligent people get hate, and dumb people get special treatment (e.g. it not being allowed to point out that fact about their mental performance).
So naturally, they choose the more efficient way.
But the thing is, that we all are very much capable of grasping those complex concepts that we always say we were too dumb for. It’s just an excuse. And the more it is used, the more mental growth we miss. So after some time, we really have a hard time using our brains. Just like with a muscle. Just like we all are born with the ability to some day run for hours, every day, in the heat.
So, no, they are not too smart. We’re just used to being lazy as hell.
Any sufficiently advanced intelligence is indistinguishable from stupidity.
mind reading the Whole thing??
like i said user facing stuff should be at the five year old level
API stuff should be at the level of a 7 year old (with documents)
Any person using FTFY or editing my postings agrees to a US$50.00 charge
Quite frankly I'm sick of people writing APIs that are contorted to attempt to fit into the confines of todays popular buzzwords.
Its pretty much impossible NOT to have a RESTFUL filesystem unless you intentionally go out of your way to mess it up.
REST..the *ideal* is obvious and makes a great deal sense in many contexts. REST the bastardization of the ideal over HTTP *DOES NOT*. HTTP does not allow definition of arbitrary verbs. There are no central registries or namespace hierarchies to reuse or understand the meaning of fields as in XML namespaces, LDAP object classes, SNMP MIBs..etc.
In other words no practical horizontal reuse!
If the point is reuse and possible machine understanding of subclasses REST over HTTP epicly fails. What you are left with is a contorted API that attempts to fit within a flawed framework and at the end of the day ends up being more complicated and ackward to work with had it serially been well designed without the cheap plastic REST enclosure.
Having said all this the API itself does not look too complicated or unreasonable to me. I would have made different design choices but everyone has their own ideas and audience.
The only criticism I can come up with isn't there WEBDAV or similar technologies already in production specifically for this sort of thing? Seems like re-invention of the wheel from first glance?
Your comment reminded me of this story:
http://thedailywtf.com/Articles/Classic-WTF-The-Complicators-Gloves.aspx
A mighty fine story about overcomplication :)
It's The Golden Rule: "He who has the gold makes the rules."
The Editard's Editard. At this point I really think we can class him as either an honest-to-God moron, or a really clever troll. I mean, we bite every time.
If you were blocking sigs, you wouldn't have to read this.
When someone tries to bash a cleanly designed RESTful interface as being "too complicated", you know it's a sad state of affairs. If this can lead to even one person reading chapter 5 of Fielding's dissertation, maybe some good can come of it after all...
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
http://en.wikipedia.org/wiki/Representational_State_Transfer
http://en.wikipedia.org/wiki/Roy_Fielding
"Developer", meet HTTP..
No, the user is the user. When *users* post to Twitter with a shiny GUI they don't even have to know that the Twitter API exists, what it is, what its methods are, etc.
After reading through the API, if anything, it's too simple. You can't copy a bucket without reading it from Google's servers and writing it back, which is far slower than a copy carried out within their high-speed network. The "list" capability isn't well documented. The security model is about as dumb as the UNIX/Linux one; it doesn't have capabilities or anything like that. Bucket transactions are themselves atomic, but there are no user-specified atomic transactions. You can't, for example, rename "current" to "old" and "new" to "current" as an atomic transaction. (That's a normal operation in SQL, and a useful one when you've constructed a new copy of a mostly-static table and want to make it live.) Nor do buckets have version management. There's no way to read replication status; although bucket data is supposedly replicated, when does this happen? Right after uploading a bucket, or some time later?
theodp in this post quotes from a book entitled "The Dumbing-Down of Programming."
Not content with infantilizing the end user, the purveyors of point-and-click seem determined to infantilize the programmer as well.
Judging by this story submission, it turns out he's for it.
Your brain is not a computer.
ALL of it is user facing. That's the very point of an API. The user is the developer.
In which case, being able to explain it to a 5-year old child is pointless, since that's nowhere near the lowest common denominator for software development.
Perhaps it should be explainable to a CS undergrad, but not a child.
Write your representatives! Repeal the 2nd Law of Thermodynamics!
Sure. But you shouldn't be able to explain Photoshop or vi to a 5 year old, either. Nobody would deny that they have UIs.
ALL of it is user facing. That's the very point of an API. The user is the developer.
Yes, developers are "users" of APIs. But any "developer" worthy of that moniker has an assumed baseline of specialized domain knowledge *far* greater than any 5 or 7 year old.
Yes, there can and should be will be high-level framework APIs that mask inner complexity for straightforward use cases. The open source web world is littered with such things. See "idiomatic" Ruby and Python libraries that wrap native (OS/REST/etc.) counterparts. See what MS did with C#-based APIs that wrap many of the hellish old direct Win32 calls. Sometimes an early design is refined by experience into a simpler one (cf. Plan9's dial() API versus bind/accept/listen).
But sometimes you've just got to give access right down to the metal -- the problem domain is truly complex, and oversimplification of that simply makes users' lives much, much worse.
Pay someone to abstract it for your particular domain. If the API works and has solid corresponding documentation, you shouldn't have a reason to complain.
How the hell did I get modded -1, Offtopic on this!?
*sigh*
That’s what you get when you mix the ex-taxi-driver “web designer” with the typical consultant: A Paula Bean.
Brillant!
Any sufficiently advanced intelligence is indistinguishable from stupidity.
I agree. It's pretty bad.
A programming language should make common operations simple, and other operations possible.
Any implementation of copying files that doesn't follow the form, "CopyFile (source, destination)" is probably a de facto fail.
Worse, if it can be abstracted into code like this, and isn't, it only indicates naivety on the part of the developers as to the mechanics of human behavior, and more likely than not, the kind of arrogant, lazy, slacker mentality that's worthy only of contempt.
Please do not read this sig. Thank you.
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.
Guess? You didn't say anything about the design of Google's Storage API. (Which is fine by me, since the basic premise of this thread is stupid. The storage API is designed to match the S3 API, and isn't targeting end-users in the first place.)
Sure. But you shouldn't be able to explain Photoshop or vi to a 5 year old, either.
Sure I can. Photoshop lets you paint on pictures, and Vi is like a piece of paper that you can write on.
With an API the difference is that you should be able to assume that your user will have a common lower bound on their knowledge. If your API deals with multi-threading, to be effective you probably need to assume your user knows the fundamentals of multi-threaded programming. Or, at least that the user has some base level of knowledge in computer science.
Attempting to over-simplify a concept to a child limits our ability to develop for things that aren't simple to begin with.
Write your representatives! Repeal the 2nd Law of Thermodynamics!
I'm offended at the "...kind of 'user-friendly' API one might expect from a bunch of computer science Ph.D.s" remark. My collegues and I have always strived for simplicity and elegance in code. An advanced degree is no excuse for poor software engineering skills.
In Google's defense, their APIs may be punk in many ways, but incredibly useful, and a lot of people like them.
Guess? You didn't say anything about the design of Google's Storage API. (Which is fine by me, since the basic premise of this thread is stupid. The storage API is designed to match the S3 API, and isn't targeting end-users in the first place.)
The headline is "Are Googlers Too Smart For Their Own Good?". My comment goes to the very heart of that, by suggesting above average developers can actually be a problem. It's entirely on topic!
Whoever moderated me -1, Offtopic is just plain wrong. It was an incorrect moderation.
I wonder if Google Storage can be abused as a way to host phishing pages?
There's a phishing page 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. 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.
Theo neglects to mention in his trollish post that google is using defacto industry standard. So it is not google that decided to overcomplicate things. also, because it is standard, you should (i have not tried admittedly) be able to use whatever language bindings/libraries/guis that you want to access the service.
Why would anyone take advice from a guy with an AOL email?
Why is it so hard to only have politicians for a few years, then have them go away?
I think you lost the context. RobertLTux, the one who started the 5 and 7 year analogy in this thread, pretty much did, and he's defending it in the thread. His stated rule was: user-facing = 5 year old, API documentation = 7 year old.
If the API is mean to your users, as a software developer, you should intervene. I've heard that they have these new-fangled "thingies" called "user interfaces" (UIs) and even newer thingies called "graphical user interfaces" (GUIs). GUIs allow a developer to intervene even on behalf of users so stupid that they cannot read and to translate their wishes for processing by the API. In this way, you can shield your users from the complicated, convoluted, and confusing APIs.
I think that's the point though. In a world where complicated is the norm yet we (claim to) want to bring computing to the masses, releasing a new service with yet another complex api seems counter to our goals (I say "complicated" in terms of volume, not in time-to-learn for someone familiar with APIs).
This is the company that brought real, effective search to the masses and collaborative document authoring/editing to companies full of PHBs. Google knows how to make complex things simple for the user. So given all this, I think the argument is rather the old standby: Do we need another X? In this case, do we need another cloud storage solution with nothing but APIs? S3 was bad enough. I don't see anything differentiating this service.... yet.
Sony ha
Mike McConnel would disagree with you, and so would I. It's covered in "Code Complete", somewhere. The analogy he uses refers to coffee machines, IIRC.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
If only they had to be worthy of the moniker to get a job...
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Have you ever looked at how WebDAV works ? It's more complicated and I don't think it's very fast.
I really don't like how they put paths in the XML either, that's just stupid, if you have a proxy, it shouldn't look at the content, just the method/URL and know what is it's for.
New things are always on the horizon
Take a look at google's homepage. If you can't figure it out, get off the pot, er the tubes!
Everything is vague to a degree you do not realize till you have tried to make it precise. - Bertrand Russell
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.
Simple: kdawson.
"Go forth, and be excellent to each other" --Bill & Ted
The headline is "Are Googlers Too Smart For Their Own Good?". My comment goes to the very heart of that...
Well there's your problem. You've mistaken assumed that the title is in any way related to the summary, or that either of those are in any way related to the article.
Well there's your problem. You've mistaken assumed that the title is in any way related to the summary, or that either of those are in any way related to the article.
Heh, yep. My mistake. :)
I don't understand how this is any harder (or much different :)) than say Amazon's S3 API? theodp, can you explain what's 'user-unfriendly' about the API compared to what you would conceive while still supporting the same features they have? Anyway, the 'user-friendlyness' usually comes when someone writes wrapper around the RESTful API for the platform you're using. Take a look at their Python API and let us know if you still think it's 'user-unfriendly'.
You're complaining that the API for Google Storage for Developers isn't user-friendly?
This is for developers writing web apps requiring guarantees of security, synchronization, reliability, etc. It's not supposed to be a more "legit" version of Dropbox.
*snickers* n00bs
that would be Steve McConnell. No idea who Mike is.
Next time don't advertise on the front page of Slashdot you can't implement a basic REST API.
If you're looking for a way cool way to store and share (or not share) you code/files, just check out Dropbox. It just works!
Reason: Works for me. Comment: Nice API and easy to understand too.
The bigger question, really, is how come if somebody thought that that list of steps to copy a file was good enough to be an example of how to perform a simple task using the API, then why aren't those steps encapsulated as a reusable function that just gets called with the source, the destination and the objects to copy.
It just strikes me as programming at the wrong level of abstraction--which is, quite frankly, the most common flaw of programmers everywhere.
Are you adequate?
Developer is the user relative to the API (and also compiler, IDE, and other development tools). What's so hard to grasp about this concept?
It's not like God has ordained that there shall be users, and developers, and never shall they mix.
I sometimes hire people to work in my programming group. If you have a PhD, you have to work EXTRA hard in the interview to prove to me you can do useful work. Over the nearly two decades I've hired programmers, I've generally been most impressed by the work of former auto mechanics who taught themselves to program, and had a passion for it, rather than people with advanced degrees from Ivy-league schools.
I cannot tell you how many times I have had a tricky problem to delegate, one that I have some ideas how to implement. Invariably, the PhD will tell me it can't be done, can't be done well, or will offer to write up a whitepaper explaining why it's a bad idea to try(!) ... while the mechanic rolls up his sleeves, pulls an allnighter or three, and in the end has something ugly and fragile -- but that basically works, and buys time for the next iteration.
Part of the Second American Revolution!
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... and more blah blah...
The fact that you erroneously mix user-friendly with API tells me you are not a developer, or at least not one worth listening to when it comes to API design. And the fact that you state we should not expect better from a bunch of computer science Ph.Ds is an indication of projection and ignorance. What do you know about Ph.Ds? About their work and what they do? Did posting that generalization made you feel good about your webby education?
Seriously, if you were really that serious (and intellectually/professionally) capable of, you should have broken down the problem and shown a better alternative. But you didn't. You can't. So shut up.
I've just read the GSfD documentation, and the API is exactly the same as that of Amazon S3, which has been comfortably used by developers and web designers for years now.
Why was this story approved?
Yes, but a developer is presumed to know something about APIs. It seems odd to me that any good can come of development by a developer that can't even understand a simple API. From what I saw on the site, it wasn't that bad at all, most of the end user stuff was similar to *NIX and the developer section wasn't terribly taxing either.
In which case, being able to explain it to a 5-year old child is pointless, since that's nowhere near the lowest common denominator for software development.
Apparently you've not worked with some overseas developers. At least a 5-year old will *try* to understand what you're telling them not to do.
A truly "smart" person knows that almost everyone he meets is "dumber" than him. So he spends his life talking to people who are "dumber" which causes one of two reactions. He either becomes arrogant or he becomes humble. Arrogant is easy to explain. This arrogance is born of the knowledge that you are "better" than most of the people you work with.
Humble is harder. The humility comes from years of seeing what the "best" path is and trying to save people from their own stupidity and finally realizing that all the genius in the world is worthless if it doesn't help anyone. Humility is the knowledge that no matter how genius you are it is pointless if your genius is consumed in a self-serving intellectual Ouroboros.
I test in the top 2% for intelligence. This means 98% of the people I meet are "dumber" than I am. There are also a vast array of people far more intelligent than I am. People that make me look like a total moron. From this vantage I can see that without making my intelligence available or useful then all of my talents are a "chasing after the wind" and only so much "sound and fury" amounting to nothing. Such a rating is worthless and meaningless unless it yields a result in some context (evolutionarily or otherwise).
This last step toward humility requires a tiny bit more intelligence and wisdom than arrogance does.
Let's say Google hires the smartest 2% of programmers on the planet. The reaction will probably either be arrogance or humility. So if this is the product of genius what is it? Inaccessible arrogance? Then they are using the wrong metric for intelligence and don't have programmers that are smart enough in the right ways.
Humility is harder. Humility is precious. Humility requires real intelligence.
[signature]
Smalltalk's creators didn't agree with you - I wonder if they do today.