Forem: pretzelhands

Build your own PSR-4 autoloader

pretzelhands — Tue, 26 Jan 2021 09:51:14 +0000

You can find the repository for this project on GitHub

If you're anything like me, you've probably wondered before: "What kind of magic makes Composer go?" - You look at the source code of vendor/autoload.php and see it links to yet another autoloader that's called autoload_real.php Then there's a bunch of hashes and it's confusing and eventually you just accept that Composer is magic and you aren't worthy of its secrets.

Today, let's look at how you can build your own Composer. At least the autoloading part. We won't talk about the seven million other features that Composer provides to us aside from that.

Setting up the project

This time, all you need to bring is any kind of PHP installation. Technically it needs to be at least PHP 5.3, but I very much hope that you aren't running anything that old.

As always, we'll start with what we want our project structure to look like

psr-4/
├─ autoloader.php
├─ app.php
├─ src/
│  ├─ Pretzel/
│  │  ├─ RandomClass.php

autoloader.php is going to be what it says. This file will be roughly equivalent to vendor/autoload.php when using Composer.

app.php is going to be our test file where we include the autoloader and try to use our classes.

src/ will contain our application-specific code. The folder doesn't have to be Pretzel. You pick whatever makes you happy.

Our stated goal is to load every class that is located in src/Pretzel. Each subdirectory constitutes a new namespace. So any file in src/Pretzel/Factory has a namespace of Pretzel\Factory.

The magic spice: spl_autoload_register

All we really need to create an autoloader is that function: spl_autoload_register. You can read more details about it in the PHP documentation.

You call it like this

<?php

spl_autoload_register(function(string $class) {
    // Perform unknowable magic here
});

All you need to pass in is a callable of some kind that receives one argument: a string with a class name. You can register multiple of these callbacks too. This is useful if you want to have a few logically different ways to load classes.

After your function is registered, PHP will call it every time a class is used for the first time. This is usually either when you call new on it, or when you use a static function on it. Let's see that in action.

Interacting with spl_autoload_register

I'll set up my autoloader.php like this:

// autoloader.php

<?php

spl_autoload_register(function(string $class) {
    die($class)
}

For now we'll just print the class name that was desired and exit. We also need a class to load, so let's build a quick PretzelFactory. It returns a pretzel emoji from a static method. It's very fancy.

// src/Pretzel/Factory/PretzelFactory

<?php

namespace Pretzel\Factory;

class PretzelFactory {
    public static function getPretzel(): string
    {
        return '🥨';
    }
}

We need to use that class somewhere. This is what our app.php file is for. We'll have to include our autoloader, pull the class in and then call the static method. Something like this.

// app.php

<?php

require __DIR__ . '/autoloader.php';

use Pretzel\Factory\PretzelFactory;

echo PretzelFactory::getPretzel();

When we run our app.php file, this is the result.

$ php app.php
Pretzel\Factory\PretzelFactory

So we get the fully-qualified class name (FQCN) passed to us. Now PSR-4 states that a FQCN name consists of:

A namespace prefix (e.g. Pretzel) that corresponds to a base directory (e.g. src/Pretzel)
Zero or more sub-namespaces (e.g. Factory) that correspond to a directory (e.g. src/Pretzel/Factory)
One class name corresponding to a PHP file with that same name (e.g. PretzelFactory.php)

Some of you might have realized by now, that our FQCN is essentially a direct path to the file we need to load. How convenient!

Loading the appropriate files

To load our file, first we need to turn our FQCN into an actual path. This can be done by replacing every backslash with a forward slash and appending .php at the end. With that, we can already autoload files from a hard-coded base path!

Let's try it out!

// autoloader.php

<?php

function fqcnToPath(string $fqcn) {
    return str_replace('\\', '/', $fqcn) . '.php';
}

spl_autoload_register(function (string $class) {
    $path = fqcnToPath($class);

    require __DIR__ . '/src/' . $path;
});

After adding this, we can just run our app.php script again

$ php app.php
🥨

Great success! This shows you what autoloading boils down to: A fancy way to require a PHP file just in time when it's needed. But if we want to be (reasonably) spec-compliant, we still have work to do.

Right now the path we load from is hard-coded to be src/ but according to PSR-4, every package is free to define its own namespace prefix that maps to a path. This is essentially what you do every time you set up autoloading in Composer

{
    "autoload": {
        "psr-4": {
            "Pretzel\\": "src/Pretzel"
        }
    }
}

So let's try to parse this JSON snippet and use it to load our classes. I'll call it conductor.json, because that's what the logo of Composer depicts, and we're basically a cheap knock-off. 🤪

Autoloading according to configuration

The first thing we have to do is to grab our JSON file and turn it into something we can actually work with (i.e. an associative array). Luckily, PHP has native functions for both of those things.

// autoloader.php

<?php

$configuration = json_decode(
    file_get_contents('conductor.json'),
    true
);

$namespaces = $configuration['autoload']['psr-4'];

// .. SNIP ..

Now, the user is free to specify as many namespaces and base directories as she wants, so we need to check if the prefixed/first namespace is available in our psr-4 associative array. We could use a foreach loop, but we can also make it a bit more efficient using a function called strtok().

// autoloader.php

<?php
// .. SNIP ..

spl_autoload_register(function (string $class) use ($namespaces) {
    $prefix = strtok($class, '\\') . '\\';

    // We don't handle that namespace.
    // Return and hope some other autoloader handles it.
    if (!array_key_exists($prefix, $namespaces)) return;

    $baseDirectory = $namespaces[$prefix];
});

What strtok does is tokenize the string according to a separator. If we pass in the backslash, it will return us everything up to the first backslash, excluding that. To correctly match our configuration, we just add it again ourselves.

For the performance nerds among you this makes sure that we find the proper base directory in O(1) time.

Then we check if this namespace prefix maps to a path in our configuration. If it does, great! If it doesn't, we just return from the function and hope that someone else handles this case. We can't do anything else with it.

The next step is to remove the prefixed namespace from our class name. This is because we know exactly what directory the prefix maps to, and we want to start building our final path from that. We can do this in our fqcnToPath function.

// autoloader.php

<?php
// .. SNIP ..

function fqcnToPath(string $fqcn, string $prefix) {
    $relativeClass = ltrim($fqcn, $prefix);

    return str_replace('\\', '/', $relativeClass) . '.php';
}

spl_autoload_register(function (string $class) use ($namespaces) {
    $prefix = strtok($class, '\\') . '\\';

    // We don't handle that namespace.
    // Return and hope some other autoloader handles it.
    if (!array_key_exists($prefix, $namespaces)) return;

    $baseDirectory = $namespaces[$prefix];
    $path = fqcnToPath($class, $prefix);
});

Once again PHP has our back! We use ltrim to remove the main namespace from the beginning of our FQCN. This gives us the "relative" class, in the same sense as having a relative path. The rest of the function stays the same.

At this point we have a base directory and a relative path going out from that base directory. So the final piece that's missing is trying to require the appropriate file!

// autoloader.php

<?php
// .. SNIP ..

spl_autoload_register(function (string $class) use ($namespaces) {
    $prefix = strtok($class, '\\') . '\\';

    // We don't handle that namespace.
    // Return and hope some other autoloader handles it.
    if (!array_key_exists($prefix, $namespaces)) return;

    $baseDirectory = $namespaces[$prefix];
    $path = fqcnToPath($class, $prefix);

    require $baseDirectory . '/' . $path;
});

At this point we can run our app.php again and see if it works as advertised.

$ php app.php
🥨

Great! So now we can add PSR-4 autoloading configuration to our JSON file just as if it were Composer. Of course, one should probably add some more input validation to this code. Users could forget to specify a \ in their namespace. Or they could accidentally add a / in the base directory. But I'll leave that part to you, dear reader.

Closing thoughts

While this is a simplified example of what Composer does internally, it still shows you the general principles of PSR-4 autoloading and what goes into it. Once you break it down, it's really not as complex as it seems!

The main reason I even got the idea was due to a side project I'm silently hacking away on. I needed a simple way to load in PHP classes that define plugins, and well, here we are.

As always, the entire code for this blog post is available on GitHub.

Cover photo by Henri L. on Unsplash

Building an easily distributable single-file command line app with PHP and Composer

pretzelhands — Thu, 21 Jan 2021 13:59:04 +0000

This post was compiled from two of my Twitter threads. Be sure to follow me to see the new ones first!

In May 2020, Symfony released version 5.1 of their components and included something truly beautiful for us developers: The SingleCommandApplication class. This allows you to define and immediately run a command line app in 32 lines of code. Here it is:

#!/usr/bin/env php

<?php

require __DIR__ . '/vendor/autoload.php';

use Symfony\Component\Console\Input\InputInterface;
use Symfony\Component\Console\Input\InputOption;
use Symfony\Component\Console\Output\OutputInterface;
use Symfony\Component\Console\SingleCommandApplication;

const JOKE_API_ENDPOINT = 'https://official-joke-api.appspot.com/jokes/%s/random';

function command(InputInterface $input, OutputInterface $output)
{
    $topic = $input->getOption('topic');
    $jokeResponse = file_get_contents(sprintf(JOKE_API_ENDPOINT, $topic));
    [$joke] = json_decode($jokeResponse);

    $output->writeln($joke->setup);
    $output->writeln("<info>{$joke->punchline}</info>\n");
}

(new SingleCommandApplication())
    ->setName('Joke Fetcher')
    ->addOption(
        'topic', 't',
        InputOption::VALUE_OPTIONAL,
        'Get a joke relating to a specific topic',
        'general'
    )
    ->setCode('command')
    ->run();

And this is what it looks like when you run it.

Let's examine the app piece by piece.

Dependencies

For building the command line app, we require only a single dependency from Symfony.

$ composer require symfony/console

Once that's installed, you're ready to go!

Setting the stage

The first 12 lines are all setup. We include the autoloader and all classes we need. We also setup our endpoint as a constant so it doesn't become a magic string floating around in our application code.

#!/usr/bin/env php

<?php

require __DIR__ . '/vendor/autoload.php';

use Symfony\Component\Console\Input\InputInterface;
use Symfony\Component\Console\Input\InputOption;
use Symfony\Component\Console\Output\OutputInterface;
use Symfony\Component\Console\SingleCommandApplication;

const JOKE_API_ENDPOINT = 'https://official-joke-api.appspot.com/jokes/%s/random';

👀 Take note of the shebang (#!/usr/bin/env php) on line 1! It enables us to run our helper using ./joke-fetcher instead of having to call PHP specifically (php joke-fetcher).

Defining the command

Our actual command is just a PHP function called exactly that: command. Making it a separate function is a style choice. You can pass a closure directly to the SingleCommandApplication.

function command(InputInterface $input, OutputInterface $output)
{
    $topic = $input->getOption('topic');
    $jokeResponse = file_get_contents(sprintf(JOKE_API_ENDPOINT, $topic));
    [$joke] = json_decode($jokeResponse);

    $output->writeln($joke->setup);
    $output->writeln("<info>{$joke->punchline}</info>\n");
}

In here we fetch the topic that the user can give us, and request our joke endpoint. We then output it with some pretty formatting.

In a real application, you'd want to use a proper HTTP client to do this. file_get_contents/json_decode is just easy for demonstration.

Also you can also learn more about console output formatting in the Symfony docs

Building our `SingleCommandApplication`

This is the interesting part! We create a SingleCommandApplication and immediately use the return value to define various settings.

(new SingleCommandApplication())
    ->setName('Joke Fetcher')
    ->addOption(
        'topic', 't',
        InputOption::VALUE_OPTIONAL,
        'Get a joke relating to a specific topic',
        'general'
    )
    ->setCode('command')
    ->run();

setName is optional. It just improves the output of some pre-delivered options (e.g. --version).

addOption allows us to add a command line flag the user can set. It takes the following arguments:

The name of the option (--topic)
A shortcut for the option (-t)
A "mode" (Is the option is required, optional or boolean?)
A description of the command (used for --help)
A default value (The standard topic of our jokes)

->addOption(
    'topic', 't',
    InputOption::VALUE_OPTIONAL,
    'Get a joke relating to a specific topic',
    'general'
)

If you're using PHP8 already: This is a great place to use named arguments to selectively set options.

However, the optional arguments all have UX implications. It's in your best interest to set sensible values for them.

The second to last line (setCode) sets the code the command line app should run. This can be any kind of PHP callable

💁‍♂️ I like pulling out functions to avoid nesting and improve reusability

The last line (->run()) immediately runs the app we've just made.

And there you have it. You can now run your app and enjoy corny jokes!

If you want, you can also rename your PHP file to remove the .php extension and run it as ./<filename> -- You just have to add the executable flag with chmod!

Making the app distributable

To make our app easily distributable and executable, we'll have to turn it into a PHP archive, better known as a PHAR file.

For this we'll use the ✨ beautiful phar-composer package by clue.engineering

Installing it is a lot like installing composer, if you do it manually. The steps look like this

$ curl -JOL https://clue.engineering/phar-composer-latest.phar`
$ php phar-composer-1.2.0.phar install clue/phar-composer
$ rm phar-composer-1.2.0.phar

❗️ You should always double-check what you're pulling into your shell with curl/wget, but I vouch for this one

Also note, that the version may not be 1.2.0 for you. The package is regularly updated.

Preparing our composer.json

Now we need to add a bin property to our composer.json to let phar-composer know which file is runnable. In my case it's cli.php and it's in the app root folder

{
    "name": "pretzelhands/joke-fetcher",
    "require": {
        "symfony/console": "^5.2"
    },
    "bin": ["cli.php"]
}

As a ✨quality-of-life improvement✨ I also like to add a Composer script called phar that just calls the necessary command for us.

So instead of running

$ phar-composer build

I can run

$ composer run phar

which is more consistent within most of my projects. To add the Composer script, edit your composer.json file and add a new scripts property like this:

{
    "name": "pretzelhands/joke-fetcher",
    "require": {
        "symfony/console": "^5.2"
    },
    "scripts": {
        "phar": "phar-composer build"
    },
    "bin": ["cli.php"]
}

Now you can run it! In my case the joke-fetcher app we wrote above comes out to ~980KB.

💄 For aesthetic reasons you can also rename your PHAR to remove the file extension.

🔥 You can share this app with anyone who has PHP installed and they can just run it with chmod 755!~

Final notes

🤬 phar-composer will complain if phar.readonly is set to off in your php.ini - This doesn't stop it from working. But it advises you how to get rid of the message
💬 For the name of your PHAR file, phar-composer looks at the name prop in your composer.json
🚮 phar-composer won't check if there's already a PHAR in the project directory. It'll just package it in there, making your PHAR twice as big

You need to delete it yourself. You can make this part of the composer run phar script. This is left as an exercise for the reader ;)

Scratching my own itch: Building Notebag

pretzelhands — Sat, 02 May 2020 20:08:03 +0000

Notebag is on Product Hunt! Check it out!

This post was originally published on my personal blog

I was never any good at coming up with ideas. I'm not sure whether you could attribute it to a lack of creativity, my life being "boring" by many peoples standards or whether I've just been satisfied with existing solutions to all of my discomforts and problems.

Well, except for that one thing where I never found a satisfying solution: Note taking. I tried a few different approaches. For a while I would put my notes into my IDEs scratch file feature. That wasn't exactly a very scalable or searchable solution, but it was good enough for storing code snippets in.

For another while I had my writings in Apple Notes. I liked the simplicity of it, but it didn't have support for typing out notes in Markdown, which made formatting cumbersome.

Then I tried note taking wunderkind Bear, which is beloved by many. And for a while I was very happy with it. It has a wonderful set of features and great user experience. Seriously, hats off to the people at Bear. But I still had to reach for my mouse to do things every now and then. And there was still the thing where I had to either open the app on demand or switch around all my open windows with Cmd-Tab. It still felt off.

This entire journey went on for a good year or so. I had fought off the idea of writing a note taking app because I felt
that:

A) It would be super complicated
B) The market for note taking apps is incredibly over saturated

I still believe that the second point holds true to a certain extent. There is certainly a lot of competition out there. But the first point was shattered when I found out about a lovely little thing called tiptap. It's based on ProseMirror which is a wonderful library for building rich text editors.

And on March 7, 2020 I finally got fed up enough to start writing code. (Although there were earlier indicators of what was about to happen).

Development

Notebag is an Electron-based app since I am primarily a web developer and native code seems scary. I would have loved
to give Swift a try, but in the end stuck to what I know best. For the frontend I landed on Vue since that is what Tiptap uses and I don't really hold much of a strong opinion in the great war of the frontend frameworks.

One great thing that allowed development to move quickly is Prosemirrors concept of input rules. These are essentially little functions that take a regex you want to search for and then spit out appropriate HTML for the thing you just entered. This is what powers all of the Markdown formatting as well as a few custom functionalities such as the nestable categories
and Zettelkasten-type links.

For most of March I was still working on this very sporadically as I was pre-occupied with contracting work for most of my week. Sadly due to the world going a bit haywire I ended up having not so much contract work anymore by April at which point I started focusing on the development in earnest.

Within a week or so I had implemented most of the barebones features of a note taking app (funnily enough, switching between notes was one of the last ones. Oops!) And I sent out my first beta builds. At this point the app looked a bit like a boring Apple Notes clone.

This is what I sent out to a few trusted beta testers

Differentiating the app

This was also the time at which I started drilling down on what I consider the unique selling points of the app. At first there is the omnibar or "Go To Anything". This is essentially the same thing as in any modern IDE or code editor.

You have a full fuzzy search for your notes. And this is also where the keyboard focus really took overhand. I spent a good chunk of the next two weeks assigning tabindexes to every important element, writing countless :hover, :active, :focus styles and adding numerous keyboard bindings that you can use to get around the app.

There was lots of talking with beta testers and refining and implementing and polishing. You never expect how much there is to do until you start writing it down and ending up with a todo list in the mid double digits.

How do I even marketing

Once the app reached a reasonably stable level of maturity, I had to get around to the point I am the worst at. The one I had pushed away again and again for as long as I could: I had to build a landing page to market
this thing. Oh dear

The struggles started with naming. In total I went through 27 names before the right one appeared. Some of them were: Keynote, Typemark, Markflow, Swiftnote, Feathermark, Keynib, and Crosskey. The final name wasn't even my idea. The credit for it goes to Shaun Farrugia. But I liked it and it stuck.

Next came logo design. I've always had a certain love for RPGs and I liked the way the old timey bags full of gold looked. It's not a perfect fit for the app at hand, but the design came together quickly and I was quite pleased.

And finally the landing page. I grabbed myself a bit of Tailwind and Jekyll and got to work. For what its worth I still have no idea how marketing experts do it, but I discussed the copy with people, I polished the experience of reading it for the first time, I made sure it looks decent on all the devices I have around and then it got pushed to live.

Since going live it managed to convince three people to get the app, so I guess I'm not doing too bad!

Launching

And here we stand, shortly before the big launch. This is really the first time I have built a proper product of my own and I am excited and also terrified of where the journey goes next. Here's hoping that the name "Notebag" can eventually stand proudly among the big stars of note taking.

Look for the launch on ProductHunt on Monday, May 4! And in the meantime, feel free to check out Notebag at notebag.app!

A recap of 2019 and looking towards 2020

pretzelhands — Sat, 21 Dec 2019 14:15:57 +0000

Photo by Danil Aksenov on Unsplash

This post was originally published on my personal blog

Hey. It's been a while since I've written. It's almost been an entire year and what a year it's been. Since it's almost Christmas and things are quieting down for just a few days, let's take a look at what this year has been and where the next one will go.

Freelancing

This year has been the most successful in terms of freelancing that I've ever had. Most of my year was still spent working with my long-term client, although that relationship is now ending due to legal reasons, that I don't want to type up here. The bottom line is that my contract runs out on Dec 31 of this year.

Either way, it's been a fun time full of neat e-commerce projects and I gained a lot of domain knowledge about fintech and online payments that I'm sure will help me in some fashion in the future. If only because it gives me new insights the next time I have to integrate a payment gateway.

After 1.5 years of working with a big enterprise-y client, I do however have to say that I'm looking forward to a more spontaneous/flexible work environment. When a company comes up on a few thousand employees, there will always be some obstacles and decisions naturally take longer. Also I will not miss the meetings.

2020

The new year will be exciting! For all of January I will be taking a month off. Not only to recharge and maybe pick up some things that I've dropped throughout the year, but also because I have to move. More on that below.

Starting with February, I have found a new opportunity. It comes with decent pay and a flexible contigent of hours, while also being remote. Overall it sounds very great and I'm looking forward to it. Being remote also means I can cut out some time for going places every day. At 3h/day those are significant savings!

And of course I'll stay in the whole e-commerce niche, since that seems to be a quite comfy spot from my current point of view!

Side projects

...

Can we talk about something else? No? Fine. This is the part of the year that got absolutely lost. I had grand plans of working on things in January, but between major life changes and above commuting problems I really had neither the time nor the energy to put into my side projects.

They're all still there, lying in my ~/Projects folder, but most of them have been touched no later than February 2. This is quite painful as its the second time in a row that I've failed to achieve a side project goal.

In 2018 I had set a goal of earning $50/mo from side projects. That didn't work out. In 2019 I didn't even set a goal and just got started working on things. Then I dropped the ball.

Ouch.

2020

I have no grand plans for 2020. I want to ship something, I want to make a product that I can be proud of and that I can call my own. Ideally, by the end of 2020 I want to somehow manage to get $1 into my pocket by the way of having a side project.

Given my new contracting job and a non-existent commute, I think it should be possible. But we shall see. I've also been meaning to rewrite my nginx wrapper in Python instead of Bash. Maybe that's where I can start.

Life changes

Ah yes, personal life changes. This is where things kind of exploded in terms of time spent and effort. But it all had an outcome that is very positive. So!

In 2019 I got married to my girlfriend and now-wife of 4 years. She also moved here to be with me. This would've been quite the event on its own if not for the fact that we used to be a short jump of 10,000km (~6,200 miles) apart.

Together with all of the visa restrictions that my country imposes and the fact that we had guests from her country coming by as well it turned out to be quite the adventure. Really, this is where the first half of my year just vanished.

Either way, all things worked out well and we managed to make it happen!

2020

As for the new year, we have a big move right at the start. I've always been a person who has lived in the rural countryside in small towns that were at best about 5,000 people big. This will change as we're moving smack dab into the middle of the second-largest city of Austria.

Packing all of our stuff is not so fun, but the prospect of the move is very exciting! It'll be a totally new experience for me to live in a decently-sized city along with all of the benefits and drawbacks that might bring.

Closing

I'm still a bit blurry about what my 2020 will actually look like with a new place and a new job, but I'm also very excited about the possibilites that will bring.

Here's hoping that your year was a great one and that the next one will bring you lots of good luck!

Managing WordPress from your terminal

pretzelhands — Tue, 29 Jan 2019 21:08:07 +0000

Photo by Luca Bravo on Unsplash

This post was originally published on my personal blog

Hi, I'm Richard. I'm addicted to WordPress.

...

Oh, this isn't the support group? Fine. But nevertheless, let me tell you about a humble command-line tool called wp (or WP CLI). It is by far my favorite way to manage WordPress installations and saves me from having to click through the Dashboard approximately 95% of the time.

Installation

Getting wp installed isn't much of a hassle. If you already have Composer installed it's a breeze. You need only require the package and you're done.

I usually have wp installed globally because I manage a lot of WordPress sites:

composer global require wp-cli/wp-cli

But of course you can also just require wp for a project locally:

composer require wp-cli/wp-cli --dev

If you don't have Composer installed, there's also some alternative installation methods. Feel free to pick the one that best suits your workflow.

✨ Congratulations! Your life just became a whole lot more efficient!

Installing WordPress from the command-line

Now to see just what you can do with wp, let's install WordPress and configure it. All done from the cozy comfort of your shell. The very first thing we need to do is to download the latest version of WordPress.

$ wp core download

Downloading WordPress x.y.z (en_US)...
md5 hash verified: 83bec78836aabac08f769d50f1bffe5d
Success: WordPress downloaded.

That wasn't hard at all, was it? Now let's setup our wp-config.php with all the necessary information. For this you can run the following command

$ wp config create --dbname=wpdemo --dbuser=root --dbpass=root

Success: Generated 'wp-config.php' file.

Of course you should replace the above database information with your own. The next step is to actually run the WordPress installer. That looks a bit like this

$ wp core install \
          --url="https://wpdemo.test" \
          --title="WordPress Demo Site" \
          --admin_user="pretzelhands" \
          --admin_password="awesome-p4ssw0rd" \
          --admin_email="hello@pretzelhands.com"

Success: WordPress installed successfully.

And you're done. You can now visit the URL of your WordPress site and take a look at your wonderful new installation!

That's a lot of parameters to remember. But never fear, wp is here! Until you remember all these parameters you can also run wp config create --prompt and wp core install --prompt. These commands will interactively ask you for all required parameters. Nifty!

Now let's talk about some other awesome features you might want to have.

Installing plugins

Check! Grab the slug of a plugin and you can run the following command:

$ wp plugin install advanced-custom-fields

Installing Advanced Custom Fields (x.y.z)
Downloading installation package from https://downloads.wordpress.org/plugin/advanced-custom-fields.x.y.z.zip...
Unpacking the package...
Installing the plugin...
Plugin installed successfully.
Success: Installed 1 of 1 plugins.

$ wp plugin activate advanced-custom-fields

You can also pass in a --activate flag to activate the plugin immediately. This looks like

$ wp plugin install advanced-custom-fields --activate

If you don't know the slug of a plugin you can find it by going to the plugin repository, searching for your plugin and then checking what it says after the last slash.

For example the URL for the Advanced Custom Fields plugin looks like this: https://wordpress.org/plugins/advanced-custom-fields If you check everything after the last slash you can see the slug is advanced-custom-fields. This is what you pass to wp. It may take some time to remember what slug each plugin has, but you'll remember your favorites soon enough!

Installing languages

I hail from a German-speaking country. If I hand over a WordPress site with an English dashboard to a local client, they'll probably look at me weird. Thankfully, installing languages with wp is a breeze.

$ wp core language install de_DE --activate

Downloading translation from https://downloads.wordpress.org/translation/core/x.y.z/de_DE.zip...
Unpacking the update...
Installing the latest version...
Translation updated successfully.
Success: Language installed.
Success: Language activated.

And you're done! Go grab some tea or coffee and enjoy your success. The --activate flag here works the same way it does with plugins.

Installing a theme

By now I'm sure you've figured out the pattern. But here's how you install a theme and activate it

$ wp theme install storefront --activate

Installing Storefront (x.y.z)
Downloading installation package from https://downloads.wordpress.org/theme/storefront.x.y.z.zip...
Unpacking the package...
Installing the theme...
Theme installed successfully.
Activating 'storefront'...
Success: Switched to 'Storefront' theme.
Success: Installed 1 of 1 themes.

And now you have Storefront for WooCommerce installed and running. Yes, that's really all there is to it.

Closing notes and further reading

The three examples given above showed you the most common use cases for wp, but you can manage pretty much anything with it. Here's a short excerpt of what you can do without ever touching the WordPress dashboard

Manage users
Create, update, delete your posts
Create, update, delete and moderate comments
Do a search-replace in your database
Export and import WordPress data
Manage multi-site networks
Scaffold code for custom post type, taxonomies, child themes, etc
Run a custom PHP shell for your WordPress install
Run a local development server for your Wordpress install
... (The list does go on for a while longer)

And if you install WooCommerce for example you get another set of commands related just to managing your online store.

So if you're working with WordPress, especially if you're working with more than 2-3 sites I heartily recommend you go out, install wp and get more free time out of your day.

If you want to read more, you can check out the documentation, it is an excellent reference. Otherwise, a lot can be found out by running wp help and browsing the man page.

Enjoy!~

My planned side projects for 2019

pretzelhands — Thu, 24 Jan 2019 20:33:14 +0000

Photo by NordWood Themes on Unsplash

Originally published on my personal blog. The topic of today's post was voted on by Twitter. It's a mix of the top two choices.

It's 2019. New year, new me, new possibilities! At least that's what many of us want to get out of it. As for me, I have a simple goal. I want 2019 to be more successful than 2018. Given how that went, that is tall enough order on its own.

For me 2019 should be the year where I focus on establishing a bit more freedom from the normal hustle. At this point in time I work an amount that is probably not healthy in the long term. I sleep a lot less than I should. And that is not something I want to or even can keep up in the long term. 5-6 hours of sleep and coffee a good combination does not make.

Instead, the focus for 2019 should be on side projects and growing an audience. You've probably been seeing this quite a bit in January already. I started a blog, I've rebuilt a previous one-day build of mine, I've gotten back into the Twitter game and I'm trying to take up streaming more regularly again.

But what are the projects I'm building? Well, ideas may randomly pop into my head at all times, but the ones that follow I'll try my hardest to focus on right now. Enjoy a curated tour of my brain

💵 How Much Does This Meeting Cost

URL: howmuchdoesthismeetingco.st

This one's a biggie. In the middle of 2018 I built a little site called howmuchdoesthismeetingpay.com. It was meant as a half-joke because I'd been sitting in a lot of meetings and wanted to know how much money actually came from that. So I built a little counter on a nice sunny Saturday and put it online. It actually did pretty well on Product Hunt and people were into it!

But there was one request that came again and again:

Richard, I want to use this with my team. Can you add that?

Well, I got side-tracked by a very lucrative contract but yes. Yes I can. So I put a new prototype version of it online and I'm currently hacking away on adding user accounts and billing.

The game plan

The idea is to extend this project into more than a simple cost tracker. I want it to be a tool that can be used to track your meetings from start to finish: Meeting notes, action points, participants tracking, statistics. I want meetings to be as transparent as possible.

Why? Because I think a lot of meetings are just utterly frustrating and unnecessary. If this were more visible, perhaps companies could cut down on wasting precious time and get back to delivering value to their customers.

Yes, this is supposed to be a paid service.

I'll also try to livestream most of the development.

✨ jinx

URL: GitHub respository

I accidentally a popular repository. For what it's worth: before I started building jinx I was heavily in the camp of Caddy server converts. But due to some unfortunate circumstances I was forced to move over to nginx in a pinch. And because I got sick and tired of ^R-ing for the same four commands I wrote a wrapper script.

Then I put it on dev.to and people loved it. Then I marketed it on Twitter and people loved it. And here we are.

The game plan

I want to make jinx as useful as it can be for the largest number of people. Some of the more immediate features I want to add are HTTPS support and improved templating for server configurations.

Ideally this eventually becomes flexible enough to support some sort of plugin functionality so that people can add their own features and ideas! For now, however, everyone is welcome to make a pull request.

And no, I haven't gone back to hosting my sites on Caddy yet. 🤓

📝 Blogging about everything

URL: pretzelhands.com

I was inspired by Swizec Teller to pick up blogging and try to write 200 words every day for a few weeks. Well, I'm not good at keeping posts short, but I decided that 200 words/ day or 800-1000 words/week doesn't matter all that much.

What does however matter is keeping up the habit. And I've done pretty nicely on keeping up the habit so far. I've also found that blogging has immensely increased my audience size in a very short period of time.

Generally I publish posts on my blog first and then crosspost them on dev.to for maximum reach. This has been successful enough that my dev.to audience is actually about to outgrow my Twitter audience. Within less than a month. Woops! 😅

The game plan

My blog is both a project I take to to get wild with programming and to grow my online presence. The engine is hand-written from scratch in PHP with a bunch of loose libraries thrown in. I want to extend it bit by bit to turn it into something I love using.

Ideally, this can also help me supplement my freelance leads in an organic way. Because while the overarching goal is to be less-dependent on a 60hr/week hustle, I will still need to make money to survive.

🤵👰 Getting married

This isn't really a side project, but it does take up a good chunk of my time and it's probably the personally most important thing to me on this list.

In May I'm getting married to my wonderful fiancée and she will come to live with me. It's been 3.5 years of a long-distance relationship with 10,000km between us at this point and I'm already looking forward to having her around. I've actually taken off all of May in anticipation for it.

And I'd love to invite all of you, but I can't host some 1,000 people in my backyard.

Wrapping up

These are my goals for 2019. I hope to achieve at least some income out of How Much Does This Meeting Cost by the end of 2019. I don't care if it's $5/month or $500/month. But earning real money from a side project is something I've been wanting to do for a long time. So it's about time I just sat down and shipped something.

If you want to follow along:

Talk to you soon!

Live streaming as productivity multiplier

pretzelhands — Sun, 20 Jan 2019 21:04:06 +0000

Photo by Nikita Kachanovsky on Unsplash

This post was originally published on my personal blog.

There's probably a few of you who know some form or another of this meme

Sometimes this is very much me when it comes to side projects. Don't get me wrong, I love building side projects and really want to get as many things out there as possible. But sometimes the rabbit holes of the internet can be crazy deep and what starts out as a quick check in the documentation can end up in hours of reading about some esoteric programming language you'll never make use of.

I admit that I might have a bit of a procrastination problem. It happens to the best of us.

But there's a nice way to fight it and share with other people at the same time: Live streaming while you code. This has been a thing for a while now, but especially since shipstreams.com by fellow Austrian programmer Armin Ulrich showed up, there's been a bit of a boom around it. And I joined in back when it first started.

Turns out streaming is a bit like pair programming on demand but with more of a social factor. Having someone watch you and help you when you're stuck is like a super power. At the same time you get to talk about what you're doing and interact with people who are actually interested in what you're doing feels both incredibly humbling and motivating.

Generally there's only like 4-5 people at any one time watching my stream, but knowing that they are spending their free time to see me code makes me a lot more focused and prevents me from accidentally wandering off on tangents of non-productive behavior. In the end it's a bit more exhausting than coding by yourself, but it also feels like I get at least twice as much done in the same time.

Also whenever you find an error you will be doubly invested to fix it and to keep things moving along. Yes, your code might not always be super pretty while you're live, but at least you get stuff done! And sometimes that's the important thing. You can fix code that has been written, but you can't do anything with code that does not exist.

So if you ever find yourself in a creative rut, give streaming a shot! Set up an account on Twitch and Shipstreams, learn how to set up your PC/laptop for streaming and off you go! It doesn't have to be perfect, it doesn't have to be ultra professional. People will be happy enough to watch you either way. It's great fun and maybe you can learn a thing or two.

And for a shameless plug: You can follow me on Twitch to see when I go live. I'd love to chat with all of you!

I am a full-time freelancer aged 21. I work mostly in PHP and React. Last year I made approximately $75,000 in revenue. AMA!

pretzelhands — Wed, 16 Jan 2019 19:55:48 +0000

Okay. That title sounded a bit more braggy than I wanted it to. So if you clicked, I hope I at least garnered your interest.

If you want to read the journey in detail, you can check out my post on how I got into freelancing. To give you a hint: It involved more luck than I had any right to have and I made some very stupid decisions.

The starting point of my freelance journey was a bit more than two years ago at the tender age of 19. It's been a lot of ups and downs since then, but especially since Q1 2018 I haven't really had any downs.

I'd be happy to answer any questions you might have regarding freelancing, regarding my chosen tech stack, my previous work and really anything else you might have in mind. As long as I have something to say about it, I'll be glad to tell you.

You can also find some extra tidbits about me on my profile. :)

Looking forward to your questions!

Breaking the rules to keep programming fun and experimental

pretzelhands — Tue, 15 Jan 2019 19:03:59 +0000

Photo by Ashim D’Silva on Unsplash

This post was originally published on my personal blog.

You probably have processes at work. Style guides for writing your code. Unit tests and integration tests verifying each piece of functionality. Best practices established in the project over a commit history in the thousands. The sacred rules established in your company and by the programming community at large. And following those rules is important for a product used by potentially thousands or millions of users.

But sometimes, in your personal projects, you should try throwing the rules out of the window. Just chuck them out and play around! One such example is the code behind my blog. It's written in PHP without a framework of any kind. It's a loose collection of loose PHP files with a bunch of rewrite rules holding it together. It's basically like a non-polished version of Jekyll.

Here's what the folder structure looks like using tree

blog
├── bootstrap.php
├── composer.json
├── composer.lock
├── lib
│   └── Post.php
├── ps
│   ├── 2019-01-02-coloring-terminal-text.md
│   ├── 2019-01-03-non-obvious-behaviors.md
│   ├── 2019-01-04-command-line-flags.md
│   ├── 2019-01-05-bringing-your-entire-infrastructure-down.md
│   ├── 2019-01-07-jinx.md
│   ├── 2019-01-09-how-i-got-into-freelancing.md
│   ├── 2019-01-12-mentoring-junior-team-members.md
│   ├── 2019-01-14-building-responsive-email-with-mjml.md
│   └── 2019-01-15-breaking-the-rules.md
├── public
│   ├── assets/ (images etc.)
│   ├── blog.php
│   └── index.php
├── vendor/ (dependencies)
└── views
    ├── base.mustache
    ├── blog.mustache
    ├── listing.mustache
    └── partials
        ├── about-me.mustache
        ├── description.mustache
        ├── header.mustache
        ├── newsletter-form.mustache
        └── title.mustache

The public folder is what gets exposed. The ps folder contains all of my posts written in Markdown with frontmatter. The lib folder holds the class responsible for loading posts.

Internally a URL like https://pretzelhands.com/posts/jinx gets rewritten to https://pretzelhands.com/blog .php?slug=jinx. I then search the files to match the correct one based on the slug. I parse the post date from the title. All of that happens in a Post class. Before that the code was directly in blog.php along with some nasty mixed up HTML.

Here's what that looked like

Is it ugly code? Unbelievably so. Was it fun to write? You bet! The entire blogging system was running in an hour or two on a Sunday before going back to work. I didn't want it to be pretty, I just wanted to get it out there. And whenever some code becomes unbearable to look at some selective refactoring happens.

And I love hacking on this thing. I bolt on some code, upload it to my server and call it a day. There's some globals running wild, there's code duplication, there's all sorts of stuff I would get yelled at for during a code review. But no one will ever see the code for my little blog, so I'm totally okay with doing this. It's my own messy little playground. I keep adding to it and see what sticks.

So if you're ever working on a small project of your own that isn't intended to be The Next Big Thing™, why don't you just go all out and write code as if you're throwing color at the wall? It's incredibly therapeutic, I tell you!

Here's an example from a project didn't see the light of day

require_once('../../server/bootstrap.php');

use Respect\Validation\Validator;
use Carbon\Carbon;

$database = getDatabaseConnection();
$emailValidator = Validator::email();

if (!isset($request->email) || !$emailValidator->validate($request->email)) {
    sendResponse([
        'error' => true,
        'errors' => [
            'Please provide a valid email for logging in.'
        ],
        'errorFields' => [
            'email'
        ]
    ], 400);
}

There's no standardization to any of this. The sendResponse function was a little wrapper that just sent a few headers, serialized the array into JSON and echoed it all. $request is just the STDIN PHP provides wrapped in json_decode It's beautiful in its ugliness.

Disclaimer

This does not mean I think you should write production code as if you're some abstract artist and ignore all rules and conventions at work. Those conventions usually have good reasons behind them. But I feel like if you're programming for your own enjoyment it helps to be more creative and experimental. To get rid of rigid structures. Who knows, maybe you find something you really like and can refine and improve.

So don't go around and tell people that Richard gave you the permission to write spaghetti code. 😁

Enjoy!~

Building responsive email with MJML

pretzelhands — Mon, 14 Jan 2019 20:23:18 +0000

(Photo by Joanna Kosinska on Unsplash)

This post was originally published on my personal blog.

So I assume that if you're reading this article, you belong to one of three categories of people: The type which has never built HTML email but wants to get into it, the type which has built HTML email before and wants to find a better way to do it and then the type who just reads everything I write for some reason.

If you count yourself among those that have never built an HTML email before, count your blessings. The amount of work that has to go into these magical creations can be absolutely mind-numbing. HTML email is like the Wild West of web technologies.

I wish I was kidding about this, I really do. Building HTML email was one of my responsibilities at my first job before I got into freelancing and I feel like in those three years I aged by at least a decade. The amount of tiny, obscure things you have to remember is incredible. An affront to everyone even. We're talking inline styles, table layouts, transparency hacks, and so and so forth. And funnily enough Google, the company responsible for one of the most advanced browers, is one of the worst offenders.

No really, here's a list of CSS support in email. Be sure you sit well before reading it. It's a hoot and a half.

Of course for a while now there's been solutions like Foundation for Emails, emailframe.work and many others. But they're either terrible to set up or still require you to remember a good few pitfalls in HTML email. But a while ago, thanks to @pugson I learned about one framework that stood above all others.

It's called MJML and it rocks my socks.

It came a bit too late for my mainstay in email marketing, but I still use it for transactional emails. And this is your whirlwind guide to building HTML with it! So let's get started.

Installing and running MJML

Installing MJML is quite simple if you have npm or yarn installed. You need only run the following command and you're good to go.

npm install -g mjml

If you're not part of the web crowd and don't have MJML or if you just want to try it out and save some time, you can also use their online playground. I admit that I mostly use that one, simply because it's super convenient to see your email right next to your code.

To learn how to use the command-line tool in detail, be sure to check out the excellent documentation.

But as quick summary here are the commands you will most likely want to use

# Compile the MJML file and save it to an HTML file
mjml email.mjml -o email.html

# Watch an MJML file for changes and recompile automatically
mjml --watch email.mjml -o email.html

# Minify the compiled HTML to save space
mjml --config.minify email.mjml -o email.html

Building your first email

As an example email to build I will pick one made by yours truly. It's a magic link email I'm using for a meeting tracker app I'm currently building.

It's not particularly complex, so I think it's a perfect fit for a first go at MJML. First, let's take a look at the entire template as it stands and then let's take it apart bit by bit.

<mjml>
    <mj-head>
        <mj-font name="Montserrat" href="https://fonts.googleapis.com/css?family=Montserrat:400,700" />
        <mj-preview>Click the button inside to log into your account</mj-preview>

        <mj-attributes>
          <mj-text font-size="16px" line-height="24px" padding="0px 48px 16px" />
          <mj-button font-weight="bold" font-size="16px" background-color="#8e2de2" />
          <mj-divider border-color="#8e2de2" />
          <mj-all font-family="Montserrat, Helvetica, Arial, sans-serif" />
        </mj-attributes>

        <mj-style inline="inline">
          .link {
            color: #8e2de2;
            text-decoration: none;
          }
        </mj-style>
    </mj-head>
    <mj-body>
        <mj-section padding-bottom="0">
            <mj-column>
                <mj-image
                        padding-top="20px"
                        padding-bottom="20px"
                        width="200"
                        src="https://howmuchdoesthismeetingco.st/assets/logo-hmdtmc.png"
                />

                <mj-divider />

                <mj-text align="center">
                    <h1>Your magic link</h1>
                </mj-text>

                <mj-text>
                    Somebody requested a log in from your account. If that was you click the button
                    below to sign into your account.
                </mj-text>

                <mj-button href="https://howmuchdoesthismeetingco.st/token/abcdefg123456789">
                    Log in now
                </mj-button>


                <mj-text>
                    <br />
                    Have a wonderful day,<br />
                    <strong>Richard from HMDTMC</strong>
                </mj-text>

                <mj-divider />

                <mj-text
                        padding="8px 48px"
                        font-size="11px"
                        line-height="16px"
                        color="#999999"
                >
                    If the button up doesn't work, you can use this link:
                    <a
                            href="https://howmuchdoesthismeetingco.st/token/abcdefg123456789"
                            class="link"
                    >
                        https://howmuchdoesthismeetingco.st/token/abcdefg123456789
                    </a>
                    <br/>
                    Your login link expires after 1 hour. You can request another one at any time.
                </mj-text>
            </mj-column>
        </mj-section>
    </mj-body>
</mjml>

Okay, that was a lot of code and if you're not running yet, I'm proud of you. The most complex part is probably right at the beginning in mj-head, but let's start from the very beginning: the root element.

The document structure

MJML is not unlike HTML or XML. It is after all a markup language that tries to spit out HTML. As such, each MJML document begins with a simple root tag:

<mjml></mjml>

Inside this root element you have the same sections you're used to from a regular HTML document. One head and one body. They're just prefixed with mj. So the standard structure looks like so:

<mjml>
    <mj-head></mj-head>
    <mj-body></mj-body>
</mjml>

The mj-head is a pretty exciting place where you define all of your styling and meta data! It's probably the most fun part of writing an MJML-based email.

The document head

Now let's look at all the weird stuff in the mj-head and demystify it a bit.

<mj-head>
    <mj-font name="Montserrat" href="https://fonts.googleapis.com/css?family=Montserrat:400,700" />
    <mj-preview>Click the button inside to log into your account</mj-preview>

    <mj-attributes>
      <mj-text font-size="16px" line-height="24px" padding="0px 48px 16px" />
      <mj-button font-weight="bold" font-size="16px" background-color="#8e2de2" />
      <mj-divider border-color="#8e2de2" />
      <mj-all font-family="Montserrat, Helvetica, Arial, sans-serif" />
    </mj-attributes>

    <mj-style inline="inline">
      .link {
        color: #8e2de2;
        text-decoration: none
      }
    </mj-style>
</mj-head>

As the very first child of our document head we have a mj-font tag. It takes in a name and an href. If you look at where the href links to, you'll quickly figure out that all this does is load in a font hosted on Google Fonts. Of course, given the state of affairs, not all email clients support this. But some do and they get rewarded with prettier typography.

<mj-font name="Montserrat" href="https://fonts.googleapis.com/css?family=Montserrat:400,700" />

After this we find an mj-preview tag that contains some text. This is an invisible preview text that gets displayed in the inbox of some email clients right below the subject of the email. To give you some context, I'm talking about the light-gray text depicted here (in Apple Mail)

You can use this to tease your subscribers about the content of your newsletter or give a summary of the contents. It's a bit of an art to find text that is just long enough to fill out the entire area, but not too long to be cut off by the email client.

<mj-preview>Click the button inside to log into your account</mj-preview>

Next up is a special one. mj-attributes allows you to set default styling for all MJML tags that you're using. You can of course override these at any time. These just exist so you don't have to repeat yourself over and over again.

Each child of the mj-attributes tag is another MJML tag such as mjml-text or mjml-button. Each of the CSS properties you want to use is defined as an attribute. This may be unusual at first, but you'll get used to it very quickly. There's also a special mj-all tag, which can be used to apply a style to all elements. (A bit like the CSS * selector)

Also note how I define some fallback fonts for the mj-all tag. This is so that email clients with bad CSS support still have at least a somewhat bearable font to look at.

<mj-attributes>
    <mj-all font-family="Montserrat, Helvetica, Arial, sans-serif" />
    <mj-text 
        font-size="16px"
        line-height="24px"
        padding="0px 48px 16px" 
    />
</mj-attributes>

And we wrap up our head component with an mj-style tag. You can use these to write regular CSS and media queries. One special thing to note here is that I added the inline="inline" attribute to my style tag. This makes MJML search for all elements with a class of link and adds a style attribute to it.

<!-- So this element -->
<a href="#" class="link">My awesome link!</a>

<!-- Turns into this -->
<a href="#" class="link" style="color: #8e2de2; text-decoration: none;">My awesome link!</a>

The reason why you would want this is once again rooted in the lack of CSS support in email clients. Many only support only basic selectors like a or h1, while Gmail just takes your style tag and throws it out entirely. Yup. That's actually a real thing that happens. Thanks Google.

The document body

This is where the meat of your email lives. MJML provides many custom tags to make building email as painless as can be. You can find a list of all tags available in the documentation.

I will highlight the ones I used below, starting with mj-section.

mj-section is meant to be used as a row in your layout. Imagine it a bit like Bootstraps or Foundations grid row elements. It offers some vertical spacing by default, but you can of course remove it. If you don't need any special thing like that you can of course also just use a div or table (and yes, I'm serious about the table).

mj-column allows you to define one or more columns in your layout. This way you can easily build a grid layout in your email. To have multiple columns next to each other put them into an mj-section and you're good to go.

An example of a 2x2 grid could look something like this

<mj-body>
    <mj-section>
        <mj-column>Row 1, Column 1</mj-column>
        <mj-column>Row 1, Column 2</mj-column>
    </mj-section>

    <mj-section>
        <mj-column>Row 2, Column 1</mj-column>
        <mj-column>Row 2, Column 2</mj-column>
    </mj-section>
</mj-body>

mj-image is an image. You probably knew that. By default MJML adds some styling to it to make it stand out a bit more, but once again, you can easily change that.

mj-text is a generic text container. You can put any p, h1 or whatever else in there and make it look pretty. If it's just a random blob of text you can also simply put that text in directly as a child.

mj-button is essentially a link that's styled like a button. Pass in href as an attribute and you've got a great call-to-action in less than 30 seconds. If that's not speedy email development I don't know what is.

mj-divider is a bit like an hr, except it's a lot easier to style. In my email template I used it to separate header and footer from the main content.

Styling tags

For each of the tags I named above, you can easily pass in attributes to give them a one-off style that you didn't add in your mj-attributes. For example I used this tag to style my footer text

<mj-text
    padding="8px 48px"
    font-size="11px"
    line-height="16px"
    color="#999999"
>
    Footer text
</mj-text>

If you end up using a set of styles more than once, but it is still not the default style you want, you can also define an mj-class that allows you to pass styles around like Oprah passes around cars.

You need only define the following in your mj-attributes

<mj-attributes>
    <mj-class name="padded" padding="20px" />
</mj-attributes>

Give you class a name and some CSS attributes you want it to use and off you go. Note however that this only works for MJML tags. For regular HTML tags you should make use of mj-style.

Summary

MJML is a great tool that helps you build responsive HTML email much faster than you would otherwise be able to. The predefined components help you get the most annoying parts out of the way so you can focus on the content and layout, instead of fiddling around with CSS hacks.

Of course, no tool is perfect and neither is MJML. So in the end, always be sure to test your email templates with a tool such as Litmus or EmailOnAcid. Just to be sure ;-)

Enjoy!~

My approach to mentoring junior team members

pretzelhands — Sat, 12 Jan 2019 19:50:43 +0000

This post was originally published on my personal blog.

This post is probably a bit of a weird one. I generally don't talk about my soft skills as I hold the opinion that I am an awkward nerd who sometimes can't even keep English and German apart in his head and thus makes hilariously bad code switching a reality.

On the other hand, I've recently found myself doing a lot of mentoring during my hours at $BIGCO that I mentioned in my previous post about freelancing and the people I've been speaking with seemed to be into it.

Things I write here may be complete bollocks, but hey, read the first paragraph again and you'll understand why. I guess this is partly just for me to think things through.

Be patient with everyone

I don't know if you've ever noticed this with other members in your team, but many people seem oddly annoyed when approached with questions by someone. It may be because they dislike being interrupted by others during work, it may be because they don't like being bothered with someone else's problems. But it's always a bit sad to see when someone has a question and the person they ask rolls their eyes or sighs as they get up from their table.

Hence I always, always, always try to be patient. I've had many people come to me for a question that took me all of a minute to show them the answer to. They got unstuck and could happily continue their work and I didn't lose any critical amount of productivity in mine. If a question in your team pops up a lot, write it down on an FAQ page.

And if you ever find yourself losing your train of thought, go and read this post by Swizec. No one will hold it against you if you take a few seconds to write down stuff.

Give them tools to solve the problem

One thing that can be nice to do is to not point somebody directly to a solution unless it's critical to your deadline. But if you have leeway in your project try and show them how they can find a solution themselves. They don't know how to get started with checking where things go wrong in their program? Teach them how to use breakpoints to step through their program! They can't figure out why their flexbox is behaving weirdly? Show them a site like flexbox.help let them describe their goal to you and let them click through it while explaining it to you.

If they really ran into something bigger they'll come back and ask for help again, but if they can figure it out themselves that feels like a huge win that they had independently of you. It gives a sense of confidence and independence.

So show them how to get there, but don't just point at the screen and tell them, they should have, obviously used justify-content: space-between instead of justify-content: space-around. Let them have their own wins.

Pair programming can help a ton

This is of course dependent of the type of person you're dealing with, but sometimes of people feel a lot more confident when pair programming. At times it already helps if you're the duck for their rubber duck debugging. While they speak out loud and explain the code to you, often times things will click in their head.

So if they're open to it and you have a few minutes, sit with them. Let them explain their code, walk through it with them. Sometimes the thought of someone having your back is all that is needed.

Listen to the individual

Of course, all of this varies from person to person. Junior devs that joined your team a week ago will most likely need more hand-holding than one who joined two months ago. Some people don't like somebody looking over their shoulder while they code, and that's fine too. For what it's worth I'll fumble through a docker run command if you just stand their and watch me.

Each person is different and each one requires a different approach to mentoring. But these are some things I found useful in helping others learn. Maybe you can find some use for yourself.

And above all, when a question seems trivial to you but insurmountable to your junior always remember: Once upon a time you were new to programming as well. ;)

Enjoy!~

What are some things you wish your mentor did?

pretzelhands — Fri, 11 Jan 2019 06:20:02 +0000

To those of you who once had a mentor, please take a stroll down memory lane.

Those of you who still have a mentor, please think of your current situation.

Got it? Okay. Now I have a simple question: What do you wish your mentor did better? Should they have been more proactive in helping you? Should they have given you more independence? Should they have bought you pizza every second Thursday?

I unexpectedly find myself in a new senior role with some people to guide, and I want to do it as well as I possibly can. So if you have any input, please go ahead and tell me about it.

Thanks!~

Forem: pretzelhands

Build your own PSR-4 autoloader

Setting up the project

The magic spice: spl_autoload_register

Interacting with spl_autoload_register

Loading the appropriate files

Autoloading according to configuration

Closing thoughts

Building an easily distributable single-file command line app with PHP and Composer

Dependencies

Setting the stage

Defining the command

Building our SingleCommandApplication

Making the app distributable

Preparing our composer.json

Final notes

Further reading

Scratching my own itch: Building Notebag

Development

Differentiating the app

How do I even marketing

Launching

A recap of 2019 and looking towards 2020

Freelancing

2020

Side projects

2020

Life changes

2020

Closing

Managing WordPress from your terminal

Installation

Installing WordPress from the command-line

Installing plugins

Installing languages

Installing a theme

Closing notes and further reading

My planned side projects for 2019

💵 How Much Does This Meeting Cost

The game plan

✨ jinx

The game plan

📝 Blogging about everything

The game plan

🤵👰 Getting married

Wrapping up

Live streaming as productivity multiplier

I am a full-time freelancer aged 21. I work mostly in PHP and React. Last year I made approximately $75,000 in revenue. AMA!

Breaking the rules to keep programming fun and experimental

Disclaimer

Building responsive email with MJML

Installing and running MJML

Building your first email

The document structure

The document head

The document body

Styling tags

Summary

My approach to mentoring junior team members

Be patient with everyone

Give them tools to solve the problem

Pair programming can help a ton

Listen to the individual

What are some things you wish your mentor did?

Building our `SingleCommandApplication`