<?xml version="1.0" encoding="UTF-8"?>
<!--Generated by Squarespace Site Server v5.11.81 (http://www.squarespace.com/) on Wed, 08 Feb 2012 10:17:49 GMT--><?xml-stylesheet type="text/css" href="/universal/styles/feed.css"?><rss version="2.0"><channel><title>Journal - Comments</title><link>http://abdullin.com/journal/</link><description>CQRS, cloud computing and enterprise development made simple - articles, practical tips and learning references</description><copyright></copyright><language>en-US</language><generator>Squarespace Site Server v5.11.81 (http://www.squarespace.com/)</generator><item><title>Rinat Abdullin comments on Make Code Explicit and Stupid</title><author>Rinat Abdullin</author><pubDate>Tue, 07 Feb 2012 11:08:10 +0000</pubDate><link>http://abdullin.com/journal/2012/2/6/make-code-explicit-and-stupid.html#comments</link><guid isPermaLink="false">287483:2929700:comment/16805662</guid><description><![CDATA[<p>David, </p><p>this post of mine is obviously biased by the environment I&#39;m working in (somewhat similar to 37 signals). I&#39;m dealing with projects that are owned by a few developers that also handle deployment to hundreds of machines and maintenance. There is no separation between deployers and developers (it would be too costly in such environment).</p>]]></description></item><item><title>Rinat Abdullin comments on Architectural Principle - Focus on Simplicity</title><author>Rinat Abdullin</author><pubDate>Tue, 07 Feb 2012 11:00:43 +0000</pubDate><link>http://abdullin.com/journal/2012/2/2/architectural-principle-focus-on-simplicity.html#comments</link><guid isPermaLink="false">287483:2929700:comment/16805648</guid><description><![CDATA[<p>Alan, I&#39;m sorry for not making this explicit. </p><p>I don&#39;t argue about getting rid of all dependencies, I&#39;m just suggesting to factor in complexity and friction they bring, while making build vs. make decision, while steering towards overall simplicity and efficiency, if possible.</p>]]></description></item><item><title>David Schmitt comments on Make Code Explicit and Stupid</title><author>David Schmitt</author><pubDate>Tue, 07 Feb 2012 10:48:24 +0000</pubDate><link>http://abdullin.com/journal/2012/2/6/make-code-explicit-and-stupid.html#comments</link><guid isPermaLink="false">287483:2929700:comment/16805620</guid><description><![CDATA[<p>Because the deployer is not the developer and doesn&#39;t have the same infrastructure/skills available?</p><p>I do understand that this is a completely different situation to a hosted solution.</p>]]></description></item><item><title>Alan Franzoni comments on Architectural Principle - Focus on Simplicity</title><author>Alan Franzoni</author><pubDate>Tue, 07 Feb 2012 10:21:08 +0000</pubDate><link>http://abdullin.com/journal/2012/2/2/architectural-principle-focus-on-simplicity.html#comments</link><guid isPermaLink="false">287483:2929700:comment/16805556</guid><description><![CDATA[<p>Of course just every additional piece - be it a dependency, a library,  a framework - increases complexity, and must be understood, and its bugs must be coped with.</p><p>So you&#39;re basically saying &quot;if you can afford writing it by yourself, even though it&#39;s a stripped down edition, write your own&quot;.</p><p>It might be the right approach indeed, but sometimes rolling your own version comes with its own bag of caveat and bugs. It really depends on whether your team is more skilled or less skilled than the team that builds your external dependency.</p><p>I&#39;ve seen teams that would better just use external deps and write as little code as possible :-)</p>]]></description></item><item><title>Rinat Abdullin comments on Make Code Explicit and Stupid</title><author>Rinat Abdullin</author><pubDate>Mon, 06 Feb 2012 19:00:56 +0000</pubDate><link>http://abdullin.com/journal/2012/2/6/make-code-explicit-and-stupid.html#comments</link><guid isPermaLink="false">287483:2929700:comment/16799120</guid><description><![CDATA[<p>David, why would you need anything more complex than dynamic initialization, when it takes just a few minutes to change static code and have it deployed across hundreds of machines?</p><p>NB: I used to be Autofac contributor :)</p>]]></description></item><item><title>David Schmitt comments on Make Code Explicit and Stupid</title><author>David Schmitt</author><pubDate>Mon, 06 Feb 2012 18:40:28 +0000</pubDate><link>http://abdullin.com/journal/2012/2/6/make-code-explicit-and-stupid.html#comments</link><guid isPermaLink="false">287483:2929700:comment/16799026</guid><description><![CDATA[<p>I know you&#39;re not a fan of IoC/DI stuff, but I&#39;d still say that using a container library like autofac leads to more declaration and less code than coding it locally.</p><p>I have to admit though, that autofac would be no improvement over the second version, if you only need static initialisation and VS is your configuration editor.</p>]]></description></item><item><title>Rinat Abdullin comments on People Don't Think in Tables</title><author>Rinat Abdullin</author><pubDate>Mon, 06 Feb 2012 15:43:15 +0000</pubDate><link>http://abdullin.com/journal/2012/2/5/people-dont-think-in-tables.html#comments</link><guid isPermaLink="false">287483:2929700:comment/16797751</guid><description><![CDATA[<p>BlockBlobs for documents (views and states), page blobs for event stores, block blobs for immutable large objects for data crunching.</p>]]></description></item><item><title>Jonathan Oliver comments on People Don't Think in Tables</title><author>Jonathan Oliver</author><pubDate>Mon, 06 Feb 2012 12:48:47 +0000</pubDate><link>http://abdullin.com/journal/2012/2/5/people-dont-think-in-tables.html#comments</link><guid isPermaLink="false">287483:2929700:comment/16796997</guid><description><![CDATA[<p>Are you guys using block blobs or page blobs for this?</p>]]></description></item><item><title>Rinat Abdullin comments on Architectural Principle - Focus on Simplicity</title><author>Rinat Abdullin</author><pubDate>Sun, 05 Feb 2012 10:41:43 +0000</pubDate><link>http://abdullin.com/journal/2012/2/2/architectural-principle-focus-on-simplicity.html#comments</link><guid isPermaLink="false">287483:2929700:comment/16788135</guid><description><![CDATA[<p>Jonathan, I was a major fan of Autofac for this same reason. Then (mostly by reading Ayende and Jeremie) I&#39;ve learned out how to replace IoC with a simple and more clear code. Components stayed almost the same, but relationships became more explicit and surprisingly LOC counts dropped.</p><p>People say that discarding container was a major improvement and simplification in Lokad.CQRS. NB: I still see it&#39;s use for MEF-like functionality.</p><p>Re view models: not even table storage, just blobs for now (files for non-Azure). Requires reshaping client context and leads to facebook-like UIs.</p>]]></description></item><item><title>Jonathan Oliver comments on Architectural Principle - Focus on Simplicity</title><author>Jonathan Oliver</author><pubDate>Sat, 04 Feb 2012 20:24:34 +0000</pubDate><link>http://abdullin.com/journal/2012/2/2/architectural-principle-focus-on-simplicity.html#comments</link><guid isPermaLink="false">287483:2929700:comment/16783048</guid><description><![CDATA[<p>I&#39;m gonna push back a little biit is the IoC container reference.  While I completely agree that most people badly abuse and misuse IoC containers and, in fact, treat them like service locators, I still think IoC has a place.</p><p>In our environment, we have IoC pushed into a corner where it only helps with component wireup.  Beyond that, it never reaches anywhere in the architecture.  Specifically, nothing has a dependency on the IoC container.</p><p>Furthermore, another *huge* advantage to an IoC container, like Autofac, is deterministic disposal.  The idea is that resource disposal is handled by the container at each unit of work and then during process shutdown to have a nice, clean application exit.</p><p>I also have to ask, are you just using Azure Tables/Blobs now for your storage? Or do you have any other persistence engine for your your view models?</p>]]></description></item></channel></rss>
