We recently added invoices to Browserling. I thought I'd share how we did it as it's another interesting story.

Our customers keep asking for invoices all the time so we made it simple to create them. They can now just go to their Browserling accounts and download them. Here's how an invoice looks like:


Example invoice. (Download example.)

And here are the implementation details.

We use a node module called invoice. The invoice module takes a hash of invoice details, internally spawns pdflatex that creates a pdf invoice, and then calls a callback with the path to the pdf file, like this:

var invoice = require('invoice');
invoice(
    {
        template: 'browserling-dev-plan.tex',
        from: "Browserling inc\\\\3276 Logan Street\\\\Oakland, CA 94601\\\\USA",
        to: "John Smith\\\\Corporation Inc.",
        period: "2/2013",
        amount: "$20"
    },
    function (err, pdf) {
        if (err) {
            console.log("Failed creating the invoice: " + err);
            return;
        }
        console.log("Pdf invoice: " + pdf);
    }
);

The browserling-dev-plan.tex latex template contains %to%, %from%, %period%, and %amount% place holders that the invoice module simply replaces with the given data:

\documentclass[12pt]{article}

\pagenumbering{gobble}

\begin{document}

\begin{center}
\Large{\textbf{Invoice}} \\
\vspace{0.5cm}
\large{Subscription to Browserling's Developer Plan}
\end{center}

\vspace{1cm}

\section*{Invoice from:}
%from%

\section*{Invoice to:}
%to%

\section*{Period:}
%period%

\section*{Amount:}
%amount%

\end{document}

Once the pdf invoice is generated, we create a token that maps to the pdf file, and once it's requested, we send it to the customer as an application/pdf.

Until next time!

This is going to be a quick tutorial on how to run multiple node versions side by side. There are many different ways to do it but this works well for me.

First I compile node versions from source and I set them up in the following directory structure:

/home/pkrumins/installs/node-v0.8.20
/home/pkrumins/installs/node-v0.8.21
/home/pkrumins/installs/node-v0.10.3
/home/pkrumins/installs/node-v0.10.22

When compiling node I simply specify --prefix=/home/pkrumins/installs/node-vVERSION, and make install installs it into that path.

Next I've this bash alias:

function chnode {
  local node_path="/home/pkrumins/installs/node-v$1/bin"
  test -z "$1" && echo "usage: chnode <node version>" && return
  test ! -d "$node_path" && echo "node version $1 doesn't exist" && return
  PATH=$node_path:$PATH
}

Now when I want to run node 0.8.21, I run chnode 0.8.21 to update the path:

$ chnode 0.8.21
$ which node
/home/pkrumins/installs/node-v0.8.21/bin/node
$ node --version
v0.8.21

Or if I want to run node 0.6.18, I run chnode 0.6.18:

$ chnode 0.6.18
$ which node
/home/pkrumins/installs/node-v0.6.18/bin/node
$ node --version
v0.6.18

Works for me both locally and in production. Until next time.

Here is a neat trick. If you want to start a program that always respawns if it gets killed, just put it in /etc/inittab. The init process will respawn the program. That's what it's for.

Here's an example. Let's say you want /bin/unkillable to always run. Put this in /etc/inittab:

uniq:3:respawn:/bin/unkillable

Then run init q to make init re-read the inittab file. Now whenever /bin/unkillable gets killed, init will respawn it.

The init process uses this same trick to spawn terminals (otherwise if the terminals died and no one respawned them, no one would be able to log in from the physical terminals). This approach is also very useful if you absolutely must have some programs running. You don't even need complicated tools such as daemontools or supervisor to respawn programs. In most cases this trick is enough.

More information about init and /etc/inittab can be found in man init and man inittab. Until next time.

Footnote:
* by unkillable I mean one that respawns when you kill it.

This is going to be a super quick tutorial about how to access a Windows environment through ssh.

Step 1. Install cygwin, and make sure openssh and cygrunsrv packages are installed:


Make sure openssh is selected for installation


Make sure cygrunsrv is selected for installation

Step 2. Start cygwin and run ssh-host-config to configure ssh:


Run ssh-host-config to configure ssh

Step 3. Run cygrunsrv -S sshd to start sshd as a Windows service:


Run cygrunsrv -S sshd to start sshd

Step 4. Ssh into Windows using your favorite ssh client


Use putty to ssh into Windows

You can even set this up for your local workstation (if it happens to be Windows). Then you can forget about cmd.exe or PowerShell and use a real shell locally. Until next time.

Here's another interesting story about type of problems we've to deal at Browserling and Testling. This story is about how we implemented Windows user session cycling for Testling.

Here's what it is.

We run JavaScript tests on Windows for days straight and Windows sessions become really unstable after a while. When that happens we start getting errors such as Internet Explorer timing out randomly although everything is fine:


Internet Explorer cannot display the website

Or remote desktop connection gets messed up and I'm no longer able to get into the server:


Remote Desktop can't connect to the remote computer

Or Chrome starts to randomly crash:


Aww snap

None of these errors happen when the Windows session is fresh, so to work around these issues we implemented a Windows session cycler that simply logs out the user that runs tests, and logs it back in again every 6 hours. The implementation is pretty straight forward and just uses the standard Windows command line tools for managing users, such as users.exe and logoff.exe, as well as rdesktop.exe.

The user cycler is about a 100 line program but here's how it basically works:

user_id = find user id of testling user using users.exe
call <logout.exe user_id>
wait until user has been logged off
login testling user again using rdesktop.exe

The testling user's startup script initializes the testing environment and tests continue running after a short interruption.

A better solution would be to boot a clean Windows instance for every test but we're not there yet. Until next time.