Well, what goes around and all that and I’m getting back into the idea of front and back end development separation. It’s still very much hobby coding at present but I’m starting to delve more and more into it – last week I discussed a starter I’d put together in Node.JS to build a simple API and this week I’ve started tentative steps working towards the front end of that with React.

It’s certainly something I’m really looking forward to spending some more time with and I’ve already looked at a couple of tutorials online for ingesting from APIs, passing data back and forth between components, but one of the things I really wanted to do was get myself set up with a good starter project I can take forward to kick off my own projects going forward.

Over the last few months at work we’ve started using Tailwind as our go to CSS framework – it’s an excellent set of utility classes that hooks into Webpack and it’s so intuitive it’s led me to completely abandon the bloatiness of Bootstrap. One of the key reasons for this is the fantastic way that Tailwind prunes any unused styles on build, leaving you with a streamlined and super quick to load stylesheet. To me this felt like the perfect thing to pair with React to start creating some nice quick web apps.

Fortunately Tailwind have a great step-by-step guide on how to get Tailwind working in tandem with the create-react-app environment, but I didn’t really want to have to go through all that every time I wanted to spin up a new app. So, I built my own starter which not only incorporated Tailwind into the process but also built in node-sass to allow me to code scss stylesheets, as well as moving the default c-r-a set up into a more logical structure that separates components from styles.

You can grab it from GitHub here and it’s what I’m planning to start using to build some tasty React stuff going forwards. Watch this space and shout up in the comments if you find this useful!

As with most developers, I’ve worked with APIs for a big chunk of my career – being able to access third party data in a secure fashion to use in your own applications is kind of one of the cornerstones of being a good and efficient developer and I’ve utilised this heavily on projects like CLOCK and the work I did on the University of Lincoln Research Bridge. While I’ve always been happy to consume data from other parties endpoints, though, I’ve not often actually written my own; and while I have built my own solutions to allow applications to access data within the systems I’ve worked with it’s never been in a “proper” REST way.

One of the things I had hoped to do with Research Bridge, before the project itself was suspended several years back (that’s a story for another post… maybe…) was to convert the WordPress based proof of concept we’d built into something that was more sustainable and modern. While I orbited Laravel and Symfony for a while, one of the constant thoughts I had was to separate the back and front end into separate Node.JS apps – the back end to handle the data collection and distribution, and the front end to get this data and display it to the user.

As readers of this blog will know, I’ve been a tinkerer with Node.JS for a number of years and, to me, this seemed like the logical choice to not only simplify the code base, but also to make the core “bridge” data easily reusable by other applications. While I never got the opportunity to learn and apply this to the production Research Bridge app, it’s something that I’ve returned to over the last couple of weeks, toying with different tutorials and ideas to get to a point where I have what I’d consider a good foundation for building a RESTful endpoint to act as a backend for an application.

If you want to take a look, it’s in this GitHub repository here.

Now, I can’t fully take credit for the code – it’s largely influenced by this Medium article by Abhijit Roy, however I have made some tweaks such as simplifying down the schema so as not to make it too bulky for a starter project, as well as tweaking the code formatting to match my own. Still, if you want to get a better understanding of what the code is doing, check out that original article.

So, first things first, why MongoDB? Well, again, it was something I’d wanted to get to grips with for a while, being a SQL focussed developer for my entire career. As with many things, this revolved largely around the requirements of the roles I’ve been in. The idea of a database that stored its data not as structured SQL but effectively as collections (that’s what “tables” are literally called in MongoDB land) of JSON documents fascinated me.

One of the things that stood out for me when playing around with this, is that, while you’re learning at least, it’s far easier to set up your DB environment using the free service at MongoDB Atlas. While I got MongoDB up and running on my Mac no problem, it was quite the fiddly process – for experiments, Atlas will do exactly what you need to and host your data in the cloud.

Also, when you’re testing your endpoint with Postman (which is a fairly essential piece of kit, by the way), don’t forget to set the body type of your Post requests to Raw and JSON – I had a fantastic time trying to figure out why my perfectly correctly figured JSON data was being rejected by the insert function and this was the reason…

Anyway, I hope this helps you if you’re interested in API development. It’s definitely something I’m hoping to be playing around with in the future and the next step is to create a tasty front end (I’m thinking of using React) to plug onto the API here.

As always, please shout up in the comments!

For me the last two years have been a real change in how I look at this kind of thing, from changing jobs to having to focus my mind a lot more in a personal environment that’s largely gone into stasis, and for a period my personal organisation took a dive. Recently, though, I’ve been trying hard to organise myself, to write more and do more coding exercises on things that I don’t get an opportunity to do outside of work; this has led me to need to be way more organised, and over the last couple of months I’ve realised there’s three devices I use more frequently than anything else for different tasks.

I think what fascinates me most is how interconnected technology has become; when I read back through posts on this site of me lambasting Apple’s walled garden device approach VS the more open tech from Google and Microsoft, then consider the fact I’m writing this post on an iPad, using imagery I took on two different devices that I also back up to a Google Drive account, I realise we live in a far more connected world than we did 10, maybe even 5 years ago. With that, these are the three devices I use most to manage my personal work.

MacBook Air

This is a very recent change based on a year of using a MacBook Pro for work while struggling through trying to do personal coding on a very creaky old Windows machine. Anyone who’s previously read articles on this site will know I’ve long been a Windows user, through my days at the City of Lincoln Council through to my time freelancing and my work at the University of Lincoln.

But the more I started adopting modern ways of coding, the more I realised that the Windows approach wasn’t cutting it any more – I needed to be able to work more fluently on the command line, not be hamstrung by Windows non-Unix conventions, and when I started with Laser Red moving on to a Mac was the logical solution.

One year on and I picked up one for myself – an M1 MacBook Air released towards the tail end of 2020 and a very tasty prospect for both productivity and some light gaming. I’ve not quite pushed it as far as I’d like, but as a development machine it’s fast and efficient; I’m planning on doing some video editing soon and it certainly feels like it’s going to hold up well.

The only downside I’ve really found is the Air having two USB C ports over the Pro’s 4, however a decent USB dock has mitigated that and I’ve even rearranged my office set up to allow me to easily hot-swap my work Pro for my personal Air when I need a larger screen to work off or game (gaming on a Mac is an interesting thing, but that’s a whole other article!)

iPad Pro

So,yeah, apparently I’m an Apple person now… Sort of…

I picked up my iPad Pro over a year ago to replace my older iPad (I think it’s a 2012 model?). I predominantly got it to use as a writing device as well as for media consumption but it’s ended up becoming a nice lightweight alternative to a full OS device for productivity. I picked up the keyboard case to go with it and despite having a fairly small footprint, I really enjoy using it for writing.

Yes, I do prefer writing on it over my PC or Mac; the apps I use (this was written entirely in the WordPress app and I also use Google Drive for general writing and Celtx for screenwriting) are light and free from distractions. But it’s also great for low level video editing with LumaFusion, photo editing using Snapseed and sketching in ProCreate using the Apple Pen.

As a media device it’s incredible with good sound and a bright screen, with compatibility across all my digital media and streaming services, and advances in streaming video games mean I can use services like Stadia to play AAA game titles on it.

There’s still one or two niggles I have with it – iPad OS is a far more open ecosystem than it once was, with a proper file manager and better interactivity between apps overall, but it’s still not the same as a grown up OS – there are still times when I have to jump through hoops to say transfer audio samples between Hokusai and GarageBand, or get photos from my Google Photos storage into an app.

But it’s small enough to pop open in the dinner table for quick note taking, prop up in the kitchen to watch a film or sit on my lap on the sofa to do some more creative work. Being able to use a USB C hub to connect “proper” devices to it is also a bonus, plus it doubles as a second screen for my Mac thanks to the magic of Apple’s sidecar technology.

Pixel 4a with 5g

Yes, I still use an Android phone.

Despite moving my productivity largely over to Apple devices I still can’t bring myself to get an iPhone. I think that’s largely down to the fact that I still use Google apps primarily and having my phone on me all the time makes it my first point of call for note taking, checking emails and bringing up documents to read on the go.

I also love the camera tech Google builds into their devices. I do dabble in photography – it’s not really a hobby but it’s something I enjoy and having a camera as good as the one on the Pixel just in my pocket is fantastic. Sure, it’s not THE BEST CAMERA, but it’s excellent for taking good looking photos, the stock app has some reasonable settings and the more open ecosystem on Android means there’s good options for getting more technically advanced camera apps such as Filmic Pro which I use for video.

I can’t see myself moving off an Android handset in the future, but the fact that I can seamlessly go between my Apple devices to it means I’m not particularly bothered – I’m no fanboy and I’ll take myself where the tech is best to do what I need it to, whether that’s using a device from Google, Apple or Microsoft.

And I guess that’s the purpose of this post, to talk about how we seem to be entering a golden age of tech where everything is working with everything. Walls are being broken down – Apple tech and apps are appearing on other devices (heck, we can watch Apple TV and iTunes purchased video content on the new Google ChromeCast for goodness sake!) cloud services and standardisations of connection tech via USB C and Bluetooth means that we can transfer data between devices in a cinch and it’s feeling less like an “us and them” mentality towards interoperability.

This can only be a good thing and it opens up opportunities for everyday users and folks with specialist tech requirements to pick up a device knowing that there will generally be a way for them to carry their data and experiences with them regardless of the new tech they’re moving on to. I like it!

So, has the opening up of tech walls helped you make any different decisions on the hardware or software you use? Shout up in the comments!

Now, I’m going to hold my hands up here and say my testing mojo isn’t great. It’s something I keep trying to get right but I often don’t find myself in a position professionally where I have the time or the right kind of project to set up a decent automated test, so my skills in this area are somewhat underdeveloped. Still, that doesn’t mean I can’t take some time out to skill up (a good developer is always learning, imo) so I decided to take a look at how to set up automated testing and indeed test driven development, in Node.JS.

I’ve set up a really simple Node app which you can grab from GitHub that takes arguments from a command line, performs simple calculations based on those arguments and outputs the result. So, if you launched the app with:

app.js add 2 2

The code would ADD 2 TO 2, or 2+2, which would output 4 as the answer. Very straightforward. But to code this I took a different approach. Before jumping right into building the required functions I decided to set up a series of tests that would enssure they were returning the correct calculation.

Enter Mocha and Chai

Mmmm, mocha and chai – I love a good mocha or chai. In a cup. Of course.

These aren’t hot drinks, though; Mocha is a testing suite that runs in Node and performs a series of tests on your functions, while Chai is an assertion library – basically a tool that looks at a value and assesses whether it meets certain criteria. You can find out more about Chai here.

In your project you’ll create a folder called tests, and in that folder you’ll create a series of .js files that contain the rules for each of your tests. Ideally there will be a .js file for each module you plan on writing in your application. A typical test will:

• Describe what module it’s testing
• Describe each test in the module
• Determine what it expects the outcome of the test to be

So, something like this:

describe("My lovely module", function(){
    it("returns hello world", function(){
        var hello = module.helloworld();
        expect(hello).to.equal("Hello World!);
    });
});

So in the example above, the test is getting a value returned from a module called helloworld() and checks to see if the value it gets is “Hello World!”; if it is, the test passes. If it’s not, the test fails. That’s the essence of the Mocha/Chai combo, where Mocha handles the running of the tests and Chai gives you that nice, plain English expect(x).to.equal(y) assertion checking.

So, I started by creating my project, installing these two dependencies and setting up a simple test (I decided to call the project sum-it):

mkdir sum-it
cd sum-it
npm init
npm i --save-dev mocha chai
touch test/sum-it.js

That creates my basic, empty test file. We can run this by typing:

mocha --reporter spec

…or we can add an entry into our package.json:

"test": "mocha --reporter spec"

…which will allow us to run the test simply by typing npm run test.

If we do that now the whole thing will error because, well… the test doesn’t really do ANYTHING.

So, we need to define the tests.

I knew my sum-it module needed to have 4 basic functions – add, subtract, multiply and divide and that each of those would take in two numbers and return the result. Firstly I needed to include these modules (remember, I’ve not written them yet) and then define the tests for them. Using the basic Mocha/Chai layout, these are the resulting tests:

var expect = require('chai').expect;
var sumit = require('../app/sum-it');

describe("Sum It Calculator", function(){
    it("adds the numbers", function(){
        var answer = sumit.add(2, 2);
        expect(answer).to.equal(4);
    });
    it("subtracts the numbers", function(){
        var answer = sumit.subtract(4, 2);
        expect(answer).to.equal(2);
    });
    it("multiplies the numbers", function(){
        var answer = sumit.multiply(2, 3);
        expect(answer).to.equal(6);
    });
    it("divides the numbers", function(){
        var answer = sumit.divide(6, 2);
        expect(answer).to.equal(3);
    });
});

That basic test loads in Chai and the sum-it module, sets up four simple tests and checks to see if the functions are doing what they should.

But, those functions still don’t exist, so let’s create them.

Adding in the functionality

Let’s add in our empty module file:

touch app/sum-it.js

…and put some flesh on the bones of those functions:

exports.add = function(num1, num2) {
    return num1+num2;
}

exports.subtract = function(num1, num2){
    return num1-num2;
}

exports.divide = function(num1, num2){
    return num1/num2;
}

exports.multiply = function(num1, num2){
    return num1*num2;
}

One fun thing I learned through this exercise is the exports method you see used above. That allows us to define this file as a module, something we can include elsewhere and run the functions from. You can see it in the test above where we define var sumit = require(‘../app/sum-it’) and run the individual methods of the module with, for example, var answer = sumit.multiply(2, 3).

So, now we have our module set up, running npm run test on the command line will fire off Mocha, check all our functions and tell us if they’re behaving themselves. Cool stuff!

Bringing it all together – and taking it further

In the repo for this code on GitHub I’ve also built an app.js file that takes those command line arguments and fires off the methods as requested:

var sumit = require('./app/sum-it');
var args = process.argv.slice(2);

var type = args[0];
var num1 = parseInt(args[1]);
var num2 = parseInt(args[2]);

switch(type){
    case 'add':
        console.log(sumit.add(num1, num2));
        break;
    case 'subtract':
        console.log(sumit.subtract(num1, num2));
        break;
    case 'multiply':
        console.log(sumit.multiply(num1, num2));
        break;
    case 'divide':
        console.log(sumit.divide(num1, num2));
        break;
    default:
        console.log('Unknown type');
}

This all works great, but there’s more that could be done here – there’s an assumption that all the the arguments are as we expect them to be, but we could set up a function to check that before running the sum-it module and, by proxy, we can set up another Mocha test to make sure THAT function is behaving as it should.

Automated testing is cool – it makes you think more about the application you’re about to write, how the user is going to interact with it and how it’s going to interact with itself. It’s not something I have a huge opportunity to delve into professionally, but it’s definitely something I’m going to be introducing a lot more into my personal projects going forward.

As always, if you found any aspects of this article helpful, or if you have anything to add to what I’ve written here, please feel free to shout up in the comments!

So, what I’m going to talk about is how fun Gitmoji are! What are Gitmoji? Well, they’re basically emoji. Nothing special or new, but the idea of using them in Git commits is as an easily identifiable tag that explains what the commit is. Is it refactoring code, redoing some of the front end HTML or CSS or even something simple as updating some comments or documentation? There’s a recommended emoji for all those scenarios and you can check them at this handy cheat sheet on gitmoji.dev.

We’ve been using them in our commits at Laser Red for a few weeks now and they’ve not only helped make it clearer what we’re committing but they’ve also made me in particular think about how chunky my commits are – ideally I like to use only one or two emoji per commit so I’ve really started keeping them lean and to the point, committing little and often to the repo.

It’s something I’ve already started applying to my own github repo’s so it’ll be something you’ll start to see popping up on my own projects that I’ll be discussing here in the future.

If you don’t already tag your commits with Gitmoji, give them a try and, if you do, let me know how you find them in the comments!

Sure, I know how to code Javascript and CSS from scratchand for those bits where I can’t recall things from memory there’s always a developers first and best tool, good old Google, but relying on libraries like JQuery and chunks of copied code from StackOverflow will only get you so far. Why use Bootstraps built in modals or dropdown menus when you don’t actually know what the code you’re implementing is actually doing.

Again, JQuery would, in the past, allow me to repidly implement my own versions of such functions with ease, but as we’ve already established, it’s a big library from a time when vanilla JS would have you go round the houses to tackle a simple task. Modern JS is far more user friendly and DOM manipulations can be impemented just as easily as they can in JQuery.

As an exercise, I put together this simple example of a universal function to control show/hide elements in Modern JS:

As you can see, the results are pretty cool – with a very straightforward bit of JS and some reserved CSS classes we can control the visibility of elements on the page based on interactions with their respective triggers. This functionality extends from dropdown menus to modals and even a mobile nav menu.

For the latter, the inclusion of a class popout–static was key, implementing a popout element that wouldn’t be closed by interactions with other popouts which may be contained within it, only by its own triggers. JS making it simple to check for the existance of this class with classList.contains was the last part of that puzzle, allowing me to make my code as lean as possible.

This is a fairly basic but effective function, but it’s one that I’m already planning on expanding with some accessibility considerations for shifting focus into the popout once it’s triggered, as well as allowing active popouts to be closed using the esc key or by clicking outside of the element itself.

Obviously you can check out the code in the Pen above, but if running things locally is more your flavour, here’s an Express driven Node.JS project you can grab from GitHub.

Let me know if you find this code useful at all by dropping a comment below!

I’ve been keeping my head low since then for a number of reasons, mainly having to adjust to being at home pretty much 24/7, but also because I’ve been finding my feet in a new role away from the University of Lincoln, working for Lincolnshire based digital agency Laser Red. It’s been a bit of a change moving away from the world of research and library information systems, but I’ve been working with some great developers and have picked up some new skills along the way.

One I wanted to chat about today is a change to the way I handle asset building. Yes, yes, I know – I wrote a whole bunch of posts a couple of years back talking about how to set up Gulp to build JS and CSS for web apps – well, it’s time to chuck that in the bin and move along because Laravel Mix is now a part of my toolbox and it’s very much here to stay.

Whereas Gulp required a bunch of disparate modules to do simple tasks and could be fiddly to set up, often breaking horribly between versions, Mix is far more lightweight and easy to get up and running in minutes. Now, normally I’d go into more detail with a walkthrough at this point, but the documentation on the Mix website for getting started is so concise there’s really no point. Go give it a read.

Still want more? Here’s an upgrade to the Node.is project starter I wrote a few years back that uses Mix instead of Gulp as its asset builder. See how more streamlined it is? Using Mix opens up a bunch of opportunities for front end work including compiling specifically for production with ease, as well as implementing modern PostCSS frameworks like Tailwind.

So there we go – I guess I’m back writing blog posts and not just movie and videogame reviews (although I’ve done a fair few of those over the past year if you want to go and give them a read) – as always, spark up in the comments if you have any questions and keep your eye on here. I’m planning on doing some regular code tinkering again and will be certainly sharing my work!

Did you know that Jamstack isn’t just about static site generators or the latest hot framework?

I kind of did. I mean, it’s in the name really, isn’t it? Javascript, API’s and Markup. At it’s core that’s, well, Javascript, some kind of AJAXy thing (maybe) and some HTML/CSS combo to deliver a bunch of content to the browser. The ecosystem also includes version control, continuous integration and hosting via a CDN such as Netlify, but ultimately it’s all about those core building blocks of the internet and, in theory, you can get there however you want.

So I did.

Early last year I put up a few starter templates on GitHub to help me put projects in motion quicker and one of those was called ‘flat_default’. You can check it out here. It’s fairly rudimentary presenting a Gulp workflow that takes a folder of Pug views, a bunch of JS files and some SCSS, allows for rudimentary and hand coded templating (if you’re happy with Pug as a HTML pre-processor!) and has a build command that spits everything out into a /dist folder. That’s everything a Jamstack site needs. So, I thought today, let’s see what Netlify can do with it.

Here you go.

Remarkably painless, easy to get up and running with the simplest learning curve possible – no learning of a static site builder, no esoteric frameworks or Javascript magic to build pages. Just good, old fashioned HTML and CSS. So it’s missing things like lazy loading and content sourcing, but these are all plugin’s I’ve looked at in Gatsby any way.

Consider a “simple site”, one that’s a handful of pages, some styles, some images; no dynamic content, nothing fancy – this is where the power of the Jamstack concept comes in. With a straightforward workflow you can pull together the content for this site and host it on Netlify in a matter of minutes. Just point Netlify site at the repository, tell it what build command to run and where it can find the generaqted files.

This is some powerful, game changing stuff.

Feel free to fork the flat_default set up above and let me know if it’s of any use to you!

A days worth of research later and I was set to start building class based designs into my plugins. At first I started looking at one of my old plugins, the Custom Field Editor. That plugin basically enables a shortcode based system for building forms on the front end that can then be used to add entries to the post meta for recalling. It was a part of the EPortfolios project that I’ve mentioned a number of times on here and is really designed to be hidden behind a login. Long story short, trying to turn this into a class model led to a LOT of frustrations, mainly in how PHP classes behave (they technically have to be in one file, not split over multiple files as I normally do) and how they behaved in respect to the idea that the plugin embeds multiple shortcodes within one main one (for some reason the embedded shortcodes broke the rendering of the main one).

So I took a step back and decided to code a very simple class based plugin starter that I could use in future projects. The result is something I’m hugely pleased with, mainly because it made me realise how easy it is to build WordPress plugins in a class, but also because it allowed me to tick another to-do off my list; split out markup from my PHP functions, in this case with the implementation of a rudimentary templating engine. You can find the starter class here, so feel free to grab and use it.

What is this doing, then?

The plugin

There’s a few key things at play here so I’ll do my best to split them down:

• base.php is a “core” class file which defines some standard functions and vars that would be usable across any plugin, things like setting the root folder, magic functions and the template renderer (we’ll get onto that in a bit)
• wp-plugin-starter.php, meanwhile, is the main plugin class. This extends the base class and sets its own vars and logic. In the case of the starter it generates a basic admin screen and shortcode.
• The constructor does most of the heavy lifting with the WordPress API, grabbing settings for the admin and setting up functions that tie into WordPress specific hooks. Because we’re in scope of the class, we need to reference the callback functions as an array – array($this, ‘function_name’)
• The shortcode function itself is probably more complex than it needs to be. As I mentioned, I like to split my code down into manageable chunks, but PHP class definitions are required to be in a single file. To get around this, I put the code that sits within the function into another file and included that, keeping the variables in scope. The only gotcha here was that I couldn’t “return” from this file, something essential for WordPress shortcodes.
• Finally, after the class has been defined, the plugin file instantiates the class. This triggers all the API hooks, grabs the data from WordPress and basically makes the plugin “work”. As WordPress reinstantiates this every page load, the constructor will always be getting up to date data from any admin settings, so everything operates smoothy and as expected.

This provides a good foundation that can be expanded on to build plugins and will be the way I tackle this going forward.

The template engine

I think template engine is the right term here. It’s not something like Twig, but it was based on a very timely article from Chris Geelhood on CSS-Tricks that explored how to write a simple render_template function for PHP that takes a template name, a bundle of data and pushes something to the screen. I made a couple of modifications to this in context of the class:

• The path is made up of the plugin path and view path. At present this view path is hard coded into the base function and is relative to the plugin root (‘/views’). These values are stored in the object so that they can be easily accessed by all its methods.
• I added a bool flag so that a function can decide whether to render direct to the screen or return the output buffer to the calling function. This was, again, due to the nature of shortcodes needing to return their content to be rendered at the correct place on the page but I can see it potentially having other uses.

I’ve split this function out into a separate repository so that it can easily be included in other PHP projects and you can find it here.

Final thoughts

It’s easy to let your standards slip or at least get into habits that are entirely of your own making when you’re not part of a fully technical team, but I’m pleased that not only have I proven to myself that I can pull past knowledge to the fore, I can also add to it in a meaningful way that will make future projects a lot more manageable.

My next goal is to properly refactor the Custom Field Editor plugin – I’ve got a great idea as to how I can rework it so that it has a low reliance on shortcodes which I’m eager to put into place.

I’m also conscious that the idea of the shortcode is becoming somewhat redundant in the move to Gutenberg, so another future goal will be to look at migrating my knowledge to blocks!

As always, you know where the comments are – shout up if any of this has been useful for you!

One of the things I’m particularly pleased about is that Codepen.io allows you to fully configure your pens with your favourite pre-processors and frameworks, as well as allowing you to sideload other resources. I’ve also been using my (currently) unused Github.io site to serve images to my pens, which has been super handy.

Check out some of my work on Codepen.io here and spend some time looking at other folks pens and projects. There’s some really smart stuff on there and you should totally sign up if you’ve not already done so!