Stylify Me

A crucial part of the creative process is researching current trends and advances in the design industry. This is a time consuming task involving inspecting the CSS of sites, taking notes of design elements, and evaluating them before choosing a design direction. We discussed how there was an opportunity to make this process easier, and Stylify Me was born.

Stylify Me was created to help designers quickly create a style guide of an existing site, including colours, fonts, sizes and spacing. It’s a tool that allows the designer to research the CSS styles efficiently without the need to inspect each element, in order to be aware of current design trends and inform their design decisions.

Retrieving CSS styles from a website is easy when you can query against the actual DOM elements, but as many sites cannot be opened in an iFrame, a client side only approach was not an option. Michael had previously heard of PhantomJS, a scriptable, ‘headless’ WebKit browser, on the Javascript Show Podcast. ‘Headless’ means it runs without a GUI (Graphic User Interface) from the command line, allowing a JavaScript file with processing instructions to accept arguments like a URL or file path.


Running a load speed script from PhantomJS’s example library.

PhantomJS is commonly used for test automation and web crawling but it did exactly what we needed: loading a website, running scripts against its DOM and saving screen shots – all in a real browser using JavaScript. PhantomJS comes with an experimental server but we decided to call it from Node.js as it has a lot more to offer in terms of stability and performance. Furthermore we can leverage express, a small but very convenient development framework for Node.js.


The step-by-step process of analyzing the styles for

In our processing instructions for PhantomJS we analyze the text and background colours of all elements on the page and order them by quantity, giving some, for example, the main background and the main text colour, a higher priority. Next we look for the main text element. For proper HTML5 markup this is simple, we just need to look for the role=”main,” but in reality a lot of websites use old and irregular markup, which requires us to look for common id and class names. If this does not work we simply use the middlemost element – in the hope that this is part of the main copy and not the side navigation. Based on this selection we extract the CSS styling of the text and headlines and return everything as a JSON response back to the user.

If you’re interested in learning more about the technical side of Stylify Me, you can check out the source code of the service layer on Michael’s GitHub.

Stylify Me was a fun, collaborative project to work on. We hope it becomes a useful tool that helps make the design process a little easier.…

Boosting teamwork with Vagrant

Boosting teamwork with Vagrant

In September I was fortunate to be able to give a talk at DjangoCon US, the largest annual conference about the Django web framework. The topic of the talk was on Vagrant, a free open-source tool facilitating the manipulation of virtualized environments, and how it may benefit the development of Django applications. This talk was aimed at Django developers of all levels who were interested in getting an overview of the great possibilities Vagrant offers to support teamwork and quality assurance. In this article, I provide the same overview of the issues and solutions as addressed in the talk, albeit in broader terms that should be compelling to all kinds of web development teams, regardless of their framework or programming language of choice.


Common issues for web development teams

Over the last couple of years, a number of things have contributed to making the lives of developers easier, in particular the emergence of cloud computing, of both backend and frontend testing frameworks, and of distributed version control systems such as Git. However, the web stack specifications have also become more complex in order to provide the features that are now commonly expected by web users and to respond to ever increasing levels of traffic on modern web sites and applications. Indeed, it is now often necessary to use components such as RabbitMQ, Hadoop, Solr or Redis, just to name a few. As a result, web teams nowadays tend to be recurrently confronted with two types of issues:

  • Code sometimes unexpectedly breaks in production whereas it worked on development machines prior to being deployed. This type of unanticipated problems is often due to the inconsistencies that exist between the team members’ platforms, and to the inconsistencies between the development and production environments. Indeed, many web developers nowadays use Mac and Windows computers as their primary development platform, whereas the vast majority of websites eventually get deployed to Linux machines.
  • On-boarding new developers tends to be difficult and time-consuming. This is true especially if the person that you are on-boarding does not have much experience with systems administration, for example a frontend developer or a designer. If you are well organized, you might have long wiki pages describing every step required to manually install all of the technical requirements for your project. However, keeping those wiki pages up to date is hard, tedious and uninteresting, and so is having to manually execute all the required steps every single time a new person joins your team. What’s more, the web developers who work on Mac or Windows platforms often have to go through extra pain as the installation of certain software, such as MySQL or PostgreSQL for example, are generally much more difficult on their platforms than it is on Linux platforms. The net result is that developers end up having to spend a lot of time administering their systems, whereas they would rather spend this time writing code and building features.

Vagrant to the rescue

The issues described above would not occur in an ideal world where all developers of a same team worked on the same, pre-built platform: there would be no need to manually install anything and the working environment would automatically be assembled so that developers may solely focus on their development tasks. In that ideal world, the development and production platforms would also closely match so that no more bad surprise would occur when new code got pushed live. The good news is that this world already exists — and it’s called virtualization.

Virtualization is nothing new, really. It has been around for a long time. However, in the last couple of years it has become much more approachable and useful to developers, especially thanks to a project called Vagrant. Essentially, Vagrant is a developer-friendly interface for managing virtual machines (VM). Currently the only VM manager supported by Vagrant is VirtualBox, but there are plans for it to support VMWare in the future as well. In a nutshell, with Vagrant the workflow for a given developer is as follows:

Boosting teamwork with Vagrant

The developer interacts with Vagrant by running a few simple commands. The main command is ‘vagrant up’ (1) for booting the VM up, that is the equivalent of pressing the ‘on’ button of a physical computer. The developer also has to provide a configuration file named ‘Vagrantfile’ (1), which contains some basic directives to specify the characteristics of the VM that needs to be built. Then Vagrant will talk to VirtualBox (2) and instruct it to actually create the VM (3). Vagrant will also talk to some provisioners (4), which are responsible for provisioning the VM, that is, installing and configuring all the software required for running the project’s application (5). Once the VM has been created, booted and provisioned, the developer may directly access the VM (6), …


Peering into the soul of the virtual self

In April of this year I pre-ordered a Pebble, a new smartwatch that became a Kickstarter darling when it raised a kajillion dollars virtually overnight. Other than bragging rights, I want a Pebble because it will allow me to seamlessly track and record the average distance and speed of my bike rides to and from work.

But since my watch won’t arrive until September, I have some time to mull over the implications of self-tracking that Nora Young raises in her new book The Virtual Self: How Our Digital Lives Are Altering the World Around Us. Young explains how the combination of social media and geolocative smartphones now allow us to create elaborate shadow selves comprised entirely of data. Never before have we been able to share our daily activities with the world and also have them link back to our physical locations. The result is “a Data Map, a digital version of our earthly selves.”

The explosion of self-generated personal data has happened so quickly that we have yet to fully understand its implications. Through a combination of research, participatory journalism and in-depth interviews, Young considers the unintended consequences of our ability to post photos of everything we eat to Instagram and track our spending habits via

Young is not interested in scolding her readers, however. As she notes, “It’s easy to sit in judgment about self-monitoring, if you don’t do it. There is, however, something deeply human about the urge to document our lives, to look back at a pattern of our behaviour and make sense of it, to use it to construct the narrative of our lives.”

We are now able to crunch a variety of personal data and compare it against the Data Maps of others, using tools previously available only to major corporations. As Young notes, “The ability to reassemble information in new ways makes personal metrics much more powerful, allowing us to understand the meaning of our behaviour in a new way.” We have become test subjects in laboratories of our own design.

The problem, as Young points out, is that a Data Map cannot be used as a substitute for careful introspection. We can easily track calorie counts and bike routes, but even the most sophisticated pie chart or infographic built from our personal data will never be able to reveal our emotional or spiritual selves. Or, as Patrick McGoohan famously put in the 1960s show The Prisoner, “I am not a number. I am a free man.”

Young also identifies a major paradox: our digital obsession reduces our physical presence in the world, and to compensate for this disembodiment, we’re using the very same technology to try and reaffirm our identity. “Today’s urge to document the self is an attempt not just to assert the self but also to ground the self, to tether it, to re-embody it, to give it heft and substance.”

During a recent talk at Third Tuesday Toronto, Young used the invention of the telephone as a reminder that although technology might nudge us toward certain behaviours, it does not solely determine our actions. Many aspects of the telephone, including what to say when answering it (Alexander Graham Bell suggested “Ahoy”) were negotiated over time. The fancy term for this process is social constructivism, and Young argues in The Virtual Self that “we have the power to shape the character of our technologies.”

As our Data Maps grow in scope and importance, Young suggests that data portability will become a mainstream concern, and we might need to start treating personal data as a form of intellectual property. As Young notes, “The streams of data we’re creating are worth something. We want to access the data for our own purposes, but it’s also potentially useful to governments and to researchers interested in creating smarter policies and more responsive cities.”

In short, by the time my Pebble arrives, I will need to determine not only what I might want to measure, but why I want to track it in the first place.…