<rss version="2.0" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/"><channel><title>AppTheory</title><link>http://www.apptheory.com</link><description>RSS feeds for AppTheory</description><ttl>60</ttl><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/490/Know-Your-Deployment-Environment.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=490</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=490&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Know Your Deployment Environment</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/490/Know-Your-Deployment-Environment.aspx</link><description>In general there are lots of ways to design an application. There are many factors that play into to these choices and deployment environment is just one factor. A good example of this is a recent project in which the client needed video transcoding and cdn upload functionality. If the client had been using a shared hosting plan or did not have control of the server a DotNetNuke Scheduled task would be ideal. However, in this case we knew the client had dedicated private servers that they would be deploying this functionality to. This was a key factor in a design decision to create windows services to handle this functionality instead of using a DNN scheduled task. This gives us a bit of insulation in terms of memroy and cpu consumption since it is being run outside of the IIS arena. It also ensures a large degree of modularity. This is exactly why you should ask about deployment environment BEFORE spec’ing the project.</description><dc:creator>Scott Schecter</dc:creator><pubDate>Tue, 25 Aug 2009 20:47:02 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:490</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/202/Best-Practices-Development-Team-Collaboration-and-DotNetNuke-Part-3-The-References-amp-Project-Structure.aspx#Comments</comments><slash:comments>3</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=202</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=202&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Best Practices: Development Team Collaboration and DotNetNuke (Part 3: The References &amp;amp; Project Structure)</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/202/Best-Practices-Development-Team-Collaboration-and-DotNetNuke-Part-3-The-References-amp-Project-Structure.aspx</link><description>This is a continuation of the "Best Practices: Development Team Collaboration and DotNetNuke" multi-part series of blogs. If you have not read Part 1: The Development Environment, Part 2: The SqlDataProvider Files, you may wish to do so before reading this entry. The second installment covered not only the actual SqlDataProvider files, it also covered how to use those files to keep database structure synchronized for all developers collaborating on a project. This installment will cover some basic project structure, primarily focused on the WAP project structure, and also how to manage references for your team collaborating on a single project.</description><dc:creator>Chris Paterra</dc:creator><pubDate>Tue, 23 Sep 2008 10:25:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:202</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/180/Best-Practices-Development-Team-Collaboration-and-DotNetNuke-Part-2-The-SqlDataProvider-Files.aspx#Comments</comments><slash:comments>1</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=180</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=180&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Best Practices: Development Team Collaboration and DotNetNuke (Part 2: The SqlDataProvider Files)</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/180/Best-Practices-Development-Team-Collaboration-and-DotNetNuke-Part-2-The-SqlDataProvider-Files.aspx</link><description>This is a continuation of the "Best Practices: Development Team Collaboration and DotNetNuke" multi-part series of blogs. If you have not read Part 1: The Development Environment, you may wish to do so before reading this entry. The first installment not only covers the development environment setup, it also covers some target audience things you may wish to review as well before diving into this post. This installment is dedicated to database structure changes using the SqlDataProvider files.</description><dc:creator>Chris Paterra</dc:creator><pubDate>Wed, 17 Sep 2008 05:19:36 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:180</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/140/Best-Practices-Development-Team-Collaboration-and-DotNetNuke-Part-1-The-Development-Environment.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=140</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=140&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Best Practices: Development Team Collaboration and DotNetNuke (Part 1: The Development Environment)</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/140/Best-Practices-Development-Team-Collaboration-and-DotNetNuke-Part-1-The-Development-Environment.aspx</link><description>The majority of developers who see this blog are probably use to collaborating with other developers on projects. However, many developers who have spent only a limited amount of time on DotNetNuke development may find the process somewhat overwhelming. This is because even though DotNetNuke is an ASP.NET application, it is a specific framework with its own API. As with other frameworks, sometimes only experience or the view point of someone with experience can permit you to identify common problems before they occur. While the team here at AppTheory cannot say we have seen it all, as something new always pops up, we have plenty of experience with development team collaboration and DotNetNuke. In an effort to share some of our experiences, I have put together some of best practices we find vital to a successful project.</description><dc:creator>Chris Paterra</dc:creator><pubDate>Sun, 24 Aug 2008 21:59:06 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:140</guid></item></channel></rss>