Friday 21 October 2011

Qooxdoo generate.py source, source-all

Health warning - this may not be accurate but it reflects my current understanding.

When you write an application in Qooxdoo, your raw code has to be referenced into a master javascript file which is loaded by the browser.

You do this initially by running the generate source command.

Thereafter, provided you do not refer to any new classes (either ones you have written or ones provided by qooxdoo or contributors) you may simple edit your code and refresh the browser to see your changes. No need to run generate.

But if you create some new classes in your application, the master javascript file does not know about them. Therefore you need to run generate source again to update the master.

Or if you decide to use some additional qooxdoo classes then again the master javascript file does not know about this change and you will need to run generate source so that it knows to include the additional qooxdoo classes.

Because in writing your qooxdoo application it is much more common for you to add references to qooxdoo classes than it is to create additional classes of your own, the generate source-all command exists. This causes the master javascript file to contain references to all the qooxdoo classes whether you are currently using them or not. Thus, provided you are not writing any new classes of your own, you can in future skip the generate source command entirely. To see the effect of your code changes you need only refresh the browser.

In a nutshell, the difference between source and source-all is that using source-all can save you time in development because you only need to recompile the master when you add new classes of your own. If you were not to use source-all you would need to recompile every time you made reference to a new qooxdoo class.

This thread was the source of this article:
http://qooxdoo.678.n2.nabble.com/v0-8-generate-py-source-to-include-even-qx-classes-tp1556404p1556404.html

Wednesday 29 June 2011

Generate self-signed SSL cert

#!/usr/bin/env python
"""
A self-signed certificate generator.
"""
import os

_name="server"

commands = [
"openssl genrsa -des3 -out %s.key 1024" % _name,
"openssl req -new -key %s.key -out %s.csr" % (_name,_name),
"cp %s.key %s.key.org" % (_name,_name),
"openssl rsa -in %s.key.org -out %s.key" % (_name,_name),
"openssl x509 -req -in %s.csr -signkey %s.key -out %s.crt" % (_name,_name,_name)
]

for c in commands:
os.system(c)

#credit to http://www.akadia.com/services/ssh_test_certificate.html where the information comes from.

#When you run this code, where it asks for Common Name or YourName, enter the name of the host eg - www.example.com or mywebserver.sales.example.com .

#See http://artins.org/ben/how-to-create-a-multihomed-certificate-with-openssl for creating one certificate to protect multiple hosts.

Monday 27 June 2011

Debian Packaging

How I made a .deb file

Create a directory
mkdir foo
Descend into it.
cd foo
Create a directory DEBIAN
mkdir DEBIAN
Descend into it.
Create a text file called 'control'
vim control


The postinst and prerm scripts also go in the DEBIAN directory.
The actual install files go in the foo directory

./foo
./foo/DEBIAN
./foo/DEBIAN/control
./foo/DEBIAN/postinst
./foo/DEBIAN/prerm
./foo/bar.....

Finally, go to the directory above foo and do:

dpkg -b ./foo foo.deb and that is it! done!


Friday 14 January 2011

Shindig on Ubuntu

I was busy building a Google Gadget when I ran into a glitch. My gadget worked fine in the gagdget container on Google Sites and iGoogle but did not work too well on "Gadgets-For-Your-Webpage". (according to Firebug gadgets.io was undefined.)

In any case, my grand plan to use Google's container for gadgets for my own site was clearly not going to fly - it was a poor idea to rely too much on a third party service for this type of thing.

So I decided to install Shindig. This would allow my gadgets to be re-used all around the web, as long as I can keep the shindig service running.

Shindig gives the choice of a PHP or Java version. I chose PHP.

My server was Ubuntu 10.04.

I had Apache already installed.

First things first - check that PHP exists on my box. That would be a no.

sudo aptitude install php5

Then check that it runs with the classic phpinfo(); script of your choice.

testphp.php
<?php
echo phpinfo();
?>

Yes, PHP's up and running

Shindig has PHP dependencies - mcrypt, curl, simplexml and json.
But grepping through the output of phpinfo() there is no curl and mcrypt module.

Let's fix that.

sudo aptitidue install php5-mcrypt php5-curl

Now we have a working PHP environment.

Next up, configure Apache for Shindig.

Shindig requires that it's .htaccess file be honoured and also that mod_rewrite be enabled.

First, mod_rewrite. In my Apache out-of-the-box setup mod_rewrite was not enabled. That was an easy fix:

cd /etc/apache2/mods-enabled
ls -s ../rewrite.load

I'm not a big .htaccess fan. Which means I want to configure Apache to honour .htaccess in the Shindig installation directory. And to do that, I need to install Shindig.


I unpacked it to /var/www and then I renamed it form shindig-2.0.0 to just plain old shindig.

cd ~
wget http://www.apache.org/dist/shindig/2.0.0/shindig-2.0.0-php.tar.gz
cd /var/www
tar xfzv ~/shindig-2.0.0-php.tar.gz
mv shindig-2.0.0 shindig

So, in the appropriate part of my Apache config, in my case /etc/apache2/sites-available/default enabled the .htaccess file thus:

<Directory>
AllowOverride All
</Directory>

Next up is the configuration of the Shindig application itself.

In version 2.0.0 there is a README file at the top level of the unpacked distribution. It describes two options for installing Shindig. Option A, is to create a new virtual host container in Apache, Option B is to use an existing configuration. For me, option B was the more practical.

The instructions contained in the README have are two small errors in the B instructions:
  1. paths beginning php/ are incorrect.
  2. no reference is made to the need to edit the .htaccess file.
To correct error 1 above, just ignore the php part of the path because there is no php directory in the PHP Shindig distribution. [ It looks like what has happened is that the instructions where written for use from the Subversion source tree, where the PHP and JAVA versions live side by side in /php/ and /java/ directories respectively] I installed Shindig to /var/www/shindig and the correct path for web_prefix was /shindig .

To correct error 2, just know that you need to edit the .htaccess file. Once you know this, you will find the instructions in the file itself. But if you didn't already know that, you would be a bit stuck.

That's it. Enjoy using Shindig.