DEV Community: Conlin Durbin

Upgrade your incident retrospectives with this template

Conlin Durbin — Wed, 19 May 2021 15:13:33 +0000

TL;DR: Get the template here

The more time you spend working for tech companies, the more likely it is that you will run a retrospective for an incident.

There are lots of theories out there about how to perform retros — from Amazon's "Five Why's" strategy to Netflix's Dispatch tooling.

For most engineering teams however, incident response ends with the fix and a couple words or paragraphs about what happened. This is a great starting place, but often times focusing on what happened over what caused it to happen means we are missing out on the ability to see the patterns in our incidents and responses and learn a build on those. Making the shift from thing about incidents to thinking about the systems that produce them is a great next step to improve your responses.

I've been using a template to record all the information related to an incident for a while now, I thought you all might like to see it!

The Template

The template focuses on a few main sections and is a simple to copy Google Doc. You can find it here! The rest of this post will be a breakdown of each section and how to use it!

Event Details

The header of the document focuses on some simple details about the event. First, put in the incident's date and give this document a title. Focus on something short and descriptive like "Product Name AWS outage". Ideally, you will be filling this out on the same day it happens, but if not make sure the date at the top is the date the incident happened. This makes it easy to search logs, chat messages, and PR's for what happened that day if people want to do more investigation.

The next section is Details, which records to type of event. Type definitions are largely up to you, but make sure they are standardized and documented somewhere. Some examples might be "Vulnerability", "Third Party", or "Production Bug". I'd recommending starting of with just a few types and adapting your system as you gather more information - if a few incidents are similar and don't cleanly fit a type, consider adding a new one.

Up next is the name of the Assignee - this is the incident leader, the person responsible for handling the incident (and hopefully the person filling out the template).
Next is a bit of metadata on this incident: Were customers impacted, what notifications were sent when it happened, and what was the source of detection (i.e. who or what reported this incident)?

Incident Details

The next bit is a table for writing up the details of the incident.

Description

First, type up a quick description of what's happening. Feel free to tweak and refine this as the situation changes - at the end you should have a short overview of the event and solution.

General Notes

This is a great session for tossing quick notes as you are going. It helps keep track of various findings and artifacts while you are still learning about them. This section is most useful when you are still working on the incident, but it can also store any links/notes that don't fit into other categories later.

Contributors & Enablers

Here is where we start to get to the important bits of the document. Instead of focusing on root cause analysis or the 5 whys, we're going to focus on contributors and enablers. No incident is ever caused by just one thing, rather they are the result of a flaw in a complex system of tooling, engineers, and opportunity costs. Here, we focus on the things that enabled this incident to occur or contributed to the impact it had. For example, a broken production push might have been enabled by a mis-configured deployment file or a lack of testing around a specific area of the application. Silenced logs and an engineer on vacation might have contributed to the impact it had. By logging these things, we get an idea of the holes in our system.

Mitigators

Mitigators are the things that went right - what made this have less of an impact than it could have? For example, perhaps a critical notification was seen caught by the on-call process or an engineer happened to be looking at a page when they noticed a bug. These kind of insights help you develop resilient pathways through which your incidents travel.

Customer Impact

This section is relatively straightforward - were customers impacted and what was the extent of that impact? Did production go down for everyone or was this a small bug for a single customer?

Difficulties in Handling

This section is pretty similar to the "Contributors & Enablers" section, but more focused on "one-off" events that made this more difficult to handle. Was there a holiday that made it hard to coordinate? Maybe the logs weren't logging correctly or the incident monitoring software didn't ping right away. These events aren't always solvable, but the do give a clearer picture of your weak spots.

Artifacts

This section is for any artifacts that were created for the resolution of this incident - charts, documents, dashboards, etc. Anything that was generated for the explicit purpose of gather/collating data for the resolution of the incident.

References

This section is for all the links, PR's, tickets, etc that are related to this incident. This should give a holistic view of all the work related to this incident.

Timeline

The final page contains a basic table template for tracking the timeline of the event with a simple branching color scheme to highlight co-incident work. It's a lot easier to fill this out as you go, but it can be filled out after the fact as well. Reading this should give a casual observer a basic understanding of what happened and what steps were taken to solve the incident.

Final thoughts

This document should help you start tracking and logging the important information around your incidents, but all that data isn't super useful unless you are learning from it. A great way to do that is to have incident review meetings monthly - each team puts together a quick slideshow with the data contained here and presents it to the other teams. Bonus points for taking notes and pointing out commonalities. Even bonus-er points for coming up with some strategies to try out to lessen the impact of contributors or make mitigators even more impactful.

I hope this template is helpful! What does your incident response look like? What kind of learning does it optimize for?

Cover Image by Jp Valery on Unsplash

Build Something That Makes a Difference

Conlin Durbin — Wed, 13 May 2020 19:36:50 +0000

This was a post I wrote almost a year ago. I just now am getting around to sharing it.
If you didn't know, Codeland is online this year! Check it out!

I’m back from Codeland, and I’ve had some time to sleep and decompress. I had an inspiring and fulfilling weekend in NYC.

I spent 5 days in NYC and had an absolutely fantastic time. I explored the city - hanging out with some old friends and making some great new ones.

The conference, Codeland, was an exceptional experience! I met so many great people and heard talks that inspired and encouraged me.

The morning started out with some talks. Luna Malbroux gave a lively introduction to EquiTable, a bill-splitting app born out of a comedy code jam. The app illustrates the intersection of comedy, technology, and inclusion. One of the big takeaways for me was that we are obligated to build inclusivity into the tools we work on. Her jokes had the crowd roaring and really hit home that this conference was going to be something different.

Pedro Cruz gave an incredible talk on his work using drones to aid the victims of natural disasters. That talk reminded me that there are incredible things that we can be doing with technology. Unless we work to experience the wider world community, we can’t make those things inclusive and innovative.

After this, I jumped to my workshop, where I met some great devs from the Midwest and hacked on an IoT chip. I haven’t done hardware related stuff in a while, and I really enjoyed it! From there, it was off to lunch and into the next set of talks.

The second set of talks kicked off with Ali Spittel, who discussed why developers should think about blogging. Her journey started last year when she began writing blog posts to help her learn new things. One of the best ways to give back to the development community is to write.

Up next, Omayeli Arenyeka gave a talk on building a gendered dictionary. The talk was pretty technical, covering where she got her data and how she merged it all together. The end result was a dictionary that showed which words in the English language are gendered - things like king and queen. The dictionary lives online and is an incredible look into how our language shapes our thoughts. Why do we often think that “doctor” is a “male” word? What would our world be like if we started thinking and communicating without gendered language?

Michael Winslow gave a fascinating talk on the challenge of programming a cross-fade. There are tons of implications to consider when fading out one song and fading in another. This talk was technical, fun, and inspiring. There are so many interesting problems out there that we could solve with technology if we give it a shot.

Art Meets Algorithms, given by Kristen Webster, was a fascinating look at how we can use computers to create art that would be impossible for a human to create by hand. Algorithms have an inherent structure and beauty to them, which we can use to create fascinating art.

The last talk in this set was from Jo-Wayne Josephs, who spoke about her experience as an LGBTQ+ immigrant to the US. She shared her story of coming to the US, trying to find work while waiting for asylum, and finally being granted asylum here. It’s unbelievable all the things immigrants have to go through to live, work, and improve themselves here. One major takeaway I had from this is that a functional diversity and inclusion program should include resources for people looking for asylum or citizenship. There are tons of great organizations out there and even just having a list of the ones that might be helpful is a significant first step.

We had a break here, where we met with the conference sponsors. I met some inspiring folks from Github, and a company called Raise.dev, who are creating an impressive way to help new developers work on real projects and learn real-world development skills.

Finally, we all came back into the theatre to hear a talk from Scott Hanselman about building an artificial pancreas. There were some incredible technical pieces to this talk - from Bluetooth and radio communications to building applications to help monitor glucose levels. However, to me, the most critical part of the talk was how it inspired developers to find something that seems set or unchangeable and use technology to change it. The proprietary technology that powers glucose monitors doesn’t speak to the technology that powers insulin pumps, so some intrepid hackers made a device that bridges that gap. There are so many problems out there that could be improved with technology.

I think my favorite takeaway from the conference was a joke line from Michael Winslow’s talk on building cross-fade technology. In talking about being a DJ and channeling a bit of Uncle Ben, he said, “With great volume, comes great responsibility.”
I know what was meant by this line at the time, but I think it sums up the conference better than I ever could. In the world of tech, we tend to forget just how much volume we have. When Facebook “moves fast and breaks things,” they do so at the expense of those unable to be broken. When we limit our intake of immigrants through draconian immigration law, we miss out on the incredible people that want to make our country better. We exist in a noisy industry, and we have a responsibility to use that volume in the right way.

Design Systems 101

Conlin Durbin — Wed, 01 Apr 2020 14:12:55 +0000

How a design system speeds up page design

What the heck is a design system?

Let's start out with a couple quotes to set the mood:

A design system’s purpose is to provide consistent, tested and reusable solutions for a common UX problem.
Mina Markham

A style guide is an artifact of the design process. A design system is a living, funded product with a roadmap & backlog, serving an ecosystem.
Nathan Curtis

So what is a design system?

Well, it's not a box of Legos. It's more like the Lego factory.

People | Tools | Patterns | Guidelines | Values

A good design system is a collaboration between many parts of a business and product. It is a distillation of a companies values and people into a set of guidelines, tools, and patterns that make rapid development easier and enable a team to produce accessible functional tools.

A design system is integrated - it's built into the product and organization/product development process, not merely a style guide you reference

A design system is shared - it’s actually shared and adopted across the organization, in order to cover major part of the product

A design system contains patterns - can be patterns and/or components.

A design system contains principles - there is underlying principles behind the patterns that guide the work

We think we merely design and build websites and apps. And that’s true for the most part. After all, that’s what our clients pay us to do, and the products we create are the vehicles that generate money and success for our organizations. It seems natural to focus on the final implementations rather than the underlying system. The live products remain the primary focus of everyone’s attention, while any pattern library exists as an offshoot that simply provides helpful documentation.

Deliverables

Shopify has a great example of the various deliverables that might be produced from a design system.

Patterns

Rules around accessibility, internationalization, layout patterns, and error messages would all be gathered in the Patterns section.
Example

Content

Rules about website content, blog posts, and documentation all fall into the content portion of the design system.
Example

Style Guide

Rules about design and the creation of visual elements fall into the style guide portion.
Example

Code Style

Code style and formatting, stylelint rules, and CSS patterns are all part of the code style portion of a design system.
Example

Component Library

Reusable components like buttons, form fields, and grids make are part of the component library.
Example

Benefits of a design system:

Design systems bring order to chaos. Everyone is kept on the same page, so the entire product remains consistent and polished throughout.
Design systems improve the user experience through the repeated use of familiar and proven patterns. Designing anything from scratch leaves room for error, so try to use what already works.
Design systems improve workflow efficiency. Product teams know exactly how components of new features should look and how to implement them.

Building a design system

Questions to ask

How does the system work today and in the future?
What is our vision?
What problems are we trying to solve?
Who does this problem most impact?
What impact do we want a design system to have on how we work?

Building on a smaller team

1. Don't start from scratch

"Steal like an artist", where you can. There are lots of open design systems out there that we can borrow from. Additionally, there are lots of good tools that we can use.

Even things like Bootstrap can be useful to steal from - we can find common patterns that many web-apps use and build reusable components to build them out for our companies.

2. UX/UI Audit

We can't know where we are going until we know where we are and where we have been. Before starting, get an idea of where you are, what pages you have, what components they use, and what makes sense to abstract into a design system.

3. Build a living document

A design system is a living breathing collaboration between designers and developers. As such, it can and should grow and evolve - which means getting started and letting it change/evolve.

Some ideas of sections:

Colors
Typography
Sizing/Spacing
Imagery

4. Build a component library and document it

Once the audit is done, begin to build out a component library. For each component, include documentation and standards. Remember that when not to use a component is just as important as when you should use it.

Quick Activity for getting started

Our design system offers ____[kit scope]____
released as ____[kit outputs]__
and documented at ____[kit doc site]__
produced by ____[people]______
in order to serve ____[products]____
products and experiences.

To infinity and beyond

As the design system grows and evolves it enables us to work in interesting and new ways.

Giving Back

One great thing about a design system is that it can live out in the open. It's a great way to represent your Product/Engineering brand and give back to the community.

DesignOps

DesignOps (also called div-ops!), much like DevOps, is a fast-growing field. A design system is the first step in implementing a DesignOps team.

https://clearleft.com/posts/design-ops-a-new-discipline

Full Stack Design systems

When you’re creating a bespoke Design System for a specific product, you have the opportunity to not just group common UI elements together, but to actually represent your core product concepts at many levels. I call this a Full Stack Design System.
[Link]

Tips

Any design system is better than no design system at all.

Get something built sooner, rather than later.

GitHub’s design system, Primer, was being revamped internally and privately. Doing so, Diana said, was in part because her team faced Imposter Syndrome comparing Primer to the systems of matured and larger organizations like AirBnb’s DLS, Shopify’s Polaris, and the US Web Design System. Primer felt unpolished in comparison. Many components were deprecated.
[Link]

Build systems, not pages

The web is massive and diverse - it is no longer enough to build webpages. Instead, we need to think about responsive and adaptive design made up of components.

http://www.atomicdesign.bradfrost.com/chapter-1/

Pay attention to the team's limits

We can't build a design system in a day, a sprint, or a quarter. Even starting with just a sketch file that makes the creation of new features and pages consistent is a good base.

Organization is key

Avoid "quick and dirty", you'll only bite yourself later. Make sure people know what is happening and get input from everyone that might touch the system. The worst possible timeline is some people using the design system and others not using it.

Have a single source of truth

Have a sharable Sketch library and component library that everyone uses while working on the design system.

Links & Tools

Abstract's Customer Stories - Stories from Abstract's customers, who are using Abstract to build collaborative design systems
Design Systems - A Figma publication for design systems
Getting Developers Started with a Design System - A good article on ramping developers into a design system.
Design Systems Repo
Getting executive buy-in for your design system | Inside Design Blog
Picking Parts, Products & People - EightShapes - Medium
Accessible Brand Colors
Sketch version control & design workflow management - Abstract

Introducting RunCLI

Conlin Durbin — Wed, 21 Aug 2019 14:17:16 +0000

I just released the first version of a new little tool called RunCLI.

RunCLI let's you easily share commands with a URL. It's really basic right now - just paste a command in the textbox and click "Create". The main use case is for apps like Twitter, where sharing a medium-sized CLI command is difficult to do well.

Here is an example with a Git command:

https://runc.li/#Z2l0IGxvZyAtLXByZXR0eT0iQCVoIiAtLW51bXN0YXQgLS1mb2xsb3cgPEZJTEVfTkFNRT4gfCBncmVwIC12IFx8IHwgIHRyICJcbiIgIiAiIHwgdHIgIkAiICJcbiIgfCBhd2sgJyQyID4gNCB7IHByaW50ICQyLCAkMywgJDEgfSc%3D

I probably won't add a lot more to this, but I'd love to know what you would like to see it do!

Your favorite `git` aliases?

Conlin Durbin — Tue, 20 Aug 2019 15:29:56 +0000

What git aliases do you use? Why do you like them?

What's something you wished people would ask you about more?

Conlin Durbin — Thu, 01 Aug 2019 12:20:36 +0000

Just a fun Thursday morning question. What is one thing you wish people would ask you more?

5 tips for your first 5 days as a new dev

Conlin Durbin — Mon, 29 Jul 2019 21:32:14 +0000

Starting your first developer position can be daunting. Even after a few years, switching companies can be stressful. Here are a few tips to make transitioning into a new team easier, especially focused on new developers.

1. Meet people outside the product/engineering team

You're going to be siloed for a lot of your job, working closely with designers, product managers, and other engineers. One of the best ways to feel integrated and understand the larger impact you are having on the team. Reach out to some salespeople or a support person. If you are in an engineering-dominated company (like a Google or Apple), reach out to someone on a separate engineering team (preferably not another engineer).

Ask that person to get coffee with you or if they want to eat lunch during your first week. Chat with them about what they like best about the company, what food places they like around the area, or where there favorite quite places are around the office.

2. Take some time to get your developer environment set up

A lot of the developers I know are pretty particular about their developer environment. Joining a new team and working on a new product is a great time to get your development environment set up the way you like it. You are already going to be less productive than normal, so take some time to try out that new tool or workflow you've been wanting to check out. Worst case, you hate it and it makes you a little less productive for your first week. No harm done!

If you are looking for some new tools, check out this community #discuss I put out a bit ago:

What are your favorite developer tools?

Conlin Durbin ・ Jun 28 '19

#discuss #tools #macos #linux

3. Write some code, make a commit

On every team I've ever joined, I've made it my goal to have committed code in the first week. It gives you a good win in your first week and something to share if your team has Friday retros or team shares. It doesn't have to be anything too big - maybe you fix a small UI bug or pick up a little performance improvement. A good engineering team will have a way of tracking new developer work. If yours doesn't, ask another engineer for some help finding something that meets the criteria of being small and doesn't require much knowledge of the app. Then you can suggest tracking those kinds of stories in the future for when new devs come on! Double win!

4. Leave on time

This is a hard one and a good team will make sure you do it. Don't stay late because you are the "newbie". That establishes bad habits. Unless you have a fun event to stay after for, I'd recommended leaving at the usual time. Even if there is another engineer that stays around much later, don't feel like you have to emulate that behavior. Establish a healthy balance between work and home. Make sure that working late is an exception, never the rule.

5. Work hard, but not too hard

This final suggestion ties directly into the last one. I've heard this recommended as working at about 60% effort your first week. Don't go all out. You have plenty of time to prove yourself and you definitely don't want to peak in your first week on a team. Slowly integrate yourself into the codebase, learn about the team dynamics, and spend some time just settling in. Then, once you are acquainted with the team, start ramping up your effort. It not only makes you look better, but it will help you and the team ease into you being involved.

This doesn't mean that you should produce low-quality work, but instead produce a lower quantity for your first week or so.

Hopefully these tips help! I'd love to hear your thoughts in the comments or on Twitter.

The Radar Gun Problem

Conlin Durbin — Wed, 10 Jul 2019 00:00:00 +0000

The other day, I was driving home from an event and there was a massive slowdown on the highway. I assumed that there was a crash or some construction up ahead, but as I got closer to the bottleneck, I realized that the only difference was that there was a cop standing on the side of the highway with a radar gun. Just the presence of a monitor slowed down the performance of the system.

Later that week, I was debugging some Javascript code and ran into a problem I have hit a few times. I had a fairly intensive process looping over a lot of values. I took the standard approach to debug a JS problem and dropped in a console.log. I refreshed the page, opened the console... and almost crashed my browser.

Calling a console.log with an intensive process takes a lot of memory, it turns out. I've run into this before, but this time the traffic slowdown really made me think about it. Let's talk a bit about something I'm calling the RadarGun Problem.

In many situations, the fix for the problem is changing where the observation happens. Moving the console.log outside of the loop - either after or before -is a good option. You can also change the method of observation - drop in adebugger; and step through it, introducing a purposeful bottleneck to prevent an accidental one.

Have you run into this before? How have you solved it?

What are your favorite developer tools?

Conlin Durbin — Fri, 28 Jun 2019 14:49:47 +0000

Happy Friday!

We're getting new laptops at work, which means I have a good opportunity to re-evaluate my development setup. What lesser-known tools should I check out?

Learning React in 2019: What is React?

Conlin Durbin — Wed, 29 May 2019 00:00:00 +0000

Spend any amount of time working in the Javascript ecosystem and you'll probably hear a lot about React. Opinions on what the library is/does/should be are as numerous as the people working with it. Let's explore what React is and what the most important parts of the framework are.

Officially

If you visit the React homepage, you'll find a great description of what React is. Right at the top, you will see the words "A JavaScript library for building user interfaces". Let's break that down a bit.

"Javascript"

An important note here is that React is and probably will always be a Javascript framework. Even when you are dealing with React Native or another library, you are going to be working with Javascript code.

"Building user interfaces"

Here is the "big idea". React - through concepts like the virtual DOM, diffing algorithms, and fibers - is a fast, reactive way to build user interfaces. With tools like React Native, this expands to a large number of devices - React is not a web-only library.

Like this post?

It is the first in a series "Learning React in 2019" that I am working on. If you like it, subscribe to my newsletter below - I send out weekly updates about my posts, breakdowns of what I'm learning, and some great links I found around the web.

🎉Sign up now!🎉

The important parts of React

Likely, you have heard a lot about different features in React - the virtual DOM, components, state, hooks, and more all make up the different tools in your toolbox. Which of these are important when you are just starting out? Where should you focus?

Javascript

The best thing you can do to help improve your React skills is to work on your Javascript ones. React is built in Javascript and a good understanding of classes and functions will get you very far!

The Virtual DOM

The Virtual DOM is one of the ways in which React is so fast. Instead of doing complex operations like swapping div and re-rendering lists on the DOM, React uses a virtual representation of the DOM. If you think about the DOM as an object, it could have nodes like this:

{
    node: 'html',
    children: [
        { node: 'head', ...headElements }
        { node: 'body', ...bodyElements }
    ]
}

That object is an example of the Virtual DOM. It's much faster to swap out an element in an array than it is to swap out an <li> rendered in the DOM. If you are doing lots of DOM updates, then React can batch them and god much faster.

After to work on your JS skills a bit, I'd highly recommend checking out a tutorial on building your own basic Virtual DOM (like this one). You'll get a much better idea of what you are working with, which helps a lot when learning.

State Management

Finally, another major piece of React is state management. A great way to think about React is as a framework for presenting slices of state as a view. A component in that case is just the rendered view for a specific state. Think about this: if you have a list of items in an array stored in state, let's call it numbers, the rendered list of li's is a slice of that state, at that particular time. If you add something to the array, the li's update and you get a new slice of state.

Learning to manage your state in a React app is a great way to build performant web apps. We'll cover more on that in a later article!

It's not hard to level up quickly in React. A base understanding of the way React apps work and what React is can go a long way in helping you build great, performant front-ends. Next time, we'll cover more about JSX and how it works.

Thanks for reading!

Where to find hosting?

Conlin Durbin — Wed, 15 May 2019 11:49:00 +0000

New site, new series

I just released a new personal website and I wanted to write up a guide to creating a personal website in 2019. Here is what we will be covering:

Hosting your personal site
Writing your copy (Coming Soon)
Laying down some HTML (Coming Soon)
Adding some style (Coming Soon)
Interactive Personal Sites (Coming Soon)
Getting a domain name (Coming Soon)

Let's dive in!

Choosing the right hosting

The hosting you choose for your site comes down to a few important factors. First, you need to decide what kind of site you are going to host. Is it a simple HTML site? React/Gatsby? Or maybe you want a full Wordpress installation? Those choices will help dictate what host you want to go with. This site is running on Gatsby, so I want a host that makes deploying and updating my site easy.

Some different options

Netlify

Netlify is the webhost that I use for this site - its easy to set up, works really well with Gatsby and doesn't cost me anything! In addition, they have some really interesting addons that you can use to build out login systems, AWS lambda functions, and large media hosting. I am investigating some of these things to build out some tools in conjunction with this site and some React courses I am working on.

Link to Netlify

NearlyFreeSpeech

For a good, free as in speech option, I'd highly recommend NearlyFreeSpeech. They cost very little and provide a great service with support for Ruby, Node, Python and more for like 25 cents a month. I use them to host a few personal services, like my calendar. I used to run my personal site on them, but Netlify was just too great and worked too well with Gatsby.

Link to NearlyFreeSpeech

DigitalOcean

DigitalOcean is another great option if you want a lot of customization. It's almost more like running your site through AWS, but their backend is a lot more user friendly. This option costs a bit more, but is a great solution if you need what they provide. I use DigitalOcean to host a few side projects and the analytics engine for my personal site.

Link to DigitalOcean

Wordpress.com

Wordpress.com is a great option if you want to run a Wordpress site - the pricing is fair and they will handle basically everything for you. If you are getting started in tech and don't want to have to worry about building your blog, this is a great choice.

Link to Wordpress.com

Bluehost

Bluehost (and many other more traditional hosts out there) offer one-click installation of all sorts of tools like Wordpress, Drupal, and more! These hosts have tons of documentation around them and can be a really good, low-cost option. They will support all kinds of sites and typically have really good tech to handle a lot of website load.

Link to Bluehost

Conclusion

All in all, I would highly recommend using Netlify - its a great way to learn a bit about backends without getting too in-depth and their support for various architectures is just great. You can find really good tutorials online for setting up a site with Netlify and the community around them is really great!

Getting started with Deno

Conlin Durbin — Thu, 18 Apr 2019 13:21:04 +0000

Edit: Deno has hit 1.0 and with it, there has been some major discussion around whether the project needs an explicit CoC. The original maintainer seems to think it doesn't and I can't recommend that you use Deno until they do.
A Code of Conduct is a necessary part of any open source project.

In case you missed it, the new Javascript and Typescript runtime from Ryan Dahl, the creator of Node, has been released! It's got some really cool features and is ready for public use! Let's look at a few of the neat features and get started with a simple hello world!

What is Deno?

Deno is a new runtime for Typescript (and Javascript) written mostly in Rust. It has some great goals and some very interesting "Non-Goals", like not using npm and not having a package.json.

Getting it installed

Installing deno is as easy as running this command:

curl -fsSL https://deno.land/x/install/install.sh | sh

Then copy the export line and add it to your ~/bashrc or ~/bash_profile.

Open a new terminal and run deno. You should get a > prompt. Type exit and let's dig into some features!

Cool features in Deno

Typescript by default

Deno is integrated to run Typescript files by default. It basically makes types in Javascript a first-class citizen. No more compiling through Babel to use Typescript in server-side Javascript.

Importing from a URL

Deno lets you import from the web, just like you can in the browser. Just add a URL where you would usually name a module:

import { bgBlue, red, bold } from "https://deno.land/std/colors/mod.ts";

A Standard Library

Furthermore, Deno has a standard library that is easy to import and use. There are modules that do a couple of different things, like HTTP handling, datetime work, and file system work. You can check it out here.

Uses ES modules

Finally, Deno only supports ES module syntax, which means no more require() statements, just good ole' import x from "y".

Hello World Example

Let's look at a quick Hello World that highlights a few of those features!

Copy this into a hello-world.ts file.

import { bgBlue, red, bold } from "https://deno.land/std/colors/mod.ts";

const sayHello = (name: string = "world") => {
  console.log(bgBlue(red(bold(`Hello ${name}!`))));
}


sayHello();

sayHello("Conlin");

You can now run that with deno hello-world.ts and it should print out some stuff.

Change one of the sayHello calls to sayHello(15); and rerun it. You should see a type error since 15 isn't a string! That's pretty cool!

You'll also notice how to import from a URL - it's getting some console color stuff from the standard library!

Final thoughts

Deno isn't quite ready for the production use - there are a couple bugs, but development is moving forward quickly! This is definitely a cool new open source project and one to keep an eye on!