In a new post to his site Derick Rethans talks about "analemmas" and shows how to use PHP's own DateTime handling to determine the locations of the sun at different intervals (that's what an "analemma" tracks).

Last week I listened to an The Sceptics' Guide to the Universe where the word of the week was "But as I am currently starting to update the Guide to Date and Time Programming for a second edition, I was wondering whether I could create an analemma from existing PHP functions. Unfortunately, PHP only provides functionality to calculate when the Sun is at its highest point, through date_sun_info().

He includes an example of this function in use to determine the time the sun was at its zenith. While PHP by itself can't calculate the position, Derick remembered a PHP extension he wrote that could help: php-solarsystem. He includes some code using this functionality to iterate and locate the sun via its azimuth and altitude based on his choice of location (London). The result is a CSV export of data that he then drops in to gnuplot to create the graph of the analemma during that time.

On the Stitcher.io blog they've shared a post that makes some suggestions about where a curly brace belongs and how that might differ from situation to situation.

Dedicating a whole blogpost to curly brackets might seem like overkill but I believe it's worth thinking about them. Not just because of one curly bracket, but because there's a bigger message in all this. Thinking about how we read and write code not only improves the quality of that code, it also increases our own and others ease of mind when working with it. It can improve the fluency of your work and free your mind to think about real important stuff.

[...] I wrote about visual code improvements a while back in a previous blogpost about cognitive load. Today I want to focus on that one little, yet very important character in our codebase: the curly bracket. More specifically, we're only going to look at the opening curly bracket, because there's little to no discussion about the closing one.

The post goes on to show several different example situations and where they think the "most correct" placement for the curly brace is. They alos talk about the difference between their use on constructors versus control structures. The main recommendation, however, is to keep things consistent across the codebase.

In a new post to his site Leonid Mamchenkov talks about feature flags, a handy tool you can use in your application to enable/disable features and or risky changes in your code allowing you more production-level control.

Today edition of the “Four short links” from the O’Reilly Radar, brings a quick overview of the different feature flag implementations. It touches on the following: Command-line flags, with the link to gflags, A/B flags, Dynamic flags [which are more difficult] and more complex systems.

I’ve dealt with feature flags before, but never found an elegant way to scale those. [...] These days, something more robust than that is necessary for some of the projects at work. Gladly, there are plenty of available tools to choose from – no need to reinvent the wheel.

He talks about some of the challenges that he had in his own feature flag implementation including naming of the flags and where the flags should be placed. He then links to the PHP Feature Flags site and various PHP libraries that implement feature flags slightly differently and cover cookie-based, IP-based and URL-based features. He ends the post by pointing out that the lack of feature flags in any complex application is usually considered toxic when it comes to being able to scale an application correctly.

Loïc Faugeron has posted the latest in his "Mars Rover" tutorial series to his site today. In this new post he migrates some previously created objects over into their own package to help with reporting back the rover's location.

In this series we're building the software of a Mars Rover, according to the following specifications. It allows us to practice the followings: Monolithic Repositories (MonoRepo), Command / Query Responsibility Segregation (CQRS), Event Sourcing (ES) and Test Driven Development (TDD)

We've already developed the first use case about landing the rover on mars, and the second one about driving it. We're now developing the last one, requesting its location. In this article we're going to move geolocation value objects (Location, Coordinates and Orientation) into their new package (geolocation).

He then moves over the files relating to these objects into the "Geolocation" directory and fixed the namespace to reflect the update. Tests are all still passing so he moves over to the "navigation" package and fixes a few places in the tests where these objects were mentioned (doing the same for the "orientation" handling). This finishes out the series with a complete set of classes and objects reflecting the requirements. He summarises the work that was done, how the resulting code is structured and the major role that the phpspec testing played in the whole process.

The QaFoo blog has a new tutorial posted showing you how to work with PHPUnit and database testing for acceptance testing of your application. Acceptance testing (or integration testing) generally exercises the tests with live data from a database rather that stubbed or mocked data in true unit testing.

Most of us do not use PHPUnit solely for Unit Tests but we also write Integration or Acceptance Tests with PHPUnit. One very common question then is how to interact with the database correctly in those tests. Let me show you the different options and their trade offs...

There are multiple aspects of database tests where our decision has impact on test atomicity and test runtime. All decisions boil down to: More test atomicity leads to longer test runs, and we can buy test speed by omitting test atomicity.

They talk more about the time added for testing with database functionality included and where running them might be most appropriate (local vs on the CI server). The article then talks about one of the main decisions around doing a full data/schema reset or just removing data when the tests start or end. They then get into this last point - where the reset should happen, before or after the tests are executed. They talk in detail about each option, breaking it down into a few options: before each test, before each test class or before the whole test run. The post ends with a section talking about "mocking the database away", a method usually used in traditional unit testing but points out that this can be highly prone to errors, especially if you attempt to replace one database system with another (like replacing MySQL with SQLite).

Loïc Faugeron is back with the next part of his "Mars Rover" series (you can find all of the articles so far here with his latest post covering the Locating class' geolocation functionality.

In this series we're building the software of a Mars Rover, according to the following specifications. It allows us to practice the followings: Monolithic Repositories (MonoRepo), Command / Query Responsibility Segregation (CQRS), Event Sourcing (ES) and Test Driven Development (TDD)

We've already developed the first use case about landing the rover on mars, and the second one about driving it. We're now developing the last one, requesting its location. [...] In this article we're going to create a new package for the geolocation value objects (Location, Coordinates and Orientation).

He starts off by creating the geolocation package and its matching composer.json file. He then creates the phpspec configuration for the package and commits this initial version. He pulls this new package into the larger current codebase and makes an update to the overall phpspec configuration to run its tests. With that in place he updates two related packages, location and navigation, to include the new library before integration (coming in the next part of the series).

Loïc Faugeron continues his "Mars Rover" series of posts today with the latest in the series covering the "Locating" handler, the functionality responsible for handling requests for the rover's location.

In this series we're building the software of a Mars Rover, according to the following specifications. It allows us to practice the followings: Monolithic Repositories (MonoRepo), Command / Query Responsibility Segregation (CQRS), Event Sourcing (ES) and Test Driven Development (TDD)

We've already developed the first use case about landing the rover on mars, and the second one about driving it. We're now developing the last one, requesting its location

He makes use of the command bus pattern to create the handling for the module, doing validation in the Command object and a Bus to handle the command and perform its task. He starts, as usual, with the phpspec tests defining a class that can use a "find latest location" type instance and a "find" method to abstract out the location repsonse.

Loïc Faugeron continues his long running series covering the creation of a "Mars Rover" package to help teach programming fundamentals. In this latest tutorial he starts on the last use case in the project: requesting the location of the "rover".

In this series we're building the software of a Mars Rover, according to the following specifications. It allows us to practice the followings: Monolithic Repositories (MonoRepo), Command / Query Responsibility Segregation (CQRS), Event Sourcing (ES) and Test Driven Development (TDD). We've already developed the first use case about landing the rover on mars, and the second one about driving it. We're now going to start developing the last one, requesting its location:

Mars rover will be requested to give their current location (x and y coordinates and the orientation).

In this article we're going to create a new package for the location logic.

He starts by giving a justification as to why a new package is being created just for the location requests (when the navigation package could just be asked for that information). With that explained, he starts in on creating the new package and its tests with phpspec. He then adds this package into the current project's Composer configuration and updates the phpspec configuration to tell it about the newly creates code.

Alejandro Celaya has a post showing how he recommends working with sub-namespaced modules in a Zend Framework 2 application. It's based on a previous series of articles on the same topic but improves the methods for handling.

The solution provided in those articles was functional, but it introduced some new problems to deal with. It happens that after some time working with sub-namespaced modules I have found the best way to solve those new problems, and I wanted to write this new article explaining it.

He starts with the two main problems with the use of sub-namespaced modules: the autoloading of the module's files and how it resolves the locations of view scripts. Fortunately, the solution to both issues turns out to be "really easy". Composer's autoloading means that just changing the directory structure helps there and and update to the controller_map value helps with locating view files.

A new proposal has been made to the PHP-FIG group that would provide resource locator functionality as a standard part of an application's structure.

This specification proposes to refer to files and directories through URIs. [...] These URIs can have different schemes ("classpath", "file" etc.), but only the scheme "file" is specified in this document. The resource locator is able to turn URIs into file paths which can be read or included by PHP code. The general goal of this PSR is to locate files (PHP, XML, YAML, INI, JPG, etc.) and directories in a generic way. For example, there should be a unified notation to refer to the file of a class ABCD and other files located in the same directory (or nested directories).

Code snippets are included showing a pseudo-code interface to this locator with five requirements:

• Locate files relative to classes
• Locate both directories and files
• Short identifiers when the context is known
• Locate resources independent from PHP classes
• Support resource overriding

There's also some definition as to what is meant by a "resource location" and how the URIs should be structured and located.