“What do you need to start a business? Three simple things: know your product better than anyone. Know your customer, and have a burning desire to succeed.” – Dave Thomas

What’s new in PHP 5.5 and MySQL 5.6?

LAMP development is going to be interesting and fun with new releases of PHP 5.5, MySQL 5.6 and arise in competition with MariaDB 10.0 series.

MySQL is moving towards better performance and scalability. On other side PHP is moving towards better OOPs concepts and performance improvements.

What’s added in PHP 5.5:

  • Generators and coroutines
  • Non-scalar Iterator keys in foreach
  • Getting the fully qualified class name using ClassName::class
  • finally blocks
  • list() in foreach
  • Constant array and string dereferencing
  • New password hashing API
  • Bundled ZendOptimizer+ as OPcache

What’s dropped:

  • ext/mysql deprecation
  • preg_replace() /e modifier
  • intl deprecations
  • mcrypt functions deprecations

Reference links:

What’s new in MySQL 5.6?

  • Better Performance and Scalability
  • Improved InnoDB storage engine for better transactional throughput
  • Improved Optimizer for better query execution times and diagnostics
  • Better Application Availability with Online DDL/Schema operations
  • Better Developer Agility with NoSQL Access via Memcached API to InnoDB
  • Improved Replication for high performance and self-healing cluster deployments
  • Improved Performance Schema for better instrumentation and monitoring
  • Improved Security for worry-free application deployments
  • And other important enhancements.

Oracle claims that there is 230% Performance Improvement with InnoDB in MySQL 5.6:

  • Online operations for better availability
  • Transportable tablespace for portability
  • NoSQL access via the Memcached protocol
  • Full-text search

Reference links:


As MySQL is now proprietary software of Oracle and they are holding community addition features to promote MySQL Enterprise editions, you should look for MariaDB 10.0.1

Benchmark  with MariaDB and MySQL:


MariaDB and MySQL compatibility: 




“No matter how brilliant your mind or strategy, if you’re playing a solo game, you’ll always lose out to a team.” -Reid Hoffman

Understanding Design Patterns in better way

While our interview process we ask Questions on Design Patterns and most of the Candidates are only aware of MVC Design Pattern. I’m writing this post influenced from Book Design Patterns, Elements of Reusable Object-Oriented Software

There are lots of Definitions of Design Patterns on internet but Christopher Alexander says, “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it in the same way twice

In simplest way “design pattern is a general reusable solution to a commonly occurring problem within a given context in software design“.

In general, a pattern has four essencial elements:

  • Pattern Name
  • Problem
  • Solution
  • Consequences

The pattern name is a handle we can use to describe a design problem, its solutions, and consequences in a word or two.

  • Naming a pattern immediately increases the design vocabulary. It lets us design at a higher level of abstraction.
  • Having a vocabulary for patterns lets us talk about them.
  • It makes it easier to think about designs and to communicate them and their trade-offs to others.

The problem describes when to apply the pattern.

  • It explains the problem and its context.
  • It might describe specific design problems such as how to represent algorithms as objects.
  • It might describe class or object structures that are symptomatic of an inflexible design.
  • Sometimes the problem will include a list of conditions that must be met before it makes sense to apply the pattern.

The solution describes the elements that make up the design, their relationships, responsibilities, and collaborations.

  • The solution doesn’t describe a particular concrete design or implementation, because a pattern is like a template that can be applied in many different situations.
  • Instead, the pattern provides an abstract description of a design problem and how a general arrangement of elements (classes and objects in our case) solves it.

The consequences are the results and trade-offs of applying the pattern.

  • The consequences for software often concern space and time trade-offs.
  • They may address language and implementation issues as well.
  • Since reuse is often a factor in object-oriented design, the consequences of a pattern include its impact on a system’s flexibility, extensibility, or portability.
  • Listing these consequences explicitly helps you understand and evaluate them

As per Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides in their Design Patterns book, you can divide Design Patterns into three types:

  • Creational patterns are ones that create objects for you, rather than having you instantiate objects directly. This gives your program more flexibility in deciding which objects need to be created for a given case.
  • Structural patterns help you compose groups of objects into larger structures, such as complex user interfaces or accounting data.
  • Behavioral patterns help you define the communication between objects in your system and how the flow is controlled in a complex program.

I studied following link for Design Pattern implementations in PHP and I assume these are must read for everyone writing code in PHP and in OOPs way.

I would love to participate in healthy discussion on these.

*Credits to Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides.