Whether you want to call Drupal a CMS (Content Management System), a CMF (Content Management Framework) or a CMSomething, the 'C' always stands for Content. Content is where Drupal shines and is what it's designed for. [...] When an organisation is at a stage and mindset that they also want to manage their contacts and interactions effectively they will often need tools designed specifically for that function. These are generally referred to as a CRM, which stands for Client Relationship Manager or Constituent Relationship Manager, depending on the sector (For-Profit or Not-for-Profit respectively)

[...] What has a CRM got to do with Drupal? Nothing directly, but indirectly if you're looking to streamline your business operations and automate the ways people can interact with you, your CRM will need to work well with your website. [...] In this article, we will look at several of the big players in the CRM space that work well with Drupal, how they integrate or how developers can get them to integrate.

They start with a list of five of the seven options:

Roll it yourself

RedHen

CiviCRM

Salesforce

Sugar CRM

They also provide a few other options combining a few technologies: Microsoft Dynamics and BlackBaud or Nation Builder and Salsa. Links and a brief summary of the project are included for each item in the list. He ends with a few tips about the actual integration, including the use of the CRM tool's API or using the Migrate Drupal module.

Anthony Ferrara has written up a great post on technical debt, relating it to terms that might be a bit more "real world" for many out there - corresponding financial problems.

Lately, I've found myself in a number of discussions about Technical Debt and how it applies to project development. Overall, I think it's a very powerful tool that -- when used wisely -- can be a great asset to any team. It seems to me that most of the people that I've been talking to really don't agree, and see Technical Debt as a plague that should be eliminated at first sight. So, I figured I'd share my opinions, and see what you think...

He talks about a few different kinds of technical debt described by the names of their financial counterparts:

the Payday Loan (a current concession for the sake of time)

a Mortgage (making small parts, payments, of a whole without consideration of the overall picture)

a Credit Card (not knowing the need causes a sub-optimal solution)

Hidden Debit (an unclear understanding of the full scope of the debt)

He also touches on two other topics - how to find and get rid of the Hidden Debt your project might have and a common misconception that technical debt doesn't exist in an aglie world.

On PHPMaster.com there's a recent tutorial introducing the concept of a "domain model" and showing how to create them in PHP (manually, not inside of any ORM or database solution).

First off, creating a rich Domain Model, where multiple domain objects with well-defined constraints and rules interact, can be a daunting task. Second, not only is it necessary to define from top to bottom the model itself, but it's also necessary to implement from scratch or reuse a mapping layer in order to move data back and forward between the persistence layer and the model in question.

They include an example of a set of domain models tat relate to one another - a blog setup with posts, comments and users. They show how to create the AbstractEntity to handle a bit of the magic behind the scenes, an example "Post" and "Comment" models and how they can be put to work creating some posts and appending comments. A little bit of markup is included to output the results.

In this new post to the PHP 10.0 blog today, Stas talks about duck typing, a method that lets the code decide the functionality to use rather than a direct relation to a parent.

Well, if you are into duck typing style of programming, it may be interesting for you to have an object that implements certain set of functions, but not necessary declares it at class definition. Languages like Smalltalk do it all day along, so why PHP couldn't?

His example defines an interface Cow and a class MooingGrassEater and a function, CowConsumer, that does the work. A classname is passed in and an instance of that class is checked with "implements" rather than "instanceof" to see if it uses the Cow interface. He points out a place where PHP itself uses something similar in user defined streams.

For me the coolest feature of PersistentObject is, that the component does not require you're ORM enabled classes to inherit from a certain base to allow your objects to be stored in a database (made persistent).

This new object gives you a "wapper" of sorts to make any of the pre-existing objects in your application persistent. Check out the article for more.