RantOn: External Services and API

/rant on

While taking a break from the work effort I thought it may be cool to write a tiny module that was pluggable for my blog and possibly other services. I’m a huge fan of iLike. I love music and listen to it all the time. However, there are never enough hours in the day to find new artists and new music. Pandora is a great tool for this too but it’s not socially generated. This is where iLike has hit the nail on the head. Where they fail however is opening their API.

I am of the opinion that if you are gathering information for social networking purposes that you should allow developers to extend that functionality. I felt like creating a fast little php template that pulled information in from their site that I had full control over. Generally not too much to ask. LibraryThing, del.icio.us, and others do it so I assumed that iLike would do the same. However, it appears that they are more geared towards having their own marketing than letting anyone create what they want. They have a flash widget that they allow you to put on your site, but what about those people that want to customize the look and functionality? This widget is very limiting.

The problem I have with this and any other service that leaves out the open API is that they are really restricting the developer community from making awesome applications utilizing their services. I tend to like to customize the look & feel and functionality of tools and sites that I create. Why cant it be the same with services like that. It’s really not complicated to make rpc/soap available to the community, so why not do it?

My plea to all of you creating new applications. Make time and some effort for services. Provide some external API that developers can plug into and use. It will not only help them, but it will help you too. Be kind to the community. Give back, give us an API.
/rant off

Undertaking Projects

So I read a post from a friends blog, “Working Small”, and after I read the quote from Linus Torvalds in it I decided it was time to argue points.
Well, the next day at work we talked about the quote because I was curious about perspective on it and it seemed that we both agreed. What we both took the quote to mean was that looking at a project can be a very daunting task. Taking it from start to finish while meeting requirements, fixing bugs, working with new technologies, etc. is quite complicated. However, what we concluded is that the quote really depicts a view on how to go about working on these kinds of projects.

First you must understand that projects for clients are going to need to be thought out, put into a timeline, and then worked on until completion. However, what concerns me is the working on until completion part…thats the portion I do. If you start out by taking some project and work on it’s entire architecture and _then_ begin to develop it, you may have problems.

One of the problems, and possibly the worst, IMO, is the lack of agility. You will have a much more complicated time restructuring a system if you go through the architecture in advance of any of the development. Instead, if you focus on smaller tasks you will have a better idea of the start and end points and be able to develop with a clear vision in mind. Also, you have more ability the change an API or develop new ones as you are developing it due to certain needs. You are less likely to be able to change due to clients needs. Many projects go for some period of time and due to this, requirements may change. The client may decide over that period of time that the functionality of requirement ‘x’ actually needs to do ‘y’. In a hard fast architecture you have 0 agility. Instead, you need to add more to the application which creates bloat and functionality that may not be used. This leads to the inability to refactor your code effectively without leaving broken windows.

Now, these ideas are not new. The guys over at the Pragmatic Programmer have been talking about it for some time, however, I thought that the quote was the common link between what those guys are saying. It really embodies the view most developers should have when undertaking a project. While some architecture is important, it should not be the entire focus of the initial stages of development. There is something to be said about building prototypes and hashing ideas out before really designing the architecture of the final product.

You must have some idea of where you want to go, but that does not mean you should throw agility and prototypes out of the window.

Effective API Design

When I sit down to write an application I usually try to come up with some prototype of how I think the code base should be designed. Many times this prototype is off in one way or another, but it allows me the ability to modify the functionality easily. Prototyping the API allows me to better design the architecture. Once I’ve decided on the architecture and API I can then have other people implement additional functionality atop the API I’ve created. However, once I’ve exposed this API it becomes increasingly more complicated to refactor naming and functionality of the API.

The other day I was searching for some Java related information and found a lecture given by the author of the book Effective Java, Joshua Bloch. I listened to the whole talk and read through his slides and he really hit the nail on the head. He makes references on how to design API, how to develop methods, how to decide on parameters, etc. He even comments on effective documentation, a major side of dev. that developers choose to skip, including myself.
Video in Flash (about 1 hour 9 minutes) - http://www.infoq.com/presentations/effective-api-design
Slides in PDF - http://lcsd05.cs.tamu.edu/slides/keynote.pdf