Geeky Nuggets

Planck 6502, an open hardware extensible retro computer

Sun, 28 Feb 2021 11:32:07 +0100

Retro computing

Going back to the roots of your field can provide new insights into your day to day experience. For me, the roots are located in the 70s / 80s a time when personal computers were much simpler and could be fully understood by a regular person. This is a time when the most popular computers were the Vic20, Apple II and later Commodore 64.

These computers booted in less than a second to a raw basic prompt. To be clear: you turn on your computer, and less than one second later you start programming. How wonderful would that be, in our land of a thousand node dependencies, failing composer upgrades and wrong vagrant configurations?

What to build?

I was increasingly interested in electronics since doing a project for a friend, so I thought to myself “How hard can it be?” Well, as it turns out, quite, but that’s hardly the point right now. The point is: what should I build? I started by building a simple 6502 based computer on a breadboard. I soon realised that if I was to have anything half useful I was going to need the entire breadboard production of China to be delivered to my house. Also breadboard computers are buggy and you can’t move them around because then a cable will come loose and you will spend five hours troubleshooting your code instead.

So I decided I would convert it to PCBs. They are pretty cheap to get delivered from China, but since they take about a month to arrive the rate of iteration is not so great. Better to get it right the first time obviously.

Well I almost did. The first one was very simple, only having a 6502 processor and an 6522 parallel port interface. I interfaced with it from my computer via SPI through an arduino: the 6522 Versatile Interface Adapter can bit bang SPI easily enough. The Arduino Uno/Nano can be an SPI slave easily enough and receive that data. It can then transmit that data to my computer using serial over USB.

That worked fine (after a couple of bodge wires) but was a bit kludgy, having the Arduino sort of hanging there by a few cables.

I then tried to design a single board computer with everything I would ever want on it: serial communication, parrallel port, SPI port(s), i2c port(s), PS/2 port for a keyboard, sound chip, VGA output, etc… The board to house all of this was very big and thus very expensive. Combining this with the previous point regarding getting it right the first time, a single board computer suddenly seemed like not that great of an idea.

The plan

I then decided to build a board with basic circuitry into which other boards that provided actual functionality will be able to plug in. Turns out that already exists and is called a backplane

So backplane it is then. The size limit for this board and all others will be 10cm x 10cm as that it the cheap price limit for most cheap board houses (yes I’m cheap and I like cheap, preferably cheap that works).

Here is the backplane design:

As you can see, it is mostly just slots to plug in the extension boards. The only active components are the clock generation circuit, and some decoding to activate the expansion slots when they are needed.

The rightmost slot is reserved for the CPU card. The CPU card includes some RAM and ROM, which means the computer is already functional with just this single board plugged in, although admittedly it won’t do much in that configuration.

To get the computer to do stuff it’s best to plug in some additional boards.

The initial design includes an IO board with PS/2 port, SPI ports and a parallel port (and LEDs, of course it has LEDs!) as well as a serial board to allow the user to communicate with the computer.

After waiting patiently forever for the boards to arrive, I put it all together and gave it a try. It did not work at all. Of course there were mistakes on the boards, which confirmed the soudness of my choice of not doing one huge board at once. However not all the boards were defective, and the bad ones were quickly fixed with a few wires here and there.

After which, plugging a usb to serial adapter into the serial board, and into a usb port on my computer, I could see the Planck computer doing something!

Here it is running Forth over serial

I am currently working on more expansion boards, such as an LCD board, a sound card, and a VGA card. Stay tuned for more.

For more details about this project, please use the links below:

Mailocal, a simple SMTP server and web interface to debug your emails

Thu, 28 Feb 2019 11:32:07 +0100

Testing emails

The way I used to do it is to have all emails sent to me via a configuration setting in either Symfony or Laravel. This works fine but there can be a significant delay between the moment when the email is sent and the moment it is received, which is annoying. I have heard about mailtrap, which is a hosted service that does more or less what Mailocal does. But I’m not a fan of sending my customers’ info to a third party.

Mailocal

So over a couple of days I developed Mailocal which is a smtp server you run locally, with a web interface to view the emails is has received.

It is built almost fully with PHP (Symfony) with only a light smattering of javascript for the front-end. It works pretty good for the time I spent on it, although I can’t be sure it will parse all emails equally well.

Obviously this is something that should not be run on a production server because I haven’t looked at the security aspects much, but that’s not the use case anyway.

So I hope you enjoy it and let me know if you find any issues.

Mailocal documentation Source code

Stati, a PHP static site generator that works on any existing Jekyll site

Thu, 28 Sep 2017 00:00:00 +0200

Success !

Well it’s been quite a week. Having had an unexpected lull in my contract work, I decided to work on something fun. I use jekyll for most of my static sites, and I quite like it. It’s still a mistery to me why I decided to build a clone of it. But anyway, one week later, here we are. Stati can now build all my ex-Jekyll sites properly. Actually this blog is now generated with Stati!

Architecture

I read this How does Jekyll work blog post that gives a nice high level overview of the jekyll architecture, and I decided to mostly use the same kind of process.

A main Site class holds most of the state while the generation is in progress, with events being dispatched at several steps along the process so that plugins can hook into them and modify the input, the output, or simply monitor the progress of the generation process.

First all files are read, in different manner depending on their type (static files, posts or pages), then they are rendered (again differently depending on their type) and finally they are written to disk at the correct path.

Plugins

At each point in this process, a plugin can come into play to add pages, have them written in different locations, etc…

The first plugin, and the one that is used by most Jekyll sites I know of, is the paginator. In the case of Stati, it basically takes a list of all posts and generates a new html page for each page of posts. The core Writer then takes care of putting it in it’s proper path.

The second plugin is a related posts plugin. For each post it calculates the levenshtein distance of it’s title to all the other posts titles and gets the 10 best matches. Lots of room for improvement here.

Try it now!

So basically that’s it, a fun project that I will probably continue to use and improve. If you’d like to give it a try, you can get the latest release from github and, most importantly, open an issue if you run into a snag!

PS. I just remembered I have a history of doing this kind of thing

UPDATE : Just got some documentation online

Processing custom events in kernel.terminate

Fri, 25 Aug 2017 00:00:00 +0200

What is the kernel.terminate event?

It is the last event that is triggered in Symfony, just after the response has been sent to the client (only on php-fpm). This means that we can do some heavy lifting here because our response time is not affected. The client gets the response quickly and our processing will occur afterwards.

The Symfony SwiftMailer bundle does this by default, so we should be ok with emails, but my latest project needs to connect to various APIs on some events, and this takes quite some time.

In this post I will explain the method I use to make them run in the kernel.terminate event.

For a primer about Symfony events, I recommend the official Symfony documentation

Custom events

Custom events are trigerred from our own code, generally in the controller, and it goes something like this:

/** 
* @var $dispatcher \Symfony\Component\EventDispatcher\EventDispatcherInterface 
*/
//Get the event dispatcher from the container

$dispatcher = $this->get('event_dispatcher');
//Create our custom event

$event = new NewUserEvent($user, $request);
//Dispatch the event

$dispatcher->dispatch(AppEvents::NEW_USER, $event);

The event subscriber

Then we have an EventSubscriber that will listen to our custom events, in my case it’s called ApiSubscriber and is located in src/EventSubscriber. In this case it listens to two different events: AppEvents::NEW_USER and AppEvents::DELETE_USER.

class ApiSubscriber implements EventSubscriberInterface {

    protected $container;

    public function __construct(\Symfony\Component\DependencyInjection\ContainerInterface $container) {
        $this->container = $container;
    }

    public static function getSubscribedEvents()
    {
        return array(
            AppEvents::NEW_USER => 'newUser',
            AppEvents::DELETE_USER => 'deleteUser',
        );
    }

    //...

}

Configure the service

You will notice that I inject the container as it makes it easy to get everything we need, such as parameters or other services.

Don’t forget to configure the event subscriber in app/config/services.yml like so:

services:

    api.subscriber:

        class: AppBundle\EventSubscriber\ApiSubscriber

        arguments: ["@service_container"]

        tags:

            - { name: kernel.event_subscriber }

Now our event subscriber is ready for action whenever we trigger the event from our controllers.

Handle your custom event

The event handling function is where the magic happens. Say when a new user is created, the AppEvents::NEW_USER is triggered and the ApiSubscriber::newUser function is called.

Here it is, I’ll explain later

public function newUser(NewUserEvent $newUserEvent)
{
    // Get the request from our custom event

    $request = $newUserEvent->getRequest();
    // Add custom attributes to the request, so we can retrieve them later in the kernel.terminate event

    $request->attributes->add([
        'user' => $newUserEvent->getUser(),
        'thing_api_key' => $this->container->getParameter('thing_api_key'),
        'thing_api_user' => $this->container->getParameter('thing_api_user'),
    ]);
    // Add our custom listener to the kernel.terminate event

    // We will see later what the createThingOnApi static function looks like

    $this->container->get('event_dispatcher')->addListener('kernel.terminate', [self::class, 'createThingOnApi']);

    // This would also work but is not as clean in my opinion

    // $this->container->get('event_dispatcher')->addListener('kernel.terminate', function(PostResponseEvent $event) {

        // Do things on the API

    // });

}

So, from this code it is clear what happens. We first get the request from our custom event, then we set custom attributes on the request (simply because we need to retrieve them later from our static function) and finally we add a new listener (our static function, could also be an anonymous function) to the kernel.terminate event.

Do the job

The final piece of the puzzle is our createThingOnApi static function that will do the real work.

Here it is:

public static function createThingOnApi(PostResponseEvent $event)
{
    $attrs = $event->getRequest()->attributes;
    $user = $attrs->get('user');

    $data = [
        "type" => "newUser", 
        "name" => $user->getName(),
        //...

    ];

    $ch = curl_init("https://api.thing.com/users");
    curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "POST");
    curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode($data));
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
    curl_setopt($ch, CURLOPT_HTTPHEADER, [
        'Content-Type: application/json',
        'Content-Length: ' . strlen($data_string),
        'X-Auth-Key: ' . $attrs->get('thing_api_key'),
        'X-Auth-User: ' . $attrs->get('thing_api_user')
    ]);

    curl_exec($ch);
}

This basically retrives our data from the request attributes, and then make some sort of curl request to an external API.

All done !

Do this and watch your response times go way down (only on php-pfm)

I’m not saying the is the best or even the only method to achieve this, just the one I personally use. the alternative would be some sort of mesasge queue, but it still seems like premature optimisation for an app of this size. If you have other options to achieve this, let me know in the comments on HN.

Profiler results

Timeseries charts with Chart.js

Fri, 18 Aug 2017 00:00:00 +0200

Somehow I always end up having to do timeseries charts. Chart.js is my tool of choice for that task, but I never seem to remember what options to pass and what format the data should have. Yesterday I must have spent 2 hours looking at the docs and trying various things, mostly because it didn’t occur to me to check the last project where I used them, Budgt

So anyway, note to self : this is how you do timeseries graphs in chart.js

const ctx = document.getElementById('chartCanvas').getContext('2d');
const data = {
    // Labels should be Date objects
    labels: [new Date(2017, 08, 16), new Date(2017, 08, 17), new Date(2017, 08, 18)],
    datasets: [{
        fill: false,
        label: 'Page Views',
        data: [280, 250, 340],
        borderColor: '#fe8b36',
        backgroundColor: '#fe8b36',
        lineTension: 0,
    }]
}
const options = {
    type: 'line',
    data: data,
    options: {
        fill: false,
        responsive: true,
        scales: {
            xAxes: [{
                type: 'time',
                display: true,
                scaleLabel: {
                    display: true,
                    labelString: "Date",
                }
            }],
            yAxes: [{
                ticks: {
                    beginAtZero: true,
                },
                display: true,
                scaleLabel: {
                    display: true,
                    labelString: "Page Views",
                }
            }]
        }
    }
}
const chart = new Chart(ctx, options);

And here’s what it looks like:

That’s it. Hopefully I’ll remember I posted this here next time I need timeseries charts in chart.js

Communication between iframes with React and postMessage for an html template editor

Thu, 10 Aug 2017 00:00:00 +0200

I’m working on a project where I need some sort of simple landing page editor, where “blocks” are defined at the template level and they can be rearranged, text changed or added, and not much more. Most of the software I could find was either way too complex for my needs, gave the user the freedom to completely destroy the template, or were otherwise pretty useless.

If it was frustrating for me I imagine how it would feel for my users who need to do this quickly and efficiently. What I needed would’t have drag and drop, nor 300 sliders for everything, neither would it give the user the ability to completely modify the template. (Users can provide custom HTML for their pages if they so choose). Anyway, all I need was the ability to place some template blocks on a page, move them up and down, remove them, and change the text bits.

“How hard can it be ?”
- me, at 3 AM on thursday night.

How hard indeed ? Well, as it turns out, quite. But it’s my fault. Scope creep. I decided it would also be possible to change the images. And also upload them. And maybe add custom buttons. And edit the background images. And the background colors. Anyway, here we are now, and this is how I’ve (almost, anyday now) done it :

I used an iframe to hold the displayed template, as that allows complete style (and everything else) isolation, and gives a good preview of the final result. However, javascript between the iframe and the “controlling” page is not that easy. Because of same origin policy we can’t just tell the iframe to do this or that, or read it’s elements to see the html that’s in them.

“Inter-frame communication is like inter-process communication”
- My buddy who does C (or C++ maybe?)

Oh I forgot to say, I want to store somewhat structured data about the edits, not just the raw HTML, to enable easier further edits if necessary. mobiledoc seemed promising. I spent about an hour investigating it (my internet was slow that day, I swear!) before I realised it’s basically markdown. I thought adapting it to my use case, but it felt futile (as in: too much work). So what was I on about ? ah yes, iframes ! Mmmm who doesn’t love a good iframe? You don’t? Good, ‘cause me neither. Anyway, inter-frame communication is like inter-process communication (or so says my buddy that does printer drivers for HP – Yeah, I’ll curse him on your behalf if you have an HP printer): you have to pass messages around, in our case with window.postMessage(). It works, it’s great!

Anyway, here’s how it works: I like to think of it as communication between say a frontend and an API, mostly because of the asynchronous nature of the communication. So basically, the parent page get ready to receive messages from the iframe by listening to the “message” event, like so:

    window.addEventListener('message', this.handleFrameTasks.bind(this))

I’m using react for the frontend, so this went in the componentDidMount() method, but you could place it anywhere, really, as long as it runs when you want to start editing on the iframe side.

And then on the iframe side I have something like this:

    // Send message to react

    var data = {
        action: 'deleteBlock',
        blockId: blockId,
    };
    top.postMessage(data, '*');

In fact at the start I was JSON.stringify()ing the data I sent, as I remember it being necessary a few years ago, but that’s not required anymore.

Then on the parent React side, the handleFrameTasks dispatches the actions required depending on what the iframe requested. For example in the case above it will delete the page block with id blockId from it’s page data structure.

Did I mention that the iframe content is generated dynamically and injected in the iframe src with a data blob URL? Well then, maybe I’ll post about that the next time.

Until then, keep coding !

PS Oh about that One project per month challenge? This one is bigger than I expected, so it will (has already been) longer than a month. It will be great, I hope. Everything you need for an early stage startup. Contact me if you’d like some more info.

One project per month during 2017. Here are my first two for January and february

Wed, 01 Mar 2017 09:17:07 +0100

So at the start of January I discovered the One Project per Month project, and decided to give it a go. You can follow my progress here and I’ll also try to post here somewhat regularly about my experiences.

The first project was an app that does budget tracking. Well, not really budgeting, more like to track what I was spending. I’ve been wondering where all the money went, and this app was made to help me achieve some visibility about that. It’s great, check it out ! If the queen of england needed a way to track her spending, she told me she’d definitely use it !

Not that you care, but if you did you could go to the github repo and there you might be able to find out that it was made with React, PouchDB and quite a few more nice things.

Anyway, the second project was the February one (that’s what one per month means, for all of you following from your nursing home bed). I wanted to try my hand at native iOS apps. I looked at the Swift docs, installed Xcode but then I saw got bored and saw on hackernews that someone had built an app with react native and liked, so I said to myself : “Jonathan : do the right and be lazy. The important thing is to get this ready before the 28th” (Yes February was limited to 28 days by royal decree this year, and well, most years really… Who knows why ?) Anyway, so since all good programmers are lazy I didn’t feel too bad about myself.

So react-native is was then. Let me tell you, this thing is great ! It works perfectly, you can design stuff with CSS like ease, and all the logic is in javascript. Easy peasy. You can’t get it anywhere though because Apple wants 100€ so that I can upload my free app. But do come by my house and I’ll gladly install it on your phone. If you have an android maybe I’ll just keep for a little while to do a bit of testing. But I’ll give it back. Eventually.

So yes. So far so good. No idea for March though. Maybe I’ll just do a react-native app for the budget tracker

Any ideas ? Contact me.

Building a webGL and webworkers boat hydrostatics app

Tue, 20 Dec 2016 09:17:07 +0100

I’ve recently felt the urge to start designing boats again, as I have had some ideas I wanted to explore, specifically for boats of the Mini 650 class. The software I use has basic hydrostatics capabilities, but only for an upright boat. It cannot calculate the GZ curve, or get the righting moment at specific heel angles, which is a crucial data for the kind of craft I wanted to design.

Existing solutions are extremely powerful and extremely expensive, so I decided i’d spend a few days rolling my own, with only the features I needed for the time being. I have all the technical background for this type of calculations, so I figured it shouldn’t be too hard. I really wanted to display a 3D view of the model, and not have it only output data in table format, and since I had never used web GL and was curious about, I figured it was the perfect time to try it out. Pro tip : if you’re not used to openGL or working in 3D programatically, use three.js. Thank me later.

So at first I built something very basic that just displayed the model in threejs and did some static calculations, in the UI thread. At first it worked ok, but as soon as I added functionality to solve for trim (to align longitudinal center of gravity with the longitudinal center of buoyancy) it started to get very slow. The 3D view could not even be moved around anymore because the UI thread was doing all the calculations in the foreground. Basically to do this kind of calculations, you have to move the model up and down to adjust for the correct displacement, and then pitch it forwards or aft until the center of buoyancy aligns with the center of gravity. This loop is computationally intensive and made everything grind to a halt.

So webworkers to the rescue. I had never really used them either, but they promised to make it easy to send most of the work to a background thread that would not slow down my UI. I refactored my code to put all the heavy lifting into separate files that could then be called as a web worker. I also had to add messaging to pass data to and from the UI javascript. That was fairly easy to do, as they are simple calls to postMessage, and a callback function in the UI and the worker to receive sent messages. Very easy and obvious, so great !

The calculations are accurate, I’ve had them checked in many cases against an old Hydromax version, which is an established solution in the field, and the results match within about a percentage point. The only difficulty I’m still struggling with is to properly draw the underwater stations and the waterline, but this is only a display bug and does not affect the results. What happens is that there are many edge cases that have to be accounted for, depending on the type and quality of the input file. I’m still working on that.

If you like designing boats and currently do these kinds of calculations by hand or in a spreadsheet, or if your current software does not solve for trim, you will definitely want to give this tool a try

If you do, and you like it, or you hate it, or it doesn’t work, or anything, your feedback would be invaluable. Contact me by email or through this blog’s contact form.

How I built running shoes for my whole family in one sunday afternoon (Huarache sandals)

Sun, 26 May 2013 21:17:07 +0200

Some time ago, Diego Santamarta casually mentioned that the shoes he was wearing were not regular flip flops, but rather some kind of sandal which I had never heard about. “Oh ok” was my less than enthusiastic answer. In the meantime, and even before, I had been reading about barefoot running, even though I had never run more than a few hundred meters without panting uncontrollably. Yes, 15 years smoking does take it’s toll. After two years tobacco free, I feel I’m only now starting to recover.

Anyway, I had dismissed barefoot running as something that I would love to do — and probably the only way that I would ever run for pleasure — but that seemed very uncomfortable bordering on dangerous. Two days ago, that same Diego Santamarta posts to facebook a link about those sandals as used by barefoot runners to protect their feet on difficult terrain.

Documentation and materials

I almost immediately started reading about them, watching youtube videos or instructables explaining how to build them. I had an old tire in the growing “to throw away” pile which I never get around to bringing to the recycling center, so that was the main part of the material sorted. I also have some polypropylene cord (the blue one used to tie straw bales and some black one) which could be used as laces. As will be seen later this is not comfortable nor durable so I used some more elaborate string for the laces.

Trace your foot on paper and locate the holes as indicated in one of these guides.

Cutting the sole

Now the real work begins. We will need to hack at that tire, and it truly is tiresome work. I had some tin snips on hand which I thought would be perfect for the job. They are in fact totally useless. I did the job with a hacksaw to cut through the metal ring where the tire meets the wheel, and then one of my trusty Opinels to cut through the reinforced rubber outwall. If the knife is kept sharp, this is actually fairly easy work.

I cut some rough pieces from the outerwall, one from each side of the tire to match the curvature of the outerwall to the natural curve of each foot.

You then trace the outline of your paper pattern on the pieces you just cut, enabling you to have perfect tire soles for your huarache sandals.

I then used a small drill bit, around 5mm to drill the holes.

Putting the laces in places

The are many lacing systems that can be used, the one I used seemed simple enough, and can be slipped on and off easily.

To pull the string through the holes, I used a piece of bent wire as a threader, and pliers to pull on it if need be. A figure of 8 knot locks the string in the toe hole. the string then goes throught the outer hole, around the heel, through the inner whole, and ties around the front part of the lace

Here is the result: my son’s sandals. He complained that they were not very comfortable though, so I changed the cord (which was too thin) and used a thicker braided one I had around, which is much more comfortable.

Once everyone had their sandals ready, I decided to go for a short run to try them out

Running

Please keep in mind that I was a heavy smoker for many years, have never run unless obligated to, and never more than a few hundred meters.

The first segment was downhill, and I had to readjust the shoes almost immediately, for the only time in the entire run.

When I arrived at the first uphill segment I got out of breath quickly and decide to alternate running and fast walking for the rest of the outing. That worked out pretty good, and the running actually felt easier and easier. The shoes are superb. They are pretty comfortable, provide just the right amount of protection to avoid having to look out for every little piece of gravel and can be used to cross streams without fear of them becoming slippery.

My calves started hurting at around the ten minute mark, I think from landing on the front portion of the feet. It only got worse from then on, and now I can barely walk, it feels like I have a continuous cramp in these muscles. The feet are in perfect condition though, I just feel that they have had a good workout.

Can’t wait to go out tomorrow for more!

Installing PHP, Apache2 and nginx for faster websites

Mon, 23 Apr 2012 08:17:07 +0200

My contract with my previous shared hosting contractor is coming to a close, and as they seem to have all but abandoned their business, I decided it was time to move away. I looked at using Amazon’s EC2, but ultimately decided to go with Bhost, with which I’m fairly happy so far. To get some decent performance out of it, I planned to use Nginx as my web server

Keep using Apache as usual

All my websites are configured to work with apache, sometimes using fairly advanced rewrite rules, and a fair proportion of wordpress sites. So to save myself a ton of work I decided to just use Nginx as a proxy to apache and not reconfigure each site to use Nginx’s rewrite rules.

Install required software

I’m using Ubuntu, but the steps below should be fairly easy to adapt to your distribution of choice. To install everything from scratch, just run sudo apt-get install php5 apache2 mysql-server php5-mysql nginx. This installs mysql, Apache, PHP and Nginx

Configure Apache and Nginx

I created one bash script that creates the necessary virtual hosts files for Apache and Nginx, by taking a template a doing a search/replace with sed. Here is the apache virtual host template that goes into /etc/apache2/sites-available:

    <VirtualHost *:8080>
        ServerAdmin webmaster@localhost
        ServerName template
        ServerAlias template www.template cdn.template cdn2.template
        DocumentRoot /var/www/template
        <Directory />
                Options FollowSymLinks
                AllowOverride None
        </Directory>
        <Directory /var/www/template/>
                Options Indexes FollowSymLinks MultiViews
                AllowOverride All
                Order allow,deny
                allow from all
        </Directory>
        ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
        <Directory "/usr/lib/cgi-bin">
                AllowOverride None
                Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
                Order allow,deny
                Allow from all
        </Directory>
        ErrorLog ${APACHE_LOG_DIR}/error.log
        # Possible values include: debug, info, notice, warn, error, crit,

        # alert, emerg.

        LogLevel warn
        CustomLog ${APACHE_LOG_DIR}/access.log combined
        Alias /doc/ "/usr/share/doc/"
        <Directory "/usr/share/doc/">
            Options Indexes MultiViews FollowSymLinks
            AllowOverride None
            Order deny,allow
            Deny from all
            Allow from 127.0.0.0/255.0.0.0 ::1/128
        </Directory>
    </VirtualHost>

You’ll notice that Apache listens on port 8080. You need to change the port from 80 to 8080 in /etc/apache2/ports.conf as well, this is what mine looks like after the change :

    NameVirtualHost *:8080
    Listen 8080
    <IfModule mod_ssl.c>
        # If you add NameVirtualHost *:443 here, you will also have to change

        # the VirtualHost statement in /etc/apache2/sites-available/default-ssl

        # to <VirtualHost *:443>

        # Server Name Indication for SSL named virtual hosts is currently not

        # supported by MSIE on Windows XP.

        Listen 443
    </IfModule>
    <IfModule mod_gnutls.c>
        Listen 443
    </IfModule>

Next up is the template for the default nginx site, which is much simpler and goes in /etc/nginx/sites-available:

    server {
        listen 80;
        access_log /var/log/nginx.access.log;
        error_log /var/log/nginx.error.log;
        root /var/www/template;
        index index.php index.html;
        server_name template *.template;
        location / {
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header Host $host;
                proxy_pass http://127.0.0.1:8080;
        }
        location ~ /\.(ht|git) {
                deny all;
        }
    }

All that does is proxy everything to apache on localhost, port 8080

So, our virtual host templates are ready, and if you only have one or two sites you could copy the contents to a new file by hand and change the word template for your actual domain name / folder, but as I had quite a few sites to convert, I created a small bash script that takes car of it for me, by just calling it with the hostname:

    #!/bin/bash

    CMDLN_ARGS="$@" # Command line arguments for this script

    export CMDLN_ARGS
    # Run this script as root if not already.

    chk_root () {
     if [ ! $( id -u ) -eq 0 ]; then
       echo "Please enter your password."
       exec sudo su -c "${0} ${CMDLN_ARGS}" # Call this prog as root

       exit ${?}  # since we're 'execing' above, we wont reach this exit

                  # unless something goes wrong.

     fi
    }
    chk_root
    cat /etc/apache2/sites-available/template | sed "s/template/$1/g" |cat > /etc/apache2/sites-available/$1
    ln -s /etc/apache2/sites-available/$1 /etc/apache2/sites-enabled/$1
    cat /etc/nginx/sites-available/template | sed "s/template/$1/g" |cat > /etc/nginx/sites-available/$1
    ln -s /etc/nginx/sites-available/$1 /etc/nginx/sites-enabled/$1
    if [ -d /var/www/$1 ];
    then
      echo "host directory exists";
    else
      echo "creating directory"
      mkdir "/var/www/$1"
    fi
    chown -R www-data:www-data /var/www/$1
    /etc/init.d/apache2 restart
    /etc/init.d/nginx restart

Put this say in your home folder and give it executable permission with chmod 755 new_host or whatever you named the file.

Then run it with ./new_host example.com

This will create a folder in /var/www/example.com, copy the updated template virtual host configuration to the required location and restart apache and nginx.

Now put some content in that folder and configure your mysql connection if neccesary

You should now be able to browse to example.com and see your brand new site. Some quick benchmarking with ab gives roughly a tenfold increase in requests per second, depending on the configuration of the website itself

These are some rough numbers for Six Pixels, built with Kohana2 without any caching mechanism

ab -c20 -n200 http://6px.eu:8080/ is hitting Apache on port 8080

Server Hostname:        6px.eu
Server Port:            8080

Document Path:          /
Document Length:        12101 bytes

Concurrency Level:      20
Time taken for tests:   282.679 seconds
Complete requests:      200
Failed requests:        0
Write errors:           0
Total transferred:      2486000 bytes
HTML transferred:       2420200 bytes
Requests per second:    0.71 [#/sec] (mean)
Time per request:       28267.940 [ms] (mean)
Time per request:       1413.397 [ms] (mean, across all concurrent requests)
Transfer rate:          8.59 [Kbytes/sec] received

Now with nginx ab -c20 -n200 http://6px.eu/

Server Hostname:        6px.eu
Server Port:            80

Document Path:          /
Document Length:        12081 bytes

Concurrency Level:      20
Time taken for tests:   40.606 seconds
Complete requests:      200
Failed requests:        0
Write errors:           0
Total transferred:      2482000 bytes
HTML transferred:       2416200 bytes
Requests per second:    4.93 [#/sec] (mean)
Time per request:       4060.612 [ms] (mean)
Time per request:       203.031 [ms] (mean, across all concurrent requests)
Transfer rate:          59.69 [Kbytes/sec] received

Update:

As rightly noted by @arnaud_lb the benchmarks should give nearly the same results, as nginx is waiting for Apache to return it’s data before sending it along. What happened in those benchmarks is that cloudflare.com (highly recommended by the way) was caching some results and not others.

When I tried on localhost, the results were effectively the same. So the way to get better performance is to get nginx to cache the results from apache, by adding the following to your nginx virtual host definition :

    proxy_cache one;
    proxy_cache_use_stale error timeout invalid_header updating;
    proxy_cache_key $scheme$host$request_uri;
    proxy_cache_valid       200 301 302 20m;
    proxy_cache_valid       404 1m;
    proxy_cache_valid       any 15m;

where the proxy_cache named one is defined in nginx.conf as such :

    proxy_cache_path /usr/local/nginx/proxy levels=1:2 keys_zone=one:15m inactive=7d max_size=1000m;

The proxy_cache_valid entries above define different cache times for various response codes

And here are the real benchmarks :

Apache:

Server Hostname:        direct.6px.eu
Server Port:            8080

Document Path:          /
Document Length:        11487 bytes

Concurrency Level:      10
Time taken for tests:   15.082 seconds
Complete requests:      200
Failed requests:        0
Write errors:           0
Total transferred:      2338600 bytes
HTML transferred:       2297400 bytes
Requests per second:    13.26 [#/sec] (mean)
Time per request:       754.075 [ms] (mean)
Time per request:       75.408 [ms] (mean, across all concurrent requests)
Transfer rate:          151.43 [Kbytes/sec] received

Nginx:

Server Hostname:        direct.6px.eu
Server Port:            80

Document Path:          /
Document Length:        3031 bytes

Concurrency Level:      10
Time taken for tests:   0.027 seconds
Complete requests:      200
Failed requests:        0
Write errors:           0
Total transferred:      654600 bytes
HTML transferred:       606200 bytes
Requests per second:    7305.94 [#/sec] (mean)
Time per request:       1.369 [ms] (mean)
Time per request:       0.137 [ms] (mean, across all concurrent requests)
Transfer rate:          23351.88 [Kbytes/sec] received

Just, wow…

Careful though as this will wreak havoc on your sessions, at the minimum you can disable caching for logged-in users with

    proxy_cache_bypass $cookie_session;
    proxy_no_cache $cookie_session;

where session is the name of your cookie