Posts by: Robert Raszczynski

• Architecture Patterns: Domain Model and Friends October 31, 2011

  Imagine a workshop of a racing team. The very first thing you will notice is that everything has its own place; spanners hanging on walls sorted by size, other tools placed in drawers, divided by their purpose, bolts and nuts placed in separate dividers and once again sorted by size. Everything is labeled, clean and in order. Now imagine how would it be to work in such an environment, where every single item has its specific place. I reckon that after the first few days, you would be able to point to where everything is with your eyes closed! Such a degree of segregation and organisation makes our lives much easier and it's a pleasure to work with.

  

  Architectural and design patterns help software architects to break systems in to smaller, more maintainable sections organised by their functionality and usage. The biggest benefit of patterns is that someone has already solved problems we may face and by utilising patterns such as Transactional Script, Domain Model or Data Mapper in your application it gives us, as developers, some good guidelines on how it should be designed. (more...)

  

  

  

  

  

  

  

  

  

  

  

  

  
• How To Create User Stories July 19, 2011

  Gathering requirements for software development is a vital communication process. There are multiple parties involved and a project relies on customers, users, domain experts, and many others, each with their own view of how the system should function. We will look at how user stories can help us to gather the information we need for a successful project.

  For a project to succeed, there needs to be a process in place that gets information as early and often as possible, where decision making happens based on information available at any point in time. Agile methodologies favour face-to-face communication and use user stories to collect customer requirements and to respond faster to constantly changing requirements. Use of user stories eliminates a need of extensive upfront requirements gathering and writing comprehensive documentation, allowing to us spread the decision making across the duration of the project.

  What is a User Story?

  In short, a user story is a chunk of functionality that is valuable to a user or a customer of the software. In my opinion the most comprehensive definition of a user story was provided by Kent Beck and Martin Fowler in Planning Extreme Programming:

  "The story is the unit of functionality in an XP project. We demonstrate progress by delivering tested, integrated code that implements a story. A story should be understandable to customers and developers, testable, valuable to the customer, and small enough so that the programmers can build half a dozen in an iteration"

  

  

  

  

  

  

  

  

  

  

  

  

  
• lessphp: PHP implementation of Less CSS December 17, 2010

  In a nutshell, Less CSS is a tool that lets you simplify your CSS style sheet and allows you to extend limited CSS functionality by introducing variables, mixins, operations and nested rules. The original implementation is written in Ruby; however, there is a PHP solution based on LESS CSS called lessphp. The definition of lessphp from the project's website is as follows:

  lessphp is a compiler that generates css from a small superset language that adds many additional features seen in other languages. It is based off an original Ruby implementation called LESS (http://lesscss.org/). For the most part, lessphp is syntactically compatible with LESS, with the exception of a few things...

  So why use lessphp? Because it can speed up CSS development, mainly by using the features of less. Your CSS code is much simpler, cleaner and nicely structured and better organised. The tradeoff is the fact that lesscss code needs to be compiled after each change is introduced. Moreover, on one project, we found out that web designers do not always write CSS with DRY principles in mind, and lack of time to work with designers on that introduced some problems.
  (more...)

  

  

  

  

  

  

  

  

  

  

  

  

  
• The EAV Data Model October 21, 2010

  One problem many developers encounter while defining and analysing data requirements is the situation where a number of different attributes can be used to describe an object, but only few attributes actually apply to each one. One option is to create a table with a column representing each attribute; this is suitable for objects with a fixed number of attributes, where all or most attributes have values for a most objects. However, in our case we would end up with records where majority of columns would be empty, because attributes may be unknown or inapplicable.

  To solve the above problem you can apply the EAV (Entity, Attribute, Value) model. This pattern is also known under several alternative names including "object-attribute-value" model and "open schema". In the EAV data model only non-empty values are stored in database, where each attribute-value (or key-value) pair describes one attribute of a given entity. EAV tables are often characterized as "long and skinny"; "long" refers to multiple rows describing entity, and "skinny" to the small number of columns used. In this article we will describe the EAV model, its implementation, and show applications of using it in the real world - including examining how Magento makes use of this pattern.
  (more...)