Don’t forget to be selfish every now and then

The other day, I stumbled upon an older article by DHH. “Work on what you use and share the rest”.

My core philosophy about open source is that we should all be working on the things that we personally use and care about. Working for other people is just too hard and the quality of the work will reflect that. But if we all work on the things we care about and then share those solutions between us, the world gets richer much faster.

I’ve been keeping this in the back of my mind the past few months.

I was always adding features because I’d expect other people to expect them. It’s a trap! You’re not making people happier by guessing what they might need. You’re not doing anyone a disservice by building things for yourself.

Building things for yourself makes it easier to ship something you feel happy about. It makes it easier to ship something at all.

Don’t forget to be selfish as an open source maintainer every now and then. It’s a good investment in the long run.

I used to fall in the trap of thinking I needed to add features because other people might expect them to be a part of my code, not because I need them myself.

Keep your assets Prettier on every commit

I'm a happy prettier user to keep my CSS and JavaScript files consistent. However, it's hard to keep the discipline to run Prettier before every commit. This week I decided to automate the process with Husky and lint-staged.

As an aside, this is what our .prettierrc generally looks like in Spatie projects:

{
    "printWidth": 120,
    "tabWidth": 4,
    "trailingComma": "all",
    "singleQuote": true
}

Before we get started, we need to ensure our dependencies are installed:

npm install prettier husky lint-staged --save-dev

Running prettier with lint-staged

Lint-staged is an npm package that will run a script on your staged files, in other words, on the files you want to commit. You can filter the staged files you want to run the scripts on with a glob.

We'll add the lint-staged configuration to our package.json file.

{
    "lint-staged": {
        "linters": {
            "resources/**/*.{css,js}": [
                "prettier --write",
                "git add"
            ]
        },
        "ignore": [
            "public/**/*"
        ]
    }
}

This is based on a Laravel project, where assets are stored in resources, and built to public. With the above config, we'll run prettier on every staged CSS and JavaScript file, except if it's in the public folder.

Don't forget the .vue extension in the glob if you're using Vue single file components!

Git hooks with Husky

Husky is pretty straightforward. It registers some git hooks for you after npm install. The hook we care about is pre-commit: we want to format our assets before they get committed to the repository.

We'll add the husky configuration to our package.json file.

{
    "husky": {
        "hooks": {
            "pre-commit": "lint-staged"
        }
    }
}

This will run the lint-staged command on pre-commit.

Since lint-staged only applies to files you've changed, it runs pretty fast too, so there's not too much extra overhead while committing!

The great divide

Chris Coyier consolidated an array of opinions about what it means to be a frontend developer today.

On one side, an army of developers whose interests, responsibilities, and skill sets are heavily revolved around JavaScript.

On the other, an army of developers whose interests, responsibilities, and skill sets are focused on other areas of the front end, like HTML, CSS, design, interaction, patterns, accessibility, etc.

It's that other side that seems to really be feeling this divide. A quote from Mandy Michael:

What I don’t understand is why it’s okay if you can “just write JS”, but somehow you’re not good enough if you “just write HTML and CSS”.

When every new website on the internet has perfect, semantic, accessible HTML and exceptionally executed, accessible CSS that works on every device and browser, then you can tell me that these languages are not valuable on their own. Until then we need to stop devaluing CSS and HTML.

A lot of these excerpts really hit home. I'm looking forward to the conversation this might spark.

Read the full piece on css-tricks.com.

An introduction to Phoenix LiveView

The last year or two, I've been playing around with Elixir. Chris McCord, author of the Phoenix web framework, is working on a new feature for Phoenix: LiveView.

Phoenix LiveView is an exciting new library which enables rich, real-time user experiences with server-rendered HTML. LiveView powered applications are stateful on the server with bidrectional communication via WebSockets, offering a vastly simplified programming model compared to JavaScript alternatives.

In short, LiveView enables you to enable interactive, real-time app, without touching any JavaScript, as the application logic lives on the server.

LiveView looks like an interesting alternative to the current SPA trend. You can read Chris' entire walkthrough on dockyard.com. Even if you're not familiar with Elixir yet, LiveView's proposed programming model is an interesting topic on it's own.

Not all code is the same

As a short follow-up to Everyone has JavaScript, right?, there's more to JavaScript than availability, there are also the performance implications.

I don’t think most people are saying, “don’t use JavaScript.” That would be absurd.

But use less, use it wisely, and don’t depend on a giant framework for simple stuff. Use as little JS as possible to get the experience you want. You can do that and still have a great, immersive app.

I believe we're reaching for JavaScript more often because of its ecosystem, not because it's the better solution. The JavaScript ecosystem simply has incredible tools to build interfaces, and I hope server side solutions will still be able to compete.

I don't have a conclusion ready, I'm just interested in the topic. To be explored in 2019. Meanwhile, read Chris Ferdinandi's thoughts on the matter.

Hindsight 2018 edition

Well since you asked, Mohamed 🙃, a little retrospective on this past year…

I realized my passion lies with designing and building interfaces. I don't care about the language; PHP, JavaScript, CSS and HTML are all equally fun for me to be working with. As long as I'm actively shaping to the end user experience.

I wrote 11 full-length articles on my blog. Unfortunately one shy of my one-per-month goal, although I suppose this post makes 12!

I started a newsletter to share links. Soon after that, I stopped the newsletter and started sharing links on my blog instead ¯\_(ツ)_/¯ However, I'm very happy with the current state of my site, and I'm glad it also became a place to share things with more context and longevity than Twitter.

I got started with public speaking. I spoke at the unconference at PHP Benelux, and won a prize for it being the best unconference talk (hooray!) I also spoke at the Full Stack Antwerp meetup. I enjoyed both experiences, despite the fact that preparing a talk requires an excruciating amount of work, but I'm still undecided whether it's something I want to pursue more of in the future.

I got better at organizing, both for work and life in general. Things is a godsend!

I got a dog! Probably the best and most influential decision I've made in my personal life this year. What a lovely little creature he is.

In 2019, the area I want to improve most on professionally is design. I also want to write more and read more. I want to improve my communication skills. I want to get better at budgeting my personal finances. I want to cook more. Maybe start baking things too. Most importantly, I want to finish things more often. Either way, I'm looking forward to what 2019 brings.

Everyone has JavaScript, right?

I used to think disabled JavaScript went hand in hand with visitors explicitly blocking it. I came to the conclusion that I don't necessarily need to cater to that crowd, because the degraded user experience was by choice. After reading through this chart, I realized how wrong I was.

Sometimes your JavaScript just won’t work. Be prepared.

Read the flowchart on kryogenix.org.

iA Writer 5.2 will embrace variable fonts

iA Writer is one of my favorite pieces of software, and I can't even say why. It just feels so good. In the upcoming 5.2 release, iA Writer will replace the current iA Writer Duo font with iA Writer Quattro, a variable font.

While traditional fonts offer in a limited number of weights, variable fonts offer an infinite scale between the weights and features.

Variable fonts have different "axis" which allow an infinite amount of variations.

Gingham variable font. Taken from Get started with variable fonts by Richard Rutter.

In iA Writer 5.2 we automatically adjust the optical weight depending on the type size you use. Weights change depending on size. The font is getting thinner and tighter spaced as we increase the type size. This has not been possible in the past.

Not just size, but different screens demand different weights, too. Fonts look different on screens; some screens have more or fewer pixels, like retina and high-density retina. Depending on what device you use, we apply different gradings.

Our job would almost be boring if type size, pixel density, and screen type were the only challenges of modern typography. As you might have noticed, dark backgrounds make white text shine brighter. That’s why iA Writer 5.2 tones the optical weight down another 5% for night mode. Who does such crazy things? Crazy people.

I, for one, welcome our new variable font overlords. More words and pictures on ia.net.

If you want to learn more about variable fonts in general, or play around with a few specimens, check out Axis-Praxis.

A blogging style guide

Robert Heaton shares 39 bullets to improve your blogging. A few of my favorites:

Choose a few people whose style you like and copy it as hard as you can without infringing on any intellectual property. I aim for a combination of the Economist, Paul Krugman, and Terry Pratchett.

If you need a quick name for a generic fictional character, consider using one from a culture or gender that you usually wouldn't. Even if you don't believe that representation in the media matters, you've surely got to concede that there's still a chance that it might, and that the cost of sometimes calling your imaginary computer programmers Julianna is zero.

It's fine to spend 10, 20, 30 minutes staring into space when your plan for the day says that you're meant to be writing.

It is admittedly even better to spend that 30 minutes spamming down any old nonsense that you can refine later, or that at least helps get you mentally unblocked.

Read all 39 tips on robertheating.com.

Bézier moi

I've been reading up on SVG and Bézier curves for a side project that involves a custom-made chart (blog post about that later!). Funnily enough, this article on Bézier curves popped up on Hacker News earlier this week.

One little animation in the article totally stands out, and helped me make sense of what the control points of a Bézier curve actually do.

Taken from cormullion.github.io

While you’re waiting, have a look at another animation; this is my artist’s impression of the De Casteljau algorithm dividing the control polygons around a Bézier curve as the parameter n moves from 0 to 1. The idea is that as p1 divides A to A1, p2 divides A1 to B1 and p3 divides B1 to B. So, pp1 divides p1 to p2, and pp2 divides p2 to p3. And you keep doing this until you can’t divide any more, and eventually the point P plots the course of the final Bézier curve. The red and blue parts of the curve show that this technique is also a good way to split a single Bézier curve into two separate ones, and the red and blue parts are separate control polygons.

Read the full article on cormullion.github.io.

Readability is relative

When I write a library that's going to be used by others, I strive for a gentle learning curve. When someone reads code that uses my library, I want them to understand what's happening without reading a bunch of documentation first. I tend to keep my API's as explicit as possible, and try to stay away from odd or foreign notations.

My colleague Brent is writing a library to deal with date & time periods in PHP. There was a discussion whether a period's boundaries should be included in the range or not.