Clever ideas that failed(sites.google.com)
sites.google.com
Clever ideas that failed
http://sites.google.com/site/yacoset/Home/clever-ideas-that-failed
11 comments
A refreshing change to the general level of hubris today. Thanks.
If you haven't already, check out this guy's growing treasure trove of writing:
http://sites.google.com/site/yacoset/
Many of his articles have been posted on HN and elsewhere already.
http://sites.google.com/site/yacoset/
Many of his articles have been posted on HN and elsewhere already.
A gem from that site:
<Shipments>
<LineItem LineNumber="1" SKU="123456">
<Order Number="555444">
<Package ShipMethod="UPS" Tracking="1Z123467WW53631"/>
</Order>
</LineItem>
<LineItem LineNumber="2" SKU="654321">
<Order Number="555444">
<Package ShipMethod="UPS" Tracking="1Z123467WW53631"/>
</Order>
</LineItem>
</Shipments>
The designer of this schema was on crack.
That entire article is a treasure chest, almost strikes me as he wrote it during a therapy session.
[deleted]
Hey what a coincidence! I dunno why he failed with the 4th one.
We maintain a leasing administration system here, and one of the most important/critical features is doing the thing he describes. You can know the exact state of any leasing contract (or a group, or all of them) by chosing a date of the future and past. That way you can compare the expected result vs reality. It is implemented fully inside a SQL DBMS (and works fine)....
We maintain a leasing administration system here, and one of the most important/critical features is doing the thing he describes. You can know the exact state of any leasing contract (or a group, or all of them) by chosing a date of the future and past. That way you can compare the expected result vs reality. It is implemented fully inside a SQL DBMS (and works fine)....
Yeah, that bit made me cringe a bit too, since you have to do the something similar for storing insurance policies (track when things become effective, including forward-dated changes, storing past versions, etc.). No predictions necessary in our case. I'm guessing dealing with the time dimension is a general property of any system that needs to store anything that qualifies as a legal contract.
It is true, however, that adding in that time dimension makes everything a much, much harder problem.
It is true, however, that adding in that time dimension makes everything a much, much harder problem.
Good lessons, except for 1, without doing that there'd be no Google map-reduce and Hadoop. Of course, this means you should be using Hadoop now.
I got to the end of the entry and felt inclined to click "Report abuse" at the bottom of the page. =D
Loved it. Looking back, I have sinned as well.
Loved it. Looking back, I have sinned as well.
Great article. It's a pity that over-engineering is often the path to failure, because over-engineering is so terrifically fun to do!
@clarencewenham, you should have a nice blog and move your content there. Doesn't matter whether you update it frequently or not.
I dislike the blog format, I've tried it several times and it doesn't work for me. I found that I prefer the Wiki style where you focus on a TOC. Hopefully Google will figure out how to implement RSS for GSites one day.
Makes me think of that quote from Spinal Tap. You know, that there's a fine line...
Is there a way to access this without having to login to google docs?
an interesting article in similar vain: niklaus wirth's "good ideas, through the looking glass".
This has inspired me to begin looking back at my projects and compiling a similar list of things that I have learned by doing it wrong.