Slawek Lukasiewicz has a new post today about working with dates and times in PHP on a more object-oriented fashion than in the more traditionally procedural way of just calling PHP date/time functions on the string values.

Date and time manipulation in PHP is mostly connected with functions like: date, time or strtotime. They can be sufficient, but if we want to deal with dates like with objects - we can use DateTime class. DateTime class is not only straightforward wrapper for standard functions, it has a lot of additional features - for example timezones.

He shows how to use the DateTime functionality to return an object you can call several different methods on. He gives examples of the formatting call, comparing one DateTime object to another, how to update the date after the object's created, calculating the difference between two dates and iterating through a certain time period.

Aleksey Martynov has submitted a new tutorial showing you how to (create a) "blog in 15 minutes" with the help of the lexa-tools framework, a set of utilities that gives you a procedural API to some handy tools.

The tutorial walks you through all the steps you'll need:

• setting up the environment
• creating a site skeleton
• making the blog posts model (with the CRUD generator)
• make the main page to display the latest posts
• adding comments
• creating a page for each posts's detail
• and the comments view

If you'd like to just skip to the end, you can download the source here.

James Cohen has a new post to his blog today looking at some of the built-in functionality that PHP has to work with dates and times including simple things like strtotime and the DateTime feature.

A lot of people ask questions relating to date and time in PHP. Here are some answers to the most commonly asked questions and common mistakes.

He covers the differences between working with dates in strtotime, worrying about timezone settings and compares the strtotime/DateTime methods for formatting and returning dates, modifying dates, converting between timezones as well as finding the difference between two timezones.

According to this new post on the Web Builder Zone, the results of a poll taken about the best programming method for PHP these days is - by far - object-oriented programming.

After two weeks of gathering votes, the PHP paradigms poll is now closed. With 216 votes (73%), the winner paradigm in popularity is Object-Oriented Programming. The old procedural approach to PHP, which has given fame to Wordpress and Drupal, is coming to an end. Even Drupal 7 has an object-oriented database layer as a primary component, and this paradigm is by far the most diffused in the world for web sites and applications written in high level languages (different from C).

While the overwhelming amount of votes went to OOP, there were still a few for some of the other options including the second place winner - procedural programming. He also talks a bit about OOP's current place in the PHP ecosystem and how it has allowed for certain great tools to be developed, but how it also has a good ways to go in functionality.

If you're just making the move from procedural PHP development into the next level - object oriented programming - and are having a bit of trouble getting the hang of it, you might want to read this new tutorial from NETTUS.com introducing the topic.

For many PHP programmers, object-oriented programming is a frightening concept, full of complicated syntax and other roadblocks. As detailed in my book, Pro PHP and jQuery, you'll learn the concepts behind object-oriented programming (OOP), a style of coding in which related actions are grouped into classes to aid in creating more-compact, effective code.

He introduces the concepts behind objects and working with them in your code first then moves into how they relate to classes (with a housing metaphor). He talks about class structure, properties, methods (both magic and user-defined) as well as using __toString, visibility and using DocBlock comments in your code. They also have a comparison between procedural code and object-oriented code in the form of a few reasons to lean towards OOP.

Giorgio Sironi has a new post that warns you of the dangers that could come from the use of a technology just recently introduced to PHP - late static binding.

There's a lot of (justified) excitement about PHP 5.3 new features, such as the support of namespaces and anonymous functions. Though, some glittering capabilities of the language are definitely not gold: the goto statement is probably the most debated example, but also the long-awaited Late Static Bindings support is an hammer which may hurt your fingers...

He talks about how two of the characteristics of late static binding - the fact that it involves something being static and that there's a sort of hierarchy involved. He gives a code example of how it could be used and notes that static functions should be used sparingly since they are a more procedural way of doing things.

The post also includes a good example - an abstract Factory method - and a bad example - Active Record that doesn't evolve towards a Repository pattern being used.

Doug Brown asks a question on his blog today that is coming up more and more, especially on those programmers new to the language that don't quite get what frameworks really have to offer. Do you really need a framework for writing PHP?

The simplicity in using PHP sometimes acts against it. Since there are very few coding restrictions, developers tend to write a bad code. The answer to this is definitely to use a framework. There are various PHP Frameworks available today like Zend Framework, CakePHP Framework and CodeIgniter. They provide a strong organization for your application and follow the commonly used MVC pattern.

To help out those new to frameworks, offers a few things they have to offer that normal procedural/library-based development may not. These include maintaining code standards, attractive URLs and getting help when you need it from other developers using the same system.

Eran Galperin has a few misconceptions in web development posted to his blog today (for both front and back-end development).

Here's his list:

• OO code is less performant than procedural code
• The backend is the most important part of development
• Graphical designers are good at user interface design
• The existence of a superior programming language
• XML is more economic than a DB

While the others touch on some topics that could be PHP related, he focuses on it in #1. He points out that sometimes making classes and objects and interfaces and...well, you get the idea...is just too much and that procedural code can be the quick hit you need.

In a new post to his blog, Jacob Santos talks about why object oriented programming just "isn't easy" - including a few of his dislikes about OOP in PHP.

Functional developers have it easy. Damn straight and I wonder why so many developers choose to write functions, when they can opt for more beautiful classes instead. [...] It is easy to get functions right, all you have to do is prefix them and name them properly and you're done.

He notes that most people get OOP up to a certain point - that being the "has-a" and "is-a" relationships - where things start flying over their heads. He expresses his dislike of the way that Singletons are used (or not used) and places some of the blame on the tutorial and book authors out there trying to teach novice programmers with analogies that don't make sense in a codign situation.

Richard Davey takes a look at some of the resource levels used for creating an image with GD in his latest blog entry:

While working on a project I noticed some interesting issues regarding GD images and the amount of memory they take up simply down to where you store them in your PHP script. If you are working with GD a lot then reading this short entry might save you some time / RAM! Update: I've also discovered something very interesting relating to autoloading classes, which again is related to memory allocation.

He was setting up to make a thumbnail from an image and thought to check some benchmarks on memory usage after three different methods:

• normal, procedural code
• putting the image resource into an object array
• storing the image resource in an object variable

In the end, the results were pretty much expected - the procedural (object free) method came in lowest, while the other object-related options had more overhead. It was interesting (as he mentions too) to see the jump between procedural and the object options.