Website revitalised using Gatsby!

This year, one of my personal goals was to revitalise this website and get the source code onto Github.

Historically it has been a blog, and not that anyone’s really noticed, but I haven’t done any blogging lately. While I do want to maintain my blog, and I intend on continuing to post to it, I don’t think it should be the focus of this website anymore.

Moving forward, I want this website to be somewhere:

  • I store technical information that I might need to refer to later.
  • I can highlight projects I’m working on & try out new ideas.
  • I can blog about different topics easily.

This presented a few issues for me with the websites existing setup:

  • It was built on WordPress, which I didn’t find very motivating to develop on anymore.
  • It was self-hosted on a server that included websites for family & friends. This made me hesitant to install new tools or languages on the server.
  • The existing UI/UX of the website didn’t cater to most of what I had in mind.

Naturally, I concluded the best course of action was to start from scratch—the sort of decision you can easily take on a project that’s entirely your own.

I had recently started to use ReactJS on a few projects at Kobas and was enjoying using it, so I decided I would use that for the frontend. I also knew I wanted to utilise some form of auto-deployment for the project, as that makes development much more comfortable.

After several iterations of trying different JAMstack frameworks, I landed on Gatsby hosted on AWS Amplify.

I started the project using the ”Gatsby WordPress starter”, immediately giving me a ReactJS frontend with the data sourced from my existing WordPress instance.

This allowed me to quickly get to a point where I could work on the design using real data and recognise the functionality I needed to code myself. While I did have data sourced from WordPress, I didn’t have a comment system, contact page, search, or sidebar widgets for things like tags/categories.

I needed to decide what I didn’t immediately require, as I wanted to get the new version out as soon as possible. A design I was happy with was the first thing to get added to my MVP list. The sidebar widgets I considered design-related, the website looked bare without them, they went into my MVP list. The contact page also went onto the MVP list, mainly as it was trivial to add utilising getform.io.

I decided that I could live without a comment system, it had never gotten much engagement anyway. I also thought that if I wanted one later, I could use something like Disqus. Adding search functionality seemed the most complex out of the features I was missing, so I didn’t add it to the MVP list.

Over the next few weeks, I worked on the above MVP list. Doing my best to avoid adding more functionality along the way.

Once I was done with the MVP list, I started looking at deployment options. I wanted something I wouldn’t need to spend much time configuring. AWS Amplify fit that requirement. First, I moved my domain over to Route53. Then I pointed Amplify to my Github repository, which automatically picked up the build command in my package.json. So simple!

I’m pretty happy where I’ve got to at this point, any future development I want to do here is much more streamlined for me. More fun stuff to come I hope. 😀


Posted on October 29, 2020

Programmer Personality: 2020

While converting over my previous post of my Programmer Personality, I decided to do it again and see whats changed, as expected it has.

Your programmer personality type is:

DLSB

You’re a Planner..

You may be slow, but you’ll usually find the best solution. If something’s worth doing, it’s worth doing right.

You like coding at a High level.

The world is made up of objects and components, you should create your programs in the same way.

You work best in a Team.

A good group is better than the sum of it’s parts. The only thing better than a genius programmer is a cohesive group of genius programmers.

You are a liBeral programmer.

Programming is a complex task and you should use white space and comments as freely as possible to help simplify the task. We’re not writing on paper anymore so we can take up as much room as we need.

Find out what kind of programmer you are here !


Posted on August 09, 2020

Easy Caching with StashPHP

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.


Posted on September 08, 2015

Being a PHP Developer in 2015

Generic coding image

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?


Posted on January 27, 2015

Apache Localhost Rendering Slowly?

Slowweb-2.jpg Is your localhost taking longer than expected to load?

A possible quick fix is to edit your httpd.conf file and set 'ServerName' to 127.0.0.1:80 . This can make the difference between millisecond load times and crying while Apache tries to load.

# ServerName gives the name and port that the server uses to identify itself.
# This can often be determined automatically, but we recommend you specify
# it explicitly to prevent problems during startup.
#
# If your host doesn't have a registered DNS name, enter its IP address here.
ServerName 127.0.0.1:80

Posted on November 03, 2014