I recently attended the PHPBenelux 2014 conference with a co-worker of mine. It was the 5th anniversary edition of PHPBenelux and the second time I attended the conference. It was held January 24th & 25th at hotel Ter Elst in Antwerp, Belgium.
In this post I will recap my experience at the conference and highlight what I found most interesting, fun or otherwise noteworthy.
So, why another “PHP 5.5 new features” post? I was doing research on the subject for a tutorial at work so I was digging through all the resources I could find on the subject anyway, so I decided to write a post about it. And also because even though there are many great posts already on this topic, I found that none of them were that comprehensive to list all interesting changes that come with PHP 5.5. The PHP manual also has a quite comprehensive documentation about everything that has changed with PHP 5.5 here, but it is scattered across many pages with some not so relevant information (for most PHP devs) in there also. The official ChangeLog also lists everything that has changed, but it obviously does not go into that much detail on any of the topics.
Here are the details how to install Jenkins CI server on a CentOS server (version 6.4 in this case) and set it up with GitHub integration so pushing to GitHub automatically triggers a build. Our project is a PHP project so the build will have PHP related stuff and we are going to use Ant as the build system.
MySQL triggers can be used to create some validation conditions that are a little bit more complex than what can be achieved with basic data types and unique index for example. The reason why data validation is better kept at the database level rather than application level is that in case the same data source is used by multiple applications, or even multiple interfaces within the same application, is that you can rely on the data being consistent and valid regardless the validation logic on the application side, which might not always be consistent across different implementations.
So why triggers are ideal for this kind of logic? Triggers can be executed before data is inserted or updated into the database, and you have the values that would be inserted to the database at your disposal, as well as the old values of the row in case of an update. The insert or update can also be prevented from actually executing from the trigger with an error message. This makes it an ideal place to consistently enforce some validation logic in my opinion.
After the recent PHP User Group Finland meeting I started thinking the presentation I gave at PHPUG Finland a few years ago and decided to post the slides here since I didn’t have a blog at the time to post them in. So, here are the slides from my PHP User Group Finland talk 24.11.2011 (in Finnish). The talk is titled Tietoturva Web -kehityksessä & Zend Frameworkissä (Security in Web Development & Zend Framework) and it was a two-part session between me first covering few of the most critical security threats in web applications and how to prevent them in Zend Framework and after that Matti Suominen demonstrated how these threats can be exploited in practice.
The topics covered in the presentation are SQL injection, Cross-site scripting (XSS), Cross-site request forgery (CSRF) and password hashing. After about 1,5 years, the points made and the tools presented in the talk are still mostly relevant, but Zend Framework 1 has since been surpassed by newer frameworks, namely Symfony2 and Zend Framework 2. So I decided to revisit these topics a little bit in this post in regard to todays standards.
Recently I had to update a Drupal multisite installation with 62 sites. The whole process felt a little bit daunting at first, but I managed to pull it off quite easily after all thanks to good preparation and research beforehand. So I decided to document my experience for later reference (to myself and others). Please share in the comments if you find it useful.
Drush is your friend
I had used Drush previously so I knew it can be a real time saver. For anyone reading this who is not familiar with Drush, it is a command line tool used to manage a Drupal installation and run all kinds of Drupal commands. Such as: run cron, clear caches, make backups, install modules etc. If you do Drupal development and are not using Drush, you really should. It saves you time and makes working with Drupal more enjoyable by not having to click around the Drupal admin interface that much. Drush is your friend.
In a multisite installation you have to tell Drush which site you want to run the command on (or if you don’t, by default the command will be run on the default site). Luckily there is also a @sites keyword that executes the command on all sites of a multisite installation. It will list all the sites and ask for a confirmation before executing, so you always know when you are running a command on multiple sites.
I decided to take the advice Jeff Atwood gave to a commenter who asked for advice on blog post ideas on a recent Lifehacker interview.
After I decided to start a blog I first needed to decide what software or service I was going to use. Blogger and other similar services are easy to get started with, but since I am a developer I like to have more control over a site I’m running. I already had some WordPress experience so the decision was quite easy after all.
Next thing I started thinking about was the theme. I have always liked a minimal design so I can do most of the work in a text editor rather than Photoshop or similar image editor. The WordPress default theme (twenty eleven at the time) was a good starting point. It is mostly black and white, it has a clean and minimalist look and it’s responsive, which is also something I wanted to get more experience with. I started out by creating a child theme and gathering some ideas. Since I am not that creative visually, my design process is mostly combining and tweaking ideas and concepts I like from other sites I have seen and using them to a create a design I like and that I can call my own.
Here are some of the things I customized from the default theme: search in menu bar, meta fields on the left, round RSS, Twitter & LinkedIn buttons in header, use Font Awesome for icons, use custom fonts from Google Web Fonts and also numerous small tweaks and style changes.
The source code for this theme is available at GitHub, so you can fork it if you like it. I would appreciate a comment or email if you decide to use it.
The design is not by any means final, I already have lots of ideas for small improvements. If only I had the time to implement them all. Currently it is good enough that I can live with it. Feel free to share your thoughts about it in the comments.
Testing controllers with PHPUnit is not actually unit testing per definition, but more like automated integration testing, functional testing or acceptance testing. Whatever you want to call it, it definitely is useful at times because you can’t always cover everything with unit tests. For example if you want to test control logic that is inside controller method or display logic that is in view templates, or just verify that all those different modules work together as expected. And to help achieve this, we have Zend_Test_PHPUnit_ControllerTestCase which makes it easy to execute the whole MVC stack and assert against wide variety of things like redirects, HTTP response codes and presence & contents of DOM elements in the produced HTML (and much more).
But since most of the applications we develop are so heavily database driven, I faced the problem of wanting to test a controller that behaves differently depending on data stored in the database. So I started thinking that there must be a way to use fixtures for the database the same way as when testing models with PHPUnit Database extension (PHPUnit_Extensions_Database_TestCase). But since PHP does not have multiple inheritance, we can’t extend both Zend_Test_PHPUnit_ControllerTestCase and PHPUnit_Extensions_Database_TestCase. So I started out to create a controller test case class that has support for fixtures the same way as the database test case. I mean, how hard can it be? Surely someone else has already done it and I don’t have to reinvent the wheel!
In this post I am going to describe the method we set up with a few coworkers for testing models in Zend Framework projects. We are using fixtures to ensure our database is in a consistent state for the tests and we wanted to run the tests on the same machine we are using for development, but usually the database you use for development is full of data that you don’t want to lose. We also wanted to be able to run the tests easily on any new dev machine, test server, continous integration server etc.
So we decided to use a completely separate SQLite database for testing. SQLite seemed ideal since it would not need anything installed or configured, it should just work on any machine. There is also the very handy in-memory database that is great for this use case, since the database is only needed while running the tests, it’s faster and it does not require any file/directory permissions to be modified in order to work.