Federico Cargnelutti

Simple is better than complex. Complex is better than complicated. | @fedecarg

Archive for July 2008

Software Development Cycles

with 8 comments

The inside details of the software development cycle:

  1. Programmer produces code he believes is bug-free.
  2. Product is tested. 20 bugs are found.
  3. Programmer fixes 10 of the bugs and explains to the testing department that the other 10 aren’t really bugs.
  4. Testing department finds that five of the fixes didn’t work and discovers 15 new bugs.
  5. Repeat three times steps 3 and 4.
  6. Due to marketing pressure and an extremely premature product announcement based on overly-optimistic programming schedule, the product is released.
  7. Users find 137 new bugs.
  8. Original programmer, having cashed his royalty check, is nowhere to be found.
  9. Newly-assembled programming team fixes almost all of the 137 bugs, but introduce 456 new ones.
  10. Original programmer sends underpaid testing department a postcard from Fiji. Entire testing department quits.
  11. Company is bought in a hostile takeover by competitor using profits from their latest release, which had 783 bugs.
  12. New CEO is brought in by board of directors. He hires a programmer to redo program from scratch.
  13. Programmer produces code he believes is bug-free…

So true :)

Written by Federico

July 31, 2008 at 12:07 am

Posted in Programming

14 Ways to Learn From Creative Programmers

leave a comment »

Programmers are a great example of thinking outside the box because, well, programmers can actually create the box. If you’ve ever spent more than two minutes talking with a programmer about his work, you’ll find out very quickly that programmers have a passion for what they do. They eat, sleep and breathe programming.

Read more: 14 Ways to Learn From Creative Programmers

Written by Federico

July 30, 2008 at 1:03 pm

Posted in Programming

Dependency Injection in Zend Framework

with 5 comments

The Zend Framework is a step closer to having its own DI Container.

Bradley Holt has announced the creation of a new proposal Zend_Container, a simplified version of Zend_Di. According to him, if the framework is going to have a dependency injection component this component needs to be as simple as possible, something along the lines of PicoContainer.

Zend_Container goals:

  • The component’s primary purpose is to replace the use of class-managed singletons and Zend_Registry.
  • The component will only manage singleton items within a container, it will not act as a factory (except for creating the single instance).
  • A container can have zero or one parent container and have access to items in its parent, but a parent cannot have access to items in its children.
  • The component uses reflection to determine dependencies.

The Xyster team has already implemented a similar component, Xyster_Container, a Dependency Injection container based very heavily on PicoContainer, however the main goal of Zend_Container is simplicity.

The good news is that, for the first time, Zend has given the official go-ahead for the development of this component.

More info: Dependency Injection in Zend Framework

Written by Federico

July 29, 2008 at 10:08 am

Posted in Frameworks, PHP

Zend Framework Architecture

with 16 comments

Introduction

Before we begin our exploration of the architecture of the Zend Framework (ZF), it is important to discuss how a typical MVC application is built. Examining and understanding the architecture of an MVC Web application allows you to make more contextually sound choices when building your application.

Three-tier Architecture

The three-tier architecture focuses on defining responsibilities between different parts of the application. It has the following tiers:

Presentation Tier
The top-most level of the application is the UI. The main function of the interface is to translate tasks and results to something the user can understand.

Application Tier
This layer coordinates the application, processes commands, makes logical decisions and evaluations, and performs calculations. It also moves processes data between the two surrounding layers.

Data Tier
Here information is stored and retrieved from a database or file system. The information is then passed back to the logic tier for processing, and then eventually back to the user.

Model-View-Controller Architecture

Although the three-tiers is similar to the MVC architecture, they are different. Conceptually the three-tier architecture is linear. The Presentation tier never communicates directly with the data tier and all communication must pass through the Application tier. However, the MVC architecture is triangular: the View sends updates to the Controller, the Controller updates the Model, and the View gets updated directly from the Model.

Zend Framework

Zend Framework provides components for the MVC and Table Gateway design patterns which are used in most Web applications. Developed by Zend Technologies and released in 2005, Zend Framework is heavily based on the Solar Framework, developed by Paul M. Jones, reason why they share a similar underlying architecture.

There are 3 types of Web application frameworks:

  1. The ones that offer a solid infrastructure: Symfony, Solar, Ruby on Rails and Django.
  2. The ones that offer a component library: ezComponents and PEAR.
  3. The ones that offer both: Zend Framework.

Zend Framework not only offers a solid infrastructure, but also an extensive component library. The component structure of ZF is somewhat unique, each component is designed with few dependencies on other components. This loosely-coupled architecture allows developers to use components individually.

Architecture

The framework architecture is based on the Front Controller and Model-View-Controller architectural patterns:

MVC pattern

The Model is the part of the application that defines its basic functionality behind a set of abstractions. The data access layer and some business logic is defined in the Model. The Views define exactly what is presented to the user. Usually controllers pass data to each view to render in some format. The Controllers bind the whole pattern together. They may manipulate models, decide which view to display based on the user’s request and other factors, pass along the data that each view will need, or hand off control to another controller entirely.

Front Controller pattern

Zend_Controller is the heart of Zend Framework’s MVC system. Zend_Controller_Front implements a Front Controller pattern, in which all requests are intercepted by the front controller and dispatched to individual Action Controllers based on the URL requested.

Coupling

ZF provides a loosely-coupled component library simplified to provide most of the functionality everyone needs to develop Web applications. In object-oriented programming coupling or dependency is the degree to which each component relies on each one of the other components. The biggest advantage of a loosely-coupled architecture is that it allows developers to use components individually.

Neil Garb did an excellent job measuring the level of coupling in the Zend Framework based on the number of dependencies set in code. I’ve extended his work by measuring the level of coupling between components set at runtime. I’m using the Inclued extension to trace through the hierarchy of file inclusions and class inheritance at runtime.

The following diagrams where generated using Graphviz:

Zend_Controller dependencies

Zend_Controller and Zend_Db dependencies

Zend_Controller, Zend_Db and Zend_From dependencies

A standard Zend Framework application requires the following components: Zend_Controller, Zend_Uri, Zend_Registry, Zend_Loader, Zend_Config, Zend_Layout, Zend_View, Zend_Filter, Zend_Validate, Zend_Db, Zend_Form and Zend_Exception.

Criticism

Zend Framework is intended to serve as a novel way to manage Web development complexity. Many consider ZF to deliver reasonably well on this promise, however, it does not universally accommodate all design styles, environments or requirements.

Performance

The performance of a framework is influenced by many factors, particularly the configuration of your servers. However, the design of an application can make a big difference and determine whether your site is slow or highly responsive. Recent benchmarks show that the Zend Framework is slower than other Web frameworks.

Although low coupling is a sign of a well-structured system, it may reduce performance, and a highly-coupled system is sometimes desirable to achieve maximum efficiency. Regardless, in many modern frameworks, the cost of reduced performance is often seen as a worthy trade for the benefits to the software development process that result from low coupling.

Design

Although the framework supports modularity, it lacks of some basic features, such as a Module Coordinator. The system doesn’t include any component or configuration mechanism to deal with Model and Controller dependencies, making it very difficult to share modules between applications. Also, Zend_Controller doesn’t allow modular systems to load model files from within its own module as well as outside modules.

The system lacks of local containers to manage object dependencies and interrelationships. Instead, it uses a global container to store objects. According to Troels Knak-Nielsen, the problem with this is that a global container, whether primitive or sophisticated, will always be a global symbol. Most programmers will agree that global variables are bad design, and that goes for a global containers as well.

Namespaces

With PHP 5.3 coming up on the horizon, the Zend Framework API faces a re-design. While namespaces will hopefully lead to more readable code, Zend developers will finally need to start thinking about some standards for abstract classes and interfaces.

Links

Written by Federico

July 28, 2008 at 12:23 am

The Importance of User Generated Content

with 4 comments

The days of companies controlling the creation and distribution of engineered content are fading. An explosion of user generated content (UGC) has reshaped the Web development landscape.

UGC is Ruby on Rails latest strategy to hand over the creation of documentation to those who care most about its long-term success, its community.

User Generated vs Engineered Content

Engineered content is created by established knowledge experts and content owners who are part of an official team. UGC, on the other hand, is created by users themselves.

The benefits of UGC are:

  • User opinions: The popularity of the content is based on user ratings and opinions.
  • User interaction: Allows all users the choice of becoming participants rather than just spectators. Also, it provides knowledge experts who aren’t part of the team with a medium in which to share their knowledge
  • Content restriction: Many more methods of content entry, making it less restrictive.
  • Content coverage: A wider content provider base means more areas of knowledge can be covered.
  • Quantity of content: Increases traffic and crawlable content.
  • Content linkability: Increases engagement.
  • Content strength: Content containing targeted keywords that will be crawled by search engines and indexed highly.

Rails new social documentation site

Built on top of APIdock, a social software documentation application, Rails-doc gives you a chance to contribute by writing documentation or rating content. It also provides easy access to documentation for a full line of Rails versions. A super-fast keyword search gives quick answers to quick questions and the full search looks through everything and finds everything that can be found with your given search term.

Conclusion

Remember Zend’s quick-start contest? The idea was to get people involved in the process of writing documentation. But the problem with this is that contests are not very social, there’s no teamwork involved. Users don’t want to compete, they want to help, they want to be part of the community. Engineered content doesn’t allow this. Not surprisingly, they only received 2 contributions.

Perhaps there’s a lesson to be learnt here.

Written by Federico

July 27, 2008 at 6:51 pm

Posted in Agile Development, PHP

10 concepts that every software engineer should know

leave a comment »

In this post, Alex Iskold discusses the top 10 concepts software engineers should know.

A successful software engineer knows and uses design patterns, actively refactors code, writes unit tests and religiously seeks simplicity. Beyond the basic methods, there are concepts that good software engineers know about. These transcend programming languages and projects – they are not design patterns, but rather broad areas that you need to be familiar with. The top 10 concepts are:

  1. Interfaces
  2. Conventions and Templates
  3. Layering
  4. Algorithmic Complexity
  5. Hashing
  6. Caching
  7. Concurrency
  8. Cloud Computing
  9. Security
  10. Relational Databases

Read more: 10 concepts that every software engineer should know

Written by Federico

July 25, 2008 at 8:41 am

Zend Framework 1.6 takes Web development to the next level

with 8 comments

Zend Framework is probably the most popular Web framework right now, and this is why:

  • It’s simple and easy to learn
  • Offers extensive documentation
  • Has a modular and flexible architecture
  • Follows strict coding standards
  • Provides extensive unit tests
  • It’s supported by a large community of developers
  • Has everything you need to build Web applications

Zend Framework 1.6 features

  • SOAP (server/client)
  • File Transfer Component
  • Paginator Component
  • Unit Testing Harness for Controllers
  • ReCaptcha Service

Other features:

  • Dojo Integration
  • Tooling Project: Project Asset Management
  • Tooling Project: Command Line Interface
  • New Media View Helpers (Flash, Quicktime, Object, and Page)
  • Text/Figlet Support

Zend Framework is becoming the perfect framework for building enterprise Web applications. Version 1.6 RC1 is now available:

Zend Framework download site

Update

Tim Fountain responded to this post:

Zend’s view on component development for ZF has been that they wish to focus on areas where they feel they can offer value to the PHP community as a whole. For this reason they have delibrately avoided developing components for things already well served by existing open source PHP projects. This makes complete sense. But as a developer coming to ZF afresh, unless you already know about these projects, you’re going to see some pretty big holes in ZF as a platform on which to build your applications.

Read more: Zend Framework in the enterprise

Written by Federico

July 23, 2008 at 12:09 am

Posted in Frameworks, PHP, Programming

Enterprise Web Services Framework for PHP

with 5 comments

Apify is a small and powerful open source library that delivers new levels of developer productivity by simplifying the creation of RESTful architectures. Web services are a great way to extend your web application, however, adding a web API to an existing web application can be a tedious and time-consuming task. Apify takes certain common patterns found in most web services and abstracts them so that you can quickly write web APIs without having to write too much code.

Apify exposes similar APIs as the Zend Framework, so if you are familiar with the Zend Framework, then you already know how to use Apify. Take a look at the UsersController class.

Demo

You can see it in action here: http://www.youtube.com/watch?v=7ptoB0yCsDo

Download

Apify is hosted on GitHub. You can fork it or download it in either .tar.gz or .zip formats.

Written by Federico

July 22, 2008 at 9:07 pm

FileSyncTask: Using Phing to synchronize files and directories

with 16 comments

I needed to automate the task of synchronizing files from one server to another, so I wrote a Phing task. Finally today I found some time to finish writing the documentation.

Overview

FileSyncTask is a Phing extension for Unix systems which synchronizes files and directories from one location to another while minimizing data transfer. FileSyncTask can copy or display directory contents and copy files, optionally using compression and recursion.

Rather than using FTP or some other form of file transfer, FileSyncTask uses rsync to copy only the diffs of files that have actually changed. Only actual changed pieces of files are transferred, rather than the whole file, which results in transferring only a small amount of data and are very fast. FTP, for example, would transfer the entire file, even if only one byte changed. The tiny pieces of diffs are then compressed on the fly, further saving you file transfer time and reducing the load on the network.

FileSyncTask can be used to synchronize Website trees from staging to production servers and to backup key areas of the filesystems.

Usage

There are 4 different ways of using FileSyncTask:

  1. For copying local files.
  2. For copying from the local machine to a remote machine using a remote shell program as the transport (ssh).
  3. For copying from a remote machine to the local machine using a remote shell program.
  4. For listing files on a remote machine.

The SSH client called by FileSyncTask uses settings from the build.properties file:

sync.source.projectdir=/home/development.com/public
sync.destination.projectdir=/home/staging.com
sync.remote.host=server.com
sync.remote.user=user
sync.destination.backupdir=/home/staging.com/backup
sync.exclude.file=/home/development.com/build/sync.exclude

Listing files

The “listonly” option will cause the modified files to be listed instead of transferred. You must specify a source and a destination, one of which may be remote.

<taskdef name="sync" classname="phing.tasks.ext.FileSyncTask" />
<sync
    sourcedir="${sync.source.projectdir}"
    destinationdir="${sync.destination.projectdir}"
    listonly="true"
    verbose="true" />

Excluding irrelevant files

To exclude files from synchronizations, open and edit the sync.exclude file under the build/ directory. Each line can contain a file, a directory, or a pattern:

*~
.svn
.htaccess
public/index.development.php
public/images/uploads/*
build/*
log/*
tmp/*

Copying files to a remote machine

The following task definition will transfer files from a local source to a remote destination:

<taskdef name="sync" classname="phing.tasks.ext.FileSyncTask" />
<sync
    sourcedir="${sync.source.projectdir}"
    destinationdir="${sync.remote.user}@${sync.remote.host}:${sync.destination.projectdir}"
    excludefile="${sync.exclude.file}"
    verbose="true" />

Example

Directory structure

In order to separate the sync settings from the main build file, I’ve created a file called sync.properties:

development.com
|-- build
|   |-- build.properties
|   |-- build.xml
|   |-- sync.exclude
|   `-- sync.properties
`-- public
    `-- index.php

XML build file

Phing uses XML build files that contain a description of the things to do. The build file is structured into targets that contain the actual commands to perform:

<?xml version="1.0" ?>
<project name="example" basedir="." default="build">
<property name="version" value="1.0" />

<!-- Public targets -->
<target name="sync:list" description="List files">
  <phingcall target="-sync-execute-task">
    <property name="listonly" value="true" />
  </phingcall>
</target>

<target name="sync" description="Copy files">
  <phingcall target="-sync-execute-task">
    <property name="listonly" value="false" />
  </phingcall>
</target>

<!-- Private targets -->
<target name="-init" description="Load main settings">
  <tstamp />
  <property file="build.properties" />
</target>

<target name="-sync-execute-task" depends="-init">
  <property file="sync.properties" />
  <if>
    <not>
      <isset property="sync.verbose" />
    </not>
    <then>
      <property name="sync.verbose" value="true" override="true" />
      <echo message="The value of sync.verbose has been set to true" />
    </then>
  </if>
  <property name="sync.remote.auth" value="${sync.remote.user}@${sync.remote.host}" />
  <taskdef name="sync" classname="phing.tasks.ext.FileSyncTask" />
  <sync
    sourcedir="${sync.source.projectdir}"
    destinationdir="${sync.remote.auth}:${sync.destination.projectdir}"
    backupdir="${sync.remote.auth}:${sync.destination.backupdir}"
    excludefile="${sync.exclude.file}"
    listonly="${listonly}"
    verbose="${sync.verbose}" />
</target>
</project>

Execute task

$ phing sync:list

Outputs:

Buildfile: /home/development.com/build/build.xml

example > sync:list:
[phingcall] Calling Buildfile '/home/development.com/build/build.xml'
            with target '-sync-execute-task'

example > -init:
[property] Loading /home/development.com/build/build.properties

example > -sync-execute-task:
[property] Loading /home/development.com/build/sync.properties
[echo] The value of sync.verbose has been set to true

Execute Command
----------------------------------------
rsync -razv --list-only -b --backup-dir

Sync files to remote server
----------------------------------------
Source:        /home/development.com/public
Destination:   user@server.com:/home/staging.com
Backup:        user@server.com:/home/staging.com/backup

Exclude patterns
----------------------------------------
*~
.svn
.htaccess
public/index.development.php
public/images/uploads/*
build/*
log/*
tmp/*

(list of files that have changed)

BUILD FINISHED
Total time: 1.9763 second

More information

Related Articles

Written by Federico

July 21, 2008 at 12:03 am

Using Annotations in PHP

with 10 comments

Annotations provide data about a program that is not part of the program itself. They have no direct effect on the operation of the code they annotate. In PHP, annotations can only be read reflectively at run time.

Basic concept of Annotations

  • Add meta-data to classes, methods, properties
  • Do not (directly) affect program semantics
  • Can be used by tools or libraries
  • Can be parameterized or simple marker annotations

Addendum is a PHP library that supports single-value and multi-value annotations. There are three annotation types:

Marker

Marker type annotations have no elements, except the annotation name itself.

Example:

class Persistent extends Annotation {}

Usage:

/** @Persistent */
class Person {
    ...
}

// by class name
$reflection = new ReflectionAnnotatedClass('Person');
// by instance
$person = new Person();
$reflection = new ReflectionAnnotatedClass($person);
// true
$reflection->hasAnnotation('Persistent');

Single-value

Single-value type annotations provide a single piece of data only. This can be represented with a data=value pair or, simply with the value (a shortcut syntax) only, within parenthesis.

Example:

class Table extends Annotation {}

Usage:

/** @Table("people") */
class Person {
    ...
}

// by class name
$reflection = new ReflectionAnnotatedClass('Person');
// contains string "people"
$reflection->getAnnnotation('Table')->value;

Multi-value

Multi-value type annotations have multiple data members. Therefore, you must use a full data=value parameter syntax for each member.

Example:

class Secured extends Annotation {
   public $role;
   public $level;
}

Usage:

/** @Secured(role = "admin", level = 2) */
class Administration {
    ...
}

// by class name
$reflection = new ReflectionAnnotatedClass('Administration');
$annotation = $reflection->getAnnnotation('Secured');
// contains string "admin"
$annotation->role;
// contains integer "2"
$annotation->level;

More information

Related Projects

Written by Federico

July 19, 2008 at 11:39 am

Posted in PHP, Programming

Follow

Get every new post delivered to your Inbox.

Join 1,033 other followers