Posted on

Thoughts on 2015

Yes, I know, another year in review type post…but for me this year has been profound in a variety of different ways.

Today I finish up my 2015 working year, and return in early Jan, but it’s also the end of the first 6 months since Automattic acquired WooThemes. It’s been quite a time of nostalgia for me, particularly yesterday when some framed photos of each year’s WooTrip arrived at the Cape Town office.

It’s funny how after 6 years so much has changed. I look at that photo of the 6 of us, and even though only 4 are still around, it’s pretty crazy and extremely humbling to see what has been accomplished since then.

Woo Photos
Woo Photo wall, I’m furtherest on the left in the top left framed picture.

 

When I joined Woo, WooCommerce was merely a thought, no code, just an idea. And we wondered when we would get to it. It’s funny how a single product can change a business and capture the embrace of a community.

It hasn’t been all roses to be honest over the past 2 years for me. There have been times where I’ve been unsure of things and my future, but I’ve sought prayer and wise counsel throughout and I’m grateful for those people in my life.

Probably the biggest change this year for me was the shift away from doing additional freelance work (outside of Woo). I did freelance work mostly for fun and if there were interesting projects, not as a “have to”. But looking back, I probably took on more than I should have, and that sucks.

It’s been well documented by several people that Automattic has a COI policy – and, I don’t think it’s bad, I actually think it’s great. For me, I’m pretty drained at the end of my work day these days, and I don’t want to see a screen! I just want to relax with my family, pickup my guitar, have a swim, see my friends, basically detach from the world of tech.

This has been a massive mindshift.

I used to be “always on” but now I try to focus all my energy during my work day and detach after hours. The funny thing about that, is I’ve found I’m a lot more productive these days. I feel more focused at work, I get more sleep, and I’ve built a more meaningful relationship with my wife and daughter.

All in all, it’s been a tough year (in a good way), but has been a very rewarding year. I honestly feel proud of what I’ve been part of accomplishing at Woo, and now at Automattic, how things have changed for me personally, and the outlook for 2016. It’s an exciting time and I’m looking forward to connecting again next year, whether it’s online or in person.

So, for now, I’m signing off. Hope you all have a wonderful Christmas and New Year period.

See you later!

Posted on

Why Themeforest authors why….

So….all this commotion regarding the Slider Revolution plugin being bundled in themes has caused quite a few headaches for people. Myself included…

I spent a fair chunk of an evening this week “updating” a friends (staging) site using this theme -> http://themeforest.net/item/chariot-professional-responsive-portfolio-theme/5817175 to make 100% sure it was secure.

Here’s what I had to do…

  1. Backup the site – obviously
  2. Download the latest theme package from ThemeForest – fair enough
  3. Deactivate all the plugins – ok then…
  4. Delete all the plugins – huh? why? Oh right….cos you have your own custom installation of plugins….right….
  5. Upload the new theme – smooth, theme options maintained, hope restored.
  6. Reinstall and active the new versions of the plugins – worked well.
  7. Pour a double whiskey – because half the freaking content (such as slider images) is now gone/broken/i don’t know

So yes, I’m at a point of frustration now, because even as a seasoned developer on over 100 themes I now have to sift through backups of what SHOULD have been a smooth upgrade process just to fix the content. Loving it.

And before you ask, fortunately this wasn’t a live site, it’s a staging site, so luckily his live site isn’t buggered. And it’s not like I don’t like the Theme, just to be clear….just not this crappy plugin activation method.

Well now…that was fun….maybe I should start a marketplace?

Posted on

Jetpack Photon image_downsize() issue

Sometimes in WordPress code you have the need to get an attached image, for example in a featured slider. To do this we make use of the wp_get_attachment_image_src() function.

The reason we do this is to grab the image properties such as height etc instead of just the url in order to add a property for dynamic slide heights.

However, there is a problem with this when a user is using Jetpack and the Photon service. Jetpack uses a function called image_downsize() which does not return the required image object/array. It simply returns the url.

So in the example below, height would not normally be able to be returned with Jetpack active:

$featured_height_id = get_post_thumbnail_id();
$featured_height = wp_get_attachment_image_src( $featured_height_id, 'full' );
$featured_height = ' height: ' . $featured_height[ 2 ] . 'px;';

However, I’ve added 2 lines that fixes this -the add_filter and remove_filter for jetpack_photon_override_image_downsize action.

$featured_height_id = get_post_thumbnail_id();
add_filter( 'jetpack_photon_override_image_downsize', '__return_true' );
$featured_height = wp_get_attachment_image_src( $featured_height_id, 'full' );
remove_filter( 'jetpack_photon_override_image_downsize', '__return_true' );
$featured_height = ' height: ' . $featured_height[ 2 ] . 'px;';

And before you point out that this is not technically Jetpack’s fault – it only occurs when using Jetpack Photon. Deactivate the plugin and all is fine and dandy. image_downsize() is in WordPress core (see link below).

Related Github issue here -> https://github.com/Automattic/jetpack/issues/607

image_downsize() codex -> http://codex.wordpress.org/Function_Reference/image_downsize

Posted on

Self Commenting Code

So…a colleague of mine, posted a tweet today about self commenting code. I briefly replied, along with others, and I thought I’d share some of my thoughts on “self commenting” code and standards.

Whose rules are you following?

First things first, who defines what is self commenting code? I guarantee you that different developers will see code and comments differently. For example, a php developer who is used to a rather loose language structure, will think differently from a more structured C developer when it comes to commenting their code.

There are different interpretations based on different standards, and one such standard I have researched and written about is the Construx CxOne standard based on Steve McConnell’s work. And even by using such a standard as guidance, some of the standard is specific, for example naming conventions and formatting of variables, while other parts are vague, for example in section 1.6 under commenting “Remember the comment audience

With that said, let’s take this one step further…

Developer Career Levels

If you have been coding for 10 years (or even 5), think back 5 years and ask yourself if you know more or less than what you do now? That’s fairly simple, however, ask yourself if you are a better developer?  Who defines what “better” is – is it a feeling or do you use a metric such as a standard to govern this? Or is it your practices and habits (such as commenting and naming conventions)?

But all that aside, simply think of working in a team with junior and senior developers. I’ve had this very experience at a previous job where one of the senior developers and I had to work together on a project, and he had his ways and I had mine – whose way is better?

But is that even the right question? The real question is, when it comes to coding together is communication. Can I communicate effectively through my code to other developers. If the senior developer on the above project used super complex code with no comments, I would have been screwed and the project would have suffered. But we had defined coding standards before the project began so we knew what to expect. The same should be seen in the WordPress community, as WordPress has set code standards.

Let’s go a bit further down the rabbit hole…

Code Frameworks

Some frameworks use camel casing (but is that upper or lower camel casing…) for naming conventions of variables and functions, some have coding patterns like MVC, MVP, or n-tier, and some use docblocks to generate API docs to elaborate on there instead of the code – and here again it’s worth noting who is the audience? WordPress is a fantastic example of this – the Codex serves the community far better, in my opinion, than tons of comments in the code.

Onwards to my final point…

Who cares?

Ultimately this argument is subjective and people will inevitably have an opinion one way or another, because people are different and like to have their own opinion (just take religious arguments as one example) – the main thing here is to communicate well, if you do that well through your code, then you’ve already won!