I've spent a decade honing my engineering and design workflows, but never really bothered to share all the tools that make my days more productive and enjoyable.

My main criteria when evaluating the tools I use each day are:

• Do they enable me to work close to as fast as my brain can think?
• Do they make the experience of working a joyful and rich experience?

Here's a list of all the tools I use on a near-daily basis, and why they make me a better craftsperson:

Quicksilver

Quicksilver is the original Mac app launcher. Although it sometimes feels dated next to Spotlight, it's scriptable and lets you perform actions on your searches. Although if I'm being honest, I usually just use it to launch apps rapid-fire.

If you're still hunting for apps in your Applications folder by hand, definitely download Quicksilver and work it into your workflow. You'll be surprised you could live without it before.

Get Quicksilver

Divvy

Ever get frustrated trying to optimize your screen real estate in OS X? I like to work with a terminal on one half of the screen and a browser on the other. Trying to size the windows in this way using the mouse cursor is a bad time.

Divvy is a window management tool for OS X. It allows you to quickly size windows into exact screen portions.

I have mine configured for three quick keyboard shortcuts to allow me to make the currently-focused window occupy the left half, right half, or entirety of the screen:

Get Divvy

Focus

I used to have a tic where I'd open a new browser tab, type "f", and press Return to launch Facebook. Then I quit Facebook, and the tic shifted to typing "r" and launching Reddit. Ever been there?

I've surveyed a bunch of Mac content filter apps for keeping me focused when I'm working, and Focus is by far the best one.

It has support for blacklist- and whitelist-based filtering, timers, schedules, and a special "Hardcore Mode" which doesn't let you turn it off in the middle of a timer or schedule.

When you visit a blocked site, you'll be forwarded to a page with an inspirational quote:

Get Focus

Pomodoro One

Having trouble staying on task for hours at a time?

What if you tried staying on task for just 25 minutes? Think you could do that?

Whenever I'm feeling distracted, I use the Pomodoro Technique to keep me going. The gist of it: Work for 25 minutes and then take a break for 5. Repeat several times.

Pomodoro One is a minimalist Pomodoro timer I use when I'm in crunch mode. It keeps me focused for hours because I know a break is just around the corner.

Get Pomodoro One

OmniFocus

I've tried so many personal task management tools and OmniFocus is the best one there is, hands down.

Built by disciples of David Allen's Getting Things Done methodology, OmniFocus keeps all your tasks organized by project and context.

My favorite feature is the Inbox, where new tasks live until you get a chance to sort through them. It has integration with iOS's "Send to" feature, so I'm always able to forward articles and ideas directly to my OmniFocus for later reading without losing a beat.

Notational Velocity

OmniFocus is amazing for tracking tasks, but often I just need to archive bits of information for retrieval. This might be account numbers, usernames, license keys, or lists of books I want to read.

Mailplane

I've tried so many freaking Mac mail apps. All of them have a common problem: They're slow when put under real-world load.

I delete a ton of email, just like I'm sure you do. I found that every desktop mail app I used would lag when I was doing rapid-fire deletion.

Plus I really wanted an interface with Vim-like keyboard shortcuts.

The GMail interface is fast and had keyboard shortcuts. But I like to isolate myself from email during the day because it's almost as much of a productivity suck as Slack.

That's when I found Mailplane. It's a Mac app that wraps a nice desktop interface around GMail. Although it doesn't satisfy my dream of having a single inbox for all of my three email accounts, it does a great job of showing me my email, letting me batch through all my messages to get to zero, and getting the hell out of there.

Get Mailplane

Vim

Vim is the best text editor on the face of the earth.

And that will be the most hotly-contested statement on the face of the earth.

But seriously: Before you learn them Vim keybindings seem archaic and confusing. But they're built for speed. And once they're part of your muscle memory, they'll come as natural to you as the alphabet.

As I said before, one of my criteria for choosing my tools is if they get me closer to being able to work as fast as I think.

Here are some of my favorite Vim plugins that enhance my workflow:

• vim-pencil: Rethinking Vim as a tool for writing. I'm using it to write this!
• ctrlp.vim: Full path fuzzy finder for Vim. It's like the Quicksilver launcher for your text files.
• NERD Tree: A file tree explorer.

Vim Homepage

Tmux

Tmux is like Divvy (above) for your terminal. Split a terminal window in half without using the mouse, deploy new shells, and keep your entire session running even if you close your terminal window. Here's me editing this article using it (and Vim) right now:

Probably the biggest reason I use Tmux is because it enables IDE-like functionality without leaving the terminal. For those of you using Emacs, you might not find a use for Tmux in your toolbox. But being that Vim is a text editor first and foremost means you have to look elsewhere to do things like display an editor and shell in the same screen.

Get Tmux

Tmuxinator

Tmuxinator enhances the Tmux experience by giving you the ability to fully configure Tmux workspaces and launch them with a single command.

Imagine you're working on three different web projects. Each of them has a server process, a file you're editing, and maybe a test runner. Instead of launching all of these as separate terminal windows every time you want to switch projects, Tmuxinator allows you to configure Tmux workspace templates so that switching projects is as simple as typing mux my-project.

Plus, in case you ever accidentally close a terminal window like I do all the time, your session is saved right where you left off. Just use Tmuxinator to re-launch your session and everything will be right where you left it.

Get Tmuxinator

Powerline

Powerline is a nifty little status line plugin for Vim, Tmux, ZSH, and others. It displays things like the current time, CPU utilization, and more.

Get Powerline

Middleman

If you're not using a static site generator for your blog, I implore you to consider it! It reduces your maintenance overhead since you don't need to bother with configuring and maintaining a server or database.

And with services like Disqus and my own Formbot, it's hardly necessary to run a server application for most blogs.

There are plenty of static site generators and they all have their pros and cons.

Being a Ruby enthusiast, I settled on Middleman. It has enough features, including a robust blog plugin.

Plus it has support for external pipelining, which I use to generate image thumbnails in Gulp.

Try using Middleman

Amazon S3 & CloudFront

I've used S3 to host my static sites for years. Despite its learning curve, S3 offers unlimited storage and bandwidth at a relatively low cost.

I use the gem middleman-s3_sync to sync my Middleman sites to S3.

Hosting a Static Website on Amazon Web Services

2014 MacBook Pro

In my opinion, the 2014 and 2015 Retina MacBook Pros are the best laptops Apple ever made.

They balance fast speeds, elegant design, and ports (yes, there are ports!) for most applications.

I think it's the most refined notebook computer in history. And I'm sad Apple decided to veer off that path with gimmicks like the Touch Bar.

So for now, I'm staying in 2014.

Buy a MacBook Pro from 2015 before they run out!

iPhone 7 Plus with Defender Case

This is the best smartphone I've ever used. Even though in its Otterbox Defender case it's as big as a 1980's carphone, the iPhone 7 Plus feels like putting a computer in your pocket.

Visit the iPhone 7 site

WASD Keyboard with PBT keycaps

I didn't believe the hype at first.

An entire subreddit devoted to mechanical keyboards?!

Spurred by some pretty brutal wrist pain, I sought relief through new hardware. I looked at Amazon review after Amazon review and people were recommending mechanical keyboards.

I settled on the WASD 87-key keyboard. The Wirecutter agrees.

A $150 keyboard?!

Yes, and I spent $100 on custom keycaps. It's not for everyone. But I can tell you my fingers are happy all day long pecking away on this gorgeous keyboard. And like a good mattress, a good keyboard returns on investment over years of constant use.

Build a custom WASD keyboard

It's my ten-year anniversary of working remotely. That's a decade of coding at home in my underpants.

In that time, remote work has gone from being a fringe idea to being a mainstream industry and lifestyle.

Best practices for remote work are emerging, but they're far from codified. These are the things I do every day to make sure my projects run smoothly. They've made my teams happy and my clients happy.

1. Use (and learn!) a project management tool

It all comes down to threading. Every single time I've used email or chat to clarify requirements, it started a death spriral of scrolling up in the chat log to find the thing I said last week or last month. When you keep everything in context, it's a lot easier to track everything.

And keep it a simple tool. Just use something that has support for making comments in separate todos that you can mark done when they're done. Forget complicated velocity tracking and projections. They're going to be wrong anyway.

2. Invite the developers to every planning call

An agency I used to work with would exclude me from scoping and discovery discussions with their client. Their creative director would meet with the client, then relay the client's vision back to me.

Because of this, there were constantly questions left unanswered at the end of our planning sessions, since I tended to ask specific questions the creative director couldn't answer.

So he went to the client to ask them for answers.

And then we'd meet again. And the cycle would continue.

It's powerful to have constant contact with stakeholders. Introduce the team to your client and foster their relationship. When I do, I find the project ends up running itself.

3. Invite the client to every planning call

Building software is an amazing adventure because we get to work on projects in all sorts of industries! I've worked in fashion, pharmaceuticals, government, social media, and energy engineering, just to name a few.

Because of this, we're at the mercy of our clients to really know what they need built.

The why is critical. Make your client the focal point of your sprint planning.

4. Batch and limit conference calls

Meetings and conference calls are the only way to brainstorm and discover new features. They're also the only way to plan a development sprint.

But they're expensive. They demand the full attention of your entire team. If you have a two hour meeting with your four team members, you've lost a full workday's worth of work to that meeting.

I do my darndest to limit mandatory meetings and conference calls to under 10% of my total work hours, and batching that time all at once. The planning has to get done, but getting it done all at once means you're free to create and produce the other 90% of the time without interruption.

5. Make every task actionable

Semantics are important.

If you need to build the new marketing site and you add a task with the caption "Build new marketing site", you're going to spin wheels trying to figure out how to get it done.

But if you identify the pain points within that monumental task and sketch them out in separate tasks, you can delegate and accomplish each of them separately.

So maybe you write "Survey CMS's for new marketing site" and "Pick CMS for new marketing site" and "Deploy CMS".

And then you break down each of those tasks.

And then if it's necessary, break those down.

Suddenly, everything is in view and your team can execute.

6. Refine incomplete tasks

If there's a task that's done except for a tiny edge case, add a new task to cover the edge case, call the original one done, and make a note of it in the old task.

Now you're razor-focused on the edge case. And now your team can better assess the sprint progress without digging into every single task ticket.

7. Peer review every commit

I used to resent the process of mandatory peer review. But after having been humbled by being called out on my bullshit a few times, I can attest to the value of knowing someone else's eyes have grazed my work before it goes to production.

8. Don't use email or Slack to delegate tasks

If there's work to be done and you want to ask someone else to do it, open a ticket in your project management tool and assign them.

Don't explain it in Slack.

Don't send them an email.

A project management tool is designed to track and manage project requirements and progress. Email and Slack are fantastic platforms for informal communication, but if it winds up in the product, make sure it has a ticket.

See #1.

9. Close email and Slack most of the day

This is my superhero hack. And it's hard, because we're conditioned to be responsive and always-on.

But the truth is, the world won't end if you disconnect and focus on one thing for a few hours. I have to tell myself that every time I do.

Slack and email have their place, but it's not in the middle of your focused creative work.

I limit my Slack online time to an hour each morning, and I check my email twice daily. Sometimes I break these rules, but I think they're worth aiming for.

Read Cal Newport's book Deep Work and watch Merlin Mann's Inbox Zero talk for more on this.

Where did all my hair go?!

I started programming when I was 6. I had a full head of hair.

Now I'm 31. And all my hair is gone.

In tech circles, 31 feels old. You 40-year-olds might scoff at that notion, but since turning 30 I've felt a distinct shift in the way I make decisions. I'm less inclined to dream big and more inclined to play it safe. That's not to say I don't still dream big, but I examine caveats with more scrutiny than I did when I was 21.

I'm not as easily manipulated into work I don't enjoy

When I was 21, I'd jump at the opportunity to build new things, even if it meant compromising my values or sacrificing all my time. At 21 I had a desire to prove myself and my worth. That, and I don't think I possessed the resilience to stand my ground.

Now I vet projects with great scrutiny before committing. I want to work on projects that add great value to the lives of others and to work with people who value their time as much as mine.

I'm not sure I would have even uttered such sentiments ten years ago. I was afraid of being cast aside---of being seen as elitist or unappreciative. But now I realize being discerning and being grateful aren't mutually exclusive.

My aims lie not in achieving an "exit", but in doing great work

I've seen a few of my friends and colleagues "make it big."

I think it's amazing when someone finds their way to the pot of gold. And if I someday have mine, I'll feel blessed for it.

But that's not what all of this is about.

We're craftspeople. We thrive in the creative journey. To create is to leave a legacy bigger than yourself.

No amount of money can ever do that. Fame cannot do that.

Ten years has shown me my happiness comes not from cashing out but from pitching in.

Experience is an invaluable asset

When I was 21, I said "yes" to just about everything.

Can you build this app for me? Yes!

Do you want to take on another project? Yes!

Can we get this done by next week? Yes!

At 31, I know the naivety of that sort of indiscriminate head-nodding. Now my greatest asset isn't my willingness to say "yes" all the time, but my ability to know when to say "no."

I worry about different things

I don't worry about whether I'll make rent next month, but I do worry about whether I'll have work next year. That is, I've learned how to manage my resources but am fearful of being made redundant.

But I'm choosing to be an optimist in that regard. Continuing to learn and grow and connect has never done me wrong. And to witness the arc of technological progress over the course of the past decade gives me hope that tomorrow's digital products will be richer and more immersive than ever before. I want to be a part of that. I will be a part of that.

A thought occurred to me today as I was knee-deep in a Material UI codebase: For a lot of MVP's, hiring a visual designer is largely irrelevant now.

Bootstrap popularized the idea of prefabbed component sets, but using it relies heavily on a soup of CSS classes ugly HTML. Because of this, most Bootstrap codebases I've worked on turn into a confusing mess of CSS overrides. Gross.

React components eliminate that entropy. Instead of shipping a framework consisting of complex markup that only works when used a certain way, frameworks like Material UI are able to deliver visually challenged developers a framework for developing pleasant-looking interfaces with ease.

Obviously, great products require forward thinking visual design direction and the aid of a dedicated designer---especially in the consumer space. And someone needs to direct the user's experience regardless of the interface aesthetic.

But for delivering rapid value, interface componentization means we're able to develop fully-working, beautiful prototypes without full mockups.

The way I see it, this trend will continue. Component sets will mature, React will be replaced by another more powerful component-based library, and new methods for rapid UI prototyping will emerge.

You could say I've been throwing tons of crap at the wall lately. I'm not sure how much of it is sticking. Have you been there? You know, when you keep doing, doing, doing without really knowing why you're doing it or where you're heading? Yeah. That's where I've been for the past month.

I made it a 2017 resolution to start writing again. I wasn't sure exactly why; maybe I just wanted a creative outlet that I controlled. I'm grateful for my client relationships and the fact I get paid to be creative, but fulfilling someone else's dream doesn't feed your soul like making your own thing.

And so I've been writing. I've written about hiring, building products, business, and more. I've also been coding. I built a creative community page for Eugene, Oregon and a Slack integration for HTML forms.

But most of this has felt like I was flailing my creative elephant trunk and knocking everything over in the process.

And I realized something today: I don't have a mission.

My mission was "write more." My mission was "build things." And so I wrote more. And I built things. But I wasn't doing it with an ethos behind me. I didn't have a target at which I was aiming.

Today, I did a few things to help me focus.

For awhile now, I've tried to maintain both a personal site, a business site, and an arts site. While I hope to someday return to producing art and music in a more full-time capacity, there aren't enough hours in the day to do everything. I'm shutting down Guilded and moving everything to one place at teejayvanslyke.com.

I've also drafted a mission statement that I want to carry with me through my career. It reminds me of why I work so hard every single day: To design and build digital products that improve people's lives:

I design & build timeless & elegant digital products.

I've used the word timeless in the past to describe the epitome of what I strive for in my product work. Software is inherently ephemeral, but I do think there's value in producing tools which provide value for as long as possible.

I'm also foregoing using the word software to refer to what it is I do any longer. From now on, I'm eager for my role to be in designing and engineering digital products. I think the distinction is massive.

Too often we expect instant results.

It's not that we consciously expect things to move quickly and work out the first time, but our brains are wired to race to the finish line without enjoying the view along the way.

I've built so many failed products.

Once I built a custom printed t-shirt site. Another time I built a note tool to compete with Evernote. Yeah, that was going to take off. And I even spent months building an online marketplace site to compete with Craigslist.

All of these are now defunct. Why? Because I wasn't in it for the experience. I only ever wanted the cashout.

I'm writing this as much to remind myself as to inspire you: The only way to succeed is to be fulfilled by the journey toward success. To create something of value to someone else without expectation that you'll ever receive anything in return.

Instead of chasing the pot of gold, appreciate the fact you're sitting on a rainbow.

The Internet has the potential to connect you with people across the globe who need your help to fulfill their dreams. Your help might be offering your insight in a blog post or building a SaaS tool to help them save time, make sales, or connect with others.

It is our contribution---not our payout---which ultimately leads to our satisfaction as developers and entrepreneurs.

I've been finding that out as I've been building Formbot. The slow trickle of new users is discouraging at first, but then I realize how lucky I am to live in a time where I'm able to help others across the globe. Finding new ways to help them is more gratifying than money could ever be. And I'm confident that with that attitude, money will come.

What are some strategies you can use to build your new product without feeling discouraged by the climb ahead?

Strive to help others before yourself

Instead of constantly worrying about monetization strategies, social media outreach, and when you can retire to the beach, focus on producing something that helps other people.

Your product needn't be world-shaking to be world-changing. It could be as simple as automating a workflow that makes you and other people more productive.

You'll smile when you see other people deriving value from what you made. And when they do, they'll be happy to pay you for it.

Give yourself a break

If you're going to build something that other people want to use, it's going to take time. Consistency always wins over short bursts of intensity. Do the work, but then go live life. You'll find that when you return, you'll see things from a renewed perspective.

Just last week I was struggling to figure out what feature to build next. Luckily, I took it upon myself to shift gears and do some writing instead. Then suddenly, a burst of inspiration came all at once yesterday and I shipped a whole new feature all in one day!

Take a break, work on a different project for awhile, and come back. You'll be glad you did.

Smile and enjoy the ride

I need to remind myself of this constantly. As digital creatives, we spend the better part of our lives at the computer. Let's enjoy the time! It's an incredible era to be alive when we're able to produce so much value from the comfort of our homes.

Would you enjoy playing a game you always won, or would it bore you after the second or third round? Failure is critical to learning and growth, but it's also fundamental to our ability to experience success in the first place.

Now let's all go make something great. But first, let's go look out the window. Ooh. A squirrel!

I was at a local tech meetup. A man approached the table. "Is this Tech Tuesday?"

He was seeking a freelance developer who could help him finish development on his mobile app. He'd been through the ringer, having contracted with multiple shops and each time having a terrible experience.

Feeling down and out, he just wanted to find development talent he could trust to deliver on their promises.

I spent the better part of an hour listening to his needs and providing insight into how he might go about finding the right person. And I wanted to ensure he didn't waste any of his precious time and money on the wrong person.

If your background is business, you know how to deal with people better than you know how to deal with technology. What are some ways you can use your interpersonal skills to determine whether a developer is the right fit for your project? How do you weed out the candidates who will end up wreaking havoc?

I'm a developer myself, so I'm a bit naive about it. But here are some things I'd look for if I were in your shoes:

Do they have the heart of a teacher?

Do you believe with your heart and soul that your candidate has your best interest in mind? Is their demeanor more like that of your kindergarten teacher, or a used car salesman?

Software development is a two-way engagement. It's tempting to assume you can hand a developer a pile of requirements, wait six months, and get what you paid for. But in reality, your relationship with them is collaborative. Your understanding of how they build your application will prove valuable to you long after their engagement ends.

Ask them to explain how they would solve one of your core problems. And continue to ask questions until you understand, to the point where you could explain their explanation to someone else. If they're reluctant to engage with you in this way, run. Fast.

Are they willing to challenge your assumptions?

My greatest asset to your business is that I'm happy to tell you when you're probably better off not building the thing you think you need. Often, the software ou think you need to build isn't the most expedient way to your business goals when technical realities smack you in the face.

This doesn't mean you ought to find someone who is lazy or unmotivated! But you want them to push back when you explain your needs, and to justify their concerns.

Numerous times I've told my clients that the feature they thought they needed next probably didn't need to be built yet. Or that there was a way to do it that would better serve their needs for less cost.

Your developer is a running expense to your business. Finding one who treats themselves that way is critical.

Are they an effective communicator?

Building software is 90% communication and 10% code. The end result of poor communication in a software product is a poor product, no matter how awesome your developer's hard skills might be.

If you hire a remote developer, it's critical they have excellent written communication skills. Their work schedule might not overlap with yours to engage in phone calls and chats. And you don't want them to rely on phone calls because then they're burning all your money squawking on the phone instead of building software.

What you're really looking for is someone who can effectively engage you through your project management software. Someone who can answer your questions thoroughly, follow up regularly, and ask questions consistently.

When you're getting to know your candidate, email them with a question about a specific aspect of your project. Get a feel for how they engage in an asynchronous (i.e., not realtime, like a phone call or chat) environment.

On one extreme, you might find their responses thoughtless and overly brief. They might not satisfy your need for clear answers.

On the other hand, they might be too verbose, explaining things that needn't be explained and ultimately confusing you.

Give them the benefit of the doubt, but ask yourself whether their manner of written communication empowers you to make effective decisions about your product. Did your test exchange leave you feeling more confident, or more confused? How would you feel if you were relying on them to put out a fire in your business? Would you have faith in their execution?

Ask them to explain a time they failed. Then ask how they resolved it.

What is defeat? Nothing but education. Nothing but the first step to something better.

— Wendell Phillips

Every developer (myself included—oh boy myself included) has failed at some point in their career. We've botched a client deadline. We've built the wrong feature. We've deployed buggy code to production. And we've probably indirectly or directly lost our clients customers because of those mistakes.

If anything is certain in software development, it's that you'll fail. Because of this, the critical piece when vetting a developer is finding out how they respond to failure. Looking for a developer who has never failed will turn up two kinds of developers: Those who have failed, and liars.

Instead of facing the lost cause of finding a developer who always succeeds, ask them how they've responded to failure. Do they step up to address problems irrespective of who was to blame, or do they focus on placing blame, whether on their managers, their clients, or the technology?

Failure isn't always their fault, but the attitude with which they approach failure is an indicator of their character. Use this as a metric for how they might react to an issue on your project.

Is their rate commensurate with the market rate in your area?

The adage is that "you get what you pay for." While there are exceptions, it's most often the case that a developer knows what they're worth. If they're younger and just starting out consulting, a they might not necessarily know their value in dollars per hour or week. But then too, their lack of experience will likely be reflected in the work, whether it's now or after months of engaging with them.

Use sites like Payscale to determine how your candidate's rate compares to the average salary in the area. To convert an annual salary to an hourly rate, divide the salary figure by 1,000. For instance, if the average salary of a Senior Ruby Developer in your area is $100,000 per year, that comes out to $100/hour. This accounts for 20 billable hours per week, since most freelance consultants will spend equal time programming as they do engaging in business development, totalling to a 40-hour workweek.

If there's an obvious low rate outlier among your candidates, ask yourself whether there might be a reason their rate is so low. Do they lack experience? Are they eager to work with you, or desparate? Give them the benefit of the doubt, but don't let a low price fool you into believing you're getting a great deal!

Do they have professional references? Call them.

Always ask for the phone number of at least one professional reference. It might be a former manager, another client, or a colleague.

When you call, explain you're thinking of hiring your candidate, but that you have a few questions and are hoping they might be able to help. If they had a good working relationship, you'll hopefully find them eager and willing to help.

Don't know what to ask? Try these questions:

1. What obstacle would have prevented you from hiring/working with them?
2. What value did they provide to your business?
3. Would you recommend them to others?

These specific questions will help you identify:

• If there was something that gave them pause before hiring the candidate
• What specific value the candidate provided to a real-life business
• Whether someone would go out of their way to recommend the candidate's work

Now you have a first-hand testimonial with real talking points upon which you can base your decision!

Get a second opinion from someone you trust.

If you know someone else in the industry whose opinion you trust, why not hire them to help you with the process? A seasoned developer or technical manager will have years of experience with other developers and will know what to look for.

They'll be able to review the candidate's sample code and portfolio to tell you whether they'd feel comfortable working with them.

And most importantly, they'll give you an impartial opinion because you'll pay them a fee for helping with the hiring process—not for being a prospective candidate.

Review

When you hire your next freelance developer, consider the following:

1. Do they have the heart of a teacher?
2. Are they willing to challenge your assumptions?
3. Are they an effective communicator?
4. How do they respond to failure?
5. Is their rate commensurate with the market rate in your area?
6. Do they have professional references? Call them.

Hiring technical talent can be anxiety-inducing if you don't approach it with a process that helps you filter away candidates that aren't the best fit for your business and project. Have any techniques you like to use?

Since moving to Eugene, Oregon at the beginning of 2017, I've been flat-out astonished at the energy booming in the tech and creative communities here. Between #TechTuesday, RAIN Eugene, Silicon Shire, and the Eugene Tech Switchboard, Eugene has an incredible infrastructure of support for developers, designers, makers, and more.

This all makes me excited to contribute to the advancement of Eugene's status among creative cities. I want to build tools that help our community members promote their talents and services.

That's why I built WEAREEUG.

Inspired by sites like We are PRTLND, WEAREEUG is a "who's who" site for the Eugene creative community.

The response so far has been overwhelming. To everyone so far who has created their own profiles, I thank you for making the site glow on its very first day!

If you have an idea or suggestion for the site, I'd love to hear it. Send me a message or find me in the Eugene Tech Slack. I'm @teejayvanslyke.

Check out WEAREEUG

Incoming Webhooks are the simplest way to post messages from your application into your users' Slack channels. They use plain HTTP requests with JSON payloads to post text messages and rich content alike.

If you're building a Slack app, with Rails, you probably want to make use of incoming webhooks to send custom message notifications about your app. To do this, we'll authenticate your app to your user's Slack team and extract the incoming webhook URL from the API.

Embed the "Add to Slack" button

If you haven't already registered your app with Slack, go to the Your Apps page and click "Create New App". Give your app a name and click "Create App".

After you've created your app, head over to the Slack Button documentation page and scroll down to the "Add the Slack button" section. There you'll find a form where you can customize the code for embedding your Slack button. Be sure to select your app name from the list. Also be sure the "incoming webhook" option is selected.

Paste the resulting code into the view where you want your user to authenticate their Slack team with your application. You'll most likely want this to occur after the user has already authenticated themselves with your app so they'll be able to log back in and change their preferences.

Create a callback endpoint

When your users click the "Add to Slack" button, they'll be taken to a Slack-hosted page where they'll verify that they want to give you the ability to post to Slack on their behalf. After they confirm, Slack will redirect to an OAuth Redirect URL. This URL will receive a special code from Slack that will grant your app access to Slack's API features, including incoming webhooks.

Before we build the endpoint, add the Slack API gem to your Gemfile. I came across two popular gems at the time of this writing. The one we'll use is the slack-api gem:

# Gemfile
gem 'slack-api'

Run bundle install to download the gem and load it into your app.

Next, define a route in your routes.rb file for our new endpoint:

# config/routes.rb
Rails.application.routes.draw do
  # ...
  get '/auth/callback', to: 'slack#callback'
end

Then, create a corresponding controller in app/controllers:

# app/controllers/slack_controller.rb
class SlackController < ApplicationController
  # If you're using Devise to authenticate your
  # users, you'll want to first ensure you
  before_action :authenticate_user!

  def callback
    client = Slack::Client.new
    response = client.oauth_access(
      client_id: <YOUR_SLACK_CLIENT_ID>,
      client_secret: <YOUR_SLACK_CLIENT_SECRET>,
      code: params[:code],
      redirect_uri: "http://localhost:3000/auth/callback"
    )

    if current_user.update_attributes(
      slack_access_token: response['access_token'],
      slack_incoming_webhook_url: response['incoming_webhook']['url']
    )
      redirect_to root_path
    else
      render text: "Oops! There was a problem."
    end
  end
end

First, we create a before_action which authenticates the user before entering the controller action. It's likely you'll want to know who is clicking the "Add to Slack" button so you're able to save their Slack credentials for later use and/or discarding.

Then, in the action, we create a new Slack::Client object and call the Slack API method oauth.access which will grant us access to the Slack access token, incoming webhook URL, and other metadata associated with the Slack account we just authorized.

You'll want to change the client_id and client_secret settings to reflect the settings in your Slack app's configuration.

Since we defined the route to our callback as /auth/callback in our routes file, you should use http://localhost:3000/auth/callback (or a different port if you're running Rails elsewhere) as the redirect_uri value. Note that you'll want to make this configurable when you deploy this to production.

You'll also want to add http://localhost:3000/auth/callback to the redirect URL field in your Slack app config panel:

After we call oauth_access, we then update our current_user record's slack_access_token and slack_incoming_webhook_url attributes with the values in the API response. You might want to store them differently in your app, so I've added this purely for illustration. But you'll want to store them somewhere so you're able to access them when we post messages using the incoming webhook.

Send a message using the webhook

We've successfully authorized our Rails app to use the Slack API on behalf of our user. Now let's post a message using the incoming webhooks API!

For demonstration, let's build an endpoint at /post_message which posts the message "Hello, Slack!" into the user's Slack when we visit it.

First, add a route declaration:

# config/routes.rb
Rails.application.routes.draw do
  # ...
  get '/auth/callback', to: 'slack#callback'
  get '/post_message', to: 'slack#post_message'
end

We're going to use the Faraday gem as our HTTP client. Any HTTP client gem will do, since the incoming webhook is just a plain HTTP request. Add it to your Gemfile:

# Gemfile
# ...
gem 'faraday'

And add a new controller action to SlackController:

class SlackController < ApplicationController
  # ...

  def post_message
    conn = Faraday.new(url: current_user.slack_incoming_webhook_url)

    conn.post do |req|
      req.headers['Content-Type'] = 'application/json'
      req.body = { text: "Hello, Slack!" }.to_json
    end

    render text: "Posted to Slack!"
  end
end

First we create a new Faraday connection with the URL we captured in our callback action. Then, we post to the endpoint using a JSON request body. The payload of the request is formatted according to the specification in the Slack Incoming Webhooks documentation. Finally, we render some text to let the user know we posted to Slack.

We ought to do more error handling in the event Slack doesn't respond, but I'll leave that as an exercise for the reader.

Assuming everything is wired up, when you point your browser at http://localhost:3000/post_message, you'll find a new message waiting for you in Slack!

I had a tough time sifting through the Slack documentation to find a decent Rails walkthrough, so I hope this guide answers some of your questions.

You're using a static site generator like Middleman or Jekyll. These tools are fantastic for building blogs and marketing sites. But every so often you need to collect some data from your visitors in a form.

There are plenty of form tools on the web (Wufoo comes to mind). But most of them are bloated and made for less technically minded people. All you want is to embed a form in your site and be notified when your visitors fill it out without having to set up a server application.

Almost every time I've built a marketing site for a new product I run into this situation. So this week, I built a little tool called Formbot that's here to help!

Formbot sends the contents of your HTML form fields to any of your Slack channels. Create a custom HTML form with any number of fields, set its action attribute to your Formbot URL, and it'll do the rest.

Want to add a Slack-enabled form to your site? Install Formbot