Category: WordPress

WP Hacker Cast – the official launch post.

About a year ago (literally, I got the domain renewal notification two days ago) I came up with a podcast idea.  I had just finished reading “Milestones – The Story of WordPress” and I thought how awesome it would be to interview every single one of the core release leads, from Matt all the way up to Helen, and dive deep into the ins and outs of leading a WordPress release. I started by reaching out to two of the release leads, Drew Jaynes and Helen Hou-Sandi. Helen because she had just lead the 4.7 release and Drew because I’ve actually met him in person. Both were keen but had other things going on at the time. So I put it on hold until they were available. A few months later the idea resurfaced in my head, mostly because I had just helped Craig Hewitt launch the Seriously Simple Hosting extension for the Seriously Simple Podcasting plugin. I thought about all the WordPress developers I already know, both locally and internationally, who weren’t necessarily WordPress release leads but whose stories I would love to hear. So I decided to retool the podcast to focus on those folks I refer to as ‘WP Hackers’, people who use WordPress and write code with/for it every day. I’ve since recorded my first four episodes (3 of which are publicly available on the WP Hacker Cast website) and I’ve had good responses so far. I’m slowly learning about the extra things needed for a podcast, like a subscription option as well as submission to things like iTunes. It’s all a great learning process. I’m happy to anncounce that you can now subscribe to new podcast episodes via email, directly from the site. Use the ‘Subscribe to the WP Hacker Cast’ form in the sidebar to receive fresh podcast notifications in your inbox. The podcast is also now listed on iTunes and Stitcher, so you can consume the episodes using your favourite podcast player. Please feel free to comment on the episodes, or contact me directly with feedback, comments and suggestions. I’m always looking for WP Hackers to talk to or interesting topics to discuss.
Filed under: Experiences, WordPressTagged with: ,

Gutenberg day ??? – well that was hard!

I remember the first time I read about Jerry Seinfeld’s productivity secret. At the time it seemed trivial, but after trying to write a blog post per day for the month of September using Gutenberg, and then failing miserably at it, I can admit to the fact that planning to write something every day and actually doing it, are two very different beasts. Then I woke up this morning and saw that it has been decided that Gutenberg will no longer be using React. That’s a pretty big deal if you ask me. It also makes me realise that even one of the biggest open source projects in the world can make drastic changes to how it’s original goal was envisioned. So instead of trying to blog every day I’m just going to try and blog more, maybe once a week, with a better ‘check’ against myself to ensure it gets done. With Gutenberg still a long way from being merged into core it’s on me and everyone else who makes a living from WordPress to ensure that when it is officially released, it’s awesome, not just good.
Filed under: Experiences, WordPress

Gutenberg day 8 – Contributing to Core

I’m attempting my first shot at contributing to WordPress core with ticket that was opened 8 years ago!

I feel like it’s small enough that I can get something done by the time the next release rolls around but useful enough that it will make peoples lives easier.

Feel free to follow the ticket to see how it pans out.

In other news, using Gutenberg today was a bit of a pain. Because I use Jetpack’s publicise functionality to share my content socially and Jetpack does not yet support Gutenberg (for obvious reasons) I have to write up the post in Gutenberg but not publish it and then edit the Post in the usual way and publish it. Today this lead to me loosing all my content and merely switching to the regular post editor. Fun times.

Filed under: Development, Experiences, Freelancing, WordPress

Gutenberg day 7 – New things

WP HackerCast
Today I'm especially excited to blog as I have a little news to share. The first episode of my new podcast has officially been published.
WP Hacker Cast is my way of talking to and learning from all the great WordPress developers I know and communicate with. I've got some great interviews coming up, but the first is always the most special. I hope you enjoy it.
Filed under: Development, Experiences, Freelancing, WordPress

A month with Gutenberg

Gutenberg
If you are in any way involved with WordPress and unless you've been living under a rock you're aware of the new Gutenberg editor that is currently in development. Gutenberg is what Matt and many other WordPress developers see as the future of WordPress. However, as with most new things, it's not been met with universal praise, with some even going so far as to review poorly, strange given that it is very clearly marked as a 'beta' product. Something that Matt and others have asked for is for user feedback. I've mostly stayed away from testing Gutenberg as I don't often have a lot of time for blogging lately. However, seeing as September is spring month in South Africa I've decided to try a little experiment. From today and for the rest of September I will attempt to write one blog post a day using Gutenberg. I am hoping that this will a) give me some time to test out the new editor and b) force me to write something every day. My ultimate goal is to try and both give useful feedback back to the Gutenberg team as well as start a pattern of blogging daily. Are you currently using Gutenberg? Let me know in the comments what your opinion of it is, by the end of the month I should be able to have worked with it enough to have formed my own.
Filed under: Development, Experiences, WordPressTagged with:

2017 WordPress resolutions – mid year check in.

Late last year I wrote down my 2017 WordPress resolutions. These were the goals I set myself (for better or worse) that I would like to achieve this year.

As we’re just over halfway through the year I thought it might be interesting to take a look back and see if I’ve made any headway on any of these items and whether I need to make some drastic changes for the next six months.

A more stable work environment.

If I think about it I have not yet quite achieved the ratio I had set out to, but there is some good news. I can’t remember when last I worked past 23:00 and I’ve even had some weeks where I didn’t have to catch up in the evenings at all. I have not yet been able to carve out time for plugin development though, so that is something I want to work on more. I can still be doing better with my project estimation so I’m constantly evolving that process.

5 for the future.

To be honest this has worked out, but in ways that I never could have imagined. Due to an unexpected set of circumstances I am the lead organiser for WordCamp Cape Town this year. I am enjoying this tremendously as I am really looking forward to putting together an even that could change someone else’s life as it did mine in 2015. I also recently joined the WordPress community team as a Community Deputy, meaning that currently I assist with vetting new WordPress meetup groups as well as hold Meetup orientations.

I still want to start contributing to WordPress Core as well as Calypso, the WordPress.com product, so I am looking forward to the the newly announced New Contributors meeting. I’ve also started learning React in order to look at contributing to Calypso.

REST API powered plugin

This one is still coming, as I’ve decided to build it using React for the admin sections (similar to Jetpack) so I need to finish my React fundamentals course first.

Twenty Seventeen theme

Sadly this won’t be happening this year, but I am getting a lot of experience using Twenty Seventeen on the WordCamp Cape Town site, so perhaps that counts?

WPHackerCast

This will also not be happening, however another podcast idea has revealed itself which is a much more exciting idea and one that will benefit way more people, so watch this space.

So, not to bad as far as I can see. I think I’m pretty close to completing at least 4 out of the 5 before the end of the year. I’ll check back in December and see how it went. How’s your year going? Any goals you’ve set that you’ve either achieved or are on your way to do so?

Filed under: Experiences, Freelancing, WordPressTagged with: ,

What’s your Git Strategy?

As a freelance WordPress developer/consultant I rarely work in a team environment. So my usage of Git is mostly for my own purposes of being able to have my code backed up somewhere and the ability to create branches to try out new pieces of functionality without affecting the ‘master’ code base.

Recently I was chatting to Simon Dowdles, another Cape Town based WordPress developer, about this. He is, in his own words, very strict about a Git workflow. We agreed that it would be a good idea to implement a better system, so we put his workflow into place.

  1. Development branch is where all UP TO DATE and approved code lives
  2. Master branch is the truth and is ALWAYS what is on production
  3. Feature/hotfix branches are branched off of develop and only come back into develop with a Pull Request
  4. Release branches are made off of develop for releases, the release is done, merged back into master and tagged with the appropriate version tag (ie 1.2.0)
  5. Release branch is deleted, and there is only ever one

On the surface this all seems very obvious but it is often something that one tends to dismiss when working alone on the code base. After working with it for a few days however I can already see the benefits.

Lets first look at a real work example of how this would work in practice.

Setup

Firstly the repository is going to need a develop branch. So inside the root of my project folder I’ll create the develop branch from the master branch.

git checkout -b develop

And then push the branch

git push -u origin develop

If the develop branch already exists I can just switch to it

git checkout develop

Now I will need to create my feature branch, to make my code changes. So while still on the develop branch, create a a feature branch

git checkout -b feature/my-cool-feature

Usage

I can now starting coding my changes, committing frequently. I tend to commit every time I complete a chunk of functionality. So if I fix a bug, I commit. If I add a function and its more or less complete I commit.

git commit -a

At the end of every day, or if I am going to leave my workstation for a period of time, I push all current commits to the feature branch.

git push -u origin feature/my-cool-feature

When I am convinced it is good to go, I will submit a pull request or PR. When I create my PR I will request that it is merged into the develop branch, NOT master.

As we are using GitHub for this project I prefer to use the web based tools to create a PR, but most of the other cloud based Git services provide similar tools.

The rest of the team will review this PR, which will involve testing. They will scrutinise my code and provide feedback and I will fix or alter things to suit the team/project coding style(s).

Each time I commit the above changes, the team in the PR is notified and will see the changes in the PR.

When everyone is happy, they approve the PR and I merge my PR into the develop branch. At the same time I can choose to delete my feature branch (which I typically do)

The develop branch now has more (stable) code in it, and part of my PR should have been a version bump. (for example let’s say to 1.0.1)

Release

The team decides it is time to release version 1.0.1

First I need to make sure all my code is up to date

git pull

And then make sure I am in the develop branch. This is the branch that has all the approved code for the next release (1.0.1).

git checkout develop

I create a release branch called release/1.0.1 off of develop

git checkout -b release/1.0.1

The code gets deployed ( in this case its a WordPress plugin, so it means pushing all the code to the wordpress.org plugin repository, more on that another day 😉 )

 

I then merge the release/1.0.1 branch back into the master branch and tag it as release 1.0.1, again using all the GitHub PR, merging and tagging tools.

And we’re done, release 1.0.1 is in the wild and by following this approach, master is ALWAYS the truth. If for example release 1.0.2 were to fail, we simply roll everything back to master.

Wrap up

I’ve been working like this for three releases of the project so far and I have to say, once I had all the steps in my head, it did make developing, merging and releasing a lot smoother and more controlled.

Are you using Git as part of a team? If so I’d love to hear your comments on the idea of having a Git Workflow/Strategy.

Filed under: Development, Freelancing, WordPressTagged with: , ,