This blog has migrated to http://opletayev.wordpress.com/
I apologize for the inconvenience. WordPress is just much easier to work with for me.
Saturday, December 5, 2009
Google acquires AppJet team
Congratulations to AppJet and etherpad.com team!
EtherPad was a great product and it is nice to see the team being rewarded for their hard work. I wish they published more information on their AppJet engine, but it doesn't seem that it will ever happen.
What is interesting is that right after they announced the acquisition they immediately stopped accepting new customers and creating new free pads. It basically means that Google is not particularly interested in their customers or their user base. All they wanted was the team.
Or, maybe, they wanted to get a competitor product out of the market to clear up the way for Google Wave. But, nah, I mean, Google is not Evil and wouldn't throw money to shut down the competition, am I right? :)
EtherPad was a great product and it is nice to see the team being rewarded for their hard work. I wish they published more information on their AppJet engine, but it doesn't seem that it will ever happen.
What is interesting is that right after they announced the acquisition they immediately stopped accepting new customers and creating new free pads. It basically means that Google is not particularly interested in their customers or their user base. All they wanted was the team.
Or, maybe, they wanted to get a competitor product out of the market to clear up the way for Google Wave. But, nah, I mean, Google is not Evil and wouldn't throw money to shut down the competition, am I right? :)
Friday, December 4, 2009
Anemic Domain Model
Today I stumbled across a conversation about the Anemic Domain Model.
It sounds like a some sort of terrible disease. Martin Fowler blasted it as an anti-pattern. Wikipedia page states 1 benefit to 7 liabilities.
Even people that humor it tend to say it is limited to only inexperienced teams and small projects:
Jimmy Bogard writes:
Complex systems tend to require lots of configuration glue to keep them together. They are hard to learn and require developers to understand the whole thing before they can become fully productive. In the real world, complex projects tend to grow larger and more complex, original designers move on or move up, new features and entities keep being are added, and eventually such projects turn into a Katamari ball.
Anemic Data Model, on the other hand, means that you have very simple data objects (if they grow too big or too complex it's a sign that you need to split them) and a set of well defined interfaces for processing these objects. Instead of making your model more complex you separate components and make them interact using interfaces, shifting towards a loosely coupled model from a complex monolithic model.
It's a bit of an old Unix paradigm: make one component do one thing really well, define it's interface, interact with other components when you need to.
Loosely coupled projects are a lot easier to maintain, evolve, and scale. Simple data structures and simple interfaces allow for just that. If your project is getting too complex, figuring out how to simplify data structures and interfaces might be a better choice than working out a more complex data model.
P.S. This is one of the reasons why protocol buffer messages produced by proto-cs are declared as sealed. They are data messages, there is no need to inherit from them.
It sounds like a some sort of terrible disease. Martin Fowler blasted it as an anti-pattern. Wikipedia page states 1 benefit to 7 liabilities.
Even people that humor it tend to say it is limited to only inexperienced teams and small projects:
Jimmy Bogard writes:
Times when you can’t do a full domain model can include situations where you don’t have access to a domain expert, your team isn’t experienced with OO, or time constraints limit the conversations and analysis needed to build a decent domain model. If the domain isn’t complex, or is largely data-in, data-out, then those are contexts where a full domain model likely isn’t needed as well.Greg Yong writes:
Our domain is not extremely complex.... Our team is not highly functional in object oriented design and analysis. When I say this I mean that team members must be highly functional in order to attempt creating a domain model (all other attempts will be doomed to failure, likely as an anemic domain model).Sounds pretty bad, to be honest. Still, somehow I am not convinced. The reason I am not convinced is very simple: complexity. Look at the quotes above, they both mention ADM being not half as bad for "not so complex" domains. But do you really want to have your domains that complex?
Complex systems tend to require lots of configuration glue to keep them together. They are hard to learn and require developers to understand the whole thing before they can become fully productive. In the real world, complex projects tend to grow larger and more complex, original designers move on or move up, new features and entities keep being are added, and eventually such projects turn into a Katamari ball.
Anemic Data Model, on the other hand, means that you have very simple data objects (if they grow too big or too complex it's a sign that you need to split them) and a set of well defined interfaces for processing these objects. Instead of making your model more complex you separate components and make them interact using interfaces, shifting towards a loosely coupled model from a complex monolithic model.
It's a bit of an old Unix paradigm: make one component do one thing really well, define it's interface, interact with other components when you need to.
Loosely coupled projects are a lot easier to maintain, evolve, and scale. Simple data structures and simple interfaces allow for just that. If your project is getting too complex, figuring out how to simplify data structures and interfaces might be a better choice than working out a more complex data model.
P.S. This is one of the reasons why protocol buffer messages produced by proto-cs are declared as sealed. They are data messages, there is no need to inherit from them.
Wednesday, December 2, 2009
Dataflow Communcation Library v.1.4.0
Check out the new release of DCL:
http://dataflow-software.com
Features:
http://dataflow-software.com
Features:
- Google Protocol Buffers 2.2 compliant compiler for .NET
- Dataflow Protocol Buffer RPC (PBUF-RPC) implementation
- JSON and JSON RPC support
- AJAX support, automatically generate JavaScript needed for your web sites
- Silverlight support, access your data fast using PBUF RPC and JSON RPC
- Microsoft IIS HTTP API support, subscribe to HTTP requests from your standalone applications
- Cached#: a fast and free MemCached-inspired in-memory cache application
- Mono support for the client libraries
- Lightweight implementation (client DLL are under 100kb!)
- Lots of new docs and tutorials
Subscribe to:
Posts (Atom)
Posts
