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.
In this second part of my Continous Integration setup I will detail the steps required to install SonarQube (previously called just Sonar, renamed to SonarQube with 3.6 release just a few days ago) and integrate it with the Jenkins server from the previous post so SonarQube will run a daily analysis of our PHP project. In the previous post I covered the installation of Jenkins on a CentOS server and integrated it with GitHub, so if you do not have Jenkins set up you might want to start there.
So why do we need Sonar if Jenkins is already setup with all the static code analysis reports as in the “Template for Jenkins Jobs for PHP Projects” ? Jenkins is great for running builds and it can be setup in a way that it generates useful reports about the source code, but Sonar has been specifically designed for this. It has a great user interface and gives so much better statistics. You can really easily see what direction the project is going and how much technical debt you are accumulating. You can drill down to different parts of the project and compare them, you can see how the code base has changed over time and compare different versions etc. This is especially useful with large projects that have a long lifespan so you can better keep track of code quality. You can also take action on the issues Sonar has found by assigning them to people. All the dashboards are customizable with loads of different widgets and all the widgets are also customizable so you can really make it your own and make the data that you care about the most easily accessible. SonarQube really takes the “static” out of static code analysis and makes it dynamic and interactive. You have to see it in action to really experience it, so I suggest you either watch a screencast or click around in the live demo.
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.
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.
So, this is the first post in my blog. I have been thinking about starting a blog for a long time and over the years I have had some great ideas for blog posts (which I have now forgotten all about), but never actually got around to actually start blogging. Mainly using the excuse “I just don’t have the time” to myself.
Currently I am working on a couple of posts related to unit testing a Zend Framework 1 application. And by mentioning them here I will hopefully have the motivation to actually complete them and post them.
I have been doing web development for almost 10 years now and mostly with PHP. I have been working most of that time at a Finnish software development company W3 Group (previously W-Create) where I am currently a partner and work as a team leader/lead developer. You can read more about me in the about page or contact me through the contact page.
So, here goes. I have started a blog. My expectations are not that high regarding post frequency (I have two small children that occupy most of my spare time) and certainly not regarding visitor numbers. But hopefully I will manage to keep this alive and post something every now and again. My main motivation behind starting this blog is that I want to improve my writing skills and also to have someplace to post random development notes for later reference. Thanks for reading and please post a comment if you find anything that you like (or don’t like).