Link Roundup 04/25

Friday, April 25, 2008 - 3:53 PM
No Comment - Post a comment

 

Video on BigTable

- 1:38 PM
No Comment - Post a comment

 

Link Roundup 04/21

Monday, April 21, 2008 - 11:11 AM
No Comment - Post a comment

 

Link Roundup 04/15

Tuesday, April 15, 2008 - 5:28 PM
No Comment - Post a comment

 

Link Roundup 04/14

Monday, April 14, 2008 - 4:42 PM
No Comment - Post a comment

Pretty short link roundup today:

 

Link Roundup 04/11

Friday, April 11, 2008 - 4:13 PM
No Comment - Post a comment

I'm personally pretty excited about the possibilities of Google App Engine, however, it is worth noting that there are some potential pitfalls. Today's link roundup points to a few people's hang-ups with the service. It is my opinion that one would have to weigh these potential problems carefully to determine if the risk is worth the gain.

 

Wow, the Java/Groovy request is really gaining momentum over on the Google App Engine Issue list. This is now the number 1 request with the Ruby request ranking 2nd. Perl, an early leader has really dropped today coming now in 4th place.

I have no idea why this fascinates me so, but it really does. Perhaps it gives me a touch on the pulse of desired programming languages in this realm.

 

It isn't a surprise to me that at this writing Ruby is the number 1 user requested feature on the Google App Engine Feature/Issue tracker.

Whether or not Ruby has the largest user base for this type of environment or just the loudest is hard to determine. I've starred the Ruby feature as well as the Erlang request, which isn't doing very well. As I mentioned earlier (felt like that was a play on words with Erlang) I expect Ruby to be one of the first if not the first language brought on. As well, I just don't think that Erlang for the reasons using their processes will be brought into the stack.

If Erlang is made available, I can only think it will be a very stripped down version that lacks most of what make Erlang relevant to me. I don't have a problem with this as the theory is that App Engine is handling what I would have to code for in Erlang anyway.

If you feel passionately about a particular language or feature for App Engine, head over to the issue tracker and make your vote known. There is no guarantee that these issues will be granted by Google, but I can't help but think that they will be seriously considered if enough people are voting for them.

 

Pattern Matching Brilliance in Erlang

Thursday, April 10, 2008 - 10:06 AM
No Comment - Post a comment

I'm preparing a blog post on guards and pattern matching in Erlang as it pertains to XML parsing. Until that post is finalize and published, I do want to mention just for a moment how great I think pattern matching is in Erlang. To do so, I'm going illustrate a very simple function in Erlang. This sample code isn't meant to demonstrate concurrency and isn't the best search method by far as it is of order N. However, it is interesting to see what can be done with pattern matching.

Our scenario is that we have a list (similar to array in most languages) and a value. We want to determine if the value is contained in the list. The code is as follows*:

lookup(Value,[Value|_]) -> found;
lookup(Value,[_|Tail]) -> lookup(Value,Tail);
lookup(_,[]) -> not_found.


The call would simply be:


Found=lookup(Value,List).


Now to dissect what is happening. Our lookup function listed above is recognized as one function in Erlang. The function name is lookup and the arity is 2. Erlang determines which part of the resulting code is executing in this function depending on what values are passed into the function.


  1. When the lookup is being called with a search value of "Jeremy" and the head** of the list is "Jeremy", the first result is evaluated and found is returned.

  2. When the head** of the list isn't "Jeremy", but there are still elements in the list, the second result is evaluated and lookup is returned by calling it again with "Jeremy" being the value and the tail** of the list being passed in as the list.

  3. When the value is "Jeremy" but the list is empty, the atom not_found is returned.



To me this is very elegant. I absolutely love this way of thinking.

*This code is very similar to what is found in the book Progamming Erlang - Software for a Concurrent World by Joe Armstrong. I recommend this book to anyone wishing to learn more about Erlang.

**The syntax [Head|Tail] is an Erlang syntax to access the first element of a List represented in the variable Head while the remaining list is stored in Tail. If my list was ["Jeremy","Dave","Mike","Matt"] Head would be "Jeremy" and Tail would be ["Dave","Mike","Matt"]

 

Recently Flickr increased their feature set to include uploading and storing of video content. This upgrade in feature set has left some Flickrs quite angry. (Additional article providing some insight to this here.)

One argument presented by Flickr users is that currently, Flickr is a photography sight dedicated to photography and photographers.

"We the undersigned members of Flickr, free and pro, agree that video has no place on Flickr. Other sites on the web accept video already, but do not accept photos. We all joined Flickr because of it's dedication to photography and photographers, and we want Flickr to remain true to this dedication. It is our request that this feature and addition to Flickr be removed."
As such, expanding it takes away from the experience and the community. Whether I agree with that or not, it has been my experience that adding features sometimes dilutes your product leaving it less focused at accomplishing the tasks that may have made it very popular. Whether or not this will happen with Flickr remains to be seen as on the other hand, sometimes additional features are what you need to stay on top.

Twitter seems to be facing a similar dilemma. As it currently stands, Twitter is a very focused application with the aim of delivering very short (140 characters) text based messages for users to users. There have been requests to expand their feature set to include payloads. As of yet, this request hasn't been granted. However, other services such as Pownce have filled this niche. I have memberships at both. I use twitter much more often than Pownce. I'm not sure if it is the simplicity of Twitter that attracts me, or the user base. Either way, it will be worth tracking.

To me, Google App Engine is also occupying the space of limited feature set, they offer web application hosting. Amazon EC2 seems to be at the opposite end of the spectrum, they offer complete virtual computing. Due to these differences in scope, I do not feel that they are competing products. App Engine's goal is to provide a place to deploy your web app making it highly available. It will only host your web app. You can't currently store files although you do have data storage with Bigtable. I don't believe this will change. EC2's goals seems to be to provide a service to be able to scale your servers. Both are very simple feature sets although they may seem difficult at times. EC2 is virtual servers. Set them up as you may wish. App Engine is to provide a space for your application to run. I think each would struggle if they tried to accomplish both goals.

My personal opinion is that if you offer an application, decide what it should do and have it do it well. I am wary of expanding applications to handle increasing bigger feature sets. It makes them bloated and if you aren't careful they also become very difficult to use. I have written applications that have this problem. I try to avoid it but sometimes it is difficult to determine when a request will make the overall user experience more enjoyable, or open the road to increasing complexity and problems.