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.

 

About


Google App Engine is a service that allows developers to deploy web apps that are then run on Google resources utilizing the expertise Google has in scalability and servers.

Language wishlist


Currently Google App Engine supports Python. There is speculation and hinting from Google that more languages will be added. It will be interesting to see which languages will be added first and which ones simply will not make the cut. Personally, I'm not surprised that Python is the flagship language, there has been well documented preference to Python from Google. (Random Google support page shows a .py extension indicating the Python language being used http://www.google.com/support/talk/bin/topic.py?topic=1186)

As it is little surprise that Python is currently supported, it leads to the question of which languages will be supported and in what order will languages be brought under the Google App Engine umbrella. My speculation is that Ruby will be the next language adopted followed by Perl. After that, I struggle to determine what will be logical. My personal wish list goes as follows:

  1. Ruby

  2. Erlang

  3. Rhino

  4. Java



In reality, I don't think Erlang will be brought on. I love the language, but I doubt it will be part of the App Engine stack. One of the major benefits of Google App Engine is the fact that Google is going to manage scalability for you. As a result of this control by Google they prohibit you from doing it yourself. Although used by a different name than threading, Erlang's processes would probably be out of the question as well.

What would I create


Honestly, I don't have an idea. I do not yet have an active account. (I hope that changes soon.) As I understand at first, developers are given 3 apps they can create and are unable to delete an app should they change their mind. In other words, choose carefully. If anyone has any suggestions for potential apps, please let me know.

Wrap up


While much more can be said, and has if you track appengine on twitter, that is all I'm going to say at this time other than my opinion. I do believe that Google App Engine is a very significant milestone in cloud computing. I believe it enables people who may have had limited resources but good ideas an opportunity to show the world what they can offer. I'm excited to see what happens.

 

Link Roundup 04/08 Part 2

Tuesday, April 08, 2008 - 11:56 AM
No Comment - Post a comment

The blogosphere has been quite active today talking about Google's App Engine. This activity has been a very interesting use case for twitter. Due to the newness of the App Engine I wondered how much good content would be available about on this subject. I determined that search engines probably wouldn't have scoured the web quickly enough to get all posts, so I turned to twitter. I used the command "track appengine" and found everything from short opinions, talk about apps, links to blogs, and apparently people showing off that they made it in the top 10,000. I'm not jealous, really I'm not. Buncha snobs anyway! ;)

 

I'm posting an early link round up today, but there will be another to follow at the end of the day. The reason for the early post is I wanted to dedicate an individual post to Google's new Appengine that was released last night.

Apparently Appengine was made available for the first 10,000 individuals who signed up. At 6am, I'm on the waiting list. I'd be interested to know just how quickly it took to get 10,000 developers to sign up.

I think Appengine represents a significant milestone, one that I have been waiting for Google to do for quite some time now. We've had cloud computing available from Amazon.com, and I truly feel they paved the way for this. However, for any size deployment you pay. At Appengine, that isn't the case, they quote that it is free to get started:

Every Google App Engine application can use up to 500MB of persistent storage and enough bandwidth and CPU for 5 million monthly page views.


Suddenly, anyone with an idea for an online app can immediately begin prototyping their idea with relatively little overhead cost.

I do see a few drawbacks:

  • Language availability - Currently only Python is supported. In the Appengine documentation, it states other languages may be added. link

  • Pricing unknown - Currently, the pricing structure for going over the free user quota isn't made known to the public. Additionally, you aren't allowed to go over user quota without specifically making a request to Google. Until pricing is made known, I would be wary of putting all my eggs in this basket. However, knowing Google, I'd imagine pricing will be appropriate for the service provided.


Links:

 

Link Roundup 04/07

Monday, April 07, 2008 - 4:35 PM
No Comment - Post a comment

  • What cloud computing really means | InfoWorld | Analysis | 2008-04-07 | By Galen Gruman,Eric Knorr
    (tagged as: cloud)

  • Official Google Blog: Cone of silence (finally) lifts on the spectrum auction - Wow, google basically was willing to pay for their principles.

  • Eclipse IDE at a crossroads | InfoWorld | Analysis | 2008-04-04 | By Paul Krill

  • 700MHz spectrum winners detail plans | InfoWorld | News | 2008-04-04 |

  • Mike Downey on Adobe » Seesmic acquires AIR-based Twitter client Twhirl [via ReadWriteWeb] - Someone made money off AIR. twhirl is my favorite twitter client.
    (tagged as: via:twitter)

  • How to Customize your Terminal Prompt -
    (tagged as: terminal osx tips)
  •  

    Link Roundup 04/04

    Friday, April 04, 2008 - 9:44 AM
    No Comment - Post a comment

    I will more than likely send out another link roundup today, this includes yesterday afternoon's findings. The highlight of today's links has to be the Joe Armstrong interview. I thought it was well done and very interesting.

  • Macworld | iTunes Store now top U.S. music retailer - I think it was me personally who made them number 1

  • Christian Cantrell: Lineup: an Exchange calendar viewer for AIR

  • Episode 89: Joe Armstrong on Erlang | Software Engineering Radio - Impressive interview. Joe talks about the origins of Erlang, concurrency, pattern matching, fault tolerant systems.
    (tagged as: erlang)

  • Headius: Shared Data Considered Harmful - I love Ruby, but it is interesting to note how these problems with Ruby are avoided by design decisions of Erlang.
    (tagged as: concurrency ruby)

  • Motorola: WiMax will be big -- with or without Sprint | InfoWorld | News | 2008-04-03 |
    (tagged as: wimax)
  •  

    Link Roundup 04/03

    Thursday, April 03, 2008 - 12:12 PM
    No Comment - Post a comment

    Only thing to note is that the link content was generated using Erlang. I wrote a program that pulls data from my del.icio.us account and formats the links for me. It isn't completed, but it works.

  • Twitter / dan mcweeney: TextMate > Bread.Slice()...

  • Ted On Flex: Why Erlang?
    (tagged as: erlang flex)

  • InfoQ: RESTful Services with Erlang and Yaws
    (tagged as: erlang via:twitter yaws rest)

  • Damien Katz: Signs You're a Crappy Programmer (and don't know it)
    (tagged as: programing via:mike)

  • dilbert2006112580402.gif 600×202 pixels
    (tagged as: dilbert)

  • Leopard Technology Series for Developers: Broadcast Your Application's Content with iChat Theater
    (tagged as: applescript ichat)
  •  

    Link Roundup 04/01

    Tuesday, April 01, 2008 - 2:41 PM
    No Comment - Post a comment

    Well, I am not allowed to mock Matt on his spelling. I released ServiceTrax's roadmap with two glaring spelling mistakes today. I'm trying to pass it off as a April Fool's joke. No one is buying it.

    Speaking of April Fool's jokes, there are some pretty good ones in my link roundup today.