Blog

It’s a couple of weeks since I first wrote about LESS. The good news is that we now have a solution that bridges the gap between PHP and LESS. The even better news is that we have LESS generated CSS in production today, and that it does not impact end user load times or radically alter our development flow.

Recap

Shortly after writing about our anticipated use of lessphp, I discovered that its coverage of the language is incomplete; it failed to compile Twitter Bootstrap for example.

less.js is the LESS implementation of choice, so I worked with LESS.app for a few days (a simple Mac app’ for compiling LESS files locally that uses less.js under the covers) to get a feel for how LESS would fit into our development process. I found, for instance, that I wanted both .less and .css files checked into SVN (initially at least).

I also had to get up to speed on node.js as a server side container for less.js, a positive experience that I wrote about on my personal blog.

Our Solution

In our development environment:

1. A custom HTTP LESS server is running on our dev machine on node.js, listening on a specific port
2. Where we minify and concat our CSS at request time, we now also make requests to the LESS server for CSS files that have a corresponding .less file
3. The LESS server takes the .less files referenced in each of the local HTTP GET requests and compiles them
4. The LESS server runs as root and as such is capable of writing to the local file system (something that would be difficult to do as part of the execution of a web request within apache)
5. The compiled CSS is served, and is persisted in the file system ready to be checked in.

N.B. The CSS file corresponding to the LESS file being compiled should already exist at request time time. This ensures that the node.js process running as root will not create files within developer file systems, it will only modify existing files.

On production hosts:

1. Static CSS (albeit CSS compiled from LESS and checked into SVN) is served as it always has been

Try it yourself

Our less server is available as a Slytrunk repository on github.

Tags: architecture | less.js | node.js | php | css

It seems as though adding ellipses to pagination navigation would be straight forward, and that concise utilities would exist to help out. Two incorrect assumptions later, I set about tackling the problem and packaging the resultant code as a utility, available from Sly Trunk on github.

Desired behavior

• First item visible
• Last item visible
• Selected item visible
• Remaining number of visible items surround selected item, favoring looking ahead
• Number of visible items a parameter

The utility annotates the input array of items based on this logic. The annotated array can then be serialized to HTML including tag classes corresponding to the newly added ellipsis annotations, and then be styled accordingly.

Further, the utility provides the option of annotating the markup in such a way that the client (JS in the browser in our case) can update the ellipses in page for dynamic navigation. I avoided duplicating any of the logic used to determine which items were hidden etc. via simple bounding box annotations.

It’s a fairly straight forward algorithm when laid out in code, and it exists as static functionality within a single class with a demo file on github - let us know if you find it useful, or find any bugs!

posted by Ben.

Tags: pagination | github | web utility | navigation | php | javascript

This past weekend we ran into an issue where our Memcache keys were mysteriously disappearing.  After an entire day of debugging (in production no less), we finally figured out what exactly was happening.

Symptom: We maintain a list of keys for a given tag.  For example if we have a tag called ‘players’, we will keep a list of all the sql queries we do for the players table and if the players table gets updated, we can then clear all those sql queries by getting the cache id from the tag. Randomly, it felt like items in the tag would just disppearing even though we never explicitly called our clear tag function. Part of the code looks like this (we use the Zend Framework, so the cache object is wrapping the actual memcache object):

What was happening is every once in a while the load() call on the tag would fail which essentially erases our list that we were keeping.  There were NO error messages from PHP or Memcache that showed the failed call.

Our setup is with a pool of memcache servers and several webservers.

Solution:  The end result was some of the webservers were incorrectly configured on the network switch and causing huge latency to retrieve keys from memcache.  Instead of going straight to the memcache servers to retrieve the data, the packets would end up going outside the network through the F5 (load balancer) and then to the memcache servers. (not good!)  For some reason, this would cause the ‘get’ to fail and thus erasing our list, yet not give any error messages.  Once the network was fixed, everything purred like normal.

Tags: memcache | php | network

I discovered LESS after adopting Bootstrap for my personal website. LESS extends traditional CSS syntax, adding dynamic behavior via variables, mixins (reusable chunks), and nested rules among others. Less.js is probably the best known implementation of LESS, however there are LESS compilers for various other languages, including lessphp. This means that LESS can be incorporated within existing architectures without the need to adopt Node.js. Also, all existing CSS files are also valid LESS files so it is possible to incrementally add LESS markup to a code base after enabling LESS, (note that LESS will transform pure CSS too though).

Adding dynamic behavior to CSS is an attractive proposition, but the adoption of LESS requires some careful thought. The concerns that emerged during our conversations in the office boiled down to:

• The introduction of a compilation step since LESS needs to be interpreted and transformed into regular static CSS.
• Future proofing for a world where LESS is possibly no longer supported.
• The introduction of a disconnect between the code being written in LESS and the corresponding CSS being interpreted by the browser.

The compilation is the biggest concern, so here is a look at our options.

Introducing a Compilation Step

It turns out LESS compilation is slow. After exercising LESS with some real files (mostly static CSS, with little flourished of LESS), it became evident that the time taken to compile LESS is nontrivial; taking around 1 second to compile the CSS needed for the top page of Wonderwall for example.

It is well documented that client side compilation via Node.js is not practical, but it is worth reemphasizing that client side interpretation is out of the question. The end user cannot suffer as a result of increased page weight or rendering time, especially not solely to diversify our code base! With this in mind, we have three options:

1. The first time a LESS/CSS file is requested from the browser, we compile it, serve it, and cache it. We would do this both in development and production. It’d make the initial request slower, but not that much slower, and it would happen infrequently. The LESS and compiled CSS versions would be essentially the same file; only the LESS file would be under version control. The CSS version would be transient, only living in the cache.
2. In development we do on demand compilation as in #1, but in production we make the LESS compilation part of our deployment/build script. So our production servers would have the compiled CSS and not incur the performance hit of #1. Again, only the LESS version of the files would be under version control. The CSS version would exist in cache in development and on the filesystem/cache in production.
3. Compiled CSS in production like #2, but with some kind of gross manual compilation step in development. We would have both CSS and LESS files under version control and have an added disconnect of editing a different file from the one we’re including in our templates.

Right now, we’re weighing up #1 and #2, leaning towards #1 for simplicity. We need to get some metrics around the frequency of cache population before we roll it out though.

posted by Ben.

Tags: css | less css | lessphp | production

Welcome to the new Sly Trunk Blog.  We will periodically discuss technical problems (and hopefully some solutions) that we face from day to day.  We work on some cool projects like NFL.com Fantasy Football and Wonderwall.

Enjoy.

The Sly Trunk Team

Tags: welcome | nfl.com | fantasy football | wonderwall