What bit of advice would you share with someone new to your field?

The most FA of all the FAQs.

Here's Laura Kalbag:

Find what you love. Don’t worry about needing to learn every language, technique or tool. Start with what interests you, and carve your own niche. And then use your powers for good!

And my own:

Buy a domain name. Figure out how to put an HTML file up there. Isn’t that a powerful feeling? Now you’ve got table stakes. Build something.

Definitely, go read other A Book Apart author answers because they are all great. My other favorite is just three words.

Automate Your Workflow with Node

You know those tedious tasks you have to do at work: Updating configuration files, copying and pasting files, updating Jira tickets.

Time adds up after a while. This was very much the case when I worked for an online games company back in 2016. The job could be very rewarding at times when I had to build configurable templates for games, but about 70% of my time was spent on making copies of those templates and deploying re-skinned implementations.


Render Children in React Using Fragment or Array Components

What comes to your mind when React 16 comes up? Context? Error Boundary? Those are on point. React 16 came with those goodies and much more, but In this post, we'll be looking at the rendering power it also introduced — namely, the ability to render children using Fragments and Array Components.

These are new and really exciting concepts that came out of the React 16 release, so let’s look at them closer and get to know them.


PSA: Yes, Serverless Still Involves Servers.

You clever dog. You've rooted it out! It turns out when you build things with serverless technology you're still using servers. Pardon the patronizing tone there, I've seen one-too-many hot takes at this point where someone points this fact out and trots away triumphantly.

And yes, because serverless still involves servers, the term might be a bit disingenuous to some. You could be forgiven for thinking that serverless meant technologies like web workers, which use the client to do things you might have otherwise done on a server and is where the term serverless was headed. Alas, it is not.


Create your own Serverless API

If you don’t already know of it, Todd Motto has this great list of public APIs. It’s awesome if you’re trying out a new framework or new layout pattern and want to hit the ground running without fussing with the content.

But what if you want or need to make your own API? Serverless can help create a nice one for data you’d like to expose for use.

Serverless really shines for this use case, and hopefully this post makes it clear why. In a non-serverless paradigm, we have to pick something like express, we have to set up endpoints, we have to give your web server secured access to your database server, you have to deploy it, etc. In contrast, here we'll be able to create an API in a few button clicks, with minor modifications.


Remote Conferences; Bridging the Gap, Clearing the Odds

A few weeks back, I saw one of my esteemed mentors decry the psychological traumas he had experienced, following series and series of refusals at certain embassies.

little girl surprised
“A child concentrating hard at school” by Les Anderson on Unsplash

You would think he went for a contract he did not have the capacity for, but then, you would have been wrong. He needed to impart knowledge. He opted to do so across borders, but then, some realities were harsh.

Borders and geographical constraints can cause a lot of havoc. However, it can only do so, when the full discovery of a better way to impart knowledge across borders has not been made. Video conferencing technology has become handy at times like this. Hence, your traditional seminars, conferences, and talks can easily be achieved from anywhere, regardless of your role.


The div that looks different in every browser

It's not that Martijn Cuppens used User Agent sniffing, CSS hacks, or anything like that to make this quirk div. This is just a plain ol' <div></div> using the outline property a la:

div {
  outline: inset 100px green;
  outline-offset: -125px;

It looks different in different browsers because browsers literally render something differently in this strange situation.

I happened upon Reddit user spidermonk33's comment in which they animated the offset to understand it a bit more. I took that idea and made this little video to show them behaving even weirder than the snapshots... (more…)

Scrolling Gradient

If you want a gradient that changes as you scroll down a very long page, you can create a gradient with a bunch of color stops, apply it to the body and it will do just that.

But, what if you don't want a perfectly vertical gradient? Like you want just the top left corner to change color? Mike Riethmuller, re-using his own technique from the CSS-only scroll indicator (A-grade CSS trickery), did this by overlapping two gradients. The "top" one is fixed position and sort of leaves a hole that another taller gradient peeks through from below on scroll.

Anatomy of a malicious script: how a website can take over your browser

By now, we all know that the major tech behemoths like Facebook or Google know everything about our lives, including how often we go to the bathroom (hence all the prostate medication ads that keep popping up, even on reputable news sites). After all, we’ve given them permission to do so, by reading pages and pages of legalese in their T&C pages (we all did, didn’t we?) and clicking on the "Accept" button.

But what can a site do to you, or to your device, without your explicit consent? What happens when you visit a slightly "improper" site, or a "proper" site you visited includes some third-party script that hasn’t been thoroughly checked?


Design Systems at GitHub

Here’s a nifty post by Diana Mounter all about the design systems team at GitHub that details how the team was formed, the problems they've faced and how they've adapted along the way:

When I started working at GitHub in late 2015, I noticed that there were many undocumented patterns, I had to write a lot of new CSS to implement designs, and that there weren’t obvious underlying systems connecting all the pieces together. I knew things could be better and I was enthusiastic about making improvements—I quickly discovered that I wasn’t the only one that felt this way. There were several folks working on efforts to improve things, but weren’t working together. With support from design leads, a group of us started to meet regularly to discuss improvements to Primer and prioritize work—this was the beginnings of the design systems team.

This whole post had me nodding furiously along to every word but there was one point that I particularly made note of: the part where Diana mentions how her team decided to make “the status of styles more obvious” in order to communicate changes to the rest of the team.

Lately, I’ve noticed how design systems can demonstrate the status of a project, which is super neat. Communicating these large changes to the codebase early and frequently, over-communicating almost, is probably a good idea when a design systems team is just getting started.