As of last Sunday, I’ve been working at Kobas for five years (a demi-decade 😅) , reading my post from a month in reminds me how much has changed and prompted me to provide an update.

Job Role

My job role has changed significantly throughout my time at Kobas. Initially, I was feature-focused and spent all my time programming. As time passed, I became more involved with bug fixes and technical product management: planning features, evaluating APIs and implementing technologies. We’ve also expanded our team along the way, so I’ve experienced our onboarding process from both sides. 😆

Issue Management

Previously we were using Pivotal Tracker for our issue management, while it did work great for planning features, it was lacking in terms of bug management. I worked on moving us over to YouTrack, which at the time required utilising both the Pivotal Tracker export API and the YouTrack API (a fun task 😁). YouTrack has worked great for us so far, we use their Agile Boards for sprints, project planning and issue triage.

Working Location

COVID-19 isn’t something I’ve posted about on here yet, which is strange considering that’s been the main subject of the past year. Before COVID-19, Kobas was hybrid-remote, having staff members working from home a certain % of the week, but still maintaining an office that could host all our staff members.

We’ve now transitioned to being completely remote, which I prefer. I’ve found GitLab guide on remote work fantastic for resources surrounding working remotely. Overall, I think our transition to remote work has gone smoothly as we already had a lot of technology in place to support remote work (like a VPN).

Features

We’ve made some impressive stuff for our clients since my last post, too much to really talk about without this becoming a changelog. The most recent thing that comes to mind is the Customer Interaction Centre, providing our clients with a way to support online ordering.

Other projects that come to mind when I think of my time here are: integrating PDQ terminals using socket connections (much fun), rewriting our stock system to support FIFO (not fun), and moving our API authentication over to OAuth 2.0 (easier to support third-party integrations).

Upgrades

We like to keep all our technology up to date in Kobas, and the last five years has seen a lot of upgrades.

Our back-end now runs on PHP 7.4 (currently working on upgrading to PHP 8) with CentOS 8 Stream as the OS. Our main framework is Symfony 5, after a lot of work migrating from Silex. 😬

On the front-end, we’ve added ReactJS into the mix, and new projects are now done in that. Lastly, on the automated testing front, we are still using Codeception but are moving our acceptance tests to Cypress.

Future

As evidenced by this year, it’s impossible to know what the future holds. But I hope to be able to post more about the work I’m doing at Kobas on here, as I’m aiming to add more open source projects. Stay tuned. 😉

Frequently with PHP you are going to need to cache things, mostly expensive SQL queries, but also data you aren’t going to want to be inserting into the database on every page hit, for instance website statistics.

With PHP we have a few options to achieve this;

• Caching with the file system .
  • Pros:
    • Works well with the Opcode cache
    • Usually the fastest method of caching for small or medium websites
  • Cons:
    • Clearing the cache can be a lot slower as you will have to recursively search through path’s and delete.
• Caching with SqlLite
  • Pros:
    • Can be substantially faster than a full-blown RDBMS
    • All data is stored in a normal file in the host’s file system.
  • Cons:
    • Can only support one writer at a time, which can cause high file system latency, which is inconvenient if there are many clients trying to access it simultaneously.
• Caching with APC
  • Pros:
    • Makes PHP faster for you through the so called opcode caching.
    • No special configuration required.
  • Cons:
    • Practically none
• Caching with Memcached
  • Pros:
    • Allows machines to pool their memory together as one large memory cache, perfect for large websites.
    • Cross platform and cross RDBMS
  • Cons:
    • Stores data in the RAM, not ideal for small systems
    • Is considered to be a volatile in-memory key/value store
• Caching with Redis
  • Pros:
    • Can act like memcached as a key/value store however it’s really a data structure server.
    • Persistence to disk, by default.
    • Values up to 512MB in size
    • Built in clustering
    • Extremely fast at everything
  • Cons:
    • The more objects you put in it, the more memory its going to use.

So as you can see there are a bunch of different systems that handle caching in arguably better or worse ways depending on how big your website is. Putting a small website on Redis is probably overkill, you might already have set up a RDBMS solution and now not want to change to a key value store etc.

This is where StashPHP comes in, you basically use the StashPHP library to cache things like so:

First you setup the driver to use, lets just use File System for the moment:

<?php 
// Create Driver with default options
$driver = new Stash\Driver\FileSystem(); 
$driver->setOptions(array());

// Inject the driver into a new Pool object.
$pool = new Stash\Pool($driver);

Now you can setup your by wrapping the following code around your code:

<?php 
// Get a cache item.
$item = $pool->getItem('path/to/item');

// Attempt to get the data
$data = $item->get();

// Check to see if the data was a miss.
if($item->isMiss())
{
    // Let other processes know that this one is rebuilding the data.
    $item->lock();

    // Run intensive code
    $data = codeThatTakesALongTime();

    // Store the expensive to generate data.
    $item->set($data);
}

// Continue as normal.
useDataForStuff($data);

Later on when you decide to add another cache, rather than needing to go rewrite all your caching calls etc. you can just change the setup of the drivers like so:

<?php 
$subDrivers = array(); 
$subDrivers[] = new Stash\Driver\Apc(); 
$subDrivers[] = new Stash\Driver\FileSystem(); 
$subDrivers[] = new Stash\Driver\Memcached(); 
$options = array('drivers' => $subDrivers);
$driver = new Stash\Driver\Composite($options);

$pool = new Stash\Pool($driver);

This saves you a bunch of time and allows testing what suits your application best.

This is just some thoughts on being a PHP developer in 2015.

A standard web project before used to just require you to setup a local web server, and then you’d upload to a standard web host with some worries about PHP versions perhaps but little to no thought required for the server side of things.Frameworks were a new thing, CodeIgniter was (to me at the time) the best thing to happen to PHP, introducing me to PHP MVC patterns, easily integrated vendor libraries (I never got into Zend Framework) and Twig .

Now a web project involves using programs such as Composer, Bower and Grunt just to manage project dependencies. Then you have PHP & JS frameworks like Symfony , Laravel, AngularJS that have really made life so much easier for us developers. Of course this all comes at a cost of having to put in time into learning all these new frameworks and tools, but the benefits of doing so are just amazing; development time goes way down and you create much better products. I wish I could further go into the benefits of each but they all require posts of their own to really get across their individual uses, I’ll attempt to get to that!

Working with UNIX servers is pretty standard for most web developers now, myself included. I’ve been using DigitalOcean for all my hosting, they really are a great host and I recommend them to anyone searching. Anyway a tool I found lately for server management which I guess is what has caused this post is Ajenti , before this I was using ISPConfig for the aim of being able to manage my servers easier than via ssh, however I found it’s interface pretty clunky and just overall slow, always ending up in ssh. After testing Ajenti in a fresh droplet I changed completely over to it on my other servers, so far it’s been amazing, I’m still using ssh here and there but overall Ajenti has really solved my problem so thanks guys. The install was amazingly simple too I recommend anyone looking for a GUI for their server to check it out.

So there seems to be a lot more to PHP web development now in 2015 than there was just a few years ago, though I personally feel all of it is for the better, making my life easier. It makes me wonder what it will be like in another few years though, whats next?

So in WordPress with plugins etc. you end up using shortcode in posts to keep things simple, an example would be if you want to display a gallery you would just use:

[galleries id="1"]

However trying to this when your outside of the “WordPress Loop” (in your theme files usually) you will hit the problem that WordPress won’t parse the shortcode.

The solution is very simple, just append the following to your shortcode:

echo apply_filters('the_content', '[galleries id="1"]');

And it works!

To read up more on shortcodes in WordPress click here .