en-us http://www.keithwatanabe.net/index.php Keith Watanabe's Website http://www.keithwatanabe.net/blogs/2007/8/6/0e1850365f0a8608d1a729dc46daa530.html
The video linked below emphasizes simplicity. Programming and interfaces are all about APIs. I like to use what I call the "Eddie Van Halen Theory of Guitar Pedals." Eddie Van Halen used to go down to his local music shop to find the next latest and greatest gadget. The owner would attempt to pawn off something sophisticated with an incredible number of options. The editor article asked him, "So do these give you too much control?" Eddie's reply was, "No, they they don't provide any control!" He goes on to demonstrate how things like his guitar only has one knob. Why is this important?

This is linked to Apple's success and why Linux hasn't quite taken off as home operating system. The formula is this: keep things simple.

The less number of arguments in your API, the less options being handed out, and the more that the actual implementation can handle are the keys for developing successful APIs. Make things behind the scenes do all the work and keep it invisible from people. I've seen for instance Japanese coding. It's horrible. However, when I use a Japanese keitai or drive my Toyota around, I never say a thing. That tells me that the insides of these devices are probably equally complex and horrid, but the bundling forces me not to care about those details.

Part of how I design APIs involves having the object absorb information through numerous setters and then calling a process method which takes all the setters and does something magical on the backend. People don't need to know what process() does, they just need to know the outcome and expected outcome based on the various attributes set on the object.

Likewise, I tend to limit the number of parameters and return values being sent back. You should set up some arbitrary rule where the number of parameters should not exceed 2-3 and limit the checked exceptions on your signatures (that is, if your language supports this feature). If you need more values to be passed in, consider using an object with various attributes as options or maybe an associative array/hash. In those cases, an object is great if you have a limited number of attributes, whereas an associative array works best if the number of attributes start overflowing. For instance, at work I have this horrible form object that probably has around 40-50 attributes. The thing that drives me crazy is that there's no easy way to avoid the set/get dilemma (which is really more of a problem with the way the damn forms and page flow was designed rather than an application issue).

The other reason why this is important is that probably you want to hide how things work for people. It's psychological. If a killer developer, for example, saw 30 select statements being regenerated in the code, there's an automatic temptation to 1) avoid using the API; 2) attempt to optimize and break the code himself. But if the developer was under the assumption that the code just would work out of the box, he wouldn't spend the time normally attempting to fix it and focus on how he could use it to solve his more immediate problem.

Lastly, design APIs for usage, not performance. APIs are best thought of in terms of interfaces. Some languages don't support it or don't support it well. However, if you change your attitude to force people into thinking in terms of usage rather than optimization, part of your headaches will be relieved. Why? You're more worried about how people will use it and if it even has an audience. No one likes an overcomplicated thing that they must employ. EJBs for instance were cumbersome and imo failed except as a marketing ploy by Sun. People like and need simplicity. So aim at that rather than going for performance.]]> Mon, 06 Aug 2007 10:47:50 -0600 http://www.keithwatanabe.net/blogs/2007/8/6/0e1850365f0a8608d1a729dc46daa530.html http://www.keithwatanabe.net/blogs/2008/2/17/064bb12bad0eaf3c1d53a99114cfa7a1.html SLOWLY plowing through this library. It's really horribly documented. There's almost no tutorials and the example code is poorly written. Unfortunately, I haven't seen any other libraries with the flexibility as this one so I decided to implement it.

Well, I've managed to get my code to the point where I can authenticate round trip. Now, it's up to me to finish up the whole login/registration process. Tonight, I hit a major stumbling block where I didn't know that the stupid library uses the $_SESSION global behind the scenes in setting up some key values. In my case, I do something where I shut the session down temporarily. This is for login purposes. However, when I did that, obviously, the library wasn't able to extract the data from the session. Well, isn't that convenient! The sample code for the consumer doesn't mention a damn thing about this. And secondly, I'm now facing an issue where I'll have to figure out if this will disrupt anything during the login process that I wrote up.

On top of that, I spent hours logging various messages trying to figure out where the killer point was. I had to go through those fugly libraries and went a bit nuts placing tons of data dumps all over the place.

Before this incident, I had tried building my own system but had numerous problems trying to get it to authenticate. Then I realized that one of the return points wasn't setup yet and so the authentication server wasn't providing a response. However, the library makes no real mention of this and I couldn't really see for a few days what was going on.

There's, of course, other hitches and hurdles that I'll probably face as I descend lower into the details of the library. But I think when I nail this thing down, I'm going to write up a good tutorial so people won't have to go through the same pain that I'm suffering]]> Sun, 17 Feb 2008 03:36:58 -0700 http://www.keithwatanabe.net/blogs/2008/2/17/064bb12bad0eaf3c1d53a99114cfa7a1.html http://www.keithwatanabe.net/blogs/2008/2/21/92e141ebb99ea15b96b03f8631951c15.html
This whole situation got me thinking the other day about other major companies and how they could open more of their systems to developers to improve what they can do in creative fashion. In relationship to Google, as I mentioned with YouTube, they ought to continue opening up their applications to allow more developers to contribute to them. Although they are the giant in search, video, advertising and whatnot, they still suffer in terms of quality at times.

For instance, I find their search to be limited, constantly filled with junk results that waste my time. And certainly others must feel the same way. That isn't to say what they have is poor. However, the reality is that their search product needs a massive facelift and internally I'm not certain that the developers are able to push out their products fast enough. Similarly, I find Ads to produce a plethora of irrelevant junk ads when I had hosted them on my site. And I already mentioned what we could do with YouTube's player.

As a result, I've concluded that a potential business development move that Google ought to make is to open more of their APIs, most notably search, Google Apps, YouTube, and Ads. I noticed that Google had cut off their older web service where people could extract results via XML. This service was rebuilt as an AJAX type of search, which in my opinion, is practically useless for people who want to do more with their results. You have to use their branded search and the API is rather bulky and limited. Of course, the purpose is to maintain their hegemony over the search market. But I think this is a dangerous mode of thinking for them.

Instead, opening up more of their APIs would allow smaller businesses created by highly motivated and talented developers to improve upon Google's products where their current staff isn't. In turn, Google could also act as a venture capital company that could provide seed money for these small businesses and perhaps a controlling stake in them. In some ways, it's almost like hiring developers but in truth my plan would allow Google to let smaller, more focused teams do what they need without the business criticality one might come to expect in working at Google. I mean, if I wanted to work on a better search interface at Google, I probably wouldn't be able to, except during my 20% situation. That limits my productivity to 1 day a week as opposed to 5 up to possibly 7 days of pure coding.

Another clear benefit would be that Google wouldn't be forced to go through a dedicated hiring process. They might require a business review process if they go with the seed money/controlling interest thing. But in the end, the goal would be an acquisition if the application becomes successful. This, imo, works for both parties as Google would supply the base technology while the venture would handle everything else.



]]> Thu, 21 Feb 2008 18:30:16 -0700 http://www.keithwatanabe.net/blogs/2008/2/21/92e141ebb99ea15b96b03f8631951c15.html