Mafia Online Update, Version 2 Development Begins

Hey everyone

So I thought in today’s blog post I would cover the progress of the Mafia Online project, and why I have made the decision to start again with a rebuild.

Firstly, the reason for posting this on my own blog, rather than the Mafia Online news section; a few different times I tried to set up a blog to start posting up the news and features, and the problem is I ended up spending time trying to put that site together just right, rather than trying to actually get the development done.

So, to answer some basic questions about the rebuild;

How did the original game go?

Actually, really well. For something which was never truly intended to go live, it was really well received!

What is changing so drastically that it requires a rebuild?

I should start this with how and why the original build started, it was a side project, something I could use as a playground for some new techniques I wanted to try out, without having the worries of corporate and enterprise development.

However, I showed the game to some friends, and they really like the game. Soon there was a Beta version and a few months later I decided to put the game live. I soon found that there were some real improvements to be made.

Fundamental Changes

The reason for a rebuild, is that there are some fundamental changes to the game, such as;

  1. No death/dying
  2. No timers, energy point system instead
  3. Because of point 1, we can’t do property ownership in the same way
  4.  Stronger location structure
  5. Brand new frontend, which is far more immersive and running in real time
  6. Due to all of the above, whilst there will be paid options, there will be far less, if any, emphasis on bonds. Particularly as they lose a lot of their value without timers existing, and without death there’s no requirement for a currency which can stay with you
  7. App ready, I’m building this version of the game to be ready to be deployed into an App for iOS and Android, when the time is right

Because these changes are so fundamental to the way that the game is structured, it wouldn’t be appropriate to develop this against the existing application.

Can we have a sneak peak of the features?

Absolutely. I will post videos/screenshots of the game, as they’re available, and highlight the new features. There are going to be “less” features, in terms of activities, than on the current game. However, the features will be more interactive, and being that they’re based on an energy point system, one won’t need so many features to continue playing.

Can I be a Beta tester?

If you are an existing player of the original game, then sure, I will be posting information on Play Mafia Online about recruiting Beta testers soon.

Guide for New Developers

Hi guys

I wanted to put in a post here, because I have been working extensively with people who really want to break into web development, from those not yet doing it professionally, to those looking to grow from Junior Developer, and those who I am (in my spare time) mentoring. I find myself giving similar advice quite frequently, so I wanted to summarise here;

It takes time, patience, and passion

I know when I started my career at a trainee, and even before that, I had to put in my own time. What my first job gave me was exposure to a real-life team of developers, who gave me some great advice; some of which I still lean on today.

Your job may entail HTML, or you may be doing spreadsheets as I was, or you may be doing testing; but if you’re surrounded by developers who have lots of real world opportunity to learn. Take advantage of those developers, good developers love sharing their knowledge.

Don’t get distracted by shiny new tech, nail the basics

I read lots of CVs sent to me when I am recruiting for new roles. The worst thing you can possibly do is list lots of awesome new stuff on your CV, when you’ve yet to nail the basics.

The reason for this is quite simple; if (as the ops guy) I can’t trust the quality of your code on basic jobs, you’re never going to get the opportunity to demonstrate your new tech.

If you say you know it, either honestly say you’ve got “some exposure” to it, or a sentiment to that effect, or know it to the level where you’re comfortable demonstrating your knowledge in a competency test.

Learn from reputable sources

Any developer will laugh at this, but if you’re new to the industry you might not know; pay no attention to W3 Schools (or W3Fools as it’s often, less than affectionately, referred)

Depending on what you’re learning Codecademy is a good bet, as are Laracasts and Vue School – if you have someone to whom you look up, who is guiding you on your journey, give them a shout and see if they’ve heard of the site.

On the same token, be wary of Stack Overflow, Reddit, and other community sites. Firstly they can be absolute flamefests, especially for new developers. Secondly, you don’t necessarily know the experience and background those developers had, and even if it sounds impressive, it can be deceptive.

Understand the importance of commercial experience

This sounds really harsh, but I don’t mean it to. You may well have built something amazing in your spare time, but unless it’s reached commercial success and has been run as a commercial development projects; the experience isn’t necessarily that relevant.

Commercial development is far more than writing code. It’s writing it, maintaining it, ensuring it’s stable, robust test processes, client/stakeholder requirements, technical constraints, commercial and time constraints; and so much more.

Don’t be offended if someone discards most of your “spare time” experience.

Everything is a learning opportunity

Failed a technical test? Great! That’s better than passing it when you were sub-par, make notes in the test of what you didn’t get right, make sure you know it next time. Often it will open up a new avenue of knowledge you’ve yet to gain, and that’s a good thing.

Learn raw first

Before you try and learn Vue or React, learn JavaScript. Before you use a plugin, make sure you can code it yourself. Before you learn Laravel, understand PHP and OOP. Otherwise you don’t really know how to achieve the things you’re trying to, you’re just getting someone else to do it. That’s fine, until you can’t use your favourite plugin for some reason, or until it breaks and you don’t understand, at a fundamental level, why.

Finally, don’t give up

Learning tech comes with a cycle “this looks amazing!” – “I nailed it!” – “oh, wait a minute, maybe not…” – “What is wrong with this thing?!” – and if you persevere “this is so much more awesome than I realised!”

So don’t give up on your career or learning tech. Keep going, and know when to ask for help. Nothing worth learning is easy, progress does not come for free, and you’re building a career. So take a breather, get away from your screen.

Caveat: Burnout is bad!

Burnout is a real thing, and is bad. If you’re finding yourself getting stuck and frustrated avoid staring at your screen for hours. Go and do something, anything else. Swim, gym, walk, sleep, listen to music, get away from your screen.

Also, do make sure you leave some time at least every week to do something “just because”. Don’t obsess over the code, it’s not going anywhere, burnout will reduce your cognitive ability, and will make it harder for you to solve the problems you’re having.

Bringing OOP functionality into WordPress

So if, like me, you’re an object orientated programmer and are suddenly asked to build functionality into WordPress it can feel like you’re trapped into procedural code and functions. Consequently; I thought I would whip up a little tutorial of how to work within WordPress, whilst maintaining your OOP integrity. The reason this is important is quite simple, if you’re building complex functionality into WordPress, you want to be able to use OOP principles and methodologies.

Don’t worry or get confused, themes vs plugins

Essentially, these are the same thing! They use the same library of code, the APIs you can use within WordPress are the same. You could be asked to implement the code in either, and you’ll do it the same way. The real difference is whether you want the functionality to be exposed if the website changes theme, if that’s the case you’ll move the code into a WordPress.

PSR-4 Autoloading

The first thing you’ll want to do is get some PSR-4 autoloading running so that you can use your classes without having a huge set of require, require_once or include statements which can be a nightmare to maintain. If you’re working in a theme put this code into your functions.php – if you’re in a plugin then I would advise you do this in the registration file which might be wp-contents/plugins/yourplugin.php or it might be wp-contents/plugins/yourplugin/functions.php. If in doubt, look for the declaration of the plugin – which will be a PHP code comment as seen here.

I will use JohnoTheCoder as my vendor name and PluginTutorial as the project namespace. The file we’re putting this code into is called whenever WordPress is loaded (because the theme is initialised, as are the plugins) – so you’ll want something like this

/*
    Declare the autoloading - you can repeat this for all your different namespaces if you wish, for example if you're bringing in code from other repositories
*/
spl_autoload_register(function ($class) {

    // The classes I want to autoload are within the JohnoTheCoder\PluginTutorial namespace
    $prefix = 'JohnoTheCoder\\PluginTutorial\\';

    // The class being loaded is not within my namesapce, return early
    if (strncmp($prefix, $class, strlen($prefix)) !== 0) {
        return;
    }

    // All we're doing here is saying that your namespace classes are found within the src subdirectory
    $file = __DIR__ . '/src/' . str_replace('\\', '/', str_replace($prefix, "", $class) . '.php';

    // If the file does not exist - throw an exception with a helpful message
    if (!file_exists($file)) {
        Throw new Exception("Class [$class] not found in expected location [$file]");
    }

    // The file does exist, so require the file
    require_once($file);

});

What this means now is that you can reference JohnoTheCoder\PluginTutorial classes, and they will be looked for within your plugin, for example JohnoTheCoder\PluginTutorial\Subspace\MyClass would be found in plugin-directory/src/Subspace/MyClass.php – of course you can modify this to follow the naming conventions you have in place.

That’s it for this short tutorial – I’ll do some more “OOP in WP” tutorials in the future, to enhance maintainability and help encourage true OOP development within WordPress plugins and themes.

6 tools I couldn’t live without

Hi everyone

So today I thought I would do a quick post, as it has now been just over a year since I started as the Senior Systems Architect at Speed Agency. We’ve had an amazing year, seeing the design, development, and delivery of a number of bespoke systems, including our own modular content management system. Of course, to achieve all this we use a whole bunch of tools. Here I thought I would summarise my favourite;

#1 Digital Ocean

Now, I know there are competitors out there, however I haven’t used them. The reasons I love Digital Ocean can be summarised here:

  • We run a very strict set of processes with regards to the deployment of changes to our live environment. The snapshot functionality means I can have a single (or multiple) staging environments built in next to no time
  • Their customer service is absolutely top
  • Their availability is high, and their prices very reasonable
  • The server monitoring is really pretty damn good, especially as it’s essentially a free extra
  • And all the usual stuff to do with Volumes, Floating IPs, etc.

More information about Digital Ocean

#2 Status Cake

I’ve used a number of different suites to monitor uptime, I’ve never found one which is better for configuration, server and website monitoring (amongst other things). Also, very very few false negatives – which are a nightmare to manage if you’re handling SLAs on uptime!

Track your uptime and server statuses with Status Cake

#3 Packagist

I’ve done a blog article on Packagist before, however I have to say I love it. The power of managing modular code and dependencies through Composer, added with the closed-source nature of private packagist is just great.

Find out about Packagist

#4 GitLab

We started using GitLab for managing issues and our Git repositories. I’ve got to say, whilst it might start to fall down against its Goliath-size counterparts (such as Atalassian’s BitBucket + Jira haymaker of a combo), it has lasted us very well, it’s a great system to have, it’s open source, easy to use (particularly if you’re familiar with GitHub) and has been a great toe-in-the-water for this style of project management.

Learn more about GitLab

#5 Confluence

I’m a true nerd for documentation. I love it. I mean I love it more than I love flow charts, which is really saying something. Confluence is phenomenal. For managing, exporting, modifying, discussing, sharing, and structuring your documentation this is the absolute bee’s knees. Seriously, if you need to document your source code, project paperwork, or anything in the software development arena, sign up for it, right now, don’t even hesitate.

I don’t know why you don’t already have Confluence

#6 draw.io

There is a standing joke in my office, in which I am referred to as Sheldon (though my computational personality tends to find me also referred to as Laurie Bream) – this is because of my absolute adoration for flow charts. From processes to systems designs to user-workflows I absolutely swear my draw.io, which allows you to draw these diagrams, export them as XML files for later, and export as a number of useful formats (PDF, for example).

Get your workflow on with draw.io

In Summary

Tools and software should make your life easier. The above 6 things have made my life infinitely easier, and helped me structure, grow, and enhance my team’s capacity and capability by providing smoother, more efficient processes and workflows. I can’t take all the credit, of course, all those tools were at some point referred to me by a colleague, friend, Search Engine, or somewhere; and none of them would have any effect if my team didn’t take the whole hearted approach to adopting the things that I have mentioned above. Every team has a critical mass which makes systems effective, and my team are the best at adapting to our ever changing requirements.

I’d love to hear what tools you have which make your job easier, I can’t promise I won’t think “oh, that’s a good idea!” and consequently adopt the tool myself 🙂

Until next time,
Johno

Edit: Considering this is essentially 6 links I thought I’d best state – there’s no commercial interest in this post, I’m in no way endorsed by those companies, have no affiliation, no referrer links or anything included!

Understanding and Utilising the Expertise in your Project

So this is a topic I thought I would touch on, having worked in lots of environments, on lots of projects, with varying different sets of priorities; I have noticed a few different things; with some very common characteristics across almost all development teams.

The first is that there is a two fold problem when it comes to expertise:

  1. Expertise is never a clear cut, black and white line, every professional, in every role, has a varied set of skills
  2. The second is often the expertise people hold is often overshadowed by personalities on projects

The downside to the second point is that one can end up being entirely neglected as an asset to their project simply because their personality is not overt or extrovert; their voice not strong enough, of their opinions not heard. This can only ever be detrimental to the project, because those skills and expertise are there for a reason.

Project Archetypes

As I say, all projects are different; however, let’s assume a large website build, with complex functionality and integrated partners. I’m making this assumption for the purposes of the most complex project and set of people and expertise possible.

So, let’s look at our archetypes – I’ve given them all abbreviations to try and make this mammoth article slightly shorter.

Please do not be offended by any of the below, these are fictional characters on a fictional project to illustrate a real world point.

The Client (TC)

  • Role: The role of the client is, on behalf of their business, to get the best possible product that fits the requirements, needs, considerations, and budget for that project
  • Strengths & Skills: Nobody knows the inner workings of the business or industry like the client
  • Weaknesses: Will not always understand the implications of their requirements or changes

The Project Manager (PM)

  • Role: To bring the whole project together, encourage collaboration, and efficiency
  • Strengths & Skills: Overall knowledge of the project, from conception to delivery and beyond
  • Weaknesses: Jack of all trades, master of none; often won’t understand the low level detail of the technical elements of a project

The Critical Third Party (CTP)

  • Role: To provide the TC a third party (this could be anything from accounting software to CRM integration)
  • Strengths & Skills: Integrating their software with development teams, understanding their product, offering, and how it adds value to TC
  • Weaknesses: Usually relatively inflexible in terms of integration and capability

The Technical Lead (TL)

  • Role: Ensure the competent and efficient technical delivery of the project (technical development, testing, and delivery)
  • Strengths & Skills: Technical information, planning, and development; and understanding of the easiest route to delivery from a technical standpoint
  • Weaknesses: Sometimes seemingly inflexible, not always empathetic

The Lead Designer (LD)

  • Role: Ensure the deliverable is aesthetically pleasing, on brand, and agreeable by TC
  • Strengths & Skills: Design, brand, understanding and communicating TC’s voice by multimedia means
  • Weaknesses: Where displaying output of integrated data, doesn’t always understand technical implications of design decisions

The UX Expert (UX)

  • Role: Optimise user experience of those using the project, usually with the aim of increasing conversions, a champion of the end user(s) and customer
  • Strengths & Skills: Understanding the impacts on the user of decisions made elsewhere in the project
  • Weaknesses: Can become frustrated at the undervalue UX often receives (and is often brought in late to the project)

The Data and CRM Expert (CRM)

  • Role: Capture as much data as possible for usage by Marketing
  • Strengths & Skills: Understands every single data capturing opportunity
  • Weaknesses: Wants to capture data at every single opportunity, often to the detriment of design and UX

The SEO Consultant (SC)

  • Role: Understand the impact of all technical changes to SEO, advise on SEO strategy
  • Strengths & Skills: Search Engine Optimisation, getting traffic to the website
  • Weaknesses: Very specific skill set, often without wider technical understanding

Collaboration without restriction

As you will have noticed from the above, there are a lot of seemingly key players in this project. Consequently, I have drawn up a couple of pointers which I feel may ease the collaborative process on a project of such scale.

Understand the goals

The project should have a single, clear cut goal. Let’s say it is an ecommerce website complete rebuild and redesign it will likely be something like “increase sales by 25%”, the rebuild having been necessitated by slow page load times due to an outdated database structure, for example.

Now everybody detailed above is going to have their own set of goals. SC will want completely SEO optimised pages, and content population. UX will want a quick route from product to checkout. CRM will want to capture as much data as physically possible. LD will want the design to be beautiful, on brand, and pride of place in his portfolio. TL will want easily changeable code, efficiency and security in their code and servers.

The trick in this stage, is to understand what everyone (not just PM and TC) want out of this project. That way we can predict bumps in the road, and we can work around them before anybody has put pen to paper, code to IDE, or design to Illustrator.

Understand the dependencies

Now we understand what everybody wants and needs, we can see what dependencies there are. Likely dependencies are front end development being blocked until design is signed off. TL is likely to block integrations and development until specifications are signed, but TL is likely to be blocked on a database front by CRM until they have decided exactly what data they want to capture.

In my experience most of this will be blocked, in the first instance, by TC and PM who will need to agree and outline finalised scopes and specifications; once these are signed off the first few parties can get started in their tasks.

Understand the phases

Now we know who is involved, what they want and need, who is blocked and what order things need to be done in. Now we need to draw a plan, the phases, and who will be involved in those phases. There is no sense in a free-for-all as work will need to be redone, and there is no sense in having every party in every meeting. The popular opinion here is that it keeps the project together, working in the right direction. My professional opinion here is that, unless broken down into phases, this is a wasteful usage of time. LD doesn’t need to be in a meeting where the sole concerns are CRM, UX, and TL are discussing how and when to capture data. PM and TC should be actively involved in every phase, however, to ensure consistency across the project.

Stick to the plan

Now we have a plan, most likely with phases, timescales, and tasks down to a granular level. This has been drawn up lovingly and attentively by PM, in conjunction with all parties. On paper it will work. It is now the job of everybody to understand it, they understand the implications of the work they’re doing; so now it’s a case of move forward and don’t look back. That’s what post-go-live is for.

Understand Perfection is a Myth

Perfection is a myth. In digital it’s just not something which is possible. Browsers and devices constantly evolve. As do user journeys and user expectations. If you aim for perfection and refuse to settle for less you will never go live.

Let’s say phase 1 was to understand data capabilities, that’s been and gone. Everything has been discussed, agreed on, and is either in progress or is complete. Don’t revisit those decisions, stick with them. The consequence is we go off plan, which will cause confusion, inefficiency and definite delay; though the cost of that delay will never be crystal clear, as we’re now off plan, and away from estimations.

How you can help the large scale projects you’re on, by following these 5 simple steps

So, from working on lots of projects, here are my top tips for working in big projects.

Step 1 – Voice Your Concerns, Reasonably

There’s always a workflow or a process to follow, if you have concerns, especially those outside of your core skills and expertise; voice them. However, be careful to voice them reasonably. Don’t be deterred if you don’t get the answer you want, but also don’t be unreasonable with your fellow collaborators; their skills are not your skills. Their understanding and expertise is not the same as yours, sometimes, you will have to be told “no”.

Step 2 – Communicate for Value

This point follows upon from something I touched upon in “Understand Perfection is a Myth” above. If you are not adding value, or are not going to add value, you shouldn’t be in the meeting. If you have nothing to say, say nothing.

This does a couple of things, in practice. Firstly it cleans the lines of communications, everybody is only speaking when they have something valuable to contribute. Secondly, it makes it more likely that you’ll be listened to when you do speak, because your track record will be of only speaking when you have a strong and/or valid point.

Step 3 – Understand the People, and the Scope of their Expertise

This is a controversial one, mostly because it assumes people know what their own expertise is. Also because it means each of us as individuals acknowledging what we don’t know. SC may know one or two bits about User Experience design, but nowhere near as much as UX does, therefore it’s not really within SC’s scope to enforce decisions upon UX. Similarly TL knows nothing of brand, so beyond technical consultation should not be enforcing their views on LD during the design phase.

Your expertise is the reason you were brought into the project. If you were brought into the project as the Technical Lead, you should only insist on enforcing your viewpoint on Technical matters, unless explicitly asked otherwise.

Now I understand that this is starting to sound very much “stay in your box”, which is absolutely not the point I am making. The point I am making is when you stop valuing the experts, they lose initiative on their own ground. What that means, for your project, is that maybe TL stops making recommendations about how to keep the page speed down, because SC has made their recommendations which have been listened to over TL (and page speed is TL’s expertise).

It means LD starts doing as he’s told because TC and PM have decided that they’d rather pixel-push the design, than let LD use his area of expertise.

From what I’ve seen, letting people overrule the experts, you end up with a bunch of people capable of making changes, whilst 1 or 2 extroverted figures dictate everything. I’m open to be correct on this, but I’ve never seen it go well.

Step 4 – Empathise & Sympathise, understand Pressure Behaviour

This is the difficult one. Everyone gets a say on everything. Now everyone has to redo all of their work. All the while PM and TC are getting very excitable about how late their project is going to be, or perhaps TC is insisting upon the deadline, which PM knows isn’t necessarily possible.

Now everybody is stressed, everybody is under pressure, and everybody’s behaviours will change. It becomes “every man for himself”, this leads to some really negative behaviours in terms of what’s best for the project.

The first, is inflexibility. “Why should I do that? I’ve done my bit!”. The second, is irritability. “Why are they changing it again? I’m tired of this now!”. The third, is disrespect “Why is UX telling me about my database design, why doesn’t he stick to wireframes!”.

None of these behaviours are important. The bit that is important is that none of them are helpful for creating the best project for TC and PM.

By the time you’ve gotten to this point, it’s too late. Unless there is essentially a blank slate to work from, starting over from the first phase again, the project is doomed to be “just good enough” to get it past PM and TC and go live. Future collaborations (v2.1) will forever be tainted by this project, relationships will be ruined beyond repair. Nobody wins.

How to say “no”

This section is really founded on the principle of understanding the expertise, and respecting it. Sometimes, you do have to say no.

Approach one – “I appreciate your opinion, but I must say from a [insert skill] standpoint, it is not the best way to proceed, because of [reason]”

This approach is asserting that you value the input of other members of the team, but this is within your skillset, and it is a bad idea, which must be justified. If you can’t justify your reasoning, are you being inflexible because you don’t like the idea of someone else contributing?

Approach two – “That’s not viable given the limitation”

This is a great idea! I love it! (Or perhaps, this is a terrible idea, but it’s not viable either way). However, we have to have this done in a week, or the budget is £Xk too small. Value the input you’ve received, but not everything we want to do, is possible. That’s the basis for this particular approach.

Approach three – “That’s not in scope right now”

This is a bit of an extension on the second approach, really. This is very neutral, it’s not a good or a bad idea (unless you want to specify) but the project relies on clearly defined scope, specification, timelines, and such. Adding new things in will always impact deliverables.

This is not the worst thing for TC or PM, it’s the best thing for your current project – which is the one you must concentrate on. Rome wasn’t built in a day, if Social Media Login is a new piece of scope, it’s a great idea, but it has to wait until the completion of this project.

Celebrating the successes

It is so important, when working on a large collaboration like this, that successes are celebrated; and that personal recognition given to the parties responsible. LD had as much to do with database design as TL had with the stunning new logo alterations.

TC and PM can always take a slice of the credit, but if they’re seen to soak up all the glory, it will never be very good for the wider team. Collaboration is about accepting and appreciating the diversity that everyone brings to the table.

This vitally includes celebrating even the small successes, and attributing that credit to where it belongs. Saying “we need a logo” and then taking credit for the new design is akin to having a photo taken with Anthony Joshua, and saying that makes you the second best boxer in the world.

Continuous Collaboration

You now have a successful project under your belts, but it’s digital; it will need revisiting. You have positive foundations to lay your new project on now. There will be a sweeter taste in the mouthes of everyone who has worked on a successful project, with respected and appreciated professionals, where collaboration was free flowing, and so was respect and consideration.