I recently got a Olimex A20-OLinuXino-LIME mini computer as a speaker gift for speaking at the Bulgaria PHP Conference. It’s quite similar to a Raspberry Pi, it has few USB ports, Ethernet port, HDMI output and some GPIO pins to hook up some electronics. Quite a lot of GPIO pins actually, a lot more than on Raspberry Pi. And it runs Debian Linux from an SD card. So it’s perfect for doing some hardware hacking and I have been building something on it last week.
I decided to build a deploy button for a project I’m working on at work. We are using Jenkins CI server and Capistrano for deploying. So the idea was to show build status from Jenkins with two LEDs, green when last build has succeeded and red when last build has failed. And blink the LED while a build is in progress, just as the icons in Jenkins web interface. And then pressing a button would execute a deploy using Capistrano (if the last build was successful).
A week ago I attended the first Bulgaria PHP Conference that was organized on September 26th and 27th 2015 in Sofia. Even though it was the first PHP conference in Bulgaria, the event was a real success. The venue was spectacular, the atmosphere was laid-back but still enthusiastic and energetic and the speaker line-up was very impressive.
I could write a brief summary of all the talks I saw, or I could iterate over the things I learned, or tell you more about how well the conference was organized (but others have already done those). I thought instead that I would write about a topic that has been on my mind since the event. And that’s the PHP community.
Clean code is something that I have been interested in for a while now, and plan to write a series of blog posts about the different concepts related to clean code. In this introduction post to the series I will talk a little bit about what clean code actually is and also try to answer the question why should you care about clean code.
What is Clean Code?
Clean code is subjective and every developer has a personal take on it. There are some ideas that are considered best practice and what constitutes as clean code within the industry and community, but there is no definitive distinction. And I don’t think there ever will be.
After reading a few books on the topic, giving it some thought and delivering a couple of talks on the subject, if I had to summarize what clean code means in one sentence, I would say that for me:
Clean code is code that is easy to understand and easy to change.
Ok, that sounds nice, but what does it really mean? Let’s break that sentence apart and examine the individual points behind it.
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.