I am joining Unity Technologies!

Me at IBM

After over 1 year University placement and almost 10 years employed at IBM, I have taken the difficult decision to leave behind the Big Blue and join Unity Technologies working in the Multiplay division!

At Multiplay, the worlds leading platform for video game servers, I’ll be working on a modern front-end for a world-class hybrid cloud platform in a very exciting industry that I’ve been wanting to always be a part of: video gaming. This company is the perfect blend of gaming and enterprise, which is exactly where my skillset lies.

Apex Legends

Multiplay are amazing at what they do. They were crucial to the launch of Apex Legends. I am extremely excited to join such a high performing company.

I will be sad to leave behind everyone at IBM, but I’ve gained a huge amount of valuable skills, both in technology and in personal, and in fact it’s because they’ve equipped me with all I need am I even able to make this leap.

So here is to the end of an era, and the start of something exciting.

Written on July 6, 2019

My simple HoC rename component

I’m currently working on a front-end project that uses both React JS and Angular JS. Yes, that sounds a bit crazy but the project is evolving from Angular to React, and this is the difficult transition phase.

We are using $ngRedux to manage our Redux application state, which presented an issue to me today when I created a new React component in this AngularJS dominated codebase.

react2angular

We use react2angular (full disclosure, I am a contributor) to embed React components in AngularJS. One of the interesting parts about this is dealing with Angular’s dependency injections. $ngRedux is served to components as a dependency and injected at runtime. We can access it with react2angular like so:

import angular from 'angular';
import { react2angular } from 'react2angular';
import MyReactComponent from './MyReactComponent';

export const MyReactComponentModule = angular
  .module('my-project.components.myReactComponent', [])
  .component('myReactComponent', react2angular(MyReactComponent, [], ['$translate', '$ngRedux']))
  .name;

We can discuss $translate another day.

So my React component uses Redux, and thus I use the very useful connect() function to transform some useful stuff from the store to my component, like actions and props.

export default connect(mapStateToProps, mapDispatchToProps)(MyReactComponent);

The problem

Here’s what happened with my code above:

Invariant Violation: Could not find "store" in either the context or props of "Connect(MyReactComponent)". Either wrap the root component in a <Provider>, or explicitly pass "store" as a prop to "Connect(MyReactComponent)".

ugh.

connect() expects a prop called store in the component. This prop is the redux store which provides the data and the dispatcher to the component. However, we’re using $ngRedux via dependency injection.

I searched around the redux codebase, issues, and docs to see if I can change the expected prop name. I was unsuccessful. It doesn’t mean it’s not possible, it’s probably my lack of ability to find it (which you could argue means a lack of concise documentation).

So here’s how I solved it, with a very heavy-handed higher-order component:

// This HOC simply renames $ngRedux to store (because this is used with react2angular)
const mapNgReduxToStore = WrappedComponent => {
  const MappedComponent = ({ $ngRedux, ...rest }) => {
    return (<WrappedComponent {...rest} store={$ngRedux} />);
  };
  MappedComponent.displayName = `WithStore(${WrappedComponent.displayName})`;
  MappedComponent.propTypes = {
    $ngRedux : PropTypes.object,
  };
  return MappedComponent;
};

export default lodash.flowRight(
  mapNgReduxToStore,
  connect(mapStateToProps, mapDispatchToProps)
)(MyReactComponent);

(If you’re new to compose/flowRight, it’s just a simple way to layer HoCs for a component).

There we have it! It feels heavy handed, and perhaps I should try and raise an issue with react-redux to allow a prop name change. But this gets the job done and I hope it serves someone well.

Written on March 26, 2019

Static IBM Cloud Application

For my mum’s business, I run the website simplyfleece.co.uk. It has been through various incarnations but right now, it’s a simple website which I wrote in pure HTML and CSS (shocking!). Originally, when deploying to IBM Cloud, I was using Node JS and Express to serve the HTML. But this is overkill, especially when using Cloud Foundry.

Introducing the Static buildpack

IBM Cloud still allows users to deploy cloud applications with CloudFoundry, which I use for all of my applications. Normally I would use the NodeJS buildpack, but for simple HTML and CSS, I only need the Static Buildpack which allows simple HTML files to be served with very little config!

Simply create your website, and then create a Staticfile file, and push to IBM Cloud, and it’s ready to go!

index.html
styles.css
StaticFile
ibmcloud app push -k 64M -m 64M my-app

And that’s it! The static buildpack uses NGINX to serve the files, and if you need additional options, they go in the Staticfile and the options can be found here. For example, my SimplyFleece site has the following options for setting the file structure, and forcing HTTPS:

root: public
force_https: true
Written on August 1, 2018

GraphQL 101

Me talking about GraphQL

Today in IBM Hursley I gave a quick introduction to GraphQL. We are using GraphQL in my current project at IBM Watson, with good success. While we as a team are still learning how to best use it, I can at least attest for its benefits compared to REST.

REST is not without issues, baked into its design. By describing only how to seek and modify data, servers and clients can be tightly coupled, which means it can be difficult to apply change to the API without causing a lot of work to update the client.

Another issue with REST is predicting what a client will request. Designing an API usually means designing how the client will need and utilise the data. If the client strays off the beaten path, it can result in underfetching an overfetching, meaning requiring additional API calls for more data, and discarding useless fields in payloads.

GraphQL aims to beat these issues, and more. By describing your data structures in a strongly typed schema, you define, and implement with resolvers, only the data itself. This means you aren’t enforcing a way of fetching data on your client, only providing whatever the client asks for.

The client then queries the graph of data, fetching all and only what it needs, saving time and bandwidth, in a single payload.

For more information, I recommend the GraphQL website and How to GraphQL.

Alternatively, read my slides that follow.

Written on July 12, 2018

New Blog!

I’ve created a whole new blog on my Github Pages site! Here it is!

Written on July 10, 2018