Sameer Borate has a new post to his site sharing a method for converting a CSV to an Excel document using PHP. While you can open a CSV file with Excel correctly, using this method (and library) allows for more control over the end result.

During a recent data conversion project I needed to convert around 250 CSV files to Excel (xls) format. As this was a PHP project I decided to write a small PHP script using the PhpSpreadsheet library.

He then walks through the installation (via Composer) and use of the library to take in a simple CSV of countries and write it out as a .xls file in a single worksheet. He also includes a modification of the script that can be run from the command line, taking in arguments for the source file and the destination.

In this post to his site Ignace Nyamagana Butera shares a a helpful thing you can do with the regular expression handling in PHP to help make it a bit more clear: embedded comments.

One of the most challenging aspect of using regular expressions is documenting them. More than often you end up with a complex expression that even you as a creator have a hard time documenting. While reading sitepoint recent article around regular expressions I was intrigued that this article did not feature any tips on how to document them. So let’s take a very complex regular expression and see how we could improve its documentation.

He gives an example of a complex regular expression used to parse a URI into its different parts, including an example URI and the resulting parsed array. He points out that, while the regular expression works fine, it's easy to forget what each part does and as it is quite complex. To help remedy this, he includes an example of a commented regular expression (available since PHP 5.2) where you have two options:

• add in named subpatterns with a special < and > notation
• put in literal comments by breaking up the regex into multiple lines and using the hash (#) to mark of the comment at the end of the line

He includes code examples of both of these, resulting in a much clearer, memorable regular expression where the increased number of lines is a good trade-off for clarity.

In his latest post Derick Rethans shows how to parallelize document retrieval from a MongoDB database via PHP. This makes it possible to speed up the read operation caused by reading each item one at a time.

MongoDB 2.6 has a new feature that allows you to read all the documents from one collection with multiple cursors in parallel. This is done through a database command called parallelCollectionScan. The idea behind it is that it is faster then reading all the documents in a collection sequentially.

He includes an example snippet that enables the "parallelCollectionScan" handling for a "cities" collection and the resulting output. He shows how to manually create MongoCommandCursors (or let the driver do it for you) and use PHP's own MultipleIterator to process all of the cursors at essentially the same time.

If you've been wanting to get into document databases (NoSQL stuff) but haven't had a good beginners guide to look at, Derick Rethans has just the post for you. It introduces some of the concepts behind these databases with just a splash of how to use it in PHP.

By now most you will probably have heard of the term NoSQL. It's a vague term that covers a lot of different types of database engines. The main classes of NoSQL databases are key/value stores, column databases, graph databases and document databases. [...] Apache CouchDB and http://mongodb.org/">MongoDB belong to the last category, Document databases. We will be looking extensively at MongoDB in this article.

He starts off with some explanation of basic terminology and quickly gets into some of the strengths of a document-oriented database. He talks about data models and collection interaction as well as an example query translated from ANSI SQL to the MongoDB format. He has a basic installation and configuration guide, both for MongoDB and installing the PHP driver you'll need to make the connection.

New on PHPMaster.com is the first part of their series about indexing in MongoDB, a method for optimizing your collections to make querying them even faster. They cover the five main types of indexes and situations where they can help.

Indexing is one of the more important concepts of working with MongoDB. A proper understanding is critical because indexing can dramatically increase performance and throughput by reducing the number of full documents to be read, thereby increasing the performance of our application. Because indexes can be bit difficult to understand, this two-part series will take a closer look at them.

They look at the default "_id" index, secondary, compound, multikey and multikey compound indexes. Example documents and results are included as well as some of the options that can be set on the index types to tweak performance. They finish up the article with a look at some of the limitations and considerations to think about when using indexing, including that they cannot be used with regex queries.

If you weren't able to attend this year's ZendCon conference and wanted to see Bradley Holt's talk about entity relationships and document databases, you're in luck - he's posted both the video and slides to his site. Here's his summary of the session:

Unlike relational databases, document databases like CouchDB and MongoDB do not directly support entity relationships. This talk will explore patterns of modeling one-to-many and many-to-many entity relationships in a document database. These patterns include using an embedded JSON array, relating documents using identifiers, using a list of keys, and using relationship documents. This talk will explore how these entity relationship patterns equate to how entities are joined in a relational database. We'll take a look at the relevant differences between document databases and relational databases. For example, document databases do not have tables, each document can have its own schema, there is no built-in concept of relationships between documents, views/indexes are queried directly instead of being used to optimize more generalized queries, a column within a result set can contain a mix of logical data types, and there is typically no support for transactions across document boundaries.

He also includes links to two of the tools he mentions in the talk - Doctrine CouchDB and the Doctrine MongoDB ORM.

On PHPMaster.com today there's a new tutorial from Lorna Mitchell introducing you to using Analog for error logging in a MongoDb connection. Because of the way the tool (Analog) is designed, it could be used anywhere - she just uses the MongoDB connection as an example because it integrates easily and efficiently.

MongoDB is an excellent fit for logging (and of course other things as well) for many reasons. For one, it is very VERY fast for writing data. It can perform writes asynchronously; your application wont hang because your logging routines are blocked. This allows you to centralize your logs which makes it easier to querying against them to find issues. Also, its query interface is easy to work with and is very flexible. You can query against any of the field names or perform aggregate functions either with map/reduce or MongoDB 2.2’s upcoming aggregation framework.

This article will show how you can use existing code to add a logging library to your code and log errors to MongoDB. You’ll also see how to query MongoDB from the command line and how to filter those queries to find the information you are interested in.

Analog makes it simple to log information in an easy to use, self-contained, extensible kind of way, offering writers for multiple output formats including: files, the FirePHP plugin output, email, POSTing to another machine and sending to a syslog daemon. She also mentions the different logging levels the tool makes available and how to filter down your logging results based on them (searched by "equal to", "greater than" and grouped by level).

PHPMaster.com has a new tutorial today for those wanting to get into the MongoDb document-driven (NoSQL) database but haven't known where to start. This tutorial walks you through some of the basics including setup and configuration of both the server and PHP client side.

There are a lot of implementations of the NoSQL concept, but one of the most famous and widely used NoSQL databases is MongoDB. I think it’s one of the most interesting NoSQL databases available currently, and it’s considered by many to be one of the easiest to use (which has helped it gain widespread adoption). In this article I’ll introduce you to NoSQL with MongoDB. You’ll learn how to install the MongoDB extension for PHP, and how to add, update, and retrieve document objects.

He starts with an introduction to MongoDB and links to their site to grab the latest version of the database. A few simple steps later (including a call to install the mongo PECL module) and your PHP install is ready to go. Code snippets are included showing how to connect to the server and insert/update/select document records.

In a new post to his blog Philip Norton shares a method for creating a thumbnail of a Word document with the help of PHP and LiveDocx (in this case, the component inside the Zend Framework).

Creating Word document icons is very simple thanks to a service called LiveDocx. LiveDocx was created as a web service to allow the easy creation of most document formats from a simple template. However, it is possible to send a normal Word document as the template file and get an image of the file in return.

You'll need a LiveDocx account to be able to use the service - there's a free option of their service that uses a shared server. Included in the post is a sample script that defines a LiveDocx connection, pulls in a local Word document for parsing and calls a "getBitmaps" method on the service to return the raw image data. This is pushed into an image (using GD) as a PNG.

On the PHP on Windows section of DZone.com today Giorgio Sironi has posted about a different sort of object mapping than is usually thought of with databases - object-document mapping.

The Data Mapper pattern is a mechanism for persistence where the application model and the data source have no dependencies between each other. [...] But everytime we talk about the Data Mapper pattern, we assume there is a relational database on the other side of the persistence boundary. We always save objects; we always map them to MySQL or Postgres tables; but it's not mandatory.

He talks about two projects, MongoDb_ODM and CouchDb_ODM, that the Doctrine project is working on to help make working with document-driven databases as simple as the usual ORMs. He includes a brief code snippet showing how the feature will work (hint: a namespace of Document instead of Entity). He lists some of the features - including the usual ORM capabilities, support for collections, cascade of persistence - and where you can get the latest code for it (from github and PEAR