How to install iconv extension without recompiling whole PHP

When we install PHP on our system, often we install extensions that are common like curl, mbstring etc. However, there are times when we are asked to install and enable one or more specific extensions when we try to install a specific software. Installing an extension over an already installed PHP often raise some obvious questions like:

  1. Will there be any impact on my already running software / applications if I recompile?
  2. Will there be any chance of my installed PHP getting messed up due to recompilation?


Well, an experienced server guy or a developer might have answers for the above questions? But a beginner will have a certain dilemma. Isn’t there a way to do this in a safer way? Yes! There is. You can install an extension on already installed PHP without recompiling the entire PHP!!

In the following example I will install iconv PHP extension on my alredy existing php 5.6.22 installation.

Step 1: Create a temporary folder somewhere on your hard drive.

$ sudo mkdir php-extention-installer-test
$ cd php-extention-installer-test

Now check the PHP version you have by typing

$ php -v

For me the version is 5.6.22. So I will now download this version from and extract the compressed file.

$ sudo wget
$ tar -jxf php-5.6.22.tar.bz2

Once the files are extracted move into the following folder:

$ php-5.6.22/ext/iconv and prepare php extension to compile it.

$ phpize

Then run the following commands one by one:

$ aclocal
$ ./configure
$ make
$ make test
$ make install

Now add this extension to php.ini file:

echo "" >> /home/emfluence/.phpbrew/php/php-5.6.22/etc/php.ini

Please use the actual location of your active php.ini file.

Verify iconv:

php -i | grep -i "iconv support"

If everything went right, the above command will output the following:

iconv support => enabled

Comparison Between Centralized and Distributed Version Control Systems

Version Control Systems were introduces in development works long back and we are using it for a while now. Like all other development aspects we have come across many feature upgrades and modifications for Version Control Systems as well. So far there are two types of Version Control Systems we know about: Centralized Version Control System (CVCS) and Distributed Version Control System (DVCS).

If you want to get a basic idea of what a Version Control System is, you may read my other article What is Version Control System (VCS) – General Idea.

First let me tell you the major differences between the approaches of keeping revision histories by a Centralized and a Distributed Version Control System.

Repository: In Centralized Version Controls systems the entire codebase is located in a central server. Developers check-in and out files they work with and the updated file goes back to the same repository. With every revisions, Centralized Version Control system creates a new file and keeps a historical database or log of the same. On the other hand, A Distributed Version Control system uses a peer-to-peer approach. In this approach there is no cetralized location used to store the codebase, rather each peer has its own at their local development environment. This gives Distributed Version Control systems the great power to maintain backups in different locations. Unlike Cetralized Version Control systems, Distributed Version Control systems does not have the fear of central repository to get crashed and all hard works are destroyed!

Working Copy: Unlike Centralized Version Control System, every single developer working in a project which is managed with a Distributed Version Control system, will have their own code base at their local. In a Centralized Version Control system, even there are multiple developers working in a project nobody has a true clone of the the code. It is only available in the central repository, i.e. in the server. So with DVCS, every developer has his own “working copy” in place which they can keep working with even without fetching anything else from there central repository. This is however, not the way of using DVCS or this is not something DVCS is out there for you , but the possibility is always there.

Workflow Diagrams: The following diagrams shows how Centralized and Distributed Version Control systems work. As you can see, in Centralized systems, you always have to reply upon the online repository in order to keep your work history going. On the other hand you can keep your work history completely private from the world as long as you want by using your own local repository which is residing on your own system itself.

Centralized Version Control System workflow diagram
Fig. 1: Centralized Version Control System workflow diagram


Distributed Version Control System workflow diagram
Fig. 2: Distributed Version Control System workflow diagram

Keeping Work History: This is probably one of the major and most important breaking changes Distributed Version Control Systems have come up with compared to that of Centralized Systems. What is this actually? How does this help a developer? When we talk about Version Control systems, it is obvious that we have the ability to keep a log of all our works we have done and can review them by jumping into that version at any point of time. However, the major difference between two types of control systems is Centralized systems keep this on the remote server whereas Distributed systems first keep a copy of this log on your system (when you Commit locally), and then when you Push it to the central code repository, it gets added there.

One more magical advantage that Distributed systems provide is that you can commit your works locally and it will keep a log for you. For example, you are working on a module where you have done a bit of work already. At this stage rather than leaving the code like this, you would definitely want to keep a backup somewhere because your work is not completed so you cannot push it to the central repository yet. How will you make sure that your work history is maintained. Well, Distributed Version Control systems give you the flexibility of Committing your work locally. In Centralized systems, if you want to do this you have to Check-out to the central repository directly and if your code has errors, everybody will suffer from this.

So, Distributed systems give you the power to keep your work logged locally as well as to decide when to push your code to the central repository.

Freedom to Work Locally: While working under a Centralized Version Control System, as mentioned above, you cannot push it back to the remote repository unless your work is done and error free. If you do so other collaborators, when pull latest changes, will encounter the errors. On the other hand, Distributed systems let you save your partial works by means of committing them locally. By doing this, you make sure that your work is now recorded into your local repository but it will not harm anybody else in your team. Once your work is complete and you are ready just push it to remote repository.

Popular Centralized and Distributed Systems: Although a Distributed Version Control system is proved to be more powerful, Centralized Version Controlling Systems are still out there and making its way. Most commonly used CVCS are CVS, SVN and Perforce while Git, Mercural and Bazaar are among the most popular DVCS till date.

Popularity Comparison: Since 2004, it has been observed that Distributed Version Control systems (Git) is taking over Centralized Version Control systems (SVN). However, there are still a few countries like Morocco, Tunisia and China where CVCS are still maintaining its popularity over DVCS. You can visit Google Trends to see how these two version control systems are performing across the world since 2004.

Further Reading: What is Version Control System (VCS)

How to Speed Up Your Website and Increase Traffic

What makes a website popular? Is this the content, SEO, attractive design, speed it runs at? Well, it is to be a perfect combination of all. If any of these breaks the entire chain breaks and site starts losing popularity considerably. In this article I will focus on Speed, which plays a major role in bringing more traffic towards your site. The following brief but very effective statistics shows how much a site depends on speed. It has been observed that even just an One second delay in page loading time will result a massive downfall:

  • 11% fewer page views
  • 16% decrease in customer satisfaction
  • 7% loss in conversion

And here is another statistics which tells us how people want sites to behave like in terms of speed:

  • About 47% of people expect a web page to load in two seconds or less!
  • About 40% will abandon a webpage which takes more than 3 seconds to load!
  • About 52% inline shoppers say quick page load is very important in order for them to stay loyal to that site!

From the above statics you can easily understand that speed is something which you must take into consideration in order to make your site a success! So, lets begin…

Minimize HTTP Requests

When you load a webpage, it first looks for the components to be loaded. Components can be CSS, JavaScripts, Images, Flash, Video, Audio and may be something else. For each single such component the webpage send requests to the server over HTTP. So more components you have on a page, more HTTP request the page has to send to the server. With all these requests going back and forth, the page ultimately suffers from a delayed load time. So, to make a page to load faster make sure you have the minimum server requests.

To achieve above goal you should follow some basic principles:

  • Streamline the number of elements on your page:It is very important that you decide exactly what you require on a webpage to display upfront. Many developers have a habit of experimenting different things but afterwards they comment out these section and just forget to remove them from HTML code when it is no longer necessary. Well, a few commented out lines may not affect page loading considerably, but a large number of such lines can. It is always recommended that you keep removing unwanted comments and lines from your HTML markup. This also makes sure that your HTML stays clean and easy for you to manage it.
  • Use CSS instead of images whenever possible: Comparing to old day website layouts today we have a lot more out-of-the box utilities to design a page more effectively. Like in old day practice, if we had to create a box with rounded corners, we needed to have at least one image (if not four) consisting of the corner images which we had to use in our CSS to make that rounded corner box. Today we have a simple CSS solution for this: border-radius: xpx; which in turn renders a box with nice rounded corners. There are many such small areas where you can easily avoid using images, whatever size they are of and use CSS instead.
  • Combine multiple style sheets into one: Many of us use to write separate CSS files to keep things easily distinguishable and manageable. For example, there could be style sheet called home.css which is specific for some elements to be used and styled for homepage only, or a style sheet called footer.css, which holds CSS properties for website’s footer elements only. This is really a good practice to have such organized way of keeping and maintaining our CSS. But the problem starts when the website loads and requests all these separate CSS files one after another. Longer your CSS files, increased load time your visitors would experience! So we need to avoid this situation and let our site load only a single CSS file but combining all rules from separate CSS files. Sounds awkward, right? But the solution is not so critical.
    We have SASS compilers available to do this job us! SASS is a utility which takes multiple SCSS files (which you want to be compiled) and create a single CSS file which you refer in our webpage.
    So, no more separate CSS files like above, rather name them as home.scss or footer.scss. Create another file called main.scss (you can name it whatever you like, there is no restriction for naming, but good to have a meaningful name). In this file you refer your separate SCSS files using @import like @import ‘footer’ or @import ‘home’. Important thing to remember that I haven’t used file extensions while @import-ing them. Now when you compile this main.scss file, the compiler takes the @import-ed SCSS files into it and creates a single main.css file which now consists of all your CSS rules you defined in separate SCSS files. You now simply refer this main.css file in your webpage. To know more about how SASS compiler works I would recommend you to read first.
  • Reduce scripts and put them at the bottom of the page:A webpage can have multiple JavaScript files to refer in order to work properly, like jQuery, your own custom script files or may be others as well. Generally you put them insidesection of the webpage, which is perfectly OK. But you have to understand that when a page loads it loads sequentially, i.e. first it reads the head section and whatever is in there will be loaded first, then to your body, where you have your content. Now if the head section is too heavy with a lot of CSS and JavaScript files references, it can easily understood that the loading time will increase as it will take more take time to reach to the actual content area and render it on page. You already have an idea about how you can minimize the number of CSS file references. Now with all JavaScript file references,
    it is a good practice to move them fromto the bottom of the page, i.e. just above . There may be a few script references that need to be in thesection and if you move them to the bottom page page might not work. In such situations, identify those scripts which have no effect at the time if loading your page and move them to the bottom – in short, move all your JavaScript references to the bottom of your webpage which have no significant task to do on page loading process.

Reduce Server Response Time

  • Database Optimization:If your database is delivering content from database, the first thing you should be sure about that your database is normalized and configured for output data with its optimum performance. A few things can easily make your database close to its optimum:
    (1) Tables are indexed, (2) Complex queries are using JOIN instead of Sub-queries, (3) Checking out execution plans of your queries and optimize them, (4) Use of pagination for large data sets, (5) Use Key constraints in Parent-Child relationships, (5) If your database is capable of handling Cascade operations, such as Delete, use it so that you don’t have to tell your code to delete records form different tables one by one.
  • Traffic and Hosting:You need to be very specific and clear about how you want your site to perform. If you are expecting a high traffic towards your site you need to check first whether your hosting provider is providing sufficient resource to handle that much of traffic. Because more traffic your site brings in, it makes itself slower. In such a situation you need to upgrade your hosting to a higher plan with more resources. In addition to that, you have to also consider the amount of resources required per user. If one user requires 50 odd resources to render,
    then at any given point, with at least one user visiting your site would make at least 50 calls to your server at one given instance. If 20 visitors are visiting your site one given moment, number of calls for resources will be multiplied by 20, i.e the site will now make 20 x 50 calls to the server.
  • Always Keep Server Software Up-to-date:Keeping your software up-to-date on the server is very important for your site to perform perfectly. Like in Windows server it Auto-updates itself, so are Linux server. But if you are on a dedicated server, you have to do this manually by going into the server, as most hosting providers do not give such support for free. Software updates come with bugs fixed, improved architecture, security patches and many more. Keeping software updated ensure your server is running with latest versions and security updates.

Used Minified CSS and JavaScripts

When a page is renderd, web browsers are not concerned about the readability of code. Minification makes sure that all unwanted or non-functional data in a code file is stripped that is not required by the file to execute. Unlike traditional compression techniques, minified files don’t need to be decompressed before they can be read, modified or executed.
Minification is performed after the code is written, but before the application is deployed. When a user requests a webpage, the minified version is sent instead of its larger sized original version. This allows the server to server the HTTP request with a much faster response time (reduced latency) and lower bandwidth costs. Use of minification techniques has become a general practice in present days’ web applications and should be used ranging from personal blogs to multi-million user services. I recommend you to read first about What is Minification and Why Minify JavaScript for a better understanding before you actually implement them in your websites.

Enable Browser Caching

Browser Caching reduces the site load time considerably. Caching can be done for static resources of your site like CSS, Images, JavaScripts etc, or even you can use this technique for database driven data as per your requirement. For static resources you can have longer cache expiry while for data it could be smaller. For example your site homepage content does loads fresh database once weekly, so you can use a caching for 7 days on this page. But if you have a product page which changes list of products randomly in every 3 hours, then the cache expiry could be set for 3 hours for this page. Any request of this page by the same user within 3 hours’ time will load the cached page, which will be way faster than the original page load time. There are different way of using caching in different development platforms like WordPress has a couple of nice plugins W3 Total Cache and W3 Super Cache. A WordPress plugin with more advanced techniques is WP Rocket but it is not free. In Drupal you can follow this resource. ASP.NET also has its own caching techniques. To know about how caching is done in ASP.NET, follow this article. If you are developing an ASP.NET MVC solution this article will tell you more about how to implement and enable caching in an ASP.NET MVC application.

Install Google PageSpeed on your Server

The PageSpeed module is an open source server module from Google that automatically optimizes your website speed; it makes modifications to your server and files, following website performance best practices, without requiring you to do anything else. Installing GooglePageSpeed will ensure that you are one step ahead already for maintaining a better speed of your website.

Optimize and Reduce Image Size

Un-optimized images in your application will have a serious pay load for your server. When a page is accessed on the browser and content is served, there are many HTTP requests the server has to deal with, which include images as well. If your images are not optimized and bigger in sizes, the load time will go considerably higher and there could always be a chance that your visitor ends up with a white screen of death! To avoid this situation, you much have your images optimized before they are served. There are two good plugins for WordPress out there: WP Smush and EWWW Image Optimizer. There is also a API based tool, Kraken which optimizes images well. You can use it for Drupal and Joomla. You may be interested to to know about Kraken’s Integration Libraries and Official SDKs, which covers a wide range of application development platforms.

Enable HTTP Keep-Alive

Do you know when a user opens a page of your website on your browsers how the server actually serves its content? It is a pretty heavy task load the server deals with! The server grabs each file individually by opening a new connection. In other words, for each file server opens a connection, grabs it, closes the connection and then reopens it for the next file, which in turn asks the server to use more CPU and memory and network resources. Enabling HTTP keep-alive ensures that all file requests to your server will be made via a single open connection, leading to a much faster website for your users by limiting the number of connections to your server. I recommend you to read about how to use Keep-Alive in Apache and IIS servers.

Regularly Optimize Your Database

Most developers do not pay attention to the database which is one of the most important building blocks of the websites they are building. But this is one of the powerful ways to boost up website speed and performance. If you are building a CMS driven solution like WordPress or Drupal, which depend heavily on database usage, optimizing database is one of the must-do items you have in your hand. A site can be made to run much faster by cleaning up database.
You can use WP-Optimize plugin for WordPress which automate the process for you without any additional headache or even you can do it manually if you like.

Responsive Website Layout – Media Query

What is “Media Queries”

Media Query is a feature of CSS3 which allows websites to adopt current screen resolution (width) and adjust itself accordingly to fit inside it.

Use of Media Queries in Responsive Web Layouts

According to a survey report published on, the number mobile internet users have crossed that of desktop. However, even before that, looking at the trend many websites were developed in responsive way to increase traffic. Today responsive website layout falls into essential requirement list of a website development procedure.

The thing works behind the scene to accomplish this feature is nothing but Media Queries. As its name suggests Media Queries deals with media. There are several media types that it can deal with like Braille, Embossed, Handheld, Print, Projection, Screen, Speech, tty and TV. But mostly considered medias in website development are Screen and Print and at times Projection and TV.

Examples of Media Queries

Media Queries are used in CSS. A media query is typically written in the following fashion:

@media <media_name> and (min-width: Xpx) and (max-width: Ypx),

where <media_name> can be like screen, print, projection etc. and X and Y represent pixel size.

@media screen and (min-width: 320px) and (max-width: 768px)

Let us take a simple example. If we want our site background to be White for smartphones and tablets but Gray for any device with pixel width higher than tablet we can use the following query blocks:

@media screen and (min-width: 320px) and (max-width: 768px) {
 body {background-color: #ffffff;}
@media screen and (min-width: 769px) {
 body {background-color: #cccccc;}

Let’s take a bit more complex example to re-position HTML elements according to device widths:

@media screen and (min-width: 1200px) {
 .logo, .caption {float: left;}
 .logo {width: 30%;}
 .caption {69%;}

the above CSS snippet executes when screen size reaches a minimum value of 1200px. Once it matches the pixel size, .logo and .caption starts to float left and their width become 30% and 69% of their immediate parent element. Now to make them to appear one below the other  (.logo at the top of .caption) in smaller devices, we write this:

@media screen and (min-width: 320px) and (max-width: 768px) {
 .logo, .caption {display: block; width: 100%

the above media rule executes between screen widths 320px and 768px and makes both .logo and .caption elements to display as block elements allowing them to stretch across their immediate parent element.

Commonly used Media Query break points

  • Smartphone: 320px
  • Tablet: 768px
  • Netbook: 1024px
  • Desktop: 1600px

Tablet and PC Monitor Display Sizes(Data by W3C, Jan 2017)

Tablet and PC Monitor Display Sizes(Data by W3C, Jan 2017)

Smartphone Display Sizes (Data by DeviceAtlas, 2016)

  • Nokia 230, Nokia 215, Samsung Xcover 550, LG G350: 240×320
  • Alcatel pixi 3, LG Wine Smart: 320 x 480
  • Samsung Galaxy J1 (2016), Samsung Z1, Samsung Z2, Lumia 435, Alcatel Pixi 4, LG Joy, ZTE Blade G: 480 x 800
  • Huawei Y635, Nokia Lumia 635, Sony Xperia E3: 480 x 854
  • Samsung Galaxy J2, Moto E 2nd Gen, Sony Xperia E4, HTC Desire 526: 540 x 960
  • iPhone 4, iPhone 4S: 640 x 960
  • iPhone 5, iPhone 5S, iPhone 5C, iPhone SE: 640 x 1136
  • Samsung Galaxy J5, Samsung Galaxy J3, Moto G4 Play: 720 x 1280
  • Xiaomi Redmi 3, Moto G 3rd Gen, Sony Xperia M4 Aqua: 720 x 1280
  • iPhone 6, iPhone 6S, iPhone 7: 750 x 1334
  • iPhone 6S Plus, iPhone 6 Plus, iPhone 7 Plus, Huawei P9, Sony Xperia Z5: 1080 x 1920
  • Samsung Galaxy A5, Samsung Galaxy A7, Samsung Galaxy S5, Samsung Galaxy A9: 1080 x 1920
  • HTC One M9, Sony Xperia M5: 1080 x 1920
  • Samsung Galaxy Note 5, Samsung Galaxy S6, Huawei Nexus 6P, LG G5: 1440 x 2560
  • Sony Xperia Z5 Premium: 2160 x 3840

What is Version Control System (VCS) – General Idea

What is Version Control System?

Version Control Systems are meant for tracking and keeping a history of changes you are making in your project files over time. It ensures that all changes are being saved in a location but each such change is tied up with some sort of versioning. The magic of versioning is that you can easily recall a specific version at any point of time without affecting any other changes that are saved in other versions. The concept of versioning is not only limited to development, but you can use it for other purposes as well. For example, you are writing a long and critical research report which can take long time to finish. If you save your everyday’s work with a specific version or under some system which creates versions for you, it would be very helpful for you to refer or even switch back to a particular version number easily whenever you want.

How Version Control systems makes developers’ lives easier

Not all the time you are working on something or in a project where you are the only one dealing with it. Rather when you are a developer in a development team, you may be accessing some parts of the code in a project which other developers in your team too can access. Thus changes made in one part of the source by one developer can be incompatible with those made by another developer working at the same time. Situation like this can easily be solved by implementing a Version Control system, bring the project and all developers working in that project under it all changes and activities can be tracked and logged in such a way that a developer can have the ability to go back forth between versions during development process. How?

  • A complete history of every file, which enables you to go back to previous versions.
  • The ability to work on independent streams of changes, which allows you to merge that work back together.
  • The ability to trace each change with a message describing the purpose and intent of the change.

Centralized Version Control System (CVCS)

In Centralized Version Control Systems, you have a single “central” copy of your project located on a server remotely and commit your changes to this central copy. You pull the files that you need from the server, but you don’t have a latest complete copy of the project at your local development environment. Some of the most common version control systems are centralized, including Subversion (SVN) and Perforce. A popular SVN is Tortoise SVN.

Distributed Version Control System (DVCS)

With distributed version control systems (DVCS), you don’t rely on a central server to store all the versions of a project’s files. Instead, you clone a copy of a repository locally so that you have the full history of the project. Two common distributed version control systems are Git and Mercurial.

Know more about CVCS and VDCS: Comparison Between Centralized and Distributed Version Control Systems