Engineering

PuPHPet : A GUI for making visualization and configuration easier.

If you have gone through my last post on Vagrant, you would have understood how important it is to have automations along with your development chores. In this race towards technological advancements, there are tones of tools, which help the developers fraternity to fasten up the development. Code base getting big and you get much more time to deliver a single user story. That’s how my stint to search something new, which makes life easier for the whole team. In this process, realized the power of Vagrant. But configuring it, for different environments was still difficult. That’s how I came to know about a site phpupet.com. Its a GUI for configurating Vagrant, with simple Puppet script.

 

What is PuPHPet ?

As I said above, its a GUI to configure you Virtual Machine, from multiple options of Web servers for PHP and multiple modules for PHP development. You just have to select servers, databases and modules you require for your development; and you are done. Download the manifest file, unzip it, and say “vagrant up”. That’s All! It will start downloading the packages on your virtualized distro. And within 15-20mins you will have your development environment ready, to play on.

Why to use it!


Answer is pretty simple, “Necessity is the Mother of all inventions.”

Advantages..

I have added the use case, where Vagrant fits in and when to go for such environments. Now it’s your turn to test it, and check whether it fits with your use case or not. But remember, once Spiderman said; “With great powers, comes great Responsibility” Enjoy!

Standard
Uncategorized

PSR’s | PHP Specification Request | Proposing Specification Request

Introduction :

PSR, a PHP Specification Request, is an attempt to standardise the way people use PHP in the hope that different sets of code libraries will work together. I am writing it down here, just to make everyone understand why this is necessary, and the objective behind standardizing the way everyone writes code. This is a must, when you are trying to write your Plugin or any class; which are pluggable. These specifications have been introduces by the body called PHP-FIG; PHP Framework Interoperability Group. The focus was to create standards for every developer (call it contributor), so that classes/packages/plugins can be plugged in any where, to other frameworks as well. But later, they have started rolling out for every package. Composer, a Package management system; also considers these as guidelines. So let’s see what PSR talks about in it’s 5 versions.

 1. PSR-0 : Autoloading Standard

The following describes the mandatory requirements that must be adhered to for autoloader interoperability.

Mandatory

  • A fully-qualified namespace and class must have the following structure \<Vendor Name>\(<Namespace>\)*<Class Name>
  • Each namespace must have a top-level namespace (“Vendor Name”).
  • Each namespace can have as many sub-namespaces as it wishes.
  • Each namespace separator is converted to a DIRECTORY_SEPARATOR when loading from the file system.
  • Each _ character in the CLASS NAME is converted to a DIRECTORY_SEPARATOR. The _ character has no special meaning in the namespace.
  • The fully-qualified namespace and class is suffixed with .php when loading from the file system.
  • Alphabetic characters in vendor names, namespaces, and class names may be of any combination of lower case and upper case.

 

2. PSR-1 : Basic Coding Standard

Overview

  • Files MUST use only <?php and <?= tags.
  • Files MUST use only UTF-8 without BOM for PHP code.
  • Files SHOULD either declare symbols (classes, functions, constants, etc.) or cause side-effects (e.g. generate output, change .ini settings, etc.) but SHOULD NOT do both.
  • Namespaces and classes MUST follow an “autoloading” PSR: [PSR-0PSR-4].
  • Class names MUST be declared in StudlyCaps.
  • Class constants MUST be declared in all upper case with underscore separators.
  • Method names MUST be declared in camelCase.

 

3. PSR-2 : Coding Style Guide

This guide extends and expands on PSR-1, the basic coding standard.

The intent of this guide is to reduce cognitive friction when scanning code from different authors. It does so by enumerating a shared set of rules and expectations about how to format PHP code.

The style rules herein are derived from commonalities among the various member projects. When various authors collaborate across multiple projects, it helps to have one set of guidelines to be used among all those projects. Thus, the benefit of this guide is not in the rules themselves, but in the sharing of those rules.

Overview

  • Code MUST follow a “coding style guide” PSR [PSR-1].
  • Code MUST use 4 spaces for indenting, not tabs.
  • There MUST NOT be a hard limit on line length; the soft limit MUST be 120 characters; lines SHOULD be 80 characters or less.
  • There MUST be one blank line after the namespace declaration, and there MUST be one blank line after the block of usedeclarations.
  • Opening braces for classes MUST go on the next line, and closing braces MUST go on the next line after the body.
  • Opening braces for methods MUST go on the next line, and closing braces MUST go on the next line after the body.
  • Visibility MUST be declared on all properties and methods; abstract and final MUST be declared before the visibility;static MUST be declared after the visibility.
  • Control structure keywords MUST have one space after them; method and function calls MUST NOT.
  • Opening braces for control structures MUST go on the same line, and closing braces MUST go on the next line after the body.
  • Opening parentheses for control structures MUST NOT have a space after them, and closing parentheses for control structures MUST NOT have a space before.

4. PSR-3 : Logger Interface

This document describes a common interface for logging libraries.

The main goal is to allow libraries to receive a Psr\Log\LoggerInterface object and write logs to it in a simple and universal way. Frameworks and CMSs that have custom needs MAY extend the interface for their own purpose, but SHOULD remain compatible with this document. This ensures that the third-party libraries an application uses can write to the centralized application logs.

The word implementor in this document is to be interpreted as someone implementing the LoggerInterface in a log-related library or framework. Users of loggers are refered to as user.

For More details, check out : https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-3-logger-interface.md

5. PSR-4 : Autoloader

Overview

This PSR describes a specification for autoloading classes from file paths. It is fully interoperable, and can be used in addition to any other autoloading specification, including PSR-0. This PSR also describes where to place files that will be autoloaded according to the specification.

Specification

  1. The term “class” refers to classes, interfaces, traits, and other similar structures.
  2. A fully qualified class name has the following form:\<NamespaceName>(\<SubNamespaceNames>)*\<ClassName>
    1. The fully qualified class name MUST have a top-level namespace name, also known as a “vendor namespace”.
    2. The fully qualified class name MAY have one or more sub-namespace names.
    3. The fully qualified class name MUST have a terminating class name.
    4. Underscores have no special meaning in any portion of the fully qualified class name.
    5. Alphabetic characters in the fully qualified class name MAY be any combination of lower case and upper case.
    6. All class names MUST be referenced in a case-sensitive fashion.
  3. When loading a file that corresponds to a fully qualified class name …
    1. A contiguous series of one or more leading namespace and sub-namespace names, not including the leading namespace separator, in the fully qualified class name (a “namespace prefix”) corresponds to at least one “base directory”.
    2. The contiguous sub-namespace names after the “namespace prefix” correspond to a subdirectory within a “base directory”, in which the namespace separators represent directory separators. The subdirectory name MUST match the case of the sub-namespace names.
    3. The terminating class name corresponds to a file name ending in .php. The file name MUST match the case of the terminating class name.
  4. Autoloader implementations MUST NOT throw exceptions, MUST NOT raise errors of any level, and SHOULD NOT return a value.

References :

Standard
Engineering

Vagrant : A new weapon in the automation artillery

It was absurd, the time, when we use to write shell scripts just to automate the installation process. Being into DevOps team, introduced me to new topics and tools for automating the process we do in a regular basis. There were scenarios, when we got stuck and tried to find new (rather say weird) ideas. Pointing one problem here, was project specific installations. I use to work over LAMP stack, but as I jumped on to DevOps it became very evident to do performance tuning as per the requirement and the usage of the application. So for that I tasted all possible flavors of Linux, along with combinations of web-servers to try out. I figured out first thing, that if you have to get in to Vertical scaling of the application, only if you find the web-server not supporting the provided infrastructure. So now, I had different kinds of Web-Servers, along with different packages/libraries installed according to the different application I had to work with. This was a cumbersome job, to install-upgrade-or-degrade packages from application to application. This whole scenario lead towards only one thing, which was virtualisation.

What is Vagrant ?

I tried different tools, softwares in the whole process and settled with Vagrant. For the readers, who doesn’t know about Vagrant, here is what Vagrant is;

“Vagrant provides easy to configure, reproducible, and portable work environments built on top of industry-standard technology and controlled by a single consistent workflow to help maximize the productivity and flexibility of you and your team.” 

Why Vagrant (and Puppet)!

In simple words, Vagrant can manage your VMs. Now again, coming back to the problem with which we started. So far we had resolved the problem with handling the different flavors of OS’s. Moving ahead, I always wanted to create a generic approach for the installation process, and to make it much less painful. I got my answers when I read about “Puppet” along with “Vagrant”.
 
Puppet is one of the main provisioners available to Vagrant. I will not explain the differences between Puppet and Chef here, but Google will keep you occupied for hours on the subject! From the Puppet website,

“Puppet uses its own configuration language, which was designed to be accessible to sysadmins.”

 So with the combination, the search ended with a very scalable approach towards setting up environments. The two, Vagrant and Puppet; works with a lot of ease. I tried it with different flavors of applications, with different web-servers / configuration and libraries. Surprisingly, this solved our problem to get into different dev-environments, along with multiple configurations automated with the help of Puppet. I have not put the steps of creating and setting up Vagrant over your Virtual Box, coz you will get it all over the Internet. Though, I am including all the URL’s which might help you guys, in the process;
  1. Make Vagrant Up yours
  2. Vagrant : Getting Started
  3. Development Environment the right way with Vagrant and Puppet
  4. Rapidly Building LAMP Development Environments with Vagrant

In this all learning’s, I got one amazing tool, a Web UI called PUPHPET (http://puphpet.com/), to create and customize your environment (specifically PHP) and gives you a downloadable manifest; vagrant up and you are done. It’s a short and easy way to create manifest, and automating it along with the GUI. I will cover my experience and extremities with PuPHPet in the next post. 

Standard
Life

Webonise Lab and Me : It’s been 3 years now! :)

Hi Everyone,

Just wanted to mark the date, 7th March 2014, completed 3 years at Webonise Lab. It was an awesome journey till far. And would expect much more adventures and challenges with the new role and work. Enjoyed, the day with a drive to the favorite place. It’s a hill-top restaurant, at Sus-Road,Pashan. It feels thrilling everytime, I take Laddo to the hill-top, sat down with the cup of Coffee and see the colors spread by the almighty over his own canvas.

At Sus road Pune - @n1shant

Over Facebook : “3 years, and loads of things which has changed. An extentended family, love and lots of code. Still lot to come, to reach the acme!”

Thanks to everyone who supported to reach this far.

Standard