DEV Community: Tom Butterwith

Becoming a Highly Effective Software Developer

Tom Butterwith — Mon, 30 Sep 2024 13:40:11 +0000

Senior engineers often ask me, 'What do I need to do to get promoted?’ While technical skills are crucial, the most effective engineers possess qualities that go beyond writing code. Here are a few traits that I feel highly effective engineers embody: finishing over starting, fostering growth in others, and mastering communication.

1. Focus on Finishing Over Starting

Effective engineers understand that completing work is more valuable than starting work. This principle manifests in several ways:

Supporting Others' Initiatives: Instead of always pushing their own ideas, top engineers often throw their weight behind their colleagues' projects, helping to bring them to fruition.
Collaborative Completion: By reviewing pull requests, providing constructive feedback, and actively supporting peers, these engineers ensure that work reaches the finish line with high quality.
Making Tough Decisions: Sometimes, finishing means knowing when to stop. Effective engineers aren't afraid to recommend cancelling work when it's clear that a chosen path is no longer viable, saving time and resources in the long run.

By prioritising completion, these engineers ensure that value is consistently delivered and that the team's efforts aren't wasted on half-finished projects.

2. Ensuring Growth for Those Around Them

Great engineers are not just focused on their own development – they actively contribute to the growth of their entire team:

Educational Code Reviews: When reviewing code, they go beyond surface-level comments. They provide in-depth feedback, often linking to relevant documentation or best practices, turning each review into a learning opportunity.
Mentorship Through Pair Programming: By engaging in pair programming sessions, especially with junior team members, top engineers share their problem-solving approaches and coding techniques in real-time.
Optimising Team Processes: Whether it's introducing new methodologies or streamlining existing ones, these engineers constantly look for ways to improve how the team works together.

This focus on collective growth creates a rising tide that lifts all boats, resulting in a more skilled and efficient team overall.

3. Communicate Better Than Anyone Else

Perhaps the most crucial pillar is communication. Highly effective engineers are outstanding communicators:

Transparent Thought Processes: They don't just share results; they articulate their thinking, making their decision-making process clear to all stakeholders. This way assumptions can be tested earlier. Providing proactive status updates with potential risks or things you’re investigating further helps to build trust and gives others the opportunity to provide potential solutions or advice.
Setting Clear Expectations: By communicating frequently and in detail, they ensure that everyone has a clear understanding of timelines, potential roadblocks, and project scope. This gives stakeholders the opportunity to raise any differences in expectations they might have early on, rather than further on in a project where changes may be more difficult to make.
Realistic Estimations: While software development is inherently unpredictable, effective engineers provide the best possible estimates and clearly communicate the factors that might affect timelines. Delays and issues are best handled when shared early — if your stakeholders and peers know about issues, they might be able to help.

When engineers excel at communication, it reduces misunderstandings, allows for better decision-making across the organisation, and builds trust with stakeholders.

The Multi-level Todo List

Tom Butterwith — Mon, 22 Jan 2024 11:59:35 +0000

Originally posted on butterwith.space

Since becoming a “lead of leads” I’ve found that a simple todo list of tasks no longer fits my needs. Given I spend most of my energy delegating tasks and following up on their progress later, I had tasks on my todo list that would be on there for weeks, sometimes months as they progressed. I also found that my attention was being pulled in a number of directions at once and I struggled to identify which tasks were important and how I should spend my time.

There are a lot of words written about how to effectively manage todo lists, how to manage your time, how to prioritise, etc and I’m aware this adds to that massive pile but I think it’s important to find a process that works for you. So here’s mine.

Weekly Goals

This is the thing that keeps me on track when I’ve got multiple things on. Just like I would expect for a team, I set myself a one or two (never more) weekly goals which I use to help set direction for my week, and to help me measure if I’m making progress. I tend to set goals large enough to fill my week so that I’m somewhat stretched to complete them e.g. Set up hiring pipeline for Senior Software engineer (which might include a number of meetings, writing a job spec, setting up and interview funnel) or if something is particularly important I might have a small task as goal to ensure it’s done that week e.g. Set up 1:1s with new managers.

Any time I pick up a new task or have some down time, I refer back to my weekly goal. Does this task help me get closer to those goals? If not, then it goes to the bottom of my todo list.

As the week progresses, I regularly check in on how I’m doing. If I’ve completed a goal I’ll mark it with a ✅. By the end of the week ideally both of my goals should be ticked, if not, I’ll mark any incomplete goals with ❌. I keep a record of all of my previous weekly goals and how I did so that I can look back over time and see a high-level summary of the work I’m doing.

The Inbox

The concept of an Inbox is from Getting Things Done by David Allen. This is a space to collect everything that you have on your mind at the moment, no matter how big or small. I use it as a scratch pad during meetings as well as a space to jot things down as I remember them so nothing gets lost. Send a slack about project y – in the Inbox. Define a process for incident debriefs – in the inbox.

I like to go through my Inbox at the start and end of every day and, just like you would if you were running a team, triage anything that I’ve added over the course of the day. Anything that takes five minutes or less gets done there and then. If a task takes longer than that, it then gets moved into my Prioritised backlog.

The Prioritised Backlog

For me, the Prioritised Backlog is the key to keeping track of everything I have going on. Everything that was gathered in the Inbox is sorted into a item in the backlog, either a larger item that might hold a number of todos (such as a long running project with multiple steps) or on it’s own as a standalone task. If an item has more than one task in it I tend to keep a short summary at the top that reminds me what the latest status of that item is – in some cases a project I need to keep track of could run for multiple weeks where I don’t need to be actively involved.

I’ve found I only need four categories for items on this board: Planning, Waiting on Others, In Progress and Done, with tasks regularly moving back and forth between In Progress and Waiting on Others.

Nailing Your First Technical Interview

Tom Butterwith — Wed, 16 Feb 2022 12:31:03 +0000

The hunt for your first job can be a stressful time in your life. You’ve invested a huge amount of time and energy into learning the skills you think you need to start your journey in the world of professional software development, you’ve made some fantastic projects along the way, but who knows what those pesky interviewers are going to ask you in a “technical interview”.

Well, a technical interview could mean a number of different things - an hour of questions, writing some code (either on a whiteboard or in an online editor), or a walk through one of your projects. What I intend to set out below are some topics to help you prepare what ever comes your way.

🗒️ Throughout this page I’ll use the terms app, service or project interchangeably. What I mean by this is a thing of some kind that you’ve built.

Let’s start with the project walkthrough and some of the areas you might want to touch on. The topics below are also a great starting point for “an hour of questions” style interviews.

“Tell me about your project”

This style of interview requires you to think about a project that you’ve worked on and answer questions on the design and implementation.

First things first, how do you decide which of your projects you should chose? When I’m interviewing I’m really looking for a project that fits two criteria:

Is this project complex enough to cover all of the areas I need to cover? The project might not cover more complex topics like deployment or scale, but we need to be able to have a discussion about this in a hypothetical way. “If this app went viral, what’s the first thing that would break?”
Are you able to talk about every part of this project, whether you worked directly on it or not? You don’t need to have built the entire project you’re talking through, but you do need to be able to talk through how it works and why certain decisions were made. You may have built the front-end but you need to know about the database and back-end (and visa versa).

If you find yourself building lots of “hello world” or todo list apps to show your versatility in learning frameworks or languages, a better investment with your time might be to create a single, more complex application so you can show your depth.

So, you’ve picked a project that you’re happy talking about in depth - what sort of topics should you prepare?

Design decisions

Most of the questions in this area will be around why you made certain choices when building your application. You may not have considered any of these things when designing your application so it’s a good idea to retrospectively review some decisions you may have made. “Because this is the technology I know” is an alright answer, but companies will be looking for candidates that are able to see how the tools and technology they know fit into a wider ecosystem. There are a million and one frameworks and tools to solve a problem so you’re going to need to know how to pick the one that fits the job best.

I’ve included a non-exhaustive list of questions below, some may not be applicable to your project depending on its design.

“Why did you chose language x over y?”
“Why did you use a SQL database over NoSQL?” (or vice versa)
“Why is the database structured the way it is? How do the relationships between entities work?”
“Why do you have a server between your client and your database? What are the advantages of this?”
“How does your application deal with failures?” - I personally like this one as it allows you to talk about how people might use your app and what kind of experience you want them to have when things don’t quite work out
“Why did you use x front end framework? What advantages does it bring over plain/vanilla JS and HTML?”

Testing

If you’ve learnt to programme via a bootcamp or you’re self-taught you may have never needed to write tests but you’ve probably had a lesson or two covering them. Testing is a really important tool for ensuring the software you write:

Works in the way that you intended
Interacts with other services and other software
Doesn’t break when someone else (or even you) comes to make changes later
Is easy to understand

It’s my opinion that you don’t need to have written tests to get your first job, but you should have an understanding of why they are important and an idea of the different types of testing. A couple of key questions to answer would be:

“What value do tests provide?”
“How might you stop the next contributor to your service breaking what you’ve written?”
“How do you know the code you’ve written works as expected?”

A few types of tests to look into at unit tests, acceptance tests, integration tests, and performance tests.

Lastly, one often overlooked use of tests is to document your code. Unit tests can often provide information on the way a method is expected to be used and the kind of data the original programmer anticipated might be used. Next time you’re trying to understand someone else’s code, take a look at the tests.

Scale

Depending on the type of applications you’ve written, you may have never had to think about scale. Code running on even the most basic laptop can support enough users to test your code, share with friends, and potentially even publish to the internet. Writing software for a business will take you beyond that and it’s important that you know how to think about scaling software.

The best place to start when thinking about performance is to look at your application and try to work out which part will break first. Will your server manage with 100 times the number of requests it’s got at the moment? What about 1000 times? How about your database? Focus in on the weakest part of your application and how might you improve its capacity.

To scale an application there are two main approaches:

Vertical scaling: this is the simplest form of scaling and it involves increasing the power of the machine your code is running on. Got 500Mb of RAM? Make it 1Gb. This is useful for parts of your application that store data (or manage state as some people would refer to it.) It’s the easiest way to add capacity without too much difficultly. A word of caution with this approach - you can only go so big before cost becomes the prohibitive factor.
Horizontal scaling: this involves running multiple copies (or instances) of your code on replica machines. Have one server running your back-end? Try two. This is a really effective way of splitting the load across different instances. When horizontally scaling your application you’ll need to think about balancing the load on each machine, and handily there are services called Load Balancers to do exactly that for you.

Similarly to the point on testing, I wouldn’t expect early career candidates to have experience in scaling an application but understanding how software scales is important to know.

Deploying Software

Lastly. you should be aware of how to deploy software. Like the other sections, a surface understanding of the type of services you might use to get your application in front of users. Here’s a short list of topics:

Version control: All good deployment pipelines start with source control. You should understand why git and version control in general are good ideas
Continuous deployment: When committing to master, how does your traffic serving service get updated? Tools like Netlify and Heroku have this build in, services like Jenkins and Github Actions provide more customisation
Infrastructure: What’s running your service? Things to look at here include EC2 instances (or other cloud provisioned virtual machines), cloud database providers like Dynamo DB or Azure Database.
Logging and alerting: How do you know when your app has stopped working? Relying on users to contact you is one way but that’s often not the best idea. Tools like Loggly, NewRelic, and LogRocket allow you to find out automatically when something isn’t working as it should and help you get to the bottom of it.

Summary

In short, the points above should take you beyond thinking about writing code and into the other problems you’ll face running software at scale. Take all of this with a pinch of salt. Not every company is going to ask you the same questions and have the same expectations of a junior engineer, but understanding how to get your code, your apps, your products in front of people is very powerful knowledge indeed.

Best of luck, you’re just getting started on an exciting and potentially rewarding journey! 🚀

For more of my writing, see https://butterwith.space/blog

Your Voice Matters

Tom Butterwith — Thu, 13 Jan 2022 15:22:29 +0000

I’ve been leading teams for a couple of years now and I often receive feedback from my direct reports that they’re either unsure on how best to contribute to team discussions, or they’re newer senior engineers and don’t understand the weight their voice carries in discussions. What you’ll find below are some examples of how you can use your voice to benefit the team regardless of your role, and a couple of pitfalls to watch out for as you become more senior.

Junior Developer

An early career software developer - between 0 and 12 months experience.

Being a junior developer is an opportunity you only really get once. Question everything. Why are you using this framework over that one, what does that acronym mean, why is this thing important? These questions are expected and should be utilised to the fullest, for both your own benefit and that of you team. Just like a new joiner to a team (which you are as well as a junior developer) you have an unjaded viewpoint from which to objectively question any and all processes.

Honestly questioning existing processes and tools causes the team to reevaluate their choices up until now. Does this service/process/tool still provide value? Can I justify why this exists? Do I understand this thing enough to explain it to someone new? Anything that doesn’t have clear benefits or can’t be explained fully should be followed up on by the team later - either it’s no longer adding the value it once did, or there’s a gap in understanding that should be filled in.

New Joiners

A developer that has just changed team - any level of experience.

📢 Note: If you haven’t changed domain or looked for new opportunities in the last two years, this is a reminder to do so. You’ll benefit immensely from taking your experience and applying it to a new problem. Likewise, the problem you work on next will benefit from a new perspective and different experience. This often doesn’t need to be a job change, in fact you’ll often benefit from a rotation inside your current workplace.

Welcoming new members to a team is a great way of reevaluating the current stack and processes (see the previous section) as well as injecting a new viewpoint into discussions. You have the opportunity to input into discussions without carrying the baggage of previous work. “We tried that before and we can’t do this because of x”, “Vendor y doesn’t want to do z” etc. Things change, problems evolve, existing tools become obsolete and are replaced by new ones, so why not reevaluate some decisions that were made in that past.

This is your opportunity to ask questions of your new teammates, both to gain context on the decisions that have gone before and to challenge the status quo. Pairing with a member of the team on some of these opportunities is a great way to get to know your area of the business better and build bonds with the team.

Senior Developer

As a senior developer your voice carries more weight than you might realise, especially if you've recently been promoted. Other members of the team will look to you for feedback on their ideas - both explicitly by asking for it, and implicitly by listening to how you react to the things they're talking about. Junior engineers may follow your lead without realising it as they learn what it means to be a software engineer. Before contributing to discussions you need to be aware of how your ideas are perceived.

In general, I encourage senior engineers to speak last. This helps to avoid anchoring bias and provide space for less senior engineers to voice their thoughts. It’s much easier for you to critique them than it is for them to critique you.

This isn’t to say you shouldn’t feel comfortable contributing to discussions first, you just need to pick your moments. If there is a decision you feel strongly about, or is potentially high impact, then that’s the time to use your influence to reinforce your point.

For more of my writing, see https://butterwith.space/blog

Refactor your if statements for improved readability

Tom Butterwith — Thu, 04 Mar 2021 17:16:11 +0000

As I write more software and mature as an engineer, I've begun to understand that less code isn't always better code. Although the code we write is for machines to understand, it's often compiled and optimised for them before it's run. It's much more valuable to write code that's easier for people to understand - it leads to faster code reviews, less confusion, and safer code as people can easily see the intentions behind your code as well as what it does.

With this in mind, I've recently started writing if statements differently, trying to make the condition statements as legible as possible. One technique I've found particularly useful is moving the conditional statement into its own function.

Consider this if statement.

if (statusCode == 400 || statusCode == 500) {
    console.log("Bad response");
}

It's quite obvious that this if statement checks for error code, but what if I'm not familiar with the exact error codes that should be considered an error or the list of 'bad' codes grows? We could refactor this if statement into it's own function.

const isBadResponseCode = (statusCode) => {
    return statusCode == 400 || statusCode == 500;
}

if (isBadResponseCode(statusCode)) {
    console.log("Bad response");
}

The gains here are two-fold. Firstly, it's crystal clear what we're looking for in that if statement and when we should trigger the condition - bad response codes. If I'm skim-reading the code to get a feel for what it does, I don't need to consider exactly which response codes are bad, just that the program does something if it receives one.

Secondly, the response code comparison is contained within its own function which means it's easier to read in isolation. I don't need to break down the if statement to review which response codes the program considers 'bad'.

This is an oversimplification of this concept but it helps to prove a point. We've added more lines of code but I would argue that we've made it easier to understand and reason about, and self-documenting.

Avoid Magic Numbers to Increase Code Readability

Tom Butterwith — Wed, 03 Mar 2021 17:29:33 +0000

What are magic numbers?

Magic numbers are any numeric constant declared in your code. They could help you convert minutes to seconds, set limits for the number of all records in a database, or repeat a process a constant number of times. In any case, you'll see things like for(const i = 0; i < 10; i++) or return x * 60.

Why should you avoid them?

On their own, these numbers carry no explicit meaning, the developer has to infer what they are from the context they are used. This might be easy, everyone knows there are 60 seconds in a minute. Others, like the example for converting kilometres to miles below, are more obscure.

What should you do instead?

Consider this example. On its own, 0.6213712 carries very little meaning. We can establish from the method name that this might be the number of miles in a kilometre but without looking it up or a code comment, we can only assume.

By giving this value its own variable with a helpful name, we're writing self-documenting code that gives the next person to read this code all the information they need to know exactly what a value is.

Example one

// Before: large float in the middle of a function
const convertKilometersToMiles = (distanceInKm) => {
    return distanceInKm * 0.6213712;
}

// After: The function is easier to read at a glace. 
// Anyone reviewing the code can clearly see the intent of the function
const MILES_IN_KILOMETER = 0.6213712;

const convertKilometersToMiles = (distanceInKm) => {
    return distanceInKm * MILES_IN_KILOMETER;
}

Example two

// Before
if (users > 10) {
    throw new Error("too many users");
}

// After
const CONCURRENT_USER_LIMIT = 10;

if (users > CONCURRENT_USER_LIMIT) {
    throw new Error("too many users");
}

Dependency Injection in Java with Guice

Tom Butterwith — Sun, 19 Jul 2020 11:59:29 +0000

This post is designed as an overview and reference guide to the different methods of using dependency injection in Java. For in-depth documentation and the background context around the Guice library see the official Guice documentation.

What is DI?

Dependency Injection (DI) is a design pattern. Its core principle is to separate behaviour from dependency resolution. This means your classes should only have to deal with their function, and not have to consider where their dependencies are coming from.

Why use DI?

DI is useful for two main reasons. Firstly, it enables you to write loosely coupled classes. As dependencies are resolved by a central mechanism, there are no ties to a factory or provider class that will instantiate your dependencies. Dependency management is now configured in a single place, in this case using Guice and Modules.

Secondly, injected dependencies are easy to mock making your loosely coupled classes easier to test. As you'll see later on, mocking what were once complex dependencies is as simple as using the @Mock annotation and passing them to the constructor.

All examples are for Guice

As the heading says, all of the examples in this post use Guice for dependency resolution. Guice is an industry-standard Java library for implementing DI and widely used and well documented online. Let's get right into.

Application Setup

In the simplest instance, Guice is configured using a single AbstractModule and a statically generated injector. With these 8 lines, you can create an injector and fetch instances of any configured class within your application.

public MyModule extends AbstractModule {
    @override
    protected void configure() {
        // Write your bindings for interfaces here e.g.
        bind(IMyInterface.class).to(MyInterfaceImpl.class);
    }
}

public static void main(String[] args) {
    Injector injector = Guice.createInjector(new MyModule());
    // Injected instance of MyClass.
    MyClass myClass = injector.getInstance(MyClass.class);
}

Injecting Dependencies via Constructor Arguments (Recommended Approach)

This is the simplest example of dependency injection. MyInjectedClass has a no-arguments constructor so it can be injected into MyClass without any setup. Guice will fetch a new instance of MyInjectedClass - no need for a factory class or new MyInjectectedClass(); . @Inject lets Guice know that the constructor parameters should be resolved using DI.

public MyInjectedClass () {
    ...
} 

@Inject
public MyClass(MyInjectedClass injectedClass) {
    ...
}

If your injected class has dependencies, annotate that class with the @Inject annotation. Guice will recursively fetch the required instances until it reaches a no-argument constructor or all dependencies have been satisfied.

Injecting Field Dependencies.

Instead of using constructor arguments, dependencies can be injected directly to a field. This is the most concise form of injection but is difficult to test (testing constructor injection is covered below.)

public class DemoClass {
    @Inject
    MyClass instanceOfMyClass;

    public DemoClass() {
        // NOTE THAT instanceOfMyClass will be null here
    }

    public bool hasMyClass() {
        return instanceOfMyClass != null;
    }
}

One thing to note about field injection is that the field will not be instantiated inside the constructor. If you need the field to be instantiated in the constructor you must use constructor injection.

DI for Static Dependencies

You might find yourself migrating parts of an older project from static factories to dependancy injection and you need to grab an instance of a class set up for DI in a static class. No problem. You can configure Guice to set up your static classes at injector-creation time.

// Override the configure() method of your module
@Override 
public void configure() {
    requestStaticInjection(MyStaticClass.class);
}
...

class MyStaticClass {
    @Inject
    private static MyClass instanceOfMyClass;
}

Using the Provides Annotation

If your class requires some set up, you might want to create a @Provides annotated method inside your module. This allows you to run some code or provide some configuration when instantiating a class.

@Provides
public MyClass providesMyClass() {
    MyClass instance = new MyClass();
    instance.setSomeValue("cool");
    return instance;
}

Named Annotation

The @Named annotation allows you to identify a specific instance of a class. This is required by Guice if you have more than one instance of a class - very handy if you connect to multiple databases or caches using the same wrapper class, just set up a @Named provider for each one.

@Provides
@Named("SpecialInstanceOfMyClass")
public MyClass providesMyClass() {
    return new MyClass();
}

@Inject
public SomeOtherClass(@Named("SpecialInstanceOfMyClass") MyClass instanceOfMyClass) {
    ...
}

Binding Interfaces to Implementations

Guice needs to be told how to implement interfaces. As with the set up example at the beginning of this post, interfaces can be bound to their implementations inside a module.

public MyModule extends AbstractModule {
    @override
    protected void configure() {
        // Write your bindings for interfaces here e.g.
        bind(IMyInterface.class).to(MyInterfaceImpl.class);
        bind(IOtherInterface.class).to(OtherImplementation.class);
    }
}

Configuring Multiple modules

If you find your module is becoming large, or you want to separate concerns into different files for readability, you can register multiple modules with Guice. Be careful not to register the same dependency in more than one module - Guice will remind you with a helpful compiler exception.

Injector injector = Guice.createInjector(
    new MyModule(),
    new OtherModule()
);

Automatically bound things

Some frameworks are configured for Guice out of the box and will automatically bind providers for interfaces. For example Dropwizard will automatically bind instances of the Managed interface - any implementations you attempt to register in your module will throw an exception.

Testing

The great thing about dependency injection is it makes your dependencies easy to mock and your tests simple to write. Imagine the following class with two dependencies injected into the constructor:

class MyExampleClass {
    DBClient client;
    CacheClient cache;

    @Inject
    public MyExampleClass(DBClient client, CacheClient cache) {
        this.client = client;
        this.cache = cache;
    }
}

Using the @Mock annotation, we can get Mockito to create a mock version of each of the dependencies with no extra set up. These can be passed into our constructor to be used later. An example test file might look like this:

@RunWith(MockitoJUnitRunner.class)
public class MyExampleClassTest {
    @Mock
    DBClient mockClient;
    @Mock
    CacheClient mockCache;

    MyExampleClass myClass;

    @BeforeEach
    public void setup() {
        myClass = new MyClass(mockClient, mockCache);
    }

    @Test
    public void myTest() {
        // Use the static Mockito.when() method to set up your mocks
        when(mockClient.connect()).thenReturn(new Connection());
        myClass.someFunction();
    }
}

Creating an injector and binding classes

Finally, if you're using Field Injection and you need to mock that dependency you can set up your tests as follows:

@RunWith(MockitoJUnitRunner.class)
public class MyExampleClassTest {
    @Mock
    MyFieldDependency mockDependency;

    @BeforeEach
    public void setup() {
        var injector = Guice.createInjector(new AbstractModule() {
            @Override
            protected void configure() {
                bind(MyFieldDependency.class).toInstance(mockDependency);
            }
        });
        myClass = injector.getInstance(MyClass.class);
    }

    @Test
    public void myTest() {
        // Use the static Mockito.when() method to set up your mocks
        when(mockDependency.something()).thenReturn(true);
        myClass.someFunction();
    }
}

This tells Guice to fetch an instance of MyClass and to use mockDependency to resolve the injected field MyFieldDependancy.

Do you consider the environmental impact of your software?

Tom Butterwith — Mon, 22 Jul 2019 15:48:50 +0000

When writing or deploying software, do you consider the environmental impact of it? Does this factor into the design process when choosing hosting etc?

I've been thinking about this more and more lately as cloud computing environments have started posting their emissions statistics. For example Google are 100% carbon neutral, AWS is 50% neutral with a promise to go 100%, and Microsoft are doubling down on sustainability

Alfred and Dash: improving your workflow

Tom Butterwith — Thu, 11 Jul 2019 13:49:46 +0000

Alfred

Alfred is an award-winning app for Mac OS X which boosts your efficiency with hotkeys, keywords, text expansion and more.

The above statement is taken directly from the Alfred website, but it only scratches the surface of what Alfred can do. Besides the search functionality, the ability to integrate with other applications is a real game changer for increasing your efficiency.
On it's own, Alfred is a Spotlight search replacement but it really shines when you add in the Powerpack allowing you to write your own workflows and integrate fully with other applications.

Dash

Dash is an API Documentation Browser and Code Snippet Manager.

Using Dash has been one of the biggest optimisations in my programming career. Being able to search through local copies of documentation and "cheat sheets" rather than opening a web browser and searching for what I'm looking for.
Not only does Dash store doc sets, it has the ability to store code snippets, which can be tagged to aid searchability. These code snippets can then be used in other applications thanks to it's autocomplete feature. This is really handy for storing code templates, letting you think about writing feature code and not boiler plate.

Example text expansion from Dash in VS Code

Workflows

Workflows allow you to add cross application functionality to Alfred, enabling more complex tasks and allowing you to automate a number of repetitive tasks. There are a number of these available through the Alfred website but I'm going to be focusing on the Dash integration as that's what I have found most useful.

The available Alfred Workflows

Provided you have the Alfred powerpack and Dash installed, the workflow is available in the preferences section of Dash.

After double clicking the Alfred icon, the workflow should install it's self.

Customising your docsets

Under the Downloads section of the Dash preference pane, there are a number of both official and user contributed doc sets available for download. There is a handy search bar that allows you to search across all of the docsets for any particular set you're looking for.
Once installed, the keyword for searching a docset can be customised using the Docsets prefenence pane. The shorter the search term, the faster Alfred will recognise you're searching for a keyword within Dash.

Quick Access React Documentation

Asynchronous Javascript: 3 ways

Tom Butterwith — Wed, 10 Jul 2019 11:29:36 +0000

Callbacks, Promises, and Async/Await

The JavaScript engine is single threaded and utilises an event loop. Simply put, this means any statements you run will be executed one after the other in a single process. To avoid blocking calls, there are a number of techniques that JavaScript employs to avoid waiting while something is computed. These are asynchronous functions.

You can read more about the event loop here as the topic is too deep to cover in this post.

JavaScript provides three methods of handling asynchronous code: callbacks, which allow you to provide functions to call once the asynchronous method has finished running; promises, which allow you to chain methods together; and async/await keywords, which are just some syntactic sugar over promises.

Callbacks

The original method of handling asynchronicity. Callbacks allow you to provide a function to be executed after the asynchronous code has finished. In the example below, functionWithACallback takes a function as an argument and will call that function when it is finished.

This method, passing functions back and forth, can become very confusing if you need to chain a number of these calls together. The callback will need to be passed down the execution chain to be called at the end of the final process.

const functionWithACallback = (callback) => {
  //do some work then call the callback once done
  console.log('You called this function!');
  setTimeout(() => {
    callback('I am done');
  }, 1000)
};

const myFunction = () => {
  // the function we want to call when the work is done
  const myCallback = console.log
  // this will call myCallback once it is finished 
  functionWithACallback(myCallback);
};

myFunction();
//  You called this function
//  I am done

Promises

One of the main problems with callbacks is, when chaining a number of function calls together it can become increasingly difficult to follow the flow of execution. Promises aim to solve this issue by allowing you to chain together promises using the .then() syntax. The example below works the same way as the callback example, but is much easier to follow: wait till getPromise() has completed and then call the function containing console.log()

Error handling with promises is also less complex. Rather than calling the callback with an error object, promises provide a .catch() wrapper to help manage error states. Below, the catch block will be executed if an error occurs in any of the promises above it.

const getPromise = () => Promise.resolve('My return value');

const myFunction = () => {
  getPromise()
    .then(val => { 
      console.log(val); // prints 'My return value'
    }) // If there is an error in any of the above promises, catch
       // it here
    .catch(error => {   
      console.error(error.message);
    });
}

Async/Await

In the more recent versions of JavaScript, the async and await keywords were added. This provides a cleaner method of writing promises and gives the user more control over execution order. The below example is identical to the promises example in functionality, but is written using the async and await keywords.
Error handling for async function calls is provided using a try/catch block.

const getPromise = () => Promise.resolve('My return value');
// the function is marked with the async keyword
const myFunction = async () => {  
  // tell the interpreter we want to wait on the response
  try {
    const val = await getPromise();
    // execute when the promise above is resolved
    console.log(val); // prints 'My return value'
  } catch (error) {
    console.error(error.message);
  }
}

Jupyter Notebooks for Software Engineers 🚀

Tom Butterwith — Tue, 09 Jul 2019 11:59:23 +0000

Jupyter Notebook is an interactive web application that interfaces with the iPython repl, allowing you to run structured but iterative Python scripts. It is the de facto choice for data scientists to rapidly prototype pipelines, visualise data, or perform ad hoc analysis.

Jupyter notebooks are a fantastic way to visual any data sets you might have, as well and conduct ad hoc analysis. It is especially useful for querying databases and displaying the data in a repeatable manner.

Setting Up Your Environment

When working on any python project, I like to use Pyenv and the Pyenv Virtual Environment wrapper to manage all of the different python versions and dependencies. You can find the installation guides for on the Pyenv GitHub repo and the Virtual Env wrapper.

If you don't have Python 3.6 installed already run the following:

$ pyenv install 3.6.0

Setup a new virtual environment and activate it:

# Create a Python 3.6.0 environment called jupyter-notebooks
$ pyenv virtualenv 3.6.0 jupyter-notebooks

# Start the virtual environment
$ pyenv activate jupyter-notebooks

Next, install all of the dependencies you'll require:

$ pip install jupyter pandas numpy matplotlib seaborn

Finally, start your jupyter server in the directory you would like to save your notebooks:

$ jupyter notebook

A New Jupyter Window

Creating a notebook

Notebooks are created using the dropdown in the top right hand corner of the page. Jupyter will automatically open and start the notebook so you'll be ready to go.

The Jupyter New Notebook Dropdown Menu

An Empty Jupyter Notebook

Like with any other Python file, it is best practise to include your imports at the top of the file. In Jupyter, we can use the first cell for these. Shift + Enter runs the cell once you've written your script.

# Pandas for manipulating dataframes
import pandas as pd

# Matplotlib for inline graphs and plots
from matplotlib import pyplot as plt
%matplotlib inline

# Seaborn for plot styles.
import seaborn as sns

Reading in data

CSV

Pandas has a handy function for reading in csv files. Below are a couple of examples, but Chris Albon has a great blog post about importing csv files if you need more information.

# if the file has headers
df = pd.read_csv('path_to_file')

# if the file has no headers
df = pd.read_csv('path_to_file', headers=None)

Exploring data

There are a number of methods to explore a data-frame once it has been loaded. To inspect the first n rows, use the head function which returns the first 5 rows by default but can return any given number.

# Print the first 5
df.head()

# Print the first 10
df.head(10)

To find out some basic information about the data held within the data-frame, the describe function outputs a summary of the values excluding any NaN values.

df.describe()

Finally, to view a data-frame in its entirety pandas provides an option_context function to temporarily set options within a with context.

# Set the max rows to print to 999 and print.
with pd.option_context('display.max_rows', 999):
    print (df)

Modifying and filtering data

To access individual columns and values in a data-frame, pandas provides the loc parameter.

# fetch a column
df['column_name']

# fetch a row
df.loc['index_value']

# fetch a single value
df.loc['index_value', 'column_name']

# filter a data-frame by a given condition
df.loc[lambda df: df['column_name'] > 3]

Columns can be added or modified easily using the apply function

# create a new column based on other column values
df['new_column'] = df['old_column'].apply(lambda val: val * 2)

# override a column
df['old_column'] = df['old_column'].apply(lambda val: val * 2)

Basic graphs

Graphing in Jupyter notebooks is as easy as calling a single seaboard function.

# create a line plot using your data frame
sns.lineplot(x="my_x_field", y="my_y_field", data=my_data_frame)

An Example Line Plot

# create a scatter plot
sns.scatterplot(x="my_x_field", y="my_y_field", size="attribute_z",
                sizes=(10, 200), # size boundaries
                data=my_data_frame)

An Example Scatter Plot

The Seaborn website provides a comprehensive list of examples, each with the code snippet used to generate them and some example data sets to explore.

Bonus

Recently, GitHub has started rendering Jupyter notebooks in their UI, making it easier than ever to run and share notebooks. The iPython repository has a good example.

Useful links

Pandas
Seaborn
Jupyter