Email iconarrow-down-circleGroup 8Path 3arrow-rightGroup 4Combined Shapearrow-rightGroup 4Combined ShapeUntitled 2Untitled 2Path 3ozFill 166crosscupcake-icondribbble iconGroupPage 1GitHamburgerPage 1Page 1LinkedInOval 1Page 1Email iconphone iconPodcast ctaPodcast ctaPodcastpushpinblog icon copy 2 + Bitmap Copy 2Fill 1medal copy 3Group 7twitter icontwitter iconPage 1

This November saw some of the UVD troop head down to sunny Brighton for Full Frontal Conf, and not for the first time.

As always – a fantastically curated set of talks with a diversity of topics by Remy & Julie Sharp. We thought we’d pick one of our favourite talks and share a bit about what we learned below. The talks are all available on youtube.

“A Brief History of Modularity” – Ashley Williams

I wasn’t quite sure what to expect from this talk, but I was pleasantly surprised. The talk, although a little haphazard, did touch on many important issues around modularity. Ashley covered topics such as how people currently think about modularity, the harmful effects of “micro” modules, and the correct way to think about modularity (as well as briefly skipping over the left-pad fiasco). She also discussed some metaphysical questions, which loosely relate to modularity, like “what is simplicity?”, “what is information?” and “do dogs know calculus?” (it made sense at the time, honest).

One of the most interesting parts of the talk was the bit about the history of modularity. It turns out that modularity is an old problem. People have been thinking about how to approach modular programming since the 1960s. Ashley quoted David Parnas, one of the pioneers of modularity, who said in a 1972 paper that we should “[Start] with a list of difficult design decisions which are likely to change. Each module is then designed to hide such a decision”. It would seem then that modularity is a solved problem, at least in a general sense. What I found surprising is that developers today (including myself) are still unsure how to split their code into modules. When Ashley asked devs on twitter “how do you decide what goes in a module?”, she got answers such as “intuition” and “I throw darts”. Oh dear.

Ashley also gets extra points from me for quoting Rich Hickey’s “simple made easy”, and highlighting the difference between an easy module and a simple module.

dave

Dave

Senior Frontend Developer

“Optimise your web development workflow” – Umar Hansa

Having the skill to efficiently debug and measure the performance your web creations is possibly one of the biggest boosts to productivity and quality you can gain. The Chrome Dev tools provide that power but their greatness can be shrouded in myth and mystery (or, you know, flags).

@umaar gave a fantastic tour – given the time available – of some of the new features, techniques and workflow in upcoming versions of the dev tools that are available now or in Chrome Canary.

Highlights:

  • Workspaces: working with your code directly in the browser with changes being saved to disk. Some notable improvements coming in the future too (https://umaar.com/dev-tips/123-workspaces–2–0/).
  • Performance measuring with the performance API (https://developer.mozilla.org/en-US/docs/Web/API/Window/performance)
  • Profiling render times and frame performance with paint profiling and FPS meter (https://umaar.com/dev-tips/120-paint-profiler/)

There were some other interesting improvements covered such as proactive JavaScript compilation in the sources tab and multi line input in the console. There was also an integrated terminal in the dev tools at one point. All in all a fun ride through all the improvements coming in the future to our workflow, and interesting insights into how our tooling is getting closer to the metal where we’re working. Will dev tools become a fully fledged IDE at some point?

I’d highly recommend signing up to his tips newsletter and watching the talk.

ryan

Ryan

Senior Frontend Developer

“All Things Continuous” – Andrew Martin

Having recently taken a deep dive into the wonderful world of DevOps, when I saw the FFConf schedule Andrew’s talk really jumped out at me. I was hoping to have some of the decisions that I made when re-architecting the infrastructure of a key project validated, but also to pick up some tips and tricks on the way.

Andrew covered a huge amount of information within his 45 minute timeframe. I was really pleasantly surprised at how deep he went into the subject matter. We were already sold on Continuous Integration and have been refining our use of it over the last year, but Andrew’s insistence that Docker was the way to go has encouraged me to re-think our use of Virtual Box VMs for local development.

It was great to see Terraform make an appearance in the talk, which we’re using to orchestrate our infrastructure. Also covered was the monitoring tool DataDog which may soon be introduced to our stack as a direct result of this talk!

eddy

Eddy

Lead Developer

Share: