Nowadays developing web applications usually requires a flexible process due to changing business logic, shifting priorities or new insights. Besides choosing the right methodology this also requires designing the application in such a way that this flexibility can be achieved. [...] In this article I will show how to implement a specific case using Doctrine 2. Full code accompanying this article can be found on GitHub.

He starts by describing the entities (User/TimeSheet/TimeSheetStatusChange) and how they're defined in Doctrine objects. He modifies them to build in some business-level restrictions like "status changes are only allowed in a certain order". He shows that the domain models presented are about more than just working with the database tables. They enforce rules that effect the flow of the application as well.

We wanted not only for people to be able to visit a profile and see a score, which is easy to generate a score on demand. We wanted our users to be able to browse other profiles sorted by their score with them. This requires us to pre-generate and store these scores, and then later query them. [...] I believe we could have bent MySQL to our will and got it to work, but it would be at a high cost of server power, and that cost wouldn't scale well with our revenue stream.

He talks about some of the other options they sorted through including NoSQL databases or building something completely in-house. In the end, though, they decided that Redis was more of what they needed. He prefaces talking about their configuration with some of the limitations of the tool and then moves into their setup and statistics on its use (complete with pretty graphs). He points to predis as their Redis client of choice for PHP.

Physical interfaces such as button panels or remote controls have many disadvantages. Panel controls require a dedicated display for feedback and physical access to a fixed location. IR remote controls offer only one-way communication with limited feedback and can become difficult to manage for multiple devices. [...] We propose a new type of solution to address these issues and bring simplified management and control to a broader market through embedded virtual interfaces.

He lays out the structure of the application, some of the issues that could come up in the connection (using COMET and Websockets). His proof of concept is a connection to a HDMI switch that can be talked to through an embedded controller via a simple interface.

In this article we'll focus on a case study on enterprise software where the porting failed, to list the issues of introducing a web application into the enterprise, and hopefully pave the way for future successes. This is kind of a written retrospective.

He briefly touches on some of the advantages first, mentioning the portability they offer and the fact that it's an "automatic upgrade" for users without having to install additional software. He also talks about a case study of an application that failed but also covers things learned along the way like:

• How complex the domain the application lives in could be (enterprise needs from enterprise software)
• Worries about data portability
• Struggles with the limitations of the browser (like working with large file downloads)
• and, of course, the huge amount of requirements that come with the application just because of the needs of the company

We've been running a small educational non-profit - Edulogos - for over three years now. Until recently edulogos.org has been little more than a Wordpress blog with a few extra pages and an off the shelf theme. [...] We decided it was high time to redesign the site and move it over to Drupal to give it room to grow. Like repotting a plant. "Liefde en substral", as they used to say in our home country.

They talk about the planning stages of the move - what version control they were going to use, which Drupal modules they were going to install - and walk you through the installation and configuration process step by step. They used git and github as their chosen method for deploying the site.

Proper interaction with relational databases is incredibly important in most pieces of software. The importance of this interaction is underscored by the fact that many software architectures have at least one entire layer or system devoted to data persistence and data loading. When dealing with critical data in enterprise level applications it becomes even more important to make sure your data is being stored and retrieved correctly.

He talks about a case study on the topic (still in development) that will talk about testing techniques, functionality and how to create the tests needed to ensure your development environment can correctly use the database resource via unit tests and functional tests.

The problem. The PHP implementation [of the IP2C library] is a lot slower. Embarrassingly slower. Without any caching the Java version is able to do ~6000 queries per second. The PHP counterpart can push through ~850 queries. The implementations are the same. The stats provided by the author of the library are 8000 vs 1200. So about the same as my measurements.

He details the script, showing what parts the script is taking up the most time on. A large part of the execution is tied up in IO and the fseek/fread and readShort/readInt functions take up a good chunk.

He even tries removing the functions and making things a bit more streamlined. This helps, but still lags behind its Java brother. Check out the post for more statistics comparing the two.

He mentions:

• A case study of an online survey generator
• info about Unicoding and UTF-8
• Iconv and mbstring
• and the migration of the application to support Unicoded characters (a nine step process)

And also, a word of warning:

Everything was much more complex than expected. Don't do this because you think that UTF-8 is cool, it's difficult, not well supported in PHP, and don't do it without needing it. Don't do this without a CVS.