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.
Magic methods in PHP can be a bit confusing especially if you do everything via __get and __call. They can be very usefull but adding them
by default everywhere is definetly a bad idea. I dont like __get/__set accessors that let you access enything. That defeats purpose of
encapsulation and promotes cross dependencies.
Recently i came across a silly problem .... i think its interesting enough to have a look at it.
So what would you expect from that code?
This is hands down the best PHP book for experienced PHP programmers I've ever seen. It touches most of the things you have to know or be
aware of if you want to be a successful PHP developer.
Book does not waste time on trivial stuff like foreach loop or case statements' syntax but gets straight down to business. Reading it is a pleasure and i recommend it to all junior - senior PHP developers.
I am very happy to write that it is a great book. It is not really a PHP book as you might expect as there is little PHP code in it. It is a software engineering book in context of PHP development. It is a book that every PHP developer should read and i am convinced that everyone will find there something interesting.
Book does not describe syntax of foreach loop nor does it iterate over obvious coding examples. It provides a full overview of enterprise development. It shows who are the peoples working in enterprise PHP companies, what roles they have, what processes they apply and what tools they use.
I have read this book but to be honest i had to skip a page from time to time. It is not an easy read. I am not sure if i would recommend it to anyone either.
The beginning of the book is quite ok, maybe first 100 or so pages. But then the disaster strikes. Chapters about J2EE, design patterns and EJB are really hard to read. I am not sure is it the buzz words density or maybe the examples and over abstracting everything? At the end it is not a good part of the book. I would also not recommnd that book for design patterns study, it does not explain things but makes then more difficult ;-)
Final chapters are a bit more readable again, Messaging and internationalisation chapters are quite ok. Especially messaging seemed interesting to me.
Its a nice book especially if you are preparing for the JSP/Servlets Java exam. It seems to be a light book but it covers quite a lot.
Its funny and light as other head first books and it has quite a lot of information that you would need for the exam or jsp/servlets development.
I would recommend it to all beginners in jsp field as well as to people who plan to undertake sun's SCWCD exam.
Final score: 7/10
Thats a strange book. It prepares to EJB exam but does not really cove enough practical stuff.
You read the book but cant really practice stuff. I dont know was it because at that time there was no eull ejb container available easily to be setup like now glassfish? maybe because it would be to difficult to get through the process of installation ... i dont know.
Any way it covers nicely design patterns and some basics of EJB but wont teach you to be a EJB developer i guess.