How a 12-week program resulted in open-source education

Manifold’s internal mentorship program provides opportunities for coworkers to learn from one another over a three month period. The relationship doesn’t imply relative seniority between the mentor and mentee, but simply a desire to share and learn. We do this to foster continuous growth and to stay committed to our goal to raise up all employees to a senior-level regardless of where they started. But above all, it’s a way for us to connect with one another outside of pure work assignments.

For the summer 2018 session, Nicole Tibaldi and I paired up to dive into the finer points of CSS. We ended up splitting our time into a 2-track process: homework assignments to learn the concepts, and work projects for Nicole to apply the knowledge.

CSS Puzzles

It’s hard to identify difficult problems in CSS until you’re forced to recreate a design that—for some special reason—is just hard to pull off. Oftentimes the final result is subpar, merely because there was another clever approach that you didn’t know was an option. Thinking back to all the CSS I’ve written over the last 13 years or so, I tried to dig up some of the hardest problems I’ve encountered and extract an isolated example for each.

For each of the following exercises, you can find the code here: https://github.com/dangodev/css-exercises

Exercise 1: Markup & Grid

Sometimes you can control markup; sometimes you can’t. Exercise 1 forces you to use CSS Grid to realize you can rearrange and re-set layout without touching markup.

Exercise 2: perfect design, imperfect content

We’ve all gotten a design with a perfect layout… that only fits a very specific content length. This exercise is all about dealing with missing content, and different lengths, as elegantly as possible.

Exercise 3: interactive CSS

Bug, or feature? This exercise forces the user to abuse CSS to create interactivity most would only think is possible with JavaScript. Even though this may not be best practices, understanding what’s possible with CSS is the goal.

Exercise 4: perceived performance

This exercise forces you to load large assets over a slow connection, and figure out how HTML & CSS can solve slow-loading fonts and images (hint: font-display and fixing image heights can smooth the experience).

Exercise 5: layering

Exercise 5 explores the nature of browser layering, and how to fix the “unexpected” scenario of layering by DOM order (in the photo above, notice how the blue glow tucks under the card to the right). Once you’ve figured out the layering part, you’ll have to figure out how to apply that to animations!

Exercise 6: nth child selectors

Nth-child and sibling selectors in CSS are a classic examples of not using them because you don’t know they’re an option. They can be powerful tools in managing styling when used effectively.

Exercise 7: CSS animation

This is where things start to get fun, and we add interactivity, animation, and 3D perspective with only a few lines of CSS

Exercise 8: ratio resizing

There are many times where ratios need to be locked in, especially when media is present or design demands it. This exercise explores how to lock in ratios to responsive layout using only a sprinkle of CSS.

Nicole’s projects

After a few months of mentorship and working on projects together, Nicole threw the following together:

Together we tackled CSS & SVG animations, and even got into interactive dataviz with D3.js (which was a little sidetrack outside of styling, but who can say no to dataviz?).

How to set up your own mentorship program

Most would say mentorship is important for their own growth as well as their company’s, but few feel equipped to start it themselves. Here at Manifold we’ve found the following small steps help equip even hesitant mentors:

1. Set an end date, and meeting times. Set boundaries. Determine a duration of weeks (ideally 8–12 weeks) to run the program, and determine hourly commitment for the mentor and mentee each week. Set a regular meeting to stay on track. Be mindful of both mentor’s and mentee’s time and don’t overcommit!
2. Ask the mentee to set goals. Ask the mentee what they would like to learn by the end of the program. The mentor should help with this. Aim for a real challenge that pushes comfort zones without being unrealistic. Shoot for ~90% of goals met—you set a real challenge that pushes limits but the mentee doesn’t feel like they’ve mostly failed.
3. Check in each week on those goals. The mentor should constantly level-set, and make sure the mentee feels like they’re getting closer. Be wary of goal-shifting! As the mentee gains experience, minor details and focus may shift, but you should still stay roughly within the original parameters set.
4. At the end, ask for improvement. After the program is over, get a third party to ask both the mentor and mentee how the program went. Was it too much work? Not enough? Did the mentee feel they leveled up? Was the mentor overworked? How was communication? Every organization has different dynamics, so running a “trial” mentorship program and gathering data will set up subsequent runs for success.

How would your org benefit from such a program? How was ours? Please leave a comment with your thoughts & experience with mentorship programs.

And if you’re looking to level up yourself on our team, we’re also hiring!

CSS Puzzles: a mentorship program for better styling was originally published in manifoldco on Medium, where people are continuing the conversation by highlighting and responding to this story.

IronWorker is a containerized background job manager that gives you incredibly fast, super-scalable architecture with almost no code. Because it handles tasks asynchronously, any web app can offload heavy lifting such as slow database operations or large data processing to IronWorker without slowing down your users’ experience.

But there’s one problem—if a background worker is talking to all of these services, where do the secrets go? Docker containers are fantastic packages for consistent code runtime, but it’s no place for secrets to live—cached and available to everyone that can access that Docker image.

Manifold gives you a 2-minute setup to IronWorker (and many other cloud services) — and it can also solve the problem of secrets for you, completely free. As developers ourselves, we built the tools we’d like to exist. We’ve been using this internally for over a year, and think it’s a pretty great solution.

For extra fun—and to see how secrets work in practice—we’ll hook up IronWorker to another Manifold marketplace service, LogDNA, to enhance the experience with realtime logs. On IronWorker, you don’t get to view a single log until after a task is finished running (or erring 🙃). So taking advantage of a cloud-based logging service to give you realtime updates is a huge win, especially for large tasks.

What can I use IronWorker for?

IronWorker is just one piece of the Iron.io devops suite of products. Using IronWorker, you can handle several incoming tasks at once from multiple sources, sort the queue by priority, and monitor the status of all of those concurrent tasks.

It takes care of big, slow, heavy stuff.

Iron.io’s post Top 10 Uses of a Worker System explains why workers are simply better for heavy tasks like image processing, transactional emails, and data sifting. Give it a read to, as the author put it: “Change the way you think and program.”

Setup

You’ll need a few things to set up for this blog post:

1. Sign up for an account on Manifold (it’s secure, free, and you can cancel at any time).
2. Install the Manifold CLI, and log in with manifold login
3. Install the Iron.io CLI (Manifold will log in for us!)
4. Install Docker, create a Docker ID if you haven’t already, and log in with docker login

1. Provisioning LogDNA and IronWorker

From your Manifold account, create a new project. We’ll call it iron-example in our post, but name it any kebab-case name you’d like!

From there, provision LogDNA and IronWorker plans to the project.

Already have an existing IronWorker or LogDNA plan?

If possible, we’d recommend signing up through our Dashboard to take advantage of single sign-on and aggregated billing, but you can still power your pre-Manifold account with our integrations.

To integrate your existing accounts, click the “Bring your own service” button and entering your credentials: IRON_TOKEN and IRON_WORKER_PROJECT_ID for IronWorker; KEY for LogDNA.

Signing into LogDNA

Back in our project, we can now see the new LogDNA and IronWorker services present. Click Open LogDNA Dashboard.

With Manifold’s single sign-on we get to skip signup and go straight to our project’s LogDNA dashboard. Click the Everything tab to see our app’s logs.

It’s empty for now, but we’ll come back to this screen in just a moment to see our logs.

2. Uniting the workers on Iron.io

Building a worker in Node.js

Now that we have LogDNA and IronWorker accounts managed in Manifold, let’s get some worker code up.

We’re starting with a bare-bones example Node.js app that’s already configured for Manifold + IronWorker. To view this code locally, run the following in a terminal window:

git clone git@github.com:manifoldco/iron-example-app.git
cd iron-example-app
npm i

This is our entire app, minus config:

So our app…

1. …authenticates with LogDNA using Manifold CLI’s injected KEY
2. …doesn’t authenticate with IronWorker because that’s where our code will be running
3. …logs some simple text first,
4. …followed by our IronWorker payload with IronWorker.params() (we’ll get back to that)
5. …and a final log showing us the job’s complete.

🐳 Containerizing with Docker

IronWorker runs off Docker Hub, which is great news for the many dev teams already using it. And if you’re new to containerization, Manifold can help make adoption relatively painless.

Our app uses a custom Dockerfile (first letter uppercase, no extension) in the root folder of our application, configured for Manifold CLI within IronWorker.

Assuming Docker is running, and we’re logged in with docker login, we’ll build a new Docker container and tag with -t. You can think of tags like versions of your code, so every time you make a change, you should give it a new tag. A common format is DOCKER_USERNAME/APP_NAME:VERSION (e.g.: manifold/iron-example:0.0.1). In the following examples, replace USERNAME with your Docker username. After it’s built, we’ll send it to Docker Hub.

docker build -t USERNAME/iron-example:0.0.1
docker push USERNAME/iron-example:0.0.1

💁 Tip: testing stuff, or pushing an unstable version? Append -rc.0, -rc.1, etc. to the end of your tag to keep your versions clean.

🏋️‍ Pushing to Iron.io

We’re letting Manifold handle our credentials, but IronWorker will need to authenticate into Manifold to pull secrets. Rather than give out our Manifold email & password—that’s not secure!—we can create a special token just for this worker with read-credentials permissions just for this case:

manifold tokens create

Keep it secret, keep it safe! You won’t be able to retrieve this later. But you can generate a new token, or deprecate an old token at any time with manifold tokens --help.

With that token, we can use Manifold to inject the IRON_TOKEN and IRON_PROJECT_ID secrets as runtime variables. To alert Iron.io to our image on Docker hub, run the following:

manifold run -p iron-example -- iron register -e "MANIFOLD_API_TOKEN=MY_MANIFOLD_TOKEN" USERNAME/iron-example:0.0.1

This is using manifold run to inject variables attached to our iron-example project (-p). It’s running the iron register command, injecting a single runtime variable (-e): our Manifold token from the previous step. Our final argument is the tag of the image we just pushed to Docker Hub.

Note: to improve security and performance, Manifold isn’t a proxy; it only injects the secrets. Your app connects directly to all these services with no middleman.

Checking our work

If we go back to our iron-project in the Manifold Dashboard, we can click the Open IronWorker Dashboard button to see our Dashboard:

Once signed in, we should see our Docker image on the home screen:

🎉 Woo! 🎉 Iron.io is now running our worker code, ready to be assigned tasks.

Recap for deployment

Say we make a change in our app, and need to update IronWorker to USERNAME/iron-example:0.0.2. Here’s a recap of what to do:

docker build -t USERNAME/iron-example:0.0.2 .
docker push USERNAME/iron-example:0.0.2
manifold run -- iron register -e "MANIFOLD_API_TOKEN=MY_MANIFOLD_TOKEN" USERNAME/iron-example:0.0.2

1. Re-build with docker build
2. Push to Docker Hub with docker push
3. Tell Iron.io about the new Docker Hub image with iron register (with manifold run logging in for us)

You can add a deploy NPM Script in package.json to automate this, and save a little typing:

TAG="USERNAME/iron-example:0.0.2" MANIFOLD_TOKEN="MY_TOKEN" npm run deploy

This is what the script looks like in our package.json (we’re also using a .manifold.yml file to set the project & team):

Note: this was the shortest amount of typing I could think of without committing a sensitive secret to version control. If you can think of an even shorter way to run this, leave a comment!

3. Queueing for everyone

Now comes the good part: actually seeing our app run. Sign in to your LogDNA dashboard again from your Manifold project, and navigate to Everything. Also sign into your IronWorker dashboard, and click on the name of your image.

You’ll see a screen that shows you all your queued tasks, and which tasks ran successfully and which erred (green and red in the screenshot). This will be blank if you haven’t queued any. From that screen, click the Queue Task button to test our code.

For now, all you need to fill out is Payload, in JSON format. For our example, we’ll feed it the time-honored, classic dish:

{
  "foo": "bar"
}

Click Queue Task and you’ll see it run. Now, if everything worked as intended, pop over to LogDNA to see:

We see the thing we typed! That’s a very good sign!

Our app now takes the payload received from IronWorker through IronWorker.params(), and logs it to LogDNA. This means that your code can be dynamic, accepting a wide range of inputs and tasks based on the data it’s given. IronWorker.params() will be your entrypoint to any kind of data needed for your super special task.

Your worker is basically now an endpoint, ready for any task large or small. The secure connections are handled thanks to Manifold, and the parallelism is handled for you thanks to Iron. ✨

Next Steps

Running tasks manually gets old real quick, especially because we’re developers and will automate anything we have to do three times 😎. Now that we have a worker with running code and able to handle payloads, we’re getting into serious territory. I’ll end the post here, showing how to schedule tasks from the IronWorker dashboard, as well as programmatically from another application.

Scheduling Tasks from within IronWorker

IronWorker has a handy dashboard to create and manage scheduled tasks just one tab away! Click scheduled tasks in the navigation, followed by the Schedule Task in the top-right to be met with a familiar screen:

Here, we can also take a payload as with the manual task, but now we can schedule automatically recurring tasks, like a cron job on a server but with no server or cron jobs to manage.

If your app can run automatically, such as a newsletter or scraper, this is probably the best place to manage that schedule.

Queueing tasks from outside of IronWorker

Scheduled tasks are great, but most cases will usually involve some other application that needs to queue a job to our worker. Fortunately, the iron_worker NPM module we were using also comes with a .Client() built in:

Note: remember we didn’t have to authenticate for our worker running on IronWorker, but we will have to for outside apps.

So for any large, arduous, async job, we can simply kick it to IronWorker from any app, and go about our business. In case your stack isn’t in Node.js, fret not: IronWorker client has first-class support for Golang, Ruby, Java, PHP, Python, and .NET too!

We can’t schedule from outside our app, because ideally scheduling should be self-managing! To recap: you can schedule from the IronWorker CLI or the Dashboard, or you can queue from anywhere using the IronWorker client. Consider a different approach if you’re trying to schedule a repeat event programatically.

To learn more about queueing, see the docs on IronWorker client.

From here, the sky’s the limit!

Further Reading

• Building a Scheduled Newsletter in Ruby with IronWorker and Mailgun by Robin Percy
• Top 10 uses of IronWorker by Dylan Starnat
• IronWorker webhooks on the Iron.io docs
• Arguments and variables in Docker by Tim Speed

Secure runtime variables in IronWorker with Manifold was originally published in manifoldco on Medium, where people are continuing the conversation by highlighting and responding to this story.

We migrated our home page from a basic React boilerplate (React Boilerplate) to Next.js, a progressive web app framework for React. We made no other changes, and the switch was basically invisible. The load times were better than we expected—it was basically free performance:

On a fast connection, fast CPU, our site load time went from 1.5 seconds to 0.2 seconds — 7.5× faster! On an average connection and device, our site load time went from 7.5 seconds down to 1.3 seconds.

Free performance, you say?

To understand what a progressive web app (PWA) does, it’ll take a bit of understanding what happens in the time between a user visiting a URL (our website), and seeing something rendered on the page (in this case, our React app).

The stages

1. Once a user hits a URL, the network request is a flat cost in resolving the DNS and requesting that path from the server. It’s pretty quick, usually happening in < 100 milliseconds, but it’s mentioned because it does take some time.
2. From there, the server returns the HTML for the page, but the page will stay blank while every <script> and <link> tag inside <head> is downloaded (unless it’s marked async). There’s more going on in this step than the diagram shows, but for our purposes we’ll lump these processes together.
3. With the HTML and critical assets loaded, the browser starts to paint what it can, while downloading the rest (images, etc.) in the background. Ever wonder why images sometimes “pop” in or sometimes take a while to load? This is why! This lets you look at pages sooner.
4. JavaScript can only parse & execute after it’s downloaded. Depending on how much JS there is (which can be a lot for a normal React app if it’s bundled into one file), this could take several seconds or more (note: JS doesn’t have to wait until everything else downloads to begin executing, despite the diagram layout).
5. In the case of a React app, it has to now modify the DOM, which will trigger another browser paint after it’s all done, and another cycle of asset downloads. The time this will take will depend on the complexity of the page.

Sooner is better!

Because a progressive web app takes React and spits out static HTML and CSS, that means users are looking at your React app at Stage 3 rather than Stage 5. Which, in our tests, took anywhere from 0.2–4 seconds depending on your connection and device speed, compared to 1.5–22 seconds.

…seriously—free performance? No catch?

No catch! PWAs are a bulletproof way to serve your React app faster.

The reason why progressive web apps and PWA frameworks like Next.js are still catching on is because, traditionally, JS frameworks didn’t make it easy to generate static HTML. Today, the landscape is much different, with React, Vue, Angular, and the rest having first-class support for server-side-rendering. However, a deep understanding of bundlers and build tooling is still required to make it happen, and it’s not without its fair share of pain points. The recent appearance of PWA frameworks like Next.js and Gatsby (both late 2016/early 2017) have become a boon to PWA adoption by lowering the barrier to entry (and arguably making it fun!).

While not every application will fit into Next.js, for many React applications it boasts free performance and bandwidth boosts.

How bad is the move?

All-in-all, our migration of manifold.co wasn’t too bad, but we did run into the following pain points because of our unique setup:

🏎 React Router gets left in the dust

React Router had to go, because Next.js has its own built-in router that communicates better with its code splitting optimizations—on top of the PWA architecture I just described—to load pages much faster than any client-side router could do on its own.

In practice, because we weren’t doing a lot of complicated routing that React Router offers, for us it was as simple as replacing React Router’s standard <Link /> component with Next.js’s:

Overall, not too bad! We basically renamed a prop and added an <a> tag for SSR. Because we’re using Styled Components as well, I also found adding the passHref prop was necessary in most instances to make sure the href always made it to the generated <a> tag.

To see Next.js’ fancy router optimizations in action, pop open your Network Tab on manifold.co and click a link. In the image above, clicking a link to /services returns an XHR request for services.js rather than a normal 200 request for /services.

I’m not just talking about client-side routing—of course React Router exists for this—I’m talking about the actual .js chunk that was intelligently split out, and loaded on demand. That’s just a nice bundler feature Next.js does automatically for you out-of-the-box. This is much better than our old method of lobbing 1.7 MB of JavaScript at the client before they see anything. Although it’s not perfect, this is much closer to users’ only downloading code for pages they’re viewing than before.

⬛️ Blackboxed Redux

Continuing from the previous point, all that fancy Next.js optimization and code-splitting comes at a price: because it handles code-splitting at the page level, it won’t let you access the root React component or React DOM’s render method. If you’ve set up Redux yourself before, you’ll notice this poses a problem: where does the Redux <Provider /> sit?

In Next.js, they made a special withRedux HOC wrapper you must wrap every top level component with, on every page:

export default withRedux(HomePage);

While that’s not too bad, if you need shimmed createStore() methods like in the case of redux-reducer-injectors, plan on some extra time debugging their wrapper (sidenote: don’t use reducer injectors—ever).

Also because of its blackboxed nature, using Immutable with Redux becomes problematic. Although Immutable is supposed to work with this, I ran into problems with either the top-level state not being immutable (“get is not a function”), or the wrapper trying to use JS object dot notation rather than .get() (“Can’t get catalog of undefined”). And I had to dive into source code to debug this. After all, Next makes you use their provider for a reason.

In general, this highlights a key problem with Next.js: very little is documented. They have many examples to draw from, but if your usecase isn’t there, good luck!

🐶 Stop trying to make `fetch` happen

We were using react-inlinesvg, which offers the stylability of inline SVGs and the cacheability of remote requests. Only problem is: there’s no such thing as an XHR request when server-side rendering (at least, not in the sense of webpack URLs like it was expecting), so this blew up trying to SSR.

While there are some other inline SVG libraries that support SSR, I decided to drop it since most our SVGs were one-off illustrations anyway. I either swapped them out to an <img> tag if it didn’t need styling, or embedded them as React JSX. This might be a win-win, as the JSX illustrations are now delivered in the initial page load, and the client bundle had 1 library removed.

If you do need fetch in general (I did end up needing it for another library), you can configure that via next.config.js using whatwg-fetch and node-fetch:

👯‍ Client JS & server JS: the dynamic duo

The last confusing part of Next.js is it runs twice — once for server, and again for client. This blurs the lines a bit between client JS and Node JS in the same codebase, resulting in errors you’re not used to like fs is undefined when Node’s fs tool is trying to run in the client.

As a result, you’ll have to engineer shims like this within next.js.config:

The config.isServer flag within webpack becomes your best friend when the same code has to run in multiple environments.

You also have Next.js’ propretary getInitialProps() lifecycle addition to React, which only runs in server-mode, as well:

Oh, and let’s not forget about our good friend window, needed for event listening, window measurement, and a plethora of useful functions, which is Node.js’ greatest weakness:

Wrapping your head around when the same JavaScript is either executing in Node.js or the client can be one tricky mindgame even Next.js can’t save you from. But using config.isServer and getInitialProps() to your advantage will serve you well.

What’s next, after Next?

For the short-term, Next.js more than meets our needs of server-side rendering for performance, delivering our site to non-JavaScript-enabled devices, and now allowing rich meta tags.

We may, in the future, explore other options if and when our application needs server-side-rendering and has a more complicated server layer (we’ve talked about integrating single-sign-on between manifold.co and dashboard.manifold.co). But until then, Next.js was a huge payoff for little time investment.

We migrated to Next.js to serve our home page 7.5× faster was originally published in manifoldco on Medium, where people are continuing the conversation by highlighting and responding to this story.

How to take back full control of your cloud services in one afternoon

Using some part of the cloud—whether AWS, Azure, Google Cloud, or others—has become a standard part of modern web development. RightScale’s 2018 State of the Cloud reported 97% of respondents using at least one cloud service.

In most instances, it’s easiest to buy into one cloud ecosystem so you have fewer things to manage. But when prices of a service increase, the platform changes, or you need to add an outside service to the mix, how do you handle switching one service from your vendor-locked cloud, let alone several?

Manifold’s free developer tools provide everything you need to build-your-own cloud from existing providers. To see how, I’ll be taking an example application with authentication, hosting, and account email services, and moving the app off AWS and onto independent providers for all three parts.

The App

Our example app is nothing more than a login with an authenticated page, and a password reset via email. So we’re using the following services:

• AWS Elastic Beanstalk (Node.js)
• AWS RDS Postgres
• AWS Simple Email

You can see the code for the starting application here, in the master branch.

The credentials for the services are all fed in via environment variables through a .env file. Though the values aren’t saved in the app, you can see all the variable names needed in the .env.example file.

Moving to Manifold

With Manifold, you can hook up any service you want—even those not listed on the Services page! But for this example, our usecase is satisfied by the existing services of Mailgun and JawsDB Postgres, so we’ll use those two. But again, once the application uses Manifold, those can be swapped out easily at any time.

To start, sign up for a free manifold account (only takes a few seconds if you authenticate with GitHub). Then, from our project window, we’ll run the following:

Mac (via Homebrew):

brew install manifoldco/brew/manifold-cli

Linux/Windows:

curl -o- https://raw.githubusercontent.com/manifoldco/manifold-cli/master/install.sh | sh

Note: you can read more about this install script on the Manifold CLI Guide.

Then, log in with manifold oauth -- github if you registered via GitHub, or manifold login if you signed up with email / password. Now comes the fun part!

Swapping RDS with JawsDB

Run the following to add a resource, and the friendly CLI will walk you through provisioning (it even gives you pricing and descriptions in-terminal!):

manifold create

For JawsDB, selectjawsdb as the service type, and kitefin for the lowest-cost plan (you can adjust the plan later from the Dashboard).

Complete the remaining prompts like region and name with whatever you wish.

Updating the creds

Our app is still using the RDS creds in .env, so we’ll need to update those. Those can easily be grabbed from within the Dashboard UI, but we’ll stick to the CLI for simplicity. Simply run:

manifold export

…and you’ll see the credentials exposed into your terminal session (if you need to output a project, run manifold export --project projectname). We already have an .env already, but for future reference, you can optionally specify an output file like so:

manifold export > .env

What you should see from JawsDB is all the credentials rolled into one URL:

JAWSDB_URL=postgres://$USER:$PASSWORD@$HOST:$PORT/$DATABASE

Pluck apart those values from the URL into .env to swap your app.

Migrating the data

There’s no GUI for exporting your AWS Postgres database, but the standard pg_dump will work just fine. Assuming your RDS instance is publicly accessible, run:

pg_dump $AWS_DATABASE -h $AWS_HOST -U $AWS_USER -f development.dump

You’ll be prompted for your password so it’s not saved in your shell history. To output a development.dump file from AWS. Then simply import into JawsDB:

psql $JAWS_DATABASE < development.dump -h $JAWS_HOST -U $JAWS_USER

You’ll likely see some errors like ERROR: role does not exist because of username differences, but it should succeed nonetheless. You can verify by running psql $JAWS_DATABASE -h $JAWS_HOST -U $JAWS_USER and \dt to show a list of tables. You can follow up with a query to double-check the data made it (e.g.: SELECT * from users;).

Swapping Simple Email (SES) with Mailgun

Migrating our database was about as easy as it gets, but not all service-swapping is quite as rosy. To switch from Mailgun, we will have to modify app code a bit in addition to a simple .env update.

Add Mailgun to your Manifold account, either through running manifold create locally, or via the Dashboard. Their free tier is perfect for testing.

Once you’ve added it, click the Open Mailgun Dashboard button at the top of the screen:

From there, you’ll want to Add Custom Domain:

Follow the instructions that follow for adding Mailgun to your domain, which is necessary to avoid spam filters and whatnot. Back in our app, we’ll swap node-ses with mailgun-js:

yarn remove node-ses
yarn add mailgun-js

Then in our email config, we’ll make a few changes that swap out the SES client with Mailgun’s (you can see the diff on the Pull Request from the sample app). Overall, not too bad! The API, fortunately for us, ended up being similar. We only renamed two env variables—so as to not be confusing later— and had to change message to text in our email call.

Once some test emails are sent, we’re pretty much in business!

Swapping Hosting

Our app was originally hosted on Amazon Elastic Beanstalk, and moved to Zeit Now. I expected to glean some insight from migrating hosts, but came up short—the process was unremarkably quick and painless. The only lesson I learned is so glaringly obvious, it’s almost not even worth saying:

If you use cloud services that work on any host, you can deploy to any host at any time.

“Duh,” you’d say. And you’re not wrong! But it’s not bad advice to keep in mind, either.

💁 Tip: Projects and Teams save a ton of headache

Projects are the best way to associate related resources together, especially if you’re using several in the same application or suite of apps. You can create new projects with:

manifold projects create

Associate resources to that new project by running:

manifold projects add

The biggest advantage to projects, besides organization, is one-click .env file downloads. Clicking either the “download .env” or “Show credentials” buttons will yield all values for all resources in a project. Huge time-saver when it comes to updating access tokens!

🔐 Even more security

If you want to make it even more secure and load secrets from memory, try using manifold run to start your app—you can inject env vars directly from Manifold without any of them living in your file system! The sample app has an example of how to do this in package.json.

👯‍ Team projects

Team projects are even more useful. With team projects, you can invite and uninvite other developers to access shared resources, and pay for it all with one set of billing info. To create a team project (assuming you’ve created a team with manifold team create), first switch to a new team:

manifold switch

And then you can run manifold projects create from that new team context to create a project for that team (currently, you can’t convert an individual project to a team project, but it’s not too bad to move existing resources from an old project to a new one—you don’t have to start from scratch again).

Recap

Still debating how much effort it’d be to migrate cloud services for your app? Here are some good and bad practices that should give some indication:

Quick & easy migrations

1. Environment variables used for all credentials
2. Open-source technology powers most of the app
3. Configurations are all abstracted into a central place

Painful migrations

1. Hard-coded credentials everywhere
2. “Blackboxed” or proprietary systems power most of the app
3. Configurations are written ad-hoc, wherever they’re needed

Migrations may not ever be fun, but with tools like Manifold’s CLI it can come pretty darn close.

The best migration may be none at all, but when the time inevitably comes, Manifold makes it as painless as it possibly can be.

Cloud-jumping: swap hosted services easily with Manifold was originally published in manifoldco on Medium, where people are continuing the conversation by highlighting and responding to this story.

👋 My name is…

💻 My job at Manifold is…

💰 I’m going to donate $200 to…

🌱☀️🍂 ❄️ My favorite season is…

⛵If I had a boat I would name it…

✨ My favorite inspirational quote is…

👩‍💻 🌎 👨‍💻 I work from…

🙌 If I could have a dinner with someone who is alive or dead, I’d have dinner with…

🌎 My favorite place in the world is…

🍦 My favorite dessert is…

🎨 Draw a self-portrait

$ manifold add — human Drew was originally published in manifoldco on Medium, where people are continuing the conversation by highlighting and responding to this story.

Stylable is a CSS preprocessor for modern web development. Although it’s a newcomer to the current CSS-in-JS’ Looney Tunes-style fight cloud, it’s not really CSS-in-JS so much as a thoughtful iteration of the new philosophy of CSS Modules. If you’ve been screaming for all those CSS-in-JS kids to get off your CSS3 lawn, Stylable might be just the old tune that takes you back to the good ol’ days.

Everything is a JavaScript module in 2017 web development. To say CSS has had a tough time keeping up with this shift is an understatement. To name a few problems:

1. CSS is (still) global: JavaScript modules only expose their names via export & import—otherwise everything is isolated. In CSS, every name is global. Of course the simple add-a-CSS-file-anywhere-to-access-it was an intentional design decision of CSS that made it simple to implement. But that simplicity introduces a lot of technical debt at large scale, and so front-end developers responded by inventing invisible rulesets such as SMACSS and BEM. While these are viable solutions, all of these exhaustive naming structures must be rigidly enforced on a team, otherwise it breaks down.
2. CSS (still) doesn’t tree shake: If you wrote it somewhere, it’s being downloaded and inserted. CSS has no clue what styles you are / aren’t using. Better to leave it alone than risk breaking something, right? Welcome to the gigabytes and gigabytes of unused CSS that make up the web.
3. CSS (still) doesn’t understand state: CSS is a brilliant tool for styling state, but it’s never had a built-in method for managing state. CSS can only apply styles based on class names; it can’t add or remove classes itself. For this reason, JavaScript or server-side rendering is required to show state, which means anything generating markup has to know about your CSS class names. Now there are invisible threads running all through your application, and when the CSS class names change, so must all of these external files. There must be a saner way to manage user-facing state that your application actually understands.

Every new styling solution for modern JS frameworks must address these problems. Styled Components, Glamorous, and Aphrodite attempt to solve these problems using JS’s native language solutions to render CSS as it does HTML. But often, this re-imagining of CSS leaves features by the wayside in pursuit of these problems. For example, in most of these, it’s hard to write global styles, hard to add webfonts, hard to nest selectors, hard to use CSS3 animations, and—most dreaded of all—the :hover + child selector declaration (a longstanding problem in CSS-in-JS that’s only been effectively addressed very recently).

Stylable, on the other hand, attacks this problem from the CSS end, and does a pretty good job of preserving CSS while pushing the language forward. There are pros and cons to both approaches, which we’ll cover, but Stylable offers some compelling new solutions that make it a worthwhile addition.

The good

Stylable is 100% CSS, and then some

In case I didn’t say it before, I’ll say it again: with Stylable, you get CSS, and every part of CSS. This seems like a “duh” observation, but this is significant if you’ve ever battled with a CSS-in-JS framework over a lost or “hacky” implementation of a basic CSS feature. If this is all you’re looking for, stop reading here and try it out!

CSS in React has never been simpler

Stylable has a React helper that wraps components, and gives you a hook for styling. Here’s the Header component from Stylable’s create-react-app example:

import React from 'react';
import { properties, stylable } from 'wix-react-tools';
import style from './header.st.css';

…

const Header = stylable(style)(properties((props: HeaderProps) => (
  <header>
    <img src={reactLogo} className="reactLogo" alt="logo" />
    <img src={stylableLogo} className="stylableLogo" alt="logo" />
    <h1 className="title">{props.message}</h1>
  </header>
)));

See the className="reactLogo"? You can string together CSS classes just like the good-old days! Uh-oh—that means reactLogo is global, right? Nope! The final output class is .header1839991338--reactLogo. Not only is it scoped to this component only, but it’s also kept its human-readable name so we can easily debug our style tree if something goes awry.

Adding additional classes is exactly as you’d expect:

<div className="someClass otherClass" />

That’s it—simple, manageable, predictable.

Stylable plays nicely with other systems

Still using wix-react-tools, let’s add a .notInFile class that’s missing from the header.st.css Stylable file (the .st.css file extension connotes a Stylable CSS file):

<div className="fromFile1 fromFile2 notInFile" />

If you expected .notInFile to be namespaced, or if you expected it to be stripped out entirely, you’d be wrong! This is the output markup:

<div class="header1839991338--fromFile1 header1839991338--fromFile2 notInFile"></div>

It didn’t namespace notInFile because it knows it’s not a part of your Stylable file. Not only is it flexible; Stylable plays nicely with other systems, too.

CSS gets brilliant state management ✨

So what about dynamic classes / props like Styled Components has? Getting to props is actually my favorite part of Stylable. For dynamic classes, of course you can use template literals if that’s your jam:

<div className={`defaultClass ${dynamicClass}`} />

But Stylable has something far more powerful built-in: a tool they call custom pseudo-classes. It’s so smart I hope this actually becomes part of the CSS spec. Now you have things like this:

.root {
  -st-states: toggled, loading;
  color: black;
}
.root:loading { color: green; }
.root:toggled { color: red; }
.root:loading:toggled { color: blue; }

One glance at this, and you can tell exactly what every element’s styling should be! No boilerplate if / else operators or ternaries, or wondering if .loading is a state class or a standalone element.

The React side is every bit as clean thanks to the style-state prop helper:

<div style-state={{ loading: false, toggled: true }}>

Stylable uses CSS’s own syntax to encapsulate class names while exposing an API for JS. Your JS doesn’t have to manage CSS classes, and your CSS is completely free from logical if / else operators. Because Pseudo-classes are chainable, every state can be accounted for and styled, with the fallbacks evident as well. And chained classes are always applied with their higher specificity, to boot, no matter what order they appear in. Very clever!

The bad

No nested styles

This is a tough downgrade from Sass and the other libraries: no nesting. Even cssnext has nesting, which allows you to do things like:

.link {
  color: #0f0;
  transition: color 200ms;

  &:hover {
    color: #080;
  }
}

Which is so much more readable and composable. In this regard, Stylable throws you back to the stone-age, where you have to re-declare selectors over and over again for every single block, like some stone-age peasant.

Doesn’t (totally) tree shake

In Stylable, if I have the following:

.unused-class {
  font-family: fantasy;
}

That’s going to make it into production assuming its containing file is imported somewhere, whether or not I end up using that class. Compare that to Styled Components in a separate file:

import styled from 'styled-components';

const UnusedClass = styled.div`
  font-family: fantasy;
`;

export { UnusedClass };

If that UnusedClass wasn’t imported anywhere, or if it was imported but never called, it will be stripped from production. JS still holds the advantage here.

The weird

Magical roots

Consider the following Stylable CSS for one component:

.root img {
  height: 100px;
}

.logo {
  height: 80px;
}

You’d expect .root img to override .logo, right? Class selector + element selector > class selector, right? Wrong! Stylable invisibly prefixes every non-.root. So even though it reads as .logo, it’s actually .root .logo. Even though we’d expect 100px to be the final value, the actual value is 80px.

Once you realize this, it’s a trivial detail, but this magic can be a real head-scratcher if you’re not anticipating it. You can avoid this altogether by trying to never use the .root class, but there are many scenarios where this is unavoidable.

Modifiers using…pseudo-elements?

For as much as I love Stylable’s use of custom pseudo-classes, I’m a bit puzzled as to how they handle component modifiers:

:import {
  -st-from: './video-player.st.css';
  -st-default: VideoPlayer;
}
.mainVideo {
  -st-extends: VideoPlayer; /* define mainVideo as VideoPlayer */
}
.mainVideo::playButton { /* override mainVideo playButton */
  background: green;
  color: purple;
}

The gist here is that you’re creating a new modifier of a base component, VideoPlayer, and overriding its .playButton child class. This implementation is curious not only because of how pseudo-elements are used in CSS, but also because this seems to break single-file dependency. While this file makes it clear it’s depending on VideoPlayer, the same can’t be said for the video-player.st.css file—it’s likely another developer could edit that file unaware it’s silently affecting other files. This is an anti-pattern, especially in the world of JS models.

On the other hand, I do see some potential in this, but perhaps only if you kept it to very, very low-level utility components. Overall, I’m just not sure what to think about this feature yet.

The variables are okay

Importing variables is very JS-like:

:import {
  -st-from: "./colors.css";
  -st-named: black, blue;
}

.root {
  color: value(black);
}

.link {
  color: value(blue);
}

That’s basically the equivalent of writing import { black, blue } from './colors.css';. It becomes a bit tedious (and strange) manually importing/exporting named variables, but overall I respect the design decision behind it. I think this approach is a wash compared to the escaped template literals (color: ${black}) in Styled Components, et al.

So, is Stylable worth using?

There’s a lot to love about Stylable, and it brings a lot of new concepts to the table. In its current state, I think I still prefer Styled Components when it comes to styling in React. I’ve gotten used to composing CSS dynamically using JS, and I personally love the simplicity of having .js files that store all your styling constants like colors, typography, grid, and responsive settings—you never know when JS needs access to these values for animations and transitions.

That said, I do think the current generation of CSS-in-JS isn’t sustainable, at least for CSS. It’s currently a bastardization of many of CSS’ original design decisions, and I believe CSS will evolve and adapt in time. In that regard, I have very high hopes that Stylable will be a viable option and will grow and adapt with CSS. Stylable is very pro-CSS, which I think is the safest bet long-term. So while I may not be hopping on the Stylable bandwagon just yet, I think either a future version of Stylable or something born directly from it will someday be the new standard.

In short:

Stylable is great for:

• Developers that just miss plain-ol’ CSS
• Legacy apps with lots of existing (non-Sass) CSS that are currently being upgraded to Reactlandia
• Developers who want to invest long-term into a CSS system that will be around for years, and aren’t satisfied with the current CSS-in-JS landscape.

Stylable is not so great for:

• Developers that have established a good workflow with Styled Components or similar CSS-in-JS libraries
• Developers that prefer JS to CSS in general (disregarding the fact your animations should all happen in CSS whenever possible)

Stylable: the good, the bad, the weird was originally published in Insightful Software on Medium, where people are continuing the conversation by highlighting and responding to this story.

What’s a “brand?”

Michael Beirut, Principle at Pentagram, spelled it out a few years ago: graphic design criticism is a spectator sport. But I’d argue since that 2013 essay, it’s risen past mere “spectator sport” to the realm of casual dinner conversation. Today, it’s not unusual to overhear a coffee shop conversation with someone talking about their “personal” or “lifestyle” brand on Instagram. And it’s only becoming more embedded in our culture. For the most part, we’re all aware of it, and fine with it.

A brand often starts with a logo. This we all know. It doesn’t have to end there—a brand in its pure form is, after all, an eternal idea or movement—but slapping symbols on everything is a habit we can’t kick. No matter how lofty or eternal your vision is, society still needs that symbol or wordmark to legitimize it. Technology isn’t helping us break our addiction, either. Starting a business? You’d better have a logo. Starting a Facebook group? You need an avatar and header graphic! Made a website? Upload a logo and favicon to get started! Working at a company that still has an ’80s logo? Adapt or die! Rebrand, refresh. Rebrand, refresh.

We fell into this trap with our last Envy logo update from 2013, when we updated an over-stylized logo that dated us. We “refreshed our brand” to feel more relevant. It worked. But when it came time for us to “refresh” again, we didn’t want to do it out of pure habit. We didn’t want to neglect the one central reason you even call it a “brand.” And that’s meaning.

A brand consisting of a logo, and nothing more, is shallow and somewhat pointless. Grant McCracken reminds us of this in an interview with Debbie Millman:

When we create brands, we’re engaged in a process of “manufacturing” and “managing” meaning. … Sometimes I hear designers speaking in generalities such as, “We had to freshen the brand,” or, “We had to make it more dynamic,” and so forth. What I don’t hear designers say is, “We chose this brand, this particular meaning and that particular meaning, and we got rid of that meaning.” We can be much more particular — we must be much more particular — about the meanings that we think matter.

— Grant McCracken in Brand Thinking and Other Noble Pursuits

For most of Envy Labs’ history, we’ve been guilty of prioritizing our clients’ needs above our own. We’re not serial promoters; we neglect our “brand” almost by default. Enough time had passed since our last company orienteering, where we needed a reminder of what we stand for, and the big picture of what we’re accomplishing.

To rebrand is to revisit your values—the raisons d’être—organize them, and invite outsiders into what you’re setting out to accomplish. A brand is more than a mere company or a part of capitalism. A true brand is an idea or movement, something much grander and more important than money. It can take the form of a company, but it doesn’t have to. A brand is merely an idea that people can agree or disagree with.

We needed to rediscover our meaning.

Started from the bottom, now we’re…where, exactly?

The name Envy Labs came about in 2008 when Gregg Pollack started a full-time web agency with three other developers after his popular Rails Envy podcast/blogging venture with Jason Seifer. Rails Envy was a tongue-in-cheek reference to non-Rails developers’ being envious of Rails developers’ amazing experience building web software (which, in 2007, was mostly true based on what the rest of the landscape looked like).

Touching on that same vein, Gregg came up with the name Envy Labs because it sought to create the same culture that so many other agencies had achieved. Beautiful, downtown office spaces. Remote work. Unlimited vacation. Ridiculous benefits. Incredible company culture. Gregg wanted to start a company that took care of people well—one that others were envious of.

In a mere four-and-some-change short years, Envy Labs had grown, and now had a successful bootstrapped product on its hands: Code School. The combined number of employees were somewhere in the 40–50 range, and the company was able to provide some of the best salary, benefits, culture, and growth opportunities for a tech company in the state of Florida. It attracted some of the most passionate, driven, fun-loving individuals you could hope to find.

Everything was great. Magical, even.

But how far can “be better than the rest” take you? Where do you go from there once you’ve achieved the success you’re going for?

Rather than take some time out for self-reflection, we pushed on, continuing to focus on making our company culture bigger and better. Often to the neglect of what we were achieving beyond our four walls.

Where do we go from here?

In early 2017, the design team—Nick Walsh, John Wilson, Ayana Campbell Smith, and I—sat down to assess our current company vision. We had officially parted ways with Code School, cemented by the sale in Jan 2015. We left the shared office in May 2016, returning to our numbers to sub-twenty. In many ways, 2016 closed a seminal chapter in Envy’s history, giving way to a brand new one. What were we accomplishing? What were we targeting? If our company was a vessel, where were we sailing it?

The design team began by finding our brand positioning—our place in the (economic) universe. Where did we fit in? Did our name reflect that? Over the course of months, we explored evocative names that captured the spirit of what we were seeking after.

We needed to communicate several things:

1. We liked solving impossible problems.
2. We moved fast, and could outpace many larger agencies in building scalable web apps in a matter of weeks.
3. We were small and nimble, able to spin up or down quickly, and able to fit into nearly any existing corporate structure.

For the better part of our exploration, we felt we had outgrown the word “Envy.” We felt that word stood for something that was no longer part of who we were, or where we wanted to go.

After all, how can you build a vision for the future based on what somebody else has?

We explored many potential names, trying each out over the course of weeks. In the office, we even pretended we had already changed our name. Some company names were rejected in less than a day. Other names we really liked, and would have probably changed our name to had we not discovered a few similar trademarks after coming up with the name.

A Return to Form

Months of crumpled paper, erased whiteboards, and -final-final-v3.ai Illustrator documents turned up nothing but dead ends in the search for this new identity.

We were discouraged. After some soul-searching, we still couldn’t find the right words that captured who we needed to be. Unsure where to sail toward, we returned to our roots—that initial spark—that exploded into the vibrant culture and history we wanted to preserve.

But more than that: we couldn’t forge ahead marching to the beat of our own drum. We achieved success because we had solved others’ problems, and would continue to do so as long as the company existed. We didn’t exist without others. So, we took one step back in order to take two steps forward:

We returned to our old name—one with history, recognition, and a dash of fun. Us trying to get away from being “others-focused” (envy) only drew us right back in at the end.

Speaking to the pure design of it, our new lockup is a union of three shapes forming an abstract “e” that represent the developers, production team, and designers that make everything happen (can you guess which of the shapes represents the special snowflake designers?). Our typeface is a grotesque with notable geometric properties, evoking the forms and philosophies of mid-century modernism. We’re a modernist company, after all — we believe in the truth of forms, reduction of waste, and simplicity of execution. And of course, having “envy” in our name mandates we use some hue of green as a brand color; as designers we don’t waste any good metaphors that fall into our laps.

In terms of our brand it’s a mere symbol — a vehicle for a message. And that message is: we don’t exist without clients and their existing problems. We don’t exist without others. As soon as the world runs out of problems to solve, Envy Labs closes its doors (and that would be amazing!).

This might not be an independent identity—it can’t exist apart from other people. But for where Envy Labs is now, it’s perfect. And for the foreseeable future, we don’t want to imagine our purpose divorced from real-world problems.

Breaking out of our bubble

With this new identity, we aim to be deeply-rooted in culture. To take another page from Grant McCracken’s metaphorical book:

We pay dearly if we don’t respond to culture, and we pay dearly when we don’t respond to change.

A reason why we lost sight of our purpose, for a short time, was we were so enamored with ourselves. We had a good thing going. But the world doesn’t revolve around us, and Envy Labs doesn’t exist without real problems to solve. And we’re aiming to fix that by breaking out of our bubbles.

Along with this rebrand, we’ve also invested time inventorying what matters most to us. That’s a separate conversation entirely, but here’s a short list of things we care about deeply right now:

• Healthcare
• Education
• Orlando
• Open source software

We’re not content to let the world—and culture—pass us by, and we’re going to be spending a lot less time focusing on what we are / are not, and instead spend more time focusing on others, and how we can or can not help them. We’ll help the ones we can, and do the best to refer the ones we can’t to the right place.

Envy Labs’ brand and meaning is solving others’ problems.

So, how can we help you?

Envy Labs’ 2017 rebrand: discovering meaning was originally published in Insightful Software on Medium, where people are continuing the conversation by highlighting and responding to this story.

I grew up in a household with lots of misdirected anger, mostly from my dad. He was generally an angry person. Frequently, that anger would be directed at me, usually in the form of abusive language. Sometimes it was yelling. Sometimes it was undue punishment. Sometimes anger came in a form it took me years to identify: absence (both emotional absence—distracting himself with TV, etc.—and physical absence—leaving the house and spending the whole day with himself).

Is anger just a blanket statement for “things this person does that I don’t like?” Of course not. In fact, anger—expressed correctly—can be the most powerful force for good (we’ll get to that in a second). But all too often, our experiences with anger are negative. Because it is volatile, and at times, uncontrollable. But again, it bears repeating: anger can be a powerful force for good when expressed correctly.

What is anger?

If you asked most people to define anger, you’d get a lot a lot of answers like “the opposite of love.” A typical misunderstanding of anger as it relates to emotions like apathy and affection probably looks something like this graph. On one end, you have “anger” (bad). On the other end, you have “affection” or “love” (good). And somewhere in the middle, you have neutral—not caring. When you try and map this common misconception to good/bad/neutral, you wind up with a spectrum like this:

If we’re honest, a lot of us incorrectly think of anger like this. We all know dramatic people that can be elated one moment, furious the next, and content the next. Or how quickly do our feelings toward a fictional character go from affection to anger when it’s revealed they were a traitor? In those rapid, sudden mood shifts, are we to believe there was somehow an apathetic phase in there we just rushed past? When affection can turn so quickly to hate, and back again, is there a split second of complete apathy in between?

Unlikely.

Apathy might be misplaced, then. What happens if we bring two other concepts into the mix: amount of caring, and expectations?

Affection and anger are both deeply-caring emotions. That’s why they can flip at the drop of a hat. On the extreme opposite end is apathy: simply not caring either way. What completes the picture for us are expectations: our wishes, desires, and opinions on how reality should be, and whether or not that is actually what’s transpiring.

We get angry at injustice. We get angry at people we love when they hurt themselves. We get angry for people we love when someone harms them. We get angry at ourselves when we fail. In all of those scenarios, anger is at the intersection of caring and unmet expectations. Something happened that we wished did not, and we cared deeply about it.

No one gets angry over something they don’t care about.

Wait — aren’t you confusing “anger” and “disappointment?”

Disappointment, like anger in this graph, indeed comes from failed expectations about something we care about. But I would postulate the difference between the two is acceptance. We’re disappointed by things we wish were different but accept them as they are. We’re angry about things we expected to happen differently, and we can’t accept the outcome.

A force for good, you say?

What took me a long time to realize—and it came from having conversations with my dad as an adult—was that he had a lot of failed expectations. For his life, for his marriage. His picture of what the world should be was very different than what it actually was. However, he did little to change it, other than find ways to numb his pain.

Revisiting the statement “anger can be a force for good when expressed correctly,” we can see that all the great social reforms of history came from a place of anger. Anger that the world isn’t as it should be. Anger over evil prospering. Anger over the downtrodden that should be lifted up. Great men and women that called for change in history cared deeply, and were not happy with the state of things.

They were angry.

However, that angry energy was often directed into fruitful things: protests, rallies, petitions, speaking engagements, etc. Social reform came from the pain of unmet expectations, but they did something about it, rather than beat their fists and lash out at anything and anyone possible.

Looking back, many of the people in my life—myself included—cared deeply for something and had expectations broken, but the response usually resulted in no change other than hurting everyone within range. The conditions were there for powerful change. In my dad’s case, I think it was largely self-directed anger at his own failed expectations for his life. But rather than use that as an energy to change himself, or help others not make the same mistakes he did, he chose to lash out and hurt those that didn’t deserve it.

Few people would describe me as “angry;” In person I’m generally deadpan, even-keel, and don’t raise my voice. But I get angry very frequently. I’m not intimidating. I don’t rage. I’m not seething on the inside. But several times throughout the week (my wife can attest to this), I get pretty angry about something about the world that isn’t right. While I’m nothing close to a social reformer, people would describe me as productive and driven. What I really seek is change within my household and my community, and that takes many forms.

Realizing when we’re upset about some part of reality—whether that’s the world around us, or something inside—the only response that benefits anybody is making steps to change it. It’s OK if you do this while angry. So long as you’re kind and dignifying (that’s the important part!) to everyone around you, anger can be the catalyst for immense good in this world.

Get angry. So you don’t have to be anymore.

Too lazy to compile a list of different opinions on the debate? Don’t worry! I’ve compiled them for you:

Yes

1. John Maeda: if you want to survive in design, you better learn to code
2. Designers Code Differently
3. Design ♡ Code
4. Design is Lifelong Learning
5. Why designers should not code…anymore
6. I’m a designer. Should I code?
7. Should designers just put something out and expect the engineers to make it work?
8. Designers should write content, code, study business & other things people say
9. Designers Who Code For Real Learn For Real
10. If you’re not a Software Designer who codes, here’s why you should start now
11. Should Designers Code?
12. Should Designers Code?
13. Why designers should learn to code—or at least consider it
14. Should UX/UI Designers Code? Finding a Balance Between Yes and No (editor’s note: counting it as a “yes” because it advocates understanding code)

No

1. Should designers code… or should developers design?
2. Should designers code?
3. “Should Designers Code?” — The final Word (editor’s note: it wasn’t)
4. The Intersection
5. Product designers should say f*ck you to being forced to code
6. Designers shouldn’t code. They should study business.
7. FAQ: Do UX Designers Need to Know Programming and Computer Science?
8. Should Designers Code?
9. Why designers should stop coding (written by a 🦄)

I smartly avoid the question don’t you feel silly now

1. Breaking the “Should Designers Code” Deadlock
2. Just Say No to 🦄s
3. Death to the ‘designers should code’ argument
4. Should designers learn to code?
5. Should designers code?
6. Better questions to ask than “should designers ‘code’?” (editor’s note: such as “why is ‘code’ in quotes?”?)
7. Should Designers Code?

IDK give us money

1. Should designers code? The definitive answer.
2. Should Designers Code?

You should learn Shaolin Kung Fu

1. Should Designers Learn Code? — a Martial Artist’s Approach

Hopefully this has cleared things up and settled the debate once and for all: designers should learn Shaolin Kung Fu.

All the answers to the “Should designers code?” question was originally published in Insightful Software on Medium, where people are continuing the conversation by highlighting and responding to this story.

This year, a major focus for me has been to grow as a designer, and I’m writing this to myself as much as to other designers I’ve interacted with and mentored.

Many of us within the design community (especially younger designers) have fooled ourselves into thinking we’re growing when we’re not. Though this behavior manifests itself in myriad ways, it’s most clearly manifested itself on Dribbble, the popular designer showcase. And to be clear, it’s not Dribbble the platform that’s the problem, nor do I think its founders intended this. I love Dribbble, and think it’s a net gain for the design community at large. But for all of us it’s easy to get sucked into that false measure of quantitative growth Dribbble provides with likes and comments. We’ll this bad pattern of thinking “painkiller thinking.”

On Painkillers

The painkiller–vitamin metaphor has made the rounds in business circles, but I heard it the first time watching an episode of Apple’s app-themed game show Planet of the Apps (I know, I know—the show is super cheesy, but it has its moments). On one episode, one of the VC investors had the following to say about a product he was skeptical of:

A vitamin is something you should be doing every day, and it has a diffused benefit over time. In our experience as Venture Capitalists, we’ve found it’s much, much harder for products that feel like vitamins to reach scale and be successful than products which are more like painkillers: where the user is grasping for any solution, right away, because they have a burning, pressing headache of some sort.

Someone pitched a “vitamin” idea when he was gunning for a “painkiller” idea. Painkillers sell. Quick, effortless results sell. People want their problem solved instantly, and money follows desires.

Dribbble, for most people, is a five-minute experience. Pop it open, like some shots, close it. Maybe if you’re doing research, you’ll even spend fifteen minutes collecting shots into a bucket. But you can only use Dribbble for reference when you’re creating visuals solely for 30-and-unders that pull from popular design styles of the last few years. Oh, and make sure you steer clear of all the useless designs that can exist nowhere else other than Dribbble itself.

Essentially, relying on Dribbble is the same as eating Cheetos™ instead of veggies. Great as a snack; horrible for three meals a day. It makes the bad hungry feel go away, but doesn’t leave you with many nutrients.

Dribbble is designed to give you that instant relief: it tricks you into thinking you’re growing and becoming a better designer in five minutes. But really all it did was stave your appetite for growth.

If you’re carefully monitoring your own thoughts at this point, you’re probably thinking “Yeah, yeah, OK. I get it. Dribbble is bad. What’s ‘good’ so I can agree or disagree with you and move on?”

If you’re thinking this way, you’re still looking for that painkiller—that easy, quick solution. Stop seeking out painkillers, switch to everyday vitamins, and you’ll see great results in six-to-twelve months.

On Vitamins

So what does this “everyday” behavior look like? One example that came to my mind is Tobias Frere-Jones, designer of the Gotham typeface as well as many others you’ve probably used before (Whitney, Archer, Interstate…).

In 2015, Tobias gave a talk on bank note design. More specifically, the hundreds of minute security details printers hid in their banknotes to detect counterfeits (it goes way deeper than the “hold up to the light” trick):

Behind that talk was years and years of research, and along the way, Tobias collected sample after sample after sample, initially to scratch a personal itch. His collection isn’t available online other than the samples he’s scanned for his blog, and I’m not sure just how large it is, but judging from him describing himself as a “pack rat,” and the obscene amount of niche references he drops on a regular basis, I’m going to guess a lot.

I want you to imagine the work it takes to build your own personal archive of design samples that have never been scanned and put online. Imagine traveling around the country to build your collection. Imagine the hours of digging through libraries’ flat files. Calling up historians on the phone. Calling someone after calling someone. Would you still do it if you got no immediate feedback? What if you couldn’t make a Dribbble shot, or viral tweet after every sample you found?

For Tobias, at least, the possibility of not hoarding all this ephemera wouldn’t even cross his mind. Because he’s not motivated by what will yield instant gratification, he’s seeking after what will yield slow, long-term growth. And he isn’t the only one building his own collection—this is a shared secret among many great designers, from Herb Lubalin and Paula Scher, to Tad Carpenter, Allan Peters, and Aaron Draplin—all have their own personal collections they’ve amassed, in secret, to no other end than their personal growth.

I am surrounded by tons and tons of things. And I’ve had to go dig it up in the deadest, weirdest places. Places where you have to talk to people, and other sketchy stuff like that.

— Aaron Draplin

For all these designers, they know the true value in digging deep for obscure references yields the strongest, most informed work they can possibly produce. They don’t limit themselves to simply rehashing other designers and what’s popular; they pull from anything they can get their hands on. There’s a chasm of difference between the two.

That daily investment for long-term growth doesn’t always have to take the form of amassing a personal collection (though that never hurts)! Reading, studying, going to conferences, and finding a mentor yield the same effect so long as you are investing quality time into something, daily.

Next Steps: Experiment, fail. Repeat.

If you’re already doing most of these things, then this article wasn’t written for you. But if you’re lured by the temptation of measuring your growth with likes, you’re looking for painkillers to ease the pain of growth. Dribbble is like a cookie: a wonderful snack but awful as your only sustenance. Imagine this is your design mom talking: eat some veggies for once, and quit eating those pink heart cookies three meals a day.

So what does that look like? Here are some starting suggestions:

• Reading Meggs’ History of Graphic Design. Yes it’s $60, and yes, it’ll be the best $60 you ever spent. How can you justify what you’re doing in 20XX if you have no clue what led up until now?
• Reading books from your design heroes. Thoughts on Design by Paul Rand. Make it Bigger by Paula Scher. Things I Have Learned in My Life So Far by Stefan Sagmeister.
• Learning. To. Draw.
• Making a spreadsheet of every typeface from independent foundries (I believe what you heard was “a lot of typefaces.” I said “every typeface from independent foundries”), like Indra Kupferschmidt, a professional typographer, does. Pull from Typographica, Fonts In Use, and my personal foundry shortlist, if you don’t know where to start.
• Collecting items from archive sites like Archive.org and Fonts In Use. Both are ephemera goldmines from everything from ’80s imagery to mid-century car manuals (hint: you can use Archive.org’s advanced search to narrow by date, and on Fonts In Use you can search for “1980s,” etc.).
• Study film, game design, or data visualization.

This should open the pathway to something like Tobias Frere-Jones’ bank notes collecting habit mentioned earlier. Start your own habit! The very thing you might need most for your personal growth looking is probably lurking in some place nobody could have ever pointed you to (not even a Medium article)—some place deep, and dark, and remote; a place only aimless wandering could have reached. Somewhere “likes” can never reach you.

To get to that place involves failure. Daily failure. But it’s when you’re most uncertain about your current experiment that you find exactly where you needed to be all along.

Failure is a big part of success. … You’re gonna run a lot of stuff, and it’s going to go nowhere. And you should be happy about that. If you’re doing that, you’re doing it right. If you’re not failing all the time, you’re not creating a situation where you can get super lucky. … You don’t want to be making mediocre stuff. That’s not why anybody wants to get into this.

— Ira Glass

Dribbble is a painkiller, not a vitamin was originally published in Insightful Software on Medium, where people are continuing the conversation by highlighting and responding to this story.