I just received a new ObjectWatch newsletter by Roger Sessions and it really struck a cord with the Enterprise Application Fabrics Scalability Simplified message that I’ve been evangelizing.
The latest newsletter describes a process coined by Roger called Simple Interactive Partitions (SIP). The basis of which is a process based on a mathematical model for simplifying enterprise software's architectural complexity.
One of the blog’s I’ve been following (besides Bob’s here at Appistry) is Marc Andreessen’s from my old nemesis Netscape. I really have enjoyed some of the insights Marc has shared around startup’s, VC’s and most recently, Career Planning.
In his career planning post, he shares a couple of rules that really resonated with me and I think they are worth repeating. Marc’s career rules –
I’ve been following a blog thread by Hillel from Jackson Fish Market discussing the development trade off’s startups make between features and scalability and I had to point out this link called “The Constipation of Scale”. In his post, Brad Feld does a fairly good job of describing the development trade offs associated with keeping VC’s happy with features, and actually building a solution that scales. And I wanted to respond by describing how one of the startups we have been working with Clearent, was able to release new ‘scalable’ features on a timeline that satisfied their investors.
I just got back from attending a Microsoft HPC conference in Redmond Washington this week and during one of the breaks I had a chance to talk to another attendee who had previously worked at Microsoft back in the late 80's / early 90's. What this gentleman and I found we had in common was that back in the late 80's he taught at Microsoft University (which was Microsoft's only training facility in the 80's) where I had attended a couple of OS/2 development courses.
I just recently attended the Google Conference on Scalability in
Per my last post, I've been architecting a fabric application that would consume Twitter.com messages (timelines in the Twitter API vernacular), store them in SQL Server and generate some usage reports that I wanted to post in a graphical way on the web.
The implementation of fabric client that consumes the REST messages from Twitter.com was straightforward. Loading the Twitter public user timeline via the xmlDoc.Load works great, and parsing the last twenty messages via the xmlDoc works great.
xmlDoc.Load(url);
In an Interesting blog entry by Josh Kenzer - 5 Question Interview with Twitter Developer Alex Payne Alex points out that twitter was built using Ruby on Rails and has run into some Rails database performance issues. I personally don’t think that Alex’s description Rails inability to connect to multiple databases simultaneously is correct as do a lot of people on the Loud Thinking blog discussing Twitter Trouble.
