The Traveling Coder

Halloween Contest: Win a Copy of Instant Flask Web Development

2013-10-31T00:00:00+01:00

It’s Halloween which means it’s time for some scary stories! I have teamed up with Packt Publishing to organize a giveaway of their new book, Instant Flask Web Development.

About the book:

Manage your project dependencies using virtualenv
Understand how Flask provides URL routing and web request handling
Recognize how Flask serves static files on disk
Learn about modeling, storing, and querying data with SQLAlchemy
Present HTML forms and validate input with WTForms
Build a page layout with Twitter Bootstrap using a base Jinja template
Create, recall, update, delete, and list database records
Build custom template filters in Jinja to format data
Authenticate users and maintain sessions

The goal is to make the night as spooky as possible by sharing your scariest development stories! Post your story in the comment section below and win one of the three available digital copies of the book. Think of it as a mini Daily WTF context.

The contest will be open for 7 days, until the 7th of November. Winners will be contacted though the comments so be sure to use a method which allows me to reach you. Winners will receive an e-copy version of the book.

UPDATE: the winners were notified in the comments. Congratulations to them!

Goal Versus System Oriented People

2013-10-20T00:00:00+02:00

Last week I read an interesting article from Scott Adams, the creator of the Dilbert comic, about How To Be Successful. He exposes two different kind of people, goal oriented and system oriented, and makes the case as to why the latter is the best option.

Putting aside whether being system oriented is better or not, the article struck a chord with me. The difference between goal oriented and system oriented can be easily resume using a weight loss example:

Your goal is to loose 10kg in 6 months: you achieve it, celebrate by going to the restaurant, gain back 1kg after a day. You start playing Yo-yo.
Your system is to eat healthy and in reasonable quantity: it takes much longer to loose the weight but you will loose it in time. You will stay slim and have a much healthier diet in the long term.

The second point makes definitely more sense to me than the first. It is however more difficult to start a system has it involves a mindset. When it fits your personality it is easy to get into but needs a lot of motivation and introspection in the other case. A system is also much less rewarding in the short term (can even be the opposite at first).

I faced that problem more than once trying to get into sports. Ironically, my goal was to set up a system but it failed as I couldn’t change my mindset.
On the opposite end, I’m naturally using systems for some aspects of my life where I would consider myself successful.

I also noticed how some people will create a system to reach a long term goal (eg: earn X amount of money and retire) but then suffer the same problem as Mr. Adams describes for goal oriented people (eg: depression because the best years of life are gone). Thus a system in response to a goal is almost as bad as no system at all.

I think people will rely on goals in areas where they’re not comfortable/good whereas naturally use a system in areas where they perform well (thus not noticing the system). I don’t think most successful people consciously created their system but the system created itself naturally as a result of their mindset.

To end, I would argue that it is not the fact that they are system oriented that make people more successful but that their mindset fits well with the task at end, the system being a by-product of this good fit.

Now, you could use a system to change your mindset…

Becoming a Digital Nomad

2013-09-08T00:00:00+02:00

Although the “Hire me for your next project” page has been up for a few weeks, I didn’t talk much about it. As you may know, I’ve been traveling since January. What started as a round-the-world trip as now turned into something else as I have been taking on freelancing jobs for the last three months.

I already wrote a post, “Why I’m in Montreal Right Now”, in my travel journal covering this change and what it means for my travels.

I’m really enjoying the digital nomad lifestyle now but it needed some adjustments at the beginning. I now reserve a few half days per week for work and will usually do a bit of computer every morning or evening for minor tasks and keeping up with the news.

I work from many different kinds of places. If there is a coworking space nearby, I try to go there but I usually work from coffee shops or at the hostel/hotel.

In parallel to freelancing, I’m also working on new projects which I hope will become profitable in the long term. The beta of the first one, Makerspad, should start in the upcoming weeks.

All this is a new direction for my life and I don’t know what will happen in the future. What I know is that I’m having the time of my life and that I will work hard to keep living the dream for as long as possible!

Introducing PHP DebugBar

2013-08-14T00:00:00+02:00

Having some information about what’s happening in your application is always something nice to have. For some time, I used FirePHP which while working very well is pretty limited on the way to display information.

Some of the bigger frameworks like Symfony include a debug bar or a profiling utility. Unfortunately, it is always completly dependent on the framework (understandable) which means that standalone projects or smaller frameworks does not benefit from it.

With PHP DebugBar my goal was to create a completely generic debug bar which can be easily integrated in any project. It is divided into two parts: a server side component to collect data and a client side component to display the collected data.

A lot of data collectors are included, ranging from request data to PDO as well as collectors for popular projects like Doctrine and Swift Mailer.

The design of the data collectors is heavily inspired from the ones in Symfony which are unfortunately too much dependent on Symfony’s libraries.

The client side component is 100% coded in Javascript and is completely independent from PHP. It could easily be re-used in implementations for other languages. The only real dependency is jQuery but including FontAwesome adds nice icons.

Checkout phpdebugbar.com for a live example and a comprehensive documentation.

I also created a DebugBar plugin for Atomik and the skeleton application now comes with the debug bar already activated.

Multi-site setup using Jekyll

2013-07-30T00:00:00+02:00

Continuing on my previous post about my Jekyll setup. As I noted, I use Jekyll to publish two sites which have many things in common. After some messing around, I’m finally happy with the organization and usage of this setup.

The two site share the following things:

assets
includes
plugins
layouts

Tasks in my fabfile are adapted to multi-site usage and I also have tasks to generate the configuration files.

The organization of the files is as follow:

sites/
  _assets/
  _includes/
  _plugins/
  _layouts/
  maximebf.com/
  travelingcoder.com/
  crontab
  fabfile.py
  nginx.conf
  supervisor.conf

_assets, _includes, _plugins and _layouts are shared by all sites.

I have created three plugins to add support for more than one _layouts and _includes folder as well as copying the shared assets over to each sites.

I made a Gist containing all files from this post. Here are the three plugins:

(Note that they’re not very flexible and were made for my own use case)

I also created a config_files.rb plugin which will scan your site folder for any .config.yml file and add them to the configuration. (I use this on travelingcoder.com to keep map data out of the main _config.yml file).

The _config.yml file for each of my sites look something like this:

plugins: ../_plugins
includes: 
  - ../_includes
  - _includes
layouts:
  - ../_layouts
  - _layouts
future: false

Some of the shared _includes are Disqus and Google Analytics code, the footer, the sharing widget and common assets for <head>.

The content of the _assets folder is merged with the assets folder in each site directories.

Compared to my previous post, tasks in my fabfile take a domain argument.

$ fab serve:maximebf.com
$ fab publish:all

The crontab has to be modified to use publish:all instead of publish.

The nginx.conf and supervisor.conf files are actually templates and I use a task to generate the final configuration for every domain:

$ sudo fab gen_conf # all domains
$ sudo fab gen_conf:maximebf.com # one domain

I recently added a third site to this setup and although it shares not much with the two others, it has worked out very well.

Big Update to Beautiful Docs

2013-07-16T00:00:00+02:00

Beautiful Docs has reached version 1.0! I must be honest that the project was stagnant for some time. The recent Hacker News submission about daux.io pushed me to fix all the open issues and add the features I had been thinking about for some time.

The new features:

search (full client-side, no server needed)
rebuilt generation engine with support for themes
generate static pages alongside your documentation
links
integration with google analytics and disqus

Beautiful Docs is a static documentation generator based on markdown files. It is developed in Javascript with Node.js.

Install it with NPM:

$ npm install -g beautiful-docs

Create a manifest.json file:

{
    "title": "My documentation",
    "files": ["README.md"]
}

Generate the HTML website:

$ bfdocs /path/to/manifest.json /path/to/output

Learn more at beautifuldocs.com

Publishing with Jekyll, Dropbox and Crontab

2013-07-15T00:00:00+02:00

My two blogs are powered with Jekyll, a static site generator. I love it and this is hands down the way to publish my content I prefer the most. I’ve been using it since I moved my blog out of Posterous and it has always served me well. I’m using it with a multi-site setup (which I will cover in a future post) and have published more than a hundred articles without any issues.

At first, I generated the site on my local machine and published it on my server using rsync. It was working well but quickly reach its limitations. As you may know, I’m traveling which means that I don’t always have access to a reliable Internet connection or have Internet at all. Secondly, I really wanted to be able to write posts which would be auto-published in the future.

As a result I’m now using Dropbox to sync my site to my server where it is automatically published using a cron job. This process is very easy to setup and made things much more easier.

The site is generated at a fixed time, two times a day. It is also constantly re-generated using a jekyll server in watch mode on a “draft” subdomain. This way I can always have a look at what the site will look like and check changes live. Only the draft domain includes future and draft posts.

First, you’ll need to add future: false to your _config.yml file. It is the only way to prevent jekyll build from publishing future posts.

On the server, I installed the Dropbox daemon and used the Dropbox command line interface to exclude all folders except the one containing my site:

$ dropbox.py exclude add MyExcludedFolder

Here’s some parts of my Fabric’s fabfile which contains some useful tasks to run the site on your local machine and generate it on the server.

On your local machine use $ fab serve to make the blog available on localhost:4000. All future and draft posts will be visible. As the blog is in Dropbox, it will be automatically synced to your server.

On the server, add a job in your crontab to publish it at fixed times:

30 10,23 * * * (cd /path/to/Dropbox/MyWebsite && /usr/local/bin/fab publish)

I use supervisor to have a jekyll process which serve the site on the draft domain. I use the following supervisor configuration:

Finally, I configure nginx to serve the two domains:

Notice the try_files $uri.html $uri/ =404; line. It permits building URLs to html files without the html extension.

As a side note, varnish seats in front of all my domains and allows me to serve files quicker. It had no problem going through 30000 visitors in a few hours while one of my article was on Hacker News’ frontpage.

This setup allows me to write posts from anywhere (online using Writebox or from my mobile). It allowed me to continue writing posts while my laptop was at the repair shop, all this without having to download anything or install jekyll.

I’m now considering using Sparkleshare to achieve the same thing and at the same time having everything in a git repo. I’m sure this would be very easy to implement.

Changes in the RSS feed

2013-07-03T00:00:00+02:00

Small changes in the RSS feed. My two blogs (tech and travel) won’t be aggregated anymore into a single feed.

The feed on maximebf.com will now only feature my tech articles. The URL doesn’t change (feeds.feedburner.com/maximebf).

The feed for my travel blog is available at feeds.feedburner.com/maximebf_travel.

As I expect to write more tech articles in the near future, I wanted to really separate the two blogs, the travel one monopolizing the feed at the moment.

More changes to come, stay tuned!

Book review: The Lean Startup

2013-03-21T00:00:00+01:00

I have known about the Lean Startup movement for some time now. Everything I read about the subject rang true with me. I’m particularly exposed to it reading HN daily where it’s prevalent and my boss at Allmyapps was a firm believer. It was time for me to actually read the book about it.

The Lean Startup movement was started by Eric Ries who’s also the author of the eponymous book. As with most idea books I read, I found it a bit too long. These books tend to repeat concepts multiple time, explaining things in many paragraphs when a couple would be enough. Perhaps this what’s needed to properly communicate ideas…

Anyway, the book goes on to describe the idea, it’s origin, how to implement it and talks about a few case studies. It’s a very interesting read and it convinced me even more.

The Lean Startup takes it’s inspiration from the Lean Industry where everything is built on-demand. The stated goal is to stop wasteful work by focusing on what the customer really wants. Thus, less guesses and strategy but more experiments. Work should revolve around a Build-Test-Learn feedback loop which should be as quick as possible, speed being a major aspect of a startup. Startups shouldn’t be scared of pivoting, ie. changing course, when their growth is stuck.

I liked how Eric insists on not misinterpreting his idea as something opposed to management. The Lean Startup is a new management method for a world where the classical pyramidal scheme does not work anymore. I can’t tell if the Lean Startup is the way forward but I firmly agree with the precept.

The Five Whys is an interesting concept that I had never heard of before. The goal is to find the root cause of a problem asking your team “why” at each problem like a kid would do. Eric acknowledge the difficulty of putting in place such meetings but is convinced of the effectiveness of this method and explains how it worked well in cases he was involved.

I’m still wondering if the Lean Startup could really be applied to large companies. Eric is convinced that it can and demonstrates it with a few case studies. However, in most examples, it’s a small group inside the company. My doubts arise from the fact that I’m not convinced most employees wants to be involved as much as it is required by such a structure. In the same way, I think most management people will fight these ideas as much as they can.

The Lean Startup asks a lot from individuals. It implies rethinking the whole chain of responsibility as well as asking people to be more humble and respectful of others even in the face of difficulties. While this may be possible in small groups where people are carefully selected, I think it may be too optimistic about human nature to make it work at scale.

When I think how management works in France, we are decades away of even considering using this kind of new methodologies. The US has always been in the forefront in business thinking and I can understand how these ideas could make there way inside big companies. Unfortunately, the prevalent opinion in France is that only elites, having studied in the Grandes Ecoles, are able to manage people and that anybody else is simply an idiot that needs to be told what to do. Good luck explaining to them that they shouldn’t strategies everything.

Overall, I’m convinced this is the best management method (that I know of!) for startups. It allows to build flexible and resilient companies built to satisfy the customers and follow them as things changed.

Publishing PHP libraries using Github, Travis and Composer

2013-02-18T00:00:00+01:00

While PHP had a package manager for a long time, in the form of PEAR, it never really took off or become ubiquitous. The most common way to install a library has always been manually which is a shame given how practical a package manager can be.

Fortunately, things are changing for the best since Composer. This package manager, inspired by NPM from Node.js, is getting a very good traction and, I think, is slowly becoming the de facto PHP package manager.

In combination with Github and Travis, the trio gives you all the right tools to publish and manage your Open Source PHP library.

I don’t think Github needs any kind of presentation but you may not know Travis. It is an online continuous integration service (based on the Open Source project of the same name). Basically, it runs your test suite for you and sends you a report each time some commits are pushed on Github. You may have noticed the small green badge “build successfull” on some Github projects which indicates that they’re using Travis.

Setting up your project to use these tools is pretty straightforward. First you’ll need to have a good organization in your repository. Messy source codes are harder to dive into and harder to manage. Prefer saving the actual source code of your project in a src or lib folder (your pick, there doesn’t seem to be any real convention) in the root of your repository. Use a coding convention and choose your namespace organization accordingly. Follow the PHP FIG conventions as much as you can, they’re becoming the standard.

Your library should be testable. Writing unit tests can be a hassle but it makes the whole thing much more easier to maintain, easier for other people to contribute and (most of the time) avoids introducing bugs in existing code. The most common unit testing library in PHP is obviously PHPUnit. Save your test cases in a tests folder in the root of your repository. Create your phpunit.xml.dist file. Mines usually look like this:

<?xml version="1.0" encoding="UTF-8"?>

<phpunit backupGlobals="false"
         backupStaticAttributes="false"
         colors="true"
         convertErrorsToExceptions="true"
         convertNoticesToExceptions="true"
         convertWarningsToExceptions="true"
         processIsolation="false"
         stopOnFailure="false"
         syntaxCheck="false"
         bootstrap="tests/bootstrap.php"
>
    <testsuites>
        <testsuite name="Example Test Suite">
            <directory>./tests/</directory>
        </testsuite>
    </testsuites>

    <filter>
        <whitelist>
            <directory>./src/</directory>
        </whitelist>
    </filter>
</phpunit>

Note that I use a tests/bootstrap.php file which is ran before the test suite. It sets up the include path and any dependencies. The library source code is located in src.

Travis needs a travis.yml file at the root of your repository. You’ll find more information here but it is a very simple YAML file, here is an example:

language: php
php: 
  - 5.3
  - 5.4
script: phpunit

If your library has any dependencies managed through Composer, add this line:

before_script: composer install

To enable Travis for your project, signup on their website using Github and choose which projects should be tested.

Before announcing to the world your great new library, don’t forget to provide a LICENSE file containing the full text of your license and a README (or README.md for a markdown formated file). It should at least explain what the project is about, how to install it and the basics of using it. If a README is not enough, consider writing proper documentation (maybe using Beautiful Docs). It’s always a good gesture to provide an example usage of your library. I usually have an example.php file or an example folder for more complex projects.

To add the Travis build status to your README.md, add the following markdown snippet (replace example/example with your project name):

[![Build Status](https://travis-ci.org/example/example.png?branch=master)](http://travis-ci.org/example/example)

To be able to publish your project using Composer, you’ll need to provide a composer.json file. The project has a pretty good documentation. Here is a basic one:

{
    "name": "example/example",
    "description": "One liner description",
    "keywords": ["keyword"],
    "homepage": "https://github.com/example/example",
    "type": "library",
    "license": "MIT",
    "authors": [{
        "name": "John Doe",
        "email": "john@example.com",
        "homepage": "http://example.com"
    }],
    "require": {
        "php": ">=5.3.0"
    },
    "autoload": {
        "psr-0": {"MyLibraryNamespace": "src/"}
    }
}

The project name is in two parts, the first one being the vendor name and the second one the library name. Note the autoload section which specifies that the PSR-0 convention is used as well as the namespace and the source code location.

Signup on Packagist, the main Composer repository. Connect your Github account and activate which projects Packagist should publish. Note that version numbers are tracked using Git tags (git tag 1.2.3 and git push --tags).

You can now patiently wait for your first issue or better, your first pull request ;)