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 --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 < 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, 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;

            // 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(

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

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.