Upcoming presentation at PHPQuebec on February 5th 2015

Join us at PHPQuebec’s february meeting, i’ll be presenting a few tips and tricks on optimizing your batch processing using number and calendar tables.

The slides are available at slides.com:

For more information you can visit Meetup to register and follow PHPQuebec’s meetings at:

February 2015 Meeting – Advanced SQL Techniques for Simpler Batch Operations

Thursday, Feb 5, 2015, 6:30 PM

Pronexia
1280 Bernard West, Suite 303 Outremont, QC

18 PHPers Attending

February’s meeting will be held on February 5. And once again our sponsor Pronexia will be hosting us and providing the refreshments.When: February 5, 18:30 for drinks (sponsored by Pronexia) and networking. 19:00 for the talk.Where: Pronexia’s office  1280 Bernard West, Suite 303  Outremont,  Quebec  H2V 1V9Advanced SQL Techniques for Si…

Check out this Meetup →

Standardizing exception handling in PHP projects using CrazyCodr/StandardExceptions

A while back i created an exception library. The project was launched about a year ago, i’ve been using it a lot in my projects but there is definitely a lack of usage outside my projects and i’m not receiving any feedback. This post today is to show you the basics of the library and how you can make use of it.

What is crazycodr\standard-exceptions

This project is aimed at providing additional standard exceptions to php. Many exceptions that are missing from the SPL are constantly being reproduced in different projects. By providing a package of high-quality, well organised exceptions, it will, in the long run, increase interroperability between projects.

You can see more information about this package on GitHub at https://github.com/crazycodr/standard-exceptions.

Re-classification of existing exceptions

The existing native PHP exceptions are extended but stored in a new namespace tree that allows a better organisation of the different exceptions. Thus, if someone switches to the standard exception package, it should be backward compatible automatically.

Proposed namespace structure

The package proposes a few namespaces to allow more exceptions to co-exist and not bloat the documentation:

  • StandardExceptions (namespace)
    • ArrayExceptions (namespace)
    • IOExceptions (namespace)
    • LogicExceptions (namespace)
    • OperationExceptions (namespace)
    • ValidationExceptions (namespace)

How to use this package

Simply include it into your project using composer!

composer require crazycodr\standard-exceptions 1.*

Then you can start throwing off a few exceptions just as you would normally do.

	throw new \StandardExceptions\IOExceptions\NotAFileException();
	throw new \StandardExceptions\Validation\InvalidStringException();
	throw new \StandardExceptions\ArrayExceptions\ArrayKeyNotFoundException();

Contact and contribute

Don’t hesitate to contact and contribute to this library by supplementing it or opening discussion items in the issues tab on GitHub.

Using illuminate routing as a standalone component

I tried using Illuminate\Routing today as part of an application at work i am refactoring and following this article was quite helpful:

http://www.gufran.me/post/laravel-illuminate-router-package-in-your-application

The problem i hit was that if you set this into a subfolder such as:

/admin/mass-creation/

And expect the routing to be based off the root of the web site, then you are wrong. All your routes must be based off the url where the router is instanciated into. So if your router is in /admin/mass-creation, your routes must be something like:

$router = $ioc->make('Illuminate\Routing\Router');
$router->get('/list', function()use($controller){ return $controller->getList(); });
$router->get('/create', function()use($controller){ return $controller->getCreate(); });
$response = $router->dispatch($request);

And not:

$router = $ioc->make('Illuminate\Routing\Router');
$router->get('/admin/mass-creation/list', function()use($controller){ return $controller->getList(); });
$router->get('/admin/mass-creation/create', function()use($controller){ return $controller->getCreate(); });
$response = $router->dispatch($request);

Big companies, big structure, slow progress!

If you have never worked in a big company before (I didn’t) then you need to be aware of how these businesses operate or you might be suprised at the amount of repression and control being exerted onto you.

My most recent contract resulted in a pretty long and harsh year because i came in with the wrong train of thoughts. I was going forward with the usual idea and energy level that characterises me to try and move things but was suprised at the amount of energy it took to actually make things change. I did make some changes but looking back to the amount of time and energy i invested to achieve it, i am completly flabergasted.

The approval process

At first, i thought that having the title “Director” meant i was entitled to make changes to the structure of the things below me. Was i surprised that many control structures were in place even for the directors to prevent them changing anything, but, if you need to do something, you need to do something. I had to press constantly, hours of work, countless of speeches and demonstrations to achieve my goals. Some of them were achieved, others not.

Big companies operate a lot on the hierarchical pattern where everything has to be approved from bottom to top and it takes a lot of time. Some people with even less company power were able to stop me from moving forward on some aspects because they just didn’t have the time to review the changes they originaly asked.

For instance, a branch of code asked by a user in octobre has still not been reviewed in june next year. The master branch is 150 commits ahead. I predict one long merge operation and many conflicts.

This leads us to understanding the power behind titles. Are titles correctly used? Why am i a director but have no power to decide…

Inducing ideas slowly but surely

In time, i realized that the only way to make things work out in an environment like this is to be relentless. Talk about what you want to do, try to implement your ideas constantly and be rebuked regarding my over zealous optimism. It will take you many days, weeks or even months depending on the size of the change. Eventually, you will succeed at inducing the idea that what you are proposing is really required. The important aspect is not to lose your temper or you lose all your hard acquired work.

For example, this client didn’t have bug tracking, source code versioning and worked in completly isolated silos each person having their own applications to handle. What happened when this person would leave for holidays or vacation? Nothing, actually the project was put on halt… Unless there’s a very high priority problem, everything would wait for this person to come back. Things had to change! We are not talking about working in pair programming or agile here, just sharing knowledge and offloading pressure when needed.

As i came into the company, i made many presentations regarding code structure such as SOLID/STUPID presentations. I also introduced tools such as Git and eventually introduced a bug tracking software called JIRA. The acceptance was slow, for example, Git/Stash was not fully used by all team members until recently (4 to 8 months acceptance). JIRA was installed in the christmas period and i had to push the idea of using a bug tracking until early May, it was during a group project that i was able to force people to use JIRA. Now, 1 month later, everyone is loving bug tracking and using it pretty extensively.

Conclusion

So, don’t be surprised by the heavy bureaucracy of big companies and the refusal to change mindset. Don’t let your hopes down, it takes a lot of time for these companies to make a move mostly due to the amount of work, paperwork and the state of  imutability of these businesses.

You want something done?

You can’t just do it!

You have to induce the idea, slowly but surely.

How to set appropriate priority of issues

One question that often gets raised is how to qualify the priority of bugs/issues you receive. Knowing when to correct a bug or fix an issue is something most people don’t have a problem as long as it is rightfully prioritized.

What is priority?

Priority is a relative measure of the importance of an element versus others. So how do you elaborate what goes ahead of another? Use a non relative measure such as the impact on workload.

Many companies will have priority charts that defines how to classify priority of issues. But, if you are reading this, it’s either because you don’t have one, or maybe your current chart isn’t good enough, or your company doesn’t have a chart at all.

Composition of priority versus an issue/bug

I’ve been working with this method for a few years now and it has rarely given me incorrect results so here goes. The two components we need to work with is the severity and reach.

  • Severity defines how catastrophic is the bug and the effect it has on the operation at hand.
  • Reach defines how many people are affected by this issue either indirectly or directly.

Defining severities

To define severities, you have to look at the different levels of severity that your application can cause. Good examples are the following: Life threathening, Blocking, Cannot operate, Major, Annoying, Minor, Trivial, Subtle. All these severities define the importance of the problem:

  • Is it dangerous for the life of one or more individual?
  • Does it prevent you from working?
  • Is it a simple issue that you can bypass and work with something else meanwhile?

When you have defined a list of severities, assign a number from 1 to 100 to it. This number will be multiplied by the reach’s value to create a final priority value. You can use more than 100 if you want, but the important part is to assign very high values to very high severities and drastically lower values as you lower the priority. For example:

  • Life threathening: 100
  • Cannot operate: 60 (-40 compared to previous)
  • Annoying: 30 (-30 compared to previous)
  • Minor: 10 (-20 compared to previous)
  • Subtle: 5 (-5 compared to previous)

Defining the reach of an issue

Just like severity, you need to define the reach of an issue. Take into account the amount of time/money lost or the number of end users affected. If the problem can reach your users but affect just 1 customer, then it isn’t all that dangerous. Your issue here is to calculate the impact of a problem on the workload and on the customer base. For example:

  • All customers/users: 100
  • Many customers/users: 60
  • Some customers/users: 30
  • A user/customer: 10

Another list you can use:

  • Whole company/Big boss: 100
  • A whole branch/Branch manager: 60
  • A department/Department manager: 30
  • A few users / A supervisor: 10
  • A single user: 5

Calculating priority and testing

The next step is to cross these two tables and adjust the values. By crossing i mean, use a spreadsheet and put priority on one axis and reach on another axis, compute the multiplication of each crossing values.

Next look at each final value and the different components. It helps to render this list into a three column list view in the best scenario and sort by the ending value. You can then compare:

  • Life threathening + 1 user: 500 pts
  • Many customers + Annoying : 1 800 pts
  • Cannot operate + A whole branch: 3600 pts

That really gives us a clear insight here that something is wrong… Life threathening issues should always be at the top, whatever the case. Lets adjust life threathening to 10 000 points.

  1. Life threathening + 1 user: 50 000 pts
  2. Cannot operate + A whole branch: 3600 pts
  3. Many customers + Annoying : 1 800 pts

Now this makes more sense…

Throwing in the age

The last parameter i like to put into that is age. Age can be calculated in seconds, minutes, hours, days, weeks, months or even years; It’s up to you… I usually factor in the age in a matter of days and this simply adds points for each day a problem has been waiting in line to be solved. This way, even the “Single user + Subtle” issue will gain enough points eventually to be considered important.

Conclusion

Take into account at least severity and reach when calculating priority of an issue and if you constantly have a big backlog of issues, you might want to throw in an age to adapt the values and give some importance to the lower impact issues.

Happy bug hunting, prioritizing and solving!

Tips and tricks from a PHP specialist