<?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/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments for PointBeyond</title>
	<atom:link href="http://blog.pointbeyond.com/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.pointbeyond.com</link>
	<description>The SharePoint Business Application Specialists</description>
	<lastBuildDate>Fri, 10 Feb 2012 17:00:35 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>Comment on The “No Code” SharePoint Strategy by Christophe</title>
		<link>http://blog.pointbeyond.com/2012/01/31/the-no-code-sharepoint-strategy/#comment-628</link>
		<dc:creator><![CDATA[Christophe]]></dc:creator>
		<pubDate>Fri, 10 Feb 2012 17:00:35 +0000</pubDate>
		<guid isPermaLink="false">http://blog.pointbeyond.com/?p=997#comment-628</guid>
		<description><![CDATA[What you are suggesting is called the law of the instrument. Or: when you have a hammer, everything looks like a nail.

With a healthy needs and ROI analysis, the &quot;no code&quot; approach should be the natural conclusion, not something you have to enforce.

For the record, &quot;no code&quot; is not necesssarily lighter than coding. For example, I do a lot of no code workflows myself in SharePoint Designer, involving loops and calculations, and I sometimes wish I had a developer to make this more straightforward.]]></description>
		<content:encoded><![CDATA[<p>What you are suggesting is called the law of the instrument. Or: when you have a hammer, everything looks like a nail.</p>
<p>With a healthy needs and ROI analysis, the &#8220;no code&#8221; approach should be the natural conclusion, not something you have to enforce.</p>
<p>For the record, &#8220;no code&#8221; is not necesssarily lighter than coding. For example, I do a lot of no code workflows myself in SharePoint Designer, involving loops and calculations, and I sometimes wish I had a developer to make this more straightforward.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Boot from Hyper-V image by avebb</title>
		<link>http://blog.pointbeyond.com/2009/12/24/boot-from-hyper-v-image/#comment-625</link>
		<dc:creator><![CDATA[avebb]]></dc:creator>
		<pubDate>Wed, 08 Feb 2012 05:23:18 +0000</pubDate>
		<guid isPermaLink="false">http://pointbeyond.wordpress.com/2009/12/24/boot-from-hyper-v-image/#comment-625</guid>
		<description><![CDATA[Hey. Thanks for this. Was looking for a way to boot from a hyper-v image and glad to find it in your post from 2 years back !

Also glad that the link from your post is still alive.]]></description>
		<content:encoded><![CDATA[<p>Hey. Thanks for this. Was looking for a way to boot from a hyper-v image and glad to find it in your post from 2 years back !</p>
<p>Also glad that the link from your post is still alive.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on The “No Code” SharePoint Strategy by Ian McNeice</title>
		<link>http://blog.pointbeyond.com/2012/01/31/the-no-code-sharepoint-strategy/#comment-618</link>
		<dc:creator><![CDATA[Ian McNeice]]></dc:creator>
		<pubDate>Wed, 01 Feb 2012 20:39:10 +0000</pubDate>
		<guid isPermaLink="false">http://blog.pointbeyond.com/?p=997#comment-618</guid>
		<description><![CDATA[100% agreed. The 750,000 developers worldwide frequently develop to justify their &#039;developer&#039; role - day one does not require these skills. I one met a client who had spend over £500k on a multi language portal - unaware that Variations even existed. Our Clients 95% of the time request avoidance of any heavy development in their overarching strategic approach to SharePoint. However also consider a parallel, complimentary approach - the future commoditisation of SharePoint where business solutions are pre-packaged and bought already complete, thus avoiding long-winded, ad hoc development with variable quality and unnecessary expense.]]></description>
		<content:encoded><![CDATA[<p>100% agreed. The 750,000 developers worldwide frequently develop to justify their &#8216;developer&#8217; role &#8211; day one does not require these skills. I one met a client who had spend over £500k on a multi language portal &#8211; unaware that Variations even existed. Our Clients 95% of the time request avoidance of any heavy development in their overarching strategic approach to SharePoint. However also consider a parallel, complimentary approach &#8211; the future commoditisation of SharePoint where business solutions are pre-packaged and bought already complete, thus avoiding long-winded, ad hoc development with variable quality and unnecessary expense.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on The “No Code” SharePoint Strategy by Christian Buckley</title>
		<link>http://blog.pointbeyond.com/2012/01/31/the-no-code-sharepoint-strategy/#comment-617</link>
		<dc:creator><![CDATA[Christian Buckley]]></dc:creator>
		<pubDate>Wed, 01 Feb 2012 15:55:59 +0000</pubDate>
		<guid isPermaLink="false">http://blog.pointbeyond.com/?p=997#comment-617</guid>
		<description><![CDATA[It&#039;s a fairly common mistake for people to zip past out-of-the-box functionality and go to customized solutions because they fail to understand what SharePoint can do. I agree with Nigel -- start small, and provide the basic requirements first. Once end users see what is possible, their requirements will change anyway, modifying their initial asks based on their new understanding of what is possible.

The other reason people jump to custom code is because there is a fundamental misunderstanding of how SharePoint works. A .Net developer does not equal a SharePoint developer. There is a learning curve to understand how to build within the SharePoint framework. Attack it like just another website, and you&#039;ll open up some serious pain down the road when you want to upgrade or modify your environment.]]></description>
		<content:encoded><![CDATA[<p>It&#8217;s a fairly common mistake for people to zip past out-of-the-box functionality and go to customized solutions because they fail to understand what SharePoint can do. I agree with Nigel &#8212; start small, and provide the basic requirements first. Once end users see what is possible, their requirements will change anyway, modifying their initial asks based on their new understanding of what is possible.</p>
<p>The other reason people jump to custom code is because there is a fundamental misunderstanding of how SharePoint works. A .Net developer does not equal a SharePoint developer. There is a learning curve to understand how to build within the SharePoint framework. Attack it like just another website, and you&#8217;ll open up some serious pain down the road when you want to upgrade or modify your environment.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Sites and lists not updating from the Content Type Hub by SimonWright-PointBeyond</title>
		<link>http://blog.pointbeyond.com/2011/08/31/sites-and-lists-not-updating-from-the-content-type-hub/#comment-616</link>
		<dc:creator><![CDATA[SimonWright-PointBeyond]]></dc:creator>
		<pubDate>Wed, 01 Feb 2012 15:47:27 +0000</pubDate>
		<guid isPermaLink="false">http://blog.pointbeyond.com/?p=699#comment-616</guid>
		<description><![CDATA[Hi Rick, sounds perplexing. Have content types ever updated correctly in document libraries? Also, what sort of updates are you trying to push from the CTH: A column name changes? Adding a new column? Deleting a column? Changing column data type?   ]]></description>
		<content:encoded><![CDATA[<p>Hi Rick, sounds perplexing. Have content types ever updated correctly in document libraries? Also, what sort of updates are you trying to push from the CTH: A column name changes? Adding a new column? Deleting a column? Changing column data type?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on The “No Code” SharePoint Strategy by SharePoint Security Mistakes; Browsers Without Plug-ins; Can Azure be Saved? - SharePoint Daily - Bamboo Nation</title>
		<link>http://blog.pointbeyond.com/2012/01/31/the-no-code-sharepoint-strategy/#comment-615</link>
		<dc:creator><![CDATA[SharePoint Security Mistakes; Browsers Without Plug-ins; Can Azure be Saved? - SharePoint Daily - Bamboo Nation]]></dc:creator>
		<pubDate>Wed, 01 Feb 2012 14:12:24 +0000</pubDate>
		<guid isPermaLink="false">http://blog.pointbeyond.com/?p=997#comment-615</guid>
		<description><![CDATA[[...] The &#8220;No Code&#8221; SharePoint Strategy (PointBeyond)For an initial deployment of SharePoint 2010 how about saying: &#8220;We will not do anything that involves custom code. We will restrict ourselves to what we can do with out-of-the-box SharePoint and associated tools&#8221; This is somewhat controversial. I can already hear rumblings of discontent from distant IT strategists. IT strategy should be derived from business strategy, right? An IT strategy should put in place systems and practices that support the business in achieving its objectives. If we say &#8220;we won&#8217;t do any custom code&#8221; this is surely a classic case of tail (technology) wagging dog (business). Why should the constraints of a technology be used to tell the business what they can and can&#8217;t have? [...]]]></description>
		<content:encoded><![CDATA[<p>[...] The &ldquo;No Code&rdquo; SharePoint Strategy (PointBeyond)For an initial deployment of SharePoint 2010 how about saying: &ldquo;We will not do anything that involves custom code. We will restrict ourselves to what we can do with out-of-the-box SharePoint and associated tools&rdquo; This is somewhat controversial. I can already hear rumblings of discontent from distant IT strategists. IT strategy should be derived from business strategy, right? An IT strategy should put in place systems and practices that support the business in achieving its objectives. If we say &ldquo;we won&rsquo;t do any custom code&rdquo; this is surely a classic case of tail (technology) wagging dog (business). Why should the constraints of a technology be used to tell the business what they can and can&rsquo;t have? [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on The “No Code” SharePoint Strategy by Tobias Lekman (@TobiasLekman)</title>
		<link>http://blog.pointbeyond.com/2012/01/31/the-no-code-sharepoint-strategy/#comment-614</link>
		<dc:creator><![CDATA[Tobias Lekman (@TobiasLekman)]]></dc:creator>
		<pubDate>Wed, 01 Feb 2012 06:44:12 +0000</pubDate>
		<guid isPermaLink="false">http://blog.pointbeyond.com/?p=997#comment-614</guid>
		<description><![CDATA[I agree - avoiding code solutions should definitely be the default behaviour for new users but should also be considered, as a standard practise, for each customization scenario during a larger project.

 I would also love to see documented justifications for choosing custom code solutions as part of the project documentation. Don&#039;t get me wrong - there are many scenarios where coding is required but I have seen an enormous amount of strange code to solve problems that SharePoint can handle perfectly well out-of-the-box.]]></description>
		<content:encoded><![CDATA[<p>I agree &#8211; avoiding code solutions should definitely be the default behaviour for new users but should also be considered, as a standard practise, for each customization scenario during a larger project.</p>
<p> I would also love to see documented justifications for choosing custom code solutions as part of the project documentation. Don&#8217;t get me wrong &#8211; there are many scenarios where coding is required but I have seen an enormous amount of strange code to solve problems that SharePoint can handle perfectly well out-of-the-box.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on The “No Code” SharePoint Strategy by Nigel Price</title>
		<link>http://blog.pointbeyond.com/2012/01/31/the-no-code-sharepoint-strategy/#comment-613</link>
		<dc:creator><![CDATA[Nigel Price]]></dc:creator>
		<pubDate>Tue, 31 Jan 2012 19:08:37 +0000</pubDate>
		<guid isPermaLink="false">http://blog.pointbeyond.com/?p=997#comment-613</guid>
		<description><![CDATA[This has to be the way to go. Get something out to the users quickly so they can see the benefits of SharePoint 2010.  Once the users are on board, then start worrying about custom code. I did a presentation at #spsuk called &quot;why do we develop - becuase we can ?&quot; which looked at some of the reasons why people start developing custom code from day 1.]]></description>
		<content:encoded><![CDATA[<p>This has to be the way to go. Get something out to the users quickly so they can see the benefits of SharePoint 2010.  Once the users are on board, then start worrying about custom code. I did a presentation at #spsuk called &#8220;why do we develop &#8211; becuase we can ?&#8221; which looked at some of the reasons why people start developing custom code from day 1.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on The “No Code” SharePoint Strategy by Ian Chivers</title>
		<link>http://blog.pointbeyond.com/2012/01/31/the-no-code-sharepoint-strategy/#comment-612</link>
		<dc:creator><![CDATA[Ian Chivers]]></dc:creator>
		<pubDate>Tue, 31 Jan 2012 17:25:52 +0000</pubDate>
		<guid isPermaLink="false">http://blog.pointbeyond.com/?p=997#comment-612</guid>
		<description><![CDATA[There are many ways to solve a business challenge in Sharepoint, custom code, Sharepoint Designer, Forms Service &amp; InfoPath, Workflows, etc.  The skill is in picking the right one to meet the immediate need and potential future enhancements.  I think new Sharepoint users would do well to avoid custom code until they have a good understanding of the out of the box capabilities.]]></description>
		<content:encoded><![CDATA[<p>There are many ways to solve a business challenge in Sharepoint, custom code, Sharepoint Designer, Forms Service &amp; InfoPath, Workflows, etc.  The skill is in picking the right one to meet the immediate need and potential future enhancements.  I think new Sharepoint users would do well to avoid custom code until they have a good understanding of the out of the box capabilities.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Finding Duplicate Documents in SharePoint using PowerShell by Brian Newman</title>
		<link>http://blog.pointbeyond.com/2011/08/24/finding-duplicate-documents-in-sharepoint-using-powershell/#comment-611</link>
		<dc:creator><![CDATA[Brian Newman]]></dc:creator>
		<pubDate>Thu, 26 Jan 2012 17:36:47 +0000</pubDate>
		<guid isPermaLink="false">http://blog.pointbeyond.com/?p=685#comment-611</guid>
		<description><![CDATA[I am concerned that the Birthday paradox might increase the odds of false positives (files that aren&#039;t duplicates appearing as duplicates).  I&#039;ve done something similar to what you&#039;ve done here (but I&#039;ve done it in C#), but I think after running this script, an additional step - bitwise comparison - is needed for all the results found using the MD5 hash approach.  The MD5 hash approach is a good way to reduce the number of files that need to be compared using the bitwise approach, but I don&#039;t think it should be the final step.]]></description>
		<content:encoded><![CDATA[<p>I am concerned that the Birthday paradox might increase the odds of false positives (files that aren&#8217;t duplicates appearing as duplicates).  I&#8217;ve done something similar to what you&#8217;ve done here (but I&#8217;ve done it in C#), but I think after running this script, an additional step &#8211; bitwise comparison &#8211; is needed for all the results found using the MD5 hash approach.  The MD5 hash approach is a good way to reduce the number of files that need to be compared using the bitwise approach, but I don&#8217;t think it should be the final step.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

