Robert Rhoades

Swapping Thonny for Neovim to Dev on my Pico

2026-07-26T00:00:00Z

Like most devs, I tend to swap around editors quite a bit. I've been through a few: Sublime, Coda, Atom, PHPStorm, Eclipse, Visual Studio, VS Code...the list goes on. Lately I've been learning to use neovim (maybe I'll write a post on that) but for the pico I stuck with the default recommended editor Thonny.

Thonny is great for what it is, it makes it easy to get going with the pico and gives you easy ways to put code onto the pico, install packages, and a REPL, its the complete package! But it's not my editor. It doesn't have my theme and as I'm getting used to vim motions going back to a more traditional text editor drags me out of that mindset.

Programming on the Pico isn't like a traditional website however. I need to be able to put the code on the pico, run it and see the output to see what I did wrong! I hope thats the right terminology but I'm relatively new to embedded programming.

My setup

Instead of Thonny I use:

Neovim + Kickstart: Out of scope for this post but its just neovim with kickstart. pyright as my lsp
mpremote: This bridges the gap between my mac and my pico. It lets me run scripts on the pico.
micropython-rp2-stubs: Will get into this later but without this pyright complains about import machine

Setting up neovim and pyright

In neovim under the lsp settings I added the pyright key to enable the python lsp. I'm not sure if this is needed for everything but I assume it is, I need to learn more here.

	local servers = {
		pyright = {},

Doing this means I have syntax highlighting which is great but as I mentioned earlier import machine throws up an error as this exists on the pico but not locally on my project so what we need to do is setup a virtual env and install micropython-rp2-stubs.

python3 -m venv .venv
source .venv/bin/activate.fish # Note for fish shell users!
pip install micropython-rp2-stubs

After this I need to add pyrightconfig.json to tell the lsp that we have some packages to look at

{
  "venvPath": ".",
  "venv": ".venv",
  "reportMissingImports": "none"
}

One thats been done all seems to be fine. I do get a warning but thats better than an error! If I figure out a better solution I'll update this post.

The workflow

Okay I'm all good to go. Now when I want to work on my pico projects I can plug my pico into the mac and then:

cd into my project directory
Open neovim in a pane, then split it with another shell
Run scripts I'm editing using mpremote run <script>
When I'm happy with the final script i can run mpremote fs cp <script> :<script>

Another way to do this is to use mpremote mount . and this will mount the entire directory on the pico and drops us into the REPL. We can then run scripts by typing import <script>. I prefer the simplicity of mpremote run but just wanted to call this out as another option.

Testing Hard Drives with a Raspberry Pi Zero

2026-04-12T00:00:00Z

It's a good idea to test a hard drive before using it. They can fail in any number of different ways and losing your precious memories is the last thing you want to happen.

Testing them involves writing and reading data to the entire disk over and over. The idea being if its going to fail let it be while we're writing gibberish.

In Linux there's a tool badblocks; it writes patterns to a disk and reads them back. For example 0101, 1010, 1111, and 0000 in 4 separate passes. If a block can't be read or written to, it will be logged.

This combined with S.M.A.R.T. data can give you confidence in the drive.

One harsh reality is this process can take a while, days rather than minutes. This varies by size and speed of the disk. A 500GB disk will complete the test much faster than a 20TB disk. Equally a 7200rpm drive will be faster than a 5400rpm drive of the same capacity.

So we know this is going to take a while. Unfortunately the only computer that I have running all day is my NAS. I could run the test on that but one typo and I could accidentally wipe the wrong disk!

I want to reduce the consequences of a mistake by having an air gap from my "production" services.

I have a spare Raspberry Pi Zero 2 W which I can use. It even has a few advantages over my laptop:

It can run Linux.
It's small and low power (2 watts-ish).
It's wireless so can be left anywhere.

It's not perfect though; it's USB 2 so the writes are capped at around 40MB/s. This means our test isn't going to be an absolute torture fest but it's enough to see if these drives will work.

The ports are another downside. While I could have bought a Micro-USB to USB-A dongle, I primarily use USB-C. So I opted instead for a Micro-USB to USB-C adapter. This way, if I'm on holiday with any Micro-USB devices, I don't need to pack a separate charger.

Setting up the Pi

To get started, flash Raspberry Pi lite OS (I used 64-bit but 32-bit would be fine) to the SD card. Also be sure to fill in the extras so the zero can connect to the network, and your public key so you can ssh in.

Put the SD card into the zero and power it on. I like to leave it for a few minutes to sort itself out on the first boot.

After installing the OS, as a best practice, we should check for updates.

sudo apt-get update
sudo apt upgrade

Once done, we can reboot to apply those changes.

sudo reboot

Now lets ensure S.M.A.R.T. tools are installed so we can keep an eye on the hard drives health.

sudo apt install smartmontools

Lets also install tmux so we can leave running commands without stopping.

sudo apt install tmux

Luckily, badblock is usually part of Raspberry Pi OS so we don't need to install it. With that we have all the software we need.

Running the test

Now we can plug in our hard drive into the Pi.

For 3½" drives we'll need it to be powered separately but with 2½" we may get away with using the usb port on the Pi itself. YMMV.

Next lets find our drive name.

lsblk

This will list all our drives. I tend to use the size to identify it. Lets make a note of the name, it'll become very important later on.

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
loop0         7:0    0   416M  0 loop
sda           8:0    0 465.8G  0 disk // < this is our harddrive :)
├─sda1        8:1    0     1G  0 part
├─sda2        8:2    0     1G  0 part
└─sda3        8:3    0 463.8G  0 part
sdb           8:16   1     0B  0 disk
sdc           8:32   1     0B  0 disk
mmcblk0     179:0    0  59.5G  0 disk
├─mmcblk0p1 179:1    0   512M  0 part /boot/firmware
└─mmcblk0p2 179:2    0    59G  0 part /
zram0       254:0    0   416M  0 disk [SWAP]

Open a tmux session tmux and check the drives block size. In the code sample below I've used sda but it might be different so use the name noted previously.

sudo blockdev --getbsz /dev/sda

This will give us a number, such as 4096. In fact most hard drives that are 4 terabytes or greater will have a 4096 block size.

We are now ready for the most dangerous part of the operation. Running our test will overwrite the entire disk so its vital we double check the name of our drive. If there is any doubt, run lsblk again.

sudo badblocks -w -s -b 4096 /dev/sda

We can then quit tmux using ctrl + b and then d.

That's it, we are now testing the drive!

During the test we can take a look at our S.M.A.R.T. attributes at any time.

sudo smartctl -A /dev/sda

It will return something like this:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   164   159   021    Pre-fail  Always       -       4800
  4 Start_Stop_Count        0x0032   090   090   000    Old_age   Always       -       10065
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   100   253   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   001   001   000    Old_age   Always       -       75711
 10 Spin_Retry_Count        0x0032   100   100   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   253   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       86
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       8
193 Load_Cycle_Count        0x0032   197   197   000    Old_age   Always       -       10065
194 Temperature_Celsius     0x0022   109   082   000    Old_age   Always       -       38
195 Hardware_ECC_Recovered  0x0036   001   001   000    Old_age   Always       -       342037046
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   253   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   100   253   000    Old_age   Offline      -       0

It's useful to keep an eye on it for changes.

The Current_Pending_Sector, Reallocated_Sector_Ct and Offline_Uncorrectable are worth keeping an eye on. These identify when the drive was not able to read the data it has written and are indicators of a failure.

Another attribute to keep an eye on is Temperature_Celsius which tells us how hot our drive is in ℃. A good range is 20-45℃ and most drives under test will sit towards the top end of that range.

Finally Power_On_Hours lets us know how old the drive is. My drive has >75k hours which equates to over 8 years!

Happy testing!

What I love most about this setup is how unobtrusive it is. It sits in the corner, quietly testing my drive, sipping watts as it does so.

Should the worst happen, we can start over knowing the damage is limited to the Pi. This alone saves me a lot of stress when running tests!

What's the oldest hard drive you've got still going strong? I'd love to know!

Fixing SMB Transfers on Mac

2026-04-05T00:00:00Z

Setting up my NAS last year was probably one of the best things I did, I'll try and do another post on all that but the long and short is I'm using an old PC with Unraid.

Unraid gives you a few options to connect to your NAS, I first tried SMB, I really liked how Mac Finder just discovered it, I didn't have to remember any IP addresses or special commands.

Reads were good, I could browse directories pretty quick, open up files fine. But writing was extremely slow, and worse with lots of files.

At the time I didn't really know what to do, someone on the internet said try NFS and the transfers were much better. But today accidentally crashed my server (my fault not Unraid) and I thought ok time to give SMB another shot.

I tested this by transfering a folder of varying sized MP4's. Finder doesn't have a fancy transfer rate window like windows does so I used Activity Monitors network view which does the job.

This sawtooth pattern is weird, it looks like finder is transferring one file, then reading it before transferring the next.

The internet said that macs aren't setup great for SMB performance. And after a while of trial and error I settled on this config

[default]
# Disable signing
signing_required=no
# Turn off validation of the negotiate info (helps with signing issues)
validate_neg_off=yes
# Force SMB 3+ for better performance
protocol_vers_map=6

After connecting to an smb share on mac we can run smbutil statshares -a to get a picture of what that looks like. Unfortunately for me signing_require didn't seem to change this to OFF even after restarting.

SMB_CURR_SIGN_ALGORITHM       AES_128_GMAC

I got the same transfer performance when I tested which confirmed more work needed to be done. This config might be unnecessary, and if thats the true I'll update this article.

Next up lets make sure that signing is not on the NAS. In Unraid, Settings > SMB > Samba extra configuration:

# Force signing off
server signing = disabled
strict sync = no

It was adding strict sync = no that made the difference, since adding my network transfer looked a lot more consistent.

Speeds aren't amazing but this is equivalent to NFS so I'm happy. After reading the docs I think it was requiring the server to do a WRITE > READ cycle for every file.

Hopefully this will help you, or more likely future me after I've forgotten about this

Lessons Learned the Hard Way with Dependencies

2023-04-23T00:00:00Z

We're working on adding OpenID Connect to the app. Luckily for us we only needed to create a client rather than the server, that was being handled by another team. Theres a saying in software, don't roll your own security. And for us that naturally lead us to looking for a dependency.

We also noted that OpenID certifies packages for compliance to the spec, pretty handy! We found two for Angular that we thought would work. The first one we tried was a bit of a dud for our cordova setup so we flipped to the other. This worked well and we managed to get the flow to work.

OpenID comes with tokens, these are used to talk to a protected API. They can expire and if they do we can exchange for a new one. It was this exchange task that was the beginning of our problems. Our issue was trying to make the exchange process work with a device that maybe offline for long periods of time. The plugin would simply keep trying every few seconds which caused our logger to fill up with lots of failed requests.

We tried everything to keep the dependency. We tried patching the dependency using something like patch package but this wasn't possible because of the way angular packages are precompiled, perhaps it's possible but that is beyond my skills. We tried treating it like a black box, changing the responses from requests to blank ones. This also didn't work. We even looked at alternative dependencies but they also had issues one way or another.

In the end we were left with only one option. Write our own. In some ways after going down that rabbit hole I'm kinda glad. Writing the code ourselves is daunting in the sense of doing it wrong bu at least its our code, we have the ability to fix it if we need.

What I've learned from this process is that you should use dependencies, but maybe with a little care and nuance which might not always be apparent at the time.

Theres a lot that some dependencies offer. They're often authored by multiple people over a period of years so the code is usually quite well battle tested across a bunch of projects and contexts. This is useful as it decreases the risk of bugs. Sometimes they can also be certified by an external body, for example OpenID projects can be certified for compliance against the spec which is what drew us to using a dependency.

But be careful. It's worth taking the time to look at the dependencies available to you. Look at the common things like:

How many authors are there?
Whats the activity like on the repository?
Is there a lot of recent action or has it been untouched for years? This might not be a bad thing if the dependency does what it needs to and has no bugs but it could also be a sign of a dead project.
Whats the license like?
Can you even use this dependency? Is there a fee you need to pay?

There are also more nuanced things to look at, personal to you, your team & project.

Check out the code. How much of what it does is relevant to your needs? For example our dependency included code for the entire OpenID Connect spec. We only needed the Authorization Code flow so a lot of the code in the dependency was redundant. During debugging this meant we had a lot of irrelevant code to comb through to understand what was going on.

If you do need to tweak, can you? Without it being a bit of a pain in the bum. Some dependencies that are a bit larger make use of adapter / strategy patterns that allow you to write custom code that adheres to an interface. If you can't, is it patchable?

Lastly should you need to switch to something else, what options are available to you? Are you spoilt for choice or is it slim pickings? If its the latter how confident are you in being able to replace it with something you've written?

As for us, we're on the road towards writing our own package. It's a slow process but we're getting there, cobbling together knowledge from specs and other projects to build something that works for us.

Hopefully this ends up turning out okay...

Writing a Tool to Help Test Migrating Lots of Code

2023-02-11T00:00:00Z

My day job involves working on a mobile app for a well known medical journal based in the UK. It provides healthcare professionals with the latest evidence-based clinical decision support information.

These days the tech stack is aging but its much too large to rewrite all in one go. So instead we are doing a phased migration, gradually re-writing the application bit by bit between releases. We are moving from AngularJS to Angular, which incase you don't know is a huge change as it involves a new framework and language!

I would explain more but it's a long story so I'll save that for another post.

This is the first of a series of posts where I hope to write about the challenges we faced and how we got (or didn't get) over them.

In the app we use content from an API that is stored in JSON serialised form. To display content we first transform this into an object before handing it off to the rendering code to display.

As part of the migration we have to rewrite the transformation layer. Problem is theres about 20,000 lines of code (including tests) which increases the workload and also the chances of bugs sneaking in.

As it stands the layer is written as a single class with a bunch of static methods which we mock during testing. One of the issues with this approach is that the file becomes really large and unwieldy as it has to contain transformation code for every single content type. The other issue is that mocking can often mask issues if the mock doesn't reflect the real world.

Instead we switched to using pure functions, because transforming objects from one format to another seems like the perfect candidate for a pure function if you read enough articles about it. For tests we use the pure functions that we've tested elsewhere rather than mocking. Pros are that we're not mocking much code. Cons are that if something goes wrong jasmine doesn't make it the easiest to see whats up. Trade offs innit.

Another issue we have is despite having a lot of tests it's hard to be sure that the new layer works the same as the old layer. This is a sign that the tests could be improved but thats a story for another day.

We could just risk it and fix problems as we discover them but that sounds like a lot of stress too.

A few years ago my friend Tom created a section in the app for dev tooling to live which is super handy. A new tool was added which had one job…

The task

For every topic downloaded in the app, first run all the transformers split between old and new, then compare them! If they match then great carry on. If they don't match then stop and show where they differ in something thats easy to use.

Using this tool we can then be happy that both old and new transformers are working the same.

We'd also need to test this against other content languages such as Spanish. Different languages are an area we are particularly weak testing as most tests use English.

Ok well to build this we have to solve a few problems along the way.

Problem #1: How to flip between old and new transformers?

First up we want to restrict how much code we have to write at once before we can get to testing. The transformation layer is sits below the repository layer so thats where we need to switch between old and new transformers. Each repository extends a BaseRepository class which contains some helper methods that all repositories can use.

In BaseRepository we added a new private method which checks if we should use the new transformer. This keeps the logic in one place instead of spread out across multiple repositories:

_isNewTransformerEnabled () {
  return this._featureFlag.isEnabled('new_transformer');
}

Then in each repository (the layer above the transformer) we call this method to see if we should use the old or new transformer

find (topicId) {
  return this._rawTopicsRepository.findRawTopic(topicId).then(raw => {
    return this._isNewTransformerEnabled()
      .then(enabled => enabled ?
        this._$window.newHotness.topicParser.parse(raw) :
        TopicParser.parse(raw);
    );
  });
}

Cool thats the first problem sorted, we can now toggle between old and new transformers 🙌

Problem #2: How can we toggle the feature on demand?

In the past our feature flag looked at the state from two sources, either remotely via firebase or locally via the codebase depending on the type of flag it was. This is fine 99% of the time but for our tool we wanted to be able to toggle the feature at runtime, otherwise we'd be comparing the same transformer against itself 🤦‍♂️

To do this we added an overrides feature to the feature flag service. This would allow us to have the final say on whether a flag is enabled or disabled.

The way it works is quite simple, we have an array in the service that stores the overrides. We then have a method which lets users of the feature flag service add overrides.

addOverride (flagName, state) {
  this._overrides[flagName] = state;
}

Consumers of the feature flag service call isEnabled() which gets the status of the flag. If an override exists it ignores the original setting and instead resolves the override. We don't check for falsy because we might want to return false from the overrides.

isEnabled (flagName) {
  if (this._overrides[flagName] !== undefined) {
    return this._$q.resolve(this._overrides[flagName]);
  }

  //--- Rest of code gets the flag state from firebase or locally depending on the flag type
}

Cool, so this allows us to change the state of a flag whenever we want. A nice bonus is we have a feature flag dev tool which at the moment just shows the state of the flags. Now we have overrides we could toggle flags on or off from the dev tool which would be pretty neat!

Making the page

Ok so the page is actually pretty simple, it's just some text that describes what it does and a button that starts the testing.

Initially I struggled to write the code to make all this work, sometimes I get myself in a bit of muddle. To recap what I need to do is:

Get all the topics we have in the database
For each topic get more data about the topic so I know its type. Different topic types need a different set of transformers
We then need to get all the repositories related to the topic
For each repository we need to do the following
1. Disable the new_transformer flag
2. Get the data from the repository
3. Enable the new_transformer flag
4. Get the data from the repository again (this time it'll be using the new transformers)
5. Check both to see if they are the same and if not show the difference

I started by getting the topics, then looping over those and getting information about the topics inside that loop, then getting the repositories inside that loop again and then running the tests twice in that loop.

for (const topic of topics) {
 const topic = getTopicInfo(topic);
 const repositories = getRepositoryForTopic(topic);
 for(const repo of repositories) {
  disableFlag();
  const a = test();
  enableFlag();
  const b = test();
  compare(a, b);
  if (bad) {
    console.log(what went wrong)
    break;
  }
 }
}

Imagine this with promises too and its a bit of a mind ~~f*ck~~. So a ranty walk later I switched approach.

Instead we use promises as they were meant to be used and chain them. (Why didn't I do it this way to start with?!). Starting off we get the topics then with that we map over the resolved array to get more info about each topic like so:

this._topicRepository.findAll().then((topics) => {
    return this._$q.all(
        topics.map((topic) => this._topicRepository.findById(topic.id)),
    );
});

Cool we have an array of detailed topics! Thank u, next.

Now we want to turn this list of topics into a list of repositories. To make this easier in my head I used the jobs analogy so we're creating a flat list of jobs to iterate against. A flat list is easier to imagine than nested loops!

_createJobPayload (topic) {
  const jobs = [];
  const repositories = this._getRepositoryFromType(topic.type);
  for (const key in repositories) {
    jobs.push({
      topic: topic,
      repository: repositories[key],
      repositoryName: key
    });
  }

  return jobs;
}

So we take a topic and get the repositories for its type. For each repository we create an array of jobs which contains the topic, the repository and the name of the repository. Unfortunately this returns a nested array like this, which isn't what we want because it makes dealing with it much more complex.

[ [[job1], [job2]], [[job3]], …]

Luckily es6 added a new array method called flatMap which is absolutely marvellous! It turns our nested arrays into a nice flat list 👩‍🍳

.then(topics => {
  return topics.flatMap(topic => this._createJobPayload(topic));
})

And voila! We now have a nice flat array of jobs to test against.

[ job1, job2, job3, …]

Next up (I promise we're nearly done), we need to run the tests sequentially. Normally we could use async/await for this but unfortunately for me this wasn't possible (babel in our build system is too old and doesn't understand async/await syntax, yet another reason we want to update).

I wasn't sure how to do this but a quick stack overflow later I found my answer which was surprisingly simple!

jobs.reduce(
    (promise, job) =>
        promise.then(() => this._test(job.repository, job.topic, job.key)),
    this._$q.resolve(),
);

This uses the reduce function and starts off with a resolved promise, it then chains subsequent promises for each job so we only run the next job if the previous one resolved.

Finally (home stretch now) we need to actually do the test. Yep all this waffle above was just getting to the point where we could actually test! Thank you for sticking with me!

_test (repository, topic, key) {
  console.log('testing…', { topic: topic.id, repository: key });

  let a = null;
  let b = null;
  return this._disableNewTransformer()
    .then(() => this._testRepository(repository, topic).then(output => a = output))
    .then(() => this._enableNewTransformer())
    .then(() => this._testRepository(repository, topic).then(output => b = output))
    .then(() => {
      const transformSame = JSON.stringify(a) === JSON.stringify(b);
      if (!transformSame) {
        console.error(detailedDiff(a, b), { old: a, new: b });
        throw new Error(`Transform failed for repository: ${key}, topic: ${topic.id}`);
      }
    });
}

This is pretty similar to the mock code earlier. We disable the flag, test, enable then test again. To compare the two results we use JSON.stringify() which I got from Samantha's Blog which advised this would do the job albeit with performance and ordering issues but both of these weren't a concern for this, we just wanted to know that they were the same output.

If they don't match we throw an error with the repository and topic that failed. Also we log to the console both old and new JSON so we can dig into it and see whats up.

Quality of life extras

We're more or less done with the tool now which is great news but I wanted to add a few extra things just to make life using the tool a bit nicer. As it stands if there was a difference in the output between transformers it would be pretty tricky to know exactly where that difference is, these objects are often quite big and heavily nested!

We installed a new package called deep-object-diff which is cool because it tells you exactly where the two objects differ. We use detailedDiff which separates what was added, removed and updated into an object that can be logged to the console. This along with the log of the objects themselves makes finding the change much easier.

Another quality of life update (well thats stretching it a bit). We wanted to know how far in the test we got before it failed, so we added a progress bar and some job counts. It doesn't really help much with the task of fixing differences but it does help game-ify it a bit.

Conclusion

So thats it really. The tool was a bit of work but it's already been really useful as its identified a few differences which the tests did not pick up. We can then fix those and fix the tests too so we know it'll always behave that way in the future.

Eventually we won't need the tool after we've removed the old transformation layer. But for now it sure helps us all sleep at night better knowing its working just as it did before.

Polymer

2016-05-01T00:00:00Z

Another talk I did back in November was on Polymer.

Polymer is an interesting framework which is used to create custom HTML elements using the browsers web components API's if it can. In my talk we'll make our very own elements and use them to create a cat pinterest style application for cat lovers everywhere.

As I was recording this my screen recorder crashed which meant I had to bail from screen recording my talk. I don't think my mac likes screen recording while trying to power a projector and it's screen!

I also listed some useful links which weren't captured in the video so here are the links below:

Screencast Sourcecode - The sourcecode for the kitteh app that we built in this screencast
Official Polymer Site
Polylint - A useful linter which is good at picking up common errors
Polyserve - A simple server to load your Polymer elements
Webcomponents - Collection of all things web components
Polymer Summit - Youtube playlist of the latest Polymer summit
Codelabs - Useful collection of hands on tutorials on how to do cool stuff with Polymer
Polycasts - A youtube series hosted by Rob Dodson on polymer topics, very handy stuff!

Thank you for watching!

All About Atom

2016-04-19T00:00:00Z

I did this talk way back in November last year but it's only now I've managed to see about putting it on the interwebs.

Apologies the fan noise towards the end, I'm still using an old mac from the days when only rappers had gold macs.

This time I'm talking about my latest escapades with the open source editor Atom. I really like using this editor as it feels approachable and most importantly for a coder, tweak-able!

In the talk I go through how atom works and some of the changes I've made to it to make it work for me. I also look at other projects which have benefitted from the work done on Atom and it's child project Electron

Since then I've removed a lot of stuff that I originally had added, this is mostly to squeeze as much performance as possible out of atom as it can still be a bit of a sloth at times (usually when you're trying to do just one quick change).

And as always thanks for watching!

Refactoring with BEM

2016-02-23T00:00:00Z

It was around this time 3 years ago I was putting the finishing touches to this design.

Back then Jekyll didn't compile sass and since the design was quite simple I didn't feel the need for it, plus I'd probably forget to compile half the time anyway!

I wrote my css the old fashioned way, starting with the header and working my way down to the footer. It was great in the beginning but after a while a few drawbacks started to emerge:

No build process to minify and concatenate (I could have made one but then I would have just used sass)
High specificity caused clashes and made it easy to add bugs
Duplicated code for similar objects and redundancies

I had been meaning to tidy it up for ages but I just didn't know what to do. I was aware of OOCSS & SMACSS but didn't understand them. Lately I've been getting into BEM because it is a simpler concept to grasp.

After doing a bit at work and also reading about namespaces I finally felt confident to try and refactor this :hankey:

I ended up with this structure which I'm not fully convinced by but it's a vast improvement on what it replaces. It's still BEM but with namespaces to add a bit more information.

These aren't just namespaces plucked out of thin air either, they explain how explicit the styles are. Starting from generic wide ranging styles to more focused styles that only affect a handful of elements.

Settings & Tools: Contains sass variables and my animations
Generic: Resets, spacing and box models
Base: Element selectors only, no classes here
Object: Inspired by the media object in OOCSS this contains code shared across two or more components. Purely class selectors from here on
Component: Main parts of the design, highly specific code that affects very few html elements

Finally theres trumps which is the most explicit layer. Use of !important here is OK since I know that this is the final layer of specificity.

This format is nice to work in because I know what impact my changes will have. A useful tool I borrowed from csswizardry was his debug stylesheet which outlines different components on the page which is handy.

As an added bonus naming my files like this makes it really easy to find what I'm looking for. I guess the only downside to this technique is knowing what to call things!

Additionally I added scss-lint to the CI to make sure that my code stayed consistent which while annoying at the time is really handy. I just had to spend some time making sure I had it set up with the correct rules.

Feel free to nose around the pull request. Thanks for reading!

Congestion Busting with Blackfire.io

2016-02-13T00:00:00Z

Recently at work I was involved a project which aimed to improve the performance of one of our analytics systems. We needed a way of measuring our progress of certain user flows before and after optimization so we could give the client feedback on how the project was progressing.

Blackfire is a performance measuring tool written by the folks behind the symfony php framework and was ideal for the task. You can read about my experience with blackfire over on the Box UK dev blog.

Responsive Day Out

2015-10-07T00:00:00Z

This is my second talk of the year and first duet with Christelle (I'm not sure if thats the right terminology but lets run with it). At Box whenever someone goes to a conference they can do a short talk to summarise the event for those who couldn't attend.

Responsive day out is a front-end focused conference sharing tips and tricks on workflow, techniques and experiences on dealing with a responsive web. The nice thing about this conference was it contained both devs and designers!

We both found this one tough for the following reasons:

We needed to deliver it soon after coming back so that the day remained fresh in our heads but we were also very busy at the time
The conference was intense even by single day standards and a lot of ground was covered in a short space of time. Compressing this into a 30 minute chunk and retaining its structure was tough
Making sure we both felt we contributed equally was also really hard

The talk was well received with most saying it was the best that they had experienced of this type! :smile:

The conference was a blast and I really enjoyed producing this talk with Christelle. Hopefully we can do it again someday!