First, download the SDK. At the time of writing, the newest version is version 2.8. For 32 bit platforms:
If you are trying to get some test scripts running on Ubuntu 12.10 and you can't get the Intel SDK to work, here's a handy tip. Go over to the AMD website and download their AMD APP SDK. As long as your CPU supports SSE, the AMD SDK will provide you with OpenCL capabilities on any processor.
I was having trouble getting Intel's SDK to work, as well as their open source variant Beignet. Both versions did not reckognize any OpenCL platforms or devices. I am on a Intel Core I5 CPU with Intel HD Graphics 4000 (it's a shame I can't use that on Ubuntu yet, though I am happy to be running sample code now :-)).
For your convenience, here are the steps to download and install OpenCL on Ubuntu:
First, download the SDK. At the time of writing, the newest version is version 2.8. For 32 bit platforms:
Or for 64 bit platforms:
Extract the file you just downloaded and run the installer:
As a final step reboot your computer and then you should be able to run OpenCL applications on Ubuntu.
Recently I noticed some emails sent by Magento keep bouncing back. The mail server dropped me a few "Undelivered Mail Returned to Sender" messages. This is very undesirable, since this means that some order confirmations and/or invoices are not being delivered to the customer. After some investigation I discovered a Magento setting under System > Configuration > Advanced > System > Mail Sending Settings > "Set Return-Path". Set this value to "Yes" to make the Return-Path the same as the sender. Alternatively, you can set it to "Specified" and specify a "Return-Path Email" where all bounced emails get sent to. This can come in handy if you want to have those emails checked with priority for example, you could sent bounced mails to a priority mailbox instead.
Not specifying a Return-Path in Magento (ie. setting "Set Return-Path" to "No") will most likely get your emails blocked by a lot of spam filters.
This tutorial describes how to set up database replication for MySQL using SSL on Ubuntu 12.04. There are some tutorials out there, but I found out they are a little outdated and don't work as well any more (at least not for Ubuntu specifically). So I decided to write down my experience for other developers who find them selves setting up MySQL database replication to make their lives easier.
First, we start with setting up the master server. Last, we set up the slave server to download database changes from the master server. For the purpose of this tutorial we are going to replicate a database called 'exampledb' from a server at master.webdevelopersdiary.com to a server at slave.webdevelopersdiary.com.
Set up the master server
Setting up the master consists of the following steps:
The SSL certificates have to be placed in the /etc/mysql/ directory if you want them to work out-of-the-box. If you want to place them elsewhere, you first have to update the MySQL Apparmor settings, or SSL will fail. For the purpose of this tutorial, we will assume all the certificates will be in /etc/mysql/. The MySQL Manual explains very well how to generate the SSL certificates. I copied the steps here for your convenience. First, we generate the CA certificate:
Then create the server certificate, remove its passphrase and sign it:
Create the client certificate, remove its passphrase and sign it:
Install the certificates into to /etc/mysql/ directory:
Open /etc/mysql/my.cnf and make sure MySQL is listening on all interfaces so that the backup server can reach the database from the outside. Typically, there is a line like:
The line starting with “bind-address” should be commented out if present.
Also add the following in the [mysqld] section of the config file:
And enable SSL by editing:
Close /etc/mysql/my.cnf and restart MySQL to apply changes to the config by executing the command:
Next, we create a database dump of the database we want to replicate (exampledb). During the dump, we need to lock the database to determine the exact position from which we need to start replicating (corresponding to the database dump). So we write down the log ‘position’ column from which to start replicating on the slave.
Login to the mysql server (located at master.webdevelopersdiary.com) as root from command line (or use a web-based admin tool like phpMyAdmin to execute the required commands):
Execute the following SQL commands:
Write down the output of the last statement, you're going to need it later. An example output looks like:
Write down the output. Bring the MySQL console to the background (press CTRL+Z) and make the database dump:
`fg` returns you to the MySQL shell, execute the following SQL to finish up:
Copy exampledb.sql, ca-cert.pem, client-cert.pem and client-key.pem from the ~/mysql-tutorial/ directory to the slave server located at slave.webdevelopersdiary.com. Convince yourself there is no firewall running that is blocking SQL connections from the outside. That's it for the master server.
Set up the slave server
The steps for the slave server are:
Place all the .pem files you copied from master server into the directory /etc/mysql/ on the slave server. Start of your favourite editor and edit /etc/mysql/my.cnf and add the following lines:
Save and close /etc/mysql/my.cnf and restart the MySQL server. Then start up the MySQL console:
Execute following SQL to import database and start slave. Make sure you replace the correct values at MASTER_HOST, MASTER_USER, MASTER_PASSWORD, MASTER_LOG_FILE (from earlier written down value) and MASTER_LOG_POS (also from earlier written down value).
That's it, database replication should be up and running!
If you ever need to compile Quercus from source and install it into your local Maven repository, this post is just for you. You need to have Subversion (or Git), Maven and Ant installed. Here are the steps:
Some time ago I had to download the Resin/Quercus source from an unofficial mirror repository on github, because the official Caucho SVN repository located at svn.caucho.com was down. This mirror repository is still available, but at the time of writing it seems a little outdated. If you are interested, perform these steps instead:
The Quercus webapp is now installed in your local Maven repository as version 4.0-SNAPSHOT. Include in your project's pom.xml as follows:
If you would like to see the other build targets for Resin/Quercus, execute the following command:
Bonus tip: you can always find a recent version of the Quercus WAR file at http://www.caucho.com/download/quercus-4.0.x.war, replacing 'x' with the latest version, e.g. http://www.caucho.com/download/quercus-4.0.28.war. You can find the latest version number by looking at Caucho Resin's version number on the website's download page. I figured this out once by guessing URLs to download the latest version. The Quercus website is not updated frequently enough to keep up with newer releases, but the files are actually there.
If you ever find the need to compile H2 database yourself to install it in your local Maven repository, here are the steps:
Your custom H2 build is now installed in your local Maven repository as version 1.0-SNAPSHOT. Include it as a dependency in your project by adding the appropriate XML to your pom.xml:
I had to do these steps in order to test a fix I am preparing for H2 to solve the "SET NAMES" syntax error in MySQL compatibility mode when connecting to H2 using the Quercus PHP MySQL driver.
SQLite is a popular choice for PHP programmers to kick-start their development. It's easy, self-contained, requires no configuration, no server and all the data is kept neatly in just one file. Then later on, the application is commonly migrated to a production DBMS (e.g. MySQL). There have not been any alternatives for SQLite when developing in PHP with MySQL as a target platform. But then again, why would you want an alternative for SQLite? Well, to name a few reasons: MySQL compatibility and support for hash indices. And that's not all! Keep reading to see why.
When looking for alternatives to SQLite, I came across two suitable candidates: H2 database engine and a MySQL embedded version. My criteria were that the alternative should be as easy to use as SQLite and compatible with MySQL, based on two reasons. First, I wanted it to be compatible with MySQL so that I can keep using that easy self-contained database for development even after the application has gone into production. Second, an easy to setup database is great for bringing new developers up to speed with development as fast as possible.
Let's start with the good stuff. Below is a comparison of SQLite, H2 database engine and MySQL embedded version.
To me it looks like H2 database is the easiest to manage. It requires no server and everything is put neatly in one file, which makes back-upping and sharing databases among developers easier. It even has a nice extra feature over MySQL: encryption of data files (though I don't see a direct need for that during development for me personally).
I have experimented with PHP and H2 before and ran into some limitations (Quercus' MySQL driver doesn't play well yet with H2's MySQL compatibility mode so I have to use the Quercus' PDO driver instead). I haven't tried embedding MySQL yet, which is what I am going to try next.
The embedded version of MySQL has the big benefit of being 100% MySQL compatible, but it also has an uncertainty. I am not sure if it's okay to redistribute my application (containing embedded MySQL) among developers. Another limitation could be that I would have to buy a commercial license for MySQL should I choose to distribute embedded MySQL to customers (vs. customers setting up their own MySQL server). Though, it is okay to use MySQL embedded version for a website hosted by myself (it's not technically distributed in that case).
For now, I have not decided yet whether I will stick with H2 or switch to the embedded version of MySQL. I am going to give both a try and I will keep you updated via this blog!
In my previous post I explained how to setup PHP and H2 database engine using a platform-independent Java stack, a.k.a. JAMP. I managed to get the Code Igniter framework running on JAMP, with some tweaking of the Code Igniter PDO driver. Here are the steps to make it work.
If you would like to skip these steps and jump immediately into some coding action, download the demo.
(Unzip and go into directory jamp-ci-demo/, then type `mvn jetty:run` from the command line. You need Maven installed to execute this command.)
First, checkout a copy of JAMP at github (git clone https://github.com/webdevelopersdiary/jamp.git).
Then download Code Igniter and put in the web root (src/main/webapp/).
Because Code Igniter likes pretty urls (ie. /controller_name/method_name) I added support for mod_rewrite to JAMP. It can parse mod_rewrite rules which are located in .htaccess directly in the web root (src/main/webapp/). Add src/main/webbapp/.htaccess with mod_rewrite rules:
Start up the JAMP web server (make sure .htaccess exists before starting the web server or it will have trouble discovering it, then execute mvn jetty:run). Verify Code Igniter is running correctly by going to http://localhost:8080/welcome (the default controller).
If you see a pesky error '$assign_to_config is an undefined variable', go to src/main/webapp/index.php and add
under the section 'CUSTOM CONFIG VALUES' (line 110 of index.php) and that should get rid of the error.
Next we configure Code Igniter to connect to the H2 database using PDO. Edit the configuration located at src/main/webapp/application/config/database.php and set these settings:
Next, we have to make a slight modification to Code Igniter's PDO driver. Change the method num_rows() from src/main/webapp/system/database/drivers/pdo/pdo_result.php to:
Everything should now be in place to connect to the H2 database using Code Igniter's ActiveRecord library. Let's test it! Create a test controller application/controller/test.php:
Voila! Go to http://localhost:8080/test and enjoy a working Code Igniter on H2 database using ActiveRecord :-)
Note: I used Code Igniter version 2.1.2, Quercus version 4.0.28 and H2 database version 1.3.167.
Recently I was experimenting with running PHP and the H2 database engine in a Java web server using Caucho Quercus (or just Quercus for short). In theory this would yield an ultra portable platform-independent PHP, web server and database stack. I eventually got it working, but with some limitations. Before I get into details, here are some quick notes: Quercus is a 100% Java implementation of PHP5, though it doesn't support 100% of PHP5's functionality, unfortunately. Also, Quercus' implementation seems to differ from PHP5's implementation sometimes. That said, I thought I would give it a shot anyway, because some popular CMS systems have had success running with Quercus, such as Drupal and Wordpress. I used Jetty as my Java web server (a.k.a. Java web container) and Maven for dependency management. The source code of my experiment is available at github.
This tutorial describes how to set up the PHP and database stack in the Jetty web server. First we set up a web application (webapp for short) in Java which can interpret .php files using Quercus. Then we setup the H2 database engine. Last, we setup the part where PHP can connect to H2 while actually thinking it is MySQL that it's connecting to (using H2's MySQL compatibility mode, because PHP does not have support for H2). Here we go!
Ultra short walk-through
The long version
Setting up Quercus is quite straight-forward. Download the WAR file of the latest version of Quercus (in my case 4.0.25) and install it in your local Maven repository by running this command from the same location as where you downloaded quercus-4.0.25.war:
Then include the following dependency to your Maven project's pom.xml and Quercus should be integrated in your webapp:
The next step is to be able to run the webapp locally, so that's what we use Jetty for. Add this to your pom.xml:
Now Jetty and Quercus should be okay to go. You can verify this by putting a phpinfo.php file with the famous code snippet "<?php phpinfo(); ?>" at src/main/webapp/phpinfo.php (relative to pom.xml's location, create directories if they don't exist) and start up the Jetty webserver:
Wait for Jetty to be completely started (console output should say something like "[INFO] Started Jetty Server") and point your browser to http://localhost:8080/phpinfo.php and verify that Jetty is running and Quercus is installed. (You can stop Jetty by pressing CTRL-C in the console.)
Congratulations! If you made it this far, you have successfully setup a Java web server that can interpret PHP files! But, we're not there yet, we still have to add database support.
We will run the H2 database engine in embedded mode. To do this, we need to include the H2 dependency in the pom.xml. For the integration of H2 and PHP another dependency is required as well: database connection pooling (DBCP), so add both to your pom.xml:
To actually integrate H2 and PHP we need to tell Jetty some additional configuration. Get these two files (web.xml and jetty-env.xml) and drop them in your src/main/webapp/WEB-INF/ directory (create this directory if it doesn't exist).
At this point, your PHP webapp is entirely configured to connect an in-memory embedded H2 database. But, there is a catch. At the point of writing this article, H2's MySQL compatibility mode is not compatible with Quercus' implementation of the PHP MySQL driver (any attempt to connect to H2 using PHP's mysql_connect() will result in an error complaining about a syntax error in query "SET NAMES ..."). To work around this, we connect to H2 using Quercus' implementation of the PHP PDO driver, which does seem to be compatible with H2's MySQL compatibility mode. So, create a file, e.g. test-database.php and put it in src/main/webapp/test-database.php:
Go to http://localhost:8080/test-database.php to see if it's working (which if everything went okay, it should!).
So now you should have your ultra-portable platform-independent PHP, web server and database stack up and running. Happy experimenting! :-)
I would like to see a working version of Code Igniter using the ActiveRecord class running on this stack. Also, it would be nice to have H2's MySQL compatibility mode compatible with Quercus' MySQL driver, so we can run applications that use mysql_connect() on the stack (e.g. phpMyAdmin).
If you want to call PDOStatement::fetchObject(), you should call PDOStatement::fetchObject('stdClass') instead. This is a bug in Quercus (remember I said in the beginning that sometimes Quercus' implementation differs from PHP's). Acccording to the PHP Manual, the default first argument for PDOStatement::fetchObject should be 'stdClass', it seems the folks at Caucho forgot to implement this.
If you want to use a persistent database file instead of the temporary in-memory database, go to src/main/webapp/WEB-INF/jetty-env.xml and change line
Where you replace 'filename' with a relative path to a file (relative to pom.xml) or an absolute path to a file. Note that "mem:" has an extra ":" after it and "filename" does not. For more information about the H2 JDBC URL see H2's feature list.
MySQL has two native field types that can store information about both date and time: timestamp and datetime. The major differences between timestamp and datetime field types are:
This has some serious implications. First, timestamp can only be used where the supported value range is sufficient. Second, for scenarios where you would want to log, compare or perform other tasks with date and time, datetime is not reliable if you adhere to your server time zone settings because datetime does not store the time zone information. An example to illustrate this unreliability:
Suppose you are logging transactions of some sort to your MySQL database, neatly adding the date and time at which the transaction took place, relying on the server time zone settings. Another process is monitoring the transactions (e.g. is client X not exceeding Y transactions per hour, whether transactions result in insufficient account balance, etc.). Now suppose the time zone of the server changes, this could be because of any reason:
To stick with the daylight savings example, let's say the clock gets rewound one hour. Transactions are still happily being inserted into the database using datetime. Now, according to the transaction log, customers are making twice the amount of transactions during this hour. But wait?! Weren't we keeping an eye on the maximum amount of transactions per hour of clients? It looks like some clients that are operating at only half of their capacity suddenly exceed the maximum transaction limit during that hour, uh oh!
How will MySQL know whether it was 2:30 AM before or after daylight saving time when you use timestamp? The answer is: MySQL doesn't know! E.g. 28 October 2012 2:30 AM in either CEST (UTC+2:00) or CET (UTC+1:00) are both stored as unix timestamp value 1351387800 (= "2012-10-28 02:30 CET" = "2012-10-28 01:30 UTC"). As we will see soon, this is documented behaviour. It's not possible to insert unix timestamps directly into a timestamp field, so you are required to use a text representation of the date and time you are trying to store (e.g. "2012-10-28 2:30", NOW(), CURRENT_TIMESTAMP). MySQL takes this string and converts it into an unix timestamp using UNIX_TIMESTAMP(), this is where the point where 28 October 2012 2:30 AM CEST and CET both get mapped to 1351387800. One suggested work-around I came accross doesn't work in my boundary case, confirming what the manual says:
So how can we store our dates and times without being affected by this? The answer lies in designing your database (and application). Trusting your server's time zone settings and MySQL's time zone conversion abilities is a bad idea. Instead, use datetime fields and store UTC formatted values only. You can always get the current date and time in UTC via UTC_TIMESTAMP(), e.g.:
Alternatively, you could store unix timestamps in unsigned int columns. But then you can not reliably use all those useful documented MySQL date and time functions, and, you would have to write your own date and time calculations using math in queries which can get messy.
A disadvantage of storing all values in a datetime field is that you cannot make use anymore of the CURRENT_TIMESTAMP default value. But then again, if you need to store values outside the timestamp range or need 100% reliability, that might be one of your lesser concerns.
Use UTC formatted date and time values within MySQL and your application for reliability . Store all your date and time values in UTC format in a datetime column.
When peer reviewing PHP code, I often find dangerous uses of addslashes(). It is often believed this is a safe way of escaping user input before passing it to e.g. a SQL query, but in fact it's unsafe. If you find yourself using addslashes(), think twice if you are using it safely:
If you have more suggestions for safe escaping, please leave them in the comments below. Happy safe coding!