Almost all last week at work I was working on adding Postgres to the database interfacing part of our php framework. The more I worked on it and did research to figure out why things were the way that they were and why certain things didn’t work the same way as I thought, because of my limited knowledge of databases other than MySQL and a bit of Oracle, they should, the more that I liked this database backend (side note: why doesn’t chrome have an add to dictionary option when right click on something you ‘misspelled’?). It is not that one is definitively better than the other, it is just a different way of tackling the same problems (well… in my case they are pretty much the same problems…).

For the most part, simple queries that you would write are the exact same:

SELECT * FROM my_table WHERE my_column = 'something'

This will of course return all of the things in the database where my_column = ’something’, nice and simple.

Problems sometimes arise however when you want to do more complex things. For example if you want to delete everything from two tables where one column is the same as the other:

In MySQL, easy:

DELETE table1.*, table2.* FROM table1, table2 WHERE table1.column1 = table2.column1

In Postgres, it is easy as well, but different:

(Downloading and installing Postgres so I don’t mess this up… that would be embarrassing…)

CREATE TEMPORARY TABLE mytmptable(column1 text);
INSERT INTO mytemptable(SELECT table1.column1 FROM table1, table2 WHERE table1.column1 = table2.column1);
DELETE FROM table1 WHERE table1.column1 IN (SELECT * FROM mytemptable);
DELETE FROM table2 WHERE table2.column1 IN (SELECT * FROM mytemptable);

You could do the delete in a similar way to that in MySQL, but you probably wouldn’t because the other way is simpler. It is more dangerous though because of the possibility to delete everything in your tables while you are testing by accident if you miswrite the query.

Fortunately not everything is more complicated in Postgres, for example you can do:

DELETE FROM table1 WHERE column1 IN (SELECT column1 FROM table2 WHERE column1 LIKE 'some text' LIMIT 10 OFFSET 2)

and it will have no trouble deleting things from your tables. In MySQL you cannot do this because of the way that MySQL queries the tables when it uses LIMIT and OFFSET (apparently). What you have to do is this:

CREATE TEMPORARY TABLE mytemptable(column1 text);
INSERT INTO mytemptable(SELECT column1 FROM table2 WHERE column1 LIKE 'some text' LIMIT 10 OFFSET 2);
DELETE FROM table1 WHERE column1 IN (SELECT column1 FROM mytemptable)

This makes postgres a more attractive option to me… if only it supported

CREATE TABLE IF NOT EXISTS ...

…

I finally decided to update wordpress and the plugins that I use to go with it. The update seemes to have gone well, and I believe that my site is still working fine. My theme still seems to be working too… though I think I need to figure out the Newer, Current, and Older Post links a bit better because

I really don’t like how they show up at the bottom there when you are cycling through the posts. I also found out that the version of wordpress you are running is found in a meta-tag on your site… Might as well have it written down in plain sight (in the footer maybe? No, the number in my footer has nothing to do with versions, it is the number of times that Wordpress hits the database to generate the page…). I think I am going to hack that part of the code out of Wordpress. The offending bit of code:

<meta content="WordPress 2.6" name="generator"/>

You wouldn’t even need to be clever at all to hack my blog if it were out of date, a lot of the vulnerabilities are made public, a simple search for Wordpress + 2.3 + vulnerabilities would turn up a bunch of hits (and it does):

… about 157,000 for wordpress 2.3 vulnerabilities.

You probably would not get the same amount of results if you used cuil.com instead (burn!).

Ok, I think I am done ranting about this for now.

Time for some learning:

Zinc Oxide is important.

First of all, why not? Everything else can run on the jvm (yes… even c#), so why not php? Well… I certainly don’t see why not… Java is a fairly robust language with a pile of different libraries and (as you saw if you clicked on any of those links) languages that can run on it. It is ideal!

Don’t like php’s random function? Why not use Java’s? Not your cup of tea? Use ruby’s instead, or python’s, or  write one in COBOL if you are really brave.

It also means that you can implement the functionality in Java, the database transactions in Ruby, then write all of the presentation in PHP, no clearer MVC separation than that eh? Admitedly it might get a bit confusing and I may be over exaggerating about the possibility of these implementation’s cross communication abilities… but it would be great if you could (I might test it later…).

http://www.caucho.com/resin-3.0/quercus/index.xtp

Go check it out!

One of the tools in my tool box is xampp, which seems to work better than trying to install everything bit by bit (at least it did at work). One thing I never considered was setting up virtual hosts for each project, I always worked from a folder so that to access the site I went to:

    http://localhost/sitename

That is fine, but what happens when you are working with a site that needs to be the root site (ie: it has links like /page_name.php which bounce you out to the root)? In that case you need to set up a virtual server. In xampp they have separated the files out to ‘make it easier’ on a user to find what they want. Sometimes this is not the case… so here is how to setup a virtual server (at least it worked for me) on Windows Vista (and XP, and with some small modifications Linux and Mac as well).

Find the httpd-vhosts.conf file, it should be:

    C:\xampp\apache\conf\extra\http-vhosts.conf

if you installed it in the default location.

Then go to the bottom of that file and add:

<VirtualHost *:80>
  ServerName http://sitename.127.ca
  DocumentRoot C:\xampp\htdocs\sitename
</VirtualHost>

if that doesnt work, then there might be something in the http.conf files that is stopping access to that folder, in that case, add

 <Directory C:\xampp\htdocs\sitename>
    IndexOptions +FancyIndexing NameWidth=*
    Options Includes FollowSymLinks Indexes
    AllowOverride All
    Order allow,deny
    Allow from all
 </Directory>

So, you have:

<VirtualHost *:80>
  ServerName http://sitename.127.ca
  DocumentRoot C:\xampp\htdocs\sitename
  <Directory C:\xampp\htdocs\sitename>
    IndexOptions +FancyIndexing NameWidth=*
    Options Includes FollowSymLinks Indexes
    AllowOverride All
    Order allow,deny
    Allow from all
  </Directory>
</VirtualHost>

While you can probably put the site in any folder on your computer, it makes sense organizationally to keep them all in the htdocs folder (at least it does to me…), so that is why the example uses the path

    c:\xampp\htdocs

You should now be able to access your site by going to:

    http://sitename.127.ca

For why 127.ca see this site.

I use Komodo Edit all the time on Windows (XP and Vista) but up till now I have not used it in any Linux environment. I decided it was time to take the plunge and try things out. First I had to download the tar file from the activestate website (here), that was easy, the one thing that I was wary about was this:

AS package (libcpp6)

I had never heard of that, but as it turns out it is an [A]ctive [S]tate package. So, not a problem. When I got it there was an install .html. It had all of the instructions for all of the operating systems. As it turns out that was a bit overkill considering this was the Linux version not a Windows one or a mac one…

The only thing that I needed from the help file was the information that you had to install these packages (I use apt-get to do it, you might use something else):


scim scim-gtk2-immodule scim-qtimm scim-tables-additional


You might also need to install these ones if they are not already in your Linux of choice:

glibc libjpeg libstdc++

You will also need to have perl installed.

Finally once those packages are all installed you can run the install file

./install.sh

And then once that is done (you get to chose the path that it installs to (I left it as default because I am the only user of this machine), add komodo to your path by entering:

export PATH="/home/[username]/Komodo-Edit-4/bin:$PATH”

in the terminal (well, that is the quick way, you would probably have to type that in every time you wanted to use it… a better way is to add that line to the end of your ~/.bashrc file).

You could also create a symbolic link to it:

ln -s "/home/username/Komodo-Edit-4/bin/komodo" /usr/local/bin/komodo

Finally, you can just type in komodo to run it, or create a link in your menu (or on the desktop) to run it.

Once I get some money, I will probably be buying the full version (Komodo IDE) which has more features in it. Until then, I am more than happy with Komodo Edit 4.

If you have any problems installing it, please refer to the install file that they include as I have skipped some of the stuff that did not have any relevance to me.