In a recent post to his site Marco Perone looks at the idea of "maybe" in PHP, having functionality that acts a default value if no value is present. This idea is implemented in other languages like Haskell and Elm.

Doing functional programming in a language as PHP, which is almost completely used as an imperative or object oriented way, is not always easy. Good progresses have been made thanks to the introduction of callable type hints in PHP 5.4 and the diffusion of functional interfaces like the ones present in PSR-7.

Still, all “good” PHP code is still written using objects and classes and the object oriented perspective on the world strongly influences even the most functional oriented libraries.

In this post I would like to propose as an example how we could implement the Maybe type in PHP. We will see how some open source libraries do this, we will see an alternative solution and we will raise concerns about some modelling issues.

He starts off by describing what the "maybe" functionality is and gives some examples of it in use in other languages. He points out that while there's several PHP libraries that implement this kind of default handling, it's not in the PHP core language. He works through some of these libraries and shows them in use: monad-php, Phunkie, php-maybe-monad and php-fp-maybe. He wraps up the post showing his own suggested implementation and how it could help resolve some of the issues he found with the other libraries as he worked through them.

Rob Allen has posted a quick tip for the Slim framework users out there showing how to use default route arguments in your application.

A friend of mine recently asked how to do default route arguments and route specific configuration in Slim, so I thought I'd write up how to do it.

He illustrates with a simple "Hello world" route that responds using the "name" value from the URL path. He then shows how to modify this example and define a default using the "setArgument" method on the route itself (for both single and multiple values). He ends with an example of how it can be applied for other values needed in the route as well, like a "role" for access control handling.

In a new post to his site Free Litjen talks about defensive programming and the part that sane default handling plays when dealing with exceptions that might pop up.

With over half a million visitors a week and lots of scrapers, bots and other stuff visiting, these exceptions and fatal errors clog up logging quite a bit. Not to the point that we can't handle the volume, but it generates false positives in monitoring channels and it is something we do not want to act upon anyway.

So while I'm happy to see some defensive programming I would be even happier if exceptional situations would be silently resolved to default situations.

The post starts with a quote about defensive programming and how, despite it not being an ideal use, many applications had been seen using exceptions to handle errors and messaging. He proposes another methodology where a set of default values are used instead of just failing on any error hit with the input. The idea has merit but it can also lead to other frustrations like hidden errors in testing and situations where an exception makes more sense than a default.

In his latest post Rob Allen shows a way you can override the default Twig date filter with your own custom Date extension handling.

In one project that I'm working on, I'm using Twig and needed to format a date received from an API. The date string received is of the style "YYYYMMDD", however date produced an unexpected output. [...] This surprised me. Then I thought about it some more and realised that the date filter is treating my date string as a unix timestamp. I investigated and discovered the problem in twig_date_converter.

He includes some example code you'll need to create the custom renderer. As part of the internals of how Twig formats the date currently is internal and can't be changed, he opted to override the extension itself. As a result, the call to the filter is exactly the same as before, the output results are just formatted more correctly.

On the Websanova.com site there's a recent post about doing timezones the right way when working with them in PHP and storing them in your (MySQL) database.

Timezones are actually a very trivial concept but they seem to be overlooked and over complicated. [...] Rather than storing a timezone with each date it’s better to just accept a standard time to store all your dates with, thus doing the conversion to that standard time before storing the value in the database. It doesn’t really matter what time we store it as, but it’s generally a good idea to just use UTC+00:00.

They talk a little about what the UTC timezone is for those that may not know and show how to set it as the default timezone for your PHP application (with date_default_timezone_set or updating your php.ini). They also include the MySQL configuration option to set its default timezone and and example SELECT statement for extracting the data back out.

Engine Yard/Orchestra, a PHP platform-as-a-service (PaaS) provider has announced the release of PHP 5.4 as a part of their cloud offerings:

We’re pleased to announce the general availability of PHP 5.4 for Orchestra PHP Cloud. We are committed to keeping your apps running on the latest and greatest version of PHP. After careful lab testing, we’ll upgrade your apps as newer versions of PHP become available. What if you’re still using PHP 5.3? Don’t worry, Orchestra PHP Cloud will continue to maintain its PHP 5.3 stack. You will be able to choose which version of PHP you would like to use when you launch a new app.

The default when you set up a new application will now be PHP 5.4, so be sure you're paying attention on setup if you need something else. You can find out more about the Orchestra PaaS on the Engine Yard site and try it out for free to see how your app performs.

In this new post (and this related article) Pádraic Brady shares some of his opinions about default security languages should provide and the Secure by Design principles.

Odd though it may seem, this principle explains some of PHP’s greatest security weaknesses. PHP does not explicitly use Secure By Design as a guiding principle when executing features. I’m sure its in the back of developers’ minds just as I’m sure it has influenced many if their design decisions, however there are issues when you consider how PHP has influenced the security practices of PHP programmers. The result of not following Secure By Design is that all applications and libraries written in PHP can inherit a number of security vulnerabilities, hereafter referred to as “By-Default Vulnerabilities”.

He focuses on what he sees as a responsibility of those creating the language to either default to a more secure architecture or provide information as to why their choices could cause problems. In the extended version of the post, he talks about some specific issues that the language has including SSL/TLS misconfiguration, openings for XML entity injection attacks and limited native filtering for cross-site scripting.

On PHPMaster.com today there's a new tutorial posted about using type hinting in your PHP applications to restrict the values passed into your methods.

Since PHP 5 you can use type hinting to specify the expected data type of an argument in a function declaration. When you call the function, PHP will check whether or not the arguments are of the specified type. If not, the run-time will raise an error and execution will be halted.

Included in the post are code examples showing how to define custom types in a function definition and what happens if you pass the wrong type in. Also mentioned is one of the main limitations to hinting - the fact that it can't be used on default PHP variable types.

Derek Allard has a quick post for the CodeIgniter users out there with some styling you can use on the default CI calendar.

A project I’m working on needs a monthly calendar. Naturally, I’m using CodeIgniter as the base of it. [...] My needs were something more akin to the interface iCal provides; broad, spacious, subtle. Obviously, the default is just an unstyled base that CI provides as a starting grounds. The Calendar library documentation provides some insight into how we can start changing this up.

He talks about the settings he needed to change including the "day_type" setting and template that specifies the CSS classes to use. Add in the CSS and you'll end up with something like this. You can download the example files too.

On the Zend Developer Zone there's a new post talking about including language information in your Zend Framework application's default route in a cleaner manner.

There are several ways how to include language id in default route of Zend Framework. However, generally you end up with the solution not quite elegant and likely not totally trouble-free. I have seen people overwriting the default route by new one which mimics module route with additional language id. There is no need to throw the default module route away to do this. To get it right chain the plain language route with default route.

He gives code examples of the routing code to put in your bootstrap that uses the Zend_Controller_Router_Route_Chain and a plugin to handle the language checking and routing handling.