DEV Community: Luke Bayliss

I work for one of Auth0’s biggest clients, AMA about using their product at scale!

Luke Bayliss — Tue, 15 Oct 2019 20:18:06 +0000

Hey!

I work on IAM for one of Auth0’s biggest clients (Over 1 million users).

I’d love to answer any questions you have about how we use Auth0, challenges we’ve faced, or our general experience using their service!

Ask away!

Photo by bruce mars from Pexels

P.S: I’m not here to bash Auth0, they have been an absolute pleasure to work with.

Baseline for Effort Estimation - How Do You Do It?

Luke Bayliss — Thu, 25 Jul 2019 12:06:55 +0000

My team and I have recently been running some sessions to determine a fresh baseline for estimating our work. I'm curious how others on DEV come to a baseline for their estimations.

So, how do you come up with a baseline for your estimations?

Image courtesy of Annie Spratt on Unsplash

Going to My First Conference. Pro Tips?

Luke Bayliss — Fri, 14 Jun 2019 13:19:04 +0000

My company is sending me off to my first conference this week and I am super excited!

The thing is... I have no idea what to do 🤔

What are your tips for getting the most out of the experience? What should I bring, what should I do, who should I talk to? Or do I just kick back and watch the show like all the YouTube videos 😅

How and Why I Use Emotion with Tailwind

Luke Bayliss — Sat, 04 May 2019 07:55:53 +0000

Note 2.0: This post has not aged particularly well due to a lot of changes to a number of the tools and frameworks referenced. I had intentions to update this with a new example project and a new post but everything keeps changing faster than I can keep up. Please keep in mind that if you do follow along you may see that a lot of things are no longer the best approach for the same result.

Note: Tailwind has had a new major release which changes a lot of what is below, if you're interested in how I've adapted given the upgrade let me know!

My favourite way of doing CSS

I wanted to share my favourite approach for handling CSS in my react projects currently. I mention a little bit about how I came to use this solution and why it was needed in the first place. I also include some code snippets to show how the different libraries and tools are used together.

The Problem

I worked with a small team of developers; most of which are primarily .NET developers. When it was time for us to start building out our newest project we wanted to make sure we could do a few things.

Be productive as soon as possible, and for as long as possible.
Spend less time learning technologies and more time solving problems.
Keep styling as consistent as possible.

What this meant to us was that we would need to be comfortable across both sides of the stack as quickly as possible. At least comfortable enough so that we could be productive from the get go.

Our biggest concern wasn’t having part of the team learning JavaScript and React while the other half learned .NET Core, but how we handled our CSS. Because CSS is hard.

The Solution

Our solution was CSS In JS. I won’t cover CSS in JS in great depth here. If you are new to the idea and curious about it this is a great post.

Specifically we narrowed it down to using Emotion and Tailwind along with some Babel magic to make them best of friends.

Why Emotion

One less build step.
Felt most at home in JavaScript
Dynamically change styles directly with JavaScript.

Setting up a build process is a pain and not much fun. Using CSS in JS meant that we didn’t need to worry about setting up a CSS preprocessor; Using Emotion meant all of our styles are built along with the rest of our JavaScript. And because the styles become part of the code, we can worry less about bundling unused CSS into our project as only the used CSS should be included.

Writing our styles in JavaScript feels more at home to me. Although Emotion is practically still the same as writing plain old CSS, it’s still nice not have to be jumping between multiple files when building out a new component or view. Having everything contained in the one file, and the narrowly scoped nature of CSS in JS, meant that it was easier to focus on al logic and styling of a component at any time.

In practice this:

.button {
  padding: 10px;
  border-radius: 5px;
  background-color: blue;
  color: white;
}

import * as React from 'react';

const Button = (_props) => {
    return <button className="button">Click Me</button>;
};

export default Button;

Becomes:

import * as React from 'react';
import { css } from '@emotion/core';

const buttonClass = css`
  padding: 10px;
  border-radius: 5px;
  background-color: blue;
  color: white;
`;

const Button = (_props) => {
    return <button className={buttonClass}>Click Me</button>;
};

export default Button;

And if we used styled component (my preferred approach), we get this:

import * as React from 'react';
import styled from '@emotion/styled';

const Button = styled.button`
    padding: 10px;
  border-radius: 5px;
    background-color: blue;
  color: white;
`;

export default Button;

Using Emotion quickly proved to be powerful way to build dynamic styles for our components. No longer did we have to write separate classes for different component states. We could just directly modify our styles based on our components state or props.

import * as React from 'react';
import styled from 'emotion/styled';

const Button = styled.button`
    background-colour: ${props => props.isPrimary ? 'blue' : 'green'};
    color: white;
`;

export default Button;

Why Tailwind

Short hand is easier to remember.
Save time on the easy stuff. More time for the challenging stuff.
Consistency.

The biggest reason we decided to use Tailwind was because it made writing CSS accessible to our developers who had little to no experience building interfaces for the web. At least with modern frameworks like react.

Being able to use self descriptive and easy to remember class names meant that our developers could write out styles without having to know much CSS at all. This meant they had less to think about when building out simple components, saving (albeit short) time for worrying about bigger problems.

Writing this:

const button = css`
    ${tw('rounded text-white bg-blue')};
`;

Is the equivalent of writing this:

const buttonClass = css`
    border-radius: 0.25rem
    color: #fefefe;
    background-color: #7070ea;
`;

While a relatively simple example, the Tailwind approach for this button class didn’t require much thought at all. If wanted the button to be rounded I would just add rounded. If I wanted a blue background I would just add bg-blue. It proved to be an incredibly fast way to build out presentational components. It also works just as you’d expect with ::before and :hover as well.

const buttonClass = css`
    ${tw`bg-purple`}
    :hover {
        ${tw`bg-purple-lighter`}
    }
`;

Another great bonus for having so much of our CSS basics handled by tailwind means there is a great deal of consistency on styling, as long as we are consistent in using tailwind. All of our colours and expected spacing etc etc is managed by tailwind. If we have use tailwind as expected, this means we should have consistency across our application, as well as the ability to chance these colours and values in one place (tailwind.js) and have it immediately propagate throughout the application.

Babel Macro Magic

I am sure at first glance you would have seen the follow use of tw and been a little confused. If you missed it, here it is again:

consst Button = styled.button`
    ${tw`bg-purple`}
`;

This is where some Babel magic comes into play. Using the very cool Babel Macros we can use the tailwind.macro package to import this babel tool directly into the files we want it in. If you want to check out what macros are and how they work, you can check out this video . This lets us use the tailwind classnames inside the emotion template literal strings and it gets compiled down into the CSS they represent.

Concerns

I don’t claim to think this is perfect. I do feel that by trying to obfuscate a lot of the CSS behind shortcuts with tailwind can make it harder to debug styles and near impossible for developers unfamiliar with the tooling to know what on earth is going on.

I have found that this approach can add some bloat to my component files. Declaring various styled components to be only used once tends to result in some length files. I generally make an attempt to move out styled components I find myself reimplementing across multiple components into a single module.

Final Thoughts

It’s by no means replacement for learning CSS as more complex styles require the usual CSS to be written but it does make it more accessible. Once you get a grip on the tailwind classnames it can be ridiculously fast way to build out components and pages; I find myself blocking out everything really fast only only having to go back and tweak minor things here and there greatly improving my development speed.

EDIT: I have since deleted this repository. It was out of date as both tailwind and the tailwind components package have been updated. I hope to create a new up to date example soon, and a new post showing how the set up works in more depth.
I have an 'starter' repository I made with TypeScript and Next.js you can view on my GitHub here if you're interested.

Certainly curious to hear what you think about this approach or if you have any similar alternatives!

My Tips for Starting at a New Job

Luke Bayliss — Mon, 25 Mar 2019 10:14:02 +0000

My Tips for Starting At a New Job

I’m a month into a new job and I wanted to recap on some things I thought have helped me settle into my new workplace while they’re still fresh in my mind. I hope that my experience can be helpful for anyone else out there who may be nervous about starting a new job, or maybe feeling a little unsettled in a job they’ve just started.

Starting a new job can definitely be scary. You might have a new commute, a new building, a new team, and very likely a new code base. This can be a lot to take in and I want to talk about some of the things I’ve done to make my transition period as pleasant as possible.

Become part of the team

A new team is a big change to become accustomed to. You are essentially infiltrating what could be a very tight knit group of people and that can make you feel like a bit of an outcast in the beginning. Thankfully in my experience everyone has been incredibly warm and welcoming; offering plenty of help, invitations to sit with them at lunch, and asking if I would like to come along to their Friday team lunches out.

Make the most of these invitations as soon as possible as I have found they will be what cements your relationship with your team in the beginning. If you chose to sit alone or avoid team lunches you miss out on a great opportunity to learn more about your team, and you may find it more difficult to connect with them later on.

It can be difficult but try to make the effort to spend time with your team away from the work. I don’t mean you need to see them outside of office hours, but you can always ask if anyone wants to step out for a coffee or even tag along for a walk to grab lunch.

Ultimately I think putting in the effort to become part of team as soon as possible is a sure fire way to settle in faster. It will always be a little awkward and uncomfortable at first, but the more effort you make the easier it will get. Before you know it, you’ll be able to talk to the team like they’re old friends.

Read As Much Documentation As Possible

You might find that after starting at a new job you might not have a lot to do. I’ve waited days for hardware, and even longer for right access and software to do my job. I like to make the most of this inevitable downtime by reading through as much documentation as possible.

Hopefully your new company or team has a habit of writing down all (or at least most) of the important things into a wiki or simmilar. Reading through documentation can give an insight into how projects work, how the architecture has been built out and how certain problems have been dealt with.

Old spike documentation is a great example for getting to know what kinds of problems have come up over the course of a project as well as what and how the team chose to solve them. Not only is this a great insight into the team and the technical side of the projects but it can be an opportunity to learn something new. I like to keep a note pad with me while I read through documentation to write down any technologies that I haven’t seen before as well as make notes about problems I may have solved differently.

And be sure to check out any README.md you come across! There is all sorts of good information stuffed into those things that are there to make your life easier. And if you find out later on that something is missing, you can take the initiative to add it in!

Look At Pull Requests

Similar to above, I like to look at old pull requests. They’re a great way to get a look at the code and how it works, as well as how it’s evolved over time. Seeing what has changed, why it changed and how paints a great picture of the codes flow.

I also like to keep track of anything I think might be important that I see in a pull request. You never know when you might pick up a ticket that is similar to or relevant to an older change. Having a few notes like this can help make up for the lack of knowledge you have of the code base, or at least help shorten the time it takes to learn it.

Don’t be afraid to ask your team mates if they have done anything similar recently and if they can direct you to a pull request. I’ve had people offer to talk me through changes and even give me pointers and tips on how I can move forward.
I also find it interesting what things get pointed out. I’ve learned a few tricks from comments made on pull requests.

Don’t wait for people to make the same comments on your own pull requests, have a look and see if there is anything useful that’s been said before.

Dive into the code

The best way to learn a new code base has got to be diving right into it with no reservations. The more time you spend watching how things work and actively breaking them (locally!) the more faster you’ll learn.

Don’t be afraid to refactor either. If you see some messy code or something that not quite as good as it could be, make en effort to see what you can do to improve it. If there is a good suite of unit tests you can be more confident making changes and validate that you understand what the code is doing.

Pair programming is great. If you can get somebody to sit with you for your first ticket or two make sure to ask as many questions as humanely possible. Don’t worry too much about seeming dumb or unequipped because you question everything, everyone around you has a wealth of knowledge and they’d likely appreciate being able to unload some of it. The next time somebody asks the same question, maybe you’ll be the one who is available to answer it.

Thanks!

There is so much more I could have written down but these things have made the biggest impact on me during the last month of my new job.

Thanks for reading. I’d love to hear your thoughts on what I’ve talked about as well as any of your own tips and/ or insights!

Cover image courtesy of Dylan Gillis at Unsplash.