Common mistakes in development

If you don’t put enough time during the design (Tech) of the project and not monitored correctly, then you have to put your entire lifetime in fixing the issues that will come out later. Below is the list of points which needs to be monitored during the course of the project development and correct it as and when you identify a mistake. Delaying the correctness of mistake leads to more mistakes and it will become impossible to correct at one point.

1. Indentations: It is a very easy to read but when you are writing long lines of code, it is very important to indent your code properly. Not doing so will lead to put in lot of time to understand the code later and more time to debug for any kind of syntactical errors.

2. Long lines of code: Always avoid having long lines of code. Developers will feel proud when they write lengthy lines of code. But at one point, that much amount of code is unnecessary and also not required to achieve that particular task. Always remember to shorten the code as use functions wherever required. Please note that not using functions or writing the same block of code at more than one place is a very bad way of programming.

3. Poor database design: Poor database design could be like having many tables, improper table names/column names, not having primary keys or references. Initially while developing the project, the data model could be small and you may skip having references. But always remember to have proper references as the database is the backbone of the project and it will only increase and not decrease. So always spend more time during the database design.

4. Improper variable names: Developers are lazy and always intend to have shorter variable names. There is no wrong in having smaller variable names but you always have to understand that a project will be developed and maintained over a span of years and it is impossible to have the same developer working. So it is very important to have meaningful variable or function names and should be able to understand easily by looking at the code.

5. Not writing comments: Most developers write lengthy comments which are unnecessary at one point. Always remember to have comments where it is required and not at every line of code. It is important to write comments which explain the use of the code and not what the code does. As a developer, anyone can understand the code but not able to understand the business view behind the code. So it is very important to write the comment which explains the business view.

HTML to PDF

The Dompdf application written in PHP is used to convert from HTML to PDF. Even though there are some constraints to it, but a normal html with CSS can be converted easily to PDF.

http://www.digitaljunkies.ca/dompdf/

The above link has provided detail information about how to use the application. We have implemented this in one of our project where we had converted a html which consists of header, table, logos and images to PDF in 3 different formats (Landscape, Horizontal and Portrait).

The advantage of the above application is either you can execute this on browser or on shell. We have executed on shell since our application is written in RoR.

Steps to convert to PDF

1. Have the html file ready which you want to convert to PDF.

Note: The PDF generated will be similar to the HTML. So make sure to have everything in HTML which you want to show in PDF.

2. Execute this command to convert to PDF

/usr/local/php/bin/php -f “/dompdf.php” -o "landscape" -p "landscape" -b ""

Example:

/usr/local/php/bin/php -f /export/home/mortal/devel/eco-audit/dompdf-0.5.1/dompdf.php 52_horiz.html -o "landscape" -p "landscape" -b "/export/home/mortal/devel/eco-audit/public/papers/"

The –p option is used to tell the dompdf the size of the pdf it has to generate. By default there will be some sizes available in this file /include/cpdf_adapter.cls.php. If you want your own custom size, you can add/edit the existing in the above php file. In our above example, we have included 3 sizes to the existing array in the php file.

The –o option is used to mention the orientation of the file. It is used to specify either “landscape” or “portrait”

The –b option is used to specify the directory of the input html file. If you are already in the existing directory, then you can skip –b option.

The –f option “dompdf.php” is the file to which all the above options will be passed as arguments.

3. The above 2 points will be enough to generate a PDF file based on the given html file. If you want the new fonts to be included, then you have to do the following changes.

· In , you will have all the fonts that will be used while generating pdf. If you want any new fonts to be used, specify the font in your html file and copy that font into your directory.

· Once you copy the fonts, check the permissions on the fonts.

· Then open dompdf_ font_family_cache file in lib/fonts directory. You will see an array with the fonts in this fashion

'sans-serif' =>

array (

'normal' => DOMPDF_FONT_DIR . 'Helvetica',

'bold' => DOMPDF_FONT_DIR . 'Helvetica-Bold',

'italic' => DOMPDF_FONT_DIR . 'Helvetica-BoldOblique',

'bold_italic' => DOMPDF_FONT_DIR . 'Helvetica-BoldOblique',

),

'times' =>

array (

'normal' => DOMPDF_FONT_DIR . 'Times-Roman',

'bold' => DOMPDF_FONT_DIR . 'Times-Bold',

'italic' => DOMPDF_FONT_DIR . 'Times-BoldItalic',

'bold_italic' => DOMPDF_FONT_DIR . 'Times-BoldItalic',

),
Now to use your font which you had already copied to lib/fonts directory, mention the font name in the above mentioned file in the same way as it is mentioned for other fonts. You have to understand that for every type of font “normal”, “bold”, “italic”, “bold-italic”, you will have a separate file in lib/fonts directory and you are pointing that file in the array and this array will use the pointed file while conversion

4. Apart from this, there is a file "dompdf_config_inc.php” which has all default configuration of the dompdf. You can specify the default paper size, default font, default DPI, etc.