Author Archives: Gary

Standard

Posted by

Posted on

December 5, 2022

Posted under

Uncategorized

Comments

Leave a comment

Installing PhpStorm on WSL2 Ubuntu

Mega quick notes on how I finally managed to install PhpStorm on Windows 11 WSL2 Ubuntu VM so that it starts in the XLaunch window server.

I have no idea what I’m doing so the terminology is probably completely wrong.

Let me know if this helps you on Twitter @GeeH

In Windows 11, install VCXSRV from https://nav.dl.sourceforge.net/project/vcxsrv/ – I have no idea if this is needed or not but I’d already done it 🤷.

Enable systemd (from https://devblogs.microsoft.com/commandline/systemd-support-is-now-available-in-wsl/)

Create a file at /etc/wsl.conf containing:

[boot]
systemd=true

Start snap at startup:

sudo systemctl unmask snapd.service
sudo systemctl enable snapd.service
sudo systemctl start snapd.service

Install PhpStorm using Snap

sudo snap install phpstorm --classic

Install Java

sudo apt install default-jre

Start PHP storm with phpstorm

BONUS STUFF

Installing Docker

https://docs.docker.com/engine/install/ubuntu/

Setting up Docker so it can be used by logged in user

https://docs.docker.com/engine/install/linux-postinstall/

Standard

Posted by

Posted on

September 9, 2019

Posted under

Uncategorized

Comments

Leave a comment

Met me at SwanseCon? Ahoy!

Hi, I’m Gary, a Developer Evangelist for Twilio who’s based in Swansea. So if you’re using Twilio to power your communications or would like to know what we do, I’m the person for you. I’m local and keen to hang out with your dev teams and show you what we can do to help you engage your customers.

Drop me an email with an intro to ghockin@twilio.com and I’ll give you $10 extra credit. I can’t wait to see what you build.

Standard

Posted by

Posted on

September 4, 2019

Posted under

Laravel, PHP, React, Stream Roundup

Comments

Leave a comment

Writing a game in Laravel and React – Stream Roundup Week 1

This week on the stream I looked at writing a browser-based game that is similar to the fantastic Steam game Slay the Spire. Slay the Spire is a fun roguelike deck-builder game where you fight increasingly difficult monsters as you climb the titular spires. I decided to build a clone of this game in Laravel and React, mainly because the challenges of software design and architecture around game creation are fun and exciting. The main problems to be solved include:

  • Deckbuilding and management
  • Player state and turn-based combat
  • Programmatic level design
  • Enemy AI 

All these things are hard to master, but it should be a lot of fun trying!

Stream One – Wednesday 28th September

https://youtu.be/BRaHCvnVp6A

Find the code at

https://github.com/GeeH/codename-trapdoor/tree/E01

I started by playing the game Slay the Spire and trying to produce a mind map of the game that I want to create in PHP and JavaScript. Using Miro I produced a map of the hugely simplified game that I’ll create. Writing this game is a daunting task, and so I decided that it would be more reasonable to produce a vastly simplified playable game initially, and then iterate on that game to add more features over time.

The simplified game will have cards that only have three stats, the energy cost to play the card, how much attack damage it does to the enemy, and how much defence it applies to the Player.

Players should also only have 3 effective stats, health, energy and defence (wrongly called Block in the stream).

Next, I thought about how I can produce this in the application with another mind map.

I’m asking questions early about what tech should be used to solve the different problems we face. I decided on Laravel for the backend because it gives so much out-of-the-box to solve common problems that many websites face. Who wants to code a login form and password reset code in 2019? I’ll use React for the front-end because I’ve done some work with it in the past and need an excuse to use it some more.

Interestingly I had a long conversation with the viewers who, from now on we’ll call Chat, around what to use for persistent storage. There are lots of options when rapidly prototyping an application, and sometimes storage isn’t needed at all. In this instance, I’m deciding where I can manage the many cards that make up the game. It’s entirely feasible to store the data for the cards in PHP arrays or YAML files for example, but ultimately Chat persuaded me that I’ll need a database at some point, and so I used MySQL along with Laravel’s useful migrations and seeder to define a couple of basic cards.

https://github.com/GeeH/codename-trapdoor/blob/E01/database/migrations/2019_08_28_133517_create_cards_table.php

https://github.com/GeeH/codename-trapdoor/blob/E01/database/seeds/CardSeeder.php

Defining the database schema and initial seeded data like this is a great practice. You’re immediately putting your database into version control so that changes to schema and data can be code-reviewed just like any other changes. It also allows 3rd parties to quickly and easily get up and running with the project without too much hassle. Laravel’s migrations make this nicely straightforward, but if you don’t use Laravel, then Doctrine also provides a sound library for migrations.

A helpful tip I learned from Chat is that you can create the Eloquent model and the migration in one fell swoop using a single Artisan command:

php artisan make:model Card -m

The -m switch tells Artisan to make the model and migration, which is very useful as it’s rare that you’ll want a model without migration and vice versa.

After working with models for a few minutes, I became increasingly annoyed with the lack of IDE completion in my favourite editor of choice, PhpStorm. It’s highly recommended to install the Symfony and Annotation plugins along with the Laravel plugin. The Laravel IDE Helper library is also a must-have to generate completion on your models and Laravel’s facades. With these installed and configured, I’m in a much better place now that PhpStorm is giving full completion and proper error reporting.

Finally, I get around to writing some code in anger! I took a stab at deciding how a Player should be modelled in PHP, and it raised some interesting questions. 

https://github.com/GeeH/codename-trapdoor/blob/E01/app/Player.php

Initially, I used private properties and getters and setters to modify and retrieve values, but this looked and felt messy. The interesting part of the Player code came when I populated the Player’s starting deck in the constructor. This added logic and therefore should be tested. Funnily enough, when I wrote the test, it found a bug in the code immediately. 

At the end of the stream, I’d written some more prototype code in the test class to see how interactions with the Player object would look during various phases of the game. I decided to refactor the object to have public properties and no getters and setters, but this looked and felt wrong too. Chat raised the very valid point that the public API on a Player class should reflect the actions the Player can take. Instead of having methods like setCurrentHealth I should have actions like damage. This makes the public API much more intuitive, and when used, you can see the flow of the actions much easier.

I decided to leave it there for that stream, and consider how the public API should look ready for next time. All in it was great fun, and we made much progress.

Stream Two – Friday 30th September

https://youtu.be/lyrDERlftxQ

Find the code at

https://github.com/GeeH/codename-trapdoor/tree/E02

Before the stream, I decided to have a chat with Marco Pivetta about how I should structure the objects and where the logic should live. Marco is the maintainer of Doctrine and a very opinionated developer who I am lucky enough to call a friend. He convinced me that it’s fine to have a class that is mutable and has logic in it.

I’ve always thought that wherever possible, you should use value objects to store data in PHP. Value objects could be immutable and shouldn’t have logic in them, but I’ve been increasingly tired of classes that hold data and have a public API that only consists of getters and setters. The conversation with Marco was very useful in solidifying in my head where different code should live, and how the Game. Player and various Decks should interact.

For me, object design and interaction is one of the hardest parts of coding in object-oriented programming. Often I can’t see what classes are needed and how they should interact without getting some code down in my editor, which is why I spent the end of stream #1 prototyping some of the actions that should happen in the combat system.

To start the stream, I took the code that I prototyped last time and moved it into actual code that I’ll use in anger. I took the prototype code from the throwaway test I wrote last time and turned it into actual code and tests. This API is what I’ll use from now on, so it’s important to get it right.

https://github.com/GeeH/codename-trapdoor/blob/E02/app/Player.php

https://github.com/GeeH/codename-trapdoor/blob/E02/tests/Unit/PlayerTest.php

Some interesting things are happening here that needs discussing.

I’ve moved the Player’s stats into a new object that only has public properties called PlayerStats. This cleans up the Player so that it’s more obvious what is going on with the Player state. The logic here is mainly around moving cards between the draw pile, the hand and the discard pile and we’re using Laravel Collections to store which cards are in which pile. The different piles are:

  • The Deck – the different cards that the player has collected during this game
  • The Draw Pile – the cards that the player can draw into their Hand, made up of the shuffled Deck at the start of combat
  • The Hand – cards that the player can play during this turn of combat
  • The Discard Pile – Cards that have been discarded either by being played or by ending the turn. All cards in the hand are discarded at the end of the turn

This API is looking much cleaner than before, and in the tests, we can see what is happening. Manipulating Collections is usually trivial, but I needed to do some unusual things. I accidentally fixed the tests on stream by mistyping “slice” for “splice” but realised that I could (ab)use the splice method with various arguments to remove things from the Collection and put things in specific places of the Collection. This is very useful in a deck-building game because the majority of the code we wrote on this stream was about manipulating cards and decks.

There are some problems with the existing implementation. The testCreateDrawPileFromDeckFillsTheDrawPileWithTheShuffledDeck test fails when the shuffle re-orders the cards to the same order as the deck by pure luck. I documented this and want to make sure I fix this in the next stream. 

I’m also calling some of the methods on Player to make sure the state is correct before calling the method under test. This is particularly noticeable in the testDiscardingHandMovesHandToTopOfDiscardPileWithNotEmptyDiscardPile test. For me, this is an indication that there’s a problem in the code design somewhere. I need to be able to set the state of the Player before running the test without any Player code that isn’t under test running, to prevent false positives. 

You can see from the commented out code that I started moving the default state being created in the constructor out into dependencies to let me set state in the tests. Chat tried to persuade me this was the right thing to do throughout the stream, and as usual, they were right, and I was wrong.

While it doesn’t look like I got a lot done in this two hours, it’s so important to get the API looking right early in projects like this that I don’t mind spending the extra time making sure it’s as good as it can be. 

The fun of streaming for me is mob programming with the viewers, so if you’d like to influence how the game is designed and coded, then come and hang out during the live streams. If you’d like to know when I go live, you can follow me on Twitch, or on Twitter to get notified. If you can’t hang out while we’re coding, then leave a comment below, and I’ll consider your thoughts in future streams.

Standard

Posted by

Posted on

April 23, 2018

Posted under

Speaking

Comments

Leave a comment

Conference Speaking for Everyone – Submitting Chapter (FREE)

What even is this?

This is a full chapter from my started-but-never-finished book called Conference Speaking for Everyone. I’m posting this finished single chapter that’s been sitting on my laptop for nearly a year to a) Get some feedback and hopefully some impetus to finish the book, and b) Put what I hope is some useful information into the hands of the people who need it. So enjoy the entire full chapter (all 3000+ words of it), and if you like it and would like to see the finished book… MAKE SURE TO PESTER ME ON TWITTER!

— Gary

 

 

Call For Papers

 

So, How Do People Get Selected to Speak at Events Anyway?

In my experience, there are two ways speakers end up presenting at technical conferences. Either the conference organisers ask you directly if you’ll speak at their event, or there is a Call for Papers (CFP). As a new speaker, it’s unlikely a conference is going to ask you to speak directly, so you’ll likely get into the habit of looking out for Calls for Papers.

A CFP is when a conference invites potential speakers to submit the information on the sessions they’re interested in delivering. This information grouped together is often called an abstract, and once the conference has enough abstracts, or a set time has passed, they look through the abstracts and pick the talks they’d like at the event.

It can seem intimidating for the inexperienced; it used to scare the life out of me when I first started submitting to CFPs. Luckily, there are a few robust strategies we can use to stack the selection process in your favour.

What on Earth Am I Going to Speak About?

Before we discuss how to tackle our first CFP, perhaps we should think about what we would talk about. It’s easy to fall into the trap of thinking you have nothing exciting to say or aren’t knowledgeable enough to speak on a technical topic. Let me let you in on a secret; some of the best talks I’ve seen have been personal stories about how people solved problems, mistakes and all.

Think of the last big technical challenge you solved. It doesn’t need to be work-related; it could be a side project or an open source project. I’m willing to bet you didn’t solve it the first time. How you eventually got to the correct solution (for you) is an interesting story for many people. People love to hear how we failed just as much as how we succeeded, and the most intriguing stories I’ve listened to have been stories about the progression through the failed solutions until the problem is finally solved.

Have you used an exciting new tool or development concept recently? These can be ideal ideas to base a talk around. While you’ll see a lot of experts giving deep-dive style talks on subjects they are very knowledgeable about, there’s also room on a schedule for a gentle introduction to a tool or process a portion of the audience may have never used or even heard of.

During my developer career, I’ve learned about some handy tools and how they fit into my work, from gentle introductions to the topic. Things like Redis, Graphite, and Gherkin have all been introduced to me through very light conference talks, and I’ve adopted them all into commercial projects at some point!

Abstracts

There’s an essential point to make which also answers a commonly asked question—”Do I need to have written the talk before I write the abstract?”

No! At no point have I ever written even the outline of a talk before writing the abstract. With that said, I’ve always got an excellent idea of what the talk will contain before I write the abstract, and I know other speakers who will have an outline or mindmap before they even consider the abstract.

I curate ideas in my head for a time before I feel they are formed enough to make an abstract. Some talks will make it to abstract form a few weeks after thinking of them; others will take years before they’re developed enough to submit. Your mileage may vary (as they say).

Occasionally, I submit talks before I’ve learned all the information needed. This may seem crazy, but there are several technologies or tools that I want to know more information about; my to-do list is full of them. There’s nothing like having a talk about the OWASP Top 10 accepted to force you to do the research and learn all about that thing you never got around to learning!

I wouldn’t recommend submitting a “Deep Dive Into…” type talk without knowing the subject matter in depth, but I certainly think you can learn enough about a topic to submit “An Introduction To…” with only enough knowledge to understand the basics.

Talk Length

Every conference is different, but there are some slot types which persist across many of the events I’ve attended. Let’s take a look at the most common ones.

Lightning Talks

Typically between 10 and 20 minutes, lightning talks are a fantastic way to dip your toes into speaking at events because they are usually significantly shorter than the full scheduled slot. Lightning talks can cover a single technology or thought quickly and lightly, or can be a brief look at a tool or concept. Either way, having only 20 minutes of content to write can be less intimidating than writing a full talk—particularly first time out.

I’ve seen some delightful lightning talks that have amused, entertained, and informed; some of my favourites have not even been on technical subjects. Organisers are more likely to “waste” a slot on their schedule on a non-technical matter when it’s a lightning talk just because there are more of those spaces to go around.

Regular Slots

These are the bread and butter of most events and are usually between 45 minutes and an hour. This is an excellent length talk as it allows you to deliver content with an interesting narrative (more on this later), and work to a fulfilling conclusion. At most events I’ve attended, the talk slot length also includes questions, so it’s worth planning on finishing 5 or 10 minutes earlier depending on the number of questions you anticipate and are happy to answer.

Tutorials

Longer teaching slots are not really talks. Usually three, six, or even eight or more hours are for training rather than speaking engagements, and won’t be covered any further in this book.

Keynotes

Keynotes are sometimes picked from submissions but may be negotiated directly. These talks are typically the bookends of the conference. Usually, they are the only talk during that timeframe (in multi-track conferences) and are generally by people of note in (or out of) the community and contain a powerful message. Keynote slots are usually given to experienced speakers and aren’t something you should worry about at the start of your speaking career.

Writing Abstracts

I use a tried and tested formula when I’m writing my abstract. It’s crucial that your abstract conveys a certain amount of information for the eventual audience, but I always write my summary with the organisers in mind. I’m still trying to think of how I can convince the organisers to pick my talk when writing my talk abstracts. If the event organisers do not feel invested, the talk will never be delivered.

We’ll cover writing a great abstract soon, but first, we need to mention something equally as important.

Talk Titles

Your talk’s title is arguably the most essential piece of the puzzle. A good title can help an average abstract, but a great title can be intriguing enough to get the talk selected and entice more people to attend. It’s also worth mentioning that at most events the schedule the attendees pick talks from only show the title. People often make snap judgements based on the title alone and not the abstract. In my opinion, the title should clearly convey the topic of the talk with bonus points for clever wordplay, but I’ve seen many people have success with weird and wonderful titles that may have nothing to do with the topic.

My advice when beginning your speaking career would be to make the title clear and evident without trying to be too clever. You’ll have room to grow in this department as you get more experience. I’ve never seen a talk rejected because the title was too obvious.

Good Titles

  • Climbing the Abstract Syntax Tree

Explains we’ll be looking at something called the abstract syntax tree with a clever little pun.

  • Learning Machine Learning

Tells you exactly what you’re going to learn in the session without wasting any words.

  • Step Into Debugging

We’re going to learn about debugging and “Step Into” infers it will be an introduction, as well as being a term used in the debugging process.

  • DDD for Beginners

Almost the perfect title for me, we’re covering DDD, and it’s for people with no prior experience. But, would a beginner audience know DDD means domain-driven design?

Not-So-Good Titles

  • Lean, Extreme, and Bulletproof

What is this talk even about? It doesn’t tell us anything about what will be covered. It may be smart when considering the abstract, but don’t forget many people will never read your abstract.

  • The UI is application

This makes no sense. It makes me wonder if your abstract will make sense. Remember, organisers will be reading hundreds of abstracts and sometimes will not even read your synopsis if your title is not even grammatically correct.

  • Don’t fix bugs, prevent them and harden your code!

While this may seem like great advice, as a title, it doesn’t work for me. If I were going to attend this talk, I’d want to know what skills or tools were going to be covered to ensure I wasn’t learning about something I already use.

  • STEADY REVENUE: A FEW TIPS ON HOW TO EARN MORE WHILE DEVELOPING FEWER WEBSITES

It’s too long, and it’s all in capitals. While you may be tempted to scream your title from the rooftops because you’re proud of your idea, it doesn’t help. Try and keep your titles short and catchy. The double space between “fewer” and “websites” also doesn’t help either.

The Abstract

“Write for the organisers” is such good advice that it’s worth repeating. In my mind, the abstract is something I’m using to try and get the organisers to pick my talk, while the title is something I’m using to try and get the attendees to attend the sessio. With that said, there are three key pieces of information I like to include to try and get my talk selected.

I’ve stolen and adapted these ideas from the tweets and ideas of @grmpyprogrammer so my thanks go out to Chris Hartjes.

The Problem

You’ll likely be trying to teach the attendees about something, but before I want to learn about something, I need to know what problem it will solve for me. What’s hard in a developer’s life that you can make easier for them?

The Solution

Now that we’ve outlined what’s hard, here we can explain how we can make it easier. Talk about the technologies you’ll introduce or the skills you’ll hone. Make it clear that we’ll solve the problem outlined above using the tools or skills we’re informing about here.

While the problem and the solution should be provided, sometimes it’s possible to combine them into one paragraph or even one sentence.

The Take-Away

I like to finish by making it clear what anyone attending my talk will leave the session with. Often I’ll use phrases like “You’ll learn about $x,” or, “You’ll leave having a solid grounding of $y.” I like to set expectations in this section, so anyone who attends (who’s read the abstract) will have no illusions about who the talk is targetted towards, and what they’ll take away.

Examples

Here are some examples of my abstracts that follow this formula. I’m in no way saying these are great abstracts. These examples are from my own abstracts and show the formula at work, ensuring my submissions are at least getting read and understood by the people selecting the talks.

Getting started with Zend Framework 2 is relatively easy. But once you have a basic CRUD application up and running where do you go from there? Knowing how you should build your application with maintainability and scalability in mind can be very daunting. But there are some hard and fast rules you can use to help to factor your application into something functional, maintainable, and performant.

In this tutorial, we will take a pre-built ZF2 application straight from GitHub, and apply some simple(ish) rules to make a basic ZF2 application run in a more modern way. Say goodbye to getServiceLocator in your controllers, and say hello to the full power of dependency injection, event listeners, and framework plugins.

This is a good example of outlining the problem and solution, then finishing with the takeaways.

Dependency injection is everywhere, and dependency injection containers and programmatic service locators are very popular right now. Zend Framework’s Service Manager is one of the cornerstones of the framework, but using the right feature at the right time can be difficult. Join us as we cover exactly how and when you can use the Service Manager, from the simplest “invokables,” through “factories” and “abstract factories,” all the way to “initializers”
and “delegators.”

Here we combine the solution with the takeaways, but both points are covered.

At some point, in any successful web application’s life, you’re going to need to remove things from the request and response cycle to improve performance. From sending out emails to publishing information on social media channels, we’re finding ourselves trying to shoehorn more and more processes into the traditional HTTP request/response.

This talk will help explain how you can use ZF\Console based command line PHP to control workers that take and process jobs from a queue, helping to make sure each and every one of your responses is lightning fast. Using popular technologies like Redis and Beanstalkd to manage and monitor worker processes is a skill every developer will benefit from sooner rather than later.

Again we outline the problem, then give the solution and takeaways in the second paragraph.

While I find this system works very well for me, and I’d encourage you to use this in your early submissions, it’s likely that with experience you’ll find your style. As my own presentations evolve I sometimes see myself not outlining the solution because I want the big reveal to be in the talk itself, but this format has worked well for me and it’s something I end up going back to—particularly when I want to talk about a technology or tool.

Other Information

As well as the title and abstract, organisers usually ask for more information to judge your submission. Often organisers will provide a separate field to allow you to pitch your talk (and yourself) to them without the public ever seeing the information. I suggest that you use this field to your advantage to give organisers confidence that you’ll deliver a fantastic talk. Have you presented this talk before at a conference or user group (we’ll talk more about these later)? Make sure to let them know. You can also give some information about why you should be selected, and this is particularly useful if you’re a new speaker. Being honest can help, saying you’re new but you understand what’s involved and you’re confident you can deliver an exciting talk will help organisers to take a chance on you for your first few presentations.

If you’re submitting on a given technology, it can help to explain why you’re qualified to speak on that topic. Do you contribute to an open source project that you’re submitting on? Make sure to mention it as these qualifiers can help tip the balance in your favour if there are many submissions on a similar topic. Don’t be afraid to sing your own praises. Not many people are comfortable with self-promotion, but an honest reflection of your incredible talents can help you get selected.

Don’t be tempted to leave the “other information” box empty, particularly if you’ve never spoken before. I always put something in the box, either links to feedback from previous talks I’ve given or if it’s a new talk why I think it’s incredible. You’re given the opportunity to pitch yourself to the organisers — use it!

An Aside on Expenses

Often organisers will ask you if you need help with travel and accommodation costs if your company is interested in sponsoring the event, where you’re travelling from and a myriad of other logistical information. If you need help paying for your travel and accommodation, then don’t be tempted to lie about the fact. You’re doing the organisers a massive favour by agreeing to speak at their event for free (or even at your own cost) so don’t undersell yourself by agreeing to pay your own way. Of course, I can only give my own opinions here the final decision is yours, but think about the time you will spend submitting to the event, writing the talk and slides, practising the presentation and then travelling to the conference and delivering your speech. This can add up to tens and sometimes hundreds of hours of time you won’t be compensated for, so the least the conference can do is to pay for your expenses to present for them.

Most conferences are open and upfront about their policy to reimburse speakers expenses, and I would personally advise to only submit to those with a transparent and fair expenses policy. Some events will try and claim that speaking for them will give you exposure and boost your career, but don’t forget they are charging people to be at an event that couldn’t happen without people like you speaking there.

Personally, as an experienced speaker who is lucky enough to count presenting as part of my job, I do sometimes break my own rules to speak at events while paying for hotel and/or travel myself. But these times are rare, and usually, when the conference has particular morals I agree with such as being free or very low price to encourage people to attend, or have a certain topic I feel is important enough to donate my time and money to present on (such as my talks on mental health). My rules of thumb is I expect a ticket to the event and my travel and hotel covered before I will submit to an event.

It can be tempting to attempt to pay your way to your early acceptances, but I would recommend against it.

Standard

Posted by

Posted on

February 23, 2018

Posted under

Uncategorized

Comments

Leave a comment

Nerves Before Speaking

My good friend and fellow PHPUK keynoter, Jenny Wong posted an interesting post on Stage Fright, in which she explains how she minimises the stagefright before going on stage for a keynote talk. It’s fascinating because as those who know me will attest, I get terrible nervousness before going on stage, particularly with keynote talks and even though I’ve given several of them now.

One of the reasons that I found it so interesting is because Jenny’s experiences differ from mine in some regards, but hold up in others. In particular, I worry about the content of a talk the day before I deliver it, or if it’s a closing keynote then the morning of the session. During my recent closing keynote at PHPUK, I was probably the most worried I’d ever been about the talk and felt underprepared, even though I had put my usual 40-or-so hours of prep time and practice into creating the talk.

Interestingly, PHPUK will be the first time I’ve given this talk, and I haven’t had it seen by anyone — today’s audience will be the first. The concept has been vetted heavily by friends who I trust, so I’m happy the idea is solid. I love Jenny’s advice about setting a run-through date with friends to force you to create the content ahead of time. This has rarely been a problem for me which in itself is interesting. I can be as procrastinating as anyone, but I generally get my talk content prepared well ahead of time as I know what it feels like to be on stage and bomb. My rehearsals will have been in my front room with the TV connected as the projector, delivered to nobody, just to make sure I have the pace and cadence of the talk right. I feel like it’s important to fill any timeslot you’re given, and this kind of practice makes me feel confident I’ll run to time (even if everything else is a disaster).

The talk was about things I wish I’d known earlier in my developer career and was (loosely) linked with gaming, and my central panic was that the advice I’m giving was too obvious, too fundamental to warrant being told in a keynote slot. Information like “learn to say no” has been really important in my career, but when you’ve heard the advice before, then it may seem worthless. I’m a firm believer that everything is obvious when you know it, but how simple can you be without being too simple?

My other massive concern is that the gaming references would alienate parts of the audience and make the talk exclusionary. I try not to make jokes just for people who are “in” on them because that makes the rest of the audience feel left out. For speakers who’ve been around a bit, this can be difficult as anything I say can be construed as an “in joke” by friends who will laugh leaving everyone else confused.

ASIDE: I hate this and try hard to make any jokes that most of the audience will get, but it’s impossible – even a word or two I didn’t think about can cause only my friends to laugh which is terrible. I remember being at talks before I was a speaker baffled at what people were laughing at and feeling completely disconnected from the rest of the room. It’s horrible.

To combat my weird feeling of underpreparedness, I spent the morning of the talk in my room going over my slides and practising out loud. Rehearsing out loud is the super-power that allows me to combat fear, although I don’t want to practise too much as my talk can lose the story-telling spontaneous edge that I enjoy so much. In general I don’t practice the morning of my speech, but in this case, I couldn’t shake the feeling, so I decided to break the rules and do it.

I then did my usual ritual of eating very early, in this case for a 5pm slot I ate at 12pm and then only a small meal, and getting to the venue well in time. Typically I’ll be at the conference all day on the day of my talk, although I’ll find somewhere to hide out when I need to be alone. I also like to try and see any other keynotes that come before mine so I can reference them in my talk, it’s excellent for conference organisers if the themes flow (although as mentioned in the particular case I felt practising was more critical).

Once at the venue, there’s a few things I need to do to combat nerves. I need somewhere to hide. In the case of conferences that have the speaker hotel attached, this isn’t a problem as I can quickly get to my room, but where the hotel is a distance away, it can be a problem. I try and find either the conference organised quiet room (or speaker green room in some cases), or some off-the-beaten-track part of the venue where nobody goes. This is important for me to have some quiet time when I need it, and to run through slides if I want to.

The second thing I find it a toilet. It’s not nice to talk about bowel movements, but very often when I’m nervous, it has a physical impact on my digestive system. Sometimes my bowels feel the need to empty, and quickly. Experience has taught me that having a lavatory close to hand makes me feel more comfortable — again if I’m speaking at the speaker’s hotel then no problem, but if not I try to find an out-of-the-way bathroom that is little used so there won’t be a queue. You can usually find these at any venue by wandering away from the conference or even asking at reception. I’ll stop talking shit now.

Once I get into the hour before the talk, all bets are off. I usually go for a walk with my headphone on, but I won’t listen to music. I tried this after seeing it work very well for people like Anthony Ferrara but it ended up making me feel even more manic and frantic which if you’ve seen me speak isn’t a good thing. I need to calm down not psych up! I will listen to an audiobook or podcasts and go for a reasonably long walk away from the venue, usually about 45 minutes making sure to get back in plenty of time for the tech check. This is personal to me, I feel the exercise and attempt to switch off really help me to keep calm (toilet issues notwithstanding). Before heading to the tech check, it’s one final visit to the toilet and then head off to the room.

ASIDE: People often ask if I have a beer before speaking, and the answer is always no. I’ve never had a drink a talk and I never would because beer tends to make me need to pee, and I can’t think of anything worse than being on stage needing to pee. When you’ve got something working, I think it’s foolish to risk breaking it.

The tech check can be stressful in itself, but having done so many now, I don’t feel so bad. I have a copy of my slides in PDF and Keynote format on a pen drive that doubles as my clicker, so if all else fails I’m covered, but I don’t have as many slide decks as Jenny does. I think Jenny’s advice is golden if you’re just starting out and want to take as much stress as possible out of the day, but for me, I’m comfortable that I can fix any problems in-situ. Experience has taught me that my high-contrast slide theme works well on most projectors as that was a priority when I got it designed. I have the feeling that now I’ve said that this will bite me in the bum sometime soon, but I generally don’t feel nerves about getting my slides and mic setup.

And away we go, baring technical problems there’s not much more you can do. To echo Jenny’s point, nobody in the room wants you to fail, and it’s vital to settle everyone down (including yourself) as quickly as possible. I read a LOT of autobiographies by stand up comedians, and most of them mention that getting the audience relaxed as soon as possible makes life easier for everyone. It’s slightly different in the stand-up world, but the premise is that everyone wants you to do well but they’re nervous you’ll be poor. Reassuring them with a good joke right off the bat settles everyone and stops people being scared for you — they can just enjoy the show. This translates to me trying to be calm and self-confident as soon as I can so the audience knows they are in safe hands and can relax. Usually, this is in the form of either a scripted laugh (a funny picture of myself usually works well) or some observation. In the case of PHPUK I mentioned how much I liked the new round seating setup which seemed to put everyone at ease.

Technical problems can be a nightmare and are usually out of your hands, I don’t know what to say about this as each case is different. I tend to plough on through while making a joke about it if it’s possible but I have no idea what I’d do if the problem meant I couldn’t continue. At PHPUK my slide deck started flickering on the main screen and the comfort monitors (the displays below the stage facing up that show the speaker what’s on the main screen). This was extraordinarily off-putting and pulled me out of the moment a few times. I tried making a joke about it, but even that fell flat which made me feel worse — I have no idea what I could have done differently. In the end, the tech team started pausing my slides on the output and then updating them by hand when I flicked through, which created its own problems as lots of my jokes are timing based on the slide changing. This could have been so much worse, but I have no idea what I could have done differently, it’s something I want to investigate in the upcoming weeks to see if it’s something I can learn and improve on (but I suspect it’s not).

There you have it, a brain dump of my very nervous keynote talk at PHPUK. I hope this helps someone, if you have questions or want to talk about this with me, hit me up on Twitter, I’m always happy to discuss this stuff!

Good luck.

Standard

Posted by

Posted on

September 1, 2017

Posted under

Uncategorized

Comments

1 Comment

New Opportunities

It’s with equal parts excitement and amazement that I’m making myself available for consulting development or training work from the 1st October 2017.

This does not mean I’m leaving JetBrains!

Luckily for me, I’ve somehow managed to cultivate the unique opportunity to continue with JetBrains as a Developer Advocate for PhpStorm on a part time basis — keeping my role as the face of PhpStorm in the PHP community, speaking at conferences and working on the booth which is a job I love doing.  However, when I’m not attending events, I’m now going to be back working for Roave providing consulting, training and mentoring which is also something I’ve missed and love doing.

Please continue to talk to me on Twitter or at conferences with all your PhpStorm stories, troubles and recommendations as this will very much still be part of my job.

If you need consulting services from someone with now very close to 20 years experience in the technology industry, training on all aspects of PHP but particularly Zend Framework, or are interested in hiring me for short to mid-term contract work then please get in touch, my DMs are open on Twitter @GeeH.

This new development is truly going to give me the best of both worlds as I’ll be even more useful as the voice of the PHP community to the fantastic PhpStorm developers when I’m solving the real-world problems that we (the users of PhpStorm) face on a daily basis.

Standard

Posted by

Posted on

October 10, 2016

Posted under

Uncategorized

Comments

Leave a comment

Open Sourcing Mental Illness Handbooks

One of the most important objectives for the Open Sourcing Mental Illness project is to help people get the support they need for mental health challenges in the workplace. I’m so proud that we’ve had our Mental Health in Tech guidelines available as ebooks from our website for the last six months, but today, we’ve released these handbooks on the Leanpub platform.

Continue reading →

Standard

Posted by

Posted on

May 5, 2016

Posted under

Laravel

Comments

4 Comments

Yes, I’m Learning Laravel

I can hear large parts of the internet laughing at the joyous irony. Gary Hockin, the vocal proponent of mocking Laravel, is going to sit down and learn the framework. Not just play around with it, not just read the manual, but build something extensive and meaningful from beginning, to end. For real.

Continue reading →