Archive
Martin Fowler’s article on micro-services
Martin Fowler and James Lewis have an article on micro services here http://martinfowler.com/articles/microservices.html
Though my first reaction to it was, “what, isn’t this SOA”, the article itself had a sidebar which mentioned “service orientation done right”.
Worth a read, Excellent stuff as usual from thoughtworks folks.
To some extent, I felt Martin Fowler is taking an U-turn on
Hence, we get to my First Law of Distributed Object Design: Don’t distribute your objects!
How, then, do you effectively use multiple processors? In most cases the way to go is clustering (see Figure 7.2). Put all the classes into a single process and then run multiple copies of that process on the various nodes. That way each process uses local calls to get the job done and thus does things faster. You can also use fine-grained interfaces for all the classes within the process and thus get better maintainability with a simpler programming model.
Quote from Patterns of Enterprise Application Architecture (PoEAA) Chapter 7 Distribution Strategies.
Yes, yes,
- I am aware of the terms that Fowler uses here “Objects” – I always thought he used objects here in the sense of component objects / service objects – Earlier in this chapter he uses “With separate remote objects for customers, orders, products, and deliveries. Each one is a separate component that can be placed on a separate processing node.” So I believe he uses object in a broader sense in the First Law of Distributed Object Design.
- Granted today we have a faster network stack
- His argument about coarse grained interfaces was spot on.
- Also I understand the benefits that micro services brings.
I think, he that he should rewrite his Distribution Strategies Chapter in PoEAA to include the micro services alternative as well.
Your thoughts?
In search of a client-side templating solution
After a long time I am posting a technical entry. I am in search of non intrusive client-side templating solution. The following are the requirements
- Non intrusive Should not require something like
ko.observable, ko.mapping and then tableMetadataViewModel.name(), tableMetadataViewModel.name(‘Employees’)
Ember.Object.create, tableMetadataModel.get(‘name’), tableMetadataModel.set(‘name’, ‘Employees’)
The problem with these kind of solutions is that these solutions are no longer Plain Old JavaScript Objects. They introduce a tight coupling with the templating library / framework which is implicit.
- Is reactive / supports ‘Live Templates’ To Quote from Wikipedia
For example, in an imperative programming setting,
would mean that
is being assigned the result of
in the instant the expression is evaluated. Later, the values of
and
can be changed with no effect on the value of
In reactive programming, the value of
A modern spreadsheet program is an example of reactive programming. Spreadsheet cells can contain literal values, or formulas such as "=B1+C1" that are evaluated based on other cells. Whenever the value of the other cells change, the value of the formula is automatically updated.
In this specific context, when I update the name of the table object by setting an alias like
table.alias = ‘e’
It should automatically update in the UI.
- Two-way data-binding
when I update the name of the table object by setting an alias like
table.alias = ‘e’
It should automatically update in the UI.
And when I update the alias in the UI, it should update the object model.
- Model as the single-source source of truth In this specific context, when I update the name of the table object by setting an alias like
table.alias = ‘e’
All the places in the UI where table is rendered as a view should be updated.
Reactivity and Two-way data-binding go a long way in helping Model as the single source of truth.
- Modular
Supports defining templates in external files and plays nice with requirejs text plugin.
- Performs efficiently
Supports r.js optimizer & requirejs text plugin
For example splitting the application into small modules that have a single responsibility requires writing many modular templates. But i may result in poor performance if we make many calls to load them from the browser. Bundling them with the r.js optimizer for example can reduce this performance hit.
Granular re-rendering
Reactive templates should not mean the whole template is re-rendered every time model changes.
For example modifying an item, adding an item or deleting an item in a list should not re-render the whole template and instead just re-render / add / delete the concerned item nodes and the whole list or worse the whole template.
No dirty checking
- For example angularjs uses dirty checking that impacts the performance negatively.
Read this to see what I mean http://stackoverflow.com/a/18381836
- Plays nice with other legacy frameworks / libraries
Recently I tried my hand with Polymer Web Components Stack. I ran into a hard to identify issue. Finally the issue was joint.js(+jquery) which I was using in conjunction with polymer was walking the DOM tree and made an assumption that the root node is the document node. Which is not true when it comes to shadow dom.
- Fits well with Nicholas Zakas’s Scalable Application Architecture
Can I find the templating solution that fits well with Nicholas Zakas’s Scalable Application Architecture? Time has to tell.
http://www.youtube.com/watch?v=vXjVFPosQHw
object.observe, web components based?
- Some sort of a dom based templating solution based on object.observe on the modern browsers and an object.observe polyfill in other browsers which do not support object.observe should be good. But looks like knockout, ember etc are not taking up the object.observe route yet. May be I will end up forking knockout and implement one myself.
A build-time two-step transform view?
- http://martinfowler.com/eaaCatalog/twoStepView.html with one of the transforms / templating running at build-time may help support multiple template engines from a single template. But it will be really hard to build such a library.
- Taking a hard dependency on a single templating solution, esp. for a product does not seem right.
- Are there any adapters / abstractions available that help one switch templating solutions over the same Model?
- Any suggestions comments would be welcome.
Answer to my question, Are Shelves anti-CI?
A while ago a posted a blog entry on are shelves anti-CI. Martin Fowler’s entry today on Feature branches is very much related to some of the questions I had in mind.
http://sendhil.spaces.live.com/blog/cns!30862CF919BD131A!1318.entry
CRUD User Interfaces around entities Anti-Pattern
I am by no means an UI Design expert, but I am just blogging my current thoughts on the topic. Also this is my personal opinion (based on the limited experience I have) and I might change my opinion with time as I get to see better frameworks.
There is this school of thought “automagically generating user interfaces based on a model” (either the Domain Model or the Data Model). The most prominent examples which I had seen include
- A Business Application Platform which supports building a domain model on the fly and provides UI Design capabilities (e.g. Microsoft Dynamics CRM, Sharepoint). The UI is modeled as a projection of the business domain. You get Forms to Create and Update domain entities, Lists to View and Delete domain entities.
- A Framework which supports UI scaffolding. This may not be as bad as the previous one, since there may not be a notion of permanence here. I see this as an anti-pattern even in the prototyping stage as it might limit/bias the UI Designer’s / Developer’s ideas. Examples include Ruby on Rails Scaffolding, Subsonic Scaffold control, ASP.NET Dynamic Data. I know very well that these are good frameworks and do not recommend anyone to use the generated UI in production applications. Also, I am talking only about the automagically generated UI.
A custom application where you do not have an UI Designer and the developer decides to structure the UI design around the domain model / data model. The UI will provide forms to Create and Update, Grids to View and Delete domain entities.
This CRUD of entities based UI Design can be considered a leaky abstraction where the domain model (or worse data model) has leaked into the UI. The Worst part is that the end users of the system are forced to wriggle around their daily tasks using the provided User Interface. So if we do not structure our UI as CRUD of entities what should we structure them around?
User Interfaces should be designed around the tasks which the Users perform day to day. For example a task might include displaying / editing information from multiple entities. The same data can be visualized differently in a way it is the most intuitive to the users. So if you are thinking of building a Framework to automatically generate CRUD User Interfaces around entities understand the limitations it will impose on the end users of the system.
Agile & Engineering Practices
Continuing on the previous post about agile failures,
One of the core principles behind Agile Manifesto is “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.” Isn’t that the exact opposite what we were taught in Software Engineering 101 course, ‘the cost of change increases exponentially over the lifecycle of a project. The later the change is the harder it is to do’. But welcoming change and building in increments without having a Big Up Front Design means having a reasonable cost of change curve. It is enabled by
- Having a automated test suite which serves as a safety net for changing code
- Willingness to refactor & Refactoring
- Continuous Integration
- OOP and Following Good Design Practices
Automated Test Suite is a must and Refactoring & Continuous Integration are enabled by it. Without Refactoring the code quality decays continuously. Continuous Integration is what makes sure we have quality (potentially shippable) code in the source control system always. Violation of encapsulation will be costly when you change something. OOP and good design practices are more important in an agile project where you welcome change.
Most of the projects are pressed for time. So if testing follows code ‘automated test suite’ is never a possibility because coding time will eat into our automated test suite time. So agile proponents advise to do the tests first. This way no code can ship without being tested & without having the license to change.
No BDUF <> No Design
On one end of the spectrum is BDUF and on the other end is No Design. Agile design is about drawing a line in between in the right place. How do we identify the right place. Kent Beck’s criteria Simple Design is the best.
Fowler explains all of this very well in his paper Is Design Dead?
To sum up
- Having a automated test suite which serves as a safety net for changing code and doing tests first.
- Willingness to refactor & Refactoring
- Continuous Integration
- OOP and Following Good Design Practices
- Simple Design instead of No Design or Big Design Up Front
are Implied assumptions of Agile. If any one of those assumptions is ignored, it is going to hit back hard.
Further complications could be factors like distributed environment, not having an onsite customer, no pair programming. But then “Engineering is not about perfect solutions, It is about doing the best you can with Limited resources” (The Last Lecture – Randy Pausch).
End of the day it is not the framework / method which matters, it all boils down to people. In case you ignored all of these assumptions in the beginning (because you did not know them or thought they were not important) you could still come back on track if
- you have the right set of people in place who could identify these in your early retrospectives.
- you have a supporting management who understand development and is willing to pay off the technical debt in phased fashion.
Of course it will be hard, but not impossible.
Are TFS Shelves anti CI?
IMO, TFS shelves are kinda anti CI. I like the way Jeff Atwood and Jeremy Miller put it.
The golden rule of source control Check-in early, Check-in often
“It’s like putting milk out on the kitchen counter. A little while is fine, but too long leads to gross sour milk.” Not checking code in should make you feel unclean
I was searching the other day for what people think about Shelves/Shelvesets in TFS. I was hoping to find something along these lines. Since I couldn’t find one I thought I should start one. Again, this is strictly my personal opinion and you may not agree with it. I am open to hear any thoughts which suggest otherwise.
Fragile Tests
In the thoughtworks geek night yesterday there was a discussion on "Fragile Tests". There was a lot of discussion around the causes & solutions. At the end of the discussion there was no structured summary, which left me as confused as I was @ the beginning of the discussion. I thought of looking into it today in the xUnit Patterns book to clear my mind a bit on the topic.
From "xUnit Patterns"
Fragile Test: A test fails to compile or run when the system under test (SUT) is changed in ways that do not affect the part the test is exercising.
Trouble-shooting advice
Read more here
Microsoft Sync Framework
What is the Microsoft Sync Framework?
Microsoft Sync Framework is a comprehensive synchronization platform enabling collaboration and offline access for applications, services and devices. Developers can build sync ecosystems that integrate any application, any data from any store using any protocol over any network. With the Microsoft Sync Framework, developers can:
· Easily build collaboration and offline capabilities into new and existing applications, services, and devices
· Roam and share information in any data store, over any protocol, and in any network configuration
· Leverage sync capabilities exposed from Microsoft assets and platforms to boost productivity and performance
When will the Microsoft Sync Framework be available?
The Microsoft Sync Framework CTP1 will be available for download November 5th, 2007. The Microsoft Sync Framework will also be included within SQL Server 2008 as well as the next release of Visual Studio Orcas.
Performance Testing Guidance for Web Applications – P&P Guide
Think & Code
‘Think and code’ is better than ‘code & think’. Use agile techniques
- white board sketches (a jumpstart to your domain model)
- behavior driven development (if you do not have any idea of the specification you are coding against….@$%!&@!&#$&!#$$#!&$^)
so that you just do not jump into code and mess with something.
Sendhil's Cyber Home 