Code bits: Fixing a rebase mess

What started being an “easy issue to fix” became a mess rapidly due to my inexperience with GitHub, the issue can be seen [here].

Seems that when I tried to fix some linting errors, I rebased it wrongly and created a divergent branch, that’s why every time I tried to rebase again it did not work as expected.

Seems that this can be fixed using git cherry pick and git push origin --force but as I was unsure how to go with it, and I rather prefer to test it first in my own repository instead of making the commit history of this issue even worst, I decided to take the long way:

– git checkout master

– git pull // I’m getting the latest changes

– git branch -d fix/248 // Deletes the current local branch

– git checkout -b fix/248 // Recreates the local branch again

– git push origin fix/248 --force // Overwrites the branch by deleting my previous commits to fix/248 and push the latest code into the same Pull Request (as it has the same name and origin) and ignores the warning with --force

This is normally not recommended for one reason: You’ll also overwrite other people commits, but as I was the only person working on this branch, then only my commits are the ones being overwritten.

 

Code bits: Multi-line statements

Trying to make some changes to issues like this one [ #15438 ] I kept receiving this error message from the pre-commit linter:

error Line xxx exceeds the maximum line length of 140 max-len

There are multiple times where you’ll need to use more than 140 characters, and the way to avoid this error is by using multi-line statements:

translate( 'a very long string' +
'other parts of the string' +
'even more strings'
);

Contributing to Open Source & wp-calypso

Not only the jump from “vanilla” PHP and Javascript to React/Redux has been a big deal for me, but also how I use Git and GitHub in a project that requires more than one person (myself ), as that was the only experience I had until the moment with personal projects, or filling/testing bug reports for some of our products at Automattic.

• How to create a pull request and how to do it properly?
• Which are the guidelines or conventions to follow that makes everybody’s life easier?
• How to tag and label issues accordingly, so the right people/team can filter through.
• How to set reviewers for your code.
• There’s other commands you’ll need to use besides push, pull, add and commit.
• What is CircleCI.
• How to fix conflicts with the base branch. What is rebase? And cherry-pick? What about squash?
• What happens after the PR is approved and merged? How to deploy? Shall I do that? What happens if things go south?
• Is my code tested properly?

 

These are only a couple of new things I’ve learned lately, and has been tremendously beneficial and helpful when trying to reach the objective of closing the knowledge gap between theory and how code is used in “real life”. Also thanks to some experienced colleagues (Like Igor and Andrija) that were happy to help with my newbie questions

I’m pretty happy that some of these Pull Requests had been approved and merged into Calypso, definitely learned a lot in the past weeks trying to contribute to the project and looking forward to keep doing so.

A Day in the Life of a Happiness Engineer

This post is part of a series describing what Automatticians do on a daily basis. You can read more posts like this by following the tag #a8cday on WordPress.com and Twitter. There’s other colleagues that also write theirs here!

7:00 – I wake up at Koh Pha Ngan, an island in Thailand, depending on the day I go for breakfast and an early swim to the sea, go for some fruit and coffee near by, or just stay at home and have a slow breakfast by the terrace.

Banana, mango and coconut ice cream breakfast

I’m originally from Spain but I’ve decided to spend the winter months in south east Asia, who doesn’t like good weather?

I just had a face-to-face team meetup with my colleagues in Singapore last week, so why not staying around a little bit longer until the cold in Europe goes away? Does that mean I’m on holidays? Nope, I’m working, but I don’t need an office.

Team awesomeness in Singapore

I work at Automattic as a Happiness Engineer. We’re the company behind WordPress.com, Akismet, VaultPress, Simplenote, CloudUp, Jetpack, WooCommerce, … We are a distributed company and each one of us works remotely.

My place for this winter

So, how a normal day looks like for me?

8:00 – I go to a co-working space, a coffee shop or I stay at home, depending on the day. I turn on the computer. For the next five hours I will interact with users of (mainly) WordPress.com via live chat or via email, helping them to solve any issue or question they might have regarding their sites or any related product (domains, plans, purchases, etc, …). I also keep up with the news and updates across the company and hangout with my coworkers via Slack (chat) or Zoom (video), either work-related or not. Each one of us works from a different timezone, country and schedule, so lots are happening all the time even when you’re sleep!

Co-working space by the beach

13:00 – I stop for lunch, that normally takes me around an hour but I might extend it depending on the day. I take it easy as I like to have a coffee afterwards by some terrace, take a nap, read a little, … who knows?

14:00 / 15:00 – I come back to work and use the next couple of hours to close issues I had opened during the day, finish pending bug reports, testing new features, followup with users that I’ve interacted with during the morning, finish reading here and there, etc, …

Iced coffee anyone?

16:00 /17:00 – Normally by this time I’m finished for the day. Now is time to meetup with friends, hit the gym (oh Crossfit you’re going to kill me) or dedicate time to hobbies. I’ve been into coding and contributing to Open Source (for example contribute to WordPress core) lately, so I try to do a little everyday, but is mostly a weekly objective I’ve set for myself

This is how a normal day looks like, however you would be surprised to know that most of the days are not normal! We deploy something new, test new features, we train a new Happiness Engineer (yes, the training is done by your colleagues), we plan objectives for the next week, month, quarter, year, etc, …

Some dinner on a local place

22:00 / 23:00 – By this time I’m at home and ready to watch some show or film and go to sleep, tomorrow will be another day as an automattician.

Does this sound like something you’d like to do? Well, we’re hiring!

I will never stop learning. I won’t just work on things that are assigned to me. I know there’s no such thing as a status quo. I will build our business sustainably through passionate and loyal customers. I will never pass up an opportunity to help out a colleague, and I’ll remember the days before I knew everything. I am more motivated by impact than money, and I know that Open Source is one of the most powerful ideas of our generation. I will communicate as much as possible, because it’s the oxygen of a distributed company. I am in a marathon, not a sprint, and no matter how far away the goal is, the only way to get there is by putting one foot in front of another every day. Given time, there is no problem that’s insurmountable.

Using QUnit for WordPress testing

I’ve been interested in testing and automated testing for a while (one of my gigs when I was freelancing was to create automated tests using CasperJS for WordPress sites) but I couldn’t find the time to research on how unit testing is done on WordPress.

Even there’s a dedicated page for Automated Testing in the core handbook, the information is pretty lacking at the moment (something to work with and fix in the future), so setting everything up was not the easiest task. Looks like the testing is done via two testing frameworks, PHPUnit for PHP tests and QUnit for Javascript tests.

I’ve been playing with Hello Dolly and integrating QUnit into the plugin, so is nothing fancy but just some spaghetti code here and there to make it run.

You can find the plugin code in my GitHub here: Repository

Getting ready for SEA

The first quarter of 2017 I’ll be working nomadic from Singapore (10 days), Thailand (30 days) and Vietnam (15 days). Is not the first time I do this, the last year I did Thailand, Vietnam and Japan for a total of 6 months, but last year I was freelancing (10-20 hours weekly) and this time I’m a full-timer (40h+ a week), so is going to be interesting to compare the both experiences.

Some events I’ll attend:
– 13th February: Talk at Singapore WC about WooCommerce.
– 18th February: WordCamp Bangkok – Talk on how to become a web developer using WordPress.

Personal projects to develop during the Q1:
– Better understanding of JavaScript, React and Redux.
– Regular contributions to WordPress Core.
– Blog more regularly.

30-Day Vanilla JavaScript Challenge

Starting this week, I’m going to do the 30-Day Vanila JavaScript Challenge by Wes Bos. Blogging about it everyday will be a little too much for me so I’d update weekly about how is it going, so far I’ve setup a Github repo so I have accountability on my daily/weekly progress.