How To Also Be Productive Tomorrow: 1 Simple Idea

This very simple idea is one of the best productivity hacks I have heard in a long while. It is so simple to implement and it has the potential to really improve your workflow.

Last night, I was accidentally watching a show in TV, which I normally try to avoid. I usually find it to be a waste of time. But yesterday I ended up watching it anyways, because someone else put it on. In the end of the show, 3 celebreties, one of them a famous and controversial Danish poet, had to come up with a creative ending for the show.

When I’m writing, I make sure to always stop while I’m still in the zone. It makes it a lot easier to get started the next day.

Long story, short. At one point the poet, Jørgen Leth, said something that really resonated with me, but never occurred to me. He said: “When I’m writing, I make sure to always stop while I’m still in the zone. It makes it a lot easier to get started the next day.

Wow! There is a saying that you have to “strike while the iron is hot” and I always assumed that it applied to writing as well. I never questioned it. When I am in the zone, I don’t want to stop. I want to get as much done as possible, while I have the chance. However, getting into the zone has always been a mystery to me. After endless staring at the screen, all over sudden I end up in “the zone” without knowing why. At least sometimes. What if, once I am in the zone, I could just leave a door open for the next day, so to say?

There is a saying that you have to “strike while the iron is hot” and I always assumed that it applied to writing as well. I never questioned it.

Well, that would make it a lot more tempting to sit down and get something done. Imagine that right before you write down that really great idea you have, you postpone it until tomorrow. It will stay in your head and you simply can’t wait to get it “down on paper”. Next morning, you jump right into the zone.

To good to be true?

Why I’m Keeping The Free Version Of WP Pusher

This morning, while taking a run in Las Palmas, Gran Canaria (Yay! Location independence ftw!) I decided to no longer offer a free version of WP Pusher. This was quite a big decision for me and something that has been on my mind for a long time. 4 hours later, during my lunch break, I decided to keep the free version after all. Here is why.

Some Background

Throughout the (short) history of WP Pusher, I have had 3 business models. First, WP Pusher was meant as a Software as a Service business, where users paid a monthly fee to use it. This model was great because it allowed me to do stuff on my own server, instead of having to mess around too much on customers WordPress installs. However, when building the plugin, I kept making it simpler and simpler. In the end I felt like the SaaS model was overkill and decided to rewrite everything to be just a plugin. Business model #2 was a free version, available on WordPress.org and a paid version with some extra features.

Then I got this e-mail:
WP Pusher banned from WordPress.org

There went business model #2.

Business model #3 still involved the free version, but now that it wasn’t allowed on WordPress.org, I had to offer it through my own site. Actually, this wasn’t too bad, since this allowed me to collect e-mails from the people who wanted the free version so I could stay in touch.

Fast-forward to this morning.

For a while, I have been kind of upset with the free version. A lot of people are using it, so maintaining it, answering e-mails and the likes all takes up quite a bit of time. And then one more thing. People love the free version! Actually, most of the users I have been in touch with love the free version so much that they do not upgrade to the paid version. Actually, most people who paid to use the plugin did so from the beginning and never used the free version. There went business model #3. At least that was my conclusion this morning.

Why Keeping It Is A Great Idea

So, even though the conversion rate from “Free” to “Pro” is not as high as I would like it to be, I still decided to keep the free version. These are the “why’s”:

  • I have about 20 times as many people using the free version compared to the pro version. These users provide me with invaluable feedback that also relates to the pro version.
  • Most of the bug reports I have received are from people using the free version. I think that people using the free version are actually thankful that they get to use it for free, which encourages them to submit very detailed and useful bug reports.
  • I get to collect e-mail addresses from users of the free version, which means I can stay in touch with them, get their feedback and tell them about the pro version.
  • People using the free version will potentially talk about it and attract new potential customers. (I don’t know if this is valid as I haven’t tested it.)
  • Even though the numbers are not large enough, I still have people convert from free to pro. I think some people use the free version as a free trial before they decide to go pro.

The Unresolved Case

I am still left with a dilemma. I have concluded that either my free version is too good or the pro version needs to be even better.

Should I make the free version worse or should I come up with a better pro version? In my world, the Push-to-Deploy feature from the pro version is without doubt the best part of WP Pusher, but apparently that (and support for branches) is not enough to convert people from free to pro – in most cases.

The main issue is that the pain-relieve when going from not using WP Pusher to using the free version is pretty large. Somehow, I need to make the pain-relieve when going from free to pro equally large.

Anyways, I am keeping the free version for now because in the end, I think it gives me a lot of valuable feedback and user interaction that I otherwise would not have. It is a dilemma, since worsen the free version just does not feel right. At the same time, the free version was originally meant to be a teaser for the pro version – not a replacement. Personally, I think the pro version is killer. Maybe I need to communicate it better. Or maybe add an extra killer feature that users of the free version simply cannot resist.

I am trying to figure out if I need a business model #4.

3 Cool Things You Can Do With Arrays In PHP

PHP has a wide variety of functions for interacting with arrays. Some of them are more known than others. In this short blog, I will demonstrate 3 cool things you can do with arrays in PHP that you may or may not know about.

Turn variables into arrays

The first thing I want to show is how to use compact() to turn variables into an array. I never heard of it before using Laravel, but now I use it all the time – especially in my controllers when I need to pass variables to a view.

php > $name = 'Peter';
php > $email = 'peter@suhm.dk';
php > $array = compact('name', 'email');
php > var_dump($array);
array(2) {
  ["name"]=>
  string(5) "Peter"
  ["email"]=>
  string(13) "peter@suhm.dk"
}

Turn arrays into variables

The opposite of compact() is extract(), which lets you turn an array into a bunch of variables.

php > $array = array('name' => 'Peter', 'email' => 'peter@suhm.dk');
php > extract($array);
php > var_dump($name);
string(5) "Peter"
php > var_dump($email);
string(13) "peter@suhm.dk"

Implement ArrayAccess

Finally, I want to demonstrate the ArrayAccess interface that comes with PHP. It is really awesome and lets you take arrays to the next level. If you need inspiration, check out the Collection class from Laravel. By implementing ArrayAccess, your objects can be accessed like they were an array, which is pretty awesome.

class AwesomeClass implements ArrayAccess
{
    // Example from php.net
    // http://php.net/manual/en/class.arrayaccess.php
    private $container = [];

    public function offsetSet($offset, $value) {
        if (is_null($offset)) {
            $this->container[] = $value;
        } else {
            $this->container[$offset] = $value;
        }
    }

    public function offsetExists($offset) {
        return isset($this->container[$offset]);
    }

    public function offsetUnset($offset) {
        unset($this->container[$offset]);
    }

    public function offsetGet($offset) {
        return isset($this->container[$offset]) ? $this->container[$offset] : null;
    }
}

// Usage
$awesome = new AwesomeClass;

$awesome['name'] = 'Peter';

Resolving Controllers With Symfony And A DI Container

For a project I am working on at the moment, we are using Symfony’s great routing component. The other day, I had to set up the routes to work together with our controllers and stumbled upon something that I would like to document here.

By adding a _controller parameter, such as ‘PostsController::show‘, to a route, Symfony’s ControllerResolver can automatically resolve the controller class given a request object. The ControllerResolver is a part of the HttpKernel component, and also contains an interface, so you can implement it however you like. In my particular case, I actually needed to resolve the class from my DI container, and only needed the resolver to resolve the arguments of the method. I was not going to implement my own ControllerResolver, so here is what I did instead:

// First, fetch the controller string from the request
// Could be something like 'PostsController::show'
$controllerString = $app->request->attributes->get('_controller');

// Next, split the controller string and pass it to two variables
list($class, $method) = explode('::', $controllerString);

// Resolve the controller class out of the DI container
$controller = $app->get($class);

// And use the ControllerResolver to get the arguments
// of the method
$resolver = new ControllerResolver();
$arguments = $resolver->getArguments(
    $app->request,
    [$class, $method]
);

// Now that we have the class and the arguments, we
// can finally call the controller and have it return a response
$response = call_user_func_array(
    [$controller, $method],
    $arguments
);

How WordPress.org Did Me A Favour

In the beginning of this week, I wrote about my (non-existing) marketing strategy for WP Pusher, and boy, this week has gone by fast. The day after I wrote the blog, Sara Gooding decided to write an article about WP Pusher over at WP Tavern – a popular WordPress blog. I got pretty excited and realised how effective content marketing is. It works even before you start doing it!

In other news, I didn’t quite get the amount of traffic I would have expected from the Tavern. The day of the article, according to Google Analytics, 270 people stopped by my the landing page. Not quite a Hacker News kinda thing, but actually, I was pretty satisfied. See, out of those 270 visits, I got 50 free downloads which is almost 20 %.

Remember how WP Pusher is not allowed in the .org repository?

WP Pusher banned from WordPress.org

Since then, I have asked for people’s e-mail addresses upon download, so I can keep in touch and send them updates. Had WP Pusher still been on WordPress.org, 50 downloads in one day wouldn’t be anything exceptional, but think about it. 50 e-mails in one day. That’s not too bad and hence the title of this post. Maybe WordPress.org actually did me a favour by removing the plugin from the official repository.

To sum up the WP Tavern thing, I did not make any sales (that I could directly relate to the article) and I got roughly 100 downloads (the article was tweeted multiple times in the following days).

Content marketing it all

This week, I have been trying to work out how I am gonna strategically work with content marketing. I have been really busy with my clients, but every morning I have been reading articles, PDF’s and I have been jotting stuff down in a spreadsheet. I have also started a makeover of the WP Pusher Blog. At this point, I don’t think there is a lot of value in sharing the spreadsheet, but here is a recap of the most important things:

Main channel The WP Pusher Blog
Main focus Develop Thought Leadership
Target audience Freelance developers and agencies that work with version control on client projects.
Main Topics Deployment, version control and best practices

I think there is a demand for quality information about these topics, that hopefully the blog can help satisfy. I really believe that great content is the way to go. The article on WP Tavern was highly based on the few posts that are already on the blog, which leads me to an important point: Writers and journalists are busy people with deadlines. The easier you make it for them to write about you and your product, the more likely it is that they will do so. It’s really a great lesson for me that I will keep in mind.

Now that I have a better content strategy for the blog, and a fresh design, I’m ready to start creating some great content. Hopefully, that content will help drawing more attention to WP Pusher and ultimately more sales.

It has been almost a month since I launched and I am quite satisfied with the results so far. If I was still living in Chiang Mai, Thailand, WP Pusher would already pay for my rent and basic meals. That’s not quite the case here in Copenhagen, Denmark.

PHP, sendmail And Mandrill

One of the first things that has to happen when I start working on a new project, is to ensure that mail sending is handled by a third-party service. Preferably something like Mandrill or Mailgun. I have no desire to maintain mailservers, SMTP stuff and what not.

Today I had a challenge, when moving a lot of old code to a new Linode server. Most of the code was sending e-mails through a third party package, and was already configured to send through Mandrill. However, some of the code was still using mail(), so I had to somehow configure sendmail to run on the server, in order to not break the app. Just the name, sendmail, makes my palms sweaty.

In the end, I came up with a really simple solution that can easily run until that code has been refactored.

Step 1: Install sendmail

First of all, we need a sendmail binary. I’m writing ‘a’ and not ‘the’, since multiple Ubuntu packages can provide a sendmail binary. Take a look at this:

$ sendmail
The program 'sendmail' can be found in the following packages:
 * exim4-daemon-heavy
 * exim4-daemon-light
 * lsb-invalid-mta
 * postfix
 * citadel-mta
 * courier-mta
 * dma
 * esmtp-run
 * lsb-invalid-mta
 * masqmail
 * msmtp-mta
 * nullmailer
 * qmail-run
 * sendmail-bin
 * ssmtp
 * xmail
Ask your administrator to install one of them

The ‘trick’ here is to use nullmailer, which is a small program that can only forward e-mails to another MTA (message transfer agent). At least as far as I have understood. Anyways, installing nullmailer on Ubuntu is pretty pain-free:

$ sudo apt-get install nullmailer

Step 2: Configure nullmailer

While installing, you will be prompted for a few options. First thing, you need to provide the fully-qualified host name for the server. You will know better than me what this is! Next thing, nullmailer will allow you to specify a ‘smarthost’ to connect to. Here is the one I used for Mandrill:

smtp.mandrillapp.com smtp --user=[username] --pass=[password] --port=587

If at some point you want to edit this, you can do so in /etc/nullmailer/remotes.

Step 3: Test it out

To test it out, you can try to send a test e-mail from the server. First, create a text file with the e-mail:

# testmail.txt

Subject: Test mail from server

This is a test mail from sendmail.

Now, use sendmail to send the e-mail:

sendmail you@example.com < testmail.txt

You can check you mail queue to see if the message was sent:

$ mailq

And that’s it!

A Content Marketing Strategy For My WordPress Plugin

To me, online marketing is intimidating.

As mentioned earlier, I like to consider myself a devtrepreneur. I love using my technical skills to build products that people wants to use. However, I am no marketer. I do know the basics of marketing, I have a bachelors degree from a business school and I have been involved in many startups, but honestly, I still find it intimidating. It feels like there are so many things to do and everything has to be timed and planned out for it all to work.

Last month, I launched my first WordPress project, a deployment solution named WP Pusher. The only marketing I have been doing, is telling people about it on Twitter, which has been enough to generate the first few sales and free downloads. While building WP Pusher, I thought about marketing from time to time, but I never did much about it, which I guess was because I felt intimidated. Actually, after launching, instinctively I just wanted to move on to the next project, like I have done many times in the past, which would be pretty stupid. I have everything I need in order to start a proper marketing effort. I have a useful product that people really seems to like and a nice landing page.

All of which is why I decided to document everything here.

Sharing the journey

Sharing everything here, is my own way of trying to tackle an intimidating task. By sharing, I will be forced to reflect and evaluate everything I do. In the long run, hopefully, it will lead to feedback and discussions on Twitter or here on the blog.

I will share what I have been doing, both the things that worked, and the ones that did not. I am really busy these days and work +40 hours a week for clients. This leaves me with evenings only to work on WP Pusher. I have to prioritise my time and try not to waste it too much.

The plan

Right now, I do not have a plan. I know I want to focus on content marketing, which I think is a great way of attracting traffic and followers. Here is a list of things I think I need to do:

  • Make a SEO strategy, so I have something measurable
  • Re-launch the blog on blog.wppusher.com, including a content strategy
  • Make a strategy for external content, such as guest posts, reviews etc.
  • Consider paying for content on popular WordPress websites
  • Find a way to get more (@WP_Pusher) followers on Twitter

Probably, one of the first things I will do, is to make a more detailed plan. Preferably, the plan should include a few goals with actionable steps. Stay tuned for this.

If you have any feedback or ideas, please post a comment or ping me on Twitter.

That’s all for now.

Recursively Resolving Dependencies With PHP’s Reflection API (Part 1)

Today’s post have a very long title, even though the actual concept we are going to discuss is quite simple and straightforward. The whole concept of dependency injection can sound very complicated, but it really isn’t.

This is dependency injection:

class UserManager
{
    protected $users;

    public function __construct(UserRepository $users)
    {
        $this->users = $user;
    }
}

The UserManager depends on a UserRepository, which we therefore inject through the constructor. This has some obvious advantages – especially if we make our objects dependent on interfaces instead of implementations. We will get back to this in part 2.

Resolving dependencies

How do we resolve the dependencies of our objects, so we can properly instantiate them? This can be quite cumbersome.

Instantiating an object with its dependencies:

$userManager = new UserManager(
    new UserRepository(
        new EntityMapper(
            new DB(
                new Configuration()
))));

You get the point. The dependencies has dependencies themselves.

We need to automate this, and actually, automatic dependency resolution is a core part of modern PHP frameworks such as Laravel. Lately, though, I have been working on several legacy codebases (I consider WordPress legacy as well), where some sort of automatic resolution comes in very handy. In legacy projects, oftentimes there is no easy way to access different objects across the codebase (global variables, I’m looking at you!). Implementing some sort of service container that can help me resolve services and their dependencies is always one of the first things I do. And the good news is, with PHP’s reflection API, this is not too hard to implement.

Here is what the PHP documentation says about reflection:

PHP 5 comes with a complete reflection API that adds the ability to reverse-engineer classes, interfaces, functions, methods and extensions.

In short, the reflection API gives us an easy way to gather information about our classes and objects (including their dependencies), which is exactly what we need to implement our own dependency resolution mechanism.

Ultimately, this is what we want:

$userManager = $container->resolve('UserManager');
// UserManager instance, including all nested dependencies

Let’s see some code:

class Container
{
    public function resolve($class)
    {
        // Reflect on the $class
        $reflectionClass = new ReflectionClass($class);

        // Fetch the constructor (instance of ReflectionMethod)
        $constructor = $reflectionClass->getConstructor();

        // If there is no constructor, there is no
        // dependencies, which means that our job is done.
        if ( ! $constructor)
            return new $class;

        // Fetch the arguments from the constructor
        // (collection of ReflectionParameter instances)
        $params = $constructor->getParameters();

        // If there is a constructor, but no dependencies,
        // our job is done.
        if (count($params) === 0)
            return new $class;

        // This is were we store the dependencies
        $newInstanceParams = [];

        // Loop over the constructor arguments
        foreach ($params as $param) {

            // Here we should perform a bunch of checks, such as:
            // isArray(), isCallable(), isDefaultValueAvailable()
            // isOptional() etc.

            // For now, we just check to see if the argument is
            // a class, so we can instantiate it,
            // otherwise we just pass null.
            if (is_null($param->getClass())) {
                $newInstanceParams[] = null;
                continue;
            }


            // This is where 'the magic happens'. We resolve each
            // of the dependencies, by recursively calling the
            // resolve() method.
            // At one point, we will reach the bottom of the
            // nested dependencies we need in order to instantiate
            // the class.
            $newInstanceParams[] = $this->resolve(
                $param->getClass()->getName()
            );
        }

        // Return the reflected class, instantiated with all its
        // dependencies (this happens once for all the
        // nested dependencies).
        return $reflectionClass->newInstanceArgs(
            $newInstanceParams
        );
    }
}

With the resolve() method, we can achieve something like this:

php > $userManager = $container->resolve('UserManager');
php > var_dump($userManager);
class UserManager#7 (1) {
  protected $users =>
  class UserRepository#10 (1) {
    protected $em =>
    class EntityMapper#13 (1) {
      protected $db =>
      class DB#14 (1) {
        ...
      }
    }
  }
}

This works because of the recursive behaviour of the method. According to Wikipedia, recursion:

… refers to a method of defining functions in which the function being defined is applied within its own definition.

The above definition basically means that a function calls itself. In our case, the resolve() method calls itself with each dependency it discovers as a parameter. We do not want dependencies to depend on each other, in which case we would have a recursive loop that would never end. Object #1 would require object #2 that would require object #1 and so on. Dependencies should only go one way, so we know that our recursive dependency resolution mechanism will eventually hit the bottom of the dependency tree.

That was a lot of fancy words for a simple concept, but I hope you get the idea. The PHP reflection API is fun to play around with and indeed very useful. In the next part, we will take a look at how to allow binding of actual implementations to the service container, so our code can rely on interfaces instead.

How I Stopped Wasting My Time On Facebook

It’s been almost a month since I unfollowed everyone on Facebook. This is how my feed looks now:

My empty Facebook feed!

 

Now, my only ventures to Facebook are for messages and group conversations. All the noise is gone. If I have the desire to stalk someone, I have to make a conscious decision to type in their name in the search box. More often than not, I don’t bother. To me, staring at that “No posts to show” message, every time I visit Facebook, has been such a relieve.

How I did it

It’s a step-by-step process and, honestly, it’s been super easy.

  1. Every time you log onto Facebook, you go through your feed post by post and unfollow whoever posted it. As many as you can handle. Don’t distinquish between people (and pages, groups etc.). Unfollow everyone who posted something. Remember, you can always follow them again if you change your mind.
  2. Repeat!
  3. When you see the “No posts to show” message the first time, you are getting closer. It won’t stay there, since some of your friends post very infrequently.
  4. Once in a while, a new post will pop up. Some people never post anything, but will be tagged in updates and pictures once in a while. Actually, you will soon discover that most of the Facebook clutter comes from a very small group of people. This is good news, since it makes the whole process stepwise. You will have less and less people to unfollow and less and less Facebook noise to look at.
  5. After a while, post an update to Facebook explaining what you did. This way, people will know why most of the time you won’t like or comment their stuff. If you do, though, you will have made a conscious decision to visit their profile and actually have cared about them.

That’s it. You will probably never unfollow every one, since some people literally never post anything and disabled tagging of their names. But since you won’t see anything from those people, there is no reason to unfollow them.

Why it works

  • You do it step-by-step
  • You can still visit Facebook as much as you want
  • You can still post updates if you feel like it
  • You can still (choose to consciously) stalk people
  • You can still use messages and groups (the biggest excuse for most people)
  • You can still see if it’s someone’s birthday

Start now. Go to Facebook and unfollow a bunch of people. It feels great and it’s not your responsibility to read everything that people post on their walls.

Hi, I’m Peter

Hi! My name is Peter and this is the first entry on this freshly created blog. It’s not the first time a blog has been created by me. You see. I like to begin new projects and I do it all the time. Sometimes I start blogs on the Internet, sometimes I build online products for myself, or for my clients, or I start businesses that rent out bartenders, or one of a 1000 other things. Actually, most of the times when you meet me, I will tell you that I just started this new cool project. It’s how I work.

Just setting up this WordPress blog, I turned into a project… I even put it on Github.

I’m that thing between a developer and an entrepreneur, which means that whenever I get an idea for a new project, no one is holding me back. A few hours later, I’ll have a website up and running and ask you to retweet it to your followers! I like the term ‘devtrepreneur‘, and I think it describes me pretty well.

Think of those first 3 paragraphs as a disclaimer. This blog will be about all my projects. I think. Hopefully I won’t abandon it too soon, like (a few) of my previous projects. Anywho.

$ whoami

I’m mostly a programmer. I also like to think of myself as a traveler. I’m danish, but in the last 2 years, I think I’ve been more outside of Denmark than inside it. I’ve lived in Morocco and Thailand and traveled to many other countries. I also like the term ‘digital nomad’ and like the idea of combining the two terms:

Devtrepreneur + Digital Nomad = Win?

It’s difficult for me to predict what will happen with this blog, but I expect to be posting about at least the following topics:

  • Programming (PHP and server stuff)
  • Business (Freelancing, entrepreneurship and bootstrapping)
  • Traveling

At least, those are topics that I care about a lot these days.

Since this blog is still pretty fresh, ff you want to know more about me, you could check out some of the following stuff:

I’ll also have an about me section on this website soon.

This post is quite random, but at least the blog now has one post! Thanks for reading it.