DEV Community: Mike Oram

Garbage collection - explain it like im 5 request (language agnostic)

Mike Oram — Fri, 16 Aug 2019 13:18:35 +0000

I have been looking for an article about Garbage collection for junior developers, to give a high level overview of what it is, why we need it, how it works. I have been unsuccessful in my search.

So I invite everyone to comment their best "explain-it-like-im-five" descriptions of garbage collection. Or anything more detailed for a junior dev would be great!

Introduction to Gulp 4.x

Mike Oram — Mon, 01 Jul 2019 12:18:49 +0000

There is a really great article written on CSS tricks called Gulp for beginners which covers this topic far better than I could, however, unfortunately, it is related to Gulp 3.x, which has changed not insignificantly with the later release of Gulp 4.x

At iO Academy we used to use the CSS Tricks article for reference, this article is an attempt to recreate the tutorial points from the CSS Tricks article with updated examples for Gulp 4.x. If you want an introduction to what Gulp is and why we use it, I strongly suggest the previously mentioned article.

Installing Gulp

Assuming you have Node and NPM installed, we need to start by installing Gulp into our project, to do this, run the following command from the root of your project folder

$ npm install gulp --save-dev

Note: this installs Gulp to your current project as a dev dependency, make sure you have created a new project folder and have navigated into that folder before running this command.

If you check the project folder when the command has finished executing, you should see that npm has created a node_modules folder. You should also see a gulp folder within node_modules.

Now that we have Gulp installed we can start to use it, we are going to assume the following directory structure, if you are using a different one, you may need to adjust your gulp JS to suit.

  |- app/
      |- css/
      |- index.html
      |- js/ 
      |- scss/
  |- gulpfile.js
  |- node_modules/
  |- package.json

Creating your first Gulp task

First we need to require Gulp into your gulpfile.js

var gulp = require('gulp');

We can now begin to write a gulp task with this gulp variable. The basic syntax of a gulp task is:

function taskName(cb) {
  // code for your task here
  cb();
}

exports.taskName = taskName;

Replace all occurrences of taskName in the above example for the name of the command you wish to use when running gulp, i.e gulp taskName

An example of this would look something like this.

function hello(cb) {
  console.log('hello');
  cb();
}

exports.hello = hello;

Which you can then run from the command line using gulp hello.

Sass with Gulp

Now that we have set up Gulp, we are going to use it compile our Sass. First we need to install the gulp-sass module as a dev dependency.

$ npm install gulp-sass --save-dev

As before, we then need to require this into our gulpfile.js

var gulp = require('gulp');
// Requires the gulp-sass plugin
var sass = require('gulp-sass');

We then need to create our sass task

function sassCompile(cb) {
  return gulp.src('app/scss/style.scss')
    .pipe(sass()) // Converts Sass to CSS with gulp-sass
    .pipe(gulp.dest('app/css'));
  cb();
}
exports.sass = sassCompile;

Once the task is setup, we can test that it works by creating a style.scss file inside the app/scss folder and adding some Sass to it. Below is some example code for you.

$blue: #0000ff;

body {
  background: $blue;
}

If you run gulp sass in the command line, you should see that a styles.css file was created in app/css and was compiled to css.

The above example compiles a single file into a single file, while there are different CSS architectural approaches, generally I recommend using Sass imports in a single base file such as style.css to then import all your seperate CSS files. If you are using a different pattern however you may want to compile more than a single file, you can do this using wildcard selectors, or Node globs, by replacing the src with something like the below. This will compile all .scss files inside app/scss as well as all child directories of that folder. Each scss file will become the equivilent css file.

app/scss/**/*.scss

Auto-compiling scss files

While being able to compile our scss files with a single easy command is great, it's not particularly practical, instead we want to create a watcher that will auto-compile our sass any time it detects a change.

We can do this by setting up a gulp watcher. Using a similar syntax to the gulp task, we first create a named function and call gulp.watch. This takes 2 arguments, the file pattern to watch (all .scss files in this example) and the function to run when any of those files change.

function watch() {
  gulp.watch('app/scss/**/*.scss', sassCompile);
}


exports.watch = watch; // dont forget to export your command!

Note: The files to watch are all .scss files, not just the main style.scss, otherwise it will not auto-compile when any file changes. The file in the sassCompile function should still only point at the style.scss file, so that it only compiles that file (and everything it includes) when the watcher is triggered.

You can use this watch function for any other watchers you may need, so you can start all your watchers with a single command.

$ gulp watch

There are lots of other useful things you can do with Gulp, some of the things you may want to look into are included below.

Autoprefixer - vendor-agnostic CSS
Sourcemaps - easier debugging of compiled CSS and JS

Stop expecting tools, start expecting understanding

Mike Oram — Fri, 13 Jul 2018 07:50:00 +0000

In my role at Mayden Academy, I speak to a lot of companies about their needs for new developer staff. With the current big trend towards front-end applications and JavaScript frameworks, I’m seeing that companies are increasingly making skills with specific frameworks a requirement within their job ads. I will always, always advise against that.

Here’s why.

A developer with an understanding of vanilla JavaScript – who has dabbled with a few of the most popular JavaScript libraries and frameworks – will be able to pick up new frameworks and libraries with ease.

Companies expecting years of experience with React / Angular / [insert your favourite framework here] are entirely missing the point. Would you rather hire a developer who can only write React, or someone with a real depth of understanding of JavaScript who can pick up any framework?

Unfortunately there are far too many developers in the industry today who were ‘brought up’ on a particular tool or framework, rather than understanding the fundamentals of a language before picking up its tools. As an industry we need to start encouraging training organisations to focus on vanilla languages when teaching beginners, not on shiny new tools.

At Mayden Academy we’re determined to ensure that our graduates are set up for long term careers, not for skills that will plug short term gaps in the job market for now. Sure, we teach tools and frameworks too, but we don’t touch them until our students have a solid understanding of the technologies behind them.

Hiring people who have experience in specific tools / frameworks is no a bad thing. But don’t make it a requirement for your junior level positions. If you’re making specific tools / frameworks a requirement for a junior position, I’d suggest you take a good look at the position you are trying to fill. Is it really a junior developer you need?

Invest in junior developers by recruiting people who understand vanilla technologies, and then teaching them your particular toolset. My guess is that this will vastly increase your potential hiring pool.

It’s okay to ask questions

Mike Oram — Thu, 24 May 2018 12:10:07 +0000

As somebody who trains lots of aspiring and existing developers one of the things I find myself saying over and over again in classes is that it is okay to ask questions! In my experience many new or junior developers will avoid asking their peers questions but I believe every developer in every team should feel safe, comfortable and encouraged to do so!

I believe this avoidance happens for at least one of the following reasons….

The most common reason is not wanting to be judged as less able or skilled than their colleagues – “perhaps if I ask too many questions people will suspect I don’t know what I’m doing…..” My question is; can you ever ask too many questions? I would always rather that my students ask all the questions that they need to so that they can learn and get things right faster. That way nobody needs to get frustrated spending hours fixing incorrect and ‘buggy’ code, or maybe even risking deploying bugs.

Another common reason for avoiding questions is wanting to tackle a problem alone. This is a perfectly valid reason as everyone should have an opportunity to figure it out for themselves. It’s a great way to learn and solving a challenge by yourself comes with a great sense of achievement, which no developer should be denied. However, nobody should get stuck on a problem for too long. Eventually they will become frustrated with it and lose morale and motivation. ‘Code blindness’ should also be a consideration, and it’s not just a problem for junior developers (see Byron Delpinal’s tweet).

But where is the line? How long is too long on a problem before you should stop and ask for help? In my opinion, there is no single answer to that question. Every problem is different, and therefore how long somebody takes to solve it will be different. However, as a general rule of thumb, I tell my students to give themselves 20 minutes of being completely stuck before asking for help. This doesn’t mean “spend 20 minutes on a problem before giving up”. It simply means that you should spend as long as you need on a problem while you are making progress, but as soon as you completely run out of ideas and have to start Googling questions like “how do I do this thing?” then give yourself 20 minutes of trying to find a solution….and then ask for help.

One way to tackle this is by using an agile methodology and a means of estimating tasks. At times like this, estimation points become vital. After estimating your stories and tasks everyone in the team should have a rough idea how long something should take, so keeping an eye on task length for everyone in your team will help prevent people getting stuck for too long. If you have a scrum master this can be a critical part of their role.

Ultimately however encouraging a good culture of asking questions and seeking the input and collaboration of peers is healthy and beneficial for both the company, the team and the individual. It will create better team relationships and increase productivity in the long run. Much like pair programming, it is an essential part of the development of your team and your own self improvement.

Is PHP relevant?

Mike Oram — Thu, 08 Feb 2018 10:37:24 +0000

One of the most common questions I’m asked by academees, applicants and even other developers, is, ‘why do you teach PHP?’ or, sometimes even, ‘isn’t PHP a dead language?’

Let me very clear about this from the start. PHP IS NOT DEAD.

As of December 2017, PHP makes up over 83% of server side languages used on the internet. Much of that is made up of PHP-based content management systems such as WordPress, but even if you remove pre-built CMS from the equation, PHP still makes up over 54% of the web. In fact, if you take a look at the graph below, you can see that the PHP market share was consistent throughout 2017, and has even increased.

Back in September I wrote a blog about ‘industry relevant’ skills and technologies. At the time of writing that blog, PHP and JavaScript were by far the most sought after languages in the job market. That remains the case. Not coincidentally, they’re the two languages we spend the most time on at the academy.

Let’s look at some of the usage stats around other languages, starting with the most popular ones being taught to new programmers. Universities tend to focus on Java and / or C, and as a result of this many new startups are choosing to build their applications in these languages. This means that Java now makes up about 2.5% of the web’s server side languages. With C nowhere to be seen, but ASP.NET – which is a web framework sometimes taught by universities – at 14.2%. Languages such as Python, Ruby and Server-side JavaScript are the most common focus of programming bootcamps, yet collectively these languages only cover 1.2% of the internet. Server-side JavaScript (Node.js) is currently the fastest growing server-side technology, and though still relatively small, it’s certainly one to be prepared for (and we currently dedicate a week’s learning time to Node.js in the academy curriculum).

Techrepublic recently published an article about the top languages to learn in 2018, with both PHP and JavaScript appearing in the top six, and with PHP moving from 9th to 6th in 2017.

So why do so many people claim PHP is an irrelevant or dead language?

There are two reasons as far as I can see. First, it’s sometimes a a legacy opinion passed down from developer to developer. When PHP was in its early years, it was a relatively slow language, with many inconsistencies and very little direction. The language has evolved a lot over the years however, and since PHP 5.3 was released in 2009, most of these old complaints have been fixed. The latest version (7.1) is an extremely fast, streamlined language with a strong OO focus.

Second, PHP is a very flexible, loosely typed language. This makes it very easy to pick up and start writing, but also very easy to write poorly. You could say that it’s a victim of its own success. But when written properly, following methodologies such as DRY, SOLID and MVC (all concepts we teach on the academy course), it is a very powerful, diverse and fast language with a lot to offer.

So no, PHP is not dead. While like any language, it has its flaws, the statistics really do speak for themselves.

How to stay up to date as a developer

Mike Oram — Wed, 31 Jan 2018 14:09:14 +0000

A question devs are often asked by people new to programming is how we manage to keep up with all the new technologies. Programming is one of the – if not the – fastest moving industries out there. There are so many JavaScript frameworks coming out all the time that websites like “Days Since Last JavaScript Framework” and “FapFap.js” exist just to poke fun at the situation.

With new libraries, frameworks and even languages appearing all the time, how can one ever hope to keep up, let alone start to learn them all?! I have to admit, I’m glad I started programming over ten years ago, before things started moving quite so quickly. I’m sure it seems like an impossible task these days. Don’t worry, it’s not!

The main thing that people new to the industry should understand is that although there really are new things coming out everyday, most of them are the same underneath. Libraries and frameworks follow the same general principles regardless of language. Learn those using one language, and you will find it relatively easy to pick up the others. After all, every library or framework out there has to follow the same rules as the language it’s built on. If you understand those rules, you’re well on your way. This is why, at Mayden Academy, we don’t introduce frameworks in any language to our students until they have studied at least one module including a complete project build in that language.

The next really important thing to remember is that you don’t have to keep up with everything all the time. All programmers know and appreciate the struggle of having too many new things to learn all the time. Most developers choose a few technologies and languages that interest them and focus on just keeping up to date with those. That alone is not enough though. And here’s the important part: we share that information with each other.

Programmers are truly exemplary in the way that they freely share information with each other. I have never experienced a community that is not just willing, but which actively tries to share knowledge the way the development community does. Research conducted by TechNation in 2016 showed that over 5,000 people regularly attend meet-ups in the Bath and Bristol area. If meetups are not your thing, companies like Mayden, Edo and Seccl (our hiring partners) run all sorts of internal events to help their developers stay up to date, from hack-days to developer lunches to Monday morning code wars. Employers are increasingly recognising that they need to dedicate some of their developers’ time to training
and keeping up to date.

I recognise that most people who read this blog aren’t yet working as developers though. So where do you start? Below I’ve listed a collection of blogs, meetups and chat channels that I strongly recommend you spend some time on. No doubt they’ll help you as they do me.

Chats:
http://bathjs.club/

Meetups:
http://www.meetup.com/BathCamp/
https://www.meetup.com/php-sw/
https://www.meetup.com/Bristol-PHP-Training/
https://www.meetup.com/bristech/

Women’s meetups:
https://www.meetup.com/Womens-Tech-Hub-Bristol/
http://www.itgirls.com/

Blogs:
https://maydenacademy.co.uk/blog/ (obviously)
https://davidwalsh.name/
https://blog.codinghorror.com/
https://akrabat.com/
https://www.smashingmagazine.com/

Is ZCE really worth it?

Mike Oram — Tue, 16 Jan 2018 14:46:00 +0000

A few months ago, I posted a blog about what ZCE is, as a follow up to a talk about becoming a Zend Certified Engineer. Since then, people have been in touch asking why you would take the ZCE exam and whether it’s worthwhile. Because, after all, it is a real challenge. So I thought I would share my thoughts here.

Personally, I took my ZCE exam for that exact reason: the personal challenge. I wanted to prove to myself that I could. It’s not an easy test, and it covers a lot of ground including a fair few abstract, lesser known parts of PHP. I’ve been writing PHP for over ten years, but there were still parts of the language I had never worked with. ZCE gave me the opportunity – and the excuse – to explore those.

The ZCE qualification is a rubber stamp. It shows that you are someone who can not only code their specific flavour of PHP, but who also has a broader understanding of how the language works.

At the time of writing this article there are 997 Zend Certified Engineers in the UK. No one is saying that those 997 developers are the best PHP developers in the UK – there are certainly many fantastic PHP developers out there without the ZCE certification. But how do you measure skills in PHP? A certification like ZCE enables you to differentiate yourself as a developer – and goes a long way toward proving that you know your stuff.

The general advice provided by Zend is that you should have between 2 and 3 years of professional PHP development experience before taking the ZCE exam. While that amount of time means you’re likely to have experienced a large amount of the content in the real world, I do believe you can do it sooner. I’ll be the first to say that experience trumps qualifications, but when starting out as a developer, you need as much evidence on your side as possible. A portfolio is one of the best ways of doing this – that’s why the students at Mayden Academy build a portfolio during the course – and industry recognised qualifications – like ZCE – are another.

A ZCE qualification also proves to employers that you’re committed to growing your skillset. It requires serious dedication, and it isn’t essential. Having ZCE under your belt is evidence of your motivation and of the attitude you take to your work.

So, is ZCE worth doing? In summary, yes – I believe so. If you are a fairly new developer, being able to say you have taken the ZCE already differentiates you from the crowd. It shows employers that you are serious about your career and about your personal development, and that you have both practical and theoretical knowledge. And who doesn’t love having extra letters after their name?!

Next time a job is between you and a similarly experienced developer, ZCE could tip the balance in your favour.

Good Code Reviews

Mike Oram — Thu, 04 Jan 2018 15:17:48 +0000

Code reviews are one of the most useful parts of the development lifecycle. There are many different approaches to code reviews, and figuring out best practice for yourself and your company can be hard. You have to do what works for your scenario, but there are certain things that all of us should be doing as part of code review.

In a code review, a developer passes a finished piece of code - be that a new feature, bug fix, or change to an existing feature - to another developer to be reviewed, before it is considered ‘done’. This process has many benefits for both the developer and the company.

The main reason to perform code review is to ensure that code quality is maintained. There is never a single solution to any problem, and by having at least two developers review any piece of code, we are more likely to create the optimal solution. Having a second set of eyes will often reveal things that the original developer did not think of, but also prevents laziness and stops developers taking shortcuts in the code in order to complete a job more quickly. Bad code will cost you down the line.

Code reviews also add a QA test layer to the development process. Every developer should test the code they write, both manually and with automated tests, it is easy to miss use-cases when you are the one writing the functionality. Getting lost in what the code should do, rather than what it should not. Having another developer both read through your code and test it (manually and by running automated tests) will help confirm that mistakes were not made and that the code is . Unfortunately, manual testing is often skipped during code review, and because of its people often assume that code review means simply reading through the code. While this is useful, it does not provide a complete picture of what is happening.

The pull request feature provides the perfect interface for delivering a code review, allowing you to comment on individual lines of code, or on the entire change. Once a reviewer has completed their code review, they can then approve the pull request, request changes or just comment without either approving or rejecting.

Due to the nature of the code review process, only constructive feedback is given. While there is no reason not to provide positive feedback, there is no benefit to the code in doing so, so it is usually seen as a waste of time. Positive feedback is no feedback. As a result of this, it is not uncommon when implementing a new code review process for developers to feel disheartened or victimised by their code reviewer. To prevent this, when implementing a code review process (or hiring a new developer), all developers should be made aware of the expectation of the process. While this is not a complete solution, after you have been through the review process a few times, it becomes normal. The aim is to foster an environment where developers strive to get their code through code review without any comments at all.

When implementing the code review process, it is a good idea to start out with a checklist of things to look out for. This ensures that all your developers are performing the same checks. While it should not be necessary to check code formatting and coding standards, provided your developers are using correctly configured linting tools, it is often the first item on a code review checklist. Other items may include: manually testing functionality, automated tests passing, automated tests covering all use and error cases, no known security vulnerabilities, no obvious poor performing or unnecessary code, testing. You will need to design a checklist that works for your team and your company's requirements. Once your team has become used to delivering consistent code reviews, you will be able to phase out the checklist, although to ensure consistency, it can be a good idea to continue to use it for new developers joining your team.