DevHawk
Passion * Technology * Ruthless Competence
Weblog
Archives
Custom Content
TechieWife
DevHawk Designs
Thursday, January 03, 2008
« Morning Coffee 133
|
Home
|
Morning Coffee 135 »
Morning Coffee 134
Bill de Hora
responds
to a few of my
Durable and RESTful
ideas. He points out that relying on a client-generated ID can be troublesome, and recommends using multiple identifiers - one created by the sender, one by the receiver and one representing the message exchange itself. However, the sender ID is vulnerable to client bugs & tampering as Bill points out, and neither the receiver ID nor the exchange ID can be used to determine if a given message is a duplicate. If you don't trust the sender, is it even possible to determine if a given message is a duplicate?
Pablo Castro
confirms
that there are "practical limits" to what ADO.NET Data Services can do with respect to
idempotence
. Nothing in his post was surprising, though I hope it will be more explicitly called out in the final docs. Developers used to the comforting protection of a transaction may be in for a rude awakening.
Dare Obasanjo has a
great post comparing
the new features in C# 3.0 to dynamic languages like IronPython. I believe many of the productivity aspects of dynamic languages have little to do with being dynamic.
Pat Helland
noodles
on durability and messaging, two topics near and dear to my heart (probably from working with him for a couple of years). I'm not sure where he's going with this - his conclusion that "Basically, big, complex, and distributed system are big, complex, and distributed" isn't exactly ground-breaking. But his point that "durable" isn't a binary concept is worth more consideration. Also, his description of IMS only looking at the effects of a committed transaction is very similar to how web sites work, though obviously HTTP isn't durable so you can't make event horizon optimizations like IMS did.
Tangentially related, Werner Vogels discusses the idea of
eventually consistent
distributed databases. Today, that's a problem mostly only Internet-scale sites like Amazon deal with. In the near future of continued data explosion + manycore, we'll all have to deal with it.
Nick Malik
argues
that categorizing enterprise applications by lifecycle is much less useful than categorization based on organizational impact. He might also need a new chair.
Jesus Rodriguez
digs into
one of SSB's new features in SQL 2008: conversation priorities.
Arnon Rotem-Gal-Oz and Sam Gentile are mixing it up over the definition of SOA. Sam
thinks
SOA has to include business drivers and Arnon
doesn't
. I'm with Sam on this, defining "SOA" independently from "Applying SOA" seems pointless. Then again, rigorously defining SOA - much less arguing about said definition - seems like a waste of time in the first place IMHO.
Wow, this guy Zed is
mad at the Ruby community
.
Andrew Baron has
8 Reasons Why The TV Studios Will Die
. Personally, I think reason #2 - Expendable Middle-Person - is the most important. If content producers can reach consumers directly, what value-add will the networks provide? (via
United Hollywood
)
Posted By
Harry Pierson
at 10:00 AM Pacific Standard Time
Comments [0]
Architecture
|
SOA
|
Durable Messaging
|
Dynamic Languages
|
Idempotence
|
Media 2.0
|
Morning Coffee
|
REST
|
Ruby
Comments are closed.
Email DevHawk
Subscribe to DevHawk
Call DevHawk
DevHawk on Twitter
DevHawk on Facebook
DevHawk on WLM
DevHawk
World Tour 2008
Upcoming Dates
PDC08
patterns & practices
Summit 2008
Øredev
RayTracer
Blog Archive
September, 2008 (4)
August, 2008 (8)
July, 2008 (16)
June, 2008 (1)
May, 2008 (6)
April, 2008 (12)
March, 2008 (18)
February, 2008 (14)
January, 2008 (14)
2007 (245)
2006 (174)
2005 (150)
2004 (252)
2003 (262)
Recent Bookmarks
Tags
.NET Framework (2)
ADO.NET (5)
Agile (7)
AJAX (3)
Architecture (284)
Guidance (6)
Interop (2)
Modelling (61)
Patterns (7)
Process (4)
SOA (93)
Web Services (5)
ASP.NET (24)
Battlestar Galactica (3)
BI (2)
BizTalk (4)
Blogging (115)
dasBlog (11)
Podcasting (4)
BPM (1)
C# (10)
C++ (4)
Capitals (5)
CardSpace (3)
CLR (2)
College Football (10)
Comedy Central (1)
Community (81)
Concurrency (6)
Consumer Electronics (1)
Database (13)
Dependency Injection (2)
Development (117)
C Plus Plus (1)
Embedded (5)
Lanugages (37)
Media (2)
P2P (11)
Rotor (1)
SharePoint (6)
SOP (3)
DIY (1)
DLR (14)
Domain Specific Languages (13)
Durable Messaging (5)
Dynamic Languages (10)
Dynamic Silverlight (1)
Education (3)
Enterprise 2.0 (1)
Entertainment (14)
ETech (15)
F# (51)
Functional Programming (17)
Game Development (2)
Guidance Automation (3)
Hardware (8)
HawkEye (3)
Hockey (29)
Home Electronics (1)
Home Network (5)
Humor (5)
IASA (1)
Idempotence (3)
infrastructure (5)
Instrumentation (4)
Integration (2)
IronPython (27)
IronRuby (11)
Java (2)
Job (3)
LINQ (19)
Live Mesh (2)
Lost (1)
Master Data Management (1)
Media 2.0 (6)
Microsoft (29)
MIX06 (2)
Mobile Phone (1)
Monads (5)
Morning Coffee (172)
Object Oriented (4)
Office (5)
Open Source (5)
Open Space (2)
Operations (3)
Other (135)
Art (1)
Books (1)
Family (31)
Games (18)
General Geekery (26)
Home Theater (1)
Movies (23)
Music (20)
Politics (3)
Society (1)
Sports (37)
Working at MSFT (15)
Parsing Expression Grammar (16)
patterns & practices (2)
PDC08 (2)
Politics (42)
PowerPoint (2)
PowerShell (33)
Presentation (5)
Projects (1)
HawkWiki (1)
Python (4)
Quote of the Day (4)
Refactoring (1)
Research (2)
REST (18)
Reuse (5)
Robotics (2)
Rome (5)
Ruby (23)
Ruby on Rails (1)
Sci-Fi (2)
Scripting (4)
Security (3)
Service Broker (14)
SharePoint (2)
Silverlight (18)
Social Software (1)
Software + Services (2)
Software Design (1)
Software Factories (11)
Software Industry (1)
Spark (1)
SQL Server (2)
Stephen Colbert (1)
TechEd (7)
TechEd06 (1)
TechRec League (1)
Television (6)
Travel (6)
Unified Client (1)
Unit Testing (4)
UX (1)
Virtual PC (2)
Visual Basic (1)
Visual Studio (20)
Volta (2)
Washington Capitals (34)
WCF (31)
Web 2.0 (65)
Web Services (5)
WF (21)
Windows Live (23)
Xbox (1)
Xbox 360 (53)
XML (7)
XNA (14)
Disclaimer
: The information in this weblog is provided "AS IS" with no warranties, and confers no rights. This weblog does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my opinion. Inappropriate comments will be deleted at the authors discretion.
Sign In