<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article10_02_04_1538251</id>
	<title>The Art of Scalability</title>
	<author>samzenpus</author>
	<datestamp>1265307360000</datestamp>
	<htmltext><a href="http://www.martijndeboer.eu/" rel="nofollow">Martijn de Boer</a> writes <i>"Creating high performance growing networks is really a special skill managers and network architects should possess to be ready for the future. The Art of Scalability is a book written for these kinds of functions, and prepares you for the present and the imminent future. Scalability is achieved by principles that work on many levels within enterprises, whether it's processes, organizational structure or setting up your project, this book covers it all."</i> Read on for the rest of Martijn's review.</htmltext>
<tokenext>Martijn de Boer writes " Creating high performance growing networks is really a special skill managers and network architects should possess to be ready for the future .
The Art of Scalability is a book written for these kinds of functions , and prepares you for the present and the imminent future .
Scalability is achieved by principles that work on many levels within enterprises , whether it 's processes , organizational structure or setting up your project , this book covers it all .
" Read on for the rest of Martijn 's review .</tokentext>
<sentencetext>Martijn de Boer writes "Creating high performance growing networks is really a special skill managers and network architects should possess to be ready for the future.
The Art of Scalability is a book written for these kinds of functions, and prepares you for the present and the imminent future.
Scalability is achieved by principles that work on many levels within enterprises, whether it's processes, organizational structure or setting up your project, this book covers it all.
" Read on for the rest of Martijn's review.</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31027060</id>
	<title>Re:Very Marketable</title>
	<author>damn\_registrars</author>
	<datestamp>1265278320000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p><div class="quote"><p>As computational resources on the market continue to expand, I would suspect that we could soon come to see the opposite of scalability becoming more important - getting more done with less space and energy.</p> </div><p>If you think the solution to scaling issues is to 'throw more silicone' at the problem,</p></div><p>
I have no idea how you could have possibly derived that from what I said.  Indeed I was saying the opposite of that - I was questioning whether scaling itself is relevant.</p><p><div class="quote"><p>you are about the worse programmer in the universe</p></div><p>
I am not a programmer by profession, nor do I play one on TV.</p></div>
	</htmltext>
<tokenext>As computational resources on the market continue to expand , I would suspect that we could soon come to see the opposite of scalability becoming more important - getting more done with less space and energy .
If you think the solution to scaling issues is to 'throw more silicone ' at the problem , I have no idea how you could have possibly derived that from what I said .
Indeed I was saying the opposite of that - I was questioning whether scaling itself is relevant.you are about the worse programmer in the universe I am not a programmer by profession , nor do I play one on TV .</tokentext>
<sentencetext>As computational resources on the market continue to expand, I would suspect that we could soon come to see the opposite of scalability becoming more important - getting more done with less space and energy.
If you think the solution to scaling issues is to 'throw more silicone' at the problem,
I have no idea how you could have possibly derived that from what I said.
Indeed I was saying the opposite of that - I was questioning whether scaling itself is relevant.you are about the worse programmer in the universe
I am not a programmer by profession, nor do I play one on TV.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31025516</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31027484</id>
	<title>Re:First two sections</title>
	<author>nullchar</author>
	<datestamp>1265280360000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>First two sections are not going to happen in large organizations.</p></div><p>What you say is sad but true in my experience at the companies I have worked for.</p><p>The first two sections are essentially: (1) the business strategy for your particular product, and knowing your human resources (team); (2)<nobr> <wbr></nobr>/really/ thinking about the future, not just how you will sell it; why you would need to scale.</p><p>The following question is somewhat on topic as this book appears to be targeted to decision makers at the company, which usually means high-level product/project managers and "directors" or "VPs" of technology/software engineering.</p><p><b>Question:</b> Why do company decision makers not rely on pooling the collective input of their subordinates or teams, and instead make rapid and unfaltering business and technical decisions that are not forward-thinking?</p><p>Perhaps they are marking wise decisions for the company, so they can make money in the short term and grow the business, which allows them to fund new projects and so on. But I read on Slashdot all too often where management's short-sightedness to choose one specific technology, seemingly without consent of other knowledgeable employees (yet lower on the decision chain), cause headaches for the actual implementors down the chain.</p><p>Say these decision makers dictate no application caching and choose a commercial database offering for vertical performance scaling, instead of adding caching and partitioning data on free databases for horizontal scaling.  Yet if they would have asked the collective software engineers and low-level management for input, the decision would have been reversed.  Will a book like this even help those types of high-level decision makers, say VPs of Tech: brought in from outside the company to grow the business away from the previous [multiple] VPs' mistakes?</p></div>
	</htmltext>
<tokenext>First two sections are not going to happen in large organizations.What you say is sad but true in my experience at the companies I have worked for.The first two sections are essentially : ( 1 ) the business strategy for your particular product , and knowing your human resources ( team ) ; ( 2 ) /really/ thinking about the future , not just how you will sell it ; why you would need to scale.The following question is somewhat on topic as this book appears to be targeted to decision makers at the company , which usually means high-level product/project managers and " directors " or " VPs " of technology/software engineering.Question : Why do company decision makers not rely on pooling the collective input of their subordinates or teams , and instead make rapid and unfaltering business and technical decisions that are not forward-thinking ? Perhaps they are marking wise decisions for the company , so they can make money in the short term and grow the business , which allows them to fund new projects and so on .
But I read on Slashdot all too often where management 's short-sightedness to choose one specific technology , seemingly without consent of other knowledgeable employees ( yet lower on the decision chain ) , cause headaches for the actual implementors down the chain.Say these decision makers dictate no application caching and choose a commercial database offering for vertical performance scaling , instead of adding caching and partitioning data on free databases for horizontal scaling .
Yet if they would have asked the collective software engineers and low-level management for input , the decision would have been reversed .
Will a book like this even help those types of high-level decision makers , say VPs of Tech : brought in from outside the company to grow the business away from the previous [ multiple ] VPs ' mistakes ?</tokentext>
<sentencetext>First two sections are not going to happen in large organizations.What you say is sad but true in my experience at the companies I have worked for.The first two sections are essentially: (1) the business strategy for your particular product, and knowing your human resources (team); (2) /really/ thinking about the future, not just how you will sell it; why you would need to scale.The following question is somewhat on topic as this book appears to be targeted to decision makers at the company, which usually means high-level product/project managers and "directors" or "VPs" of technology/software engineering.Question: Why do company decision makers not rely on pooling the collective input of their subordinates or teams, and instead make rapid and unfaltering business and technical decisions that are not forward-thinking?Perhaps they are marking wise decisions for the company, so they can make money in the short term and grow the business, which allows them to fund new projects and so on.
But I read on Slashdot all too often where management's short-sightedness to choose one specific technology, seemingly without consent of other knowledgeable employees (yet lower on the decision chain), cause headaches for the actual implementors down the chain.Say these decision makers dictate no application caching and choose a commercial database offering for vertical performance scaling, instead of adding caching and partitioning data on free databases for horizontal scaling.
Yet if they would have asked the collective software engineers and low-level management for input, the decision would have been reversed.
Will a book like this even help those types of high-level decision makers, say VPs of Tech: brought in from outside the company to grow the business away from the previous [multiple] VPs' mistakes?
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31025124</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31025516</id>
	<title>Very Marketable</title>
	<author>Anonymous</author>
	<datestamp>1265314260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><i>As computational resources on the market continue to expand, I would suspect that we could soon come to see the opposite of scalability becoming more important - getting more done with less space and energy.</i>
<br> <br>
If you think the solution to scaling issues is to 'throw more silicone' at the problem, you are about the worse programmer in the universe. This talent is incredibly handy, as any site shut down by Slashdot's ravening hordes would attest. What you are suggesting is akin to 'Bubble sorts are a great algorithm if you do them an a fast CPU'. Any tech company that hopes to achieve more than a small audience will need people with this skill set.
<br> <br>
With databases hitting petabyte sizes, and a world wide Internet audience in the hundreds of millions and growing, I very much doubt that scaling issues will be resolved by simple hardware solutions anytime in the foreseeable future.</htmltext>
<tokenext>As computational resources on the market continue to expand , I would suspect that we could soon come to see the opposite of scalability becoming more important - getting more done with less space and energy .
If you think the solution to scaling issues is to 'throw more silicone ' at the problem , you are about the worse programmer in the universe .
This talent is incredibly handy , as any site shut down by Slashdot 's ravening hordes would attest .
What you are suggesting is akin to 'Bubble sorts are a great algorithm if you do them an a fast CPU' .
Any tech company that hopes to achieve more than a small audience will need people with this skill set .
With databases hitting petabyte sizes , and a world wide Internet audience in the hundreds of millions and growing , I very much doubt that scaling issues will be resolved by simple hardware solutions anytime in the foreseeable future .</tokentext>
<sentencetext>As computational resources on the market continue to expand, I would suspect that we could soon come to see the opposite of scalability becoming more important - getting more done with less space and energy.
If you think the solution to scaling issues is to 'throw more silicone' at the problem, you are about the worse programmer in the universe.
This talent is incredibly handy, as any site shut down by Slashdot's ravening hordes would attest.
What you are suggesting is akin to 'Bubble sorts are a great algorithm if you do them an a fast CPU'.
Any tech company that hopes to achieve more than a small audience will need people with this skill set.
With databases hitting petabyte sizes, and a world wide Internet audience in the hundreds of millions and growing, I very much doubt that scaling issues will be resolved by simple hardware solutions anytime in the foreseeable future.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31024974</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31025206</id>
	<title>Eerie</title>
	<author>fulldecent</author>
	<datestamp>1265312520000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>1</modscore>
	<htmltext><p>This reminds me of the original Zelda where you go in the cave and pay money...</p><p>Gates: Give us all your personal information and we will use this to make recommendations for you<br>User:<nobr> <wbr></nobr>/me gives<br>Gates: We recommend that you be less gullible</p></htmltext>
<tokenext>This reminds me of the original Zelda where you go in the cave and pay money...Gates : Give us all your personal information and we will use this to make recommendations for youUser : /me givesGates : We recommend that you be less gullible</tokentext>
<sentencetext>This reminds me of the original Zelda where you go in the cave and pay money...Gates: Give us all your personal information and we will use this to make recommendations for youUser: /me givesGates: We recommend that you be less gullible</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31026370</id>
	<title>Martijn</title>
	<author>dingen</author>
	<datestamp>1265275440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Now there's a cool name.</htmltext>
<tokenext>Now there 's a cool name .</tokentext>
<sentencetext>Now there's a cool name.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31026042</id>
	<title>You fail 17</title>
	<author>Anonymous</author>
	<datestamp>1265274120000</datestamp>
	<modclass>Troll</modclass>
	<modscore>-1</modscore>
	<htmltext><A HREF="http://goat.cx/" title="goat.cx" rel="nofollow">The project 7o and Michael Smith that comprise Would you like to</a> [goat.cx]</htmltext>
<tokenext>The project 7o and Michael Smith that comprise Would you like to [ goat.cx ]</tokentext>
<sentencetext>The project 7o and Michael Smith that comprise Would you like to [goat.cx]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31027908</id>
	<title>"This book is much more than you may think it is"</title>
	<author>weston</author>
	<datestamp>1265282640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>"This book is much more than you may think it is. Scale is not just about designing Web sites that don't crash when lots of users show up. It is about designing your company so that it doesn't crash when your business needs to grow. These guys have been there on the front lines of some of the most successful Internet companies of our time, and they share the good, the bad, and the ugly about how to not just survive, but thrive." -- Marty Cagan, Founder, Silicon Valley Product Group</p><p>From the somehow omitted <a href="http://theartofscalability.com/" title="theartofscalability.com">site for the book</a> [theartofscalability.com].</p><p>(Also... is there some kind of Martin conspiracy going on here? The author is named Martin, the reviewer is named Martijn, the guy I just quoted is presumably a Martin...)</p></htmltext>
<tokenext>" This book is much more than you may think it is .
Scale is not just about designing Web sites that do n't crash when lots of users show up .
It is about designing your company so that it does n't crash when your business needs to grow .
These guys have been there on the front lines of some of the most successful Internet companies of our time , and they share the good , the bad , and the ugly about how to not just survive , but thrive .
" -- Marty Cagan , Founder , Silicon Valley Product GroupFrom the somehow omitted site for the book [ theartofscalability.com ] . ( Also.. .
is there some kind of Martin conspiracy going on here ?
The author is named Martin , the reviewer is named Martijn , the guy I just quoted is presumably a Martin... )</tokentext>
<sentencetext>"This book is much more than you may think it is.
Scale is not just about designing Web sites that don't crash when lots of users show up.
It is about designing your company so that it doesn't crash when your business needs to grow.
These guys have been there on the front lines of some of the most successful Internet companies of our time, and they share the good, the bad, and the ugly about how to not just survive, but thrive.
" -- Marty Cagan, Founder, Silicon Valley Product GroupFrom the somehow omitted site for the book [theartofscalability.com].(Also...
is there some kind of Martin conspiracy going on here?
The author is named Martin, the reviewer is named Martijn, the guy I just quoted is presumably a Martin...)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31026450</id>
	<title>Re:Very Marketable</title>
	<author>psycho\_eddy</author>
	<datestamp>1265275740000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>If you think the solution to scaling issues is to <strong>'throw more silicone' at the problem</strong>, you are about the worse programmer in the universe.</p></div><p>throwing more silicone at the problem has helped many an aspiring playmate. i know this is unintentional, but i got a chuckle out it<nobr> <wbr></nobr>:-) emphasis mine.</p></div>
	</htmltext>
<tokenext>If you think the solution to scaling issues is to 'throw more silicone ' at the problem , you are about the worse programmer in the universe.throwing more silicone at the problem has helped many an aspiring playmate .
i know this is unintentional , but i got a chuckle out it : - ) emphasis mine .</tokentext>
<sentencetext>If you think the solution to scaling issues is to 'throw more silicone' at the problem, you are about the worse programmer in the universe.throwing more silicone at the problem has helped many an aspiring playmate.
i know this is unintentional, but i got a chuckle out it :-) emphasis mine.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31025516</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31024938</id>
	<title>this book covers it all</title>
	<author>djupedal</author>
	<datestamp>1265311320000</datestamp>
	<modclass>Funny</modclass>
	<modscore>3</modscore>
	<htmltext>Didn't we just go thru this with the slime mold that grows perfect networks?
<br>
<br>
<a href="http://science.slashdot.org/article.pl?sid=10/01/22/1715229" title="slashdot.org">http://science.slashdot.org/article.pl?sid=10/01/22/1715229</a> [slashdot.org]
<br>
<br>
So if this is so hard for humans and they need new books to work it out, why can slime mold do it?<br>
<br> Is there a slime mold chapter in this book or is that coming in next release?</htmltext>
<tokenext>Did n't we just go thru this with the slime mold that grows perfect networks ?
http : //science.slashdot.org/article.pl ? sid = 10/01/22/1715229 [ slashdot.org ] So if this is so hard for humans and they need new books to work it out , why can slime mold do it ?
Is there a slime mold chapter in this book or is that coming in next release ?</tokentext>
<sentencetext>Didn't we just go thru this with the slime mold that grows perfect networks?
http://science.slashdot.org/article.pl?sid=10/01/22/1715229 [slashdot.org]


So if this is so hard for humans and they need new books to work it out, why can slime mold do it?
Is there a slime mold chapter in this book or is that coming in next release?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31025124</id>
	<title>First two sections</title>
	<author>Curlsman</author>
	<datestamp>1265312220000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext>are not going to happen in large organizations. <br>
Nobody ever knows everything about the strategy or organizational structure, and the people and managers change places and responsibilities faster than any project can proceed.<br>
And continuity, crisis and incident management are only longed for when the systems are down and eveybody is expected to work continuously until they're fixed, but never when it's time to pay for it.</htmltext>
<tokenext>are not going to happen in large organizations .
Nobody ever knows everything about the strategy or organizational structure , and the people and managers change places and responsibilities faster than any project can proceed .
And continuity , crisis and incident management are only longed for when the systems are down and eveybody is expected to work continuously until they 're fixed , but never when it 's time to pay for it .</tokentext>
<sentencetext>are not going to happen in large organizations.
Nobody ever knows everything about the strategy or organizational structure, and the people and managers change places and responsibilities faster than any project can proceed.
And continuity, crisis and incident management are only longed for when the systems are down and eveybody is expected to work continuously until they're fixed, but never when it's time to pay for it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31029848</id>
	<title>Re: this book covers it all</title>
	<author>Anonymous</author>
	<datestamp>1265293800000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>they are dominating the planet right now.....</p></htmltext>
<tokenext>they are dominating the planet right now.... .</tokentext>
<sentencetext>they are dominating the planet right now.....</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31025604</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31026178</id>
	<title>Warning</title>
	<author>Anonymous</author>
	<datestamp>1265274660000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>Unless you are actually working on a web site that needs to be scalable, thinking about scalability is both a waste of time and harmful. A totally unscalabe web app where each page view takes 1 second, can sustain 86k page hits per day or 2.5 million page hits per month. Will your web site see that much traffic? Really? If not, your main objective should be to get the site out of the door as soon as possible to keep development costs down. Hopefully, users flock to your site, melting the servers under huge loads of traffic. Good for you, you'll have a very profitable job designing the next scalable version of the site.</p><p>Or you get no traffic because the site idea was stupid to begin with. That sucks, but much less so than if you had spent months of effort making it scalable. "Scalable architecture" is merely a different form of premature optimization, and it is just as harmful.</p></htmltext>
<tokenext>Unless you are actually working on a web site that needs to be scalable , thinking about scalability is both a waste of time and harmful .
A totally unscalabe web app where each page view takes 1 second , can sustain 86k page hits per day or 2.5 million page hits per month .
Will your web site see that much traffic ?
Really ? If not , your main objective should be to get the site out of the door as soon as possible to keep development costs down .
Hopefully , users flock to your site , melting the servers under huge loads of traffic .
Good for you , you 'll have a very profitable job designing the next scalable version of the site.Or you get no traffic because the site idea was stupid to begin with .
That sucks , but much less so than if you had spent months of effort making it scalable .
" Scalable architecture " is merely a different form of premature optimization , and it is just as harmful .</tokentext>
<sentencetext>Unless you are actually working on a web site that needs to be scalable, thinking about scalability is both a waste of time and harmful.
A totally unscalabe web app where each page view takes 1 second, can sustain 86k page hits per day or 2.5 million page hits per month.
Will your web site see that much traffic?
Really? If not, your main objective should be to get the site out of the door as soon as possible to keep development costs down.
Hopefully, users flock to your site, melting the servers under huge loads of traffic.
Good for you, you'll have a very profitable job designing the next scalable version of the site.Or you get no traffic because the site idea was stupid to begin with.
That sucks, but much less so than if you had spent months of effort making it scalable.
"Scalable architecture" is merely a different form of premature optimization, and it is just as harmful.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31026622</id>
	<title>Scalable?</title>
	<author>frank\_adrian314159</author>
	<datestamp>1265276400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>Creating high performance growing networks is really a special skill managers and network architects should posses to be ready for the future.</i> </p><p>Most software/network designers will never work on any project that has so much traffic that it needs to scale to the levels discussed in this book.  In fact, most (note I say <i>most</i>) businesses don't actually need the amount of scalability currently built into their current out-of-the-box hardware and software solutions.  Just saying...</p></htmltext>
<tokenext>Creating high performance growing networks is really a special skill managers and network architects should posses to be ready for the future .
Most software/network designers will never work on any project that has so much traffic that it needs to scale to the levels discussed in this book .
In fact , most ( note I say most ) businesses do n't actually need the amount of scalability currently built into their current out-of-the-box hardware and software solutions .
Just saying.. .</tokentext>
<sentencetext>Creating high performance growing networks is really a special skill managers and network architects should posses to be ready for the future.
Most software/network designers will never work on any project that has so much traffic that it needs to scale to the levels discussed in this book.
In fact, most (note I say most) businesses don't actually need the amount of scalability currently built into their current out-of-the-box hardware and software solutions.
Just saying...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31028434</id>
	<title>Re:Warning</title>
	<author>Anonymous</author>
	<datestamp>1265285460000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Well, while I do agree with you, there are little things that you can do to make it *easier* to scale later. For example, you can design your architecture around lots of small non-coupled components---so if you ever need to, you can run them in parallel, etc.</p></htmltext>
<tokenext>Well , while I do agree with you , there are little things that you can do to make it * easier * to scale later .
For example , you can design your architecture around lots of small non-coupled components---so if you ever need to , you can run them in parallel , etc .</tokentext>
<sentencetext>Well, while I do agree with you, there are little things that you can do to make it *easier* to scale later.
For example, you can design your architecture around lots of small non-coupled components---so if you ever need to, you can run them in parallel, etc.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31026178</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31026224</id>
	<title>Re:Very Marketable</title>
	<author>emt377</author>
	<datestamp>1265274840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>What you are suggesting is akin to 'Bubble sorts are a great algorithm if you do them an a fast CPU'. </p></div><p>This is an interesting analogy, because the fastest possible way to sort 3 elements is bubble sort.  It's a good example why reductionism often yields poor algorithms.  It's also relevant to scalability of implementation versus scalability of architecture.  The former is more about software design, running MT hot, clustering, db schemas, etc, while the latter is more about partitioning the problem and processes.  Many business processes are much too big for any one person to comprehend in depth, and it's important to partition it so everyone can understand the overarching purpose and structure, but only have to be expert on one part.  These can then further partitioned if big enough.  Scalability of architecture in the really comes down to modularity and an ability to identify and eliminate bottlenecks - an implementation may have bottlenecks, but with a good architecture individual parts can be reimplemented or provisioned as needed to eliminate them.  It's also common to architect for the biggest realistic scope but only implement what's actually needed; this guarantees that things like policy management goes in place early even if it's mostly a skeleton.  Since policy needs to be managed at the highest abstract level it needs to be part of the architecture, and is one of those things that's virtually impossible to bolt on after the fact.  Anyway, somehow I wanted to convey that good architecture can't be reduced to good implementation and while good implementation is important it's not actually essential.  What's essential is that good implementation is <i>possible</i>.  (This is also why if you can't design and implement software at high level of proficiency you can't architect, because you will invariably paint yourself into a corner.)</p></div>
	</htmltext>
<tokenext>What you are suggesting is akin to 'Bubble sorts are a great algorithm if you do them an a fast CPU' .
This is an interesting analogy , because the fastest possible way to sort 3 elements is bubble sort .
It 's a good example why reductionism often yields poor algorithms .
It 's also relevant to scalability of implementation versus scalability of architecture .
The former is more about software design , running MT hot , clustering , db schemas , etc , while the latter is more about partitioning the problem and processes .
Many business processes are much too big for any one person to comprehend in depth , and it 's important to partition it so everyone can understand the overarching purpose and structure , but only have to be expert on one part .
These can then further partitioned if big enough .
Scalability of architecture in the really comes down to modularity and an ability to identify and eliminate bottlenecks - an implementation may have bottlenecks , but with a good architecture individual parts can be reimplemented or provisioned as needed to eliminate them .
It 's also common to architect for the biggest realistic scope but only implement what 's actually needed ; this guarantees that things like policy management goes in place early even if it 's mostly a skeleton .
Since policy needs to be managed at the highest abstract level it needs to be part of the architecture , and is one of those things that 's virtually impossible to bolt on after the fact .
Anyway , somehow I wanted to convey that good architecture ca n't be reduced to good implementation and while good implementation is important it 's not actually essential .
What 's essential is that good implementation is possible .
( This is also why if you ca n't design and implement software at high level of proficiency you ca n't architect , because you will invariably paint yourself into a corner .
)</tokentext>
<sentencetext>What you are suggesting is akin to 'Bubble sorts are a great algorithm if you do them an a fast CPU'.
This is an interesting analogy, because the fastest possible way to sort 3 elements is bubble sort.
It's a good example why reductionism often yields poor algorithms.
It's also relevant to scalability of implementation versus scalability of architecture.
The former is more about software design, running MT hot, clustering, db schemas, etc, while the latter is more about partitioning the problem and processes.
Many business processes are much too big for any one person to comprehend in depth, and it's important to partition it so everyone can understand the overarching purpose and structure, but only have to be expert on one part.
These can then further partitioned if big enough.
Scalability of architecture in the really comes down to modularity and an ability to identify and eliminate bottlenecks - an implementation may have bottlenecks, but with a good architecture individual parts can be reimplemented or provisioned as needed to eliminate them.
It's also common to architect for the biggest realistic scope but only implement what's actually needed; this guarantees that things like policy management goes in place early even if it's mostly a skeleton.
Since policy needs to be managed at the highest abstract level it needs to be part of the architecture, and is one of those things that's virtually impossible to bolt on after the fact.
Anyway, somehow I wanted to convey that good architecture can't be reduced to good implementation and while good implementation is important it's not actually essential.
What's essential is that good implementation is possible.
(This is also why if you can't design and implement software at high level of proficiency you can't architect, because you will invariably paint yourself into a corner.
)
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31025516</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31026812</id>
	<title>Re:How Marketable Will That Skill Be?</title>
	<author>Anonymous</author>
	<datestamp>1265277240000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>As long as there is a limit on what a single item can do, there'll be the people whose needs go beyond that, and thus end up needing more than one of said item to handle their workload.</p><p>But sure, when the day comes that we have a thing that'll let us transfer unlimited bits over an unlimited distance and use unlimited cpu cycles and has unlimited memory and unlimited storage all at once, then yes, you're right, scaling won't be necessary. But until then?</p></htmltext>
<tokenext>As long as there is a limit on what a single item can do , there 'll be the people whose needs go beyond that , and thus end up needing more than one of said item to handle their workload.But sure , when the day comes that we have a thing that 'll let us transfer unlimited bits over an unlimited distance and use unlimited cpu cycles and has unlimited memory and unlimited storage all at once , then yes , you 're right , scaling wo n't be necessary .
But until then ?</tokentext>
<sentencetext>As long as there is a limit on what a single item can do, there'll be the people whose needs go beyond that, and thus end up needing more than one of said item to handle their workload.But sure, when the day comes that we have a thing that'll let us transfer unlimited bits over an unlimited distance and use unlimited cpu cycles and has unlimited memory and unlimited storage all at once, then yes, you're right, scaling won't be necessary.
But until then?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31024974</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31024910</id>
	<title>Ferst Past</title>
	<author>Anonymous</author>
	<datestamp>1265311200000</datestamp>
	<modclass>Troll</modclass>
	<modscore>-1</modscore>
	<htmltext><p>HI all.</p></htmltext>
<tokenext>HI all .</tokentext>
<sentencetext>HI all.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31025604</id>
	<title>Re: this book covers it all</title>
	<author>Anonymous</author>
	<datestamp>1265314800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Maybe because in some ways, slime molds and fungi (slime mold isn't a true fungus) actually have far more advanced physiologies than our own. Don't confuse the primitive appearance of the organism with its biological complexity and resilience. If the fungi had ever evolved locomotion, they would be dominating the planet right now.</htmltext>
<tokenext>Maybe because in some ways , slime molds and fungi ( slime mold is n't a true fungus ) actually have far more advanced physiologies than our own .
Do n't confuse the primitive appearance of the organism with its biological complexity and resilience .
If the fungi had ever evolved locomotion , they would be dominating the planet right now .</tokentext>
<sentencetext>Maybe because in some ways, slime molds and fungi (slime mold isn't a true fungus) actually have far more advanced physiologies than our own.
Don't confuse the primitive appearance of the organism with its biological complexity and resilience.
If the fungi had ever evolved locomotion, they would be dominating the planet right now.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31024938</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31026620</id>
	<title>Re:How Marketable Will That Skill Be?</title>
	<author>khallow</author>
	<datestamp>1265276400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>I'm not sure that scalability will be all that relevant as long as Moore's Law continues to hold.</p></div><p>If that were going to be true, it would have happened long ago. Remember the traffic for a popular website can double a lot faster than once every two years.</p></div>
	</htmltext>
<tokenext>I 'm not sure that scalability will be all that relevant as long as Moore 's Law continues to hold.If that were going to be true , it would have happened long ago .
Remember the traffic for a popular website can double a lot faster than once every two years .</tokentext>
<sentencetext>I'm not sure that scalability will be all that relevant as long as Moore's Law continues to hold.If that were going to be true, it would have happened long ago.
Remember the traffic for a popular website can double a lot faster than once every two years.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31024974</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31031990</id>
	<title>Re:How Marketable Will That Skill Be?</title>
	<author>inKubus</author>
	<datestamp>1265313120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Unfortunately, they have multiple datacenters and they are running cached mysql with some magic glue so it often does take several minutes for changes to propagate from coast to coast, become cached, etc.  That's why the default feed is not live, but you can click it to get it--they would be brought to their knees doing all live updates.</p><p>They do use a technique called sharding which keeps the row counts down.  Basically they break up all the users into different tables, databases or even servers.  Then they try to keep users who talk to each other frequently in the same "shard".  This minimizes the joins and of course enables more horizontal scalability.  Personally, I think they could probably do more with a mainframe style of system but they don't have the money for that.  Not that I hate LAMP but really the site is shoddy.  Unpredictable at best, and really it doesn't do much.  Just holds some information from almost every person in the U.S.</p><p>So what?  TransUnion and Experian have held our entire credit histories and can not only retrieve them but score them with a complex algorithm in a few milliseconds.  Which goes to show (and I've been trying to tell my boss this with some success) is that it's not just the data or the complexity but the interactivity that really intensifies the need for speed.  Ajax and stuff is cool but it's only cool when it works fast.  Otherwise it sucks.</p><p>So now we're dealing with hundreds of tiny requests rather than one big one.  Apache was designed to handle those big requests.  So you run into lots of issues there.  Yeah, there's lighty and nginx which are going to be the new kings of that stuff.  I'm thinking about probably moving my web services to a separate web server from my big MVC framework pages.</p></htmltext>
<tokenext>Unfortunately , they have multiple datacenters and they are running cached mysql with some magic glue so it often does take several minutes for changes to propagate from coast to coast , become cached , etc .
That 's why the default feed is not live , but you can click it to get it--they would be brought to their knees doing all live updates.They do use a technique called sharding which keeps the row counts down .
Basically they break up all the users into different tables , databases or even servers .
Then they try to keep users who talk to each other frequently in the same " shard " .
This minimizes the joins and of course enables more horizontal scalability .
Personally , I think they could probably do more with a mainframe style of system but they do n't have the money for that .
Not that I hate LAMP but really the site is shoddy .
Unpredictable at best , and really it does n't do much .
Just holds some information from almost every person in the U.S.So what ?
TransUnion and Experian have held our entire credit histories and can not only retrieve them but score them with a complex algorithm in a few milliseconds .
Which goes to show ( and I 've been trying to tell my boss this with some success ) is that it 's not just the data or the complexity but the interactivity that really intensifies the need for speed .
Ajax and stuff is cool but it 's only cool when it works fast .
Otherwise it sucks.So now we 're dealing with hundreds of tiny requests rather than one big one .
Apache was designed to handle those big requests .
So you run into lots of issues there .
Yeah , there 's lighty and nginx which are going to be the new kings of that stuff .
I 'm thinking about probably moving my web services to a separate web server from my big MVC framework pages .</tokentext>
<sentencetext>Unfortunately, they have multiple datacenters and they are running cached mysql with some magic glue so it often does take several minutes for changes to propagate from coast to coast, become cached, etc.
That's why the default feed is not live, but you can click it to get it--they would be brought to their knees doing all live updates.They do use a technique called sharding which keeps the row counts down.
Basically they break up all the users into different tables, databases or even servers.
Then they try to keep users who talk to each other frequently in the same "shard".
This minimizes the joins and of course enables more horizontal scalability.
Personally, I think they could probably do more with a mainframe style of system but they don't have the money for that.
Not that I hate LAMP but really the site is shoddy.
Unpredictable at best, and really it doesn't do much.
Just holds some information from almost every person in the U.S.So what?
TransUnion and Experian have held our entire credit histories and can not only retrieve them but score them with a complex algorithm in a few milliseconds.
Which goes to show (and I've been trying to tell my boss this with some success) is that it's not just the data or the complexity but the interactivity that really intensifies the need for speed.
Ajax and stuff is cool but it's only cool when it works fast.
Otherwise it sucks.So now we're dealing with hundreds of tiny requests rather than one big one.
Apache was designed to handle those big requests.
So you run into lots of issues there.
Yeah, there's lighty and nginx which are going to be the new kings of that stuff.
I'm thinking about probably moving my web services to a separate web server from my big MVC framework pages.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31025478</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31027412</id>
	<title>Re:How Marketable Will That Skill Be?</title>
	<author>liquiddark</author>
	<datestamp>1265280000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Moore's Law 1) isn't about speed in particular and 2) may or may not hold for much longer.  It was only predicted to last 10-20 years, and that was almost 50 years ago.  We have about 5 halvings to go before we've saturated silicon at the atomic level, and although there are other techniques for preserving the growth curve, we're far enough away from Grand Computing Goals that it would seem likely we're going to see a dramatic slowing in the growth of computer power per dollar spent in the reasonably near future.  <br>
<br>
It's definitely well past time that anyone who wants to work in IT start concerning themselves with scalable solutions.  Relying on morebetterfastercheaper hardware stopped being wise about the same time processor clock speeds stopped rising, which was several years ago.</htmltext>
<tokenext>Moore 's Law 1 ) is n't about speed in particular and 2 ) may or may not hold for much longer .
It was only predicted to last 10-20 years , and that was almost 50 years ago .
We have about 5 halvings to go before we 've saturated silicon at the atomic level , and although there are other techniques for preserving the growth curve , we 're far enough away from Grand Computing Goals that it would seem likely we 're going to see a dramatic slowing in the growth of computer power per dollar spent in the reasonably near future .
It 's definitely well past time that anyone who wants to work in IT start concerning themselves with scalable solutions .
Relying on morebetterfastercheaper hardware stopped being wise about the same time processor clock speeds stopped rising , which was several years ago .</tokentext>
<sentencetext>Moore's Law 1) isn't about speed in particular and 2) may or may not hold for much longer.
It was only predicted to last 10-20 years, and that was almost 50 years ago.
We have about 5 halvings to go before we've saturated silicon at the atomic level, and although there are other techniques for preserving the growth curve, we're far enough away from Grand Computing Goals that it would seem likely we're going to see a dramatic slowing in the growth of computer power per dollar spent in the reasonably near future.
It's definitely well past time that anyone who wants to work in IT start concerning themselves with scalable solutions.
Relying on morebetterfastercheaper hardware stopped being wise about the same time processor clock speeds stopped rising, which was several years ago.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31024974</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31026534</id>
	<title>Re:How Marketable Will That Skill Be?</title>
	<author>ClosedSource</author>
	<datestamp>1265276100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Remember Moore's law is about number of transistors. Historically there was a correlation between Moore's law and processor performance. A mulitcore approach breaks that correlation.</p></htmltext>
<tokenext>Remember Moore 's law is about number of transistors .
Historically there was a correlation between Moore 's law and processor performance .
A mulitcore approach breaks that correlation .</tokentext>
<sentencetext>Remember Moore's law is about number of transistors.
Historically there was a correlation between Moore's law and processor performance.
A mulitcore approach breaks that correlation.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31024974</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31024974</id>
	<title>How Marketable Will That Skill Be?</title>
	<author>damn\_registrars</author>
	<datestamp>1265311440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I'm not sure that scalability will be all that relevant as long as Moore's Law continues to hold.  IIRC it has taken on average less than 10 years for the computing power of a top10 supercomuter to be available in a consumer laptop.  As computational resources on the market continue to expand, I would suspect that we could soon come to see the opposite of scalability becoming more important - getting more done with less space and energy.<br> <br>
That said, any admin worth their salt who focused on scalability should still be an excellent sys admin anyways, so they shouldn't be heading towards the bread line.  I'm just not convinced that focusing on learning skills for network scaling is the best idea unless you want to build clusters for research groups.</htmltext>
<tokenext>I 'm not sure that scalability will be all that relevant as long as Moore 's Law continues to hold .
IIRC it has taken on average less than 10 years for the computing power of a top10 supercomuter to be available in a consumer laptop .
As computational resources on the market continue to expand , I would suspect that we could soon come to see the opposite of scalability becoming more important - getting more done with less space and energy .
That said , any admin worth their salt who focused on scalability should still be an excellent sys admin anyways , so they should n't be heading towards the bread line .
I 'm just not convinced that focusing on learning skills for network scaling is the best idea unless you want to build clusters for research groups .</tokentext>
<sentencetext>I'm not sure that scalability will be all that relevant as long as Moore's Law continues to hold.
IIRC it has taken on average less than 10 years for the computing power of a top10 supercomuter to be available in a consumer laptop.
As computational resources on the market continue to expand, I would suspect that we could soon come to see the opposite of scalability becoming more important - getting more done with less space and energy.
That said, any admin worth their salt who focused on scalability should still be an excellent sys admin anyways, so they shouldn't be heading towards the bread line.
I'm just not convinced that focusing on learning skills for network scaling is the best idea unless you want to build clusters for research groups.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31025358</id>
	<title>Re:How Marketable Will That Skill Be?</title>
	<author>Anonymous</author>
	<datestamp>1265313480000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>Did you even look at the title of the book?</p><p>"Scalable Web Architecture, Processes and Organizations for the Modern Enterprise"</p><p>This has more to do than just processing power. Good Grief...</p></htmltext>
<tokenext>Did you even look at the title of the book ?
" Scalable Web Architecture , Processes and Organizations for the Modern Enterprise " This has more to do than just processing power .
Good Grief.. .</tokentext>
<sentencetext>Did you even look at the title of the book?
"Scalable Web Architecture, Processes and Organizations for the Modern Enterprise"This has more to do than just processing power.
Good Grief...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31024974</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31025158</id>
	<title>Re:How Marketable Will That Skill Be?</title>
	<author>Maximum Prophet</author>
	<datestamp>1265312280000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext>Intel et. al. are achieving Moore's law by adding more cores to existing chips, not making them much faster for single threaded processes.  In ten years, if you really want your code to run fast, it may have to scale across 10s of processors just to run on any given machine.</htmltext>
<tokenext>Intel et .
al. are achieving Moore 's law by adding more cores to existing chips , not making them much faster for single threaded processes .
In ten years , if you really want your code to run fast , it may have to scale across 10s of processors just to run on any given machine .</tokentext>
<sentencetext>Intel et.
al. are achieving Moore's law by adding more cores to existing chips, not making them much faster for single threaded processes.
In ten years, if you really want your code to run fast, it may have to scale across 10s of processors just to run on any given machine.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31024974</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31029460</id>
	<title>Book cover</title>
	<author>Anonymous</author>
	<datestamp>1265291640000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Ok, let me get this straight. You wrote a book about scalability, and for the cover image you picked... a bonsai? Really?</p><p>Does that mean that all of the book's advice boils down to a paraphrasing of "If you want your tree to grow large, then stop cutting off its roots, asshole!"</p></htmltext>
<tokenext>Ok , let me get this straight .
You wrote a book about scalability , and for the cover image you picked... a bonsai ?
Really ? Does that mean that all of the book 's advice boils down to a paraphrasing of " If you want your tree to grow large , then stop cutting off its roots , asshole !
"</tokentext>
<sentencetext>Ok, let me get this straight.
You wrote a book about scalability, and for the cover image you picked... a bonsai?
Really?Does that mean that all of the book's advice boils down to a paraphrasing of "If you want your tree to grow large, then stop cutting off its roots, asshole!
"</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31028122</id>
	<title>Re:Warning</title>
	<author>Jay L</author>
	<datestamp>1265283780000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Unless you are actually a contender for the Olympics, thinking about being stronger and faster is both a waste of time and harmful. Will you actually be a finalist? Really? If not, your main objective should be to fit out the door. Hopefully, sponsors flock to you. Good for you, you'll have your work cut out for you training in the pre-season.</p><p>Or you watch the Olympics on TV like the rest of us. That sucks, but much less so than if you had spent months of effort cutting your times by a hundredth of a second. "Training" is merely a different form of premature optimization, and it is just as harmful.</p></htmltext>
<tokenext>Unless you are actually a contender for the Olympics , thinking about being stronger and faster is both a waste of time and harmful .
Will you actually be a finalist ?
Really ? If not , your main objective should be to fit out the door .
Hopefully , sponsors flock to you .
Good for you , you 'll have your work cut out for you training in the pre-season.Or you watch the Olympics on TV like the rest of us .
That sucks , but much less so than if you had spent months of effort cutting your times by a hundredth of a second .
" Training " is merely a different form of premature optimization , and it is just as harmful .</tokentext>
<sentencetext>Unless you are actually a contender for the Olympics, thinking about being stronger and faster is both a waste of time and harmful.
Will you actually be a finalist?
Really? If not, your main objective should be to fit out the door.
Hopefully, sponsors flock to you.
Good for you, you'll have your work cut out for you training in the pre-season.Or you watch the Olympics on TV like the rest of us.
That sucks, but much less so than if you had spent months of effort cutting your times by a hundredth of a second.
"Training" is merely a different form of premature optimization, and it is just as harmful.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31026178</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31040040</id>
	<title>Re:How Marketable Will That Skill Be?</title>
	<author>z-j-y</author>
	<datestamp>1265367360000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>twitter wasn't scalable at all even long after it became famous.</p><p>don't buy this book. only 12.5 people on the earth need to know scalability, and they don't need to read this book either.</p></htmltext>
<tokenext>twitter was n't scalable at all even long after it became famous.do n't buy this book .
only 12.5 people on the earth need to know scalability , and they do n't need to read this book either .</tokentext>
<sentencetext>twitter wasn't scalable at all even long after it became famous.don't buy this book.
only 12.5 people on the earth need to know scalability, and they don't need to read this book either.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31025478</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31027076</id>
	<title>Re:Warning</title>
	<author>Jeppe Salvesen</author>
	<datestamp>1265278320000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext><p>Once you know how, making the solution fairly scalable is usually not a whole lot of extra work. Furthermore, if you don't bother learning how to do stuff right, you'll continue to make subpar products until you get your shot and then you waste that shot because your solution wasn't up to the task. Ahh.</p></htmltext>
<tokenext>Once you know how , making the solution fairly scalable is usually not a whole lot of extra work .
Furthermore , if you do n't bother learning how to do stuff right , you 'll continue to make subpar products until you get your shot and then you waste that shot because your solution was n't up to the task .
Ahh .</tokentext>
<sentencetext>Once you know how, making the solution fairly scalable is usually not a whole lot of extra work.
Furthermore, if you don't bother learning how to do stuff right, you'll continue to make subpar products until you get your shot and then you waste that shot because your solution wasn't up to the task.
Ahh.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31026178</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31025478</id>
	<title>Re:How Marketable Will That Skill Be?</title>
	<author>Blakey Rat</author>
	<datestamp>1265314020000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p><i>I'm not sure that scalability will be all that relevant as long as Moore's Law continues to hold.</i></p><p>Ask Twitter or Facebook.</p><p>Moore's Law is helping them, I'm sure, but for really successful new websites, it's nothing compared to the influx of new customers to deal with. (And yes, it's Slashdot so we all must hate Twitter, but you have to admit they grew damned fast.)</p><p>I think you're overestimating the value of CPU power here. The real bottleneck is always data-- storing data in such a way that access to it is fast, but keeping it in a consistent state at the same time. Nobody would use Facebook or Twitter if it took a couple minutes for your status update to be visible by your friend.</p></htmltext>
<tokenext>I 'm not sure that scalability will be all that relevant as long as Moore 's Law continues to hold.Ask Twitter or Facebook.Moore 's Law is helping them , I 'm sure , but for really successful new websites , it 's nothing compared to the influx of new customers to deal with .
( And yes , it 's Slashdot so we all must hate Twitter , but you have to admit they grew damned fast .
) I think you 're overestimating the value of CPU power here .
The real bottleneck is always data-- storing data in such a way that access to it is fast , but keeping it in a consistent state at the same time .
Nobody would use Facebook or Twitter if it took a couple minutes for your status update to be visible by your friend .</tokentext>
<sentencetext>I'm not sure that scalability will be all that relevant as long as Moore's Law continues to hold.Ask Twitter or Facebook.Moore's Law is helping them, I'm sure, but for really successful new websites, it's nothing compared to the influx of new customers to deal with.
(And yes, it's Slashdot so we all must hate Twitter, but you have to admit they grew damned fast.
)I think you're overestimating the value of CPU power here.
The real bottleneck is always data-- storing data in such a way that access to it is fast, but keeping it in a consistent state at the same time.
Nobody would use Facebook or Twitter if it took a couple minutes for your status update to be visible by your friend.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31024974</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31027002</id>
	<title>Re:Warning</title>
	<author>BitZtream</author>
	<datestamp>1265277960000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>Wrong, because 80k of those hits actually come during a 8-12 portion of the day, sometimes much smaller depending on the focus of the site.</p><p>Yes, its fine if you're never going to get anywhere near that kind of load, but load planning doesn't work in 'days' it works in hourly peaks and valleys if you want to look at it from a real rough perspective.</p><p>Ask some sites that get slashdotted how well capacity planning works when you get 120k hits in the first hour its on slashdot, and 10k for the rest of the day after it has moved down the list on the main page.  Sure they could have easily handled the load with a little delay if they had built an app that loads in 1 second, IF the load was perfectly timed to send one request per second, which simply isn't the way it works.</p></htmltext>
<tokenext>Wrong , because 80k of those hits actually come during a 8-12 portion of the day , sometimes much smaller depending on the focus of the site.Yes , its fine if you 're never going to get anywhere near that kind of load , but load planning does n't work in 'days ' it works in hourly peaks and valleys if you want to look at it from a real rough perspective.Ask some sites that get slashdotted how well capacity planning works when you get 120k hits in the first hour its on slashdot , and 10k for the rest of the day after it has moved down the list on the main page .
Sure they could have easily handled the load with a little delay if they had built an app that loads in 1 second , IF the load was perfectly timed to send one request per second , which simply is n't the way it works .</tokentext>
<sentencetext>Wrong, because 80k of those hits actually come during a 8-12 portion of the day, sometimes much smaller depending on the focus of the site.Yes, its fine if you're never going to get anywhere near that kind of load, but load planning doesn't work in 'days' it works in hourly peaks and valleys if you want to look at it from a real rough perspective.Ask some sites that get slashdotted how well capacity planning works when you get 120k hits in the first hour its on slashdot, and 10k for the rest of the day after it has moved down the list on the main page.
Sure they could have easily handled the load with a little delay if they had built an app that loads in 1 second, IF the load was perfectly timed to send one request per second, which simply isn't the way it works.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31026178</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31027016</id>
	<title>throughput vs latency</title>
	<author>Colin Smith</author>
	<datestamp>1265278020000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p><div class="quote"><p>A totally unscalabe web app where each page view takes 1 second</p></div><p>That's latency, not throughput. Scalability is throughput. Latency is how shitty it is to use.</p><p>I can scale your 1 second web app by adding 1000 processes per server and 1000 servers. That's a million page views per second throughput. But it'll still be a 1 second latency piece of shit application.</p><p>
&nbsp;</p></div>
	</htmltext>
<tokenext>A totally unscalabe web app where each page view takes 1 secondThat 's latency , not throughput .
Scalability is throughput .
Latency is how shitty it is to use.I can scale your 1 second web app by adding 1000 processes per server and 1000 servers .
That 's a million page views per second throughput .
But it 'll still be a 1 second latency piece of shit application .
 </tokentext>
<sentencetext>A totally unscalabe web app where each page view takes 1 secondThat's latency, not throughput.
Scalability is throughput.
Latency is how shitty it is to use.I can scale your 1 second web app by adding 1000 processes per server and 1000 servers.
That's a million page views per second throughput.
But it'll still be a 1 second latency piece of shit application.
 
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31026178</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31025508</id>
	<title>Re:Eerie</title>
	<author>getSalled</author>
	<datestamp>1265314260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Talk about the metaphor of all metaphors....</htmltext>
<tokenext>Talk about the metaphor of all metaphors... .</tokentext>
<sentencetext>Talk about the metaphor of all metaphors....</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31025206</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31030954</id>
	<title>Re:throughput vs latency</title>
	<author>Firehed</author>
	<datestamp>1265303940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>He's obviously talking about the page rendering time, not hosting a fast app from a dial-up connection. We're not serving static pages anymore (and if it takes a full second to serve a static page, you're doing something seriously wrong).</p></htmltext>
<tokenext>He 's obviously talking about the page rendering time , not hosting a fast app from a dial-up connection .
We 're not serving static pages anymore ( and if it takes a full second to serve a static page , you 're doing something seriously wrong ) .</tokentext>
<sentencetext>He's obviously talking about the page rendering time, not hosting a fast app from a dial-up connection.
We're not serving static pages anymore (and if it takes a full second to serve a static page, you're doing something seriously wrong).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31027016</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31027656</id>
	<title>Re:Warning</title>
	<author>gbjbaanb</author>
	<datestamp>1265281440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>Unless you are actually working on a web site that needs to be scalable</i></p><p>I'm sure they wrote Facebook thinking they'd only get a few hundred hits per month... few years and several billion dollars later, guess what - they're writing PHP compilers to fix the problems with the initial design.</p><p>Take a little time to make yourself a better developer, learn the necessary knowledge and apply it to all you do, and you'll be known as the guy who writes good systems. Keep thinking you can just hack it all together and you'll be the guy who wrote those shitty systems that need to be replaced. I know which guy I'd prefer to be. The biggest thing is - you don't need to spend more time at all on designing the better system once you've become good, doing a good job will become second nature.</p></htmltext>
<tokenext>Unless you are actually working on a web site that needs to be scalableI 'm sure they wrote Facebook thinking they 'd only get a few hundred hits per month... few years and several billion dollars later , guess what - they 're writing PHP compilers to fix the problems with the initial design.Take a little time to make yourself a better developer , learn the necessary knowledge and apply it to all you do , and you 'll be known as the guy who writes good systems .
Keep thinking you can just hack it all together and you 'll be the guy who wrote those shitty systems that need to be replaced .
I know which guy I 'd prefer to be .
The biggest thing is - you do n't need to spend more time at all on designing the better system once you 've become good , doing a good job will become second nature .</tokentext>
<sentencetext>Unless you are actually working on a web site that needs to be scalableI'm sure they wrote Facebook thinking they'd only get a few hundred hits per month... few years and several billion dollars later, guess what - they're writing PHP compilers to fix the problems with the initial design.Take a little time to make yourself a better developer, learn the necessary knowledge and apply it to all you do, and you'll be known as the guy who writes good systems.
Keep thinking you can just hack it all together and you'll be the guy who wrote those shitty systems that need to be replaced.
I know which guy I'd prefer to be.
The biggest thing is - you don't need to spend more time at all on designing the better system once you've become good, doing a good job will become second nature.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31026178</parent>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_04_1538251_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31028434
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31026178
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_04_1538251_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31025158
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31024974
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_04_1538251_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31026620
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31024974
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_04_1538251_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31025508
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31025206
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_04_1538251_19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31040040
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31025478
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31024974
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_04_1538251_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31025358
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31024974
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_04_1538251_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31026812
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31024974
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_04_1538251_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31028122
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31026178
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_04_1538251_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31027060
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31025516
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31024974
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_04_1538251_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31026224
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31025516
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31024974
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_04_1538251_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31031990
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31025478
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31024974
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_04_1538251_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31027656
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31026178
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_04_1538251_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31027412
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31024974
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_04_1538251_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31027002
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31026178
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_04_1538251_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31026450
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31025516
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31024974
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_04_1538251_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31026534
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31024974
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_04_1538251_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31027076
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31026178
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_04_1538251_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31029848
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31025604
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31024938
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_04_1538251_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31030954
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31027016
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31026178
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_04_1538251_18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31027484
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31025124
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_04_1538251.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31024938
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31025604
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31029848
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_04_1538251.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31025124
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31027484
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_04_1538251.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31026370
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_04_1538251.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31024974
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31026534
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31025158
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31026812
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31025516
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31026450
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31027060
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31026224
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31025478
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31040040
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31031990
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31025358
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31026620
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31027412
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_04_1538251.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31025206
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31025508
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_04_1538251.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31029460
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_04_1538251.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31026178
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31027016
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31030954
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31027076
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31028434
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31027002
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31027656
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_04_1538251.31028122
</commentlist>
</conversation>
