I have been reading about event processing, message driven architecture and queuing for more than a year now. I think I have had some eureka moments already and got a fairly good understanding of it, but unfortunately I still have not found a truly awesome book on the subject.
I am very happy to share my first-ever screencast.
Screencast is about my open source project called phpProxyBuilder. It is a PHP library aimed at code reuse and promotion of proxy design pattern in PHP. It is heavily inspired by AOP and helps to implement cross-cutting concerns once and reuse the same code forever. It also promotes some of my favourite design principles like decoupling, testability, single responsibility and code reuse.
I wanted to create some screencasts for a while but I found it difficult to get the right tools. Fortunately screencasting and video editing are much easier on linux now and i hope to share more screencasts about PHP, open source and software design in the future :)
Patterns of Enterprise Application Architecture by Martin Fowler was not exactly as i imagined. First of all it was written in early 2000s and you can feel that it got a little bit outdated. Back in 2003 I am sure it was a really great source of patterns and best practices but from current perspective it may be a bit less relevant.
The book has some really good parts and I think every engineer would benefit from skimming through it. Way too often I see engineers with huge haps in important areas as concurrency, distributed systems, decoupling etc. I think there is still quite a lot of relevant knowledge in the book.
First of all i would be lying if i said that i did not like RabbitMQ :) It is a pretty cool piece of software. Having said that, i could be a bit biased in favor of the technology but i will try my best to be objective here.
RabbitMQ in Action is a really nice book. I think Alvaro Videla and Jason Williams did very good job at describing how to use and leverage RabbitMQ in your web applications.
While working with legacy applications and inherently dirty code you have to find creative ways to make things better. Rewriting / major re-factoring are usually not an option as team does not get enough time to do even basic housekeeping, what do you do then?
I have seen sphagetti code way too many times in my life not to call it an anti pattern. One of the main reasons for sphagetti code is allowing any object in the codebase to talk to any other object. In addition it comes hand in hand with usage of global/static scope and leaking information between application layers.
I recently realised that i have been applying the same pattern for a while now. The pattern i propose is an effort to cluster ugliness and relief rest of the code-base from exploding dependencies.
I have been thinking a bit recently how to manage dependencies and how to structure Zend Framework based applications to make the code less coupled, more testable and less dependent on the global scope.
I don't mean to be negative but I am not too happy about the web application structure that most articles and books present. In Zend Framework world controller seems to be the place when things get done. Controller is the workhorse and this is where all the logic seems to be buried. It also seems to me that model in MVC is reduced to database integration but there is no services layer for some reason. Where ever you look you will see the same examples with controller doing all the work and models being simple Zend_Db_Table or Zend_Db_Table_Row instances. You will not see business logic focused classes, Controller or DB Model, thats all you can choose from.
I saw a post recently and it got me thinking, should constructor of a child class follow the signature of its parent? My gut feeling was telling me it should not really matter. Constructor is not part of the Interface nor part of the public API that object exposes (not a class).
On the other hand i like the rule of least surprise and I like to have arguments in same order across the API (if it makes sense).
Author suggests that it is a good idea to use same arguments lists in exceptions derived from \Exception. I don't really think its a bad idea i am just wondering does it have anything to do with inheritance as the article suggests (i think the argumentation is not very accurate in this case).
To make it short and clear, I liked the book a lot. From a very begining it is clear that author has a vast experience in software design and development.
There are a few bits that really stand out.
First of all I loved the chapter showin pair programming and minimal effort principles. It is really fun to read and shows some very interesting observations.
After many years of reading references to it, i finally read Design Patterns by the famous Gang Of Four (GOF). Book is probably one of the most quoted and refereed IT books ever :-). Many of the articles I have read, that referred to the book, were really badly written. In most cases I had a feeling that authors did not understand design patterns at all. As a result my impression was that book has to be poor as well and does not do good job explaining patterns. This made me think that book has to be horrible if so many people write these vague and confusing articles referring to the GOF book itself.
I have had this discussion like a dozen times already so I thought I could write it all down.
In many cases it is not that big deal. The problem is that people seem to be blind and ignore the fact that accessors can cause design issues. Its more about principles and overall rules. You wont get swine flu and die if you keep on using getters and setters. So don't panic! But your code may be cooler and more coherent if you stop for a minute and consider should they be there.
About the author
Hi, my name is Artur Ejsmont,
welcome to my blog. I am a passionate software engineer living in Sydney and working for Yahoo!
If you are into technology, you can order my book Web Scalability for Startup Engineers on Amazon. I would love to hear what are your thoughts so please feel free to drop me a line or leave a comment.