The Brief on Developer Book Clubs

Perhaps not much of a surprise but working as a developer requires a great need for continuous learning and growth, and of course this is not always an easy task. Some time last year, I found myself struggling to learn functional programming principles. I approached several people at work with some success, but couldn’t make the most of the opportunities for discussion - often these were just snatches of time between meetings or over a beer. Obviously there was a great willingness for learning but no real platform to make the most of it. I strongly believe that a platform and structure is perhaps the most important component when approaching a technical topic for the first time, to enable a sense of progress and reflection. This led to the creation of the developer book club at my workplace. In this blog post I want to cover how we run the club, some opinions around this point, and some general challenges we’ve faced or anticipate in the future.

How we run the book club

We have three main channels of communication: A GitHub repo, a HipChat room, and a mailing distribution list. The GitHub repo is the place where we put all the written notes and presentations, which I’ll come to later, as well as leverage the issue creation system to enable people to make reading suggestions. The HipChat room is where the majority of online discussion takes place as well as where we make general announcements and potentially vote on the next reading if this has not already been decided during the book club session. Finally, the mailing distribution list allows us to make announcements and book meeting rooms without spamming everyone.

We try to book a session every two weeks, for one hour during lunch, which has so far worked for us. When deciding on readings to focus on, we ideally want something that is freely available electronically with exercises, so that the barrier to entry is as low as possible. We tend to stick to two basic formats, the choice between them following from the kind of reading being covered. For less technical readings, we use as retrospective style format using the labels “liked”, “learned”, “lacked”, which for obvious reasons lends itself to a learning exercises. For technical readings, we use a presentation-style format: Ahead of the session, people are given a section or chapter to focus on, with the expectation that they are able to give a brief presentation in sufficient detail to cover the material. We often combine formats: our first session for a more technical reading follows a retrospective style, then once we’ve established a baseline for what everyone wants to take away from the reading, switch to a presentation style format in future sessions. In all cases, we keep some informal minutes to make note of the key talking points covered.

Going back to the example of learning functional programming, we were able to select an appropriate reading as a group, which in this case was the “Mostly Adequate Guide to Functional Programming”. We have an initial session following a retrospective format, and had two more sessions using the presentational style format. Rather than trying to make notes of everything I had trouble with whilst I read it individually or hoping to simply tease out some meaning from the text, we were able to work through individual problems we had as a group and made great progress.

I think sticking to a format is absolutely key to making the most of these sessions. Firstly, keeping written records of the sessions allows for future reference and reflection. Secondly, both formats makes sure that everyone has to talk about the reading where they may otherwise be unwilling to open up in simple freeform discussion. Finally, a more obscure point, having a format and keeping notes allows people who are unable to commit to every book club to still get involved. Even if they cannot make a session, someone can still go to the repo with an expectation for the kind and quality of notes there. More broadly, every topic we cover is much bigger than any one reading, so enabling someone who may not be able to finish the reading in time to still get involved, but may otherwise know about the topic, is very rewarding for everyone else.

A criticism of this approach might be that it stifles discussion, which is true to a certain extent, but this is also kind of the point! I feel freeform discussion is a much less effective approach to learning in general, and for the reasons above not as inclusive or enabling as a more strict format provides. Discussion will happen regardless and will be more targeted and focused overall.

Problems

That’s all well and good but what kind of problems have we faced, and what do we anticipate? The problems we’ve faced so far are all the ones you’d anticipate: how do we keep numbers up and keep a diversity of interest. We’ve done ok as far a numbers go, averaging around 5 people per session, which considering the level of commitment required is promising. However, they tend to be the same people, which could indicate we need to think more broadly when it comes to reading choices overall. A problem we anticipate in the future is how to approach much longer and more technical readings, in particular several weeks ago someone stated their interest in learning Haskell, which is obviously a big ask. Our thought would be to interlace this activity with shorter, less technical choices, so we both get good progress with the longer term goal as well as a nice turnover of topics and discussion, sessions to session.

Conclusion

Overall I think developer book clubs are a great asset to the workplace and a really important learning platform. In particular I think sticking to a strict format as much as possible makes the most of everyone’s time and makes for a greater learning experience overall.

On a more personal note, I’ve thoroughly enjoyed the time since starting the book club. Whilst I haven’t necessarily touch on topics I wouldn’t have otherwise, I have approach them in a much different way and taken a lot more away from each reading. If nothing else, it’s very enlightening to see how different people with very different skills sets approach the same material and what unique challenges they may be faced with.

In Defence of BEM

BEM is an easy target for criticism in the world of front-end development, it can be verbose, complicated, and just plain ugly. In a world of preprocessors and source maps, it is all the more important to restate some of the advantages BEM can bring,

  1. There is a one-to-one relationship with named selectors in stylesheets and selectors found in the DOM,
  2. Grepping your stylesheets is that much easier because of strict “double underscore,” “double hyphen” syntax,
  3. Natural extension of the above two points: no ambiguity of relationship between selectors, no need to infer by context

Let’s look at an example, the following code is adapted from Robin Rendle’s BEM 101,

.menu {
  background: #0B2027;
  &.trigger {
    background: #16414f;
    float: left;
    padding: 1.3rem 0;
    width: 10%;
    text-align: center;
    color: white;
    font-size: 1.5rem;
    -webkit-transition: .3s;
            transition: .3s;
    &.active {
      background: salmon;  
    }
  }
}

Taking advantage of a preprocessor, we can nest sibling selectors to create a concise code snippet. However we can already see some possible problems that may arise,

  • It is only clear what we should expect .active to do by reference to its nesting, we’d need to take advantage of @import rules to properly namespace,
  • Is this really scalable? How often can we expect this set of class names to occur in the future?
  • What about JS hooks?

A fully BEM solution would produce,

.menu {
  background: #0B2027;
}

.menu__trigger {
  background: #16414f;
  float: left;
  padding: 1.3rem 0;
  width: 10%;
  text-align: center;
  color: white;
  font-size: 1.5rem;
  -webkit-transition: .3s;
          transition: .3s;
}

.menu__trigger--active {
  background: salmon;
}

Though perhaps arguably less attractive to look at, there is certainly something to said for being explicit. To slightly abuse the conclusions made in Ben Frain’s Enduring CSS, for the small risk of extra bloat in the short term, there is the promise of greater mobility in the long term. CSS selector naming is first and foremost about communicating intent to other developers, especially those that may not be exclusively front-endians. With BEM, there is an explicit flat relationship between selectors, which is clearly communicated in CSS and HTML: No need to dig around to know that .menu__trigger--active implies a state change and relates to a specific child/component.

All the best,

Tom

Serving Up Hamburger Menus - or Not

Hamburger menus have a problem. Best put by Luis Abreu’s post against needless use of the UI, hamburger menus,

  1. Lazily put together too many UI elements, which means that,
  2. They are less usable, which leads to,
  3. Poorer user engagement.

More important still is to remember why a hamburger menu is a popular choice for dealing with navigation in the first place: We want to transplant a desktop experience to a mobile experience. This is a crucial mistake to make, and overlooks the golden rule “content is king.” Jonathan Fielding took this head on in a recent Front-end London talk, by selectively choosing which content to prioritise for a given device. In a move towards a responsive, mobile-first web experience we are routinely required to tweak performance for efficient delivery of assets by device type. This is exactly how navigation and UI should be treated.

Instead of lumping all UI elements under the hamburger, Luis Abreu shows exactly how to keep as much up front as possible using a tab bar. This may require trimming away of some elements, or a least a tidy up a desktop navigation. Although this solution may not be entirely scalable, it at the very least allows us to engage our information architecture head-on - something that would be easily hidden by using a hamburger menu as a first step.

All the best,

Tom

Nesting Lists

Dealing with nested lists in HTML gave me pause for thought recently as though simple the markup is not immediately obvious. Intuitively I’d go for placing the markup for the nested list as a direct child of the parent list, like so,

<ul>
    <li>List item one</li>
    <li>List item two</li>
    <ul>
        <li>Subitem 1</li>
        <li>Subitem 2</li>
    </ul>
    <li>List item three</li>
</ul>

However, ul elements may only contain list item elements. Direct from the W3C wiki, “the nested list should relate to one specific list item.” Hence the markup should be,

<ul>
    <li>List item one</li>
    <li>List item two
      <ul>
          <li>Subitem 1</li>
          <li>Subitem 2</li>
      </ul>
    </li>
    <li>List item three</li>
</ul>

Minor point perhaps, but good markup is better for your users and makes your life easier in the long run.

All the best,

Tom

CSS Percentage Margin/Padding Properties

Definitely a candidate for one of my more recent WTF moments. I recently discovered, and subsequently had to work around, the following CSS behaviour: margin/padding-top/bottom percentages are calculated by reference to the width of the containing block, not the height.

This is at the very least slightly confusion especially as CSS enables you to calculate top/bottom with respect to height as expected. I’ve not found an especially clear explanation for this, however most opinions converge on the following,

  • We tend to set/deal with widths, not heights explicitly,
  • It makes rendering that much easier for “horizontal flow,” as discussed here,
  • There has to be some shared reference between margin-top, margin-left etc. as setting margin:5% is a thing.

The end result being that setting resizeable aspect ratios are a breeze as we have constant referring to the width of the element in question. Others, much braver than myself, have looked in to how to explicitly set something equivalent to top/bottom-margin. However, I would advise against this as it exploits the quirks of the CSS specification, which is never a good place to be.

All the best,

Tom

CSS Counters

CSS counters provide a really convenient way of adding academic-style numbering to your markup, with the added advantages of being well supported and easily expandable to an arbitrary indexing style and depth of nesting.

Provide you have some markup to get started on, you will need to specify the following properties counter-reset, counter-increment, and content. The first property relates to the containing element of our counters, creating a new instance for the counters. The latter two relate to how the counters are displayed on the page. For instance,

<body>
  <!-- 'Ere be imaginary markup -->
  <section class="content-section">
    <h2 class="content-section-heading">Awesome Heading</h2>
    <p class="content-text">Awesome text</p>
    <p class="content-text">Awesomer text</p>
  </section>

  <section class="content-section">
    <h2 class="content-section-heading">Another Heading</h2>
    <p class="content-text">More text</p>
  </section>

</body>

For this example, I’d like to have the elements with class “content-section-heading” numbered as “1.”, “2.”, and so forth, and each paragraph element with class “content-text” numbered as “1.1”, “1.2” etc. where the first number corresponds to the “content-section-heading”, and the second corresponds to the number of the p element. In the following we refer to the two numbers as “section”.”sub-section”,

body {
  /* Set section counter to zero */
  counter-reset: section;
}

.content-section-heading {
  /* Set sub-section counter to zero, following each "h2.content-section-heading" */
  counter-reset: sub-section;
}

.content-section-heading:before{
  /* Render section counter to page with decimal and trailing space */
  counter-increment: section;
  content: counter(section) ". ";
}

content-text:before{
  /* Render section and sub-section counter to page with decimal and trailing space */
  counter-increment: sub-section;
  content: counter(section) "." counter(sub-section) " ";
}

Altogether we should get,

<body>
  <!-- 'Ere be imaginary markup -->
  <section class="content-section">
    <h2 class="content-section-heading">1. Awesome Heading</h2>
    <p class="content-text">1.1 Awesome text</p>
    <p class="content-text">1.2 Awesomer text</p>
  </section>

  <section class="content-section">
    <h2 class="content-section-heading">2. Another Heading</h2>
    <p class="content-text">2.1 More text</p>
  </section>

</body>

CSS counters are highly customisable, allowing you to specify the unit to increment/decrement the counters, and the number of counters changed at any one time.

All the best,

Tom

JavaScript: Expressions v Statements

JavaScript, like many other languages, distinguishes between expressions and statements, which means you should too. However, the terms do not refer to a particularly clear cut syntactic difference in many cases and often the difference is largely context specific.

The simplest definition of these terms: Expressions produce a value, or stand in wherever a value is expected, these act without producing any side effects. For instance, examples are taken from Rauschmayer’s review of the subject,

myvar
3 + x
myfunc("a", "b")

On the other hand, a statement provides an action or behaviour, such as a loop, if statement, or function declaration. (Most authors lump together declarations with statements. this is not exactly true as, for instance, declarations are treated differently in the hoisting process.) An important unidirectional relationship exists between expressions and statements: A statement may always be replaced by an expression, called an expression statement. The reverse is not true. The distinction becomes more muddy from here!

A particular problem relates to the difference between function expressions and function declarations, which look essentially the same,

// Function expression
var greeting = function () { console.log("Hello!"); };

// Function declaration
function greeting() { console.log("Hello!"); };

I wasn’t lying! The devil is in the details: the function expression returns a function object which we’ve assigned to the variable greeting. The function expression here is actually anonymous - there is no name given on the right hand side of the equals sign. A named function expression such as,

// Named function expression
var greeting = function howdy() { console.log("Hello!"); };

has the name howdy that is scoped to the function expression. The function declaration on the other hand, declares a new variable, with a new function object assigned to it. This produces something equivalent to the function expression above,

var greeting = function () {
  console.log("Hello!"); 
};

Unlike function expressions, function declarations cannot be anonymous, which is why the the first example function expression was an expression not a declaration. This is an important point as this implies IIFE pattern has to be a function expression.

Without going into any great detail, the distinction between function expressions and function declarations also shows up again in the topic of hoisting: only function declarations are completely hoisted.

The discussion only continues from here: Whether statements or expressions are more performant - I accept it’s a nonce word, or which better lends itself to best-practices.

All the best,

Tom

Blogging Best Practices: Categories v Tags

Categories and tags can be a very useful tool to help make a blog/website more navigable for users and boost SEO to boot. However the specific execution of these features are very much a matter of personal taste and discussion of the subject quickly leads to confusion. This is even more the case for a blogging platform such as Jekyll, which has both few plugins to automate the process and best practices. I myself am guilty of blindly using the very straightforward YAML declarations that Jekyll supports without any real forethought. Wordpress however provides very explicit documentation on the subject, which we can use as a good starting place.

Very simply, categories describe the gross structure of your blog, tags label specific entries. By analogy consider a publication, categories would be the table of contents, tags would be index headings. With this in mind we can anticipate that there will always be at least as many tags than categories, most likely more. The exact number depending on the breadth and depth of topics you choose to blog about, and the level of specificity each category contains. Generally speaking, tags describe something about a particular post, categories group several posts together. Once you have come to a decision how you will use categories and tags in your blog, consistency is key to make the most of your conventions. Another point to bear in mind, more specific to tags, is to make sure to use them effectively. Tags can be both underused and overused, ideally - I use the term very loosely here - you want each tag to be used more than just a few times, without being used for any and every post. Another way to think about this is whether or not the tags actually inform or help users. Analytics services could be helpful here to indicate user flow through your blog.

In practice, the first step is to think ahead: anticipate the breadth and depth you could possibly write about. Although this might not be entirely realistic, it will help prevent the problem of tagitis in the future. Beyond this, you may wish to think about how a user may navigate using categories or tags. As mentioned above, Jekyll tends to have a fairly sparse set of plugins, though there are some authors who have looked at this specific issue.

All the best,

Tom

jQuery Tips

This is a very short post on some useful tidbits I’ve learnt using the ubiquitous jQuery library. I have occasionally found myself in a sticky situation because either (a) the library had not loaded, (b) I’ve been using the wrong version.

We can check if the library is available to us by using either a bang (or two), or using the instanceofoperator. We can use jQuery and $ interchangeably, as they are aliases.

// Load library if it hasn't already
if (!window.jQuery) { 
  // code goes here ...
}

if (typeof window.jQuery == 'undefined') {
  // 'ere be code ... 
}

In the previous example we used window.jQuery as this will simply result in a truthy output. Using just jQuery or $ alone with the leading bang will lead to a reference error.

We can get the version number by logging one of the following,

// Either ...
jQuery.fn.jquery // or jQuery().jquery

// or equivalently
$.fn.jquery // or $().jquery

Of course, we would need to know the library had already loaded before checking the version!

Short and sweet!

All the best,

Tom

High Performance CSS

CSS performance covers a wide range of topics. We can mean anything from selector performance, property performance, architecture practices, and file size to mention a few. At times all these considerations pull in different directions, as what is most efficient for browser processing is least efficient for the developer’s time. This is especially true in relation to selector performance as the most efficiently rendered selectors, ids, are least practical for the purpose of CSS architecture. For the purpose of this post, I’m going to ignore the issue of selector performance as it quite difficult to predict performance costs ahead of time, can lead to bad practices (as already mentioned), and is highly browser dependent. (That said, there is a point to writing well structured selectors, but generally speaking this will be the place where good architectural practices step in.)

We instead want to explicitly look at the overall stylesheet size and property performance to achieve consistent, reliable, and meaningful performance gains for our stylesheets. In relation to the former, it is probably no surprise that a smaller overall file size performs better simply as there are fewer bytes to send over the intertubes. However the gains in rendering time can be significant to say the least. Sticking to a consistent CSS architecture style is the first step to creating smaller stylesheets. Further down the line, we may need to prune unused styles to reduce file size.

Property performance is not often discussed but if neglected can cause real performance problems. Costly properties are those that slow down the render tree construction most. These are properties that require the browser to perform more manipulations, repaint or reflow, in order to paint to/reorganise elements on the screen e.g. a background colour with a gradient as opposed to a plain background. For a WebKit based browser, “border-radius” and “transform” have been shown to be some of the most expensive properties. Our overall design should be sparing with browser reflows and repaints.

The main take away: solid CSS architecture is the gift that keeps on giving, it will empower developers to maintain a DRY, semantic stylesheet, which ultimately leads to performance gains come rendering time. This topic also touches on the issue of Critical Rendering Path optimisation, which I will cover in the future.

All the best,

Tom