When should you
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.
The most newbie-friendly way to add a library to a project is to:
- Search for the library
- Look for the source file
- Copy the source file
- Paste what you copied into the project.
This works, but it’s a painful process. It easier if you use CDNs like JSDelivr.
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.
Setting up a new Mac is painful. Here are some of the things I have to do:
- Install all 47 applications I use every day.
- Provide the right credentials for each application.
- Change macOS default settings to the ones I like.
- Set up coding configurations.
- Move files from the old Mac to the new one.
I estimate at least a three day’s worth of work (downloading things and waiting for them to download 😴) if I have to install everything manually.
But I was able to set my computer up in hours (automatically) thanks to dotfiles.
My first task in 2019 is to get a new computer. I didn’t want to change computers, but my old one gave way and I had no choice 😭.
Since I’m already switching computers, I thought it’ll be interesting to share the apps I use on a daily basis.
I hope you find some of them interesting!
Many people wanted two things at Zellwk.com:
- An RSS feed (to get updates without going through emails).
- An easier way to browse the articles I created.
I finally found the chance to provide these features!
I decided to open source my blog. You can see the source code (for almost everything, except credentials) over at this Github repo.
Many developers feel they need to write clean code. They’re good developers only if they write clean code. They’re lousy developers if they don’t.
I feel the same way too. And I try to make my code as clean as possible.
But this attempt to write clean code actually slows most of us down. We learn slower. We make fewer things. And as a result, we contribute lesser to this world.
I want to make a point that it’s okay to write dirty code. I want to give permission for myself and for you to write dirty code in this article.
Many people try to learn code this way:
- Watch a video
- Follow along with the video
- Expect they’ll be able to code
But they fail. They can’t build things on their own. They panic when they stare into a blank file.
Well, that’s because they missed a critical step in the learning process. They didn’t sit down and figure things out.