I went to see Udi Dahan speaking on Command and Query Responsibility Segregation. The open talk was organised by Skills Matter who support the Open Source community by organizing free events and courses.

Udi Dahan is a world renowned software architect and speaker. Udi is a specialist in SOA and distributed systems. It is a pleasure to listen to Udi speak because of his ability to present ideas clearly and keep others wanting to see what the next slide holds.

Command Query Responsibility Segregation or CQRS is software architecture pattern. The pattern is about separating (Segregating) the read side (Queries) and write side (Commands) of the system.

A simple example would be an application that does event reservations. All read commands would be executed against a reporting database which is stale and can be de-normalized. All calculations needed to display the data have been done before populating the reporting database. All write commands like making an actual reservation or adding a new event is executed against a Domain Model with it’s own database. Domain Model is never used to execute reporting queries. Reporting databases are generated from the write side database after all needed calculations have been performed.

This architectural pattern simplifies the Business Domain Model making it behavior only making it easier to maintain. Another strong advantage of CQRS is system performance. CQRS approach accepts that reporting data can be stale. This enables easier development of highly scalable distributed systems.

cqrs, DDD, dddd, Domain Model, Model, soa Hide

A great thing about patterns is that it provides a vocabulary. It allows developers to communicate efficiently. Complex ideas can be described at a high technical level without going into small details. Patterns are like butterflies and come in many colors, sizes and shapes and there’s.. lots of them. As butterflies patterns are grouped into families. One of such families is Domain Logic Patterns described in Martin Fowler’s book Patterns of Enterprise Application Architecture.

It’s one of the fundamental families because virtually every application written is described by any of the three patterns that belong to it. To say it simply there are three major ways how an application can be designed. What is more interesting that each of those patterns can be sorted by the amount of effort required to change the application depending on it’s complexity. Deciding which pattern to choose can be tricky because these patterns depend on various characteristics of the project being developed. The size, the complexity, the lifetime of a project and most importantly the skills of the developers.

Transaction Script

Transaction script organizes business logic by routines where each routine handles a single request from the presentation layer. It is the most common way how software beginners write applications. Required steps to perform a task are identified and expressed using language semantics. Common routines can be broken into subroutines. Transaction Scripts can be organised as classes or as global functions. A single file can contain many Transaction Scripts at once. A lot of developers may think they are proficient OOP users while in reality they write data centric Transactions Scripts wrapping them into classes which could be just as easily replaced with simple procedures.

However Transaction scripts have benefits. It’s a simple procedural model so most developers can understand it, it works well with a simple data access layer using Row Data Gateway or Table Data Gateway.

An example transaction script may be booking a hotel room where a single procedure is responsible for checking the availability of the room, calculating the price and updating the database.

class Hotel
{
	public function __construct(Data_Access_Gateway $gateway)
	{
		$this->_gateway = $gateway;
	}  

	public function bookRoom($userId, $fromDate, $toDate)
	{
		$roomId = $this->_gateway->_getRoomIdBetweenDates($dateFrom, $dateTo);  

		if (!$roomId) {
			return false;
		}  

		$days = $this->_getAmountOfDays($fromDate, $toDate);  

		if ($days < = 7) {
			$price = $days * 100;
		} else {
			$price = $days * 80;
		}

		$data = array(
			'userId' => $userId,
			'roomId' => $roomId,
			'fromDate' => $fromDate,
			'toDate' => $toDate,
			'price' => $price,
		);  

		$bookingId = $this->_gateway->insert('bookings', $data);  

		return $bookingId;
	}
}

Table Module

A Table Module is many ways the middle man between a Transaction Script and a Domain Model. A Table Module tends to organize domain logic with one class per table in the database. While a Transaction Script will have one class Hotel to do reservations a Table Module may have more fine grained classes like Hotel, Booking, Room. Even though these classes may be singular they do not actually represent individual entities and manages whole collections of entities. For example a Booking class would be responsible for mosts actions performed on the bookings database table. Like a Transaction Script a Table Module is a very data centric model approach and usually has a strong connection with the data access layer.

Table Module has a few benefits over a Transaction Script. There’s less duplication, domain logic is more organized and structured around domain entities. It works well with simple data access layers. However, Table Module doesn’t give you full power of objects in organizing complex domain logic. It lacks instance to instance relationships, has weak support for polymorphism.

To show an example of Table Module let’s re-factor the Transaction Script:

class Hotel
{
	public function __construct(Data_Access_Gateway $gateway, Booking $booking)
	{
		$this->_gateway = $gateway;
		$this->_booking = $booking;
	}  

	public function bookRoom($userId, $fromDate, $toDate)
	{
		$roomId = $this->_booking->getRoomBetweenDates($fromDate, $toDate);

		if (!$roomId) {
			return false;
		}  

		$days = $this->_getAmountOfDays($fromDate, $toDate);  

		if ($days < = 7) {
			$price = $days * 100;
		} else {
			$price = $days * 80;
		}

		$bookingId = $this->_booking->addBooking($userId, $roomId, $fromDate, $toDate, $price);  

		return $bookingId;
	}
}

class Booking
{
	public function __construct(Data_Access_Gateway $gateway)
	{
		$this->_gateway = $gateway;
	}

	public function getRoomBetweenDates($dateFrom, $dateTo)
	{
		return $this->_gateway->getRoomBetweenDates($dateFrom, $dateTo);
	}

	public function addBooking($userId, $roomId, $fromDate, $toDate, $price)
	{
		$data = array(
			'userId' => $userId,
			'roomId' => $roomId,
			'fromDate' => $fromDate,
			'toDate' => $toDate,
			'price' => $price,
		);  

		$bookingId = $this->_gateway->insert('bookings', $data);  

		return $bookingId;
	}
}

Domain Model

Domain Model organizes domain logic into well defined domain entities that contain both behavior and data. Usually each entity class represents a single entity in the data layer. Domain Model creates a hierarchy of inter connected objects that interact with each other by triggering behaviors on each other. Domain Model shines over Transaction Script and Table Module when it comes to handling domain complexity. It enables the full power of object oriented programming and all available design patterns. Even though Domain Model may sound like a silver bullet to all software development problems it is not. Learning to design applications using Domain Model requires a “paradigm shift” to start looking for entities and behaviors instead of looking for routines. The main downside of Domain Model is the way it works with relational databases. To compare I would like to quote Martin Fowler:

“In many ways Domain Model treats the relational database like a crazy aunt who’s shut up in an attic and whom nobody wants to talk about.”

Domain Model tries to be data layer agnostic. This is what object relational mappers also known as ORM’s as Hibernate try to solve by hiding the data access layer away.

To show an awkwardly simple example of Domain Model let’s re-factor the Table Module approach. To keep the example simple I’ll ignore the data access layer.

class Hotel
{
	protected $_hotelId;
	protected $_rooms;

	public function bookRoom(User $user, $fromDate, $toDate)
	{
		$room = $this->_getRoomBetweenDates($fromDate, $toDate);

		if (is_null($room)) {
			return false;
		}  

		$booking = $room->bookRoom(User $user, $fromDate, $toDate);

		return $booking;
	}
}

class Room
{
	protected $_roomId;
	protected $_bookings = array();

	public function bookRoom(User $user, $fromDate, $toDate)
	{
		$days = $this->_getAmountOfDays($fromDate, $toDate);

		if ($days < = 7) {
			$booking = new Booking($user, new ShortBookingStrategy($user, $days));
		} else {
			$booking = new Booking($user, new NormalBookingStrategy($user, $days));
		}

		return $booking;
	}
}

class NormalBookingPriceStrategy extends BookingPriceStrategy
{
	public function getPrice()
	{
		$price = $this->_days * 80;

		if ($this->_user->isLoyal()) {
			$price = $price / 2;
		}

		return $price;
	}
}

class ShortBookingPriceStrategy extends BookingPriceStrategy
{
	public function getPrice()
	{
		return $this->_days * 100;
	}
}

As you can see there is an instant explosion of classes and the data access layer is out of the picture. Responsibility to efficiently load and keep track of loaded entities is left to object mappers like Hibernate.

The End

Everyone of these domain model patterns have their benefits and downsides. It takes experience to be able to decide which approach to take. For those who are new to Domain Model it is advised to have an experienced team member who is able to guide you through it. While Transaction Script or Table Module can seem like a good solution at some point it may not be as effective later on. It is important to recognize when a different domain model approach might work better. It’s been a long ride for me. Through the years I’ve learned a few things about designing software but I still don’t feel very comfortable writing about it. I would love to hear feedback from you how this article and these examples could be improved to enable better understanding between the different modeling approaches.

Domain Model, Model, Patterns, transaction-script Hide

Just recently I’ve finished reading Spring Persistence with Hibernate. It’s a book about two major Java technologies Hibernate and Spring. Hibernate is a powerful object/relational persistence framework and Spring is a Java application platform that includes an MVC framework. The book is primarily meant for Spring and Hibernate developers but it may also be useful to developers who are interested in object relational mapping and advanced MVC frameworks. The topics covered in the book include object relational mapping, aspect oriented programming, inversion of control, MVC. Even though these topics are advanced the book does not require the reader to understand them beforehand. All examples are written in Java and should be understandable to anyone with a solid development background.

The book is quite lengthy consisting of more than 400 pages in total. First half of the book introduces the reader to the Hibernate persistence framework. It explains how Hibernate works in general and how it is configured. The most important chapters on Hibernate cover mapping to entities and entity collections, describe the life cycle of persistent objects, cascading operations, querying and lazy loading. The other half of the book focuses on topics such as inversion of control, aspect oriented programming also known as AOP, transaction management, Spring MVC framework and testing.

Before reading the book I didn’t have any enterprise experience with Java or it’s technologies. Working as a PHP developer I appreciate the Java community and technologies made available by it. Through many years of being exposed to enterprise application development Java community has developed powerful tools which are a great resource to developers with different development backgrounds such as me. I’ve found the book to be an excellent insight into the object relational mapping world. I’ve enjoyed reading about Spring’s AOP framework which opened my eyes in a few ways how AOP could compliment OOP. Spring IoC container which is used by Spring itself is an amazing piece of software setting new standards for other dependency injection containers out in the wild.

Even though I believe the book is a worthwhile read it can seem to be too detailed at times. For example describing all available bean factories and all other lists of available bells and whistles can seem to be dull or hardly memorable. Maybe it would be better to introduce to the idea that there are multiple factories, describe few most important ones and provide directions as to where it is possible to learn about other types of factories. The book provides many examples which is a great way to grasp the concepts quickly. Provided examples are individual pieces explaining a certain concept. It may have been better to provide examples by trying to build a real life application throughout the entire book. I believe it is a fun way to learn allowing to see how real life development issues can be solved.

I believe it’s every developer’s duty to be familiar with the latest development technologies and to know when to use them. Too many applications are written using improper tools. Object relational mapping technologies are discussed frequently and not everyone is a fan of them. The fact that Hibernate is commonly used by Java developers and .NET developers proves that persistence frameworks have their place and are worthwhile to familiarize with.

framework, hibernate, java, persistence, review, spring Hide

Software development produces products as any other industry. It is an interesting issue that products produced by the software development industry are not always as well tested as in other industries. One of the main reasons is due to the fact that in most companies software is manually tested by the same developers who built it.

Developers are not necessarily good testers. Good software developers while sharing some traits are different from good testers.  A good developer may be excellent at software design but won’t notice spelling mistakes. Developers tend to take the testing path that usually works while cutting corners on special cases. It is also known as happy testing.

Most reasons why software is tested manually boil down to:

• Not knowing how
• Not having the time
• Maintaining legacy code

Hardly any of these reasons are valid excuses. Truth be told automated testing is not easy. It is a skill that has to be learned and doesn’t come naturally. It’s a skill that takes years to master. It may seem that automated tests take too much time and at first it will. Due to the same fact that it’s a skill and takes time to master. In some way it is like skiing. Before going down a steep mountain racing the wind one has to learn how to otherwise it’s an unpleasant struggle climbing down with your skis across the shoulder. Automated testing won’t do miracles but when done properly it may increase productivity by 10 – 20%.

There are many types of software testing with their own benefits and downsides. Bellow are the three most important and common types of testing.

Unit Testing

Unit testing is about testing the smallest individual parts of an application. For example instead of testing the whole engine of a car all individual pieces are tested separately as units. All dependencies are replaced with stubs or mocks or fakes. Unit tests are meant to be lightning fast and execute thousands of tests in a few seconds therefore they shouldn’t connect to the database, web services or send emails. Unit tests are most effective when executed very frequently during development to inform the developer of any broken parts allowing to fix the problem immediately without losing line of thought.

Integration Testing

Integration tests ensure that all of the application’s parts work correctly when they are assembled in a simulated production environment. An example of an integration test can be a batch job executing against a database with test data. Integration tests are a lot slower than unit tests and usually work best integrated with a continuous build system. While integration tests are not good at identifying broken parts they are excellent at testing if an overall group of components is correctly wired together and produces the desired outcome.

Acceptance Testing

Acceptance testing also known as functional testing or QA testing involves testing a complete system that is usually identical to the user’s anticipated system. Acceptance tests can be automated or may be carried out by a QA team. In agile software development terms an acceptance test tests a business story. For example a simple story may be “As a manager I am able to list invoices, filter them by name and date and approve or reject them” An acceptance test would test that scenarios mentioned in the story can be done on a completed system. Automated web application development acceptance tests can be carried out by selenium that simulates recorded browser actions or by asserting HTML structures. Acceptance tests shine in proving if the user story scenarios can be completed but are usually not very good at pinpointing the nature of a problem. They tend to be slow and complicated to set up. Even testing a relatively simple back office application would require to set up an up to date test database, provide datasets for every possible scenario, provide a way to test sending out emails and their contents.

Software development testing is a vast topic that deserves more attention from the the ever growing industry. Automated software testing is often times disregarded as boring, time consuming or ineffective. Mainly because of lack of knowledge and skill to make it work for you and not against you.

acceptance, integration, software, Testing, unit Hide

Recently I’ve set myself of a new journey since I’ve decided to help my friend’s business to  battle the crisis back home by creating them a new website. It’s a bit ironic but I didn’t know where to start, because at work I usually work with custom made websites which very rarely use a content management system.

The content management system I’ve chosen to use is Drupal – a widely adopted opensource content management system written in PHP. It has a vast community and enormous amounts of modules developed by other people. It took me about a week’s worth of evenings to get to know the system and launch the website. Here are the steps involved to create a Drupal website:

• Install Drupal. The installation was really easy and simple. Put it on your webserver, access the website, follow an easy guide and you’re done.
• Configure Drupal. To a new user Drupal configuration may seem hectic or chaotic at first. It may take a while to get the hang of things. Figuring out how to change website information, setting up menus, changing themes, hiding things that you don’t want to display.
• Pick a theme. It’s generally better to pick an already made theme and modify it to fit your needs. Themes are designed to integrate with Drupal nicely. They will likely look the same on all popular browsers, will be HTML standard compliant, optimized for SEO and may even be optimized usability wise. I found it very easy to pick a theme using theme garden.
• Install modules. Drupal is a modular content management system and comes with a few useful bundled modules it self. One of the strongest Drupal’s key points is that it has a vast community actively developing modules for it. If you ever need to do something on your website most likely there is a module to do it.

More about modules

Drupal has many useful modules such as Blog, Comments, RSS, Forum, Search, Localization, Content categorization. But the true power lies in modules developed by the Drupal community. A few examples:

• CCK. Content construction kit allows you to add custom fields to content nodes.
• Views. One of the most essential modules for Drupal. Alows to change website’s representation in many ways.
• Pathauto. Allows to configure how website’s URL’s are constructed. A very powerful module for anyone interested in SEO.
• Nodewords. Allows to change meta tags. Very useful to provide custom meta descriptions for content pages. Descriptions are important for SEO.
• Page Title. Another useful Drupal SEO module that allows to provide custom page titles.
• Lightbox2. Very nice plugin to display images on the website. Also supports slideshow.
• Wysiwyg. Allows to replace a simple content text editor with a rich text editor of your choice.
• Google Analytics. Adds google analytics tracking. Provides powerful per user configuration.
• Node Gallery. A nice lightweight image gallery for Drupal. Still in alpha stages but very easy to use and provides lot’s of configuration. Integrates with Lightbox2.
• Backup and Migrate. Creates scheduled website backups in case there’s an emergency.
• And many other modules…

Pros and Cons of Drupal

Drupal has many pros:

• Extremely easy to install on any webserver.
• Has a vast community developing modules and providing technical help.
• Has a huge amount of freely available themes to pick from.
• Is very well adopted and maintained which means that bugs are fixed, security patches are released and new cutting edge features are always on the horizon.
• Drupal is fast. Maybe it’s not the fastest content management system in the world but it certainly is fast. It’s very easy to set Drupal cache settings which give an immediate boost to the website.
• It’s relatively easy to set up a website that is Search Engine Optimized aka SEO.

Like everything in life Drupal has a few cons:

• For new users Drupal may be overwhelming somewhat chaotic and hectic. It’s still very easy to set up a theme and enter content. But you may have to scratch your head for a while how to add localization support to Drupal.
• Drupal is quite old and even it’s actively developed lot’s of it is written in procedural PHP. Which isn’t necessarily a bad thing, but in some way means that it’s not a top cutting edge software modelling masterpiece.
• Even though Drupal has a huge community which develops modules for it some of the modules don’t have very good documentation. More often than not these are the less used ones. It’s not Drupal’s fault but it’s still confusing and somewhat frustrating to try and figure out where and how you can configure some module you’ve just installed.

All in all I’m happy with Drupal and I think it’s an amazing project and I’m giving my thanks to the Drupal community for all the greats things they are doing.

cms, drupal, modules, PHP Hide

PyDumpy is a simple Python utility that might be helpful for developers struggling to get fast and partial database snapshots from production databases. It does it’s job by checking the database information schema to find out the approximate rows count available in each table and limits the table if needed to avoid dumping too much data as some databases may have hundreds of gigabytes of data. It then passes all the limits information it gathers to mysqldump a tool created by MySQL to do the actual dumping.

Python does not have a built in package to connect to MySQL as for example PHP does and therefore PyDumpy relies on MySQL for Python package to work. PyDumpy also relies on mysqladmin to do the actual dumping.

PyDumpy is very simple to use. For example to dump a maximum of 50 000 rows from each table type:

./pydumpy.py -H host -u user -p pass -n dbname -limit=50000

PyDumpy also allows to specify row limits and sorting preferences for each table specifically:

./pydumpy.py -H host -u user -p pass -n dbname -limit=50000 –ask-to-limit –ask-to-sort

If you find this tool useful please feel free to provide feedback by leaving a comment.

dump, MySQL, partial, pydumpy Hide

It seems that I will continue reviewing books for Packt publishing. Spring Persistence with Hibernate is a book about a different development world. Spring web development framework and Hibernate persistence framework are both well known Java technologies. Even though I have little to do with Java I believe it has a great world wide community of software development experts. Not surprisingly lot’s of innovation comes from the Java world. I believe it is because Java developers know a lot more about proper design principles and coding practices than an average developer of let’s say PHP or .NET.

This book should cover such topics as getting a grip with hibernate, integrating hibernate with spring, spring IoC, spring AOP, transaction management, unit testing. I believe it will be a worthwhile read with high hopes that it will give me new ideas what I could implement or use in the PHP world.

framework, hibernate, java, persistence, review, spring Hide

As I mentioned earlier guys from Packt publishing asked me to review a recently published book Zend Framework 1.8 Web Application Development. The title says it all – it’s a book about designing and developing PHP web applications using Zend framework.

This book doesn’t require the reader to be familiar with zend framework and explains all concepts in proper detail, though it will be easier to read the book if the reader is familiar with the framework and/or has experience with MVC and OOP in general. This book should be interesting to all developers who design and develop day to day web applications using MVC frameworks or not yet familiar with them as it may improve their insights towards web applications modelling, testing , optimizations and more.

Even though I am fairly familiar with the framework I found the book to be an interesting, easy read, plentiful of examples explaining the intricacies of the framework.

The first though a very important chapter teaches the concept of bootstrapping using Zend_Application and shows how to write and run a simple hello world program using controllers and views. As well it introduces the use of controller utility methods such as _getParam(), _forward(), _redirect(), action helpers, view helpers which are very valuable and a lot of developers miss them entirely. This chapter also shows the proper use of the response object which also tends to get forgotten.

The second chapter dives straight into the Front Controller pattern explaining how the framework routes, dispatches requests and responds to the client. I have never been bothered to understand the whole thing and was quite surprised to see how simple it all is. It is worth mentioning that this chapter explains in great detail how the router and various routes work and how elegantly it integrates with Zend_Config. Last the chapter covers the request object and it’s external API which provides lot’s of valuable functionality.

From the third chapter author Keith Pope starts building the main application of the entire book, the Storefront. It’s a relatively simple “real life” application that serves the purpose of being an online products catalog. This chapter shows how such an application is structured on a file system and bootstrapped and configured.  Even more the chapter covers the creation of Zend_Log and various logging writers and database profiling. Extremely valuable features that not many developers know of. If every zend framework application would start as the chapter describes I believe a lot more developers would be eager to start their IDE’s 9:00 AM straight.

Next is my personal favorite chapter – Models. Zend Framework does not have a base Model class and there’s a pretty good reason why it doesn’t. Models are specialized for a certain business task and as such it is arguably impossible to make a generic model implementation that would fit all sizes well. It then might raise a question what’s there to read about? It is my personal belief that web applications modelling has lost focus during the years by the ever growing development community. Developers got their minds focused on the next “new” thing. Let it be template engines, ORM’s, rise of active record and ruby on rails, ajax and javascript frameworks. While the majority of the models “out there” are deeply crippled. Hundreds of books were written explaining how to manage the complexity of the problem so a single chapter is a mighty challenge. I believe the author made a great choice by explaining the concept of the fat model, skinny controller, explaining the benefits composition over inheritance, data access layer separation from the business layer and my deepest respect for introducing domain model design, Martin Fowler’s book Patterns of Enterprise Application and Eric Evan’s book Domain Driven Design also known as DDD.

Next five chapters describe the implementation of the Storefront application. Each chapter highlights a major component of the framework. Use of resource autoloaders, plugins, Zend_Form, Zend_Auth, Zend_Acl. Before saying anything else it is very important to say that books rarely ever show hardcore “real life” applications as examples. Even Fowler himself likes to skip certain topics like validation in certain sections of his famous book just because they complicate things too much. This book is no exception to the rule. It’s a pretty straightforward application. There isn’t a single join to another table or a GROUP BY statement in SQL, forms implemented with Zend_Form are rather simple with little if any javascript / ajax. I found it a bit disturbing that class create other classes having both business and factory logic. One of the ugly examples was where a getPrice() method on a product model creates it’s own Taxation service which could not be mocked if that class would need to be unit tested. In most of the cases author provides injection methods for unit testing but I would argue that it does not show class dependencies explicitly which is very valuable for unit testing. Besides that I really enjoyed how the author decided to go with ACL in the domain layer. This would more often than not be implemented in the controllers making the model tightly dependent on the controllers. All in all keeping in mind that it’s a tutorial application introducing the framework I’m highly satisfied of it’s overall quality. Repeating myself. If every zend framework application would be so well written..

Another chapter worth mentioning is regarding optimizations. I was surprised to learn about such things like plugin loader cache, table gateway metadata or various Zend_Cache frontends which I have never bothered to look up. Not to mention widely known tricks using APC, stripping zend framework of all requires and setting up an optimized include path.

And last but not least again one of my favorite topics – testing. I strongly agree with Misko Hevery that test driven development is a skill. It’s definitely not easy to start or learn. One would fool himself to think otherwise.  This topic deserves many books of it’s own. I can only share from my own experience – once I started unit testing applications that I work with, I have never looked back. This chapter explains different types of testing, shows how to setup PHPUnit and provides examples of controller testing using Zend_Test. I believe this chapter deserves more attention on how to do testing with a database in mind, debugging failing controllers, avoiding complicated mocks, implementing continuous integration. But again it is worth to keep in mind that the book is about Zend Framework and not testing in general.

All in all I enjoyed reading this book. I would and will recommend it to my colleagues and friends. I hope that this hopefully not too boring review convinced you to buy the book and learn something new. Once again – big thanks to Packt Publishing for a free book. Happy reading. Over and out.

book, framework, PHP, review, zend Hide

I was recently asked by Packt Publishing to review a copy of one of their books called Zend Framework 1.8 Web Application Development book. This book is about designing, developing and deploying feature-rich PHP MVC based web applications using Zend framework. Guys from Packt Publishing were generous to send me a hard copy of the book. I owe them a thanks.

Even though I feel fairly familiar with Zend Framework I believe this book will be a great opportunity to dwell into the darker corners of the framework. The fact the Zend Framework is now at version 1.9.5 and version 2.0 is on the horizon is a bit worrying but having had a quick glimpse at the table of contents I see that some topics of particular interest to me like chapters about model design, optimizations and testing are not the ones that change at the same pace as the framework does which makes this book even more worthwhile to read.

I believe I will have a great time reading and reviewing this book.

book, framework, PHP, review, zend Hide

This is my summary of PHPNW09 conference that I was lucky to attend. This was my first real conference and I was blown away. Talks that I enjoyed most are the keynote about the uncertainty principle, Lorna’s talk about the Joel Test and Rob Alen’s talk about project management. It was also very interesting to hear about the state of the PHP project and it’s internal development teams. Did you know that PHP has only about 100 active developers of whom only ~10 are core developers?

The event itself was perfectly organised. I don’t have a single complaint. Timings were perfect and don’t get me started about the food. It was delicious!

I also had an epic opportunity to see how Microsoft fails to demo their flowchart software which was highly amusing. Though I feel highly thankful to these guys because they were the major sponsors of the event not to mention their help on PHP windows builds.

In the evening we were invited to a SUN sponsored bar where I had an opportunity to meet and chat with really interesting people. Met a PHP star Derick Rethans, had a really great conversation with the event’s organizer Jeremy Coates and even met people from my own homeland.

All in all this was a great experience and I’m definitely coming back next year. There are also other conferences coming up in Barcelona and London which I hope to attend.

conference, PHP, phpnw09 Hide