TRINIX

“MemCached” is a
high-performance, distributed memory object caching system, generic in nature,
but intended for use in speeding up dynamic web applications by alleviating
database load.

In this howto I explain how you can very simply install it and make it aviable in PHP.�

You need to activate the RPMForge custom
repository (formely known as Dag Wieers): http://dag.wieers.com/rpm/packages/rpmforge-release/

Grab your specific RPM and install it:

wgethttp://dag.wieers.com/rpm/packages/rpmforge-release/rpmforge-release-*.rpm

rpm –install rpmforge-release-*.rpm

yum install –enablerepo=rpmforge memcached

Now memcached is installed.

You can test it

memcached -m 512 -u nobody -vv

First, you start up the memcached daemon on
as many spare machines as you have. The daemon has no configuration file, just
a few command line options, only 3 or 4 of which you’ll likely use:

./memcached -d -m 2048 -l 10.0.0.40 -p 11211 -u nobody

This starts memcached up as a daemon, using 2GB of memory, and listening
on IP 10.0.0.40, port 11211. The -m switch specifies the amount of memory in megabytes. The -l switch specifies the IP to listen on and finally the -p switch specifies the port to listen on. The default port is 11211 and if your machine has just 1 IP you can omit the -l parameter. In the above example I set the amount of memory to 2GB. Of course you should use a sensible amount of memory. Making your machine swap to disk sort of defeats the purpose of a memory cache daemon. Note that it’s perfectly fine to run the memcached daemon on another machine than the one you’re running your actual PHP project on. You could even set up a machine totally dedicated to being a memory cache server. And if that’s not even enough you can set up muliple servers as well. The sky is the limit. Note: if you try to start the memcached as root it will require you to specify a user under which it should run with an additional -u nobody

Installation of the PHP MemCache extension�

cd /files/download/

wget http://pecl.php.net/get/memcache-2.1.2.tgz

tar -xvf memcache-2.1.2.tgz

cd memcache-2.1.2

phpize
&& ./configure –enable-memcache && make

Copy the memcache.so to the default module
directory.

vi /etc/php.ini

add

extension=memcache.so

/etc/init.d/httpd restart

�

If you check you phpinfo() you should a memcache section appear.

You can now fully use the Memcache functionality in your PHP.

References

http://www.danga.com/memcached/

http://dk.php.net/manual/en/ref.memcache.php

�

�

In our new stagging, development environment documentation is essential.

So we want to have all our classes API generated automatically.

This can be done, fairly easy.

For generation of our php API, I choose for phpDocumentor.
Why? Because it’s easy, has a nice web GUI and command line utility and it does it work assupposed.
First lets install phpDocumentor (on a centos system)

sudo pear install phpdocumentor

Next we are going to setup the phpDocumentor.
Our project is located in the following directory.

project: /svn/builds/nameProject/www/

We create a project config file.

config file: /svn/scripts/phpdoc-config.ini

vi /svn/scripts/phpdoc-config.ini

[Parse Data]
title = Documentation nameProject
hidden = false
parseprivate = off
javadocdesc = off
defaultcategoryname = Documentation
defaultpackagename = nameProject
target = /svn/builds/nameProject/doc/
readmeinstallchangelog = README, INSTALL, FAQ, LICENSE, Release-1.3.1
directory = /svn/builds/nameProject/www/
ignore = pear-*,templates/,Documentation/,test*.php
sourcecode = on
output=HTML:Smarty:PHP

Test your configuration
Create the repertory targets

mkdir -p /svn/builds/nameProject/doc/

then launch

phpdoc -c /svn/scripts/phpdoc-config.ini

Check the /svn/builds/nameProject/doc/ directory, if everything is generated.

Next we are going to let our phpDocumentor do it’s work every night.
So I have written a little plain export script and an extend our nightly build subversion script (see http://thim.trinix.be/2007/06/06/nightly-build-script/)

Plain export

vi /svn/scripts/phpdoc-generate.sh

phpdoc -c /svn/scripts/phpdoc-config.ini

Extend Nightly build script

vi /svn/scripts/svn-phpdoc-generate.sh

phpdoc -c /svn/scripts/phpdoc-config.ini

and edit svn-nightly-build.sh

vi /svn/scripts/svn-nightly-build.sh

and add the following just before the # Create archive section

# Remove old documentation
rm -Rf /svn/builds/nameProject/doc/

# Generate documentation
/svn/scripts/svn-phpdoc-generate.sh

The final step is to setup a cron (crontab -e) or add your script to right /etc/cron.* directory (example /etc/cron.daily)

As you might have noticed since Centos 5.0, the PHP-MSSQL module / extension isn’t default available in the yum repository. So if you want to use it you can alter the PHP binairy or you can compile an mssql module / extension. In this howto I will explain how to compile the mssql module / extension.You need to activate the RPMForge custom repository (formely known as Dag Wieers)http://dag.wieers.com/rpm/packages/rpmforge-release/Grab your specific RPM and install it.

wget http://dag.wieers.com/rpm/packages/rpmforge-release/rpmforge-release-*.rpmrpm –install rpmforge-release-*.rpm

Next step is to install freetds,freetds-devel, php-devel and the Development tools.

yum groupinstall ‘Development Tools’

yum install freetds freetds-devel –enablerepo=rpmforge
yum install php-devel

next we alter the php.spec file, containing the php configuration for compiling.

vi /usr/src/redhat/SPECS/php.spec

if you can’t find the php.spec file.

You can download the php src rpm.

wget centos.mirrors.skynet.be/pub/centos/5/os/SRPMS/php-5.1.6-5.el5.src.rpmand next

rpm –install php-5.1.6-5.el5.src.rpm

And then do an updatedb and locate php.spec.

�

edit the CFLAGS= line (~line 310) of the php.spec file – remove ” -Wno-pointer-sign”

add the following piece of code to it.

Group: Development/Languages
Requires: php = %{version}-%{release}, php-pdo
Summary: A module for PHP applications that use the MSSQL database.
provides: php_database
BuildRequires: freetds-devel

%description mssql
The MSSQL package contains a dynamic shared object that will add
support for accessing MSSQL databases to php

Start building your php rpm.

rpmbuild -bb ./php.spec

If has is asking for some dependancies just yum install them

cd /usr/src/redhat/BUILD/php-5.1.6/ext/mssql/

Now we are going to make the mssql module without having to rewrite the php binairy.

phpize
./configure –with-mssql
make
make install

Next look for the mssql.so and make sure it is in the module directory specified in your php.ini.
and copy it to the specified location if needed.

final step

vi /etc/php.ini

add this line to php.ini

extension=mssql.so

save php.ini and restart apache

/etc/init.d/httpd restart

éh voila you have just made your mssql module / extension without having to change anything to the base Centos 5 HTTPD / PHP setup.

PS: I have also posted this howto on http://www.howtoforge.com

With this topic I’m going to write down some useful tips when you want to start professional development and/or start working in a development team.

When going pro there are a few issues you always have to keep in my mind.

Your project should be:

• easy to manage
• comprehensible by out-side developers
• build logical
• structured
• well documented & commented
• set-up naming & coding standards

Structure
When building web applications you get a lot of files of all kinds (CSS, PHP, Classes, JS,…)
It’s important to keep a clean structure. There could also be a difference between a public and a secured interface. So I advice to setup your directory structure in the following manner.

WEB_APP
===|——— gui
===|=======|——- js
===|=======|——- css
===|=======|——- icons /images
===|=======|——- rss
===|=======|——- config
===|=======|——- tpl
===|=======|——- class
===|=======|——- modules
===|=======|——- export
===|=======|——- service
===|——— system
===|=======|——- js
===|=======|——- icons /images
===|=======|——- css
===|=======|——- config
===|=======|——- tpl
===|=======|——- class
===|=======|——- modules

We work in a multi-tier manner. This means that we try to separate the visual,coding and database. Our web application consist out of 2 big parts, gui and system. The gui stands for the public part and system consists out the secured admin section. Of course there can be more parts needed, this is just an example case structure, which I consider a good start for a basic web app.

Explanation of directories:

• js:contains all javascript libraries
• icons / images: contains all necessary images and icons needed by the gui
• css: contains all style sheets
• rss: is the public rss feeds directory
• config: here are all configuration files placed, like your DB login data, general application settings, … files that need to be included in every page
• tpl: we work in a multi-tier environment, the tpl directory keeps the HTML templates (the pure visual part)
• class: contains all general classes, like the DB class, the HTML email class, …
• modules: consist out of all the specific application written modules, divided in directory per module.
• export: contains all the possible export files of the application
• service: is the web service part, here you place all the code for your web services.

This is just a simple case, but I find the structure clear and easy to expand.

Coding & Naming Conventions
When building applications or work in a team. You should definitely need to have this. The coding and naming conventions are the rules to follow while programming, more specific for the usage of file and directory naming and the manner variables,functions and classes our declared. This prevents each programmer of using his own specific manner of writing code and so afterwards really difficult for other developers to understand his code. And let’s say one year later the programmer still understand his own code and still works in the same way.

1. Directories

• Short names
• All in lowercase, no studly caps
• Prevent usage of points (.) and spaces
• More then 1 word use underscore (_)
• For related content use a prefix with an underscore. (ext_dir1, ext_dir2,…)

2. Files

• Logical names
• All in lowercase, no studly caps
• Prevent usage of points (.) and spaces
• Function specific files (class,func,…), use prefix followed by an point (.) (class.name.php, func.name.php)
• More then 1 word use underscore (_)
• For related content use a prefix with an underscore (adm_file1, adm_file2,…)

3. Coding Standards
Here for I would like to refer to the PEAR Coding Standards (http://pear.php.net/manual/en/standards.php)

Documentation
Another important step in becoming a pro developer is to learn to document EVERYTHING.
Write down your Application sturcture and explain what and why.
Also write down your Coding & Naming Conventions.
Everything you do or use, explain in documentation how, what, why.
This seems a waste of time but if you have a lot of projects and you need to expand an older project you can simply read your documentation and you know the structure of your application without having to figure everything out again.
Another plus is to pass your project on to another developer, you wont feel like an help desk if he don’t email you every 5 min for info over the project. Because you can just give him all the docs and he can start reading reducing the number of question greatly.

Ever wanted to re-create your own YouTube like clone.

Well read this article. It describes perfectly how you can achieve this.

http://www.onlamp.com/pub/a/php/2007/05/24/creating-mytube-with-flex-and-php.html

It explains how to set-up an PHP back end, with the FFmpeg video converter tool for converting the uploaded movies in a Flash Video (FLV) file and 2 version of a Flex GUI for the users.