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.
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).