Post pobrano z: A Personal Journey to Fix a Grunt File Permissions issue

I was working on a personal project this past week and got a weird error when I tried to compile my Sass files. Unfortunately, I did not screenshot the exact error, but was something along the lines of this:

Failed to write to location cssmin: style.css EACCES

That EACCES code threw me for a loop but I was able to deduce that it was a file permissions issue, based on the error description saying it was unable to write the file and from some quick StackOverflow searching.

I couldn’t find a lot of answers for how to fix this, so I made an attempt to fix it myself. Many of the forum threads I found suggested it could a permissions issue with Node, so I went through the painful exercise of reinstalling it and only made things worse because then Terminal could not even find the npm or grunt tasks.

I finally had to reach out to a buddy (thanks, Neal!) to sort things out. I thought I’d chronicle the process he took me through in case it helps other people down the road.

I’ll preface all this by saying I am working on a Mac. That said, I doubt that everything covered here will be universally applicable for all platforms.

Reinstalling Node

Before I talked to Neal, I went ahead and reinstalled Node via the installer package on nodejs.org.

I was told that my permissions issue will likely come up again on future projects until I take the step to re-install Node yet again using a package manager. Some people use Homebrew, though I’ve seen forums caution against it for various reasons. Node Version Manager appears to be a solid option because it’s designed specifically for managing multiple Node versions on the same machine, which makes it easy for future installations and version switching on projects.

Setting a Path to Node Modules

With Node installed, I expected I could point Terminal to my project:

cd /path/to/my/project/folder

…then install the Node modules I put in the project’s package.json file:

npm install

Instead, I got this:

npm: command not found

Crap. Didn’t I just reinstall Node?

Turns out Terminal (or more correctly, my system in general) was making an assumption about where Node was installed and needed to be told where to look.

I resolved this by opening the system’s .bash_profile file and adding the path there. You can get all geeky and open the file up with Terminal using something like:

touch .bash_profile
open .bask_profile

Or do what I did and simply open it with your code editor. It’s an invisible file, but most code editors show those in the folder panel. The file should be located in your user directory, which is something like Macintosh HD > Users > Your User Folder.

This is what I added to ensure Node was being referenced in the correct location:

export PATH="$HOME/.npm-packages/bin:$HOME/.node/bin:$PATH"

That’s basically telling the system to go look in the .npm-packages/bin/ directory for Node commands. In fact, If I browse into that folder, I do indeed see my NPM and Grunt commands, both of which Terminal previously could not locate.

With that little snippet in hand and saved to .bash_profile, I was stoked when I tried to install my Node modules again:

cd /path/to/my/project/folder
npm install

…and saw everything load up as expected!

Updating Permissions

My commands were up and running again, but I was still getting the same EACCES error that I started with at the beginning of this post.

The issue was that the project folders were originally created as the Root user, probably when I was in Terminal using sudo for something else. As a result, running my Grunt tasks with my user account was not enough to give Grunt permission to write files to those folders.

I changed directory to the folder where Grunt was trying to write my style.css file, then checked the permissions of that folder:

cd /path/of/the/parent/directory
ls -al

That displays the permissions for all of the files and folders in that directory. It showed me that the permissions for the folder were indeed not set for my user account to write files to the folder. I changed directory to that specific folder and used the following command to make myself the owner (replacing username with my username, of course):

sudo chown -R username:staff

I went to run my Grunt tasks again and, voila, everything ran, compiled and saved as I hoped.

In Summary

I know the issues I faced here may either be unique to me or of my own making, but I hope this helps someone else. As a web designer, the command line can be daunting or even a little scary to me, even though I feel I’m expected to be familiar with tools that rely on it.

It’s great that we have community-driven sites like StackOverflow when we need them. At the same time, there is is often no substitute for reaching out for personal help.

---

A Personal Journey to Fix a Grunt File Permissions issue is a post from CSS-Tricks

Post pobrano z: Designing Between Ranges

CSS is written slowly, line by line, and with each passing moment, we limit the space of what’s possible for our design system. Take this example:

body {
  font-family: 'Proxima-Nova', sans-serif;
  color: #333;
}

With just a couple of lines of CSS we’ve set the defaults for our entire codebase. Most elements (like paragraphs, lists and plain ol’ divs) will inherit these instructions. But what we rarely think about when we write CSS is that from here on out we’ll have to continuously override these rules if we want another typeface or color. And it’s those overrides that cause a lot of issues in terms of maintenance and scalability. And it’s those issues that cost us heartbreak, time and money.

In the example above that’s probably not an issue but I think in general we don’t recognize the true strength and dangers of the cascade and what it means to our design systems; most folks think that the cascade is designed to let us overwrite previous instructions but I would warn against that. Every time we override a style that is inherited we are making our codebase vastly more complex. How many hours have you spent inspecting an element and scrolled through each rule in order to understand why an element looks the way it does or how the long chain of inheritance has messed up your styles completely?

I think the reason for this is because we often don’t set the proper default styles up for our elements. And when we want to change the style of an element, instead of taking the time to question and refactor those default styles, we simply override them – making matters worse.

So I’ve been thinking a lot about how we ought to make a codebase that incentivizes us all to write better code and how to design our CSS so that it doesn’t encourage other people to make hacky classes to override things.

One of my favorite posts on this subject was written earlier this month by Brandon Smith where he describes the ways in which CSS can become so complicated (emphasis mine):

…never be more explicit than you need to be. Web pages are responsive by default. Writing good CSS means leveraging that fact instead of overriding it. Use percentages or viewport units instead of a media query if possible. Use min-width instead of width where you can. Think in terms of rules, in terms of what you really mean to say, instead of just adding properties until things look right. Try to get a feel for how the browser resolves layout and sizing, and make your changes and additions on top of that judiciously. Work with CSS, instead of against it.

One of Brandon’s suggestions is to avoid using the width property altogether and to stick to max-width or min-width instead. Throughout that post he reminds us that whatever we’re building should sit between ranges, between one of two extremes. So here’s an example of a class with a bad default style:

.button {
  width: 300px;
}

Is that button likely to be that width always, everywhere? On mobile? In every media query? In every state? I highly doubt it and in fact, I believe that this class is just the sort that’s begging to be overwritten with yet another class:

.button-thats-just-a-bit-bigger {
  width: 310px;
}

That’s a silly example but I’ve seen code like this in a lot of teams – and it’s not because the person was writing bad code but because the system encouraged them to write bad code. Everyone is on a deadline for shipping a product and most folks don’t have the time or the inclination to dive into a large codebase and refactor those core default styles I mentioned. It’s easier to just keep writing CSS because it solves all of their problems immediately.

Along these lines, Jeremy Keith wrote about this issue just the other day:

Unlike a programming language that requires knowledge of loops, variables, and other concepts, CSS is pretty easy to pick up. Maybe it’s because of this that it has gained the reputation of being simple. It is simple in the sense of “not complex”, but that doesn’t mean it’s easy. Mistaking “simple” for “easy” will only lead to heartache.

I think that’s what’s happened with some programmers coming to CSS for the first time. They’ve heard it’s simple, so they assume it’s easy. But then when they try to use it, it doesn’t work. It must be the fault of the language because they know that they are smart, and this is supposed to be easy. So they blame the language. They say it’s broken. And so they try to “fix” it by making it conform to a more programmatic way of thinking.

I can’t help but think that they would be less frustrated if they would accept that CSS is not easy. Simple, yes, but not easy.

The reason why CSS is simple is because of the cascade, but it’s not as easy as we might first think because of the cascade, too. It’s those default styles that filter down into everything that is the biggest strength and greatest weakness of the language. And I don’t think JavaScript-based solutions will help with that as much as everyone argues to the contrary.

So what’s the solution? I think that by designing in a range, thinking between states and looking at each and every line of CSS as a suggestion instead of an absolute, unbreakable law is the first step forward. What’s the step after that? Container queries. Container queries. Container queries.

---

Designing Between Ranges is a post from CSS-Tricks

Post pobrano z: What is Timeless Web Design?

Let’s say you took on a client, and they wanted something very specific from you. They wanted a website that without any changes at all, would still look good in 10 years.

Turns out, when you pose this question to a bunch of web designers and developers, the responses are hugely variant!

The Bring It On Crowd

There are certain folks who see this as an intreguing challenge and would relish the opportunity.

Accept.

With glee.

— Jeremy Keith (@adactio) July 27, 2017

Accept the challenge 👌

— Dick (@michaeldick) July 27, 2017

Totally deliver 👍

— Kevin Nagurski (@knagurski) July 27, 2017

The „Keep It Simple” Crowd

This is mostly where my own mind went:

focus on minimalist design and great typography.

— Zach Leatherman (@zachleat) July 27, 2017

I would avoid extremes: no extremely vivid colors; a classic font set; clean but not overly minimal; moderate border radiuses

— keith•j•grant (@keithjgrant) July 27, 2017

Focus on the typography.

— Daniel Sellers (@daniel_sellers) July 27, 2017

Keep it clean and minimal with excellent typography.

— ⌘ Sean Bunton (@seanbunton) July 27, 2017

Plus of course some nods to Motherfucking website and Better Motherfucking Website.

The „Nope” Crowd

An awful lot of folks would straight up just say no. Half?

Decline.

— Cennydd (@Cennydd) July 27, 2017

To be fair, we didn’t exactly set the stage with a lot of detail here. I bet some folks imagined these clients as dummies that don’t know what they are asking.

Decline the business, because that’s not a reasonable expectation.

— Len Damico (@lendamico) July 27, 2017

Refuse.

— Jez McKean (@jezmck) July 27, 2017

I wonder if the client presented themselves well, clearly knew what they were asking, and were happy to pay for it, if many of these designers would have responded differently.

Laugh

— Woman Code Warrior (@amberweinberg) July 28, 2017

Still, curious that so many designers didn’t see any the challenge here, just the absurdity.

The „Let’s Get Technical” Crowd

I’m partially in this group! What things can and should we reach for in this project, and what should we avoid?

A) system fonts
B) semantic HTML
C) let the browser's shifting sands on how to render the page update the site for you
D) git drnk

— Sean T. McBeth (@Sean_McBeth) July 28, 2017

mobile-first, svg graphics, time spent on ux analysis (card sort analysis etc), decoupled modular micro-service front+back end

— Adam Mackintosh (@agm1984) July 27, 2017

Honestly an SPA, no external dependents, and build an archive and entry mechanism to handle content. Wildcard redirect and buy 10 yr hosting

— Jeff (@etisdew) July 28, 2017

If you're looking for an actual answer besides no, maybe html only, inline styles, nothing dynamic, no external calls.

— David v2.9.5 (@davidlaietta) July 28, 2017

„No external calls” seems particularly smart here.

Based on experience and observation in my time in the industry, I’d say it’s somewhere around 75% of websites are completely gone after 10 years, let alone particular URL’s on those websites being exactly the same (reliable external resources).

The „It’s About The Content” Crowd

Simple, driven by content

— Eric Shuff (@ericshuff) July 27, 2017

Focus on making it easy to publish and manage great content. Because great content can easily outlive 10 years.

— Deepti Boddapati (@DeeptiBoddapati) July 27, 2017

Very basic, content focus without all the pretty things.

— Bethany (@fleshskeleton) July 27, 2017

Minimal. Large text elements with a few images mixed in with the content and little color.

— Veronica Domeier (@hellodomeier) July 27, 2017

The „See Existing Examples” Crowd

Adopt the Craigslist design philosophy.

— Chris Cashdollar (@ccashdollar) July 27, 2017

Borrow from @daringfireball

— Joe Casabona (@jcasabona) July 27, 2017

Hand them the Google homepage.

— Darth Seh (@seh) July 27, 2017

https://t.co/wu3bjk5zoA that would work I guess

— Pascal (@murindwaz) July 27, 2017

Plus things like Wikipedia and Space Jam. Also see Brutalist Websites.

Interesting Takes

Our very own Robin Rendle had an interesting take. Due to population growth, growing networks, and mobile device ubiquity, they site may not want to be in English, especially if it has a global audience. Or at least, be in multiple major world languages.

Leave it to Sarah to come in for the side tackle:

shape the culture that uses the app/site to hate change

— Overactive Algorithm (@sarah_edo) July 28, 2017

And Christopher to give us some options to keep them on their toes:

A) say, “Is this one of those tricky Google job interview questions?”
B) say, “GeoCities lasted 10,000 years, so this will be easy.”
C) 👀

— Christopher Schmitt (@teleject) July 28, 2017

Why do any design at all?

text file on the server root

— Eric Bailey (@ericwbailey) July 27, 2017

Although I might argue in that case, you might as well make it an `.html` file instead of `.txt` so you can at least hyperlink things.

My Take

Clearly „it depends” on what this website is supposed to accomplish.

I can tell you what I picture though when I think about it.

I picture a business card style website. I picture black-and-white. I picture a clean and simple logo.

I picture really (really) good typography. Typography is way older than the web and will be around long after. Pick typefaces that have already stood the test of time.

I picture some, but minimal copy. Even words go stale.

I picture the bare minimum call to action. Probably just a displayed email address. I’d bet on email over phones.

Technically, I think you can count on HTML, CSS, and JavaScript. I don’t think anything you can do now with those languages will be deprecated in 10 years.

Layout-wise, I’d look at doing as much as you can with viewport units. Screens will absolutely change in size and density in 10 years. Anything you can make SVG, make SVG. That will reduce worry about new screens. Responsive design is an obvious choice.

Anything that even passably smells like a trend, avoid.

Inputs will also definitely change. We’re already starting to assume a touch screen. Presumably, you won’t have to do anything overly interactive, but if you do, I wouldn’t bet on a keyboard and mouse.

I’d also spend time on the hosting aspects. Register the domain name for the full 10 years. See if you can pre-buy hosting that long. Pick a company you’re reasonably sure will last that long. Use a credit card that you’re reasonable sure will last that long. Make sure anything that needs to renew renews automatically, like SSL certificates.

---

More thoughts, as always, welcome in the comments.

---

What is Timeless Web Design? is a post from CSS-Tricks