The authors explore the end-to-end argument for data communications systems range of functions via examples of wasted effort implementing  each function in the low level. With data delivery acknowledgments,  the "request for next message" is rarely useful; It would be more meaningful to have an acknowledgment from the target application, especially in a two-phase-commit situation. Data encryption shouldn't be done in the communications layer because then the subsystem has to manage keys, messages are in clear-text outside the communications layer, and the message authenticity still needs to be checked by the application. Applications can better detect duplicate messages that look different to the subsystem, e.g. retries. FIFO guarantees need a higher level mechanism to control ordering of messages from different sites. In transaction management, acknowledgment for a successful write can only be given by the application.

Background for this paper includes that for the DARPA paper.  Regarding system design, the paper starts from the idea that there is a boundary around a communication subsystem that interfaces between it and the rest of the system. The design problem is the choice of function implementation method. The "end-to-end argument" asserts the that correct function implementation occurs only with application knowledge at both ends, thus arguing against low-level implementation.

I liked the simplicity of this paper; its examples were real and motivating. The examples show why pushing functions to the application level are not only sensible, but necessary as well. I liked the description of the differing needs of the real-time conferencing voice audio and the digitized speech system. The distinction reemphasizes the reasoning behind the creation of UDP versus TCP as seen in the DARPA paper, enhancing the idea of modularity in layered systems.

In a few examples, some functionality in the communications layer was helpful for performance. It wasn't clear to me if the authors were suggesting that this functionality should be implemented to be used for all applications, or for all applications using a particular transport service. I would have liked to see a more general discussion of the tradeoff of using low-level functions.

><><><><><><><><><><><

Principles & Concepts

One of the challenges many CAD newbies complain about is that most high end CAD packages start with the assumption that the newbie is coming from a CAD background of some sort, most likely from a competittor program. With the growing confluence of design tools I have been commenting on here, this is more and more often not the case. That's why I'm going to start this discussion with the basic concepts and 'build' from there.

While there are various tutorials & guides online about configurations,  a discussion of the 'when' & 'why' -- even the what -- is not often covered.  Configurations are one of those features which, if you don't know about it, you might not even think to wonder about it, especially if you don't come from an engineering background. However, in many ways, the premise behind configurations is intimately linked to foundation engineering principles, including modularity, or modular design.

Let's use an example we're all familiar with -- computers. When IBM opened its PC architecture to other vendors, triggering the 'flood of the clones', this was a grand lesson in the +'s & -'s of modular design. The PC is an example of modular design:

• The core of a personal computer is the motherboard, which mounts the CPU, among other things. It is the nexus point coordinating all of the peripherals to function in unison, including             
  • Video card
  • Network card
  • Modem card(for some)
  • Sound card(most newer computers have integrated this into the mother board), etc.

As the indentation shows, the peripheral cards are subsidiary to the motherboard. Each type of peripheral is a component which fulfills a specific function needed by the systmem, and facilitated by the motherboard. It is worth noting as an aside that this "indentation" is a mode of representation which carries a specific meaning in engineering -- it is used in what we call an indentured parts list. It is a valuable documentation tool.

The PC is a good example of modularity because once IBM set the interconnect standards -- what sort of edge connectors did each card need to interface with the motherboard -- vendors then based their designs around this constraint. Parameters of size, including net component height were also important. What this meant was that it created a broad spectrum of vendors who chose a niche, an area of expertise, which became the basis of a subsidiary industry. There are now multimillion $ corporations who only build one type of peripheral, like ATI or NVIDIA who make video adapter cards. Each card is its own module. Because there are many types of video cards, even from the same manufacturer, each model corresponds to a 'configuration' in the context of our discussion. Obviously, you can have configuraitons within configurations, but let's look at some examples of this.

This simple drive assy can have a series of various configurations. For instance, there might be several configurations of the gear wheel alone, based on the number &/or size of teeth, the diameter of the wheel, and combinations of these. Each variation in a parameter of the wheel would constitute a configuration of the wheel AND the assembly. So, for example, a version of the assembly where the two wheels are of different sizes would also constitute a different set of configurations. This might be done to facilitate the use of the assembly in an application where the gear ratio needed to step down or step up in order to effectively engage the systems involved.

Seeing how this could impact this assembly, we can look at how configurations in the model facilitate these variations in the assembly.

In the above video, you can see that I already have created secondary configurations in the Gear Wheel part, the Gear-Shaft assembly, as well as the top assembly, Axial Example. In the video, follow as I switch between configurations in each model, and the resulting effect. This gives some insight into configurations. As stated, part of what this enables is a reduction in the number of models, and a simplification in the feature & assembly trees at the left.

One of the key aspects of this, which I will show in Part 2 later this week, is how you can control configurations as you create the part through the specification of which configuration a given sketch, sketch dimension or feature is intended to apply to. I will also discuss the use of design tables in creating & managing configurations.

Note II: "Scalability" here is used as the project size rather than problem size. I noticed that it was not the best choice of words.

I was listening a talk on google tech talks and this came up: This morning I was thinking modularity is key to simplicity at the office. As a developer I love modularity, especially if you are dealing with large scale projects involving tens of developers you appreciate the ability to take a piece of functionality and dig into it knowing it fits all together at some level.

A developer learns to appreciate the modulariy (either for scalability or for simplicity) but hopefully your software has some users, and users do not always makes the connection between lack of modularity and the pain he is facing. Since user has an easy way out (this software suck, let's uninstall) it is better someone walks him through the logic.

Modularity requires avoiding duplications in functionality. Simpler your modules are, or more specialized in their functionality, the better. However, users like short cuts. Yes I know that command is available there but can't we put a small button here too he says. Most of the time it is simple to add and developers like that. But then, can't we have that list box here too he says. It looks like it's becoming simple at first since number of clicks is getting less and less to perform a certain functionality with each click. But, short cuts start becoming duplicated or worse imitated functionalities since it is not always easy to be that much modular.

I thought about lego blocks this morning. Each block has a one and only one functionality (at least the ones I know). Success of lego comes from the way different blocks work together, not how much additional built-in functionality each block comes with.

...

Microsoft has recently released its long awaited composite application framework for WPF (http://www.codeplex.com/CompositeWPF). As a heavy user and a big fan of the original CAB/Smart Client framework I rushed to explore it. To say that I was impressed is to say nothing. The [patterns & practices] team has done a tremendous job. The first thing that amazed me is the quality of the supporting documentation: direct mentioning and in-depth discussion of patterns used and architectural  decisions made, extensive tutorials and walk-throughs on all major concepts, and very cool reference implementation. So I immersed myself in CompositeWPF implementation to figure out how it stands against its CAB predecessor. I was specifically interested to see what CAB’s deficiencies were addressed and what are the areas improved and polished. So I started from the very beginning…

At the core of the composite application framework lies dynamic discovery and dependency resolution of its modules. This article discusses dependency resolution implementation in the new framework, its limitations (in both new and original frameworks), and suggests the ways to overcome those limitations.

Problem

Some modules in composite application framework have dependencies. Some don’t. Dependent modules must load before the modules depending on them. This goal is achieved using dependency solver that ships with the framework. Individual module developers indicate their module’s direct dependencies using metadata. They don’t have to worry about full dependency chain, cyclic dependencies, etc. It is the job of module dependency solver. The solver that comes with Composite WPF does a nice job of resolving dependency chain, detecting cyclic dependencies, detecting missing modules, etc. But when it comes to modules that don’t specify explicit dependencies results may be not what you expect. Consider the following simple module configuration (provided in application’s app.config):

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="modules"
             type="Microsoft.Practices.Composite.Modularity.ModulesConfigurationSection, Microsoft.Practices.Composite"/>
  </configSections>
  <modules>
    <module assemblyFile="Modules/ModuleA.dll"
            moduleType="ModuleA.ModuleA"
            moduleName="ModuleA"/>
    <module assemblyFile="Modules/ModuleB.dll"
            moduleType="ModuleB.ModuleB"
            moduleName="ModuleB"/>
    <module assemblyFile="Modules/ModuleC.dll"
            moduleType="ModuleC.ModuleC"
            moduleName="ModuleC"/>
  </modules>
</configuration>

This configuration lists three modules in the following order: “ModuleA”, “ModuleB”," “ModuleC” and specifies no explicit dependencies. You may naturally expect that the framework will load the modules in this order. Unfortunately, it won’t. The implementation of the solver that ships with Composite WPF (the same applies to original CAB) gives no order guarantees for non-explicitly stated dependencies. Speaking in "sorting" terms resolution algorithm is not stable. In practical terms (due to the solver implementation details) it will exactly reverse the order. If you run “ConfigurationModularity” quick start that ships with the framework with the above shown configuration you can visually observe that modules are, in fact, loaded in reverse:

The only way to guarantee deterministic module load order is to explicitly state the dependency on the previous one for every module. Our configuration now becomes:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="modules"
             type="Microsoft.Practices.Composite.Modularity.ModulesConfigurationSection, Microsoft.Practices.Composite"/>
  </configSections>
  <modules>
    <module assemblyFile="Modules/ModuleA.dll"
            moduleType="ModuleA.ModuleA"
            moduleName="ModuleA"/>
    <module assemblyFile="Modules/ModuleB.dll"
            moduleType="ModuleB.ModuleB"
            moduleName="ModuleB">
      <dependencies>
        <dependency moduleName="ModuleA"/>
      </dependencies>
    </module>
    <module assemblyFile="Modules/ModuleC.dll"
            moduleType="ModuleC.ModuleC"
            moduleName="ModuleC">
      <dependencies>
        <dependency moduleName="ModuleB"/>
      </dependencies>
    </module>
  </modules>
</configuration>

If you compare this new configuration with our original one it is obvious that it has a lot of noise. In my opinion this is an overkill for a very simple task at hand. What’s missing is the concept of “implied order”. What we want is a dependency solver mechanism that keeps the relative order of modules intact, unless explicit dependency calls for order change.

Solution

Fortunately, Composite Application Library ships in source code and is well covered with unit tests. So I armed with debugger and dove in. As it turned out the task of dependency resolution is very well abstracted from module discovery and concentrated in a single class: ModuleDependencySolver.cs (in Modularity folder). Moreover, dependency resolution logic itself is fully contained in its public Solve() method. All I needed to do is to rewrite rather simplistic existing implementation, verify that all existing tests still pass, and add a bunch of new tests that verify the relative order preservation for modules with no explicitly stated dependencies. My implementation uses two passes (versus multiple passes in the out-of-the-box implementation) through the module list: one to resolve the dependencies and one to check for cycles and missing modules. This is a full listing of my Solve method implementation:

public string[] Solve()
{
 LinkedList<string> result = SolvePass();
 ValidationPass(result);

 return result.ToArray();
}

private LinkedList<string> SolvePass()
{
 LinkedList<string> result = new LinkedList<string>();

 foreach (var module in dependencyMatrix.Keys)
 {
  var node = result.First;
  while (node != null)
  {
   if (dependencyMatrix[module].Contains(node.Value))
    break;
   node = node.Next;
  }

  if (node == null)
   result.AddLast(module);
  else
   result.AddBefore(node, module);
 }
 return result;
}

private void ValidationPass(LinkedList<string> result)
{
 for (var node = result.First; node != null; node = node.Next)
 {
  string module = node.Value;

  for (var next = node; next != null; next = next.Next)
  {
   if (dependencyMatrix[next.Value].Contains(module))
    throw new CyclicDependencyFoundException();
  }
 }

 string[] missing = result.Except(knownModules).ToArray();
 if (missing.Length > 0)
 {
  throw new ModuleLoadException(
   String.Format(CultureInfo.CurrentCulture,
    Resources.DependencyOnMissingModule,
    string.Join(", ", missing)));
 }
}

These are additional unit tests to complement the out-of-the-box ones and verify implied order preservation:

[TestMethod]
public void Solve_preserves_independent_modules_order()
{
 // Arrange
 solver.AddModule("ModuleA");
 solver.AddModule("ModuleB");
 solver.AddModule("ModuleC");

 // Act
 string[] actual = solver.Solve();

 // Assert
 CollectionAssert.AreEqual(  new string[] {  "ModuleA", "ModuleB", "ModuleC" },  actual);
}

[TestMethod]
public void Solve_solves_simple_dependency_and_preserves_independent_modules()
{
 // Arrange
 solver.AddModule("ModuleA");
 solver.AddDependency("ModuleA", "ModuleB");
 solver.AddModule("ModuleB");
 solver.AddModule("ModuleC");

 // Act
 string[] actual = solver.Solve();

 // Assert
 CollectionAssert.AreEqual(  new string[] { "ModuleB", "ModuleA", "ModuleC" },  actual);
}

[TestMethod]
public void Solve_solves_complex_dependency_and_preserves_independent_modules()
{
 // Arrange
 solver.AddModule("ModuleFirst");
 solver.AddModule("ModuleA");
 solver.AddDependency("ModuleA", "ModuleB");
 solver.AddModule("ModuleB");
 solver.AddDependency("ModuleB", "ModuleC");
 solver.AddModule("ModuleC");
 solver.AddModule("ModuleLast");

 // Act
 string[] actual = solver.Solve();

 // Assert
 CollectionAssert.AreEqual(  new string[] { "ModuleFirst", "ModuleC", "ModuleB", "ModuleA", "ModuleLast" },  actual);
}

Conclusion

If default solver implementation and its lack of “implied order” concept bothers you, you can easily overcome this by modifying the Solve() method in ModuleDependencySolver. I’m going to submit this as an issue for the Composite WPF team to consider and will update the blog with the issue link. It will be great if they agree to amend their current implementation. Even better if they can treat dependency solver like any other service: define an interface (IModuleDependencySolver) and publish its out-of-the-box implementation to DI container. This way applications have a chance to replace default solver implementation with their own without having to modify any original framework code.

If anyone feels that this sounds interesting Im thinking of maybe selling this circuits after I have tested it out. Please contact me if there is any questions.

Take a look at the pine cone. What do you see?

My first assignment was to study pine cones. Pretty random and complex structure it seems?

No kidding, pine cones actually display the Fibonacci sequence in their structures! (This might help you understand the structure more clearly.) Every system you see is composed of a simpler system or a series of simpler systems. The degree of complexity is build up through different grouping combinations of many such simple systems, even the pine cones. And there is no limit to the size of the system. It can keep growing infinitely, without losing its aesthetic and functional values. That is the power of modularity.

How can modularity be applied to product design?

Taking a simple surge protector as an example. Two months ago, I found out about Powramid, a UFO-looking surge protector that not only resolved the issue of clustered plugs on traditional surge protectors but also redefined the aesthetic standards of what surge protectors could look like. The product design is clearly innovative, but only temporal. A Powramid can take up to 6 plugs. What happens when you have to power more than 6 appliances? You'll need an extension strip that you plug into the Powramid and it goes on when your work station grows larger. Rather nasty in terms of the looks and all the cables crossing over each other and entangling. I use about 9-10 sockets at home at all times: Monitor, CPU, 2 external hard-drives, external DVD-burner, speakers, USB-ports hub, cellphone/digital camera charger, desk lamp.

E-rope Modular Power Strip

The E-rope is an IDEA (International Design Excellence Awards) Bronze winner in 2006. Although it is only a design project, the concept of taking a power socket module and multiplying it to grow into a power strip really creates a flexible solution to fit different power needs. Whether it's 4 sockets or 12 sockets, big plugs or small plugs, E-rope is completely customizable. Imagine each little unit is a surge protector itself...

A lot still needs to be refined when taking this design concept into actuality. Such as considering the amount of space required when more than a dozen modules wriggle out from the wall socket. And how realistic it is for cables to be coming in from different directions? What about the space in between when the strip makes a corner? By connecting the modules in series, it means that when one plug is switched off, the rest in line would be off too. What if I want to switch off some, but keep others powered? Can the modules be modified so that they can be connected in parallel?

Eubiq Power Outlet System

Perhaps it's not too difficult to realize a modularize and practical power strip design. The Eubiq Power Outlet System is an example and can be an architectural solution for modern homes, where you can have sockets anywhere you want and exactly where you wanted it. Just watch the demo. Really cool. Seriously, turn this into a Power Protection Outlet System and future homes could automatically enjoy the benefits of reliable power usage. Might be a bit costly to re-install it throughout the house when it's time to change the protector, but c'mon.. everything needs to be built-in nowadays! Houses are no exceptions. :D

The Quiroga studies have re-iterated the debate (if it ever went dead) about how specific the neural coding is in the brain. Is it really so that the brain has such a specific code that one cell can represent one percept? Do we have a grandmother cell, a President Nixon cell and Marilyn Monroe cell?

Today, there is wide agreement that the one-cell-one-percept idea is untenable and unsupported by the literature. Rather than cingle cells, we see that networks represent a percept, rather than single cells. However, the findings by Quiroga et al. have nevertheless stunned the scientific (and global) community with regard to just how specific the neural code can be, and that it can be detected in a single neuron. The findings that we can record how one single neuron responds to one, and only one, percept, is quite surprising.

So forget about the grandmother cell, right? Or maybe not. After all, following the idea from these findings, we should not be surprised that there would in fact be one neuron that responded preferentially to our grandmother. Yes, it would be an expression of a "network code" representing our grandmothers as such, but nevertheless, you may in fact have that one neuron that responds to ol' granny.

While we leave it at that, it is still surprising that this team of researchers use the term "medial temporal lobe" (or MTL for short). Why doe they say that there is sparse coding in the MTL? It's a rather big region, and a region packed with qualitatively different regions. Not only are these regions different anatomically, but also functionally, they are thought to be involved in different functions. The perirhinal cortex is involved in processing (and encoding) of complex visual objects as well as novelty processing and working memory, the (posterior) parahippocampal cortex is involved in spatial processing (remember the parahippocampal place area). The entorhinal cortex has a medial and lateral part that deal with spatial and object information, respectively. And in addition to the hippocampus and amygdala, with their quite different functions, we may extend the MTL concept to include the temporopolar cortex, and maybe even the inferotemporal cortex.

Where in this complex system do Quiroga et al. find their sparse coding? Everywhere? My bet is on the perirhinal cortex due to its involvement in complex visual object processing. I've come to know that the researchers have not had structural scans available to determine the exact location of their electrodes. The scans have obviously been made, but they have not been able to use that information (hush hush, don't tell anyone...).

So, while these studies are indeed important to our understanding of the coding of specific information, we're left with a huge gap in terms of their anatomical properties. While most of the research community focuses on MTL subdivisions to an increasing extent, it is a bit puzzling to me that nobody have ever criticised these studies for their sparsity of anatomical information. Maybe I'll be the first?

-Thomas

In computer science, modularity is the property of computer programs that measures the extent to which they have been composed out of separate parts called modules.

ZeroRatio:

In computer science, modularity... holy shit, I want that phone.