Architecture, Design & Strategy - Latest Comments

Eli Weinstock-Herman (tarwn) [Member] in response to: Scalability is Easy! (To Get Wrong)

Eli Weinstock-Herman (tarwn) [Member] — Thu, 06 Dec 2012 14:41:37 +0000

Voodoo Child: Been there :)

The whole reason I wrote a simulator for these scenarios was because having conversations about scaling tend to devolve into a lot of hand waving. I'm going to do a couple more posts and post up the code so when people are in similar situations they can at least run some scenarios and make some pretty graphs in excel to bring to the conversation :)

Voodoo Child [Visitor] in response to: Scalability is Easy! (To Get Wrong)

Voodoo Child [Visitor] — Thu, 06 Dec 2012 12:20:08 +0000

The real fun starts when you inherit a critical system which is in serious need of *right* scaling yesterday while too much *wrong* scaling already has been implemented.

Baseline? Numbers? Right after a documented system design.......

"I didn't mean to take up all your sweet time, I'll give it right back to ya one of these days" - Jimmy Hendrix (I suspect he designed the system I'm working on)

Eli Weinstock-Herman (tarwn) [Member] in response to: Scalability is Easy! (To Get Wrong)

Eli Weinstock-Herman (tarwn) [Member] — Wed, 05 Dec 2012 15:05:53 +0000

Absolutely, unfortunately that's not obvious to the people that skip the baseline. I've seen a number of developers that had a tendency to make a logical leap from "I code good" to "my code makes the system faster/better/strong/smarter", which made performing a baseline seem redundant and/or wasteful.

Which is doubly unfortunate, since my anecdotal experiences have shown a strong correlation between skipping the baseline and poor optimization.

SQLDenis [Member] in response to: Scalability is Easy! (To Get Wrong)

SQLDenis [Member] — Wed, 05 Dec 2012 13:23:08 +0000

Without a baseline and numbers it basically becomes voodoo

Giorgi [Visitor] in response to: Model-View-Presenter: Looking at Passive View

Giorgi [Visitor] — Wed, 28 Nov 2012 08:25:21 +0000

Hi,

Isn't there any tool that would generate all the necessary code? The common functionality could be hidden in base classes but some code needs to be written again and again, and that's not quite "cool" :)

Alex Ullrich [Member] in response to: Getting Flexible With NDepend 4 and CQLinq

Alex Ullrich [Member] — Wed, 06 Jun 2012 13:03:29 +0000

I can't say it was trivial (though our full build was pretty involved, took ~25 minutes if we were generating an MSI) but it was *much* faster than the visual studio architecture analysis (and provided much more information). We used a separate build configuration for architecture validation that ran around 2am, mostly because we first tried using the tremendously slow visual studio tool and didn't want each build taking 45 minutes.

The codebase in question was probably between half and three-quarters of a million lines split into 30+ projects. I never saw an ad-hoc analysis take more than 2-2 1/2 minutes and this was running on our spare machines that were *very* underpowered. I would expect it ran much faster than that on our build server, and that NDepend 4 would be at least incrementally faster than 3.

Eli Weinstock-Herman (tarwn) [Member] in response to: Getting Flexible With NDepend 4 and CQLinq

Eli Weinstock-Herman (tarwn) [Member] — Wed, 06 Jun 2012 12:36:05 +0000

How much of an impact did running NDepend have on your overall build time? I've played with it in the past, but only as manual runs.

Hari Subramaniam [Visitor] in response to: The law of demeter

Hari Subramaniam [Visitor] — Mon, 01 Aug 2011 09:08:48 +0000

I wonder why LoD isnt applicable for Fluent interfaces?

Eli Weinstock-Herman (tarwn) [Member] in response to: Model-View-Presenter: Looking at Passive View

Eli Weinstock-Herman (tarwn) [Member] — Fri, 20 May 2011 08:25:25 +0000

Funny, my issue with MVC is that it is so data entity specific that I felt it could only handle a subset of interfaces compared to something like MVP or MVVM, perhaps it depends on our perspective a bit.

I'm having difficulty understanding why we would need a dynamic number of rows in the dialog when we are editing the equivalent of a record in the database with a given number of columns. Ignoring that, though, I believe what I would do in this situation is pass a an ordered key/value set to the view property that drives the dialog. That way the dialog can dynamically build the proper number of rows to edit my object.

The major difference between Passive View and MVC model->view communications is that in MVC the controller handles input from the user, but the view retrieves the data to display as output. In Passive View the same decision logic occurs, but handling the input and retrieving the output to display both happen in the Presenter. MVC's view is smarter, but the view exposed in Passive View can easily be implemented by a number of interfaces (json, web service, test class) and a greater portion of the logic is now unit testable.

Oliver Watkins [Visitor] in response to: Model-View-Presenter: Looking at Passive View

Oliver Watkins [Visitor] — Fri, 20 May 2011 06:08:38 +0000

Hi,

I have some issues to take up with the MVP pattern. MVP seems to be a valid architecture for only simple GUI interfaces.

The fact that the model is completely seperated from the view brings up some problems that seem impossible to solve without going back to MVC.

Consider : I have a table with X columns. I now want to build a component that is a dialog where I can edit the values in the table. In this dialog I want to have X rows (a label and text field), where I can perform editing, close it, then the table updates.

The problem is, the View needs to know about the model in order to generate the correct number of rows. There is no way to do this without the view knowing about the model.. we could create some intermediary 'model-proxy', but then we are really fluffing things up.