In this recent post to his blog Stefan Koopmanschap shares some of the troubles (and a solution) when he was dealing with getting the Geoip PECL extension installed on his Zend Server setup in OSX.

Today I needed to get a client application up and running on my local system. This application uses the Geoip PECL package, so I needed to get this up and running. This turned out to be slightly more difficult than just a PECL install, as you're missing some libraries by default, so here is my log of things to do to get it up and running.

He gives the complete list of steps his followed including downloading the source and his way around this "System could not load this extension" issue. The trick was to recompile the source with the correct architecture. By default his extension was built with i386 instead of 64-bit but updating some of the CFLAGS settings (and a few other environment variables) got things compiling correctly.

On the Sankuru blog today the next post in the series about creating a compiler in PHP has been posted. In this latest tutorial he shows how to set up a plugin architecture for the compiler that allows you to quickly and easily extend it beyond its base functionality.

A plugin architecture allows multiple developers to work on the same application and let yet another person assemble their work later on. It allows the plugin developer to understand just his plugin API without having to understand all the details of the entire application.

He describes a few platforms that already have the concept of plugins including Joomla, Mediawiki and SugarCRM. He explains what a plugin architecture should be and what it shouldn't be. All of this is his first steps towards building a plugin-enabled compiler and virtual machine in PHP.

In this new post to Reddit.com, the question is asked "Should I be doing just about everything using REST?" - wondering if their new applications should all sit on top of a web service for their functionality.

I'm pretty new to server-side programming, and actually started out with Python/mod-wsgi. From the ground up, mod-wsgi made a lot of sense. The server gets a request, you route the request. It feels like that's where I should start, so that's pretty much what I'm trying to create with PHP (a REST router - for learning purposes, I know frameworks exist). I'm trying to think of a situation where I wouldn't use a REST interface, but I can't seem to think of one (even for simple cases). Would it be safe to say that using REST is a pretty safe bet, most of the time?

There's some good discussion and answers to his question touching on things like Service Oriented Architectures, some implications of having a web service power an entire application (or applications) and a few comments with some personal experience.

A comment about SOA sums it up well:

You learn to write for your platform in the way developers/partners will have to, so you produce a good quality usable API which encourages development and consumption of your platform.

On the Ibuildings techPortal today there's a new post from Robert Raszczynski about domain modeling and how a good knowledge of it can help your application's architecture.

Architectural and design patterns help software architects to break systems in to smaller, more maintainable sections organised by their functionality and usage. [...] There are three major layers in software architecture: presentation, domain and data source. [...] Now that we know what types of layers we can find in software architecture, let's have a look at how we can organize domain logic and data sources layers.

He looks at three patterns that can help organize your domain logic - a transactional script (one file that does one thing), a table module (logic lives in the tables) and his focus, the domain model. He shows (via a graph) how the domain logic approach can cut through some of the effort it could take to improve on the other two. He gives a two suggestions of how to access the data in your domain layer - a Gateway or a Data Mapper. To reinforce the ideas he's presented, he includes some code snippets of a basic domain model for a Store, Customer and Product and uses them in both Gateway and Data Mapper examples.

Padraic Brady has a new post to his blog asking you, the reader, for your suggestions on how to architect a distribution system for the PEAR2/Pyrus components.

With the idea of PEAR2 and Pyrus, I had hoped to see a renewal - the advancement of a PEAR architecture for the 21st Century. Instead, and this is just my opinion, PEAR2/Pyrus were a relatively simple iteration on a very old theme. [...] If the PEAR ecosystem has a failing, it is one of staggered evolution. Over time it has picked up additional features tacked on top of a base model.

He breaks up his thoughts on the future of PEAR2/Pyrus distribution into a few different topics - the issues he sees surrounding packaging (like static packaging definitions), suggestions for a dynamic channel aggregation system and overall usage of the PEAR system.

Paul Jones has a new post to his blog looking at two approaches to building applications in PHP - either using an include-based of class-based architecture, briefly looking at the advantages and disadvantages of each.

This is a topic I describe at length in my Organizing [Your PHP Projects] talk, but I would like to give the idea a home on my blog for easy reference.

He talks about the typical structure of a PHP application - at least where most start out - being the "include" method. He talks about the progression it usually makes into functions and classes and then, eventually, a jump in concept to the "class" method similar to what several popular frameworks have gone with.

The difference is that no program logic is executed at loading time with a class file. Loading the class file makes it available for use, but the programmer has to instantiate it and then call methods on it for anything else to happen.

In his latest post Daniel Cousineau talks about a good architecture decision (involving the Zend Framework) that allowed his company to stop on a dime and shift CDNs.

On the Test.ical.ly blog there's a recent post asking about good software architecture and how you could define it simply without having to muck around with all of the details it tends to conjure up.

What is a good architecture and why are there apparently two opposing trenches supporting quality on the one side and speed of development on the other side? After having had enough time to think about this whilst flying to Spain I came to the conclusion that Nils question whether it would be better to start quick and dirty to fail cheap in case the project is a looser or to stick to a clean and solid architecture and spend more time and money. Does quick always have to be dirty, clean always have to be slow, is dirty always quicker?

He suggests that "good architecture" and "quick and dirty" are the two opposite ends of the same spectrum. Instead, he suggests that a pragmatic approach is the best - focusing on what needs to be done rather that how to get there. Also by applying the "don't fix it if it's not broken" mentality to current methods and technologies, you can save a lot of hassle in the long run.

Larry Garfield has a recent post to his blog that outlines what he thinks are some of the top priorities you should take into consideration when architecting your next application - small or large - and lays that structure on top of what the Drupal project is doing.

Understanding architecture, and the trade-offs that different architectures imply, is an important part of any software project. [...] To be able to speak and think about the design of your system properly, though, you need to understand the trade-offs that come with it. There is no such thing as a free lunch, and designing a system to be powerful in one way invariably tends to harm it in another. It is important to know what your priorities are before you start building; and in a distributed collaborative environment like Drupal to all agree what those priorities are, at least to a large extent.

Talks about software architecture design patterns (like Model-View-Controller or Naked objects) including one that's not so much a pattern as an evolution - monolithic architecture. Among the list of things he suggests considering are subjects like:

• Modifiability
• Testability
• Performance
• Scalability
• Usability
• Maintainability

He compares this list to how the Drupal project is run and finds a large emphasis on extensibility, modularity, scalability. These came at the cost of testability, verifiability and understandability however.

When trying to load in the Redis module for his PHP installation, Jim Plush was getting an error:

PHP Warning: PHP Startup: Unable to load dynamic library '/[...]/redis.so' - dlopen(/[...]/redis.so, 9): no suitable image found. Did find: /[...]/redis.so: mach-o, but wrong architecture in Unknown on line 0

He fixed the issue with the help of a bash script (source included) that sets up the right environment to build PHP on the OSX platform. Then the normal make, phpize, etc process can be done on the PECL extension and have it compile correctly.