If you stuck around for a while, you might have noticed I used to post a video (and an audio) every Friday for most of 2018. I call them "Fridays with Zell".
In 2019, I decided to stop making videos. I want to share why I decided to stop making videos.
Date is weird in JavaScript. It gets on our nerves so much that we reach for libraries (like Date-fns and Moment) the moment (ha!) we need to work with date and time.
But we don't always need to use libraries. Date can actually be quite simple if you know what to watch out for. In this article, I'll walk you through everything you need to know about the Date object.
I use [Visual Studio Code][1] as my text editor. When I write JavaScript, I follow [JavaScript Standard Style][2].
There's an easy way to integrate Standard in VS Code—with the [vscode-standardjs][3] plugin. I made a [video][4] for this some time ago if you're interested in setting it up.
But, if you follow the instructions in the video (or on vscode-standardjs's readme file), you'll come to notice there's one small detail that needs to be ironed out.
Try writing a function the old way, and save it repeatedly. VS code will toggle between having and not having a space before the left-parenthesis of the function.
<Image src="/assets/2019/vscode-standard/functions.gif" alt="VS code toggles between having and not having a space before '('."/>
You get the same problem when you write methods with the ES6 method shorthands:
<Image src="/assets/2019/vscode-standard/methods.gif" alt="Same problem happens when you create methods with ES6 method shorthands."/>
"Do you have any advice on finding a job as a developer?"
Many people have asked me that question, but I can’t give a proper answer because I have never been hired as a developer before. What I did was:
Wriggled my way into a Wordpress dev role in an admin-based internship
Freelanced
Run my own company
So I'm horribly inadequate at answering a question about finding a job.
But Chris Lienert is an expert at it. Chris has experience hiring and building teams of excellent developers. (A fun aside: He used to co-run CSS Singapore, which is a monthly CSS Meetup in Singapore).
I managed to grab Chris (before he left Singapore for good) and asked him to talk about the job application process. You'll hear golden advice in this interview from Chris, like:
Chris' opinions about the hiring process.
How to improve your chances of getting an interview
What to do if you don't get a job
How you should write your CV
What to do during the actual interview
What questions to ask during the interview
How to answer any tricky questions you get
Note: We jumped around a lot in this 1.5 chat because Chris has so much to say about this topic. I highly recommend you listen to the audio version if you can.
To make it easier for you to digest, I also summarized what we talked about into three stages:
We're fierce and protective when we talk about stuff we care about. And as developers, we care a lot about these topics:
Accessibility
Web Performance
CSS
JavaScript
Frameworks
Inclusivity and Equality
There are no problems with voicing your opinion. We all have our opinions and we want them heard. I understand and respect that.
But we should be mindful of the way we say things. If we voice our opinions as complaints, name-calling, and shaming, our opinions don't get heard. No change would happen. They simply create a vicious cycle of worry, hate, and anxiety.
If we change how we project our voice, we can make real change happen. And our culture will change for the better.
We developers have become quite a toxic bunch of people to be with. We create fierce "debates" on every media we're in. Twitter, Facebook, wherever we're at.
We talk about how CSS suck (and how they don't).
We talk about Accessibility and Performance (and bitch companies that don't do them well).
We talk about frameworks vs no-frameworks. React vs Vue vs Vanilla JavaScript. And why you SHOULD learn frameworks vs why you SHOULDN'T learn frameworks.
We also talk about how some technologies are "dead" (even though they still continue living for quite some time).
Everyone has opinions. Most of these opinions are complains. We spread anger, fear, and worry in our communications. Daily
This should stop (but it won't, because you can't control what people say or do). What you can do is take a break and ignore what everyone else has to say.
JavaScript is a strange language. Once in a while, you have to deal with a callback that's in another callback that's in yet another callback.
People affectionately call this pattern the callback hell.
It kinda looks like this:
firstFunction(args, function () {
secondFunction(args, function () {
thirdFunction(args, function () {
// And so on...
})
})
})
This is JavaScript for you. It's mind-boggling to see nested callbacks, but I don't think it's a "hell". The "hell" can be manageable if you know what to do with it.
But yesterday, I happened to chance upon Scott O'Hara's [article on hiding content][2]. Scott says we only want to hide content in three different contexts:
When you create a package for others to use, you have to consider where your user will use your package. Will they use it in a browser-based environment (or frontend JavaScript)? Will they use it in Node (or backend JavaScript)? Or both?
If you want to create a package that's usable in both browsers and Node, this article is here to help.
You'll learn:
How to write packages for use in browsers
How to write packages for use in Node
How to publish your packages for use in both browsers and Node
Most developers run npm init right after creating and navigating into a new project.
It makes sense to npm init at the start of the project because we use npm to download dependencies. Once we npm init, we can begin downloading (and saving) our dependencies.
For most projects, this workflow works.
But if you're creating an open source project, the best time to npm init is slightly later. If you npm init right after creating and navigating into the project, you'll miss out a few things.
It's simple to publish a package onto npm. There are two steps:
Create your package.
Publish the package.
But publishing packages the way the industry does it? Not so simple. There are more steps. We'll go through what steps are required, and I'll show you an easy way to publish and update your package.
Many frontend developers begin styling their websites with Normalize. Some developers have personal preferences they add on to Normalize.css. I have my preferences too.
In this article, I want to share these preferences with you. personal CSS reset (that I use in addition to Normalize.css) with you.