Accessing a Docker container with NGrok

I want to access a local docker development environment from outside the host computer. This comes in handy for viewing a site on another device or sharing it with a client. There seems to be a couple of ways to do this documented online, but of course, none exactly worked for me. I’m going to assume you already have ngrok installed for doing the actual tunnel.

First, make sure nothing is using the port you want on the host machine. In my case, this means don’t run apache on the host machine if you’re docker container is using ports 80 or 443.

Then, to setup the ngrok tunnel I use this command:

ngrok http -host-header=rewrite

The key there being the host-header switch. Without it, apache couldn’t match the configured virtual host to the random hostname assigned by the service. With it, the local site is accessible without having to change anything about its configuration.

Paying Attention to Drupal Admin experience

Capturing my answer to a question on a mail list I’m on about paying attention to the Drupal admin and editor experience. Particularly, someone was asking if they should open their allowed HTML to allow pasting form and iframe tags versus the risk of being compromised by the same. My initial reply was:

If your content team is relatively small and you trust them … I think it’s OK to all form and iframe embeds.
However, if you can I’d see if you can embed these snippets via some other way, like shortcodes in WordPress or as Paragraphs in Drupal (there are probably a dozen other solutions in Drupal too) which integrate with each of those platforms. HTML is easy to break, you won’t be able to just paste the HTML into your editor, and if they embed code has to change in the future (or be removed) it’ll be tedious to do so.
Which lead to a longer discussion on ensuring the overall Drupal editing experience is not ignored.
First, “locking” clients out of editing templates and configuration values makes sense, if the vendor will be hosting and supporting the site long term. There’s a lot going on in a CMS, and accounting for changes to configuration, CSS, templates introduced only on the production server is a migraine waiting to happen.
That said, it doesn’t mean you should give up a lot of flexibility for controlling the layout of your pages and you shouldn’t have to run to the vendor for every change. Things they and you should be paying attention to:
Ensuring they aren’t hard coding page and node layouts in a template such that changing them later requires a lot of effort. This was a pain on a site I worked on last year and had the Webforms module enabled. Instead of using the Webforms UI to build a form and control how the fields were grouped and displayed, the previous developer did that completely via custom templates. For the client,this meant that any new form had to have a custom template for it and changes made to forms in Drupal’s UI had no apparent effect (which kind of misses the point of having Drupal). Other pages on the site were handled similarly with custom templates.
Just throwing a WYWIWYG editor at your editors is also a big fail. If you have a document type which will have a link to a PDF file, don’t be content with a “file explorer” type plugin for CKEditor. Have a “Related Files” field in the document content type. Editors shouldn’t have to worry about how and where the file link will be rendered. Use Drupal/your CMS to consistently display the links (and integrate the PDF contents with Search, share files with other content types, etc).
For layout control within a page, Drupal has a couple of options which don’t require an editor making the layout in raw HTML. I think there’s a Layout builder in the latest release and there’s always the “Paragraphs” module which lets you define types of blocks you can stack to build an interactive page. Conceptually not unlike Mailchimp’s editor, if your familiar with it or how Gutenberg’s blocks will be handled in WordPress.
Media handling in Drupal has always lagged behind WordPress. I’m not sure what the state of the art is, but the latest release has Media in core. If you’re going to have a lot of photos, audio files, etc… you’re better off managing them as Entities you can tag and manage like a node and not just think of them as a file you upload and link somewhere (much like images I mentioned earlier).
Also if you have some custom workflows for managing the content creation process, you should ask your vendor to use well known modules like Workbench to configure and manage the process. I wouldn’t want to code a custom workflow for a client, since that becomes harder to change whereas Drupal modules exist which can let you manage and tweak those requirements in the UI (see
Last, I’d say make sure you have a good content model. If you are going to have blog posts, articles, and press releases — each with their own quirks — they should each be a content type in the admin. Don’t make an uber “article” type which behaves differently depending on which fields are filled out. Within each content type, group fields which belong together, use vertical tabs or sidebars to break up forms with a lot of fields, etc… This is a good summary:


Creating ZIP files and streaming the response with Silex

Creating a zip file is easy and Rob Allen has you covered on that front to get you started. I needed to do this to create a zip file of PDF files generated by Dompdf. It turns out, you can add files to a ZipArchive object without actually creating the file if you can get the contents as a string. This boils down to:

// $html is what you're going to render.
$dompdf = new DOMPDF(['defaultPaperOrientation' => 'landscape']);
// this generates the PDF contents but does not output them anywhere

// now we create a zip file and add the PDF
$zip = new ZipArchive();
$zip->open('/tmp/', ZipArchive::CREATE);
// 'report.pdf' is the filename inside the zip archive
$zip->addFromString('report.pdf', $dompdf->output());

The above adds one file, clearly if you want to create multiple PDFs, you would do that in a loop and call addFromString for each one. Then, if you want to stream the response to the browser with Silex (which uses Symfony components) you do:

use use Symfony\Component\HttpFoundation\ResponseHeaderBag; 

// ...

// at the end of a controller...
return $app->sendFile('/tmp/')
           ->setContentDisposition(ResponseHeaderBag::DISPOSITION_ATTACHMENT, '')

Everything I learned to manage my career I learned from Soccer

This was originally posted on the mojolive blog 5 years ago, but I want to preserve it here if/when it goes down.

When I started working as a web developer, there wasn’t a lot of guidance about what that meant as a career choice. Of course, back then we were getting over the excitement of the blink tag and the new design opportunities afforded by table tags. I had to figure out a career path, and I did manage to do just that by watching a lot of soccer.

1. It’s not a solo effort.

Rare is the player that can take the ball from one end line, dribble past 11 opponents, and score the winning goal. Even if they manage to do it during a game, they’re likely to use their hand to score the next goal.

It is tempting to think of your career as a solo effort, particularly in technical fields where introverts seek shelter. But the people you work alongside, meet at conventions, and connect with can be invaluable resources when you’re looking for the next challenge in your career. Even at a small company, you’ll have to work alongside other programmers, manager, designers, and end users.

It pays off to make the effort and get to know them beyond the current project, I wouldn’t be working at mojoLive if I hadn’t worked with Sandy previously. Take part in your local community events and conferences too, they’re great for expanding your network’s reach outside of colleagues, schoolmates, and clients.

2. Serendipity complements planning

When you’re watching a game, and maybe dreading a scoreless tie, the entire game can change instantly.  A player with a simple flick, a mazy dribble, or an audacious goal can change the tempo and momentum of the rest of the match.  It’s impossible for a soccer coach to plan every movement or play, like an American football or baseball manager.

It’s also impossible to plan every single move in a career, no matter how good your plan is; economic conditions can change and new technologies may become popular. You have to leave room for chance and serendipity to play a part in your career, and be willing to take a risk and make a change when an opportunity presents itself.

3. Keep your skills sharp

Once a player passes 30 years old, fans and coaches inevitably start asking how much longer they can play. Like any other athlete, the shelf life of a soccer player is limited by his physical condition. Some players can defy time; Preki was named Major League Soccer’s MVP at the ripe old age of 40.

For most of us, physical traits don’t affect our job performance so drastically. But, your own shelf life is limited by the skills you acquire and use each year. If you find yourself in a rut, using the same programming language all the time, one technology stack, or targeting a single platform, make it a point to look outside your comfort zone.

4. The good players practice, practice, practice

The best players have an almost single-minded focus on soccer. It might make them dull at dinner parties but it gives them an edge. They spend extra time after practice running through drills on their own, or hitting the gym on their off days.

Likewise, extra-curricular projects can help you learn something new. Always building Drupal sites? Check out python and django. Have an idea that could be a useful product? Build it in your spare time, to see just what it takes to build something from start to finish.

5. Play with the best to get better

I came to the game late and only started playing soccer recreationally in college. I quickly learned that playing with better players made me improve faster. Not that I ever became more than a barely adequate player, but playing with them meant I had to try to be quicker, and play smarter.

Once you find a comfort zone, it’s tempting to stay in it but you risk stagnation. If you find that you’re a big fish in a little pond or you’re a little bored with the work you’re doing, its time to think about working on more ambitious projects. For programmers, a ready avenue to collaborate with other top-notch developers is through open source projects, or simply sharing code on github.

6. Don’t be a one trick pony

It seems every team has at least one player who is one dimensional but the coach loves for some reason. The worst is watching a player who can only shoot with his left foot. Inevitably, they’ll be one-on-one with the goalkeep, but the ball will be on their right foot.  As they waste time maneauvering to get the ball on their favored left foot, a defender has time to recover and tackle the ball away.

Don’t be predictable. Don’t stick blindly to always using the same solution whether its PHP, Drupal, or jQuery. For some projects, you’ll waste time trying to fit a square peg into a round hole, when a faster, cheaper solution. It’s also tempting to think of yourself as a “Back-end programmer” or a “Front-end engineer”. Learning to do both not only improves your versatility, but you can speak intelligently about what it takes to do both.

20 Years of PHP

Ben Ramsey shared how he got started with PHP and had the great idea of asking others to write about their stories and tagging it as #20yearsofphp. This is my story.

When I graduated from college in 2000, I began looking for a job without a clear idea of what I wanted to do. In grad school I had done some projects using HTML, ASP, and ShockWave for various professors and figured I could get a job building web sites until I decided on something. I replied to a job posting (I think it was on and in September 2000 I started working as a web developer at Forum One. Thanks to that job, I spent a week working in San Francisco after meeting my (future) wife on a previous trip to California. We’d get married in 2004.

At the time, PHP4 had just been released. I worked on projects which still used PHP3, or interfaced via Perl CGI scripts to save data in a custom-build in-house CMS. I think my first actual PHP project was for a local Jewish Temple. Like other junior devs at that job, I took a shot at replacing the Perl scripts with my own PHP versions. Luckily, I never inflicted them on my colleagues.

From there, PHP was a gateway to learning about Linux, web servers, databases & SQL, and so much more. Thanks to PHP (and Drupal) I worked for my favorite soccer team, D.C. United. Today I’m grateful that, through running php[architect] I get to work not only with Eli, Kevin, Sandy, and Heather on daily basis but also with the wider PHP community through php[architect]’s magazine, books, and conferences.

I don’t think I could have planned the last 15 years better. Here’s to the next 20!


Being a life-long programmer

I read the following article this morning, and found a lot of useful insight in it about what it takes to be a programmer long-term. And, though I’m not approaching 55, as my 6 year old pointed out when I told him my age two weeks ago I am “almost near 100″… Yes I Still Want To Be Doing This at 56

I particularly identified with was the following paragraph

“The thing I find most important today is that you should never work longer, just smarter. Being older does mean you can’t code 20 hours a day any more, or rather imagine you can code 20 hours a day as it’s not really good coding. Is there a real limit to how many hours a day you can actually be producing a quality application? Probably it does go down over time but as long as you continue to learn how to code smarter the end result is still quality, just with less caffeine.”

When I started out of school 15 years ago, it was very easy for me to just sit and bang out code with little preparation or thought put into it. I’d come back, if there was time, and clean up some bit or I’d come back months later and have no clue what I meant to do and kick myself for the decisions and shortcuts I’d take. Nowadays, I’m a lot more reflective when I start something, even if its a simple class. If I can, I bounce ideas off of colleagues, which at the minimum forces me to articulate the pros/cons of approaches I’m considering. I spend less time actually writing code, but have cleaner, easier to use code as a result and usually there’s time re-factor and clean up the rough edges.

Measuring developer productivity

My friend Sandy shared a link to a fascinating natural experiment comparing the productivity of two similarly tasked developer teams. If you haven’t read it already, take a minute to check it out. I’ve seen this need for visibility throughout my career.

The cable company was a rare laboratory, you could observe a direct comparison between the effects of good and bad software design and team behaviour. Most organisations don’t provide such a comparison. It’s very hard to tell if that guy sweating away, working late nights and weekends, constantly fire-fighting, is showing great commitment to making a really really complex system work, or is just failing. Unless you can afford to have two or more competing teams solving the same problem, and c’mon, who would do that, you will never know. Conversely, what about the guy sitting in the corner who works 9 to 5, and seems to spend a lot of time reading the internet? Is he just very proficient at writing stable reliable code, or is his job just easier than everyone else’s? To the casual observer, the first chap is working really hard, the second one isn’t. Hard work is good, laziness is bad, surely?

In agency work, you tend to track hours worked on a project. I’d bristle when each quarter the list of “most billable” employees. Great! If those folks are junior developers, chances are their also creating a lot of “billable” work that pulls in other people. A list of people who were the busiest in the last 3 months, when you should be encouraging people to get the most done in the least amount a time. A better metric, though harder to calculate and report, would be to figure out revenue per hour. That’s not so difficult to do per project, but it gets hairy in trying to tie it directly to people but it can be done.

If you’re part of an internal development team, upper management may use “seeing butts in seats” as a proxy for people getting work done. This encourages people to hang around just to look busy, and discourages using  remote workers. In this case, metrics you’d like to look at are more tied to business outcomes, things like site uptime, conversion rates, sales, etc.

Still, if you want to measure actual productivity, in terms of what tasks your development team what can you do? This is where I think a good habit of issue+SCM tracking, rigorous testing , and continuous integration can really shine.

  • Issue tracking can let you report the number of issues you’ve addressed.
  • Unit testing can report on the health of your code base by looking at test coverage, number of tests added/created, etc.
  • Continuous integration can then give you ongoing performance metrics. How often are we producing successful builds? How often are we deploying code to production?

I’m sure that just scratches the surface of what you can do. How do you measure developer productivity?

Colorized Word Diffs

I’ve been finding myself doing a lot for copy and tech editting. I needed a way to annotate a PDF based on the changes I’d made to our markdown source. Trying to eyeball this was difficult, and I checked if there was a way to do word-by-word diffs based on SVN output. Remember, SVN’s diff command will show line-by-line differences. But there is a Perl script wdiff that will show you word by word diffs. With a bash alias, you can pipe svn output to it and see what’s been added/removed more clearly.  Once you install wdiff, either from source or via your distributions package manager, create an alias (I use bash) that will colorize its output:

alias cwdiff="wdiff -n -w $'\033[30;41m' -x $'\033[0m' -y $'\033[30;42m' -z $'\033[0m'"

wdiff compares two files by default but in can also parse the output of a diff file. By piping svn diff to it, you can see the changes word for word. In the example below, I’m reviewing the changes made by a specific commit and using less to page the output, the -r flag keeps the colors intact.

svn diff -r 267 -x -w 05.chapter.markdown | cwdiff -d | less -r

Words that were deleted will be in red, additions are in green.



Git has this behavior built in using:

git diff --color-words

Also, if you need to share your changes with a designer (who maybe needs to update a PDF…), with this ansi2html script from, you can generate HTML output showing your changes. I found that its useful to run the generated HTML through fold so that the lines wrap if you email it to someone.

svn diff foo.markdown | cwdiff -d | ~/bin/ | fold -s > foo-updates.html

Finally, you can wrap all this functionality into a simple bash script that you can save anywhere. Pipe it the output of a svn diff or diff command, and get nice HTML as a result. It assumes ansi2html is somewhere in your executables $PATH.

# take diff input (from svn diff too), colorize it, convert it to html

cat - | wdiff -n -w $'\033[30;41m' -x $'\033[0m' -y $'\033[30;42m' -z $'\033[0m' -d \
| | fold -s