<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments for Jeff Heuer</title>
	<atom:link href="http://www.jeffheuer.com/blog/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.jeffheuer.com/blog</link>
	<description>Strategy, User Experience, Code</description>
	<lastBuildDate>Tue, 14 Jul 2009 03:27:25 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1-alpha</generator>
	<item>
		<title>Comment on 5 Reasons APIs Suck by Ken</title>
		<link>http://www.jeffheuer.com/blog/2008/09/5-reasons-apis-suck/comment-page-1/#comment-255</link>
		<dc:creator>Ken</dc:creator>
		<pubDate>Tue, 14 Jul 2009 03:27:25 +0000</pubDate>
		<guid isPermaLink="false">http://www.jeffheuer.com/blog/?p=93#comment-255</guid>
		<description>API&#039;s do suck, and they suck hard. I have been working with the Amazon AWS API for the past year and knowing what I know today, I would never even use it. 

What Amazon&#039;s AWS has taught me:

1. API&#039;s can have ridiculous limits on traffic usage and requests. Someone can steal your API access key which is readily available in any url and you are screwed.

2. API&#039;s constantly change, and more often than not whatever version you are using is going to become obsolete and forced into retirement, making your site useless.

3. The documentation for API&#039;s is crap at best. Often times you will find yourself getting confused over conventions because of mistakes in the documentation examples which are using outdated examples

4. As you mentioned you are dependent on the API. This applies to anything really. Take advertising for example most sites are dependent on Google Adsense, once they give you the boot your site has lost all revenue. Same thing with a job, you are dependent on one job, if you get fired or laid off you need to find a new one.


Overall, I will avoid complicated API&#039;s that take months to learn. If I use an API it will be for a minuscule part of my site that isn&#039;t detrimental to its success. I would never create a site that is dependent on one or more API&#039;s ever again.</description>
		<content:encoded><![CDATA[<p>API&#8217;s do suck, and they suck hard. I have been working with the Amazon AWS API for the past year and knowing what I know today, I would never even use it. </p>
<p>What Amazon&#8217;s AWS has taught me:</p>
<p>1. API&#8217;s can have ridiculous limits on traffic usage and requests. Someone can steal your API access key which is readily available in any url and you are screwed.</p>
<p>2. API&#8217;s constantly change, and more often than not whatever version you are using is going to become obsolete and forced into retirement, making your site useless.</p>
<p>3. The documentation for API&#8217;s is crap at best. Often times you will find yourself getting confused over conventions because of mistakes in the documentation examples which are using outdated examples</p>
<p>4. As you mentioned you are dependent on the API. This applies to anything really. Take advertising for example most sites are dependent on Google Adsense, once they give you the boot your site has lost all revenue. Same thing with a job, you are dependent on one job, if you get fired or laid off you need to find a new one.</p>
<p>Overall, I will avoid complicated API&#8217;s that take months to learn. If I use an API it will be for a minuscule part of my site that isn&#8217;t detrimental to its success. I would never create a site that is dependent on one or more API&#8217;s ever again.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on 5 Reasons APIs Suck by Ken</title>
		<link>http://www.jeffheuer.com/blog/2008/09/5-reasons-apis-suck/comment-page-1/#comment-3087</link>
		<dc:creator>Ken</dc:creator>
		<pubDate>Tue, 14 Jul 2009 03:27:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.jeffheuer.com/blog/?p=93#comment-3087</guid>
		<description>API’s do suck, and they suck hard. I have been working with the Amazon AWS API for the past year and knowing what I know today, I would never even use it.&lt;br&gt;&lt;br&gt;What Amazon’s AWS has taught me:&lt;br&gt;&lt;br&gt;1. API’s can have ridiculous limits on traffic usage and requests. Someone can steal your API access key which is readily available in any url and you are screwed.&lt;br&gt;&lt;br&gt;2. API’s constantly change, and more often than not whatever version you are using is going to become obsolete and forced into retirement, making your site useless.&lt;br&gt;&lt;br&gt;3. The documentation for API’s is crap at best. Often times you will find yourself getting confused over conventions because of mistakes in the documentation examples which are using outdated examples&lt;br&gt;&lt;br&gt;4. As you mentioned you are dependent on the API. This applies to anything really. Take advertising for example most sites are dependent on Google Adsense, once they give you the boot your site has lost all revenue. Same thing with a job, you are dependent on one job, if you get fired or laid off you need to find a new one.&lt;br&gt;&lt;br&gt;Overall, I will avoid complicated API’s that take months to learn. If I use an API it will be for a minuscule part of my site that isn’t detrimental to its success. I would never create a site that is dependent on one or more API’s ever again.</description>
		<content:encoded><![CDATA[<p>API’s do suck, and they suck hard. I have been working with the Amazon AWS API for the past year and knowing what I know today, I would never even use it.</p>
<p>What Amazon’s AWS has taught me:</p>
<p>1. API’s can have ridiculous limits on traffic usage and requests. Someone can steal your API access key which is readily available in any url and you are screwed.</p>
<p>2. API’s constantly change, and more often than not whatever version you are using is going to become obsolete and forced into retirement, making your site useless.</p>
<p>3. The documentation for API’s is crap at best. Often times you will find yourself getting confused over conventions because of mistakes in the documentation examples which are using outdated examples</p>
<p>4. As you mentioned you are dependent on the API. This applies to anything really. Take advertising for example most sites are dependent on Google Adsense, once they give you the boot your site has lost all revenue. Same thing with a job, you are dependent on one job, if you get fired or laid off you need to find a new one.</p>
<p>Overall, I will avoid complicated API’s that take months to learn. If I use an API it will be for a minuscule part of my site that isn’t detrimental to its success. I would never create a site that is dependent on one or more API’s ever again.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on The Four Hour Web App: Venn&#8217;d by John milton</title>
		<link>http://www.jeffheuer.com/blog/2009/02/the-four-hour-web-app-vennd/comment-page-1/#comment-30</link>
		<dc:creator>John milton</dc:creator>
		<pubDate>Mon, 09 Feb 2009 06:49:24 +0000</pubDate>
		<guid isPermaLink="false">http://www.jeffheuer.com/blog/?p=169#comment-30</guid>
		<description>Hi..
Great article
Nicely done, contents very rich.
Thanks.
john.</description>
		<content:encoded><![CDATA[<p>Hi..<br />
Great article<br />
Nicely done, contents very rich.<br />
Thanks.<br />
john.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on The Four Hour Web App: Venn&#8217;d by John Manoogian III</title>
		<link>http://www.jeffheuer.com/blog/2009/02/the-four-hour-web-app-vennd/comment-page-1/#comment-29</link>
		<dc:creator>John Manoogian III</dc:creator>
		<pubDate>Fri, 06 Feb 2009 23:30:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.jeffheuer.com/blog/?p=169#comment-29</guid>
		<description>Ooooh, sexy. Nice idea.</description>
		<content:encoded><![CDATA[<p>Ooooh, sexy. Nice idea.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Crowdsourcing, Attention and Productivity by John Manoogian III</title>
		<link>http://www.jeffheuer.com/blog/2008/10/crowdsourcing-attention-and-productivity/comment-page-1/#comment-3086</link>
		<dc:creator>John Manoogian III</dc:creator>
		<pubDate>Tue, 28 Oct 2008 17:27:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.jeffheuer.com/blog/?p=157#comment-3086</guid>
		<description>great</description>
		<content:encoded><![CDATA[<p>great</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Crowdsourcing, Attention and Productivity by Ali Sohani</title>
		<link>http://www.jeffheuer.com/blog/2008/10/crowdsourcing-attention-and-productivity/comment-page-1/#comment-6</link>
		<dc:creator>Ali Sohani</dc:creator>
		<pubDate>Tue, 28 Oct 2008 06:10:33 +0000</pubDate>
		<guid isPermaLink="false">http://www.jeffheuer.com/blog/?p=157#comment-6</guid>
		<description>Great Post, I believe that 

Scenario 1: &quot;500 user-contributed videos with 100,000 views each&quot; is better where there are some channels, big TV Companies, Movie publishers etc, where there brand attracts more people to watch shows or videos they produce.

Scenario 2: &quot;5,000 videos with 10,000 views each&quot; is better as many people producing videos according to niche, as you mentioned so directing trend towards more context oriented web of content generated from users interested in particular topics.

In both cases, focus must be on Quality over Quantity, just like any business first we got to retain the audience we have already captured because of our hard and smart work and then try to reach further; you don&#039;t do reverse unless you are inventing big time trying to capture the growth on adjacent side being ready to leave what you got in terms of market.</description>
		<content:encoded><![CDATA[<p>Great Post, I believe that </p>
<p>Scenario 1: &#8220;500 user-contributed videos with 100,000 views each&#8221; is better where there are some channels, big TV Companies, Movie publishers etc, where there brand attracts more people to watch shows or videos they produce.</p>
<p>Scenario 2: &#8220;5,000 videos with 10,000 views each&#8221; is better as many people producing videos according to niche, as you mentioned so directing trend towards more context oriented web of content generated from users interested in particular topics.</p>
<p>In both cases, focus must be on Quality over Quantity, just like any business first we got to retain the audience we have already captured because of our hard and smart work and then try to reach further; you don&#8217;t do reverse unless you are inventing big time trying to capture the growth on adjacent side being ready to leave what you got in terms of market.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Crowdsourcing, Attention and Productivity by John Manoogian III</title>
		<link>http://www.jeffheuer.com/blog/2008/10/crowdsourcing-attention-and-productivity/comment-page-1/#comment-4</link>
		<dc:creator>John Manoogian III</dc:creator>
		<pubDate>Sat, 18 Oct 2008 17:27:32 +0000</pubDate>
		<guid isPermaLink="false">http://www.jeffheuer.com/blog/?p=157#comment-4</guid>
		<description>great thinking on designing around the tyranny of the crowds and hit singles in the mass channel vs. the long, fuzzy tail.</description>
		<content:encoded><![CDATA[<p>great thinking on designing around the tyranny of the crowds and hit singles in the mass channel vs. the long, fuzzy tail.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
