boolean.co.nz
Where there is more to logic than TRUE or FALSE
Welcome to the Boolean blog
Here you will find details of news, projects, releases and other bits and pieces that we are working on at Boolean.
We hope that you find something of interest amongst the archives.
Code snippets, methodologies and useful links will also be mentioned here.
3
|
It has been quiet on the development front recently, however a new personal project is in the works.
Stay tuned for news, revelations, and beta invites!
 |
A nice little resource indeed. Sometimes you have to deal with Ems, in which case this chart will translate them to pixels to save you the trouble.
Click the image, or here.
 |
Filed under PHP, but obviously much more than that.
In an update to this post, it is time for a revisit of UTF-8.
In a post entitled “Everything you always wanted to know about UTF-8 (but never dared to ask)” the good folk at the iBuildings TechPortal have Juliette Reinders Folmer speak on a variety of topics.
“…In this talk I will cover UTF-8 from basic linguistics, through client-side aspects to all the steps you need to take to tackle the most common (and some more obscure) issues when using UTF-8 in a database driven PHP application…”
Check it out here.
|
|
This post is intended to make you think a little bit more about some of the habits you may have formed whilst programming. It is not the nirvana of programming, nor best practice, just a few little ideas to help you along the way.
1. Use descriptive variable names
Arguably this is the hallmark of the inexperienced or just plain poor programmer. Using variables names such as $x or $y makes a major sacrifice in readability for a negligible performance improvement.
Remember, variable names are cheap whilst programmer time is not.
2. No commented out code
Sure, commenting out code makes sense if you do not use a revision control system (like CVS/SVN/Git/etc) however, – why on earth are you not using a revision control system?
Leaving commented code behind tends to clutter files and reduces readability, – especially in those hard times on a console and don’t have the luxury of an editor with syntax highlighting and large resolution.
3. Write control structures as you would say them
It is all too easy to make control structures (if, switch, while, etc…) unreadable. An easy trick to improve readability is to read it to yourself, from start to finish; this forces you to read it anew and clears up strange comparisons such as: ‘!$security_check===false’.
4. Use single quotes (‘) by default and double quotes only when you want to put variables in your string
It’s the little things…
 |
Dumping a database schema is a an often required quick task. This script will read the schema from a MySQL database, and output it XML to describe it.
<?php
// Define a few constants
define(“DB_SERVER”, “localhost”);
define(“DB_USER”, “root”);
define(“DB_PASS”, “password”);
define(“DB_NAME”, “example”);
// Define a few constants
define(“DB_SERVER”, “localhost”);
define(“DB_USER”, “root”);
define(“DB_PASS”, “password”);
define(“DB_NAME”, “example”);
// Lets connect to the db
$dbhandle = mysql_connect(DB_SERVER, DB_USER, DB_PASS)
or die(“Unable to connect to MySQL”);
// Choose a database to work with
$selected = mysql_select_db(DB_NAME, $dbhandle)
or die(“Could not select examples”);
// Return all of the available tables
$result_tbl = mysql_query( “SHOW TABLES FROM “.DB_NAME, $dbhandle );
$tables = array();
while ($row = mysql_fetch_row($result_tbl)) {
$tables[] = $row[0];
}
$output = “<?xml version=\”1.0\” ?>\n”;
$output .= “<schema>”;
// Now iterate through each table and return the fields
foreach ( $tables as $table ) {
$output .= “<table name=\”$table\”>”;
$result_fld = mysql_query( “SHOW FIELDS FROM “.$table, $dbhandle );
while( $row1 = mysql_fetch_row($result_fld) ) {
$output .= “<field name=\”$row1[0]\” type=\”$row1[1]\”";
$output .= ($row1[3] == “PRI”) ? ” primary_key=\”yes\” />” : ” />”;
}
$output .= “</table>”;
}
$output .= “</schema>”;
// Notify the browser the type of file being dealt with
header(“Content-type: text/xml”);
// Display the XML to describe the schema
echo $output;
// Dont forget to close the connection
mysql_close($dbhandle);
?>
Remember, this is an example, and real world code should escape characters, follow best security practices etc. Proof of concept code here, – not a snippet to put live.
Scalability is a desirable property of a system, a network, or a process, which indicates its ability to either handle growing amounts of work in a graceful manner or to be readily enlarged. (Wikipedia)
In order to achieve good scalability an application has to be designed with scalability in mind. Every application requires its own level of scalability and performance, and this should ideally be addressed during functional and technical design specification.
During this design phase there are a number of things to consider, – especially performance. Higher performance generally means more requests per second and less intensive operations; good caching is vital (think Smarty, ZendPlatform, memcached etc)
Where possible try to build software that is ‘loosely coupled’, – that way if it is required in the future it will be possible to serve different components from different servers. Often application bottlenecks occur in a small part of the application so with loosely coupled software it is easier to relocate that component to dedicated hardware.
Infrastructure architecture must support the application architecture. PHP web server clusters require a solution for sharing sessions between servers. These servers can have their own local cache or they could use a shared caching mechanism. Building on a SOA architecture can help spread load across multiple servers.
Designing a database includes thinking about scalability and performance. While replication is a good way to spread read queries across multiple servers it doesn’t help when you have lots of writes. Data partitioning is a valuable consideration; for example each group of database servers can serve part of your database. This allows you to spread writes to different groups of servers, however obviously adds to the complexity of partitioning and fetching data.
During the development process ensure that you develop with a database that reflects the real thing. Try to populate your database with content before you start developing as a database with just a couple of rows behaves different to one with millions of rows.
|
|
I’m sure there is no need to explain the virtues of regular backups. Below are three steps to peace of mind
1) Configure a backup directory on the server
mkdir /var/lib/backupfolder
cd /var/lib/backupfolder
cd /var/lib/backupfolder
2) Make a backup script
vi mysqlbackup.sh
#!/bin/sh
# MySQL server username goes here
USERNAME=”username”
# MySQL server password goes here
PASSWORD=”password”
# List of DBNAMES for Backup
DBNAME=”dbname”
#date timestamp used in the log
DATE=`/bin/date +%Y-%m-%d_%Hh%Mm`
# format the output file
OUTDIR=”/var/lib/backupfolder/”
OUTFILE=”ip_bindass”.$DATE.”sql.gz”
#working directory
DIR=”/var/lib/backupfolder/”
#cd $DIR
# Do the MySQL Backup
/usr/bin/mysqldump –database $DBNAME –opt –single-transaction -u$USERNAME -p$PASSWORD | /usr/bin/gzip -9 > $OUTDIR$OUTFILE
# MySQL server username goes here
USERNAME=”username”
# MySQL server password goes here
PASSWORD=”password”
# List of DBNAMES for Backup
DBNAME=”dbname”
#date timestamp used in the log
DATE=`/bin/date +%Y-%m-%d_%Hh%Mm`
# format the output file
OUTDIR=”/var/lib/backupfolder/”
OUTFILE=”ip_bindass”.$DATE.”sql.gz”
#working directory
DIR=”/var/lib/backupfolder/”
#cd $DIR
# Do the MySQL Backup
/usr/bin/mysqldump –database $DBNAME –opt –single-transaction -u$USERNAME -p$PASSWORD | /usr/bin/gzip -9 > $OUTDIR$OUTFILE
Dont forget to change permissions
chmod +x mysqlbackup.sh
3) Schedule the backup in crontab
crontab -e
Add something along the lines of:
30 23 * * * /var/lib/backupfolder/mysqlbackup.sh
To backup at 11:30PM every day. Just as important as to backup up is to test restores; – it’s no good having backups and feeling at ease if you cant recover in the event of catastrophe!
|
|
A client recently asked if PHP was an Agile programming language, and during the (rather lengthy) explanation a few principles worth exploring were covered:
In the context of software development Agile is really no more than a set of principles and values. At a meeting in February 2001 people who were then developing software differently to traditional processes drew up a manifesto; they formalised practices favouring constant feedback and change, flat hierachy, and delivered early and often.
PHP is generally considered a lightweight language, – often it is used because it can get things done quicker than with other languages. A language is never agile because it does not generally define the processes used when developing with it. However it can have qualities that can make its development quicker; PHP is light, interpreted, and it is simple. Unfortunately these reasons have also attracted people unconcerned with best practices in order to ‘just get their sites up and running’
Agile doesnt mean doing the job quickly, – dont expect to finish the project earlier, but you will deliver earlier. A part of the system that is testable, usable, and something that adds value. From the feedback the team and customer will decide what will be delivered next. The iterations are closer together than other approaches and in order to deliver quickly you will only deliver what you need.
As far as web application development is concerned, being an interpreted, lightweight, embeddable, simple language, with fairly reasonable object oriented support, PHP is in a fairly unique position to fulfill the needs of agile development teams. The elements are available, but of course it is up to the enterprises to take the step and use what is there for setting up their own agile development environment.
Back to topPowered by 
| Based on a theme by Ori Pearl
| Based on a theme by Ori Pearl