Jeff Atwood: "I do think we'll adopt some of the cleverer functions of Textile and Markdown, insofar as they remove mundane HTML markup scutwork. But in general, I'd much rather rely on a subset of trusty old HTML than expend brain cells trying to remember the fake-HTML way to make something bold, or create a hyperlink. HTML isn't perfect, but it's an eminently reasonable humane markup language." -  Is HTML a Humane Markup Language?

Jeff Atwood: " Given its prevalence, you might decide that XML is technologically terrible, but you have to use it anyway. It sure feels like, for any given representation of data in XML, there was a better, simpler choice out there somewhere. But it wasn't pursued, because, well, XML can represent anything. Right? [...] Please think twice before subjecting yourself, your fellow programmers, and your users to the XML angle bracket tax." - XML: The Angle Bracket Tax

 

$ history|awk '{a[$2]++} END{for(i in a){printf "%5d\t%s ",a[i],i}}'|sort -rn|head
  174   git
   74   ls
   67   cd
   55   git-p4
   29   svn
   26   hg
   11   sudo
    8   mkdir
    7   p4
    4   ssh

via Aristotle

Czajnik responding to Jeff Atwood's howto on setting up Subversion on windows: "Have you tried any distributed source control? I've recently switched from Subversion to Mercurial, and I'm very happy about the change. The most important reason was the ability to clone the repository to my laptop, do some checkins there (without network access, on a plain, train, etc.) and resync with just one command when I'm back home. Distributed model seems cool even for a single developer :)"

Jeff Atwood responding to Czajnik: "What is the difference between what you describe, and working traditionally offline, then checking in when you get back into the office? If a "checkin" occurs on your local machine, and nobody else in the world knows about it.. did it really happen? Maybe I'm not understanding the distinction here. I still need to watch the rest of Linus Torvalds' presentation on this topic ( http://www.youtube.com/watch?v=4XpnKHJAok8 )"

I don't know that Torvald's presentation on Git is going to explain much (Randall Schwartz's Git tutorial is much better). I agree with Jeff when he says elsewhere it will take years to see distributed version control systems (DVCS) being generally adopted.  But having switched to a DVCS a while back (mercurial) coming from Subversion and before that CVS, let me lay out three things I think you get when you use a distributed model:

1. Better branching, thus control over code
   

2. speed, thus ease of use

3. Better IDEs (potentially)
   

But the short version is this - distributed version control is the general case.

Better branching

This one needs some justification, when you think of the costs associated with branching and the folklore around them - industry consensus is that branching is a bad thing, a neccessary evil.

A while back I said, "branching isn't just a process or code duplication matter to avoid - it's inevitable - as soon as you check out code or locked a file, you've branched - checking back in *is* a merge operation." That was in the context of using mercurial as an offline supplement to perforce.

Saying that a local sandbox is a branch operationally can mean a few things,

• update is a merge operation from another codeline,
  
• checkin is a merge operation to another codeline,
  
• you want to update and checkin frequently to avoid drifting.
  

Centralised systems like perforce, cvs, svn, do not treat checkouts as branching operations. As a result centralised systems support branching in a limited sense - that's often why branching is a bad thing. But once you accept this model of having your sandbox under version control, a lot of the pain (and fear) of dealing with branches evaporates. Passing around changesets and patches becomes normal and logical.

Centralised VCS also results in a bias towards the server as the single point of truth - your local sandbox can get messed up via conflicts, but a centralised model doesn't ever allow you to check in conflicted files. If the local merge after update fails you have to cleanup conflicts manually. This points to a limitation in centralised version control systems - the developer local history of changes is not preserved. It is as though you have a maintenance/dev branch where every time you commit to the branch, the checkin is routed to the code line where the branch was taken from. That means no branch history is kept, ever. The information is thrown away. And if your version of the file prior to the merge is never versioned, that in turn that means any post-facto work or cleanup of mistakes has to been dealt with manually. You can't go back through the history.

I have more than once seen a developer effectively stranded, where they can't checkin because they can't integrate locally without a lot of pain, and it's too late to cut a branch after the fact. Their sandbox is going to get hosed before they'll able to checkin. I've seen it enough that I'm inclined to think it's not a training/skill problem, it's a tooling problem. I also suspect it kills innovation and experimentation on codelines - when branching is that heavyweight and problematic, what's the incentive?

 

Speed

This one is easy. Once you start using a DVCS for local work, going back to a centralised model feels slow, as in your mind wanders and breaks flow, which is the worst kind of slow. Sometimes if something can be made much faster, it becomes a matter of improved usability rather than technology  - think broadband compared to dialup, or being able to run your unit tests in 20 seconds. If the basic versioning operations all become sub-second, this has the potential to impact your workflow for the better. The speed point takes some wind out of Perforce, which is the speed king as far as centralised models go (although it results in an ugly tradeoff with you having to tell the server what files you're working on).

Better IDEs (potentially)

Jeff also has a comment on using the IDE to do versioning: "This is sort of a religious issue. Some developers believe source control should *never* be done inside the IDE, and I've started to see their point after dealing with the many, many bugs in the Team Explorer Visual Studio integration point of Team System."

Long bet: all IDE-local versioning tooling will come to use a DVCS internally, probably one that supports renaming operations (for refactoring support). Using a real VCS instead of a private library is likely to be a good thing, as it opens up the toolchain, , in much the same way that all Java IDEs eventually supporting Ant/Maven directly did.

Eric Garrido on feed formats: "Here’s the bottom line: Stop advertising the older formats. It’s fine to continue to serve up the others, just don’t actively advertise it. No one cares what formats you advertise, or the format they click on, as long as they get the content they want."

I said something similar @Blogtalk 2008 during the microformats and mashups panel discussion - beforehand there was a presentation by Anna Rogozinska on a dieting website. The site was entirely focused on dieting - except for one thing - the pages advertised 3 or so different feed formats. It was like seeing a tear in the Matrix.

 

For people like me who are building systems and defining specifications, which one to use is important. But for the end user, it's just data; the details of the particular format aren't that interesting.

 

Charles Oliver-Nutter: "The dream, as I see it, would be to use a Ruby-like syntax to wire up any arbitrary types using what looks generally like idiomatic Ruby code. For example, our friend fib(). The same fib() method I showed before, executing against primitive integer values, could execute against boxed Integer objects or BigInteger objects just by specifying the right plugin. So if within the context of a file, I declare that "fixnum" types are to be represented as BigInteger objects, and math operations against them are to call appropriate methods on BigInteger, so be it...that's what comes out the other side."

Now this is interesting - an algorithm that can be generalised by using pluggable type resolution. It reminds me of something Alex Stepanov said in the "Money Oriented Programming" interview: "Every time I would look at an algorithm I would try to find a structure on which it is defined. So what I wanted to do was to describe algorithms generically." In that interview Stepanov defined generic programming as "finding the most abstract representations of efficient algorithms."

This type wiring does makes wonder (again) what would happen if Python had optional type declarations for function arguments. Aside from being able to look at a function and know what it accepts, it could give a type checker (and ultimately a JIT) a lot of information. Cobra allows you to say that an argument acts "as" a type.  Scala makes you declare types in functions. It's an interesting tradeoff.

From the announcement:

"JRuby 1.1 is the second major release for our project. The main goal for 1.1 has been improving performance. We have made great strides in performance during the last nine months. There have been more and more reports of applications exceeding Ruby 1.8.6 performance; we are even beating Ruby 1.9 in some microbenchmarks. Please try your applications against JRuby 1.1 and give us feedback. If you find poor performance or a compatibility problem, then we want to know about it; message us on IRC, email our mailing list, or file a bug."

Robert Fischer has a bad day with REXML: "In this language core library, both versions are broke! The solution is for me to reach in and make a change to the core library so that we avoid a null. In the standard Ruby deployment, using the standard core XML processing library, there is no way to write out XML. It is impossible because of bugs in the library.

The worst part?

THAT STUPID BUG IN THEIR CORE LIBRARY WOULD HAVE BEEN FIXED WITH STATIC TYPING. Even more if you have a type system which can check nulls for you."

I think it would be unfair to paint Ruby with REXML's brush. Even if static typing would fix some problems, I can't imagine Rails built on a language with a static type system. As we'll see in a minute you can write a good XML library without static typing. According to DHH "I think Rails feels, smells, and tastes like it does exactly because its very Ruby-like". Now the dilemma:

"I’ve cut Ruby on Rails a lot of slack, because the bugs and the awkwardness are the price that you pay to hang out with the beer-swilling hipsters that make out that community and roll with the rapid rate of development. And, really, it is the best web framework I’ve dealt with, mainly because it provides the most comprehensive and extensible set of functionality of any framework, and it’s got a solid community to back it up."

Fwiw, this is the reason I default to Django - similar to  Robert's experience with Rails, I find it provides a comprehensive and extensible set of functionality, and it’s got a solid community to back it up. Plus it's fun. Django is written in Python and Python's libraries tend to be well baked. In particular there are ones outside distro that rock. If there's a better XML lib than Elementtree, I don't know what it is. If there's a better httplib than httplib2, I don't know what it is. PIL. Feedparser. BeautifulSoup. Numeric. And so on. I guess I'm lucky in my choices.

It can take a few attempts to get the design of libraries right - going back to XML for a second, look at how long it took to get to XOM and XStream in Java (neither of which are in the JDK). Embedding libraries with immature designs, usually due to reaction to industry trends, has been a problem for the JDK. Once a lib ships in that core it's very hard to root it out. But when you look at search and megadata problems, no community has anything comparable to mg4j/lucene/hadoop. I remember a time when Python's XML support was up in the air and Unicode was "up the BOM". Python still has problems with installation, whereas Ruby has gems. 

That said, library problems are transient problems. They can be fixed.

Ian Bicking: "Here’s a general rule I have: I don’t accept anything made by people who hate the web. If you hate the web and you want to improve the web, I don’t want anything to do with you. If you think the web is some kind of implementation detail then I probably don’t care what you are doing. If you still think the web is a fad, then you are just nuts; if all you can think of is reasons why the web is stupid and awkward, and you think it’s some giant step backward (from what?), then you haven’t thought very deeply about what’s happened in the world of technology and why."

Ian's talking about Air and Silverlight. Harsh? Maybe. My complaint is that desktop platforms aren't stable compared to web ones. By the time you're done  *deciding* what platform to use, the choice is already legacy. How long will those two be around before something else shiny comes along - two/three years?

Spolsky: "I was shocked to discover that our customers with Windows Server 2003 were having trouble running FogBugz. Then .NET 1.1 was not perfectly backwards compatible with 1.0. And now that the cat was out of the bag, the OS team got into the spirit and decided that instead of adding features to the Windows API, they were going to completely replace it. Instead of Win32, we are told, we should now start getting ready for WinFX: the next generation Windows API. All different. Based on .NET with managed code. XAML. Avalon. Yes, vastly superior to Win32, I admit it. But not an upgrade: a break with the past. Outside developers, who were never particularly happy with the complexity of Windows development, have defected from the Microsoft platform en-masse and are now developing for the web."

To me, desktop app coding has always seemed like a rat race - which is why I generally don't do it (along with a host of other reasons). 

On the other hand, Mozilla Prism looks cool. I always felt what held Mozilla/XUL back as a client side application platform compared to stuff like XAML is that it doesn't have an IDE. If I had to condense every complaint I've heard about Mozilla/XUL into a sentence it would be this - I had to do all it by hand.

 

Brandon Lucas: "Mobile is the next generation of social networking" (via Emily Turrettini)

I would tend to think so too.

 

 

Brandon Craig Rhodes: "Ruby people do this. Monkey patching: F".

In fairness to Ruby people, Zope and Python people have been monkey patching for years (that's where the term comes from). I only know this because I've been in the 8th ring of Zope2/Plone hell, which is where all the monkey patchers go, and they are legion (the 9th circle is reserved for those who hack zcatalogs - a story about that some other day).  Object Adapters get a B from Brandon because he says the wrapping is annoying - and he's right, it is annoying, even though it's my reflex pattern for binding domain objects into Atom/AtomPub. Gone wrong you end up with parallel hierarchies and implicit mappings and a lot of noise - Brandon has a picture in his presentation that captures that perfectly.

Personally, I've always felt that Zope2 is a possible anti-future for Rails. And I suspect there is a cultural difference in emphasis between Python and Ruby insofar as the Python community tends to frown on monkey patching, even though it's their "fault":

Ian Bicking: "It's the second generation that's going to be less enthused, that's going to stare in bafflement at these classes that mysteriously spawn methods, and trying to figure out what's going when there's an exception in dynamically generated code. You can monkeypatch code in Python pretty easily, but we look down on it enough that we call it "monkeypatching". In Ruby they call it "opening a class" and think it's a cool feature. I will assert: we are right, they are wrong."

Chad Fowler: "But this 'monkey patching' thing is seriously powerful and, as an end-usre [sic] in this case, I can say that it makes things better for the users of Ruby."

Suggestion: if you're a Rails fan, take at look at Brandon's presentation: http://rhodesmill.org/brandon/static/2008/grok-walk-duck.pdf It gives a quick overview of Zope3's Component Architecture (ZCA) It's easy to be dismissive, but therein Zope3 captures a decade's worth of lessons learned from trying to deal with large monkey patched codebases written in a dynamically typed language. It's hard to figure out the real size of a Zope2 install because it's component/product based, but ohloh.net has it at 500Kloc - Rails according to ohloh.net is passing 100Kloc. Am I saying monkey patching doesn't scale with line count? Sort of.

If there's a downside to the Zope3 approach, it's that ZCF gives you a shadow object model alongside Python inheritence, and that can be confusing. ZCML is also noisy, but Grok seems destined to make that go away - vaguely similar to Spring XML wiring versus Guice's in-code approach.

As for all this debate about platforms - that's what markets are for. Platforms are market makers. Standards are different - they're forcing functions for markets. not market makers. Let's look at some HTML5 spec text for forms instead.

From the draft on extended form controls:

"The HTTP specification defines various methods that can be used with HTTP URIs. Four of these may be used as values of the method attribute: get, post, put, and delete. In this specification, these method names are applied to other protocols as well. This section defines how they should be interpreted."

The enormity of the consequences of HTML only allowing GET and POST cannot be overstated IMO.  It's maybe the most damaging technical decision in the web standards space - ever.  I see HTML forms as a root cause for the WS-* "everything goes over POST" debacle, a billion dollar industry mistake, at best.

What it gets wrong:

"If the specified method is not one of get, post, put, or delete then it is treated as get in the tables below."

Fail, on two counts. First a markup format that has impliciit defaults, ie, acquires values through the absence of specific markup tends to suck - example, I spent a few hours this week trying to figure out whether OpenSearch is compatible with RFC5005 - I'm not 100% sure but I suspect not - and it's because of impliciit markup. Specs in markup of the form "when the X is not present, assume a Y with value Z" are an antipattern. I have no idea how much time  I've spent dealing with ill-advised attempts at acquisition semantics in XML, (aka "default values"), or in the Atom case, trying to argue them out over the years. But I think, a lot.  Second, just allow the uniform interface and move on. Subsetting a uniform interface is - silly. I remember the Atompub WG seriously consider not using PUT and DELETE because lots of deployed infrastructure didn't support them. As of 2008, I still have to recommend X-HTTTP-MethodOverride as an option for protocols. Forms are not a special case of the Web's interface, imvho. Yes, I'm saying OPTIONS and MKCOL are valid values for the method attribute.

What would be nice - some text on server side validation. What happenss today is that  servers often send back 200 Ok with validation errors. Server side validation is so common, I'd expect the 200 "Ok, but invalid" issue could get a mention. But maybe I missed it. Anyway, since the request was not ok, the 422 (Unprocessable Entity) would be a viable option for a failed validation.

 

update: 2008/04/08: added an all microformats option based on a suggestion from Assaf Arkin.

So Google published a Contacts API based on Gdata (in turn based Atom and Atompub). This particular Application Protocol Interface allows client applications to view and update user contact details and most Google services have access to the contact list.

Here's an example of a  Google contact entry:

<atom:entry xmlns:atom='http://www.w3.org/2005/Atom'
    xmlns:gd='http://schemas.google.com/g/2005'>
    <id>
         http://www.google.com/m8/feeds/contacts/liz%40gmail.com/base/c9012de
    </id>  
    <updated>2008-03-05T12:36:38.835Z</updated>
    <link rel='self' type='application/atom+xml'
      href='http://www.google.com/m8/feeds/contacts/liz%40gmail.com/base/c9012de' />
    <link rel='edit' type='application/atom+xml'
      href='http://www.google.com/m8/feeds/contacts/liz%40gmail.com/base/c9012de/1204720598835000' />      
  <atom:category scheme='http://schemas.google.com/g/2005#kind'
    term='http://schemas.google.com/contact/2008#contact' />
  <atom:title type='text'>Elizabeth Bennet</atom:title>
  <atom:content type='text'>Notes</atom:content>
  <gd:email rel='http://schemas.google.com/g/2005#work'
    address='liz@gmail.com' />
  <gd:email rel='http://schemas.google.com/g/2005#home'
    address='liz@example.org' />
  <gd:phoneNumber rel='http://schemas.google.com/g/2005#work'
    primary='true'>
    (206)555-1212
  </gd:phoneNumber>
  <gd:phoneNumber rel='http://schemas.google.com/g/2005#home'>
    (206)555-1213
  </gd:phoneNumber>
  <gd:im address='liz@gmail.com'
    protocol='http://schemas.google.com/g/2005#GOOGLE_TALK'
    rel='http://schemas.google.com/g/2005#home' />
  <gd:postalAddress rel='http://schemas.google.com/g/2005#work'
    primary='true'>
    1600 Amphitheatre Pkwy Mountain View
  </gd:postalAddress>
</atom:entry>


Grand. Lots of extension XML. You talk GData you're set. However aside from pulling this data around into address books, a really common case is just showing the user the info.

In that vein, here's the same data, using the hCard microformat embedded in the atom:content element instead of GData extensions:

<atom:entry xmlns:atom='http://www.w3.org/2005/Atom'
    xmlns:gd='http://schemas.google.com/g/2005'>
    <id>
     http://www.google.com/m8/feeds/contacts/liz%40gmail.com/base/c9012de
    </id>   
    <updated>2008-03-05T12:36:38.835Z</updated>
    <link rel='self' type='application/atom+xml'
        href='http://www.google.com/m8/feeds/contacts/liz%40gmail.com/base/c9012de' />
    <link rel='edit' type='application/atom+xml'
        href='http://www.google.com/m8/feeds/contacts/liz%40gmail.com/base/c9012de/1204720598835000' />       
    <atom:category scheme='http://schemas.google.com/g/2005#kind'
        term='http://schemas.google.com/contact/2008#contact' />
    <atom:title type='text'>Elizabeth Bennet</atom:title>
    <atom:content type='xhtml'>
      <div xmlns="http://www.w3.org/1999/xhtml">   
        <div class="vcard">
          <a class="fn url"
            href="http://www.google.com/m8/feeds/contacts/liz%40gmail.com/base/c9012de">
            Elizabeth Bennet
          </a>
          <div class="adr">
            <span class="type">Work</span>:
            <div class="street-address">1600 Amphitheatre Pkwy Mountain View</div>
          </div>
          <div class="tel">
           <span class="type">home</span>(206)555-1213
          </div>
          <div class="tel">
            <span class="type">work</span> (206)555-1213
          </div>
          <div>Home Email:
           <span class="email">liz@example.org</span>
          </div>
          <div>Work Email:
           <span class="email">liz@gmail.com</span>
          </div>
          <div>Gtalk:
          <a class="url" href="xmpp:liz@gmail.com">liz@gmail.com</a>
        </div>
        </div>
      </div>   
    </atom:content>   
</atom:entry>

It seems to me like Google could support a uF format option as a parameter flag.

There's more.

Windows Live

Here's a sample of the Windows Live Contacts API:

<?xml version="1.0" encoding="utf-8" ?> 
<Contact>
 <Comment>This is updated primary ABCH test account</Comment> 
 <Profiles>
  <Personal>
   <NameToFileAs>Updated ABCH Int</NameToFileAs> 
   <NameTitle>UpdatedMr.</NameTitle> 
   <FirstName>UpdatedAbch</FirstName> 
   <MiddleName>UpdatedPg</MiddleName> 
   <LastName>UpdatedInt</LastName> 
   <Suffix>UpdatedJr.</Suffix> 
   <YomiFirstName>UpdatedAibiceiachi</YomiFirstName> 
   <YomiLastName>UpdatedCeshiban</YomiLastName> 
   <Birthdate>1987-02-26</Birthdate> 
   <Anniversary>May 8th</Anniversary> 
   <Gender>Female</Gender> 
   <TimeZone>GmtMinus6h</TimeZone> 
   <SpouseName>UpdatedStorage</SpouseName> 
  </Personal>
  <Professional>
   <JobTitle>UpdatedSDE</JobTitle> 
   <Profession>Updatedaddress books</Profession> 
   <Manager>UpdatedWindowsLive</Manager> 
   <Assistant>UpdatedSomeone</Assistant> 
  </Professional>
 </Profiles>
</Contact>

Which is a format more focused on the address domain - for starters it does not use Atom as a scaffold. I'm not going to try to convert that into hCard, but do note the "CamelCase" style markup; that's generally done to ease roundtripping in and out of OO languages (if you're a Java dev and have used XStream you'll have seen this in action).

xAL

Moving further along the domain specific line, here's an example of xAL, the eXtensible Address Language from OASIS.

<!-- 201/2288 Pine Street
Vancouver, BC
V6J 5G4
Canada -->
<AddressDetails>
<Country>
<CountryName>Canada</CountryName>
<Locality Type="State">
<LocalityName NameType="Abbreviation">BC</LocalityName>
<LocalityName NameType="Full Name">BRITISH COLUMBIA</LocalityName>
<DependentLocality Type="City">
<DependentLocalityName>Vancouver</DependentLocalityName>
<Thoroughfare Type="Street">
<ThoroughfareName>Pine Street</ThoroughfareName>
<Premise Type="Apartment Building">
<PremiseNumber>2288</PremiseNumber>
<SubPremise Type="Unit">
<SubPremiseNumber>201</SubPremiseNumber>
</SubPremise>
</Premise>
</Thoroughfare>
</DependentLocality>
<PostalCode>
<PostalCodeNumber>V6J 5G4</PostalCodeNumber>
</PostalCode>
</Locality>
</Country>
</AddressDetails>

Again more CamelCase markup, but the thing to note here is that the elements are not always carying the key information. There are Type attrributes that have the information your really want, such as "Type='Street'". xAL is in a sense a 'domain specific schema language'. It also has overly specific and/or localised elements like "ThoroughfareTrailingType". There's a lot to the xAL spec; what you see there is but a fragment. Incidently, the Irish government have a profile of it for eGovernment interchange.

Microformats all the way down

update: 2008/04/08. Assaf asked in a comment: "Why not go microformats all the way?" . It's an interesting idea. So here we go, using hAtom instead of Atom markup:

<div class="hentry entry" id="http://www.google.com/m8/feeds/contacts/liz%40gmail.com/base/c9012de">
    <div class="updated">2008-03-05T12:36:38.835Z</div>
    <ul class="links">
        <li>
            <a href="http://www.google.com/m8/feeds/contacts/liz%40gmail.com/base/c9012de"
                title="self" rel="tag self">Permalink</a>
            <a href="http://www.google.com/m8/feeds/contacts/liz%40gmail.com/base/c9012de/1204720598835000"
                title="Edit" rel="tag">Edit</a>   
        </li>
    </ul>       
    <ul class="categories">
        <li>
            <a href="http://schemas.google.com/g/2005#kind" title="Contact" rel="tag">http://schemas.google.com/contact/2008#contact</a>
        </li>
    </ul>       
    <h3 class="entry-title">Elizabeth Bennet</h3>
    <div class="entry-content">  
        <div class="vcard">
          <a class="fn url"
            href="http://www.google.com/m8/feeds/contacts/liz%40gmail.com/base/c9012de">
            Elizabeth Bennet
          </a>
          <div class="adr">
            <span class="type">Work</span>:
            <div class="street-address">1600 Amphitheatre Pkwy Mountain View</div>
          </div>
          <div class="tel">
           <span class="type">home</span>(206)555-1213
          </div>
          <div class="tel">
            <span class="type">work</span> (206)555-1213
          </div>
          <div>Home Email:
           <span class="email">liz@example.org</span>
          </div>
          <div>Work Email:
           <span class="email">liz@gmail.com</span>
          </div>
          <div>Gtalk:
          <a class="url" href="xmpp:liz@gmail.com">liz@gmail.com</a>
        </div>
        </div>
      </div>  
    </div>  
</div>

Looking at it, I'm not convinced. Things like links and categories don't seem to map on well. We've also lost the ability to hook into the syndication tool chain-  socially, architecturally, or whatever way you want to put it, that's a big loss. [I think if XHTML could support a web of syndication, we'd already be using it for that.] Personally speaking, I find hAtom one of the harder microformats to understand, certainly compared to hCard. So to me Atom carrying a microformat is still the right tradeoff.

CardDAV

CardDAV as found in draft-daboo-carddav-04.txt. Allow me to echo Mark Nottingham's sentiments and skip the example - I don't get it. Granted, it's based on vCard as hCard is (and the others are not). But still, I can't see CardDAV getting traction.

 

Conclusion: Microformats and Atom FTW!

Microformats rock for the web - as well as being machine readable they can be lopped into a browser and are instantly 'people readable'. hCard+Atom at least seems to hit a sweet spot between machine usefulness, content distribution, and ease of reading for people; I won't go as far as saying it's more generally useful than the other options I've shown (but I'm tempted). This is not meant as a slight on the people working on the other formats above; address modelling is a deceptively hard problem - read the xAL spec (or even vCard) if you don't believe me.

Eric Lippert: "I understand that there is an inherent and pervasive bias in pure-text communication which makes statements intended to be good-humoured sound sophomoric, makes statements which were intended to be friendly sound smarmy, makes statements which were intended to be enthusiastic sound brash, makes statements intended to be helpful sound condescending, makes statements which were intended to be precise and accurate sound brusque and pedantic, makes statements which were intended to be positive sound neutral, and makes statements which were intended to be neutral seem downright hostile."

Steve Loughran: "If you read the thread, a lot of people are upset. What's going on? they demand; fix it! they say. I sympathise with their point of view, but I don't agree with it. AWS can't say what's going on, not until they know. They can't fix it until after that. I've been on the receiving end of these 'fix it now' crises, and having lots of people on the phone doesn't help you find the problem any faster. So well done to the AWS team to (a) fixing it fairly quickly and (b) having so many users that the outage got such publicity!"

Lister's law: "people under time pressure don't think faster". I agree with Steve. And within Steve's point is a general anti-pattern of trying to go faster and introduce more stress when you're in the weeds.  But that's SOP. The most important thing seems to be to design a system that can be fixed in place when bad things happen. That means a lot of things that aren't normally considered part of software "design" - build management, release management, issue tracking, testing, configuration, deployment, rollbacks, logistics, cross-departmental processes, SLAs, findable documents and stacktraces. I really hope Steve writes a continuous deployment book.

EETimes: "Both AMD and Intel have said they will ship processors using a mix of X86 and graphics cores as early as next year, with core counts quickly rising to eight or more per chip. But software developers are still stuck with a mainly serial programming model that cannot easily take advantage of the new hardware.

 Thus, there's little doubt the computer industry needs a new parallel-programming model to support these multicore processors. But just what that model will be, and when and how it will arrive, are still up in the air.

 "It's a critical problem, and the technology is needed right now," said William Dally, a professor of computer science at Stanford. "The danger is we will not have a good model when we need it, and people will wind up creating a generation of difficult legacy code we will have to live with for a long time."

Dally said he would urge the industry "to start experimenting right away and try a dozen different ideas to find a few that work." Even then, he said, "the best ideas that emerge from that work won't be perfect in their first implementations."

 "The industry is in a little bit of a panic about how to program multicore processors, especially heterogeneous ones," said Chuck Moore, a senior fellow at AMD now serving as chief architect of the company's so-called accelerated computing initiative. "To make effective use of multicore hardware today, you need a PhD in computer science. That can't continue if we want to enable heterogeneous CPUs."

I don't know. I just don't get the whole multicore stressout. The big problem in computing seems to be managing data.  Lots of data. Zettabytes, like.