So much Writing and Coding… so Little Time

I must apologize to regular readers of my blog, that I have been slacking. I plan on writing a blog entry once a week, and even though this one is late, I am trying to keep my promises. At least one should keep promises to one self. And I apologize if this entry is a bit sparse. It is a bit “phoned in”, I guess.

Anyways, I have been keeping busy with my many projects. Because of this I feel like I am pulling myself in a bunch of directions at the same time. This feels counterproductive and progress is slow. But I’m not sure of a better way to progress forward. I fear concentrating on one project, will just make everything else fall behind. Basically what I’m saying is that I’m trying to show some real progress on my open source projects, my not-so-open-source product, my writing, and bunch of other things… but yeah… it may be a while before I have anything substantial to show. Sorry.

Don’t even ask about all my emails… it is all a bit overwhelming. I will try to get back to everyone… but there really is so much to do. And only one of me… sigh…

In the meantime, I will try to keep up with the blogging. Maybe about some tips and tricks, but no real long articles for now. At least until I feel things get more manageable.

Anyways, take care and see you next week!

PyCon CA 2016 – The Art of Writing Wargames in Python with Kivy


Last year in November, I presented a talk about Kivy at PyCon Canada 2016. I talked about my experiences working with Kivy in the context of writing a strategy game. I discussed the various UI frameworks available to a Python developer, and why Kivy is currently the best choices for UIs in Python. Especially if you are interested in making a cross-platform app or game.




Many of us got our start in programming, by building games and simple apps. However creating interesting games and UIs in Python was not a simple task especially for multiple platforms. Kivy, a cross-platform Python UI app framework changes all that. This talk discusses the journey of working with Kivy to develop a moderately complex strategy game. It also contrasts to using other platforms


Overall, the talk went better than I expected. The audience was engaged and interested. There was a few technical difficulties, namely I had to resort to using my phone as a wifi hotspot to run my presentation rather than Ryerson University’s wifi. Also there was a noticeable delay between when I changed slides on my presentation notes, and the projected display. This kind of delay is probably the only downside of using this time around. Having a local copy would of worked better, which I will do so in the future.

Also I wish I had more time to come up with a better demo for the presentation. However even after the sprints, the hex grid layout still plagues my Kivy app. In hindsight, I probably should of worked on a simpler app. Also some folks were turned off by the use of wargames, rather general games. But you know, you learn from your mistakes.

Finally I got quite a few questions, and people are genuinely interested in checking out Kivy. Which ultimately was what I was trying to achieve with this talk.

Merry Christmas and Happy New Year 2017!

Hey Readers,

Sorry for the delay between posts. I went on an unannounced hiatus, just because of the busyness of last year. However I am back, and I will return to my regular posting schedule of once a week, most likely either Wednesday or Thursday morning.

Also I hope everyone had a Merry Christmas (or has if you’re celebrating the 12 days of Christmas), and I hope your New Year is happy, bright and full of promise!

— Dorian

Avoiding Blank PHP Responses after upgrading to Ubuntu 16.04, and php7.0-fpm

Earlier this week I finally made the plunge to upgrade my VPS to Ubuntu 16.04. With a minor hiccup surrounding supervisord (which I probably can avoid if I go the systemd route) not being enabled at boot, the upgrade was simple for both my WSGI and Node webapps.

I can not say the same thing about my WordPress/PHP installations. (Installations that I hope to transition off to Rookeries once that software becomes more stable.) It took me a few hours to track down and resolve the problems. Hence I am posting this article, to hopefully save someone else’s time when they do the same upgrade.

Upgrading to PHP 7.0

Ubuntu 16.04 makes the switch away from PHP 5 to PHP 7. So I had to switch to php7.0, php7.0-fpm, and php7.0-mysql from their PHP 5 equivalents. The location of the running UNIX socket has changed from /var/run/php5-fpm.sock to /var/run/php/php7.0-fpm.sock, as did the PID files.

Updating the PHP-FPM configuration

Running WordPress using FPM (Fast Process Manager) and NGINX, requires turning off the path translation in php.ini file. This can be done by uncommenting the line cgi.fix_pathinfo=0 found in the configuration file /etc/php/7.0/fpm/php.ini. Again these files have moved from the old location. After you’ve done this remember to restart the FPM service using the new systemd utilities: sudo systemctl restart php7.0-fpm.

Updating the NGINX configuration and Solving the Blank Response

This is the tricky part. After updating my NGINX configurations to the new UNIX socket path, and restarting NGINX, I found that I got blank PHP responses. Everything else worked, expect that any PHP page would not render. And not render by not rendering any content in the body of the responses. That led me down a few rabbit holes, and researching how to re-architecture my setup using Docker. Eventually I stumbled across a blog entry with the solution to the blank PHP response issue.

In a nutshell, with the NGINX upgrade one of the parameters needed for FastCGI went missing namely the fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; bit. Oddly this parameter appears in /etc/nginx/fastcgi.conf and not the /etc/nginx/fastcgi_params file that I normally include in my NGINX configs. Anyways after adding this line and restarting NGINX using sudo systemctl restart nginx everything worked correctly. Below I’ve included a sample NGINX configuration that should work.

Sample NGINX Configuration /etc/nginx/site-enabled/example-site.conf

server {
index index.php;
root /srv/www/location_of_wordpress_install;
listen 80;

access_log      /var/logs/nginx/site-access.log;
error_log       /var/logs/nginx/site-error.log info;

location / {
    try_files       $uri $uri/ /index.php$args;

location ~ \.php$ {                        
    fastcgi_split_path_info     ^(.+\.php)(/.+)$;
    fastcgi_pass    unix:/var/run/php/php7.0-fpm.sock;
    fastcgi_index   index.php;
    fastcgi_param   SCRIPT_FILENAME    $document_root$fastcgi_script_name;
    include         fastcgi_params;

location ~* \.(js|css|png|jpg|jpeg|gof|ico)$ {
    expires         max;
    log_not_found   off;


Selling Off Some Domains

I was going to write about why needing an app isn’t a good way to try get into business. (Hint: It is very expensive, if you can’t code it yourself.) However something else popped up, namely I am trying to sell off two domains: and that I own. These were for the justCheckers project, that I’m essentially shutting down. Anyways if you are interested in buying them off me, feel free to contact me.

I will say that the experience so far has been interesting. Thankfully there are some good resources for selling a domain or site. I’ve looked at two companies that handle the auction and transfer of these things Flippa and Sedo. Both are quite legitimate, but there were some bad reviews and some people claiming to have been scammed. I’m trying out Flippa first since it was founded by the fine folks at SitePoint, who I quite like for other reasons. Anyways, I’m hoping that I can find a good home for the domains.

See you at PyCon Canada 2016!

I’m looking forward to PyCon Canada 2016 that will be happening November 12-13 in Toronto. I submitted two talk proposals and I’m hoping that one of them gets accepted. But regardless I am looking forward to the conference. If you are at the conference, and you want to meet up just message me via Twitter @dorianpula. Also I plan coming out to the sprints that I’m hoping will be happening afterwards. See you there!

Taking a Break

Dear readers,

I was hoping to have a new entry for you this week. Unfortunately I am swamped with non-blogging work at the moment, and I need to concentrate on this for the next couple of weeks. So I’m taking a break from blogging for a bit. I should be back to my regular blogging schedule in the next couple of weeks.


Through the Javascript Looking Glass Part 1: Finding ES6 + NodeJS Alternatives to the Python Stack

Apologies for missing last week’s scheduled post and being late with this week’s post as well. I’ve been putting off writing articles and refilling my queue, with other things that have been (or seemed) more important than blogging. Either way, I’ll try to fix this so that next week I’ll be back to my regular schedule. –Dorian


These past weeks right before the start of the new year, I have been experimenting with something new. As part of trying to use server-side rendering for React client inside Rookeries, I decided to figure out how to achieve this using NodeJS. To kill a couple of birds with the same stone, I decided to use this as an opportunity to play around with ES6. In these next few blog post I will write about some of the lessons I learned along the way.

The Project and Its Architecture

To help me focus my learning, I decided to concentrate around a project that would provide a skeleton for my learning. I choose to recreate one of my earlier Flask project, which runs the Amber Penguin Software website. This web application acts as a cross between a static file website and a CMS, by serving template pages that render Markdown into the body of each page. The routing is a fairly trivial look up of flat files, and returning a 404 error page when a page is not found. The tech stack being Flask, a simple [J]inja2]( template and Markdown as the Markdown rendering engine.

My project consisted of four phases:

  1. Recreate the current setup using a NodeJS tech stack,
  2. Add a simple JSON API to host the API and a simple React component that was “renderable” via the server and the client.
  3. Build out the React app to handle routing and retrieving the content of each page, with a first time server load and subsequent calls via Ajax calls to the JSON API from the frontend React components.
  4. Host the completed app using my existing Ansible setup.

Finding Alternatives

The first task consisted of figuring out what NodeJS technologies I could use to recreate the Python/Flask app. Turns out that the language specific communities in the web app world like to borrow heavily from each other. Just as Ruby’s Sinatra microframework inspired Python’s Flask, so did Node’s ExpressJS take notes from Flask. Jinja2 inspired Mozilla’s Nunjucks and a bunch of other similar templating libraries. (I ended up using Nunjucks since it is the most mature library) Marked replaced Markup. The tricky part was actually replacing Python’s to open files. With a bit of experimentation I figured out how to use Node’s fs (file system) module and its readFile() and readFileSync() methods.

In short I could translate the tech stack this way:

  • Flask ⇒ ExpressJS
  • Jinja2 ⇒ Nunchucks
  • Markdown ⇒ Marked


Next time, I’ll go into the details of setting up the ExpressJS apps and routes.

DNS Woes

For the past couple of days instead of working on actual development work related to any of my projects, I’ve been transferring all of my domains from DreamHost, my old hosting provider to a new DNS provider. I was looking forward to a gentle switch over, to my new Canadian (eh!) DNS provider easyDNS. Unfortunately like many technical problems, I ended up spending more time and effort than I expected to originally. (Enough effort that I’m late with posting this blog update today.)

It turned out that DreamHost made enabling my desired setup real easy, and hid a lot of the technical difficulties of setting up DNS records. easyDNS is a lot more flexible, but then I’m not a DNS record expert so getting a similar setup was tricky. Fortunately the fine folks at easyDNS are really responsive by email, and a few emails back and forth we arrived at a setup that worked nicely. Most of this came down to not understanding the terminology and not checking the right places

DNS Record Terminology


This the main record that maps a domain name to an actual IP (v4 and v6) address. In my case this would be the IP address of the server hosting all my webapps. ---> 123.456.789.10 (not a real IP that I own)


Canonical Name or Alias, this is used to map a subdomain (e.g. www, app, etc.) to another part of the domain or another top-level address. This retains the subdomain name in the address bar of your browser. ---> mydomain,com --->

URL Redirect

Redirects (usually via a HTTP 301 Redirect) an address to another domain or location. (This turned out to be the option I needed for most of my sites) A redirect naturally will change the URL in the browser’s address bar. ---> --->

Stealth Redirect (easyDNS specific)

Redirecting using an IFRAME, and retains the original address in the browser. Otherwise it works like a URL redirect, it just won’t look like one.

A Working Setup

My original setup at DreamHost basically pointed all my additional domains at my main domain, and removed the www subdomain that normally gets tacked on to an URL by browsers. -> ->

Now traditionally you are supposed to use a CNAME for the second example. I just ended up using a URL redirects everywhere to make things simple. And a A DNS record for the main top-level domain to point to my Linode servers.

Check Your Nameservers!!!

The setup turned out real simple, but at first I could not get any of my changes to work. Or rather some of them works, other did not. It was very frustrating at first, but then the easyDNS support rep pointed out that I had not updated my nameservers for some of the domains names I transferred over. I was originally pointing to DreamHost’s rather than easyDNS’s nameservers and my changes simply were not propagating through. Once I fixed that, everything started updating as expected.

Provider Recommendations

Finally I just want to make some recommendations for anyone looking for a hosting or domain provider. I started off using DreamHost, after migrating away from GoDaddy, and I was happy with them for the longest time. They are convenient, easy to setup especially for PHP apps and pretty supportive. I highly recommend them if you have a normal website (like a WordPress blog) and want to have one stop shop.

Personally I outgrew DreamHost, when I needed something more configurable for my Python webapps. I’ve since migrated to Linode, who provide very nice, configurable and affordable VPS (virtual private server) hosting. I love using them and they support a wide variety of different OS platforms and versions.

Finally I recommend easyDNS. Their great for Canadians, supportive and care about your Internet freedoms (their takedown policy is that you have to have a real court-order or being doing something blatantly illegal rather than some flimsy takedown letter from some random legal department). I really recommend them if you want a flexible DNS/domain hosting. The problems I encountered were my own doing and lack of understanding, that the support rep helped me resolve in a few hours and after few tries.

PyCon US 2016, Maybe?

Well it looks like 2016 is off to a nice start. This weekend I submitted two proposals to talk at PyCon US 2016! And yes, I have already bought tickets, even though I am not quite sure how I’ll get to Portland, Oregon. 😛

But I thought why not? I had a lot of fun at PyCon last year in Montreal, and I’ve never been to Portland… and talking at PyCon Canada was actually quite fun. Now I don’t know if my proposals will get accepted or not. I will say that writing proposals is not fun. But fingers crossed maybe I’ll see you guys in Portland this spring… and maybe I’ll get a chance to talk as well.