# Echobind

> Echobind is a product studio that designs and builds beautiful, reliable web and mobile applications — with deep expertise in healthcare, Stripe payments, AI integration, and React Native. We partner with teams from strategy through design, engineering, and launch.

Markdown versions of most content pages are available by appending `.md` to the URL (for example, `/post/<slug>` is also served as `/post/<slug>.md`). A full-text export of blog posts, case studies, and services is available at https://echobind.com/llms-full.txt.

===

# Services

# AI you can put your name on.

Connie, live inside Upstream's FreeBC, answers contraception questions for real patients: clinician-reviewed corpus, no open web, and a decline when it cannot ground an answer. 11,400 users in its first three months. Everything we ship is held to that bar, and if your surface is wrong for AI, we say so before you spend on it.

## How we build

### 01  Close the corpus first

If the model can reach material nobody reviewed, you do not have a product. You have a demo with a longer context window. We treat ingestion as the architecture decision. Prompting comes after.

### 02  Decline is a feature

A confidently wrong answer about a dose, a denial, or a diagnosis is not a UX miss. It is an outcome. We spend review cycles on the requests where the system is supposed to hold a line, and we ship the decline on purpose.

### 03  Outputs, not specs

Human-in-the-loop is a calendar commitment. We put real generated answers in front of the people who own the risk, repeatedly, until the declines and the answers both hold.

## What we build

Six capabilities, each anchored to real work.

### 01  Constrained assistants on a closed corpus

An assistant that answers from material you have reviewed and declines everything else. Connie, the assistant inside Upstream's FreeBC contraceptive-care platform, is the reference: a clinician-reviewed corpus, no open web, and a decline when it cannot ground an answer.

### 02  Voice agents

Registration, scheduling, and intake by voice. We helped Teladoc Health put telehealth visits on Amazon Alexa-enabled devices, and built HIPAA-compliant patient-intake voice work for a pharma services company.

### 03  Computer vision

Models that watch video and pull out what matters. Ballers turns a phone recording of a basketball game into highlights, stats, clips, and player profiles, automatically.

### 04  Document intelligence at scale

OCR, ingestion, and categorization for documents that arrive by the thousand. ReceiptVault pulls receipts out of email and off paper, reads them, and files them where a search will find them.

### 05  Automation a human still signs

We automate the work that burns hours and keep a person on the decisions that matter. For CNY Fertility, automation took per-patient administrative time from 40 minutes to 5.

### 06  Agent infrastructure and deployment

Agents your org can actually run: provisioning, memory, allowlists, and no public network surface. Our open-source rome-on-rails template deploys Hermes agents on Railway, each one a private node on a Tailnet.

[Read how we run them](https://echobind.com/post/manage-ai-slack-agents) · [rome-on-rails on GitHub](https://github.com/echobind/rome-on-rails)

## The work, checked

Every number below comes from a published case study or the product itself. Where we cannot name a client, we say so.

### 01  An assistant that is allowed to talk to a patient.

_Constrained assistant_

Connie answers contraception questions inside FreeBC, Upstream's digital contraceptive-care platform. The corpus is closed: authored and reviewed by clinicians, no open web. We put Connie's answers in front of Upstream's clinical team, repeatedly, until the guardrails held. Five months from kickoff to production, with two engineers and a PM.

**Client:** Upstream (FreeBC)

**The constraint:** Connie is constrained to a clinician-reviewed knowledge base. When accuracy cannot be guaranteed, it declines instead of guessing.

**What changed:** 11,400 users in the first three months. Users who completed the quiz were seven times more likely to complete a care pathway.

[Read the FreeBC case study](https://echobind.com/work/expanding-contraceptive-care-access-ai-assistant-telehealth-platform)

### 02  Automation for a clinic that could not stop moving.

_A human still signs_

NOVO is a patient onboarding and self-service scheduling platform for CNY Fertility, a fertility clinic with eight US locations. Patients book, reschedule, and cancel with no human intervention. Robotic process automation moves the data into the clinic's EMR. Built and launched in eight weeks.

**Client:** CNY Fertility

**The constraint:** The legacy EMR had no API. We automated data entry into it with RPA instead of waiting for API development.

**What changed:** 87% less clinical workload per patient: 40 minutes down to 5. Consult waits fell from over a month to two days. $10K+ saved monthly.

[Read the CNY Fertility case study](https://echobind.com/work/scaling-fertility-care-self-service-scheduling-emr-automation)

### 03  Telehealth visits over a smart speaker.

_Voice_

We helped Teladoc Health build voice telehealth visits on Amazon Alexa-enabled devices: register, schedule, and connect to a board-certified physician by voice, where the old path was a mobile app or a 1-800 number. The call-center reps stayed in the loop, down to the whisper they hear before a call connects.

**Client:** Teladoc Health

**The constraint:** The brief was minimal disruption. Every change was scoped to what the voice use case required, and the call-center reps were kept essential rather than designed out.

**What changed:** Went live with no significant glitches, in a launch announced publicly by both Teladoc Health and Amazon.

[Read the Teladoc case study](https://echobind.com/work/teladoc-building-the-future-of-healthcare-with-voice-assist)

### 04  A chatbot brain the clinicians could retune.

_Clinical conversation_

Pear Therapeutics, the company behind the first smartphone app to receive FDA authorization for treating medical conditions, brought us in on Pear 006: a CBT app for depression in Multiple Sclerosis patients. We built a contained chatbot brain that directed patients through guided conversational threads, each one administered by Pear's mental-health experts through a spreadsheet interface. The brain was designed to be replaceable.

**Client:** Pear Therapeutics

**The constraint:** We evaluated Microsoft Bot Framework, Rasa, and DialogFlow against Pear's clinical constraints, and recommended a contained, expert-controlled brain instead.

**What changed:** Pear's clinical team could refine patient interactions without engineers in the loop.

[Read the Pear case study](https://echobind.com/work/an-evidence-based-app-to-help-ms-patients-with-depression)

### 05  Set a phone courtside and the game films itself.

_Computer vision_

Ballers turns a phone recording of a basketball game into AI-generated highlights, stats, clips, and player profiles: set the phone up courtside, hit record, and go play. Highlights and stats are ready before you leave the gym. The full technical write-up is in progress; the product is public.

**Client:** Ballers

[See Ballers](https://ballers.gg)

### 06  Every receipt, read and filed.

_Document intelligence_

ReceiptVault pulls receipts out of email automatically, reads paper receipts with OCR, and categorizes all of it: search, folders, return windows, spending analytics, exports. The pipeline runs on email integration and receipt-scanning models, not on a person sorting an inbox.

**Client:** ReceiptVault

**What changed:** Per receiptvault.com: an emailed receipt lands in a user's vault in 0.8 seconds, and pulling one back up takes 2.4.

[See ReceiptVault](https://www.receiptvault.com)

### 07  A personal AI agent for every teammate. No public URL.

_Agent infrastructure_

Every Echobind teammate gets a Slack agent with its own bot identity, memory, and allowlist. Each deployment is a Tailscale node: SSH for maintenance, outbound Socket Mode for Slack, no inbound ports. We open-sourced rome-on-rails, the Railway template that deploys them, wrapping the Hermes agent by Nous Research.

**Client:** Echobind, open source

**The constraint:** Private by default: no public URL, no inbound ports, and an explicit Slack allowlist. If the allowlist is unset, the bot refuses every message.

**What changed:** A personal agent for every Echobind teammate, and an open-source template anyone can deploy.

[Read how we run them](https://echobind.com/post/manage-ai-slack-agents) · [rome-on-rails on GitHub](https://github.com/echobind/rome-on-rails)

### 08  A voice agent that collects patient information.

_Voice, under HIPAA_

For a pharma services company, we built a voice agent that collects patient information in a HIPAA-compliant way. We do not have permission to name the client, so we do not. Where we cannot name a client on this page, we say so.

**Client:** A pharma services company

## The Surface Review

Two weeks. A senior engineer and a product partner. We walk the one surface that would hurt if it were wrong.

You leave with one of two things:

- A constrained spike you can put in front of the person who owns the risk

- A written no, and the cheaper thing that actually solves it

If the right answer is do not build this, that is the deliverable.

## You already know which surface this is.

[Walk us through it](https://echobind.com/contact)

---

[View on echobind.com](https://echobind.com/services/ai)

---

# Design Concepts

> Brainstorm and visualize multiple visual identities before committing to a given direction.

## Design Concepts

Design concepts serve as a foundational step in establishing the visual language and direction for your product. This exploratory phase allows us to visualize multiple visual identities, ensuring that the final design not only resonates with your brand but also appeals to your target audience. Through design concepts, Echobind collaborates with you to explore various design directions, enabling a creative and strategic approach to crafting a product's visual identity.

#### What to Expect

Defining your product’s design concept is collaborative and iterative, focusing on finding the right visual language that aligns with your project goals. We start by meeting with you to understand your brand and what your product’s visual language needs to communicate. We talk through any constraints that might be relevant for making visual decisions. For example, is your app data heavy? We will want to consider typefaces that are highly legible inside of tables at small sizes. Once we’ve gathered brand and technical information from you, our designers will explore various visual identities by creating style tiles. We’ll then meet with you to review them, refine the ones you like, and ultimately settle on a single direction that will inform the UI Design and Style Guide.

#### How It Works

**Milestones**

Our design concept process often includes the following:

- Kickoff Meeting: We start by understanding your vision, brand values, and user demographics to guide the design concept phase.
- Design Concept Development
- Review and Iteration: ****Together, we review these concepts, gather feedback, and refine our approach until we find the perfect visual direction.

**Deliverables**

- Mood board (typically a Figma file)
- Style tiles (typically a Figma file)
- Recordings of any meetings

---

[View on echobind.com](https://echobind.com/services/design-concepts)

---

# Product Design

> Make users genuinely happy with insight-driven design that works.

## How design works at Echobind

From navigation to visual design we put the user at the center of the design process. And we take you, the client, on the creative journey from first concept to interactive crowd-pleaser.

#### User insights at the heart of everything

Awesome products don’t happen by accident. Here are the ways we make sure your user loves you:

- an audit of comparable products so we know what you need to beat.
- a search of pattern libraries to find data-backed designs that have worked in the past.
- interviews with target users to understand their likes and habits.
- good old-fashioned experience from doing this a thousand times before.

#### Creating the initial concept

Our UX designers will bring you a draft user flow, with screens mapped against the journey so you can begin to imagine the experience. Wireframes will show how information, buttons and menus will be organized on the screens.

Hardware will be spec’d at this point, if required, for something like a kiosk.

#### Testing with users, early and often

We’ll run the draft journey by your target user for feedback. And they’ll have some. It’s important to test and adapt now, before you invest in full design. We’ll iterate and test until we get the right balance of user preference and practical business requirements.

#### Making your product beautiful

With the core journey in place, visual designers will turn those wireframes into a beautiful brand experience. And we’ll future-proof you by using a modular design system that can scale easily and affordably as your product evolves.

#### Rolling out a prototype

As a final pre-build step, you (and your users) will get to play with a mock-up. You’ll be able to navigate through the prototype to get a sense of the live experience. This is a great opportunity to make any final tweaks before your product goes into build.

---

[View on echobind.com](https://echobind.com/services/product-design)

---

# Prototypes

> Create something that feels like the real deal before investing time and money into development.

## Prototypes

Prototypes bring your product's vision closer to reality, serving as an interactive model that simulates the user experience and design of your app before development begins. At Echobind, we specialize in crafting prototypes that effectively bridge the gap between initial design concepts and the final product. By linking all the necessary screens together in Figma, we create a dynamic, clickable prototype that not only showcases what the real application might feel like but also provides an invaluable tool for user testing and clarifying interactive elements for the engineering team. Prototyping is an essential step in our design process, allowing us to iterate on designs based on feedback, ensuring that we're building a product that meets user needs and exceeds expectations.

#### What to Expect

When we start prototyping, we'll kick things off by discussing the purpose of the prototype and the use cases we need to address. This will determine fidelity and which flows we focus on. Usability testing scenarios usually drive the need for particular functionality in the prototype, but there might also be specific interactions you want to see in higher-fidelity or complicated flows that are best communicated with a clickable prototype. Once we've got your nod of approval on the use cases, we dive into the creation of your prototype using Figma. This stage is about linking those designs together to simulate the actual user experience and functionality of your app, offering you a tangible glimpse into what the final product will feel like.

Once we’ve created the first version of the prototype, we’ll send you a link for review, inviting you to explore and critique it. This iterative process allows us to refine and perfect the prototype, ensuring it meets your expectations and addresses the needs of your users. To further validate our design, we typically conduct usability testing. These sessions provide us with invaluable insights directly from your target audience, helping to fine-tune the prototype. Finally, once the prototype has been polished and approved, we prepare for a seamless transition to the development phase. We provide the engineering team with detailed documentation and the prototype itself, ensuring they have a comprehensive understanding of the product's design and functionality. This meticulous approach not only streamlines the development process but also ensures that the final product is a true reflection of your vision, optimized for user engagement and success.

#### How It Works

**Milestones**

- Kickoff Meeting to Define Use Cases
- Prototype Development
- Feedback Iteration: refining the prototype based on your feedback and, if applicable, usability testing.
- Final Review & Engineering Handoff

**Deliverables**

- A clickable prototype of all or part of the product, typically in Figma
- Recordings of any meetings and usability test sessions

---

[View on echobind.com](https://echobind.com/services/prototypes)

---

# Style Guides

> Document your visual identity with styles and components that you can reference and reuse.

## Style Guides

A style guide documents your product’s typography, color palettes, spacing, imagery, iconography, and UI components. It’s the best way to communicate your visual identity and bring consistency, longevity, and speed to the design of your product. Style guides help designers and developers adhere to the ideals of your brand and make it easy to implement your visual language across new screens and devices.

#### What to Expect

At Echobind, we create style guides after working with you on Design Concepts and some amount of UI Design. Our style guides are created in Figma using their features like text and color styles, variables, components, and variants. The size and scope of the style guide varies by project, but most include a color palette, typography, and some UI components at minimum.

![An example style guide from a previous client’s website redesign.](https://cms.echobind.com/assets/6f1b34d6-6296-41b2-a4ba-a48a616b41b5)
*An example style guide from a previous client’s website redesign.*

#### How It Works

**Milestones**

- Style Guide Creation
- Final Review

**Deliverables**

- Complete style guide in Figma

---

[View on echobind.com](https://echobind.com/services/style-guides)

---

# UI design

> Refine the experience of your product by applying a visual identity that delights your customers.

## UI Design

At Echobind, we focus on crafting interfaces that are not only visually appealing but also intuitive and efficient for users. Our approach to UI design emphasizes the creation of engaging and accessible experiences that reflect your brand's identity and meet your users' needs. Through a collaborative process, we establish a visual language that resonates with your audience and supports your brand and business goals.

#### What to Expect

UI Design is what most people think of as the main design phase. It’s the part of our process where we use color, typography, spacing, layout, iconography, and other design fundamentals to make your app look like the real thing. During this phase, our designers will take any previously created user flows, sitemaps, wireframes, and design concepts and use them to create the high-fidelity mockups of your product. This process usually takes place over a number of weeks depending on how many screens we need to design. We will usually design a set of screens for a given user flow, meet with you for review, iterate based on your feedback, and repeat this until the full app is designed. As part of this process, we usually create a style guide that includes the components, colors, and typography that will be used in product. If you already have an established brand, we’ll use it as the starting point and extend and adapt it to the needs of the product.

#### How It Works

**Milestones**

- Identify and Design Necessary Screens
- Iterative Reviews: we’ll meet with you regular to review progress and iterate based on your feedback
- Final Approval
- Documentation for Handoff to Development

**Deliverables**

- High-fidelity visual design with realistic copy, created in Figma
- Recordings and notes from any meetings

---

[View on echobind.com](https://echobind.com/services/ui-design)

---

# Usability Testing

> Get your prototype in front of users with realistic scenarios to see where they get stuck.

## Usability Testing

In the realm of digital product development, understanding how users interact with your product is not just beneficial—it's essential. We offer usability testing to assess and pinpoint how real users navigate and experience your app or website. This process not only identifies usability issues but also provides valuable insights into user behavior, preferences, and satisfaction levels. At Echobind, we take a systematic approach aimed at validating (or invalidating) design assumptions, identifying potential improvements, and ensuring that your product aligns with user expectations before you invest in engineering. By involving users directly in the testing process, we can uncover usability problems and make adjustments to our designs, saving you the money and time it might cost to correct issues once the product has been developed.

#### What to Expect

At Echobind, we offer usability testing as a stand alone service for existing products, as part of team augmentation, and as a part of any new app design. We use two different types of usability testing, moderated and unmoderated, depending on the needs of the project.

**Moderated Testing**

One of our design researchers handles every part of the process manually, from creating the testing script, sourcing and scheduling participants, to running the sessions. While moderated tests can be time-intensive, they offer the benefit of allowing the researcher to ask follow-up questions in real time resulting in richer qualitative insights. 

**Unmoderated Testing**

Participants are recruited using a third party tool, [UserBrain](https://www.userbrain.com/en/), and the sessions are unmonitored. Our researchers write a series of task scenarios and prepare a prototype. UserBrain then recruits participants from their pool of testers and we receive recordings of the sessions once they are complete. We use unmoderated testing the most as it’s the fastest and easiest way to recruit a larger number of testers and get quantitative insights about your product.

Once we’ve completed the test sessions, our team will spend time reviewing and analyzing the recordings and notes from each one. We’ll categorize insights into themes, capture quotes, and sometimes pull out short clips from the tests for particular trouble spots so you can watch how participants respond to various interactions and features.

Once we’ve completed our analysis, we’ll use the insights to make recommendations about the next steps. If we are testing a prototype we’ve created, we’ll use those insights to make design changes before finalizing things.

#### How It Works

**Milestones**

- Outline Usability Test Objectives
- Prepare Task Scenarios & Script
- Recruit Participants
- Conduct Test Sessions
- Analyze Recordings & Create Final Report

**Deliverables**

- Usability test plan
- Script and task scenarios
- Final report outlining insights, quantitative data, and our recommendations for next steps
- Recordings and notes from any test sessions

---

[View on echobind.com](https://echobind.com/services/usability-testing)

---

# User Flows

> Outline the core screens, features, and functionality for all of your users before considering layout.

## User Flows

User flows are a fast and low-cost way to map out the screens and actions a user will take when navigating your app. They’re are a great tool for visualizing everything you need your product to do without any of the distraction of UI elements and without any of the cost of actually coding something. Our team will create user flows before creating higher-fidelity artifacts like wireframes or prototypes so that we can clarify use cases and prioritize features that will add the most value for your business and customers.

**Benefits of user flows:**

- Iterate and test out multiple interactions before committing to a direction.
- Streamline design and development by visualizing every screen and action in one diagram.
- Provide a more accurate translation of design into functional features and reduce the chances of misinterpretation during the development phase.
- Easily visualize which features will likely take the most resources, making it easier to prioritize the next phase of development.

#### What to Expect

The goal of creating user flows is to craft a shared vision for your end-to-end customer experience. Typically our team will leverage information from a discovery workshop or kickoff meeting to understand your product use cases and feature requirements. Once we know who your users are and which features we need to design and build, a member of our design team will create the user flows in a Figjam or Whimsical file. Once we’ve created the first version, we’ll typically send you a loom video for review or schedule a meeting to address any questions you might have. We’ll then work with you and our strategy team to prioritize features and create a roadmap for design and development.

#### How It Works

**Milestones**

- Kickoff Meeting: we’ll discuss your product vision and feature requirements
- Diagram Review
- Iteration & Prioritization: we’ll often refine the user flows and use the final version to prioritize which screens we will design

**Deliverables**

- User flow diagram (typically a Figjam or Whimsical file)
- A loom walkthrough of the flows
- Recordings of any meetings or sessions

---

[View on echobind.com](https://echobind.com/services/user-flows)

---

# User Interviews

> Understand your customers and make sure you’re building a solution that meets their needs.

## User Interviews

User interviews are one of the research methods we offer to understand the needs and perspectives of the people who will be using your product. They’re one of the most direct ways to understand the motivations, expectations, and pain points of your target audience, and they can provide insights that lead to a better user experience and new ideas for innovation. Talking directly to your users and hearing what they have to say can boost confidence that you’re building the right product, generate ideas for new features, and give you a unique advantage over competitors.

**User interviews are a great way to:**

- Find out how your users are currently solving the problem your product is trying to solve
- Discover new problems or unknown pain points that lead to product innovation
- Understand in what ways your product is not meeting customer expectations
- Uncover why customers might abandon your product so you can improve customer retention
- Identify the exact language your users use so you can reflect their mental model in your product

As with all of our services, our focus is always on providing the most value to you on a timeframe and budget that fits your needs. We view user interviews as one of the most efficient ways to gather the information you need to improve your product.

#### What to Expect

Our user interviews consist of five moderated sessions with individuals from your target audience. We usually start by identifying each unique type of user who will be using your product and recommend conducting 5 interviews with individuals of each type. Before we conduct the interviews, our team will meet with you to discuss the goals for the interviews and the research questions that we need to answer. Once we understand your goals, we’ll work with you to recruit the right participants and schedule all sessions.

At Echobind, our user interviews follow a semi-structured process, which means our team will prepare a general script and set of questions that are flexible and allow for nuanced conversation with each participant. A member of our design team will moderate each session. If you’re available, you’re welcome to listen in on these sessions and debrief with our team afterward. If you’re unable to attend, you will have access to the recordings after the interviews are concluded.*

Once we’ve finished the interviews, our team will review our notes and transcripts to synthesize themes and patterns. We’ll write all of this up in a final report with recommendations for next steps.

*We only record sessions if a participant has given permission

#### How It Works

**Milestones**

Our user interviews often include the following milestones:

- Kickoff Meeting: we’ll meet with you to discuss goals and questions, participant screening criteria, and participant incentives
- Interview Guide Review
- Moderated Interviews & Team Debriefs
- Final Report Delivery

**Deliverables**

After user interviews, we typically send the following:

- Interview guide
- Recordings & transcripts from all sessions
- Final findings & recommendations report
- Notes from all meetings
- Recordings of all meetings

---

[View on echobind.com](https://echobind.com/services/user-interviews)

---

# UX Audits

> Identify the top usability issues in an existing app and create a plan for how to address them.

## UX Audits

Our UX Audits are a comprehensive review of your app or website to assess its usability and overall user experience. UX Audits are a great way to invest in UX because they allow our team to uncover problems that might be hindering your product’s growth without having to create any new design artifacts, conduct research, or run usability tests.

#### What to Expect

Our UX Audits are typically conducted by one of our designers and can be completed within a week. When we perform a UX Audit, we start by talking with you about your business goals and important use cases. Once we understand what your product needs to do for your business and your customers, we benchmark it against UX best practices and give you a detailed report with findings and recommendations. Our audits typically cover things like visual design, interaction design, layout, hierarchy, navigation, accessibility, and bugs. Our main goal is to give you actionable recommendations that will have an immediate, positive impact on your product.

#### How It Works

**Milestones**

- Initial Meeting: our team will meet with you to understand your business, product, and key use cases.
- Review of Findings: once our team has completed the audit, we’ll review the findings with you and answer any questions you might have.

**Deliverables**

After we’ve finished a UX audit, we typically send the following:

- Final findings and recommendations report
- Screen annotations (typically a Figma file)
- Recordings of any meetings or sessions

---

[View on echobind.com](https://echobind.com/services/ux-audits)

---

# Wireframes

> Iterate quickly, explore foundational UX ideas, and make good decisions about what matters most.

## Wireframes

Wireframes are the first step in the design process where we start to visualize full layouts and interactions as a user might experience them. Wireframes are intentionally low-fidelity. They look like rough, black and white blueprints of an app, and their main purpose is to communicate layout, functionality, and the overall user experience of an app without any of the visual design. This intentional low-fidelity allows us to iterate much more quickly on the interaction design without having to worry about pixel-perfection. Wireframes can also be used to test ideas with users or solicit feedback about technical feasibility from the engineering team.

#### What to Expect

When we create wireframes we use everything we’ve learned from the discovery workshop, user interviews, UX audits, and user flows to design a “rough draft” of the app. We’ll typically start with core features and flows, which we then review with you to refine and iterate. Once we’ve established the navigation patterns and overall structure for the app, we’ll then create wireframes for edge cases and error states. Sometimes we will use wireframes in usability testing to validate ideas before exploring visual identity. Based on feedback from you and your team and any feedback we collect from early usability testing, we’ll either 1) refine the wireframes or 2) move right into UI design and apply the feedback in the high-fidelity designs.

For apps that already have an established design system we can usually skip wireframes and skip straight to UI design.

#### How It Works

**Milestones**

- Identify and Create Wireframes for Necessary Screens
- Iterative Reviews: we’ll meet with you regular to review progress and iterate based on your feedback
- Final Approval

**Deliverables**

- Low-fidelity wireframes in Figma
- Recordings and notes from any meetings

---

[View on echobind.com](https://echobind.com/services/wireframes)

---

# Workshops

> Uncover new insights, explore the problem you’re trying to solve, and generate ideas together.

##  Workshops
Our design workshops are interactive and collaborative sessions designed to spark conversation, generate ideas, and synthesize what your team knows. We use workshops to set product vision, align your team, and cultivate buy-in. Our goal for each workshop is that everyone leaves with a shared understanding, feeling confident and excited for the project ahead.

#### What to Expect
Workshops can vary in content and length, but they all involve a series of activities designed to answer questions and extract knowledge about your business and product. A designer from our team will meet with someone from your team to plan the workshop according to the needs of the project. Once we decide on the format and duration, our team will plan the agenda and prepare materials for each activity. We’ll work with you to coordinate meeting times that work for those who need to attend, and then we’ll facilitate the whole thing.
Once the workshop has ended, our team will synthesize what we learned and send you a recording of the workshop along with the digital whiteboard and any other relevant artifacts.

#### How It Works

**Milestones**

Our workshops often include the following:

- Planning Session: our team will meet with your team lead to discuss the goals of the workshop and plan the content
- Demo of Existing Experience (if applicable)
- Workshop Session(s): Typically one or more 2 - 4 hour remote sessions

**Deliverables**

After workshops, we typically send the following:

- Digital whiteboard(s) from each session (typically a Figjam file)
- Recordings of all sessions
- Any notes and synthesis reports

---

[View on echobind.com](https://echobind.com/services/workshops)

---

# Software Engineering

> Create a product that powers on and on, no matter what you throw at it.

## How engineering works at Echobind
We go hard on execution. Engineering is hard-baked into the whole ideation and design process so that when it comes time – the build is seamless and the product delivers.

#### Focus on getting things done

Engineers help brainstorm the ideas and features we suggest for your product, so you know everything is doable before we start. And doable on time.

#### Stability is a non-negotiable

Users don’t like spinning wheels, so we put a premium on stability – with data that moves and screens that respond in real time, every time. No matter what crazy stuff your users try to do.

#### Built to evolve
You want a product that can flex and scale as new users, new use cases, and new technologies emerge. The build will leave the door open to add extra features, switch to bigger databases, move to faster platforms, or adopt new billing models. No matter how awesome your product is for today, we want it to be even better tomorrow.

#### Thinking of every detail

Tell us what you need and, yes, we’ll deliver that – but we’ll also think about the extra stuff that often gets neglected. Like the website where people download your app, for instance. Or the SEO tagging that helps people find that website. It’s about more than responding to briefs. It's about using our experience to deliver complete value.

---

[View on echobind.com](https://echobind.com/services/software-engineering)

---

# Zero to launched in weeks, not quarters.

Strategy, design, and engineering in one senior team from the first day. A patient scheduling platform in eight weeks. A mobile app in both stores in two months. An AI-assisted care platform with 11,400 users in its first quarter. Tell us what you are building and you will have a budget range within two business days.

## One team, start to launch

The people in the first workshop are the people who ship it. Strategy, design, and engineering aren't separate teams passing the project along, so what gets decided on day one is still true when the code goes out.

### 01  Decide what version one is

A workshop with strategists, designers, engineers, and a PM. Half a day or three, depending on the product. You leave with business requirements, user needs, technical constraints, a budget, and a schedule. Then a competitor audit and target-user interviews show where parity ends and the real opportunity starts.

[How we run strategy](https://echobind.com/services/strategy)

### 02  Design it, then test it while changes are cheap

User flows first, then wireframes, then visual design, then a working prototype. Each round goes in front of target users before the next one starts. That is what keeps the expensive changes out of the build.

[How we design](https://echobind.com/services/product-design)

### 03  Build it with the engineers who were in the room

Engineering sits in the workshop and the design reviews, so the build plan exists before the first commit. The product ships doing what you asked, and it is structured to take on the next user type and the next integration without a rewrite.

[How we build](https://echobind.com/services/software-engineering)

### 04  Launch it, then read the data

Launch is the start of the useful part. Post-launch analytics are in the original budget, so the first month of real behavior turns into the next set of changes instead of a new proposal.

## Shipped from zero

Three products that did not exist before. Every number comes from a published case study; timelines are kickoff to launch.

### 01  A clinic platform that books itself.

_Healthcare platform_

NOVO is CNY Fertility's patient onboarding and self-service scheduling platform: eight US locations, patients booking, rescheduling, and canceling with no staff in the loop. The legacy EMR had no API, so robotic process automation moves the data in. Ruby on Rails, Stripe, SavvyCal Appointments.

**Client:** CNY Fertility

**Kickoff to launch:** 8 weeks

**What changed:** 87% less admin time per patient, 40 minutes down to 5. Consult waits from over a month to two days. $10K+ saved a month.

[Read the CNY Fertility case study](https://echobind.com/work/scaling-fertility-care-self-service-scheduling-emr-automation)

### 02  A care platform with 11,400 users in its first quarter.

_AI-assisted care_

FreeBC is Upstream's digital contraceptive-care platform: a method comparison library, a recommendation quiz, telehealth and in-person care routing, an analytics layer, and Connie, an assistant constrained to a clinician-reviewed knowledge base. Two engineers and a PM took it from kickoff to a live Colorado pilot.

**Client:** Upstream

**Kickoff to launch:** 5 months

**What changed:** 11,400 users in the first three months. Quiz completers were seven times more likely to complete a care pathway.

[Read the FreeBC case study](https://echobind.com/work/expanding-contraceptive-care-access-ai-assistant-telehealth-platform)

### 03  An e-commerce marketplace for an industry that ran on paper.

_Marketplace_

O'Neil Software already ran the back office for record storage centers. Annex turned that network into a consumer-facing marketplace: shop for storage, pick a vendor, sign the service agreement, pay, and manage orders and invoices in one account. Next.js, Directus, tRPC, and Stripe, with shared components built once for web and mobile.

**Client:** O'Neil Software

**What changed:** The first consumer marketplace in record storage. Typed end-to-end contracts caught issues early enough that production deploys needed zero rollbacks, and the marketing team publishes content without an engineer.

[Read the Annex case study](https://echobind.com/work/oneil-software-annex)

## How we start

Tell us what you want to build. Within one to two business days you get the main technical and design hurdles in the idea, and a rough budget range for clearing them. No discovery call required to get a number.

Then, if we fit: a working session, not a proposal deck. Half a day to three days with the full team, deciding requirements, users, tech, budget, and schedule once. You leave with a plan anchored to your objectives: prioritized features, flagged technical requirements, a budget and a delivery schedule. If money is tight, we tell you what to cut and still hit the goal.

If the right answer is a smaller version one, or none yet, that is what you will hear.

## When it's done, it's yours

- **The repository, the infrastructure, the store listings.** Yours, not ours. Nothing about the build depends on keeping us around.
- **A codebase your own engineers can work in.** Annex's marketing team publishes without an engineer. That is the standard.
- **Knowledge transfer before we leave.** And a team that comes back for the audit, the upgrade, or the next version when you want it.

## Tell us what you're building

You will hear back within two business days with the hurdles we see and a budget range.

[Get in touch](https://echobind.com/contact)

---

[View on echobind.com](https://echobind.com/services/new-product)

---

# Fix what's broken. Keep what works.

Most products that feel broken don't need a rewrite. ezCater's site went from a 43 mobile Lighthouse score to 88. Bose's Home Speaker 500 trial campaign had been in development for 18 months when we arrived; it shipped two weeks ahead of schedule on the codebase they already had. Calibrate's progress screen was redesigned, tested with members, and handed to engineering in about four weeks.

Tell us what's not working, and don't hold back. You'll have a plan and a rough budget back within two business days.

## What's not working?

Five things we hear most, and what we did about each one for a client whose case study is published.

### 01  The site got slow and nobody knows why

We profile it before we touch it. On ezCater's site, the main thread was busy with JavaScript doing work CSS could do, images were missing width and height attributes, and Google Maps and a chat widget loaded before anyone had interacted with the page. Fixing those took the mobile Lighthouse score from 43 to 88.

[Read the ezCater case study](https://echobind.com/work/corporate-hospitality-aims-for-faster-food)

### 02  The project has been almost done for over a year

Bose's Home Speaker 500 trial campaign had been in development for 18 months. Our audit found UX side effects and security vulnerabilities, and we weighed a port to React. We kept the codebase instead, fixed the high priority bugs, and delivered two weeks ahead of schedule.

[Read the Bose case study](https://echobind.com/work/helping-bose-ship)

### 03  Users reach the screen and then don't do the thing

A screen can look finished and still fail its one job. Calibrate's progress screen graphed weight in pounds and gave members nothing to measure against their 10% goal. We prototyped a fix, tested it with Calibrate's own members over Zoom, A/B tested a second version, and handed a documented feature set to engineering in about four weeks.

[Read the Calibrate case study](https://echobind.com/work/redesigning-a-core-ux-flow-in-calibrates-mobile-app)

### 04  Payments work today and we're not sure they'll survive the launch

PlayOn! Sports processes over 300 transactions per second on Friday nights and was moving from Stripe's legacy Charges API to Payment Intents ahead of a launch. Our certified Stripe architects spent two weeks in their front-end and back-end code, checked PCI compliance and peak-load behavior, and reported what was sound and what to change.

[Read the PlayOn! Sports case study](https://echobind.com/work/helping-play-on-sports-scale-their-stripe-payments)

### 05  One feature is tangled into everything else

Brilliant for Educators lived inside Brilliant's core platform, spread across Vue 2 and Next.js code. We gave it a Next.js application of its own and lifted over the parts it needed; the brief was to do that without disrupting what was already working. Version 2.0 launched on schedule for the new school year.

[Read the Brilliant case study](https://echobind.com/work/empowering-educators-one-lesson-at-a-time)

## How we start

### 01  Tell us what's not working

All of it, and don't hold back. Within two business days you get a plan for what we'd fix first and a rough budget for doing it.

### 02  An audit by the people who'll do the work

Before anything changes, the engineers who will ship the fix read the code. Bose's initial audit discovered UX side effects and security vulnerabilities. PlayOn's took two weeks and covered their Stripe front end, back end, and webhook handlers. You get what's sound, what's broken, and the order to fix it in.

### 03  Fix it, then ship it on the date

Sometimes the answer is keep what you have and fix the priority bugs; that's what got Bose to launch two weeks early. Sometimes it's a new application that lifts the working parts out of the old one, as with Brilliant for Educators. Either way there's a date, and the work above is what shipping on it looks like.

### 04  What you have at the end

The fix in production and the findings in writing. PlayOn got a final report with actionable recommendations. Calibrate got a finalized prototype and a documented feature set for engineering. And a team that knows the codebase if you want to keep going.

## Tell us what's not working.

Slow pages, a screen users abandon, a payments migration you don't trust, a feature stuck inside the monolith. You'll hear back within two business days with a plan and a rough budget.

[Tell us what's not working](https://echobind.com/contact)

---

[View on echobind.com](https://echobind.com/services/improve-an-existing-product)

---

# Engineers who join your team and ship.

Axios embedded Echobind engineers for eight months to ship a React Native app on a deadline their in-house team didn't have the capacity to hit. Univision and Teladoc Health have done the same.

The engineers and designers you talk to are the ones who join your team. Tell us where the gap is and you'll have a staffing plan and a rough budget within two business days.

## How embedding works

1. **Map the gap.** Your requirements and a map of your in-house coverage: who's on what, what's covered, what isn't. Sometimes the gap is capacity. Sometimes it's a specialty like React Native, voice, or a payments integration. That decides who joins and for how long.
2. **They join your team.** Your repo, your standups, your review process, your PM tooling. Our pull requests go through your review queue like anyone else's until your team decides otherwise.
3. **They ship inside your constraints.** The work fits your architecture and your operations. Changes stay as small as the job allows, and the people your product touches, like a call center, are part of the plan rather than surprised by it.
4. **Your team owns it after.** Handoff is planned from the start, so your engineers can keep working in the codebase without us. Abby Care's own web developers now contribute to the app we built, and they brought us back months later for an audit and an upgrade. You keep a direct line to Echobind the whole time if you need to switch people or ways of working.

## Who joins

### Engineers

Web and mobile, front end and API. React and React Native are the daily stack; Stripe, Medplum, and Alexa integrations are on the case-study pages.

**Stack:** React, React Native, Next.js, Expo, Stripe

### Designers and UX

Product designers who take one screen or one flow from problem to engineering spec. At Calibrate that was a prototype, testing sessions with their members, and a documented feature set for engineering in about four weeks.

**Stack:** Figma, Prototypes, Member testing

### Project management support

For when the bottleneck is coordination as much as code: ticket triage, build requests, and keeping the queue honest inside your PM tooling.

**Stack:** Asana

## Three teams we joined

Three engagements inside other teams' repos. Every name and number comes from a published case study.

### Axios: Eight months inside the Axios engineering team.

**The gap:** A tight deadline for new iOS and Android apps, and no in-house capacity to build them while supporting the core infrastructure.

**What changed:** Embedded engineers built app features, contributed to the news feed API, and set up post-launch monitoring. The apps launched on time and received thousands of four- and five-star ratings.

[Read the Axios case study](https://echobind.com/work/delivering-news-in-a-flash)

### Univision: Onboarded fast, then trusted with the whole front end.

**The gap:** After acquiring VIX, Univision needed a proof of concept of the redesigned PrendeTV app across iOS, tvOS, Android, Android TV, and Fire TV, and needed whoever joined to onboard quickly.

**What changed:** Our engineers sat in the PrendeTV team's daily standups, started with the Video On Demand section in React Native, and were eventually trusted to review and approve the team's own pull requests. The scope grew to the whole front end including live TV. The app shipped on the App Store, Google Play, Fire TV, and Roku, and we still maintain it.

[Read the PrendeTV case study](https://echobind.com/work/introducing-20-000-hours-of-content-to-prendetv)

### Teladoc Health: A voice telehealth visit, launched with Amazon.

**The gap:** A patient should be able to start a telehealth visit through an Alexa device, without disrupting the call center representatives who handle those visits today.

**What changed:** We worked through their stack with engineering, product, and call center teams so every change was limited to what the voice flow required. It went live with no significant glitches, and Teladoc Health and Amazon announced it together.

[Read the Teladoc Health case study](https://echobind.com/work/teladoc-building-the-future-of-healthcare-with-voice-assist)

## Two business days to a staffing plan.

Tell us the gap, the deadline, and the stack. You get a proposed plan (which roles, for how long, attached to what) and a rough budget.

Questions about your stack get answered by the people who will do the work, because they're the ones on the call.

## Tell us where the gap is.

Deadline, specialty, or both.

[Tell us what you need](https://echobind.com/contact)

---

[View on echobind.com](https://echobind.com/services/power-up-your-team)

---

# Strategy

> Nail the thinking behind your product so it delivers real value for your users, and your organization.

## How strategy gets done at Echobind

Let’s get that idea out of your head and into an organized, buttoned-down plan. We’ll work alongside you to identify the priorities and make informed, data-driven decisions.

#### Tell us what you’re working on

Send us what you’re working on and we’ll help focus your thinking on the most important decision points. If you find us helpful, we can jump into a workshop to flesh things out. [Get in touch](/contact).

#### Workshop your priorities with experts

Discuss your key goals and deliverables with our strategists, designers, engineers, and project managers. They’ll help distill a set of key priorities and get to work on a plan.

##### Strategy delivery (with all thinking explained)

Your strategy will hit the key points we agreed on in the workshop, with the background and rationale for every recommendation. Here’s what you get.

**Product strategy, including:**
- user research and competitor analysis to inform specifications and design
- prioritization of features so you can make smart decisions
- engineering recommendations so your product can grow and evolve

**Technology choices, including:**
- tech recommendations that suit the scale and life-stage of your product
- flexible architecture and seamless integrations
- advice on AI tools and risk management

**Prioritization and budgeting, including:**
- prioritization of features to support smart planning
- resource recommendations to help max out your budget
- end-to-end scheduling for clarity on milestones

**Post-launch plan, including:**
- post-launch analytics and reporting
- data-driven optimization recommendations
- no-surprises – with optimization included as a line in the original budget

#### Project Management

A comprehensive strategy has lots of moving parts. You’ll have complete visibility of progress throughout. And a project manager who’s up-to-date on all workstreams, at all times.

---

[View on echobind.com](https://echobind.com/services/strategy)

===

# Work

# Launching a First-of-its-Kind SaaS Business: Clerestory

> Echobind built and launched Clerestory, a SaaS company that simplifies invoice creation for kitchen and bath remodeling.

---

[View on echobind.com](https://echobind.com/work/clerestory-saas-rebranding-marketing-website-and-tradeshow-materials-support)

---

# Introducing 20,000+ Hours Of Content To PrendeTV

> Univision, a leader in the Spanish TV marketplace, took on the challenge to re-envision PrendeTV into a more robust AVOD-free media streaming service after acquiring VIX in 2021.

The Problem
-----------

In order to incorporate the newly acquired content from Vix, the design and engineering teams at Univision worked in tandem to update the PrendeTV app. Univision looked to Echobind to augment within their existing dev team, and assist them in building a Proof of Concept (POC) of their newly redesigned media streaming app with support on iOS, tvOS, Android, AndroidTV, and FireTV platforms. Specifically, our initial directive was to build out the Video On Demand (VOD) section — think Netflix — for Apple and Android mobile devices. POC app completion needed to happen relatively quickly to stay within beta launch deadlines, while also allowing enough time for proper Quality Analysis, so our team needed to onboard quickly and immediately get working on the new design direction of the app.

Client's Plan
-------------

With a successful launch of PrendeTV earlier this year in March, the integration of VIX content will allow for Univision to offer a robust selection of the most popular Spanish-language programming available to viewers in the U.S., Mexico, Brazil and many other countries.

Echobind participated in daily meetings with the Univision team, providing build updates and recommendations, while getting directives on what our team should focus on week to week.

Traps and Challenges
--------------------

Collaborating with other dev teams often requires us to tactfully work through a few technical challenges. Below are some that our team encountered and overcame:

*   Building for tvOS and Android TV using React Native
*   Implementing the SDK for Fire TV testing on actual Fire TV Stick devices
*   Outdated/version locked packages which were tied to unknown pieces and complexity of tracing the flow of data/props through components.
*   Prior to getting Code Owner privileges for the repo, PRs would tend to queue up for Univision review as we were introducing new pieces of the build at a fast pace.
*   Getting feedback, sending builds to testflight/Android's version, and making sure the most up to date branches have been sent out for testing via Applause. We also needed access to SDKs that had components or functionality that we could not change otherwise.
*   Adding Auth: [iOS has particular standards](https://www.nytimes.com/2021/09/13/technology/apple-software-update-spyware-nso-group.html) if content is meant to be locked behind an account registration and Univision initially wanted a particular auth flow that made the account feature difficult to find.
*   Making sure the team is equipped with the necessary physical devices to test on, which helps navigate issues on emulator/simulator devices vs physical devices.
*   Translations: Team assisted in translating Invision designs from Spanish to English and Portuguese.

The Fix
-------

Echobind helped Univision build out the Video On Demand section of the PrendeTV mobile, TV and web app by transforming static designs into a fully functional React Native UI. Beyond our initial assignment of VOD, the collaboration grew into our team supporting all aspects of the front end build, including VLL (think live Cable TV). The team also performed rigorous QA testing of all versions of the app across different devices, especially when making any bug fixes or introducing additional features. Beyond the engineering scope, we helped their PM with managing tickets in Asana and triaging incoming build requests. Crucial to our joint success was transparent communication on features and bug fixes.

Signs of Success
----------------

Our joint efforts led to not only a successful proof of concept, it blossomed into full adoption and was made available in the Apple App Store, Google Play Store, and for TV platforms including Fire TV and Roku. We continue to maintain the app through bug fixes, new feature implementation, and A/B testing through Google Firebase. The app has been downloaded thousands of times, with users spanning from the U.S. through all of Latin America, and even in Portugal.

---

[View on echobind.com](https://echobind.com/work/introducing-20-000-hours-of-content-to-prendetv)

---

# Streamlining the Billing Process

> We built a seamless way for CNY staff to create complex financing plans and then allow patients to agree to finance terms and make a manageable monthly payment using Stripe.

CNY Fertility is on a mission to provide the most affordable fertility care in the industry. Echobind built CNY Fertility’s new Fertile Financing Platform for patients and the CNY Fertility staff. What we built was a seamless way for their team to create individualized financing plans. Their patients are able to review and agree to financing terms, review their balances, and make payments in a variety of ways.

![Summary of a patient invoice for CNY fertility.](https://cms.echobind.com/assets/eb06e2c1-5ae3-4a49-acbd-0f780418da3f)

The Concept
-----------

CNY Fertility’s goal was to remove the manual processes for enrolling patients into payment plans. Their team spent a significant amount time setting up each patient's financing terms. This included applying line item discounts, re-calculating monthly payments and capturing payment information. Automating this manual work would allow team members to spend more time with the patients, improve CNY Fertility's cash flow and give patients more control. And by bringing all payments into a single system, CNY Fertility could better track data on their financing plans and patient enrollment. This presented three interesting challenges for our team.

Challenge #1 - Data Migration
-----------------------------

Echobind's first challenge was to migrate CNY Fertility's customers from their existing payment processor. We wanted this to be a seamless process. Stripe offers several options to help migrate data, but we wanted CNY Fertility to have more control over the migration process. We created a tool in their billing platform to allow admins to migrate patients to the new system if it fit their migration criteria. This gave CNY Fertility granular control over the migration process. Patients received an email about the migration and could review and accept their new payment plan. Upon acceptance, patients securely store their payment information on Stripe. CNY Fertility staff members then received a notification about the migrated user and cancelled their old payment plans.

![Online form with fields to add a patient's information and payment for services.](https://cms.echobind.com/assets/d8c2b385-d7af-4378-bcc1-613fecd77078)

![Online form summary of costs with options to remove line items.](https://cms.echobind.com/assets/c0a56478-16c1-4006-8304-21edc66fa638)

Challenge #2 - Facilitating Financing
-------------------------------------

Stripe provides excellent options for Buy Now, Pay Later through Klarna or Affirm integrations; however, because CNY Fertility provides its own financing, those weren’t viable options. Luckily since Stripe’s list of products is so robust, approaching this problem in another way was feasible. To apply the Buy Now, Pay Later concept with CNY’s own financing, the EB team structured Stripe Subscription Schedules so that all outstanding funds are calculated and collected over a number of iterations equal to the terms the patient selected during checkout. For example, suppose a patient chooses to finance their treatment for six months. In that case, a Subscription Schedule is created for six iterations for the total amount of the treatment, divided by the number of iterations.

*   Build features for the new mobile apps
*   Contribute to their news feed API
*   Run tests and troubleshoot complex performance problems
*   Set up monitoring tools to track and manage post-launch performance

![Online form with a sliding scale showing amount for monthly payment and what is due today.](https://cms.echobind.com/assets/a39eb5a4-687a-4b0a-927a-32091aca0155)

Challenge #3 - Managing Payment Plans
-------------------------------------

Our mission was to automate much of the payment and finance process. One ask from CNY Fertility was to keep as much of a human touch as possible when interacting with customers. This is a great reminder that software is made for humans. And because life happens, it was critical for us to add tooling that allowed for payment adjustments. CNY Fertility needed the ability to change payment terms at any time for any reason. Echobind built the ability for admins and patients to adjust – or remove – the down payment. When generating quotes, admins can apply line-item discounts. And when patients want to pay off the remaining balance, the portal can apply a discount automatically. Finally, admins can use the portal to add payments made when a patient pays with cash at a clinic. Any cash payment made will reduce future monthly invoices. Everything described here flows through Stripe's Payments, Subscriptions and Invoices products.

The Outcome
-----------

CNY Admins now have consistency in quoting practices, available services, service prices, discounts, legal terms, and payment options. Creating a quote is as simple as choosing line items, applying discounts, and clicking ‘Send’. The system still gives them the flexibility they need to offer discounts or waive down payments on a case-by-case basis. Patients now have an easy, streamlined way to view quotes, review terms, reject quotes, or accept and enroll in a monthly payment plan. Their billing portal shows them their monthly payment and outstanding balance at a glance, so they never need to wonder about the state of their payment plan. As of this writing, a number of patients have successfully paid for services through the new portal, with some of those opting for a monthly payment plan. As the portal continues to roll out, even more patients will be onboarded and enjoy the convenience that the patient dashboard provides. And CNY is still able to preserve the personal interactions and support they give to their patients through every step of their treatment, which is what makes them stand out in their industry.

---

[View on echobind.com](https://echobind.com/work/cny-fertility-stripe-billing-implementation)

---

# Teladoc Health: Building the Future of Healthcare with Voice Assist

> Teladoc hired Echobind to develop an Amazon Alexa integration for telehealth visits with voice and video. This new workflow aims to improve compatibility with voice assistants.

---

[View on echobind.com](https://echobind.com/work/teladoc-building-the-future-of-healthcare-with-voice-assist)

---

# Hoag Healthy Together

> We helped Hoag Hospital create a single application to encompass all of the different patient journeys.

Based in Orange County California, Hoag Hospital is a healthcare company aiming to revolutionize what it means to be a hospital by providing state of the art amenities and forward thinking programs that bring together all there is to being healthy.

The Concept
-----------

Hoag's goal was to change the way and support patients. We wanted to expand upon a patients journey and incorporate their entire healthcare experience into one mobile application. Regardless of what type of patient they were at this moment, maternity, pediatric, or general, we wanted the experience to be curated and complete.

The Problem
-----------

Hoag hospital is revolutionizing what it is to be a hospital and building an app to accompany that mentality was a challenge. We were especially mindful that this app would engage patients at a variety of stages in their healthcare journey (general care, maternity, pediatric to start) and we wanted to be sure the app was useful and engaging to keep them coming back. On top of this we wanted to create a curated experience for each patient with a WordPress backend.

The Solution
------------

We ended up understanding a patient as always being on the Hoag journey as a whole, but that their journey changes based on their current healthcare needs. We designed and built a solution which would allow use of the application without even logging in. You can see all that Hoag has to offer including classes, news, and care options. Once logged in the users experience begins to align with their personal journey. They can begin registering for classes and events. They also gain access to what we have deemed Healthcare Modules. These modules are where the curation of the journey really begins.

Users will access the module they are experiencing either by themselves or by a permission given to them by their doctor. Once they have activated a module their entire application experience begins to change. The home screen will dynamically change based on the patients journey; with maternity information during pregnancy, such as how far along you are and how big your baby might be at this point in the pregnancy.

The Outcome
-----------

We ended up with an app that engages patients on multiple levels. Patients are able to sign up for classes at Hoag such as yoga or pilates. They can schedule these for either in person or virtual. When a virtual class was scheduled a YouTube live link would be provided in the mobile application and once the class time has passed it could be converted to an on-demand class to watch at the patients leisure. We also used this functionality to allow patients to sign up for flu shot time slots which created an incredibly smooth process and actually had more flu shot signups then previous years. We have a fully dynamic mobile application platform that allows for scalability and adaptability.

---

[View on echobind.com](https://echobind.com/work/hoag-healthy-together)

---

# A Change Platform

> Dough is an online platform giving emphasis to women-owned businesses, and empowering their shoppers to become #WalletActivists

Dough is an online platform giving emphasis to women-owned businesses, and empowering their shoppers to become #WalletActivists. They empower members to shop in women-owned businesses by incentivizing them with savings.

The App's Job
-------------

Echobind had the opportunity to help create a membership platform for Dough's paid subscribers. The platform allows paid-members to view discount codes and other member benefits. It also allows Dough admins to curate promo codes and show/hide content from their Instagram feed.

The Problem
-----------

One of Dough's major goals was to create a membership platform that integrated data from Squarespace so they could easily manage content and avoid building out a custom CMS. Dough determined early on that Squarespace couldn't meet their needs for paywall and subscription-based membership, but it was vital that their team could add new content easily to both their marketing site and the to-be-built membership platform.

The membership platform needed to allow paid users to access promotional codes from partner sites. Dough members also needed direct access to a concierge via an in-app chat.

Our Solution
------------

Our developers joined Dough as the Engineering department while creating the first version of the Dough platform. We later helped them interview and onboard their first engineering hire.

One of our major goals was to build a cost-effective solution, that would also easily scale with any traffic Dough could throw at it. We knew that Browser extensions and a potential mobile app were on the roadmap for the future, so we prioritized GraphQL for the API layer to make these integrations easier when the time was right.

Using designs provided by Dough, our team leveraged React, Node, GraphQL, and Serverless technologies to develop a stable and cost-effective foundation for the future. Dough's marketing site (built on Squarespace) powers much of the content.

We:

*   Built a GraphQL API in Node that syncs data from Squarespace every 5 minutes. This ensures stability and performance. Data is persisted to a Postgres database.
*   Built the frontend in React using Next.js.
*   Used Emotion as a modern CSS-In-JS approach to style components.
*   Connected with Smooch to enable Concierge chat/SMS.
*   Leveraged Stripe for subscription plans and payment processing.
*   Added Sentry and Amplitude for error and event tracking.
*   Created an admin tool that allows Dough to control individual promotional codes for brands and products. It also allows admins to show or hide content from an Instagram feed.

Eventually, [**Dough successfully sold their company to Juniper**](https://www.prnewswire.com/news-releases/ladies-lets-rise-introducing-dough-a-new-website-that-makes-it-easy-to-shop-women-owned-and-harness-the-power-of-wallet-feminists-300862429.html) and they merged their technology and team. We're incredibly proud of the work we did to help the Dough platform succeed.

![Screenshot of Dough's "Become a member" text and button.](https://cms.echobind.com/assets/d6d52154-655f-4251-b42b-f8f705cbd31f)

---

[View on echobind.com](https://echobind.com/work/a-change-platform)

---

# Helping PlayOn! Sports Scale Their Stripe Payments

> PlayOn! Sports has the largest high school sports ticketing solution in the United States. With the help of Echobind's Stripe architects, they were able to scale up their Stripe implementation with confidence.

[PlayOn! Sports](https://www.playonsports.com/) has the largest high school sports ticketing solution in the United States. At peak times, such as Friday night football games, they are processing over 300 transactions per second using Stripe’s Charges API.

The Charges API is now considered legacy and Stripe recommends using the Payment Intents API to charge, save, and authenticate cards. PlayOn’s engineers have been working to migrate their codebase to the new Payment Intents API in preparation for a new launch of their ticketing solution.

When you’re processing as many transactions as PlayOn! does, there’s a lot of risk involved in making a change like this. So as their engineers neared completion of development, they worked with Echobind to help audit their front-end and back-end codebases. Echobind provided two of our [certified Stripe Professional Architects](/partners/stripe) to perform the audit.

## Focus of Audit

After an initial meeting with the PlayOn team to understand their business and concerns, it was agreed the main focus of this audit revolved around the following questions:

- Does their codebase correctly implement the Stripe Payment Intents flow?
- Does their codebase follow Stripe’s security best practices?
- Does their codebase correctly fulfill orders after a successful payment?
- Will their codebase scale with their peak volume of 300+ transactions per second?
- Is their codebase PCI compliant?

## Performing the Audit

Over the course of two weeks, our architects traversed PlayOn’s codebases. Our approach was to review the different pieces of the Stripe implementation:

- [Payment Element](https://stripe.com/payments/elements) to build the payment user interface in web and mobile applications
- [Stripe Webhook](https://stripe.com/docs/webhooks) handlers for order fulfillment
- Creation of Payment Intent and handling thereafter

## Results of the Audit

After reviewing their codebases, we compiled our findings into a final report that we could present to the PlayOn team. We were able to reaffirm the areas where their implementation was sound and also make actionable, meaningful recommendations that will help reduce risk and ensure their launch is successful.

We are excited to see PlayOn’s ticketing solution transition to the new Payment Intents API that will provide a much better user experience for their users and an overall upgrade to their Stripe implementation.

---

[View on echobind.com](https://echobind.com/work/helping-play-on-sports-scale-their-stripe-payments)

---

# Delivering News in a Flash

> When you’ve already reinvented news for the web, and then you have to do it again for mobile. Twice.

The Problem
-----------

Axios’s news site had won legions of fans for their ‘to-the-point’ editing and formatting for the web. But the browser experience wasn’t working for mobile users.

The Axios Plan
--------------

With a growing user base that increasingly demanded news on the move, Axios needed to offer a native mobile app. That app had to allow users to follow favorite topics, and browse breaking news.

Traps and Challenges
--------------------

Axios gave themselves a tight deadline to create a new product for iOS and Android. The React Native framework would allow them to build both apps at once, but Axios didn’t have enough in-house capacity to pull it off while also supporting their core infrastructure.

How We Helped
-------------

Echobind embedded three full-stack engineers with Axios for 8 months. We helped:

*   Build features for the new mobile apps
*   Contribute to their news feed API
*   Run tests and troubleshoot complex performance problems
*   Set up monitoring tools to track and manage post-launch performance

Signs of Success
----------------

The new apps were launched on time and [received thousands of four- and five-star ratings](https://apps.apple.com/app/apple-store/id1464917429?mt=8). It's also loved by many Echobinders—it certainly never hurts to love the products you work on.

---

[View on echobind.com](https://echobind.com/work/delivering-news-in-a-flash)

---

# Klem Connect: Warehouse Order and Product Tracking

> We built UB Klem a web application called Klem Connect to track warehouse workflows from the calendar, order, and product level.

**We built UB Klem a web application called Klem Connect to track warehouse workflows from the calendar, order, and product level.**

UB Klem builds custom-ordered furniture for restaurants and other organizations. Each day, UB Klem ships 5-12+ orders with up to 30 unique products that require custom piece assembly. Lucky for UB Klem, they have a strong supervisor team with deep-seated knowledge of warehouse workflows and an ingrained awareness of daily departmental needs. Historically, order tracking happens solely in these supervisors’ heads and via pen and paper, with different documenting methods. Unfortunately, this has made expanding warehouse production, training new supervisors, and covering shifts difficult, not to mention the room it leaves for human error.

Recognizing this problem, UB Klem tested a custom kanban board to track projects. This created standardized outputs where supervisors could see the same lists of order due dates and product whereabouts. The downside was that feedback couldn’t be given in real-time and had to be entered manually at the end of the day by a front-office employee instead of the supervisor operating the manufacturing equipment.

To resolve the issues UB Klem was encountering, Echobind built a custom web application to track warehouse workflows from the calendar, order, and product level. The idea behind this software is that each supervisor can have an iPad in their department and can easily check off when a product enters and leaves their station.

The Concept
-----------

The Echobind team built a custom web app solution that allows supervisors to see real-time order data on a calendar view that highlights: 
- shipment due date and customer details. 
- order priority levels.
- new and in-progress order statuses.

![](https://cms.echobind.com/assets/2492a22b-5b99-4e3b-adef-65496fa607c3)

UB Klem supervisors can search and filter their calendar view to only see orders important to them.

For UB Klem, filters work in an OR rather than AND fashion in order to pull as many relevant orders as possible. Many filters will work to exclude as much as possible to narrow down on a specific set of information, but UB Klem found it more valuable to pull more information rather than less.

Customer names are also pretty standard across the board, so instead of just having customer names within the search function, we placed in a filter so that the CEO of UB Klem could get better overviews of progress for specific clients.

Users can access detailed order information from the calendar, set order priority, and see where each product in an order is in the UB Klem warehouse. Supervisors can now track when an order’s individual products are in their department and when they leave their department.

![](https://cms.echobind.com/assets/5703f6ef-ca92-411b-a322-85b8349e24f3)

UB Klem’s goal was to standardize warehouse workflows and better understand the status of an order at any given time. Klem Connect offered a way for UB Klem supervisors to document what products were in their department in a central and transparent place. This presented three interesting technical challenges for the Echobind design and engineering teams.

Challenge #1: Development - Syncing data between Microsoft Dynamics and the app
-------------------------------------------------------------------------------

UB Klem tracks client details, order data, and shipping information in Microsoft Dynamics. Before implementing this software, UB Klem would copy information from Microsoft Dynamics, type it into a calendar program, and print copies for the supervisors.

In order for Klem Connect to have up-to-date information on each order, we would need to sync with Microsoft Dynamics. Rather than allow changes from Klem Connect to transfer into Dynamics, and potentially break something on that end, we opted to only allow information to flow one way, from Dynamics into Klem Connect, and not the other way around. This greatly simplified our data flow, eliminated the risks around pushing data into Dynamics, and saved some project time, not having to create the UI elements needed to manage Dynamics data in Klem Connect.

Challenge #2: Design - Products do not move linearly through departments
------------------------------------------------------------------------

One assumption before building Klem Connect was that products would move linearly through the factory. This was not always the case; not only do products take different paths through the warehouse, but the individual parts of a product can be in multiple departments at the same times. This led to a complicated discussion about the granularity needed while avoiding swamping the users in too much complexity. Instead of tracking every piece of a product, we opted for allowing users to indicate that a product is in multiple places simultaneously. We also built the system in such a way that future iterations will allow us to track products and their parts more granularly.

We implemented a system to track the department status of each product in an order by attaching a list of departments to it and providing radio buttons for users to indicate the current status. This allowed for granular tracking of each product's movement through the warehouse without overwhelming users with complexity.

We ensured that status updates to one product would not affect the tracking of other products. This was achieved by associating a list of departments with each product in an order so that the status of each product could be updated individually without changing the status of other products in the order.

Challenge #3: Dev - Filters need to maintain until users log out
----------------------------------------------------------------

Since many supervisors only need to look at their department, we implemented a filter system that allows users to filter by customer name, department, and order priority, and save those filter selections until the user logs out. This enabled users to easily filter and find the specific orders they need, improving warehouse operations' efficiency and organization. Maintaining filters until the user logs out was critical to avoid having supervisors set filters every time they navigate to another page.

Now supervisors in the rough mill department can set a filter to only see the orders they still need to complete and, at the same time, the office staff can easily search for all the orders of a single client.

Challenge #4: Development/Design - Drawer statuses
--------------------------------------------------

Depending on the progress that a given department made with a product or what needed to happen with a given product, it was likely that a supervisor no longer needed to see something before other people. Once they no longer needed to see a product within an order, they might never need to see it again. We made it so that supervisors could close the ‘drawer’ of a product if they no longer needed to see it. In the below image, the user has closed the status drawer of the top product but they still have the bottom status drawer open.

The challenge came when we needed to save the opening and closing of a given drawer for each supervisor and make it so that a supervisor opening or closing a drawer did not open or close the drawer for someone else. Saving these individual actions became necessary since many orders might have 10+ products, but a given supervisor might only need to interact with 1 or 2 of them. Leaving the drawers open or or not saving their status would make scrolling through the list of products more burdensome and time consuming than if they could easily navigate to the product with which they needed to interact. We also chose to default products to being open since every supervisor would need to interact with a given product at least once, even if that interaction was to indicate that it was not applicable to their department. Ultimately Open → interact → Close is longer more demanding than Interact → Close, especially for orders with 20+ products.

![](https://cms.echobind.com/assets/ca3d4748-bf99-4002-8caf-8135ee18f05f)

The Outcome
-----------

When UB Klem first came to Echobind, they needed a way to track orders and products without a complex paper system or requiring a few individuals to have all of those order status details in their heads. They wanted their supervisors to be able to take time off without blocking the flow of products through the warehouse. And they wanted to make it easy to train new team members without them needing to learn the complex flow of products outside the departments they work in. Klem Connect provides a solution for these needs with centralized, transparent, and easy-to-use tracking of products and orders through UB Klem’s custom production warehouse.

---

[View on echobind.com](https://echobind.com/work/klem-connect-warehouse-order-and-product-tracking)

---

# Corporate Hospitality Aims for Faster Food

> When your core service depends on your website, and it starts to slow down, you pull out all the stops.

The Problem
-----------

ezCater makes it easy for businesses to find and hire hospitality professionals for corporate events. But their users were experiencing slow site load times. Meanwhile, the company was also struggling to customize follow-up communications.

ezCater's Plan
--------------

To continue their meteoric growth, ezCater needed to overhaul their top-of-funnel experience.

*   A faster site would be a better experience for new users, and it would increase brand visibility through improved SEO (search engines penalize slow-loading websites)
*   A more flexible email marketing platform with easily accessible analytics would allow ezCater’s marketers to optimize communications with prospects and customers.

Traps and Challenges
--------------------

Site speed – lazy loading images and videos, plus poor performance with screen readers meant ezCater’s website scored low for accessibility and SEO on the lighthouse scale (getting 40s and 50s out of 100).

Email marketing – the existing Action Mailer platform was too hard for marketers to use. It prevented them from trying new templates, or accessing performance metrics like CTR.

How We Fixed Things
-------------------

Echobind sped up the site by:

*   switching from JavaScript to CSS, which reduced the main thread work
*   setting a width and height for all images
*   adding unique IDs to elements
*   deferring Google Maps and Liberty Chat until users interacted with the site
*   pre-connecting to Google Fonts
*   adding aria labels to elements for screen readers.

And we migrated their Action Mailer system to SendGrid, which made it easier for ezCater’s marketers to implement new email designs and layouts. It also gave them analytics tools to assess and iterate those new approaches.

Signs of Success
----------------

ezCater’s lighthouse score has increased to well over 90 for desktop and 88 on mobile (up from 56 and 43). Meanwhile the marketing team is working in SendGrid and running key A/B tests on core communications.

---

[View on echobind.com](https://echobind.com/work/corporate-hospitality-aims-for-faster-food)

---

# Redesigning A Core UX Flow In Calibrate’s Mobile App 

> Echobind worked with the team at Calibrate to quickly augment and improve the progress screen, adding a visual indicator of a member's 10% weight loss goal.

Calibrate is a healthcare startup that is changing the way the world treats weight. As part of this mission, Calibrate focuses on a 10% weight loss goal rather than a number of pounds. 10% helps members work toward a clinically significant, realistic goal that is relevant to their personal journey rather than an arbitrary and impossible number based on a BMI chart.

Challenge
---------

All of Calibrate’s marketing clearly communicated this 10% weight loss goal philosophy in order to set program expectations for members. Unfortunately, the messaging in the app fell short of reinforcing their philosophy. They didn’t create a place for a member to see their 10% weight loss goal or measure their progress in relation to that goal.

<figure>
  
![](https://cms.echobind.com/assets/0ef1d95a-7257-45d1-98a8-eb604b32219a)
<figcaption>Here’s what the progress screen looked like before we got to work. The graph provides an overview of weight loss, but only in pounds, and it doesn’t do a good job of helping a member stay focused on their goal or see a summary of their progress.</figcaption>
  
  </figure>

Solution
--------

Echobind worked with the team at Calibrate to quickly augment and improve the progress screen, adding a visual indicator of a member's 10% weight loss goal.

Here’s a summary of the work we did:

*   Created a high-fidelity prototype
*   Wrote task scenarios for testing
*   Wrote user interview questions
*   Recruited participants from Calibrate’s existing member base
*   Scheduled and conducted sessions remotely via Zoom
*   Summarized our findings, finalized the prototype, and documented the feature set for engineering

…all within the span of about four weeks.

With the deadline for a handoff to engineering quickly approaching, we needed to work fast. We decided to run hybrid user sessions that included user interviews combined with usability testing the solutions we aimed to develop.

We wanted to get a sense of how members were conceptualizing weight loss goals to ensure we were in the right ballpark, but we also needed to test early ideas and get feedback on real solutions given the time constraints.

User Research
-------------

We structured each session so that members’ answers to the interview questions weren’t biased by their use of the prototype. We sent a Figma prototype link to members and walked them through the task scenarios only after they had answered the interview questions.

<figure>

![](https://cms.echobind.com/assets/f9623928-b785-489c-b977-8d9db0e3a72f)

<figcaption>Here are the interview questions we used. Warm-up questions are used to build rapport, while the core interview questions are used to uncover answers to the main research question.</figcaption>

 </figure>
  
Rapid Prototyping
-----------------

We started out with a single prototype to get some initial feedback but quickly realized that members were unable to complete one of the core tasks because the interface didn’t clearly signify that you could horizontally scroll on the weight graph.

We created a second prototype with a horizontal scroll signifier and spent the remaining sessions A/B testing each prototype.

<figure>
  
  ![](https://cms.echobind.com/assets/5a9ae1e8-61a2-4443-9b30-824e04f68bee)

  <figcaption>Changes were made to ensure the progress bar and start weight & goal weight were large enough. We also added a scroll indicator to the graph so members could easily navigate to a previous date.</figcaption>
  </figure>

This pivot highlights one of Echobind’s core strengths: We’re able to recognize when something isn’t working early on in a project and quickly correct course to find a more effective solution.

Conclusion
----------

The second prototype performed much better than the first, and members were easily able to complete the task scenarios. With a solid foundation of user research and validation of base usability, we marked up the designs for handoff to engineering.

<figure>
  
  ![](https://cms.echobind.com/assets/92cb7371-1800-4d26-958d-379b5f759f1d)
  
<figcaption>Our designers markup their designs with notes for development to explain complex interactions or nuanced design decisions. This saves the engineers time by limiting the amount of guesswork they have to do and saves the designers time when they QA the final build.</figcaption>
  </figure>

With this new version of the progress screen, Calibrate members are now able to easily track their weight loss progress against their 10% weight loss goal. As Echobind continues to work with Calibrate, we’re looking to monitor the performance of the new progress screen and iterate as we collect more performance data to refine design solutions.

---

[View on echobind.com](https://echobind.com/work/redesigning-a-core-ux-flow-in-calibrates-mobile-app)

---

# Empowering Educators, One Lesson at a Time

> When your mission is to make world-class problem-solving accessible to all, you build a platform that’s as innovative as the educators who use it.

The Problem
-----------

Brilliant is all about turning people into world-class problem solvers. They provide a learning platform for those who want to master quantitative skills—think math, data, and the ever-growing fields of CS and AI. They deliver interactive lessons that cut out the fluff. The team behind Brilliant is over 100 strong, with folks based in San Francisco, NYC, and scattered across the globe, all working together to make learning as impactful as possible.

**Brilliant for Educators** is an extension of this mission, offering free access to Brilliant’s rich content to K-12 students and teachers worldwide. It’s not just about access, though—Brilliant for Educators provides educators with tools to invite students, organize classes, assign lessons, and keep tabs on student progress. But with all this functionality tied up in Brilliant’s core platform, they needed a serious revamp to give Brilliant for Educators the space it needed to grow.

**Client Need:**

The client needed to decouple both the onboarding experience and the educator admin tools. Brilliant needed to break Brilliant for Educators out of its current mold and build it as a separate entity, all while keeping it connected to the main platform. The challenge was to do this without disrupting what was already working, especially since Brilliant for Educators was tangled up with the rest of Brilliant’s codebase. They were looking for a partner to help bring this vision to life and ensure that Brilliant for Educators could stand on its own while still playing nicely with the rest of Brilliant.

The Plan
--------------

Our solution? Create a brand new Next.js application specifically for Brilliant for Educators. This way, we could lift and shift the necessary parts from the existing Vue 2 and Next.js codebases, ensuring everything looked and felt like Brilliant, but with the freedom to innovate and expand Brilliant for Educators without stepping on the main platform’s toes.

Traps and Challenges
--------------------

This wasn’t your typical “start from scratch” project. Brilliant for Educators was already established and deeply intertwined with Brilliant’s core platform, so separating it out had challenges. We had to be super careful to avoid breaking anything in the process, especially when moving from Vue 2 to Next.js. Consistency was key—everything had to look and feel just right to make the transition seamless for users.

How We Fixed Things
--------------------

- **Frontend Development:** We built the new Brilliant for Educators platform using Next.js and React, with Chakra UI handling the styling. This combo allowed us to create a responsive, sleek interface that mirrored the main Brilliant site, making sure users felt right at home.
- **Backend Development:** On the backend, we used Next.js alongside Supabase for the database. We utilized RLS (Row level security) from Supabase which fostered a “security first” approach. For deployments, we leaned on Vercel to streamline the process.

![](https://cms.echobind.com/assets/5f814e54-fc08-4237-b9de-d24bca415479)

Signs of Success
--------------------
**Result/Impact:**

We’re proud to say that Brilliant for Educators v2.0 was launched on schedule, just in time for the new school year. Educators now have a platform that’s not only easier to use but also packed with powerful tools to manage their classes and content. Brilliant for Educators is now a shining example of how educational tools should work—intuitive, powerful, and built to grow with its users.

![](https://cms.echobind.com/assets/6156bb52-bc37-4b7b-97ad-00a7c72208a0)

Future Scalability
--------------------
**Looking Ahead:**

Now that we have decoupled the platform from Brilliant, there are more opportunities to independently expand and enhance the tool with educators and students in mind. Brilliant for Educators not stopping here; there’s plenty more on the horizon:

1. **Enhanced Progress Monitoring:** We’re working on real-time updates that will let teachers see exactly how their students are progressing, down to the minute. 
2. **Content Navigation Enhancements:** We’re refining the content navigation tools with improved UI, better search functions, and more accurate tagging—making it even easier to find the perfect lesson.
3. **Educator Portal UI Improvements:** We’re giving the Educator Portal a facelift, creating a more cohesive and seamless experience from start to finish.


![](https://cms.echobind.com/assets/80d0a563-bed0-42a9-b364-f1de88d9f5b3)

---

[View on echobind.com](https://echobind.com/work/empowering-educators-one-lesson-at-a-time)

---

# Rental Property Payments Made Simpler

> The Dvora app was already valuable to a large number of building residents; moving their payment system to Stripe made it even more so.

[Dvora](https://www.dvoralife.com/), a resident-services company, has a mobile app that is designed to make life hassle-free for tenants of their buildings. Residents can book building services, discover and RSVP to events, reserve spaces, and more.

Challenge
---------

As the app grew in complexity, Dvora realized they needed a payment system that gave more control and flexibility to residents, landlords, property managers and service providers. Their different users needed to be able to do things such as:

*   accepting payments from their residents without having to leave the app
*   accommodating multiple custom user flows for payments and receivables
*   scheduling future rent subscriptions and custom proration
*   applying automatic late fees to subscriptions with varying configurations
*   allowing residents to have control over automatic vs. manual charges on a per subscription basis
*   allowing residents to make payments to different businesses without having to re-enter a payment method for each business

It was clear that Dvora had outgrown a one-size-fits-all payments approach and needed a tailored solution.

Solution
--------

As a Stripe-certified team, the Echobind team was able to understand all of Dvora’s challenges and business functionality requirements to develop payment flow diagrams and user flows.  Mapping this out for the Dvora team allowed us to validate and determine which Stripe products were necessary.

We determined that developing a secure and scalable microservice that contains REST API endpoints to interact with Stripe’s API would be the best solution. We utilized the following Stripe products during our implementation:

*   [Stripe Connect](https://stripe.com/connect): helps landlords and property managers with smoother payouts to service providers.
*   [Stripe Elements](https://stripe.com/payments/elements): provides the ability to collect payments directly in Dvora’s app without leaving the app for a seamless experience.
*   [Stripe Billing](https://stripe.com/billing): allows for managing subscriptions and generating invoices for residents.

<div style="background:white">

![](https://cms.echobind.com/assets/3a8be6a1-df6f-4272-a8fa-e7362ca4d87d)
  
</div>

Result
------

With their newly rebuilt payment system, the Dvora app is now a first-of-its-kind platform that allows landlords, property managers, and service providers to easily make and receive payments customized to their specific needs.

In the end, all parties that used the app now had what they needed:

*   Service providers were able to receive direct charges into their Stripe Connect account and were responsible for managing refunds and disputes
*   Landlords and property managers could split payments between multiple deposit accounts
*   Renters were able to easily pay one lump sum and know that their payments were being distributed accordingly—without having to make multiple payments to various accounts.

Last but not least, the payment solution we built relied on Stripe to do all of the heavy lifting (communicating with card providers, facilitating transactions and all of the other great things Stripe can do). This allowed Dvora to keep focusing on their central mission: making the lives of residents easier.

💡*Visit our [Stripe partnership page](/partners/stripe) to learn more about Echobind’s expertise in building Stripe implementations.*

---

[View on echobind.com](https://echobind.com/work/dvora-stripe-rental-property-payments)

---

# Helping Bose Ship

> Echobind stepped in to salvage the existing code base on this Bose project and get the campaign live.

Bose is a manufacturing company that predominantly sells audio equipment. Bose is best known for its home audio systems and speakers, noise-canceling headphones, professional audio products, and automobile sound systems.

The Engagement
--------------

Echobind teamed up with Bose to improve sales for the Home Speaker 500 through a 30 day free trial period. During our 3 month engagement, we collaborated with marketing, product and backend teams to deliver various HTML templates that would fit within their Java based platform. We worked with their marketing team to define the why. We helped their product team scope the necessary requirements. And we enabled their backend team to effectively integrate the frontend solution.

The Problem
-----------

The goal of the campaign was to increase product adoption through a physical free trial of their Home Speaker 500. The hypothesis for our specific team was that offering free trials to a targeted audience with a compelling on-boarding experience would create higher conversion and more engaged usage. The project had been in development for the past 18 months and it was the first of its kind— the usage of Bose's microservices in this fashion was unprecedented.

The Solution
------------

Prior to our engagement, a plain HTML/CSS/JavaScript and jQuery solution was in place. However, there were multiple negative UX side effects and various security vulnerabilities were discovered during our initial audit.

We considered porting existing code to React and patching API requests with a JWT workflow. However, we determined that keeping the codebase and focusing on high priority bugs was in the best interest of the project's projected delivery.

![A webpage showing a shipping details form](https://cms.echobind.com/assets/0bb19f30-2544-453e-ae23-08826dc5fb51)

The Outcome
-----------

The campaign was delivered two weeks ahead of schedule and the conversion rate was around 95% - 98%. This successful turnout enabled the marketing teams at Bose to continue to evaluate free physical trial periods with other products. The successful integration with their internal microservices also lead to future discussions around opening up further integrations to allow teams to rapidly iterate over these bleeding edge marketing concepts.

---

[View on echobind.com](https://echobind.com/work/helping-bose-ship)

---

# Building a Home Health Mobile App from Scratch for Abby Care

> Echobind partnered with Abby Care, a home health provider for children with special needs, to develop AbbyAid, an Expo powered React Native mobile app that enables caregivers to complete daily charting with Electronic Visit Verification, biometric authentication, and Medplum integration.

Abby Care is a home health provider for children with disabilities or special needs. Abby Care trains family caregivers for certification, develops personalized care plans for each child, and then compensates the caregivers through Medicaid for their services in caring for their child.

In 2024, they recognized the need for a mobile application to better serve their community and extend their reach through digital channels. With a clear vision but needing technical expertise, they turned to Echobind for end-to-end mobile app development.

## The Need

Abby Care needed a mobile application, AbbyAid, built from the ground up to allow caregivers to complete daily charting for their child. The organization required a charting flow that included:

1. Electronic Visit Verification (EVV), Biometric authentication, Location tracking, Recording of start and end time of charting
2. Handle dynamic and complex routing depending on the care plan created for the caregiver, and whether the charting is being completed on time or late
3. Integration with Medplum

The project needed to move from concept to reality quickly, requiring both initial development expertise and a commitment to long-term partnership.

## The Solution

![AbbyAid Login Screen](https://cms.echobind.com/assets/62a469d7-58ac-439e-809b-10d390026d46)

The team chose **React Native with Expo** as the technology stack, providing several advantages:

* **Cross-platform development**: One codebase for both iOS and Android. This also allowed Abby Care’s web developers to contribute to the codebase.
* **Rapid development**: Expo's toolchain accelerated the development process and publishing to the App Store and Play Store.
* **Future-proof architecture**: Built-in support for over-the-air updates and easy maintenance

### Technical Highlights:

* Built entirely from scratch using React Native + Expo
* Implemented a scalable architecture to support future growth
* Guided the Abby Care team through the App Store and Play Store internal testing processes to getting the app reviewed for publishing

![AbbyAid Mobile Apps](https://cms.echobind.com/assets/edda341b-6efa-4501-a7ba-ad65a4447e55)

## The Outcome

The partnership resulted in:

* A fully functional mobile application from concept to production in two months available in the App Store and Play Store
* Establishment of an ongoing support relationship, demonstrating client satisfaction
* A scalable foundation that allows Abby Care to continue evolving their digital presence
* Seamless knowledge transfer to the Abby Care team to enable them to maintain the codebase going forward

The success of the initial build led to continued engagement, with Abby Care investing in additional development hours after the app had been in production for months to audit, upgrade to the latest Expo version, and expand the application's capabilities.

>> **"We loved working with Echobind, and they left us in a great spot."** -- Evaline Bai, Director of Engineering

## Why Echobind?

Abby Care chose Echobind for several key reasons:

* **Full-stack mobile expertise**: Deep knowledge of React Native and Expo enabled rapid, high-quality development
* **Healthcare expertise**: Having prior experience allowed us to make critical recommendations, and move faster when implementing features like EVV and working with FHIR data standards.
* **Collaborative approach**: Regular communication and flexibility in scheduling showed commitment to client success
* **Long-term partnership mindset**: Rather than just building and walking away, Echobind reengaged with Abby Care months later to audit their recent changes and resolve some of their pain points in the codebase
* **Professional project management**: Clear communication channels and proactive updates kept stakeholders informed throughout the project

This project exemplifies how we take a mobile app from initial concept through development and into successful long-term support, providing clients with both technical excellence and reliable partnership.

---

[View on echobind.com](https://echobind.com/work/building-a-home-health-mobile-app-from-scratch-for-abby-care)

---

# Scaling Fertility Care with Self-Service Scheduling & EMR Automation

> Discover how CNY Fertility cut onboarding time by 87% and slashed wait times from weeks to days through automation and self-service scheduling.

# How CNY Fertility Cut Patient Onboarding Time by 87% and Slashed Wait Times from Weeks to Days

## When your intake form becomes a business blocker, it's time to build something better

CNY Fertility's team remembers the moment everything changed. After months of outgrowing their existing form solution, they watched as their new system automatically pulled patient data and populated their EMR in seconds. "It's magical," one employee shared, watching 40 minutes of manual data transfer and appointment coordination compress into an automated process.

This is the story of NOVO, a ground-up patient onboarding platform that transformed how CNY Fertility connects with patients seeking care.

## About CNY Fertility

CNY Fertility is a fertility clinic founded by Dr. Robert Kiltz in 1997, known for offering affordable and accessible fertility treatments. With locations across the US, including Syracuse, Albany, Buffalo, Rochester, Atlanta, Colorado Springs, Philadelphia, and Sarasota, they aim to make fertility care more attainable for a wider range of individuals. CNY Fertility is recognized for its inclusive practices, offering financing options without credit checks and accepting patients regardless of age, BMI, or ovarian reserve markers.

## The catalyst for innovation

Due to their reputation for accessible, affordable care, demand for CNY Fertility's services was rapidly outpacing their operational capacity. Like many successful healthcare providers experiencing rapid growth, CNY Fertility recognized the need to evolve their systems. Their CEO had ambitious plans to dramatically increase consultations, but achieving this vision required reimagining their entire patient onboarding infrastructure:

- Their existing form solution had reached its limits, causing operational slowdowns.
- Like many healthcare providers, CNY faced the common challenge of manual data entry taking up to 40 minutes per consultation.
- Appointment scheduling required multiple staff touchpoints and back-and-forth communications, stretching wait times to over a month.
- Rescheduling meant more phone calls, emails and staff time.
- SMS costs had grown to over $10,000 monthly through their EMR's messaging system.

The math was simple: to scale consultations, they needed to completely reimagine their onboarding infrastructure.

## The partnership

When evaluating scheduling solutions for the project, Echobind knew that typical HIPAA-compliant scheduling services weren't designed for the unique workflows of fertility practices. Rather than compromise on functionality, Echobind's CEO reached out directly to SavvyCal's CEO, Derrick Reimer, to discuss the possibility of creating a new scheduling application specifically for appointments. As longtime users of SavvyCal for meeting scheduling, Echobind was thrilled when Derrick and the SavvyCal team expressed enthusiasm for tackling the challenge of building a HIPAA-compliant solution.

This collaboration gave birth to [SavvyCal Appointments](https://savvycal.com/appointments), a new product line designed specifically for healthcare's unique scheduling demands. For CNY Fertility, it meant getting a purpose-built solution that could handle their needs. For SavvyCal, it represented an exciting expansion into the healthcare market with a trusted partner to help validate and refine the product.

## Building NOVO: The technical innovation

### The challenge of no API

Most modern integrations rely on APIs, but CNY Fertility's EMR system offered none. This constraint pushed Echobind to think creatively, ultimately implementing robotic process automation (RPA) using UiPath that would become NOVO's secret weapon.

### The tech stack

Echobind built NOVO on a foundation designed for healthcare's demanding requirements:

- Ruby on Rails 8 for rapid, reliable development.
- PostgreSQL for robust data management.
- HIPAA-compliant architecture with encryption at rest and in transit.
- Stripe for secure payment processing.
- SavvyCal for intelligent appointment scheduling.
- UiPath RPA for EMR integration without APIs.
- Modern Rails stack including Hotwire, Turbo, and Stimulus for responsive interfaces.

### Design through data

The team went through multiple design iterations, but what set this project apart was the commitment to continuous improvement. They added HIPAA-compliant product analytics to monitor the patient journey and elevate metrics to key stakeholders, creating a feedback loop that revealed drop-off points and optimization opportunities.

## The transformation

### By the numbers

After just 8 weeks of development, the results exceeded even the most optimistic projections:

- **From several weeks to within days:** Average consult wait time dropped from several weeks to just 2 days.
- **87% less clinical workload:** 40 minutes of data transfer and scheduling coordination streamlined to just 5 minutes, with plans already underway to achieve full automation.
- **Higher patient satisfaction scores:** Self-service scheduling eliminated frustrating phone tag.
- **100% self-service scheduling:** Patients could now book, reschedule, and cancel without any human intervention.
- **Zero manual payment processing:** Fully automated, secure payment collection.

### An unexpected bonus: massive cost savings

While the primary goal was improving patient experience and staff efficiency, switching from the EMR's SMS system to AWS SNS delivered an additional win: over $10,000 in monthly savings. This 90% reduction in messaging costs meant the project would pay for itself rapidly while improving message delivery and engagement.

### The game-changer: true self-service scheduling

Perhaps the most transformative aspect of NOVO was what it eliminated entirely: the need for human intervention in scheduling. Patients gained complete control:

- Book instantly based on real-time provider availability.
- Reschedule anytime before their appointment.
- Automatic slot recovery when rescheduling, immediately freeing spots for other patients.

This shift from staff-managed to patient-managed scheduling didn't just save time. It fundamentally improved the patient experience while freeing CNY Fertility's team to focus on clinical care rather than administrative tasks.

## That magical moment

For CNY Fertility's staff, watching the RPA system work for the first time was transformative. Forms submitted by patients automatically flowed into the EMR, data fields populated perfectly, and appointments synced in real-time. But the real magic happened when they realized patients could completely manage their own scheduling journey. Booking, rescheduling, and canceling without a single phone call or email.

What once consumed nearly an hour of administrative time per patient now happened automatically in the background.

## The unexpected challenges of success

Success brought its own surprises. The dramatic increase in consultation volume surfaced new operational challenges that CNY Fertility had never encountered at their previous scale. These "fast follow" issues, while good problems to have, required quick adaptations to maintain service quality at the new volume levels.

## Looking forward: the future of healthcare onboarding

NOVO's success at CNY Fertility points to a massive opportunity in healthcare technology. The challenges they faced—legacy EMR systems without APIs, complex scheduling requirements, HIPAA compliance needs, and manual data entry burden—plague every telehealth provider, from primary care and mental health practices to dermatology and specialist consultations.

But the opportunity extends beyond healthcare. Any business that relies on scheduled paid consultations (coaching, legal services, financial advisors) faces similar challenges with intake forms, scheduling, and payment collection. NOVO's architecture provides a blueprint for transforming these experiences across industries.

The Echobind team's commitment to continuous improvement drives their roadmap forward: "We're actively working to eliminate even those last 5 minutes of manual work," says Michael Yared. With enhancements to the RPA capabilities and deeper EMR integration already in development, NOVO is positioned to become the standard for healthcare onboarding.

## The bigger picture

What started as a growth opportunity for one fertility clinic has evolved into a blueprint for modernizing healthcare operations. NOVO proved that even with legacy systems and complex compliance requirements, it's possible to create patient experiences that feel magical while dramatically improving operational efficiency.

For healthcare organizations struggling with similar challenges, NOVO demonstrated that the choice isn't between maintaining legacy systems or complete digital transformation. Sometimes, the most powerful solution is building a bridge between the two.

**See how building a custom application can help your organization cut onboarding and scheduling time by 80% or more. Contact Echobind today for a free consultation.**

---

[View on echobind.com](https://echobind.com/work/scaling-fertility-care-self-service-scheduling-emr-automation)

---

# Simplifying the healthcare experience for pet owners

> Koala Health is on a mission to make the pet care experience easier for Pet Parents. We helped them move this goal further by allowing them to offer custom telehealth solutions for new and existing customers.

---

[View on echobind.com](https://echobind.com/work/simplifying-the-healthcare-experience-for-pet-owners)

---

# An Evidence-Based App to Help MS Patients with Depression

> Pear Therapeutics developed the first FDA-authorized Prescription Digital Therapeutic (PDT). Echobind worked with them on 006, an app designed to treat depression in patients with MS, which entered Pear's clinical study pipeline.

Pear Therapeutics was known for producing the first smartphone app to receive FDA authorization for treating medical conditions. They received FDA clearance for doctor-prescribed apps to treat substance use disorder and opioid use disorder, and were working toward clinical applications to help treat a number of other conditions.

Echobind leveraged several of their senior engineers to help the Pear Therapeutics team research, develop and publish their app, simply named “Pear 006”, whose goal is to treat depression in Multiple Sclerosis patients.

The App’s Purpose
-----------------

Depression is a common symptom for multiple sclerosis patients, who have their own set of concerns, worries and biological symptoms. The depression symptoms associated with MS are known to be very manageable with the help of Cognitive Behavioral Therapy (CBT), a widely-used treatment methodology in which patients make note of their automatic negative thoughts, and replace them with more constructive ones.

The Pear 006 app took the form of a chatbot that would help a patient form the habit of assessing negative thoughts and turning them into more constructive ones. Each iteration of the app was validated with patients to ensure it was going to be maximally helpful to them.

Our Solution
------------

Our process with the Pear team involved regular assessments of goals for both the company and the end users, combined with evaluations of feature development possibilities. For the CBT chatbot, we conducted a comparative analysis of existing frameworks like Microsoft Bot Framework, Rasa, and Google’s DialogFlow, carefully weighing the pros and cons of each through the lens of client concerns and making informed recommendations.

Echobind leveraged its expertise in AI to create a custom chatbot for Pear 006, designed to support MS patients with depression. By developing a proprietary chatbot "brain" that efficiently managed patient interactions through guided pathways, Echobind ensured minimal developer intervention while allowing Pear's mental health experts to fine-tune content. This bespoke solution not only streamlined DevOps overhead but also provided a scalable platform for future AI enhancements, demonstrating Echobind's capability to integrate advanced technology in healthcare applications.

Ultimately, the right solution was different than expected: the Echobind team built a custom chatbot “brain” that was contained within the app, directing the patient through different chat threads based on their input. Each conversational thread was completely administered by the Pear 006 expert team via a sophisticated yet stable spreadsheet interface. This design ensured the chatbot brain could be easily replaced if needed.

In short, Pear was able to continually refine and improve the chatbot’s patient interactions with minimal developer involvement.

---

[View on echobind.com](https://echobind.com/work/an-evidence-based-app-to-help-ms-patients-with-depression)

---

# O'Neil Software solutions for record storage centers

> O’Neil Software, specializing in software solutions for record storage centers, partnered with Echobind to develop Annex — a first-of-its-kind e-commerce platform to amplify the reach of local record centers and transform how individuals find businesses to handle off-site record management.

### The Opportunity

O’Neil Software’s existing system adeptly manages record centers’ client data and inventory, but they saw an untapped opportunity: create a marketplace. 

A consumer-facing e-commerce model had yet to be created in the industry. So they thought, “What if we pivot everything on its head and go after the real customers of storage: The everyday user, and not simply warehouses?” 

This creates a largely-untapped opportunity for an e-commerce spin on what is traditionally a very pen-and-paper acquisition model. Annex was conceptualized to bridge this gap, offering a platform for record centers (existing O’Neil Software clients) to advertise services and enabling consumers to easily purchase storage space for physical files and media services. Attracting new customers to long-term storage contracts with new record centers allows record centers to secure new recurring revenue over time without heavy advertising and marketing costs, and Annex benefits from that by being the majority provider of services to that network.

And just like that, an entire industry was made instantly more accessible and user-friendly.

### Echobind Solution: Consumer-facing e-commerce web application 

![](https://cms.echobind.com/assets/c6dab65b-71dd-4896-8daf-57997950e2ea)

The O’Neil Software team enlisted Echobind’s expertise in designing and building a modern, user-friendly interface for Annex. The platform not only solidified O’Neil Software’s customer retention but also opened new revenue streams for record centers.

![](https://cms.echobind.com/assets/6da09932-e0f1-47a5-bc65-7d37851369ac)

### Key annex.com Features:

- **Responsive Web Application**: The initial release features a responsive web design, with plans for major mobile app development in the very near future.
- **Tools & Technologies**: Utilization of modern tools such as Turborepo, Next.js, Directus, GraphQL, Tailwind, Expo, Nativewind, tRPC, Storybook, Tailwind Variants.
- **Payment Integration**: Incorporation of Stripe for seamless payment processing.
- **Innovative Backend**: Integration with internal APIs using tRPC for stable and efficient production deployments.
    - Backend development involved connecting to their internal API and using tRPC to automatically set up the types to connect to both the Directus GraphQL API that we were using and the internal Annex API. Having stable and defined types and endpoints that were consistent and predictable allowed for issues to be found very early in the development process, resulting in very stable production deployments requiring zero rollbacks after deploy.
    - The Annex team's adoption of Directus enables non-technical members, especially in marketing, to independently manage and update website content without coding, enhancing responsiveness to market changes and reducing reliance on the technical team for regular content updates.
- **Frontend Excellence**: A mix of web and mobile interfaces, focusing on cross-platform compatibility and reusability.
    - Frontend was a mixed web and mobile interface utilizing Storybook, Expo, Nativewind, Tailwind, and Tailwind Variants for cross-platform "build once" functionality. Any components designed to be shared across web and mobile were built to be independent of any platform-specific needs and thus reusable`.`
 
 ![](https://cms.echobind.com/assets/0396c148-54f3-449c-88fc-1a2c221756df)
    
## The Design:

Echobind conducted rapid-iteration workshops, resulting in swift and effective design outcomes. Real-time decision making and feedback facilitated rapid validation with the team. During the discovery workshop, the O’Neil Software and Echobind teams identified additional requirements:

- **Content outline:** The Annex team internally crafted an initial design wherein they delineated the content they deemed crucial for their company. This served as an initial blueprint for the website's content.
- **Content Management System:** The Annex team required the capability to control, update, and create new content for their business.
- **E-commerce element:** Clients needed the ability to shop for storage goods, find and select storing vendors, agree to service agreements, enter payment details, and check out.
- **Account management:** Users needed to be able to view and manage their orders, stored goods, invoices, order statuses, review vendors, and manage other users.
- **Integrations marketplace:** A library of software that can easily connect to the Annex software to enhance the user's experience.

![](https://cms.echobind.com/assets/db95b122-5570-4136-9863-8283368a016c)

The design solution to these requirements included:

- Custom pages and elements for easy content management, eliminating the need for extensive design efforts from the Annex team
- Modules that can be personalized with content by the client, enabling them to create future pages and update existing content conveniently
- A personalized shopping experience integrating the purchase of goods, vendor selection, and service agreements seamlessly
- A user portal enabling account management, viewing of order statuses, documents, and managing authorized users
- A marketplace showcasing logos, providing information, and offering a selection of external solutions to fulfill diverse client needs

![](https://cms.echobind.com/assets/1aaf966e-16b4-4a46-bccf-10019f011507)

O’Neil Software and Echobind’s collaboration in developing Annex resulted in a significant leap in e-commerce for the record storage industry, showcasing Echobind’s ability to deliver innovative, robust, and user-friendly software solutions.

![](https://cms.echobind.com/assets/0fa85571-711f-436e-b1b8-ecd854e233b8)

![](https://cms.echobind.com/assets/6eda76f9-c6e1-4894-84b7-00c81bed0239)

![](https://cms.echobind.com/assets/832eb54e-ada2-452d-bc09-fd97de5fb6bd)

---

[View on echobind.com](https://echobind.com/work/oneil-software-annex)

---

# Upstream: Expanding Contraceptive Care Access for Rural Communities

> Echobind partnered with Upstream, a patient-centered contraceptive care nonprofit, to build FreeBC.

Upstream partners with healthcare organizations to improve contraceptive care education and access. Together with Echobind, they built FreeBC, a digital product designed to reach the people most underserved by traditional clinic access: women in rural communities, where the nearest provider can be hours away and private, judgment-free information is hard to find.

> "You guys are so fast. I have never worked with a dev team this fast. There is no messing around with you guys."

### The challenge

For many women, the barrier to contraceptive care isn't just cost. It is access and information. Rural communities often have few clinics, long travel times, and limited private ways to ask honest questions about birth control. FreeBC set out to close that gap: help someone learn about their options, compare methods, get trustworthy answers, and find a pathway to actual care, all from a phone.

### What we built

Echobind built a live digital care product that takes a user from "I have questions" all the way to fulfillment:

- **Education and method comparison.** Clear, accessible resources that let users understand and compare birth control options side by side.
- **A personalized quiz.** It recommends methods based on a user's lifestyle and preferences, which turns a confusing decision into a guided one.
- **Connie, a clinician-reviewed AI assistant.** Trained on clinician education materials and QA-reviewed for medical soundness, so users can ask private questions and get answers they can trust.
- **Video testimonials.** Real stories that make an intimidating topic feel human.
- **Telehealth fulfillment and clinic referral.** Pathways to care that work even for users without reliable phone access, plus clinic search and referral workflows.
- **Detailed product analytics.** PostHog dashboards track how users move through education, decision, and fulfillment, so the product can keep improving on real behavior.

### How we worked

Echobind moved fast and shipped a live product, working closely enough with the Upstream team that speed became the thing they remembered most. Connie in particular required tight collaboration with clinicians. The AI assistant is only useful if it is medically sound, so clinician review was built into how it was created and maintained rather than bolted on afterward.

### The outcome

FreeBC is live and moving real users through the full pathway, from learning about options, to getting personalized guidance, to fulfilling a method through telehealth. The product gives Upstream a scalable way to extend contraceptive care education and access to communities that clinics alone can't reach, with the analytics foundation to prove what's working and expand from there.

---

**Building digital health that has to earn trust?** [Let's talk.](/contact)

---

[View on echobind.com](https://echobind.com/work/expanding-contraceptive-care-access-ai-assistant-telehealth-platform)

===

# Blog

# Building a React Native POS App with Stripe Terminal and Tap to Pay

> Lessons from shipping a React Native POS app with Stripe Terminal, Tap to Pay, a BFF over two backends, and a payment flow built to prevent duplicate charges.

_By Preston Kelly · 2026-07-10_

We recently shipped a mobile POS app for a client whose staff take payments in the field. It had to accept contactless payments on a phone, present one experience over two existing platforms, and recover safely when a charge succeeded but the network response failed. Those constraints drove most of the architecture.

### Tap to Pay means the phone is the reader

Dedicated readers add friction to a field rollout. Staff have to keep them paired, charged, and nearby. With Stripe Terminal's React Native SDK, a supported iPhone becomes the contactless reader. Staff can accept cards and phone wallets without carrying another device.

We also support the BBPOS WisePOS E and the pocket-sized M2 for teams that need chip and swipe. Both options use the same [Stripe Terminal React Native SDK](https://docs.stripe.com/terminal) integration. The app asks Terminal to collect a payment, while the connection layer handles the reader choice.

Two things worth knowing going in:

- Tap to Pay and Bluetooth readers only work on physical devices. Plan for on-device testing early, because you can't validate the real payment path in a simulator.
- You will manage runtime permissions. Terminal needs Bluetooth and Location. Handle the case where a user revokes them mid-session, not just the first-launch prompt.

### One app, two backends: reach for a BFF

Our client runs two platforms with different APIs and data models. The app sends every request through a small Node and Express backend-for-frontend. The BFF uses session context to route the request and normalizes the response.

The React Native app receives one contract for records, catalogs, and payments. Platform-specific field names and missing endpoints stay in the BFF, where we can test them without spreading conditional logic through the UI.

### The payment flow that can't double-charge

The riskiest failure happens after Stripe accepts a payment but before the app receives confirmation. If the staff member retries, the customer could be charged twice.

We use the PaymentIntent ID as the transaction's identity from creation through sale recording. The backend records at most one sale for that ID:

```js
POST /payments/record
{ "paymentIntentId": "pi_123", ... }

// Server: has pi_123 already been recorded?
//   yes -> return the existing record, do nothing else
//   no  -> record it, then return
```

A network retry now returns the existing sale instead of creating another one. The device also stores the last successful PaymentIntent ID, so the app can recover after a crash without starting a new charge.

Automated tests cover this exact failure path. If a future change allows the same PaymentIntent to create two sale records, CI catches it before release.

### OAuth with PKCE and native secure storage

Staff sign in with OAuth 2.0 and PKCE, which avoids storing a client secret in the mobile app. The app stores session tokens in native Keychain or Keystore storage through Expo. The backend receives the authenticated session context it needs to route each user to the correct platform.

### What we would repeat

- Start testing Stripe Terminal on physical devices early. A simulator can cover the interface, but it cannot validate the payment hardware path.
- Use the PaymentIntent ID as a durable transaction key across the device and backend.
- Keep multiple upstream platforms behind one BFF contract.
- Lead with Tap to Pay, then support dedicated readers for teams that need chip or swipe.

Building something similar, whether that is in-person payments, a POS on mobile, or a unified app over multiple systems? [We'd love to help.](/contact)

---

[View on echobind.com](https://echobind.com/post/in-person-payments-stripe-terminal-tap-to-pay-react-native)

---

# Echobind's Second Product: Meet CopperTab

> Echobind is launching CopperTab: HIPAA-compliant billing for cash-pay healthcare. Why we built it, who it's for, and why we're the team to do it.

_By Michael Yared · 2026-07-08_

For over a decade, Echobind has built software for other people. Health systems, telehealth platforms, clinics, comsumer companies, startups. We take on work that challenges us, and we're good at it. But every so often, client work shows you the same problem enough times that you stop billing hours against it and start building the answer.

That's what happened here. Today we're announcing [CopperTab](https://coppertab.com), a new company that provides HIPAA-compliant billing and payment infrastructure for healthcare providers. It's the second product to come out of Echobind, after Kind Kiosk launched in 2024, and it exists because of a gap we kept hitting in our healthcare practice.

## The problem we kept running into

![](https://cms.echobind.com/assets/7a493bc7-0688-4980-970c-f6756530150a)

Healthcare is going cash-pay fast. GLP-1 and weight loss programs, fertility treatment, direct primary care, hormone health, longevity medicine, med spas, concierge practices. These businesses run on memberships, payment plans, and recurring charges. They look a lot more like modern subscription companies than like traditional fee-for-service medicine.

The billing tools haven't caught up. Modern payment processors are exceptional at moving money, and they are deliberately not in the business of handling protected health information. That's the right call. But it leaves providers stuck: the moment a subscription describes a treatment, a plan name, or anything that ties an identifiable person to their care, you have PHI in your billing system. General-purpose billing platforms either aren't built for that at all, or they gate HIPAA compliance behind enterprise contracts that a twelve-provider clinic will never sign.

We know this because our clients kept asking us to solve it. And we did, over and over, as custom builds. A compliant billing layer here, a PHI-safe checkout there. Custom HIPAA payment infrastructure routinely costs six figures to build and then has to be maintained forever. At some point, building the same thing repeatedly for individual clients stops making sense. It should be a product.

## What CopperTab is

![](https://cms.echobind.com/assets/975d7041-4ec8-413a-9bba-dd14f872edd1)

CopperTab is subscription billing, invoicing, and payment infrastructure built specifically for healthcare. The core idea is simple and architectural: PHI never reaches the payment processor, by design.

CopperTab holds all of the sensitive context. Patient records, plan names, billing logic, invoices, retry schedules, subscription terms. When it's time to collect a payment, only a neutral, PHI-free charge goes downstream to the processor. Providers connect their own Stripe account, funds settle directly to them, and CopperTab is never in the funds path and never the merchant of record.

And CopperTab signs a Business Associate Agreement with every client, on every plan. Not as an enterprise upsell. Every plan. That's paired with a platform that runs on HIPAA-compliant infrastructure with encryption, access controls, and audit logging throughout.

The pitch to a provider fits in one breath: keep your payment processor, keep your rates, and let CopperTab handle the compliant billing layer so you never have to think about PHI leaking into a payment system.

## Who it's for

CopperTab is built for cash-pay and patient-pay healthcare: weight loss and GLP-1 clinics, fertility centers, direct primary care, hormone and men's health, menopause care, longevity and executive medicine, medical aesthetics, and concierge practices. If your revenue is recurring and your patients pay you directly, CopperTab was built for you. It works just as well for multi-location groups that need one compliant billing layer across every clinic.

## Why we're the right team to build it

Three reasons.

**First**, we've lived in [healthcare software](https://echobind.com/industries/healthcare) for years. We've built for telehealth platforms, clinics, and health systems, integrated with the major EHRs, and shipped products that run in hundreds of care settings. We know where PHI hides, and we understand the workflows healthcare companies depend on to get paid.

**Second**, we know the payments side. Echobind is a [Stripe Premier Partner](https://echobind.com/partners/stripe), and we've implemented complex payment infrastructure across all types of client engagements. CopperTab isn't our first time connecting healthcare to modern payment rails. It's the productized version of work we've already done many times.

**Third**, we built compliance in from the first commit. CopperTab was never a prototype that got a compliance program bolted on later. Isolated per-client databases, audit logging, encryption, and access controls were part of the architecture from day one, because in healthcare the architecture is the compliance story.

CopperTab is its own company, with Echobind as its engineering partner. That separation is intentional: healthcare clients deserve a purpose-built entity whose entire job is this one thing.

## What's next

CopperTab is live at [coppertab.com](https://coppertab.com), and we're onboarding our first providers now. If you run a cash-pay practice and billing compliance is top of mind, [we'd love to talk](https://echobind.com/contact).

---

[View on echobind.com](https://echobind.com/post/echobind-s-second-product-meet-copper-tab)

---

# Building a Healthcare AI Chatbot: Meet “Connie”, the Contraceptive Care Chatbot 

> Building an AI chatbot for contraceptive care means navigating empathy, privacy, and clinical boundaries all at once. Here's how we built Connie, and what we learned along the way.

_By Emily Nadler · 2026-06-24_

How do you build a chatbot that is empathetic, personalized, and private, which are three things that AI chatbots notoriously struggle with? When a healthcare client approached us to build an AI chatbot specialized in contraceptive care, we had to face this question head on. Healthcare conversations require towing the line between providing patient-centered educational resources without crossing into clinical decision-making territory. Here's what I learned, as a Product Manager on the team that built “Connie,” an educational chatbot for a digital contraceptive healthcare product.
## Understanding the client’s needs
Like any good software project, the first step in building the AI chat was understanding what the client wanted to achieve, and how it would fit into the rest of the digital product. This part felt familiar, even if the technology behind it was new to me. What would success look like? How would this chatbot fit into the larger experience?
### Personalization and contextualization
One of the client's most important requirements challenged the generic chatbot paradigm entirely. They didn't want users to always simply be greeted with "Hi, what can I do for you?" Instead, they wanted Connie to be contextually aware of the current page that the user was viewing.
Imagine you just clicked into the page with information about the IUD. When you open the chatbot and ask, “tell me about this,” Connie responds: "I see you're looking at the Hormonal IUD. Would you like to ask a question about side effects or insertion?" That's a fundamentally different (and better) user experience.
We track which pages the user is on, and which pages the user has visited. Including that in the chatbot prompt allows Connie to say things like, "I noticed you were curious about IUD pain. Would you like to discuss pain management options?"
This approach transforms a reactive help tool into a proactive guide that meets users where they are in their research journey.
### Patient-enabled decision making tone
Trust is everything in healthcare. Providers are trained to maintain a patient-centered, empathetic, and calm tone of voice while giving care. Because we were working within the context of contraceptive care, which has its own host of stigma, it was even more important to us to think critically about gaining the trust of a potential user interacting with an AI chatbot.
Rather than writing tone guidelines from scratch, we used actual physician training materials as part of the chatbot's context. We also provided examples of "good" versus "bad" contraception support language, with specific phrases to use and avoid.
A core design principle was making the chatbot feel like a knowledgeable friend or sister rather than a clinical authority. By allowing casual language, affirming phrases, and even the occasional emoji, the experience feels approachable and human. Connie meets users where they are instead of where a doctor's office expects them to be. The anonymity of a chatbot adds another layer of comfort, removing the self-consciousness that can come with discussing sensitive topics face-to-face. For women who find conversations about reproductive health intimidating, that combination of warmth and privacy can make all the difference. 
## Security and Privacy Are Non-Negotiable
Healthcare data requires extreme caution, even in a public educational tool. We had to address several security concerns:
Session Management: We store conversations server-side rather than in the browser to prevent users from editing their message history and manipulating the chatbot into violating its safety guidelines. 
HIPAA Compliance: We treated HIPAA compliance as a foundational requirement throughout the project, which meant thinking carefully about potential data exposure at every step of the process. Because the application does not register users, users are not identified as they navigate the site. Additionally, each chatbot session gets a unique token, so there is no persistent tracking across sessions.
Beyond the user-facing design, we evaluated our entire infrastructure for compliance risks. This included ensuring our LLM provider has a BAA in place, and configuring our analytics and error-tracking tools to avoid logging identifying details. FreeBC is fully HIPAA compliant, so chat histories are stored in a HIPAA-compliant database.
## Testing is key
The client wants their team, their clinical team, and our internal team to actively try to "break" Connie before MVP launch. The most helpful feedback format we established was:
Query: What the user asked
Response: What the chatbot said
Expected Response: What it should have said
This structured feedback loop helped us iterate on the prompt engineering and refine the chatbot's expected behavior. One helpful decision we made was to separate the system prompt such that the chatbot on the production site used its own file, completely isolated from staging. This allowed the engineering team to iterate freely on the system prompt themselves in staging leading up to the MVP launch, without any risk of affecting the live product. 
What this testing looked like in practice was hands-on and iterative. It involved testing system knowledge, adjusting the chatbot’s tone, and refining edge cases. It was deliberately a team effort of trial and error: each session surfaced gaps or unexpected behaviors, which were addressed by refining the system prompt. 
## The Bottom Line
The process of building healthcare AI chatbots successfully comes from respecting three things: your users' context, your domain experts' knowledge, and your users' privacy. 
Most importantly, remember that in healthcare a chatbot isn't just answering questions, it's supporting people through potentially life-changing decisions. That responsibility should guide every design choice you make.

---

[View on echobind.com](https://echobind.com/post/building-a-healthcare-ai-chatbot)

---

# Beyond the Build: How We Helped Upstream Understand Their Product Through Analytics

> How Echobind built an analytics layer for FreeBC, Upstream's contraceptive care platform, helping a nonprofit see how real users move through their product.

_By Emily Nadler · 2026-06-24_

When a product launches, the work doesn't stop at deployment. The real questions start arriving: Are people using the product? Which flows are they using the most? Where are they dropping off? For Upstream, a nonprofit focused on expanding access to contraceptive care for underserved women, answering these questions and adjusting the product as needed was critical to achieve their mission. 
As a product manager at Echobind, I was positioned well to understand how to create the tooling in order to help take our engagement with Upstream beyond feature delivery and build a window into how their users actually experience their platform, FreeBC.

## The Platform: "FreeBC"
FreeBC is a digital tool designed to guide users through contraceptive education and connect them with care. The application includes a “quiz” flow, which guides users through questions aiming to capture their preferences surrounding lifestyle and priorities for birth control, and provide them with results based on methods best for them. It also has an AI chatbot, trained using materials used to train clinicians. It also has 19 method detail pages, which contain information from clinicians regarding pros and cons of the method, video testimonials from real users, and pathways for both telehealth and clinic-based care completion.
Upstream had meaningful questions they needed answered before and after launch:

- Which campaigns were driving the most traffic?

- Were users completing care pathways in a single visit or across multiple sessions?

- Were lower-income users gravitating toward telehealth or clinic-based care?

- Which methods were most popular? 

- Were users actually engaging with the AI?

- Where were users dropping off in the quiz, the method exploration, and the telehealth flows?

The list was long, and it reflected a team that genuinely wanted to understand their users, with the goal of ultimately improving the product. 

## PostHog
PostHog was already in the stack, as it’s Echobind’s analytics tool of choice. The challenge for us wasn't access to data, it was how best to structure that data. Raw event data flowing into PostHog is only useful if you've thought through what you want to capture, how you want to group it, and what questions those events are meant to answer.
The first phase of the work was translating Upstream's business questions into an analytics architecture: funnels, insights, and dashboards that could surface real answers.
Some questions mapped naturally to PostHog's out-of-the-box capabilities. Conversion funnels became the primary tool for understanding the telehealth and clinic care pathways. These helped us track where users entered, where they advanced, and where they left. Drop-off points in the quiz, method exploration, and care flows were modeled as distinct funnel stages so the team could see exactly which steps were losing users.
Other questions required a bit more creativity. Tracking scroll depth, CTA clicks by location on the page, video engagement, AI chatbot interactions, and filter usage meant thinking carefully about what events were being fired and whether they'd hold up over time.

## The Event Tracking Decision
Early in the process, the team went through three distinct phases of thinking about event tracking, and each phase taught something the previous one couldn't.

**Phase one: autocapture.** PostHog offers autocapture out of the box, which automatically records user interactions without any developer instrumentation. It requires near zero work to set up, and an immediate flow of data. The team started here, using autocaptured events to begin building funnels and insights. This worked until the limitations became apparent. Autocaptured events are opaque. You can see that something was clicked, but tying it reliably to a specific interaction, across users, across languages, across product changes, is fragile.

**Phase two: interaction IDs.** The next step was attaching interaction IDs to PostHog events. We manually tagged elements in the codebase so that events could be identified more precisely and used more generally across insights and funnels. This felt like a meaningful improvement. Instead of relying on PostHog to guess what happened, the team was asserting it from the level of the codebase.
But the cracks started to show as the team went deeper.
The core problem was brittleness. Interaction IDs are scoped to how components are structured in the code. If a developer refactors a component, even without changing any functionality, the interaction ID can change silently, breaking any insight or funnel built on top of it. And because developers have no visibility into what PostHog is tracking through these IDs, they wouldn't even know they'd broken something.
There was also a multilingual dimension. FreeBC currently supports both English and Spanish users, with the goal of expanding to more languages in the future. Interaction IDs tied to text content would fail to capture Spanish-language interactions consistently, meaning any funnel built on them would have a hidden gap in the data.

**Phase three: custom events.** The team landed on fully custom events: deliberate, developer-placed tracking calls that fire when specific things happen in the app. More setup work upfront, but dramatically more reliable. When a developer sees a custom event in the code, they know that interaction is being tracked, and if they change the component, they know to preserve it. The tracking is no longer silent to the people maintaining the codebase.
The team also designed the custom events to be dimensional rather than exhaustive. Instead of creating a separate event for every pill on every method page, a single `pill_clicked` event carries properties like `method` and `prompt_text`. Instead of a hundred CTA events, a single `cta_clicked` event with `placement` (e.g., `home_hero`, `home_get_real`) and `target_url`. One event, many dimensions, and fewer things to break.

## Building the Dashboards
With a cleaner event architecture in place, the dashboard work could begin in earnest.
The dashboards were organized around Upstream's core questions:

**Acquisition** — Where are users coming from? UTM source and medium tracking gave visibility into which campaigns drove traffic, and how those sources correlated with deeper engagement versus immediate bounces.

**Engagement** — How are users actually moving through the product? Page view tracking, scroll depth, and CTA click events made it possible to understand not just that users visited a page, but how they interacted with it. Funnel visualizations showed the most common paths users took before completing a care pathway.

**Care Pathway Conversion** — The telehealth and clinic funnels were the heart of the analytics work. Each stage of each flow was instrumented, so Upstream could see exactly where momentum was lost. Were users dropping off when asked for their zip code? After viewing their best-fit method? Before completing the telehealth intake? These answers would directly inform product iteration.

**AI Engagement** — The AI chatbot was a major feature investment, and Upstream wanted to know if it was paying off. Tracking chatbot opens, the pages users were on when they engaged with it, and the volume of back-and-forth exchanges gave a picture of how the AI was being used — and whether users who engaged with it were more likely to complete a care pathway.

**User Demographics and Outcomes** — Some of the most meaningful questions Upstream had were about equity: Were lower-income users completing care differently than higher-income users? How did age correlate with method selection and care completion? These questions intersected with a separate data mapping effort, but the PostHog instrumentation was designed to leave room for that analysis.

## What This Kind of Work Actually Takes
One of the things I took away from this engagement is how underestimated analytics work tends to be, especially on product teams moving fast toward launch.

Setting up event tracking isn't a checkbox. It requires product thinking (what questions matter?), technical judgment (how do we structure events so they're maintainable?), and ongoing coordination between PMs and engineers.

We were doing a lot with a little, and that constraint forced some real clarity. It pushed us toward the custom events approach, which helped us create analytics dashboards that would hold up over time as the product evolved.

## The Bigger Lesson
Upstream's mission is to make contraceptive care accessible to women who face the most barriers to getting it. Every drop-off in the quiz, every user who didn't complete their care pathway, every AI interaction that didn't lead somewhere represent real people who came looking for help and didn't quite get there.

Building the analytics layer helps to serve that mission. It gives Upstream the visibility to ask hard questions about their product, learn from the answers, and keep improving.
Delivering a product is the beginning. Understanding how it's actually used is what makes it better.

---

[View on echobind.com](https://echobind.com/post/beyond-the-build-through-analytics)

---

# Manage Personalized AI Slack Agents Across Your Org

> How Echobind built a private, personalized Slack AI agent management app.

_By Stuart Gross · 2026-06-22_

We've been quietly running a per-person AI agent experiment at Echobind where each teammate has their own Slack AI assistant.  Each assistant has its own bot identity, its own memory and its own learnings (and eventually it's own token usage tracking). The agents live on a private tailnet so we can `ssh` in as needed, while provisioning and lifecycle are handled from a small internal tool we built called **Roster**.

This post is the story of how we built it, why we picked the technologies we did, and what the UX taught us along the way. We want to share what we learned since portions of our work is made public and open-sourced (the Railway template and agent container repo).  And If you're thinking about embedding agents into your own team's workflow, this demonstrates what we might build for you too.

The stack overview:

- **[Hermes](https://github.com/NousResearch/hermes-agent)** - the open-source agent runtime from Nous Research. Persistent memory, skills, learning, multiple chat-platform gateways out of the box. 
- **[rome-on-rails](https://github.com/echobind/rome-on-rails)** - Echobind's [Railway template](https://railway.com/template/) that wraps the [upstream Hermes Docker container](https://github.com/NousResearch/hermes-agent/blob/main/Dockerfile) with a Tailscale sidecar, an opinionated entrypoint, and a documented env-var contract.
- **[Tailscale](https://tailscale.com/)** - runs inside the container, so each agent is its own tailnet node we can SSH into, with no public surface. 
- **Roster** - Echobind's internal control platform with an org chart of people plus the agents assigned to them.  It contains the "Create new agent" flow that drives the whole Railway provisioning sequence and lifecycle control. 

### Why per-person agents, and what that meant for the design

We didn't want one agent for the whole company. We wanted personalized agents with there own:

- **Slack identity.** A distinct bot name, avatar, and Slack app, so the assistant feels personal and their context is not cross-pollinated with other bots.
- **Memory.** Conversations, skills, and learned preferences that don't bleed across teammates. (Hermes's `state.db` lives on a per-service Railway volume)
- **Access boundary.** Only the people on a specific Slack allowlist can talk to a given agent and the list can be updated any time.
- **Maintainer surface.** When something breaks, we need the ability to `ssh` in and look at logs and inspect files directly.

Those four constraints shaped almost every decision.

### The two-layer access model

One Hermes Railway service per Slack agent, behind tailnet was our chosen model.  It lets team members chat with their agent without ever knowing what Tailscale is, while an engineer who needs to debug an agent's memory or rotate a skill can quickly ssh in without exposing anything to the public internet.  Decoupling those two surfaces was important and Tailscale turned out to be the right tool for the job.

> *Screenshot: the Roster 'agents' dashboard.*
>
>![](https://cms.echobind.com/assets/368957ff-e3d8-433d-8356-941e383be8ca)

## The Railway template for Hermes Slack agents

Before we built Roster, we built **rome-on-rails**.  It's a Railway template that deploys a single Hermes agent and tailnet node.  It pulls the upstream Hermes Docker image (we purposely designed around the upstream image so we can benefit from future updates with minimal maintenance), adds a small entrypoint that sets up Tailscale networking, runs Tailscale with ssh, and then hands off to the upstream Hermes entrypoint.  It also persists agent memory on the Railway volume so an agent keeps the same tailnet hostname and memory across redeploys.

A big design decision for the Railway template was to stay deliberately single-service since Railway templates fix the service count at publish time. So a 3-service template is wrong wouldn't work for a client who needs 2 or 4 agents, and publishing a per-count template means maintaining multiple near-identical templates with different service counts.  So instead, the template provisions one Hermes service, and to add another agent in the same Railway project, we duplicate the service inside Railway (in our case, programmatically using the Railway API).  All we have to do is override the per-agent environment variables (Slack tokens, Tailscale hostname, LLM provider key) but leave Railway workspace token and the Tailscale auth key alone since they are shared at the project level.  Per-agent variables on the service with shared variables on the project means we have granularity over control of things like LLM token usage.

## Postman as the empirical validator

Before integrating the Railway API into our frontend, we took the "trust but verify" approach to the API docs.  We built a Postman collection first, ran every query against the live system, watched the Railway dashboard and the logs update live , and only then translated the verified shapes into our backend.  This also enforced our understanding of the API interactions as we iterated our Postman environment and queries until they were successful.  It also let us create a Postman collection json artifact customized to our app that we could leverage using AI later on.

## The Roster UX

With the API verified and the template stable, we built the Roster side. Roster is the place we manage who has agents and which humans they support.  The idea is an org chart of people with Slack agents assigned as supporting resources for those people.

> *Screenshot: the Provision modal: top half.*
>
> ![](https://cms.echobind.com/assets/a116f2da-4aa8-4034-97fe-0811a83e0ef3)

The "Create new agent" button on the Agents page opens the provision modal where the user enters the required information.  The prompt and notes fields don't ship to Railway, they just live on the agent row in our database.  The "Project" toggle is where the operator decides whether to spin up a brand-new Railway project for this agent or add the agent into an existing project.

> *Screenshot: the Provision modal: bottom half.*
>
> ![](https://cms.echobind.com/assets/1df9ee69-9505-43ab-a7b0-c236c3e5d89c)

This is where the per-agent environment overrides live. The LLM provider key, the two Slack tokens, the home channel, the Slack Allowed Users checkbox list.  Only checked users can talk to the agent in Slack and nobody else. The Slack user ID list is controlled in a table that is seeded by our team, so the user picks from real humans, not free-text member IDs.

Once **Provision agent** is clicked, Roster does the following:

1. Creates a new project or uses an existing project's ID.
2. Generates a per-project Railway token via and persists it in our DB with encryption.  This is what lifecycle calls (start/stop/restart) authenticate with afterward instead of the workspace token.
3. Fetches the published Hermes template, adds the user's inputs to setup the Railway environment variables, and deploys the template.
4. Persists the new agent to the database with status set to provisioning.
5. Returns immediately so we aren't waiting for Railway to finish building.

Since a Railway build can take several minutes, we close the modal the moment Railway has accepted the deploy, show the new agent card in the dashboard as "provisioning", and only update the card to "running" *after* the deployment webhook arrives back at Roster.

> *Screenshot: the post-provision handoff. The one manual step left.*
>
> ![](https://cms.echobind.com/assets/da9caf5e-fd27-4f1f-a481-f6230caaf18f)(Pasted%20image%2020260502131142.png)

There's one manual step left, paste the per-project webhook URL into Railway's dashboard. Railway's GraphQL API doesn't (yet) expose programmatic webhook configuration, we discovered this suring Postman development, planned for it, and made sure the modal hands the URL off as a simple one click copy-and-paste option. 

> *Screenshot: the project detail page, where that webhook URL lives forever.*
>
> ![](https://cms.echobind.com/assets/6d53b288-01a7-413d-a991-3079b0854bc0)

The project detail page is where the operator can come back and grab the webhook URL again, regenerate it (treat as a credential), or watch the green "Webhook live" indicator confirm that Railway is talking to us. The page also lists every agent in the project with an available link to its detail view.

## Agent lifecycle control via buttons

Once an agent is provisioned, it's lifecycle is controlled by just three buttons on the agent card: **Start**, **Stop**, and **Regenerate token** (decommission button is coming in a future revision). Under the hood:

> *Screenshot: agent card for lifecycle managment*
>
> ![](https://cms.echobind.com/assets/4961c4f0-30e4-4d0f-bbd5-5efe942c12ec)

- **Start** calls the deployment restart endpoint against the agent's last deployment Id. The container comes back with the same volume, so same Hermes session history, same skills, same Tailscale machine identity, same MagicDNS hostname. The agent picks up where it left off.
- **Stop** calls the stop deployment endpoint.  While the container is paused, Slack and Tailscale go quiet, but the data volume is preserved.

Every one of those actions is observable in Roster via the webhook.  The status of each agent flips through `provisioning → ready → running → stopped` based on what Railway actually says happened, not what we *think* should have happened.

## How to use the Railway template yourself

Roster itself is internal Echobind tool, but the parts you need to build the *agent* side are public:

- **The template:** [github.com/echobind/rome-on-rails](https://github.com/echobind/rome-on-rails) has the Dockerfile, the entrypoint, and template-notes that describe the environment variables.
- **The Readme:** contains the one-click Railway template deploy button .
- **The docs:** the rome-on-rails repo includes tailscale-setup.md, secrets-guide.md and webhook-setup.md so you can deploy your first agent in no time.
- **Hermes upstream:** [github.com/NousResearch/hermes-agent](https://github.com/NousResearch/hermes-agent) credit to the Hermes runtime; we just package it.
### Common gotchas

- If SLACK_ALLOWED_USERS is left blank, the bot looks online but never responds.
- If SLACK_BOT_TOKEN and SLACK_APP_TOKEN are reused accross services, two containers connect to the same Slack app and there is no way to specify which agent receives the message.
- If TS_HOSTNAME is not unique, machines fight for the same hostname in Tailscale; only one wins, the others are unreachable. Always set an explicit hostname.
- Choose Reusable Tailscale auth keys since non-reusable keys spend themselves on the first registration and the agent can't re-register after a redeploy.
- When testing webhooks in local dev, Railway can't reach your laptop.  We used [ngrok](https://ngrok.com/) to provide a tunnel for the webhook to reach our local dev and put the public URL in NEXT_PUBLIC_APP_URL.

## Future considerations

A few things we're excited about in the next iteration:

- **Programmatic Slack-app creation:** Today, every new agent needs a Slack app created by hand (bot token, app token, install to workspace). We're going to explore the [Slack App Manifest API](https://api.slack.com/reference/manifests) to provision Slack apps automatically as part of the "Create new agent" flow.
- **Editable allowed-users list:** The provisioning modal already has the right checkbox UX for picking allowed Slack users.  We're going to show the same control on the agent detail page so moving users between existing Slack agents is easy.
- **Per-agent token usage and live cost:** OpenRouter and the upstream providers expose usage data per request. We want to easily see how much agents have been spending and what their allowed to spend in Roster.  For now the spend column is seeded, but we hope to have this live soon.

If any of this is interesting to your team, whether that's "we want our own per-person agents," "we want to build something like Roster for our own runtime," or just "we want to talk through whether AI agents are the right shape for our workflow", we'd love to [hear from you](https://echobind.com/contact). 

And if you want to play with the agent side without us, the template is available.  Deploy it, paste in a Tailscale auth key and a Slack bot tokens, and you'll have your own personal Hermes assistant on your tailnet in minutes. The hardest part is picking what to name it.

*Special thanks to [Nous Research](https://github.com/NousResearch/hermes-agent) for the open-source Hermes runtime that this is all built on, and to the [Railway](https://railway.com/) and [Tailscale](https://tailscale.com/) teams for platforms that enable us to experiment with new ideas.*

---

[View on echobind.com](https://echobind.com/post/manage-ai-slack-agents)

---

# We Built a Slack AI Agent on Hermes. Here's Everything That Broke.

> Build a Slack AI agent with Hermes Agent, from a locked-down droplet to persistent company knowledge. Includes the toolset security config, a two-layer context file setup, and four gotchas that aren't in the docs.

_By Stuart Gross · 2026-03-25_

During my first internship in 2012, a coworker shared the company's "acronym bot" to help me get up to speed. It was a large company with a LOT of acronyms, and I still remember what a lifesaver that integrated chat bot was. Fast forward to 2026, and the value of a customized AI-powered chatbot within an organization goes well beyond fetching acronym definitions. Today's AI assistants can perform complex tasks using natural language prompts, schedule and perform recurring tasks, create deliverables, or even change their behavior under the hood for a better user experience.

Today we'll implement a custom AI-powered Slack app that responds when @mentioned inside a channel it's been invited to. We'll use an open source AI framework called Hermes Agent to power our app. This is our framework of choice because it's lightweight, works with our LLM of choice including a local LLM, and because it supports the features mentioned above. Tailscale will serve as our private network provider to ensure our server is only accessible by us.

### Spin Up a Linux Server and Lock It Down

Before we can install anything, we need a server that's always on and reachable by Slack. A cloud virtual machine is a great fit for a proof of concept project of this scope. We'll use a DigitalOcean Droplet to host our Linux server with the 2GB RAM option. This gives us some headroom on top of required processes (Linux, Hermes framework, observability dashboard, SQLite session, etc.) which would creep dangerously close to the 1GB plan. The setup is straightforward. We pick a region, an operating system, CPU and storage specs, paste our SSH key, and we're ready to go.

For the OS, we're going with the Ubuntu long term support image since Hermes docs use Linux commands throughout their documentation and the FAQ section even recommends Ubuntu. Once the Droplet is created, we SSH in, create a non-root user with sudo privileges to work from, run `sudo apt update && sudo apt upgrade -y` to get everything current, and reboot. Now we've got a fresh server on DigitalOcean with a public IP address.

A fresh Linux server accepts connections on any port by default. We want to make sure SSH key authentication is the only way in. DigitalOcean handles this when we create a Droplet using an SSH key by disabling password login automatically. We'll use [Tailscale](https://tailscale.com/) to limit who can attempt SSH key authentication. Tailscale creates a private encrypted network between our devices using the WireGuard protocol. Think of it like a VPN, but we don't run a VPN server. Instead, Tailscale handles the coordination, and the actual traffic is encrypted end-to-end between our devices. We install it on the server, install it on our laptop, sign in with the same account, and now they can talk to each other over private IPs that nobody else can reach.

Now with Tailscale up, we configure the server's firewall (`ufw` on Ubuntu) to deny incoming traffic by default. Then create an exception to only allow traffic arriving through the Tailscale interface. Outbound traffic is allowed since the server needs to call external APIs (Slack, our LLM provider, package repositories). So now even if someone knows our server's public IP address and tries to connect on any port, the connection gets dropped.

```bash
sudo ufw allow in on tailscale0
sudo ufw allow 41641/udp
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable
```

### Set Up the Hermes Agent Framework on the Server

[Hermes Agent](https://github.com/NousResearch/hermes-agent) is an open source AI agent framework that gives our LLM tools persistent memory and messaging integrations. It extends chatbot capabilities to executing tasks, scheduling cron jobs, searching the web, reading files, and remembering context across conversations. It supports multiple LLM providers including local models. For our LLM provider, we went with [OpenRouter](https://openrouter.ai/) with Claude Sonnet 4.5 as our model. OpenRouter lets us access models from multiple providers (Anthropic, OpenAI, etc.) through a single API.

[Installation](https://hermes-agent.nousresearch.com/docs/getting-started/installation) is a one-liner:

```bash
curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash
```

The installer handles everything: it installs Python, clones the Hermes repo, installs all dependencies, and launches a setup wizard. The wizard walks us through picking our provider, model, terminal backend, session settings, and messaging integrations. It was honestly very easy to set up following the wizard, but hand-editing the YAML config is also a valid option. After the wizard finishes, we verify the install with `hermes doctor` (which checks API keys, tools, and config) and a quick test chat to make sure the model responds.

Troubleshooting: the setup wizard wrote the model config as a flat string.

```yaml
model: anthropic/claude-sonnet-4.5
```

But Hermes actually expects a nested YAML key.

```yaml
model:
  default: anthropic/claude-sonnet-4.5
```

When left flat, Hermes falls back to a different default model. In our case it defaulted to Opus 4.6.

### Create the Slack App and Connect to the Server via WebSocket

This step follows the [official Hermes Slack setup guide](https://hermes-agent.nousresearch.com/docs/user-guide/messaging/slack). We begin by creating our Slack app in the Slack API dashboard, then configure the bot token scopes, and grab the two required tokens for Hermes. Socket Mode needs to be enabled since we prevent incoming traffic. Without it, Slack is unable to send messages to our server. WebSocket mode allows the server to initiate two way communication with Slack.

![Slack API dashboard showing Socket Mode enabled for the Hermes app](https://cms.echobind.com/assets/19dd72e1-c97b-4398-86b5-4f9ebd97dbbc)

With our Slack app set up, we can add the Slack API tokens to our server environment variables and install the [Hermes Gateway](https://hermes-agent.nousresearch.com/docs/user-guide/messaging/?_highlight=gateway). We'll install it as a systemd service (`hermes gateway install`), and enable "lingering" so the service keeps running even after we close our SSH session. The gateway is what actually maintains the WebSocket connection to Slack and routes messages to and from the Hermes agent.

![Terminal output confirming the Hermes gateway systemd service is installed and running](https://cms.echobind.com/assets/1948e972-a29d-4b3f-a531-90c15731466d)

Once the gateway is started, we're ready to test the @mention flow in Slack. We just need to install our app in Slack, and then invite Hermes into a channel. We can designate a Slack channel as Hermes' "home" channel where it will log activity by default.

![Hermes bot replying to an @mention in a Slack channel for the first time](https://cms.echobind.com/assets/5ef89589-7dc8-4bf4-a694-56a3723836e2)

Troubleshooting: During initial gateway testing, the Slack bot was triggering an "active session" interrupt on every first message after startup and preventing the gateway from responding. After some troubleshooting and verifying the Slack app and Hermes environment were set up correctly, we checked the Hermes Agent GitHub repo. We noticed `slack.py` had been modified in a recent batch of commits with changes that seemed relevant, so we ran `hermes update`, which pulled 98 new commits. Then we restarted the gateway, and the issue was gone. This was a great reminder to check for updates frequently when working with source code that is moving fast.

### Explore Slack Security Guardrail Options

Hermes comes with a lot of built-in [toolsets](https://hermes-agent.nousresearch.com/docs/user-guide/features/tools): web search, cron jobs (scheduled tasks), terminal command execution, file operations, code execution, memory, and more. Out of the box, it's powerful. But in some applications we may not want our Slack bot to run shell commands on the server, manipulate files, or spawn sub-agents. Hermes uses a `config.yaml` that acts as an allow list, so only the toolsets we choose are available on the platform.

![config.yaml showing the per-platform toolset allow list restricting which tools Slack can access](https://cms.echobind.com/assets/351ad631-7c62-4aad-a847-2315755f2728)

Troubleshooting: Hermes has a global `toolsets` setting that defaults to `[all]`. If you don't change this to `[]`, it overrides the per-platform restrictions and makes everything available everywhere. We discovered this when Hermes made code changes via Slack requests even though the Slack toolsets were not listed.

Another powerful layer of security is the `SLACK_ALLOWED_USERS` environment variable. It is a user whitelist that only allows listed users to make Slack requests to Hermes. Slack user IDs are available under Slack user profiles. Every user ID has to be added to the Hermes environment variables before that person can make requests, including our own.

Hermes also has some baked in [security](https://hermes-agent.nousresearch.com/docs/user-guide/security) guardrails to protect against other forms of threats. In our use case, the user whitelist along with the toolset config offers enough protection. But it's good to understand the defense in depth offered by Hermes for other applications where guardrails need to be tighter.

### Set Up Hermes Agent Context Files

Since we want Hermes to always "know" about Echobind, we need to decide how to set up its knowledge internally by referring to the [Context Files](https://hermes-agent.nousresearch.com/docs/user-guide/features/context-files/) documentation. Since the "How Context Files Are Loaded" section mentions the overall context is "injected" into our prompt, we want to minimize the overhead of company knowledge that gets sent with every prompt. To do this, we'll take advantage of the Hierarchical Discovery feature when loading context files.

On startup, it walks recursively from its working directory and concatenates every `AGENTS.md` file it finds to build its context. So we'll use a two-layer approach. A condensed summary of Echobind will live in `~/.hermes/knowledge/AGENTS.md`. This gets automatically loaded into every prompt and gives Hermes an overview of the company along with where to find more detailed information. The full company content, scraped directly from Echobind.com in this case, lives as individual markdown files in the same `~/.hermes/knowledge/` directory. When a user asks a specific question, like "tell me about the Stripe partnership", Hermes uses its `read_file` tool to pull the relevant files that don't get loaded with every prompt.

Troubleshooting: Hermes also maintains its own `~/.hermes/AGENTS.md` file where it writes self-improving context over time in the root directory. This file doesn't exist at initial setup, and so the hierarchical discovery fails until it is either manually created, or Hermes creates it. Also, we don't want our Echobind knowledge to be overwritten, so we don't store it in the root directory `AGENTS.md` file since Hermes updates this as its context updates. We instead store it in the knowledge directory (created by us) `AGENTS.md` file where it is discovered hierarchically.

Finally we need to populate Hermes' knowledge with content from Echobind.com. We'll use a custom Python scraper to pull web content around services, case studies, capabilities, and partnerships. These are the pages that answer the question "what does this company do?" The final knowledge directory created by the scraper looks like this (each section contains relevant markdown knowledge files).

![Directory listing of the ~/.hermes/knowledge folder with markdown files grouped into sections](https://cms.echobind.com/assets/0203966d-4995-41b9-b8f3-85ef0703f722)

### Test Persistent Knowledge and Memory

This is the moment of truth. Does Hermes actually use its knowledge instead of searching the web? We'll test from the command line first with a request for general information.

```bash
hermes chat -q "What does Echobind do?"
```

Hermes should pull from the scraped content without using tool calls at this point since the Echobind summary in `AGENTS.md` will handle this.

![Terminal output of Hermes answering "What does Echobind do?" directly from context with no tool calls](https://cms.echobind.com/assets/8558e28a-4a69-45f3-a28f-1ccbe6a4fdaf)

Next, let's test something more specific, like "Give me a detailed description of Echobind services." This information lives in an individual knowledge file, not in the summary `AGENTS.md`. So Hermes will use its `read_file` tool to pull the relevant file(s) and answer with details about the services. This will confirm the two-layer system is working since the summary provides the general overview, and the detailed files get pulled on demand when specifics are needed without searching the web. Let's test this using Slack to get the full user experience.

![Hermes in Slack calling its read_file tool to answer a detailed question about Echobind's services](https://cms.echobind.com/assets/30695374-bd94-417f-87a2-c5a61d49447f)

Over time, Hermes also builds up its own learned context in its self-managed `AGENTS.md`. As it handles more questions, it adapts by recognizing patterns across sessions and updating how it handles similar questions. This is part of the "adapts to you" piece. The knowledge gives it context, but the persistent [Hermes Memory](https://hermes-agent.nousresearch.com/docs/user-guide/features/memory) lets it get better at using it. Users can also explicitly tell Hermes to adapt with prompts like, "always format your responses to me using bullet points" or "use relaxed but professional language in this channel".

![Hermes in Slack acknowledging a formatting preference and applying it to the following response](https://cms.echobind.com/assets/91a58bbd-3273-4d9e-beb0-c16099b17e05)

The last toolset we'll look at is `schedule_cronjob`, one of the most useful tools Hermes offers. We'll have it perform a simple task here for the purpose of this walkthrough. But it is capable of scheduling and executing complex recurring tasks. Let's ask Hermes to remind us to check our email in 5 minutes.

![Hermes in Slack scheduling a cron job and delivering the reminder five minutes later](https://cms.echobind.com/assets/569b892c-0aea-4cca-abe9-fecc4c0edb0b)

### Create an Observability Portal

We need to know if the agent is working, what it's been doing, and what went wrong when something breaks. Without a dashboard, the only way to check on Hermes is to SSH into the server and review logs manually.

Instead, we'll build a lightweight Flask dashboard since we're already using Python and Flask is a Python web framework. The dashboard is simple with only two routes. The root (`/`) serves the HTML page, and `/api/status` returns a single JSON payload with everything the frontend needs. The frontend fetches `/api/status` on a timer and refreshes the page every 30 seconds. No database, no WebSocket, no client-side framework, just a page that polls a JSON endpoint.

The dashboard will show whether Hermes is up or down, system resource usage (memory, disk, uptime), recent activity parsed from the gateway logs, recent errors and warnings, and the current state of the knowledge files. We'll also set it up to run as its own systemd service that automatically starts up, and make it only accessible over Tailscale.

![Flask observability dashboard showing Hermes status, system resource usage, and recent gateway activity](https://cms.echobind.com/assets/e52133b9-6414-48fa-b925-eb271f900829)

Fun Fact: We built the initial observability dashboard, then enabled file and terminal command toolsets for Slack to experiment with them. When prompted, Hermes updated the dashboard to add additional observability without any issues. We probably could have let it build the initial dashboard as well.

### Final Thoughts

Hermes is a long way from the acronym bot I used during my internship over a decade ago. But the core idea is the same. It's an integrated tool that lives where your team already communicates and helps them get things done. The difference now is that the tool can reason, remember, adapt, and perform tasks instead of just looking up definitions.

We went from an empty DigitalOcean Droplet to a fully functional AI Slack assistant that is secure, connected to Slack, and knows about our company. We also highlighted some troubleshooting and design considerations along the way. Hermes Agent is currently a quickly moving project, but the barrier to entry is not as high as it first seems.

**What it costs**

- Hermes Agent is open source and free.
- DigitalOcean Droplets start at $12/month for the 2GB tier we used.
- Tailscale has a free tier that's more than enough for a setup like this.
- LLM usage is the variable line item. Token spend scales with how often your team @mentions the bot, so watch it for the first few weeks.

**Resources**

- [Hermes Agent on GitHub](https://github.com/NousResearch/hermes-agent)
- [Hermes Slack integration guide](https://hermes-agent.nousresearch.com/docs/user-guide/messaging/slack)
- [Tailscale](https://tailscale.com/)
- [OpenRouter](https://openrouter.ai/)

---

[View on echobind.com](https://echobind.com/post/hermes-agent-slack-setup-guide)

---

# Beyond Compliance: What We Learned Building an App for Adults with Intellectual Disabilities

> Key lessons learned building a financial literacy app for adults with intellectual disabilities, including visual-first design, dual-user interfaces, and gamification as essential accessibility strategies.

_By Emily Nadler · 2026-03-06_

As a software agency, we regularly build products for clients serving specific populations, such as teachers, doctors, or children. Each has their own needs, and it’s best practice to design with those users in mind from the start.

When a client asked us to build a financial literacy platform for users with intellectual disabilities, we realized that this population would force us to rethink our general assumptions about how people interact with technology more than other populations we’ve built for. We discovered that true accessibility is more than just checking compliance boxes, but instead about intentional design and creative feature choices. Many of those choices turned out to be more universally applicable than we’d expected.

Here's some of what we learned.

## Text can be a barrier, not a feature

One of the first things our client told us: "95% [of our participants] can't read. And if they can, it's very limited."

This single insight changed our entire approach from how we would typically design a software product. We could no longer rely on labels, instructions, or error messages to guide users. Every interaction had to be visually intuitive. Images and icons had to carry meaning on their own, and text became supplementary, there primarily for the caregivers helping participants navigate the app. We learned to pair visual cues with minimal text, but the visuals always came first. One example: when a participant answers a question correctly, they are shown a confetti animation, along with the coin amount with emojis:

![](https://cms.echobind.com/assets/b871145e-8565-4357-b902-91dc05d94606)

## Designing for multiple users simultaneously

We also learned that the users for our app would be using the app from centers where they would be accompanied by Direct Support Professionals (DSPs). These DSPs would sit beside them, helping them navigate the app interface and, in certain cases, answering questions on their behalf.
This created a dual-interface challenge. Participants needed large buttons, visual feedback, and gamified rewards. However, DSPs needed monitoring tools, the ability to see multiple participants' progress at once, and administrative controls. 

Our solution was to build for both user needs, splitting the app out into multiple logins. The participant view was designed to be engaging, interactive, and accessible. The DSP view was designed to be informative, streamlined, and straightforward. For example, DSPs could answer questions on behalf of the participants, while the participants still got to see and interact with the questions, too. 

Overall, both users get the ideal user experience for their needs.

## Gamification as Curriculum

For people with intellectual disabilities, the classroom experience isn’t just about information transfer, it’s about recognition. Our client described how their in-person financial literacy classes have typically functioned, before the creation of this app. When someone gets an answer right, the instructor celebrates publicly, everyone claps, and the participant feels seen. That moment of acknowledgement isn’t a nice-to-have. It’s what makes learning stick, which is why we needed to replicate that dopamine hit digitally. 

How we did it:
- Coins for correct answers: Immediate, tangible rewards say “you did it.”
- Badges for milestones: Allow participants to track their progress over the course of time
- Visible progress bars: Clear visual indications of how far participants have come, and how close they are to their next achievement

Research shows that gamification improves engagement and retention for learners with intellectual disabilities (i.e. [Kumar, 2025](https://restpublisher.com/wp-content/uploads/2025/03/The-Impact-of-Gamification-Strategies-on-Motivation-and-Knowledge-Retention-in-Learning-Environments-for-Persons-with-Intellectual-Disabilities.pdf)). Ideally, the visual progress indicators in our app would both reduce cognitive load around “how am I doing?” and the collectible elements would create intrinsic motivation to return to the app. Overall, our takeaway was that these features weren’t decorative, but instead primary features of our app. 

## What Went Wrong
Designing for multiple users simultaneously was a meaningful challenge, and we didn't get everything right the first time.

We successfully designed the app such that a DSP could answer questions on behalf of a participant, which was an important accommodation for users who needed more hands-on support. What we missed, however, was the login experience itself. We hadn't accounted for the fact that a DSP might also need to log a participant into the app for them, not just assist them once they were already inside it.

It was a gap that, in hindsight, revealed something important: truly understanding a user's workflow requires more than empathy in the abstract. It requires diligence at every step of the journey, especially for users whose day-to-day experience we don't have firsthand familiarity with. It's easy to design thoughtfully for the moments we can imagine clearly. The harder work is pressure-testing the full flow, including the parts that happen before a user ever reaches the first screen, and asking whether someone who relies on a caregiver for support can actually get there at all.

## What We're Taking Forward

Building this app taught us that, when building for a certain population, accessibility is a lens through which every decision gets filtered. For example, we constantly found ourselves asking questions like:

* "Will this work for someone who can't read?" 
* "Will this work for someone using it with a caregiver?" 
* "Will this make someone feel motivated to learn?"

The answers to those questions shaped an app that is potentially simpler, more visual, more celebratory, and more human than anything we would have built by default. A lot of these principles would make any software better: fewer screens, clearer feedback, celebration of progress. These are more than accommodations for disability, they're good design. We just happened to learn them by building for a population that made the stakes impossible to ignore.

---

[View on echobind.com](https://echobind.com/post/beyond-compliance)

---

# How to Hire Stripe Developers

> What to look for when you hire Stripe developers, from a team with more Stripe-certified developers and architects than any other agency in the US.

_By Mike Cavaliere · 2025-08-19_

If you are searching for Stripe developers, you have probably already discovered the thing that makes
this hire confusing: Stripe is genuinely easy to start with. The APIs are well designed, the docs are
excellent, and any competent developer can have a test charge working in an afternoon.

That is exactly why teams underestimate it.

The hard part of a Stripe integration is not the first charge. It is the hundred edge cases between a
working demo and a payment system you trust with real money — and those only become visible after you
have shipped a lot of them. What you are really hiring for is not knowledge of the API. It is pattern
recognition about what breaks.

Here is what that difference looks like in practice, what Stripe certification actually verifies, and
how to tell whether the team you are talking to has seen the problems you are about to hit.

## The part of Stripe that is actually hard

Every integration starts simple. Then the business shows up with requirements.

**Webhooks and fulfillment.** Stripe will deliver the same webhook more than once, out of order, and
occasionally hours late. If your fulfillment logic is not idempotent, you will double-ship orders or
double-grant access. This is the single most common defect we find in existing integrations, and it is
usually invisible until volume exposes it.

**Refunds, disputes, and partial states.** A payment is not a boolean. It can be authorized, captured,
partially refunded, disputed, or reversed weeks later. Systems designed around "paid / not paid" have to
be rebuilt once the first chargeback arrives.

**Subscriptions and proration.** Upgrades mid-cycle, downgrades, pauses, trials that convert, seats that
change on the fifteenth of the month. Stripe supports all of it, but the correct primitive is rarely the
first one you reach for.

**Money that moves between more than two parties.** The moment you have sellers, providers, or landlords
receiving funds, you are in Stripe Connect, and you are making decisions about account types, payout
timing, and dispute liability that are expensive to reverse later.

**Migrations.** Moving off a legacy processor, or off Stripe's own deprecated APIs, means running two
systems correctly at once while customers keep paying.

None of these are exotic. They are the normal second act of a payments project, and they are where
projects stall.

## What Stripe certification actually verifies

"Stripe experience" on a résumé can mean someone copied a Checkout snippet once. Stripe's certification
program is a real exam, and there are two distinct tracks that get conflated:

**Stripe Certified Professional Developers** are full-stack engineers tested on hands-on implementation
using Stripe-sanctioned best practices — the API surface, the security expectations, the correct handling
of the flows above.

**Stripe Certified Implementation Architects** are tested on something harder: choosing the right technical
strategy for a business requirement, and leading developers through executing it. This is the person who
tells you that your financing model should be built on Subscription Schedules rather than a Buy Now Pay
Later integration, and can explain the tradeoff before you have written the code.

Most teams need the second one earlier than they think. The costly mistakes in payments are architectural,
not syntactic, and they get made in week one.

Echobind maintains more Stripe-certified developers and Implementation Architects than any other agency in
the United States, across both tracks. You can see the full breakdown on our
[Stripe partner page](/partners/stripe).

## What volume actually buys you

Certification proves someone knows the platform. Having shipped many integrations is what tells you which
of Stripe's many correct-looking options is the right one for your situation. A few examples from our own
work:

**When the obvious Stripe product is the wrong one.** [CNY Fertility](/work/cny-fertility-stripe-billing-implementation)
needed to offer patients financing for treatment. Stripe supports Buy Now Pay Later through Klarna and Affirm, but CNY wanted to provide their own financing, so neither was viable. We structured Stripe to collect the outstanding balance over exactly the term the patient selected at checkout. The right answer was a product built for a different purpose, applied sideways. That is not in the docs.

**When the risk is in the change, not the code.** [PlayOn! Sports](/work/helping-play-on-sports-scale-their-stripe-payments)
runs the largest high school sports ticketing platform in the US, processing over 300 transactions per second at peak on a Friday night. Their team was migrating from the legacy Charges API to Payment Intents ahead of a launch. They did not need us to write it — they needed two certified architects to spend two weeks auditing whether it would hold: correct Payment Intents flow, webhook handlers that fulfill reliably, security best practices, PCI compliance, and behavior at peak volume. Sometimes the highest-value engagement is a second set of certified eyes before you ship.

**When multiple parties need to get paid.** [Dvora](/work/dvora-stripe-rental-property-payments) needed residents, landlords, property managers, and service providers all transacting inside one app — with scheduled rent, custom proration, configurable late fees, per-subscription control over automatic versus manual charges, and saved payment methods that work across different businesses. That is Connect, Elements, and Billing composed deliberately, designed as payment flow diagrams before any code was written.

We are never without a Stripe project. That continuity is the actual product: we have already met the
failure mode you are about to discover.

## When it makes sense to hire outside help

Not every team needs to. It is worth being honest about when it does.

### You do not have an in-house engineering team

If payments infrastructure is not something you want to own and maintain, hiring specialists lets you get
the capability without building the org around it.

### Your team is capable but committed elsewhere

Your engineers could learn Stripe deeply. The question is whether the months they would spend doing it are
better spent on the product only they can build. Specialists are frequently the cheaper path once you price
the opportunity cost.

### The specific thing you need is genuinely specialized

Stripe Checkout is fast. Connect marketplaces, usage-based billing, multi-party payouts, and complex
subscription models are not. Teams often start these confidently and reach a point where they realize a
second opinion would have saved a rewrite.

### It has to be right the first time

Payments is one of the few systems where a quiet bug is a financial and compliance problem rather than a
UX annoyance. Getting the architecture reviewed before launch is materially cheaper than correcting it
after money has moved.

### You have a team and want certified oversight

Plenty of our engagements are advisory. Your engineers do the building; certified architects validate the
approach, review the implementation, and keep the project out of corners that are expensive to back out of.

If any of these sound like your situation, [tell us about your project](/contact). 

## What to ask before you hire anyone

Whoever you talk to, including us, these questions separate real experience from familiarity:

- How do you make webhook handling idempotent, and what happens when Stripe delivers the same event twice?
- Walk me through how you would model a mid-cycle plan change with proration.
- When would you use Subscription Schedules instead of Subscriptions?
- For a marketplace, how do you decide between Connect account types, and who carries dispute liability?
- How would you migrate us off our current processor without downtime or double-charging?
- What did you get wrong on a previous Stripe project, and how did you find it?

Vague answers to these are the signal. Specific answers — ideally with a story attached — are what you are paying for.

## Working with Echobind

We are a Stripe partner with certified Professional Developers and Implementation Architects on staff, and
we have built and audited Stripe integrations across healthcare, ticketing, property management, and
marketplace platforms. We take on full implementations, targeted architecture reviews, and advisory support
for teams doing the work themselves.

[Get in touch about your Stripe project](/contact), or read more about
[our Stripe practice and credentials](/partners/stripe).

---

[View on echobind.com](https://echobind.com/post/how-to-hire-stripe-developers)

---

# GPT-5: Pros, Cons, and Why You Should Try It Today 🔧

> OpenAI’s GPT-5 has officially been released as of August 2025. Knowing when to and not to use it can save you money, time, and frustration.

_By Mariah Grey · 2025-08-18_

As of August 2025, OpenAI’s GPT-5 has officially been released, and it’s already making waves. It has been noted as the most flexible and capable version of GPT thus far, but, as with every powerful tool, it’s not quite perfect. Knowing when NOT to use it can save you money, time, and frustration.

## The Pros (aka Why GPT-5 Is A BIG DEAL)

### Long-form context handling
GPT-5 can manage more than 256,000 tokens at a time (that’s equivalent to hundreds of pages of text). This makes it a great option for use cases like in-depth analysis, multi-document processing, or long-form conversations.

### Improved Reasoning and Planning
Problem-solving gets a major upgrade here, especially for multi-step processes. GPT-5 can break down your plans into steps and adapt as you go, which is awesome for coding projects (I’m looking at you, engineers), workflows, and preliminary research.

### Personalization
In GPT-5, you can tailor the output to you. From the tone and how verbose responses are, to updating the “personality”, which allows answers to feel more authentic and aligned with your brand or style.

### Safety and Compliance
Safety is a huge priority for many people, and GPT-5 understands that. It’s become more capable of responding with policy-compliant and safe outputs without stalling the conversation. This means it can tell you why things can’t be done a certain way and offers alternatives to keep you on track.

### Human-like Capabilities
GPT-5 can handle multi-part jobs, such as data summarization or generating drafts, outlining all the steps without continuous prompts.

All of these are significant improvements, especially the ability to handle large contexts, manage hundreds of pages of text, and offer comprehensive analysis. The improvement in reasoning and problem-solving is a clear benefit. Allowing technical users to hone the voice and complexity of the model makes it feel like their own, and prioritizing safety keeps users safe (maybe from themselves). Adding the ability to manage multi-part tasks and jobs without constant prompting makes GPT-5 a clear contender in the toolbox of users today.

## The Cons (aka Where GPT-5 Isn’t Quite There)

### Speed and Cost
The advanced capabilities of GPT-5 mean that it takes longer and more resources to compute. If you’re using it for giant workloads, costs can climb quickly, and the response time can be significantly increased when compared to GPT-4o.

### Over Confident
While GPT-5 is better at reasoning, it will still sometimes give wrong answers, in an extremely confident tone. This can be very dangerous for decision-making for users in a hurry who might not fact-check.

### Overcomplicated and Complex
For quick question/answer sessions, GPT-5 could easily be overkill, while also being slower and more resource-heavy than smaller models. With additional customization options, there’s more to refine. Newer (or less technical) users might find it overwhelming compared to basic models.

### Mixed Feedback
Some early users still strongly preferred GPT-4o for casual Q&A and creative writing, saying that GPT-5 felt “too technical” in some use cases. 

Even with the incredible advancements in GPT-5’s capabilities, it’s not the right option for every use case. 

- **Time-sensitive queries:** Faster (and cheaper) response times when using models like GPT-4o or smaller.  
- **Strict data isolation:** GPT-5 isn’t for you currently—it runs via cloud infrastructure, not local deployment.  
- **Financial, medical, or legal fields:** Fact-checking will continue to be critical as accuracy is still improving.  
- **High volume workloads:** If you’re hoping to use GPT-5 with a lot (read: millions) of requests, the costs will likely outweigh the benefits.  
- **Finely-tuned tasks:** GPT-5 is still too generally trained, rather than with specific models and datasets or targeted contexts.  

## Bottom Line
No matter what model you end up choosing, it’s hard to disagree with the simple fact that GPT-5 is the most versatile and advanced AI model offered to the public today. Its ability to handle complex, mult-step reasoning and large-context volume provides the brains and brawn to handle almost anything you can throw at it. Keep in mind, it’s not always about using the newest tool on the market, but the right one for your job, and GPT-5 just might be that tool.

---

[View on echobind.com](https://echobind.com/post/gpt-5-pros-cons-and-why-you-should-try-it-today)

---

# Understanding Generative AI: The Technology That's Reshaping Our Digital World

> In the rapidly evolving landscape of artificial intelligence, **Generative AI** has captured the attention of technologists, creators, and businesses alike**.** But what exactly is generative AI, and why is it causing such a transformation across industries?

_By Deloris Thompson · 2025-08-18_

In the rapidly evolving landscape of artificial intelligence, **Generative AI** has captured the attention of technologists, creators, and businesses alike**.** But what exactly is generative AI, and why is it causing such a transformation across industries?

## 

## What is Generative AI?

Generative AI creates new content, such as text, images, or other data types, in response to prompts. Such models have diverse applications across various industries, including content creation, software development, design, and beyond.  
At its core, generative AI is a model that accepts a **prompt** as input. The model then processes the prompt to output a response that is similar to the data it has already seen during training.

## 

## The Role of Prompts

**Prompts** are pieces of data that guide the model to complete its task. Prompts can include images, audio, code, or any other form of data that the model has been trained to understand.  
**Types of Prompts**

* Zero-Shot  
  * A Zero-shot prompt relies on existing knowledge. It is a single prompt that can contain instructions and additional content.  
* Few-Shot  
  * Best suited for complex tasks, few-shot prompts provide a model with multiple examples. One example is a prompt that contains a JSON response format.  
* One-Shot  
  * When a single example is provided to the model, it is considered a one-shot prompt. These work for predictable responses.

### **Models that Analyze (Discriminative Models)**

Machine Learning or ML models are known as discriminative models because they discriminate between different types of inputs. They answer closed-ended questions, which have a limited, predefined set of answers.  
These models excel at classification tasks like:

* Filtering spam  
* Identifying if a picture is a dog or a car, and more.

### 

### **Models that Imagine (Generative AI)**

In contrast, **generative models** guess what the data would be for a given prediction. These models utilize generative AI techniques in conjunction with other machine learning methods within specialized architectures. They can handle

* Drafting an email  
* Replacing an object with another in an image  
* Creating a new 3D object for a design

### 

### **Generative Adversarial Networks (GANs)**

Introduced in 2014, one of the most fascinating approaches to generative AI is **Generative Adversarial Networks (GANs)**. This type of generative AI consists of two neural networks. A generative model and a discriminative model. They are trained together in a competitive relationship. They compete with one another, one trying to trick the other. After each round, they share insights, which improve both models over time.  
Think of GANs as two AI models locked in a creative competition:

* **A generator model** attempts to create fake data that is indistinguishable from the real, trained data.  
* **A discriminator model** attempts to distinguish between real and fake data.

## 

## The Evolution of AI: Recent Breakthroughs

### **Transformers: The Game Changers**

The development of **transformers** has revolutionized the field of generative AI. These architectures provide several key advantages:

* Understand the meaning and context within the text  
* Identify the relationships between words  
* Generate human-like responses that provide useful information  
* Allow models to handle multiple prompt elements at once

## 

## The Impact and Future of Generative AI

Generative AI represents a fundamental shift in how we interact with technology. Instead of rigid, programmed responses, we now have systems that can create, adapt, and generate content that feels remarkably human-like. As these technologies continue to evolve, we can expect to see increasingly sophisticated applications across various industries. From personalized content creation to complex problem-solving, generative AI is not just changing what's possible—it's redefining what it means to be creative in the digital age.  
The journey of generative AI has only just begun, and its potential to transform how we work, create, and communicate continues to unfold before our eyes.

\*This blog post explores the fundamental concepts of generative AI, from basic definitions to advanced techniques like GANs and transformers. As this technology continues to evolve, staying informed about these developments will be crucial for anyone looking to understand and leverage AI in their work or personal projects.\*

---

[View on echobind.com](https://echobind.com/post/understanding-generative-ai-the-technology-that-s-reshaping-our-digital-world)

---

# Solving Nixpacks Node Version Issues with a custom nixpacks.toml

> If you’ve tried upgrading your app to Node.js 22+ on a hosting service like [Railway](https://railway.app/) and hit walls despite doing *everything right*, you’re not alone. We recently ran into a frustrating issue where **Nixpacks** refused to use the correct Node.js version—even though we specified it everywhere.

_By Deloris Thompson · 2025-08-18_

If you’ve tried upgrading your app to Node.js 22+ on a hosting service like [Railway](https://railway.app/) and hit walls despite doing *everything right*, you’re not alone. We recently ran into a frustrating issue where **Nixpacks** refused to use the correct Node.js version—even though we specified it everywhere.



## The Problem: Node Version Inconsistencies in Nixpacks

We needed to deploy an app that required **Node.js \>= 22.12.0** for compatibility with [Directus 11](https://docs.directus.io). But when deploying to **staging or production**, the Railway builds kept **using a version that was one patch lower than needed**, breaking the app at runtime.

We tried all the usual methods:

### What Didn't Work:

* Setting `NIXPACKS_NODE_VERSION=22,`this ENV only allows setting major versions like 22 and not 22.12.0   
* Adding `"engines": { "node": ">=22.12.0" }` in `package.json`  
* Adding an `.nvmrc` file with `22.12.0`

Despite all of that, the builds would still pick up a **lower version**, causing failure.


## The Fix: Use `nixpacks.toml` with a `nixpkgsArchive` Pin

The only reliable way to force the correct Node.js version was to **override the Nixpacks base archive** by creating a `nixpacks.toml` file:

```toml
[phases.setup]
nixpkgsArchive = '51ad838b03a05b1de6f9f2a0fffecee64a9788ee'
```

This commit hash from the [NixOS/nixpkgs repo](https://github.com/NixOS/nixpkgs) provides **Node.js 22.13.1**, which works perfectly with Directus 11\.

The correct version was picked up, and our builds succeeded.


## Why This Works

The `nixpkgsArchive` pin tells Nixpacks to use a **specific commit** of the Nix package repository, locking in the exact Node.js version available in that snapshot.

Without this, hosting sites like Railway use a default nixpkgs archive—which may lag behind or skip specific Node versions.

**Note:** This approach is similar to pinning dependencies in `package-lock.json`, but for your system-level environment.


## Finding the Right nixpkgs Commit for Your Version

Want a different Node.js version in the future? You’ll need to find the right `nixpkgs` commit. Here’s how:

1. Go to the [nixpkgs GitHub repo](https://github.com/NixOS/nixpkgs).  
2. Navigate to: `pkgs/development/web/nodejs/`  
3. Check the `v22.nix` file across commits to find the one that introduced your desired version.

### Known Working Commits

| Commit Hash | Node.js Version |
| :---- | :---- |
| `51ad838b03a05b1de6f9f2a0fffecee64a9788ee` | ✅ 22.13.1 (Confirmed working) |
| `bf744fe90419885eefced41b3e5ae442d732712d` | ✅ 22+ versions available |
| `ffeebf0acf3ae8b29f8c7049cd911b9636efd7e7` | ⚠️ 22.14.0 (from master, may be unstable) |

For more info, check out [Nixpacks GitHub Issue \#1017](https://github.com/railwayapp/nixpacks/issues/1017), where this workaround is discussed.


By using `nixpkgsArchive`, you get deterministic builds and avoid the frustrations of version mismatches, especially when platform requirements (like Directus needing Node \>=22) are strict.

Let us know if you’ve hit this and found another workaround. Happy deploying\!

# Resources

* [Nixpacks Documentation](https://nixpacks.com/docs/configuration/file)

---

[View on echobind.com](https://echobind.com/post/solving-nixpacks-node-version-issues-with-a-custom-nixpacks-toml)

---

# Upgrading Directus from v10 to v11: A Safe and Reliable Guide

> Upgrading from Directus 10 to 11 brings significant improvements and important changes that require planning. In this guide, we’ll walk through how to safely upgrade your Directus instance from version 10.5.3 to 11.10.0 without risking data loss or breaking your app.

_By Deloris Thompson · 2025-08-18_

When I first learned I'd be upgrading Directus, I felt a familiar mix of confidence and apprehension. Having upgraded packages before, I knew the general process, but Directus is different. Schema changes, dropping outdated fields, or not typing them in are potential issues with CMS upgrades. As I dove into the upgrade process, I quickly realized this wasn't just another package update. The extra steps, like backing up the database first reminded me that production upgrades require a different mindset than development work. The local upgrade went smoothly, which gave me a false sense of security. Then came the deployment headache. Nixpacks refused to build with the Node.js version specified in our engine, and that's when the real challenge began. What started as a routine upgrade turned into a day-long puzzle that required creating a [custom nixpack file](https://docs.google.com/document/d/1HQ88BbIRYAzE-kDa75HdD9dmEXZd48idK4WbvEXEgag/edit?tab=t.0#heading=h.m7gs0cwmxhkh). By the end, I felt both exhausted and accomplished.  The upgrade pushed me to understand deployment infrastructure in ways I hadn't before, turning what could have been a simple package update into a valuable learning experience about production deployment complexity. 

## Important: Directus 11 Requires Node.js ≥ 22

Before starting the upgrade, make sure your local and deployment environments are running **Node.js version 22 or higher**.

### Check your Node version:

```bash
node -v
```

If it's lower than `22`, upgrade Node before proceeding. We recommend using a version manager like [`nvm`](https://github.com/nvm-sh/nvm) or asdf:

```bash
nvm install 22.12.0
nvm use 22.12.0
```

### Set Node version in `package.json`

To ensure your deployment environment (e.g., Railway, Vercel, Netlify) uses the correct version, update your `package.json`:

```json
"engines": {
  "node": ">=22.12.0"
}
```

### Watch for breaking changes in dependencies

Upgrading Node may break other packages in your project. After switching Node versions, run:

```bash
# NPM
npm install

# OR Yarn
yarn install
```

And resolve any errors or dependency issues before proceeding.

### Example Error You Might See If Using Node \< 22

```bash
The engine "node" is incompatible with this module. Expected version ">=22.12.0". Got "18.20.4"
error Found incompatible module.
```

## Step 1: Review Breaking Changes

Before upgrading, it’s critical to review **all breaking changes**, not just those in the most recent version.  
Review the [Directus breaking changes](https://directus.io/docs/releases/breaking-changes) to catch:

* Field and API behavior changes  
* Role/permission updates  
* Any deprecated features or schema tweaks  
* Core system architecture changes  
* Extension/plugin compatibility notes  
* Auth and API adjustments

Understanding what changed ensures you're not caught off guard after the upgrade.

## Step 2: Prepare a Local Testing Environment

To avoid surprises in production, create a **local copy** of your staging (or production) environment.

### Clone the staging environment:

* Export the current database  
* Copy your `.env`  
* Pull your current Docker setup (if applicable)

```bash
# Example: Export DB
pg_dump -U your_user -h staging-db-host your_db > staging_backup.sql
```


## Step 3: Backup Everything

Always take a backup of your **database** before any major upgrade.

Whether you're working locally or pushing to staging, never upgrade without a clean rollback plan.

## Step 4: Upgrade the Directus Version

Update your Directus package to version `11.10.0`. 

### If using NPM/Yarn:

```bash
# NPM
npm install directus@11.10.0

# OR Yarn
yarn add directus@11.10.0
```

### If using Docker:


If you are self-hosting or using Docker for your build, this step is important.  
Update the `Dockerfile` or `docker-compose.yml` to use either V11.10.0 or the latest image:  
**v11.10.0:**

```
services:
  directus:
    image: directus/directus:11.10.0
```

**Latest:**

```
services:
  directus:
    image: directus/directus:latest
```

Then rebuild:

```bash
docker-compose build
docker-compose up
```


## Step 5: Run Migrations Locally

After upgrading, run the Directus migration command **only in your local environment** to apply any necessary schema changes and confirm your data structure is still intact:

```bash
npx directus migrate:latest
```

**Note:** On staging and production, migrations will run **automatically** during deployment, so no need to run this manually there.

## Step 6: Test Everything Locally

Before deploying, verify your project works as expected:

* Log in to the Admin Panel  
* Verify collections, fields, and relationships  
* Run common API queries  
* Test filters, roles, and permissions  
* Check custom endpoints or hooks  
* Confirm plugins or extensions still work

This helps you catch breaking issues before they hit your users.


## Step 7: Deploy to Staging, Then Production

Once everything checks out locally:

1. Deploy to your **staging** environment  
2. Verify everything again in staging  
3. Then deploy to **production**


## Optional: Clean Up

After deployment:

* Update your internal documentation  
* Remove deprecated config or unused fields  
* Ensure backup schedules are still intact

## You're Done\!

Enjoy the performance improvements, new features, and better developer ergonomics\! Need help upgrading? Reach out and schedule a call today\!

# Resources

* [Directus Documentation](https://directus.io/docs/)  
* [Nixpacks Documentation](https://nixpacks.com/docs/configuration/file)

---

[View on echobind.com](https://echobind.com/post/upgrading-directus-from-v10-to-v11-a-safe-and-reliable-guide)

---

# How to Add Stripe Embedded Checkout to Rails 8

> Stripe's embedded checkout allows you to accept payments directly within your Rails app, eliminating the need to redirect users to external pages. This guide will help you to get it working with Rails 8 and Hotwire.

_By Deloris Thompson · 2025-08-18_

Stripe's embedded checkout allows you to accept payments directly within your Rails app, eliminating the need to redirect users to external pages. This guide will help you to get it working with Rails 8 and Hotwire.

## What You'll Build

A page that renders Stripe's embedded checkout form directly in your Rails app. That's it. No database, no user management, no webhooks \- just the core integration.

## Prerequisites

- Rails 8 app with Hotwire  
- Stripe account (test mode or sandbox)

## Step 1: Set up Dependencies

Add the following directly to your Gemfile and run bundle install:  
[Ruby Gems: Stripe](https://rubygems.org/gems/stripe)

```bash
gem 'stripe', '~> 15.3'
gem 'dotenv-rails', '~> 3.1', '>= 3.1.8'
```

Add the JavaScript SDK:

```bash
NPM
npm install @stripe/stripe-js

yarn
yarn add @stripe/stripe-js
```

## Step 2: Configure Stripe

Add the following to your **.env** file

```
STRIPE_PUBLISHABLE_KEY=pk_test_your_publishable_key_here
STRIPE_SECRET_KEY=sk_test_your_secret_key_here
STRIPE_PRICE_ID=price_your_product_price_id_here
```

Create the initializer:

```
# config/initializers/stripe.rb
Stripe.api_key = ENV["STRIPE_SECRET_KEY"]
```

## Step 3: Create the Checkout Service

This service class handles the Stripe API integration with clean, focused responsibility

```ruby
# app/services/checkout_service.rb
class CheckoutService
  def initialize(return_url:)
    @return_url = return_url
  end

  def create_checkout_session
    Stripe::Checkout::Session.create({
      line_items: [{
        price: ENV["STRIPE_PRICE_ID"],
        quantity: 1
      }],
      mode: "payment",
      payment_method_types: ["card"],
      return_url: @return_url,
      ui_mode: "embedded"
    })
  end
end
```

## Step 4: Create the Stimulus Controller & Register it

Run the following command in your terminal to generate the controller and register it in the `app/javascript/controllers/index.js` file

```bash
./bin/rails generate stimulus stripeCheckout
```


```javascript
// app/javascript/controllers/stripe_checkout_controller.js
import { Controller } from "@hotwired/stimulus"
import { loadStripe } from '@stripe/stripe-js'

export default class extends Controller {
  static values = {
    publishableKey: String,
    clientSecret: String
  }
  
  async connect() {
    const stripe = await loadStripe(this.publishableKeyValue)
    
    const checkout = await stripe.initEmbeddedCheckout({
      clientSecret: this.clientSecretValue
    });
  
    checkout.mount(this.element);
  }
}
```

This Stimulus controller handles the frontend payment interface with minimal code:  
Configuration: The controller expects two data attributes from the Rails view:

- publishableKey \- Your Stripe public key for client-side operations  
- clientSecret \- The checkout session secret from your Rails controller

The **connect()** method runs automatically when the controller connects to a DOM element and:

- Loads the Stripe JavaScript library using your publishable key  
- Initializes Stripe's embedded checkout component with the client secret  
- Mounts the complete checkout form directly into the HTML element

## Step 5: Update the Desired Controller

This Rails controller handles the core functionality of a Stripe checkout flow in just two actions:  
The **show** action initiates the checkout process by:

- Creating a new CheckoutService instance with a return URL for post-payment redirects  
- Generating a Stripe checkout session through the service  
- Extracting the client\_secret from the session to pass to the frontend for payment processing

The **return** action handles the post-payment flow by:

- Processing successful payments (this is where you'd typically update order status, send confirmation emails, etc.)  
- Redirecting users back to the homepage with a success message

```ruby
# app/controllers/checkout_controller.rb
class CheckoutController < ApplicationController
  def show
    checkout_service = CheckoutService.new(return_url: return_checkout_url)
    checkout_session = checkout_service.create_checkout_session
    @client_secret = checkout_session.client_secret
  end

  def return
    # Handle successful payment
    redirect_to root_path, notice: "Payment successful!"
  end
end
```

## Step 6: Set up Routes

```ruby
# config/routes.rb
Rails.application.routes.draw do
  root "checkout#show"
  
  resource :checkout, only: [:show] do
    get :return, on: :collection
  end
end
```

## Step 7: Create the View

```erb
<!-- app/views/checkout/show.html.erb -->
<div class="container mx-auto px-4 py-8">
  <h1 class="text-2xl font-bold mb-6">Complete Your Purchase</h1>
  
  <div class="max-w-md mx-auto">
    <div data-controller="stripe-checkout"
         data-stripe-checkout-publishable-key-value="<%= ENV['STRIPE_PUBLISHABLE_KEY'] %>"
         data-stripe-checkout-client-secret-value="<%= @client_secret %>">
      <!-- Stripe embedded checkout loads here -->
    </div>
  </div>
</div>
```

Simple Stripe Checkout View  
This minimal Rails view creates a clean checkout page with just a few lines of HTML:  
**The Structure:**

* Uses Tailwind CSS for styling with a centered container layout  
* Displays a "Complete Your Purchase" heading  
* Contains a div that connects to the Stimulus controller

**The Magic Happens in the data-controller div:**

* data-controller="stripe-checkout" connects to your Stimulus controller  
* data-stripe-checkout-publishable-key-value passes your Stripe public key from environment variables  
* data-stripe-checkout-client-secret-value passes the checkout session secret from your Rails controller

**The Result:** When the page loads, the Stimulus controller automatically transforms the empty div into a complete Stripe checkout form with card fields, payment buttons, and error handling.  
**Pro Tip:** You can extract this into a partial for reusability:

## Testing

1. Start your server: `./bin/dev`
2. Visit `http://localhost:3000` 
3. Test with card: `4242 4242 4242 4242`

## Don't Forget \- Additional Setup Required

This guide gets Stripe embedded checkout working, but for a production application, you'll need:

### Required for Production

- **Webhooks** \- Handle payment events (`checkout.session.completed`, `payment_intent.succeeded`)  
- **Database** **models** - Store orders, payments, and customer data  
- **User authentication** - Track who made purchases  
- **Error handling** - Handle Stripe API failures gracefully

That's it\! You now have Stripe embedded checkout working in Rails 8\. The checkout form renders directly in your app without any redirects. At Echobind, we have experience working with Stripe and can help you integrate it in a new or exisiting application.

---

[View on echobind.com](https://echobind.com/post/how-to-add-stripe-embedded-checkout-to-rails-8)

---

# AI in Healthcare: Skip the Buzzword Bingo

> "AI in Healthcare: Skip the Buzzword Bingo" cuts through the hype to show healthcare leaders how to start small, solve real problems, and see quick wins with AI. No jargon. No million-dollar price tags. Just practical steps to make healthcare a little less painful for staff and patients alike.

_By Lex Meola · 2025-08-08_

## AI in Healthcare: Skip the Buzzword Bingo

You've heard about AI at conferences, board meetings, and probably your neighbor's barbecue. Congratulations—you're officially living in the future, where every conversation somehow circles back to ChatGPT.

Here's the thing: AI doesn't require a PhD in computer science or your entire IT budget. You can start small without betting the farm.

## Why AI Sounds Impossibly Complicated

Because everyone calls everything "AI." Machine learning finds patterns in patient data. Natural language processing reads medical notes faster than your residents. Automation handles the paperwork nobody wants to do. Different tools, same hype-laden umbrella term.
No wonder it feels like drinking from a fire hose.

## AI You're Already Using (Without Realizing It)

Your hospital probably runs AI that doesn't announce itself with fanfare:
- Patient intake forms that actually make sense
- Lab results that get flagged before someone has to manually review 847 normal cholesterol levels
- No-show predictions that aren't based on reading tea leaves
- Insurance claims that code themselves

Boring? Maybe. Useful? Absolutely.

## Three Myths Keeping You Stuck

**"It costs a fortune."** Small pilots cost less than your last consultant's PowerPoint deck.

**"We'll fire everyone."** Unless your goal is replacing doctors with robots, AI mostly handles tasks humans hate doing anyway.

**"We need to revolutionize everything overnight."** Or you could start with one annoying workflow and see what happens.

## How to Actually Get Started

1. Pick something genuinely annoying — prior authorizations, patient scheduling, whatever makes your staff contemplate career changes
2. Find a partner who knows HIPAA exists — surprisingly not everyone does
3. Run a short pilot — 6 weeks, not 6 months
4. Check if it actually worked — radical concept, we know

## The Real Point

AI isn't about being trendy or impressing other executives. It's about making healthcare slightly less painful for everyone involved. Start small, stay practical, and ignore anyone who uses "paradigm shift" unironically.

---

[View on echobind.com](https://echobind.com/post/ai-in-healthcare-simplified)

---

# How to Set Up Stripe Terminal in React Native with Expo

> Build a mobile payment app with Stripe Terminal and React Native using Expo, covering reader discovery, connection, and in-person payments on iOS.

_By Preston Kelly · 2025-08-07_

In this guide, we'll walk through the high level steps you'll need to build a mobile payment app using [Stripe Terminal](https://stripe.com/terminal) and React Native. This guide will be the framework for a complete solution, you'll need to add your own UI, styling, error handling, etc. We'll focus on iOS, the principles are similar but not identical for Android. This guide uses [Expo](https://docs.expo.dev/) to simplify development. 

## Why Stripe Terminal?

Stripe Terminal provides a solution for accepting in-person payments using your device. It's ideal for:
- Small businesses looking to accept card payments
- Service providers who need to accept payments on the go
- Developers building custom point-of-sale solutions
- Retail stores requiring reliable payment processing

## Prerequisites

Before we dive in, make sure you have:
- iOS 16.7 or later
- Xcode 14 or later
- An Apple Developer account
- A Stripe account
- A compatible Bluetooth card reader
- Node.js and Expo CLI installed (npm install -g expo-cli)
- A physical iOS device

## Implementation Guide

### 1. Create a new Expo app

Create an Expo app with the following command:

```bash
npx create-expo-app@latest
```

### 2. Setting Up Dependencies

Let's install the necessary packages:

```bash
npm install @stripe/stripe-terminal-react-native@0.0.1-beta.24 expo-build-properties@0.14.6
```

### 3. Configuring Your App

Create or update your `app.config.ts` with the following configuration:

```typescript
import type { ConfigContext, ExpoConfig } from 'expo/config';

export default ({ config }: ConfigContext): ExpoConfig => {
  return {
    name: 'stripe-terminal-app',
    slug: 'stripe-terminal-app',
    version: '1.0.0',
    orientation: 'portrait',
    icon: './assets/images/icon.png',
    userInterfaceStyle: 'automatic',
    ...config,
    ios: {
      ...config.ios,
      bundleIdentifier: 'com.yourcompany.stripe-terminal-app',
    },
    plugins: [
      ...(config.plugins || []),
      [
        'expo-build-properties',
        {
          ios: {
            deploymentTarget: '16.7',
            useFrameworks: 'static',
          },
        },
      ],
      [
        '@stripe/stripe-terminal-react-native',
        {
          bluetoothBackgroundMode: true,
          locationWhenInUsePermission: 'Location access is required for payments.',
        },
      ],
    ],
  };
};
```

### 4. Setting Up the Backend

First, we need to set up a backend server to handle [connection tokens](https://docs.stripe.com/api/terminal/connection_tokens). Connection tokens are used by the Stripe SDK to connect to a reader. 

Create a simple [Express](https://expressjs.com/) server to handle connection tokens:

```typescript
const express = require('express');
const stripe = require('stripe')('YOUR_STRIPE_SECRET_KEY');
const app = express();

app.use(express.json());

app.post('/connection_token', async (req, res) => {
  try {
    const token = await stripe.terminal.connectionTokens.create();
    res.json({ secret: token.secret });
  } catch (error) {
    res.status(500).json({ error: error.message });
  }
});

app.listen(3000, () => console.log('Server running on port 3000'));
```

### 5. Creating the Terminal Provider

Now that we have our backend server running, we can create a Terminal Provider that will use the connection token endpoint:

```typescript
import { StripeTerminalProvider } from '@stripe/stripe-terminal-react-native';
import { ReactElement } from 'react';

const fetchTokenProvider = async () => {
  const response = await fetch('YOUR_BACKEND_URL/connection_token', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
    },
  });
  const { secret } = await response.json();
  return secret;
};

export function TerminalProvider({ children }: { children: ReactElement }) {
  return (
    <StripeTerminalProvider
      logLevel="verbose"
      tokenProvider={fetchTokenProvider}
    >
      {children}
    </StripeTerminalProvider>
  );
}
```

### 6. Building the Payment Screen

Create a payment screen that allows the user to discover readers, connect to a reader, and process a payment. For a more complete solution, you'll likely want a separate screen for reader management. For our high level example, we'll create a single screen that handles discovery, connection, and payment. Here are the essential code snippets:

**Initialize Stripe Terminal:**
```typescript
const { 
  initialize, 
  discoverReaders, 
  connectReader, 
  createPaymentIntent,
  collectPaymentMethod,
  confirmPaymentIntent 
} = useStripeTerminal();
useEffect(() => {
  initialize();
}, [initialize]);
```

**Discover Readers:**
```typescript
const handleDiscoverReaders = async () => {
  await discoverReaders({ discoveryMethod: 'bluetoothScan' });
};
```

> **Note:** The `useStripeTerminal` hook provides several callbacks, such as `onUpdateDiscoveredReaders`. You can use this callback to update your component state with the list of discovered readers, allowing you to display them in your UI and let the user select which reader to connect to.

**Connect to a Reader:**
```typescript
const handleConnectReader = async (reader: Reader.Type) => {
  await connectReader({ reader }, 'bluetoothScan');
};
```

**Process a Payment:**
```typescript
const handlePayment = async () => {
  // Create the payment intent
  const { error: intentError, paymentIntent } = await createPaymentIntent({
    amount: 1000, // $10.00
    currency: 'usd',
    captureMethod: 'automatic',
  });
  if (intentError) return;

  // Collect the payment method
  const { error: collectError, paymentIntent: collectedIntent } = await collectPaymentMethod({
    paymentIntent,
    updatePaymentIntent: true,
  });
  if (collectError) return;

  // Confirm the payment
  await confirmPaymentIntent({ paymentIntent: collectedIntent });
};
```

**UI Example:**
```typescript
return (
  <View>
    <Button title="Discover Readers" onPress={handleDiscoverReaders} />
    <Button title="Process $10.00 Payment" onPress={handlePayment} />
  </View>
);
```

### 7. Running the App on a Physical Device

To test the Stripe Terminal integration, you'll need to run the app on a physical device. This is because:
- Bluetooth functionality requires a real device to work properly
- The iOS Simulator doesn't support Bluetooth connections
- Stripe Terminal SDK requires actual hardware to communicate with card readers

Run the following command to build and install the app on your connected device:

```bash
npx expo run:ios --device
```

Make sure your device is:
- Connected to your Mac via USB
- Unlocked and trusted
- Developer mode enabled in (Settings > Privacy & Security)

## Next Steps

1. Add loading states and progress indicators
2. Implement reader reconnection logic
3. Add payment confirmation and receipt handling
4. Implement proper state management
5. Add error recovery mechanisms
6. Reach out to [Echobind](https://echobind.com/contact) for a complete solution

## Resources

- [Stripe Terminal Documentation](https://stripe.com/docs/terminal)
- [React Native Documentation](https://reactnative.dev/)
- [Expo Documentation](https://docs.expo.dev/)

## Production-Ready Solutions with Echobind

Connecting to a reader is just the beginning. While this guide covers the basics of implementing Stripe Terminal in a React Native app, building a production-ready payment solution requires additional considerations such as handling for edge cases where a reader may disconnect unexpectedly, software updates, loading states, and location management. At Echobind, we have experience working with Stripe Terminal and can help you build a complete payment solution.

### Advanced Features
Here are some examples of advanced features you might want for a complete solution

1. **Stripe Location Management**
   - Dynamic location registration and updates
   - Multi-location support for businesses
   - Location-based reader assignment
   - Automated location verification

2. **Reader Management**
   - Automatic reader updates and firmware management
   - Reader health monitoring and diagnostics
   - Battery level tracking and notifications
   - Reader registration and deactivation workflows

3. **Error Handling**
   - Automatic reconnection strategies
   - Offline mode support
   - Transaction recovery mechanisms
   - Comprehensive error logging and monitoring

4. **Analytics and Reporting**
   - Real-time transaction monitoring
   - Custom reporting dashboards
   - Performance analytics
   - Error rate tracking

[Contact Echobind](https://echobind.com/contact) to discuss how we can help build your complete payment solution.

---

[View on echobind.com](https://echobind.com/post/stripe-terminal-in-react-native-with-expo)

---

# How to Use LLMs Without Turning Your Brain to Mush

> Keep your brain sharp while using AI: Think before prompting, fact-check everything, and know when to step away. Get the efficiency without the mental atrophy.

_By Lex Meola · 2025-08-01_

![](https://cms.echobind.com/assets/51abc0ff-044b-43f7-8d2a-b852a72db199)


## How to Use LLMs Without Turning Your Brain to Mush

Language models are incredible tools—like having an enthusiastic intern who never sleeps and occasionally lies with confidence. But the more we outsource thinking to them, the easier it becomes to stop thinking critically altogether.

Here's how to harness LLMs without letting your brain atrophy.

## Treat LLMs Like a Collaborator, Not a Crutch

Good prompts reflect your thinking, not replace it. Instead of "write me a blog post," try "outline a post for busy CTOs who want AI efficiency without fluff" or "give me three angles—practical, contrarian, funny."

You direct the ideas. The LLM speeds up execution.

## Fact-Check Everything

LLMs are confident, well-spoken liars. Verify anything that sounds too slick, especially stats, quotes, legal advice, or technical details. Half those "Einstein" quotes are fake anyway.

Think accelerator, not truth engine.

## Keep Your Voice

Generic AI writing is easy to spot—and worse when passed off as yours. Don't copy-paste. Edit ruthlessly: add your perspective, match your tone, break the symmetry LLMs love.

Your job is injecting you back into the draft.

## Use Prompts as Thinking Tools

Ask the model to argue against you, simplify without dumbing down, or roleplay your audience. You're not just producing content—you're pressure-testing ideas.

## Know When to Stop

If you're "prompt-spiraling" through dozens of variations, step away. The model can't think for you if you haven't figured out what you're trying to say.

Journal. Whiteboard. Talk it out. Come back when you're clear.

**Bottom line:** Think before prompting. Edit like it matters. Question everything. Add your perspective. Take the wheel when needed.

You can keep your brain and save time. That's the future worth having.

![](https://cms.echobind.com/assets/0fbbda92-ced3-4d34-94f3-edc22401c09d)

---

[View on echobind.com](https://echobind.com/post/how-to-use-llms)

---

# The Hallway Conversations Method: Uncovering Healthcare Requirements (Even When There Are No Hallways)

> Why the most critical healthcare software requirements never make it into formal meetings—and how to find them in Slack DMs, pre-call chats, and accidental screen shares. A practical guide to uncovering what users really need when everyone's working remotely.

_By Lex Meola · 2025-07-25_

## The Hallway Conversations Method: Uncovering Healthcare Requirements That Don't Make It to Meetings (Even When There Are No Hallways)

Here's a fun fact: The most important requirements for your healthcare software project will never be mentioned in your requirements meeting.

I know, I know. You spent weeks scheduling that stakeholder Zoom. You had a beautiful agenda. Everyone nodded enthusiastically as you walked through user stories. And somehow, six months later, you're staring at a technically perfect piece of software that doctors avoid like expired cafeteria sushi.

Welcome to healthcare development, where the real requirements live in hallway conversations—even when the hallways are virtual.

## The Conference Room Charade (Now in HD)

![](https://cms.echobind.com/assets/5d9413b5-00b2-48af-a59f-e489db2db214)

Let me paint you a picture. You're staring at a grid of faces in Brady Bunch formation, muted microphones, and carefully curated backgrounds. The department head is present. The IT director has joined. Maybe—if you're lucky—one actual end user who's been voluntold to attend and is clearly multitasking.

Everyone's on their best behavior. The official process gets described in glowing terms. Pain points are diplomatically minimized. "Oh, that workaround? It's really no big deal."

Meanwhile, in Slack channels you're not invited to, nurses are having a completely different conversation about how that "no big deal" workaround adds forty-five minutes to their shift and makes them question their life choices.

The hierarchy dynamics in healthcare are real, and they're spectacular at suppressing honest feedback—whether you're in person or on screen. Nobody wants to be the person who admits the current system is held together with digital duct tape and prayers, especially when the meeting is being recorded.

## Where the Truth Lives Now

![](https://cms.echobind.com/assets/32d9c377-7307-4f7b-aab2-757d698c57e8)

The magic still happens in the spaces between meetings—they're just different spaces.

It's the Slack DM that starts with "Hey, quick question" and ends with a dissertation on workflow dysfunction. The five minutes before everyone joins the call when someone's got their guard down. The Teams message that begins "This might be a dumb question, but..." and reveals the fundamental flaw in your entire approach.

It's the casual phone call that was supposed to be about scheduling but turns into a therapy session about why everyone hates the new system. The screen share that was meant to show you one thing but accidentally reveals the seventeen browser tabs of workarounds they've got running.

These aren't edge cases. These are Tuesday.

## The Art of Strategic Digital Loitering

![](https://cms.echobind.com/assets/2b7be63d-431b-4266-8a9c-d1938ee4dfe2)

Here's your new job description: Professional Slack Lurker with Purpose.

Join the channels where actual work happens, not just the official project ones. Pay attention to the side conversations during virtual meetings. Notice who's active at weird hours (hello, night shift) and reach out individually.

But—and this is crucial—don't show up in someone's DMs with a clipboard and an agenda. Show up as a human being who's genuinely curious about how people's days are going. Ask about their workflow after you've asked about their weekend. Let conversations flow naturally toward the pain points that keep them up at night.

## The New Venues for Truth-Telling

![](https://cms.echobind.com/assets/2aa8b711-02df-4714-b9ee-4afb56b7d8e2)

**The Pre-Meeting Chat:**
Those precious five minutes before the official meeting starts when people are more honest about what's actually broken.

**The DM Follow-Up:** 
Hey, you mentioned something in the meeting about that being frustrating—mind if I ask what you meant by that?"

**The Screen Share Accident:** 
When someone's showing you their desktop and you notice the sticky notes, multiple browser tabs, and Excel sheets that clearly represent unofficial workarounds.

**The Phone Call That Goes Long:**
When a "quick sync" turns into an hour-long downloading session about everything that's wrong with their current tools.

**The Cross-Timezone Conversation:** 
Reaching out to night shift, weekend staff, and remote workers who experience completely different versions of your "standard" workflow.

## What You're Actually Listening For

![](https://cms.echobind.com/assets/1bf05953-2b77-4431-b288-ab7a0c76b9da)

Forget feature requests. Listen for the digital equivalent of sighs. The delayed responses that suggest internal eye-rolling. The phrases like "we just deal with it" or "it is what it is" buried in otherwise professional messages.

Pay attention to what they share in their screen shares that they didn't mean to show you. Notice the bookmark folders labeled "Workarounds" or the shortcuts to tools that aren't in your official tech stack. Watch for the elegant solutions they've MacGyvered together that should probably be actual features.

## The $2 Million Reality Check (Remote Edition)

![](https://cms.echobind.com/assets/306fbc41-3ddf-4256-a94c-78bedf4dce48)

I once watched a development team spend eighteen months building a beautiful, HIPAA-compliant scheduling system. Every stakeholder Zoom was a lovefest. The demos were flawless. The security audit was pristine.

It launched to the sound of digital crickets.

Turns out, during a casual phone call about something completely unrelated, I learned that the scheduling workflow they'd optimized for happened maybe 20% of the time. The other 80% involved emergency changes, last-minute substitutions, and the kind of clinical chaos that doesn't fit neatly into user stories—and definitely doesn't happen during business hours when all our meetings were scheduled.

The informal conversations would have caught that. The formal Zoom never had a chance.

## Making It Official (Without Killing the Magic)

![](https://cms.echobind.com/assets/bbf6d43f-f89c-4c72-a55a-c6a7e2397c67)

The tricky part is turning these informal digital insights into actionable requirements without losing the authenticity that made them valuable in the first place. Document the patterns, not the gossip. Look for themes across multiple casual conversations. Validate what you're hearing through broader observation.

And please, for the love of all that is holy, don't paste someone's candid Slack message into the next requirements document. That's how you lose your informal access faster than you can say "HIPAA violation."

## The Remote Advantage (Yes, Really)

![](https://cms.echobind.com/assets/2a71e224-79a6-4639-bb18-b9a97ab5ddfe)

Here's the thing: Remote actually gives us some superpowers for this kind of intelligence gathering. People are more likely to be honest in a private DM than they ever were in a hospital hallway where their boss might walk by. You can reach people across shifts and time zones. You can have longer, more thoughtful async conversations.

The asynchronous nature of remote work means people can think before they respond, leading to more nuanced feedback than the quick hallway chat ever provided.

## The Uncomfortable Truth

![](https://cms.echobind.com/assets/5f018035-8c56-4192-9103-38e16b0824a9)

Healthcare software fails not because we can't build technically sound systems. We fail because we optimize for the workflows that exist in policy manuals instead of the ones that exist in reality—whether that reality is happening in a hospital corridor or scattered across Slack channels and video calls.

The hallway conversations method isn't revolutionary. It's just paying attention to what people are already telling us, if we're willing to listen in the right (virtual) places.

Your users are talking. The question is: Are you in the channel where it happens?

Or better yet—are you building the trust that makes them want to tell you what's really going on?

*Next time you finish a requirements call, don't close Zoom and move on to the next meeting. Send a few follow-up messages. Schedule some informal coffee chats. Join the Slack channels where actual work gets discussed. You might be surprised what you learn when nobody's recording the conversation.*

![](https://cms.echobind.com/assets/a21d6103-211f-4168-a758-9de091a67bbe)

---

[View on echobind.com](https://echobind.com/post/the-hallway-conversations-method)

---

# What Makes a Great Client-Agency Relationship (From an Account Manager's POV)

> This blog explores the intentional practices behind exceptional client-agency relationships, drawing on lessons from managing dozens of partnerships. It outlines four core pillars—trust, alignment, communication, and advocacy—and offers real-world examples to show how strong relationships drive better outcomes, smoother launches, and long-term collaboration.

_By Lex Meola · 2025-07-18_

**Building Exceptional Client-Agency Relationships**

Some client relationships feel like creative magic. Others feel like death by Slack thread. After managing dozens of partnerships, I’ve learned the difference isn’t luck—it’s intentionality.

Great client-agency relationships lead to better outcomes: faster timelines, smoother launches, and partnerships that extend beyond single projects. After managing dozens of relationships, I've identified three pillars that separate good partnerships from exceptional ones.

![](https://cms.echobind.com/assets/1d0839b4-eeee-4754-b3bd-62943fa570b5)

**Trust Is Earned Early**

First impressions aren't just important—they're everything. Trust isn't built through perfection; it's built through honesty.

The most powerful phrase in my arsenal? "We don't know yet, but here's how we'll find out." Clients don't expect you to have all the answers on day one—they expect transparency about what you do and don't know.

I once worked with a startup founder who had aggressive launch deadlines tied to a major conference. Instead of nodding along, I walked him through our discovery process and explained why rushing would cost more time and money later. "I'd rather disappoint you now with realistic expectations than surprise you later with delays," I told him. That conversation set the foundation for one of our strongest relationships, and we launched two weeks ahead of schedule because we'd planned properly.

Transparency in estimates and timelines isn't just about managing expectations—it's about respecting your client's business.

![](https://cms.echobind.com/assets/38b8866e-1296-4ad4-b737-367952304550)

**Alignment Isn't a One-Time Event**

Projects drift. Priorities shift, market conditions change, new opportunities emerge. The difference between successful partnerships and frustrating ones isn't whether these changes happen—it's how you handle them.

Alignment is an ongoing practice, not a checkbox. I build regular check-ins into every project, not just to report status but to confirm we're still solving the right problems in the right ways. Sometimes it's a quick Slack message: "Is this still the priority, or should we pivot based on that customer call?"

Documentation becomes your lifeline. Meeting notes, decision logs, and project updates aren't just for accountability—they're your shared source of truth when memories get fuzzy or new stakeholders join.

As an account manager, you're constantly translating between business needs and technical execution. Your client might say, "We need this to be more engaging," while your development team needs specifics: animation, interactivity, or content strategy? Your job is bridging that gap.

I worked with a client whose priorities seemed to shift weekly. Instead of getting frustrated, I instituted five-minute "priority check-ins" every Monday morning. Sometimes we nailed the choreography, sometimes we stepped on each other’s toes. But we stayed in sync.

![](https://cms.echobind.com/assets/302b302f-9218-41d4-a65e-ff3735169376)

**Communication Is Everything**

If trust is the foundation and alignment is the framework, communication is the electricity that powers everything else. But it's not just about frequency—it's about intentionality.

The best client relationships have rhythm: standing meetings for strategic discussions, async updates for progress reports, and clear escalation paths for urgent issues. Your clients shouldn't have to guess when they'll hear from you next.

Tone matters more than most realize. In status updates, clarity beats cleverness. In tough conversations, empathy beats defensiveness. When delivering bad news: lead with the problem, follow with your plan to address it, end with next steps.

The biggest communication sin? Going dark. Nothing kills trust faster than "black box syndrome"—when clients feel like their project disappeared into your agency. Even when there's nothing dramatic to report, a simple "Here's where we are, here's what's next" keeps the relationship warm and anxiety low.

I once had a technical discovery take twice as long as expected, revealing complexities that would impact timeline and budget. Instead of waiting for all the answers, I called immediately: "Here's what we've learned, here's what it means, and here's how I recommend we adjust." That conversation could have been tense, but because I led with transparency and came prepared with solutions, it strengthened our relationship.

![](https://cms.echobind.com/assets/50c3f58f-d096-4d3b-93a7-092bbe7efe0f)

**Advocate, Not Order-Taker**

The best account managers wear two hats: fierce advocates for their clients internally, and trusted advisors externally. This dual role is where real value gets created.

Internally, you're your client's voice in every design review and development session. When the creative team debates approaches, you can say, "Based on what I know about their customers, option B aligns better with their goals."

Externally, you're guiding clients toward what's realistic, strategic, and valuable. Being consultative means occasionally saying no to requests that don't serve their best interests—even when they think they want them.

I remember a client who wanted to add a complex feature late in development because a competitor launched something similar. Instead of just estimating the work, I dug deeper: "Help me understand the business impact you're hoping for." We realized the feature wouldn't serve their core users and would delay launch by six weeks. Instead, we identified a simpler solution that achieved the same business goal in half the time.

Being valuable means being consultative. Your clients have plenty of vendors who will do exactly what they ask for. What they need is a partner who will help them figure out what they should be asking for in the first place.

![](https://cms.echobind.com/assets/25cca8c2-5654-4119-85c7-321feaaa69e7)

**Conclusion**

Strong client-agency relationships don't happen by accident—they're built through intention, consistency, and mutual respect. When trust, alignment, and communication are in place, projects stop feeling like negotiations and start feeling like collaborations. Problems become puzzles to solve together rather than blame to assign.

The businesses that thrive long-term aren't just those with the best products—they're the ones that build the best relationships. As an account manager, you have the privilege and responsibility of being the architect of those relationships.

If you're looking for a partner who approaches client relationships with this level of intentionality, I'd love to hear about what you're working on. The best projects aren't just about what gets built—they're about who you build them with.

---

[View on echobind.com](https://echobind.com/post/what-makes-a-great-client-agency-relationship)

---

# The Dev Accelerator Guide for Stretched Teams

> Your team is stretched thin and deadlines are slipping. Learn how Dev Accelerators help teams ship faster without the hiring headaches.

_By Lex Meola · 2025-06-30_

Your roadmap looks like a Tetris game designed by sadists. Your team is stretched thinner than pizza dough at a budget restaurant. And somehow, critical features keep slipping through the cracks like your sanity during sprint planning.

Sound familiar? Welcome to the club. The membership fee is your sleep schedule and the meetings are held at 2 AM when production breaks.

That's where the Dev Accelerator model comes in—a flexible, fast-moving approach to bringing in experienced development partners who can plug in quickly, move projects forward, and help you hit your goals without your internal team contemplating career changes in interpretive dance.

Here's what it is, how it works, and when it's worth considering (spoiler: probably right now).

![](https://cms.echobind.com/assets/c6f26b46-25ad-4b86-96b0-99e725eee51c)

## What Is a Dev Accelerator?

A Dev Accelerator isn't staff augmentation—those well-meaning but confused contractors who spend three weeks figuring out where the bathroom is. It's also not a traditional outsourced dev shop that treats your requirements like suggestions and your deadlines like gentle guidelines.

It's a model built around high-velocity, high-trust partnerships. You bring in a team of senior engineers, technical leads, and PMs who can immediately contribute, collaborate with your existing team, and focus on delivery. No hand-holding, no six-month ramp-up periods, and no getting lost in Slack threads debating whether the button should be cerulean or periwinkle.

The goal? To accelerate your dev efforts—not replace them with people who think "legacy code" means anything written before lunch.

![](https://cms.echobind.com/assets/b86c5d91-de09-4e21-b6ad-acc8d3e8186c)

## When to Use a Dev Accelerator

Here are the scenarios where we typically get the emergency bat signal:

**You're behind schedule.** You've got deadlines breathing down your neck like a persistence predator, and not enough hands to fend them off. Your current timeline is more fantasy than your favorite Netflix series.

**You can't hire fast enough.** Recruiting moves at the speed of continental drift, but your competitors aren't waiting around. You need delivery now, not after your fifth "final round" interview with a candidate who ghosts you for a 20% salary bump elsewhere.

**You're launching something big.** A new product, a major migration, a complete rebuild—basically anything that makes your current team look at their monitors with the same expression people reserve for tax audits.

**You're tackling something complex.** Stripe integrations that make you question your life choices, HIPAA compliance that reads like ancient hieroglyphics, or legacy systems held together by hope and deprecated libraries. We've been there, survived to tell the tale, and still have most of our hair.

**Your team is focused elsewhere.** Your core developers are busy keeping the lights on and preventing the digital equivalent of the building catching fire. We'll handle the heavy lifting while they do the heroic work of making sure users can actually log in.

![](https://cms.echobind.com/assets/fbaba422-ad66-4de4-b234-c64fd34ee8a7)

## How It Works

We embed quickly. We communicate clearly. We deliver consistently. We also don't require a three-hour orientation on your company culture and core values (though we're happy to pretend your ping-pong table is revolutionary).

Here's the typical flow:

**Kickoff** — We get aligned on goals, scope, and team dynamics. Think of it as speed dating, but for software development and with less awkward small talk.

**Onboarding** — We plug into your tools, your communication channels, and your codebase faster than you can say "technical debt." No two-week adjustment periods where everyone pretends to be productive.

**Build & Deliver** — We push work forward while keeping you in the loop. You get progress updates, not progress theater.

**Transition (when needed)** — We hand off cleanly or stay engaged for the long haul. Your choice, depending on whether you've grown attached or want us gone before we learn too much about your questionable architectural decisions.

The result? Real output, not just warm bodies warming chairs in video calls.

## Real Results (Names Changed to Protect the Innocent)

**Healthcare App Launch:** A product team was blocked by complex data workflows and legacy integrations that seemed designed by someone with a personal vendetta against future developers. We deployed a senior team and helped them go live six weeks ahead of schedule, which in healthcare time is basically traveling at light speed.

**Stripe Fix & Rebuild:** A fast-growing company had a Stripe integration more broken than a New Year's resolution by February. Webhook failures, payment mismatches, and support tickets multiplying like rabbits. We rebuilt the integration from scratch, resulting in a 75% reduction in billing-related support issues and significantly fewer developers contemplating switching careers to artisanal soap making.

**Legacy System Rewrite:** A CTO needed to modernize a critical internal system that predated most social media platforms but couldn't spare the internal bandwidth without everything else catching fire. We handled the rebuild, working alongside their team and delivering on time with minimal disruption—a minor miracle in the software world.

![](https://cms.echobind.com/assets/17210a7b-dc4f-4046-b481-f62a1da02b75)

## Why It Works

**Senior, autonomous talent.** No training wheels, no "gentle guidance," no explaining why we can't just "make it pop." We've done this before, survived the experience, and learned from our mistakes.

**Speed + clarity.** We ramp up fast and communicate constantly. No mysterious silences followed by "we hit a small snag" announcements three days before deadline.

**Embedded delivery.** We act like an extension of your team—without the politics, the long onboarding process, or the need to explain why certain code exists (we've all been there).

This isn't theory crafted in an ivory tower by consultants who think "technical debt" is something you pay with cryptocurrency. It's how we help teams get ahead, stay ahead, and ship the work that actually matters.

## Do You Need a Dev Accelerator?

Ask yourself these questions (honestly, like you're confessing to your therapist):

Are critical projects stalling like traffic on a Friday afternoon? Are you burning time on workarounds instead of progress, like using duct tape to fix a structural engineering problem? Do you need help now—not in 90 days when your next hire finally starts and spends their first month figuring out what everyone actually does?

If you nodded along to any of these (or all of them, which honestly wouldn't surprise us), it might be time to bring in reinforcements before someone stages a developer revolt.

## Let's Talk

We've helped teams like yours get back on track, hit deadlines, and launch with confidence instead of crossed fingers and desperate prayers to the demo gods. If you're facing a development bottleneck that's making you question your career choices, we'd love to hear what you're working on.

The good news? We've probably seen worse. The better news? We know how to fix it.

**Ready to stop the madness? Let's chat.**

---

[View on echobind.com](https://echobind.com/post/dev-accelerator-guide-for-teams)

---

# Why Your App Needs a Maintenance Contract (Unless You Enjoy Digital Dumpster Fires)

> Congratulations on your shiny new app! Now, how long until it breaks spectacularly in front of your biggest client?

_By Lex Meola · 2025-05-22_

Congratulations on your shiny new app! Now, how long until it breaks spectacularly in front of your biggest client?

![](https://images.unsplash.com/photo-1503266980949-bd30d04d0b7a?ixlib=rb-4.1.0&q=85&fm=jpg&crop=entropy&cs=srgb)

Let me tell you a story that still amazes our team. Last year, a client contacted us about an app we built for them a decade earlier. TEN YEARS with absolutely no updates, no maintenance, no changes whatsoever—and somehow, miraculously, it was still running. When they reached out, we were equal parts impressed and terrified.

While this digital time capsule continued functioning against all odds, looking under the hood revealed what you'd expect: a foundation built on deprecated libraries, security vulnerabilities that made us wince, and compatibility issues just waiting to manifest at the worst possible moment. This client had essentially won the software lottery—but this level of longevity without maintenance is extraordinarily rare and dangerous.

For every miracle story like this, there are countless applications that crash and burn within months of neglect. The digital landscape evolves rapidly, with new security threats emerging daily and platform updates that can break functionality overnight.

Software maintenance contracts for web and mobile apps aren't just another way for agencies to extract money from your wallet – they're your insurance policy against the digital apocalypse. They cover everything from security updates to compatibility fixes, ensuring your app continues working smoothly long after launch.

## Your App Today: Working Perfectly. Your App Tomorrow: 404 Not Found

![](https://images.unsplash.com/photo-1555861496-0666c8981751?ixlib=rb-4.1.0&q=85&fm=jpg&crop=entropy&cs=srgb)

The stability of a freshly launched app is temporary. Every piece of software accumulates technical debt that must eventually be addressed.

Research indicates that unmaintained software typically develops critical issues within 6-12 months of launch. While the "fix it when it breaks" approach appears cost-effective initially, it often leads to more expensive and disruptive problems down the line.

Regular maintenance isn't just about fixing what's broken—it's about preventing failures before they impact your users and your business.

## The Real Cost of App Emergencies

![](https://images.unsplash.com/photo-1554672723-b208dc85134f?ixlib=rb-4.1.0&q=85&fm=jpg&crop=entropy&cs=srgb)

App failures during critical business periods can be devastating. When your application crashes during a major sales event, you're forced to seek immediate technical assistance under pressure.

Emergency development services typically come with substantial cost premiums. Beyond the immediate financial impact, these incidents create a cascade of negative effects: damaged customer trust, lost revenue opportunities, and significant stress on your team.

Preventative maintenance helps avoid these high-stakes emergencies and preserves both your business operations and peace of mind.

## What You're Really Paying For

![](https://images.unsplash.com/photo-1592609931095-54a2168ae893?ixlib=rb-4.1.0&q=85&fm=jpg&crop=entropy&cs=srgb)

Maintenance contracts typically cover:

- Regular security updates—because hackers don't take vacations
- Compatibility maintenance to keep up with iOS, Android, and browser changes
- Performance optimization so your app runs smoothly and keeps pace with modern expectations
- Bug fixes—because squashing bugs before users find them is always better
- Minor feature enhancements to keep users happy and engaged

## The Financial Case for Preventative Maintenance

![](https://images.unsplash.com/photo-1523875194681-bedd468c58bf?ixlib=rb-4.1.0&q=85&fm=jpg&crop=entropy&cs=srgb)

From a financial perspective, planned maintenance is demonstrably more cost-effective than emergency repairs. When applications fail unexpectedly, the true cost extends beyond immediate technical fixes to include lost revenue, diminished customer confidence, and potential competitive disadvantage.

Industry data shows that a single hour of business application downtime typically costs organizations between $10,000-$50,000, depending on the sector. Compare this to structured maintenance agreements ranging from $1,000-$3,000 monthly that can significantly extend your application's functional lifespan.

Proactive maintenance represents both risk mitigation and a sound financial strategy for protecting your digital assets.

## Essential Features of Effective Maintenance Agreements

![](https://images.unsplash.com/photo-1600880292203-757bb62b4baf?ixlib=rb-4.1.0&q=85&fm=jpg&crop=entropy&cs=srgb)

When evaluating maintenance contracts, prioritize these critical elements:

- Transparent reporting and performance metrics
- Regular, accessible communication in non-technical language
- Flexible service options that align with your specific business requirements
- Clearly defined response time guarantees with service level agreements

Be cautious of providers who cannot clearly articulate their maintenance processes or who offer pricing significantly below market rates, as this often indicates compromised service quality.

## Conclusion

![](https://images.unsplash.com/photo-1506126613408-eca07ce68773?ixlib=rb-4.1.0&q=85&fm=jpg&crop=entropy&cs=srgb)

Proper maintenance transforms your application from a potential business risk into a reliable asset. Investing in professional maintenance protects your digital investment and ensures it continues to deliver value rather than becoming a liability.

Regular maintenance isn't just a technical necessity—it's a fundamental business strategy for protecting and maximizing your software investment.

---

[View on echobind.com](https://echobind.com/post/why-your-app-needs-a-maintenance-contract-unless-you-enjoy-digital-dumpster-fires)

---

# How to Deploy a Next.js App to Azure with Docker

> Learn how to deploy a Next.js app to Azure using Docker and Azure Container Apps in this step-by-step guide.

_By Preston Kelly · 2025-03-06_

## Introduction

In this guide, we'll walk through deploying a Next.js application to Azure using a Dockerfile and the Azure CLI. We'll use the Container Apps product which provides a serverless, scalable way to host containerized applications without the need to manage the underlying infrastructure. Since Dockerfiles are typically tailored to each project, we'll exclude them from this guide.

## Prerequisites

Before starting, ensure you have the following tools installed:

- A Next.js application with a Dockerfile
- An [Azure account](https://portal.azure.com/) (new accounts include free credits)
- [Docker](https://www.docker.com/) installed on your machine
- [Azure CLI](https://learn.microsoft.com/en-us/cli/azure/install-azure-cli) for command-line management

## Step 1: Setting Up Your Azure Environment

### 1.1 Create an Azure Account

If you don’t have an Azure account yet, sign up at [Azure Portal](https://portal.azure.com/). The free-tier provides sufficient resources to get started.

### 1.2 Install Azure CLI

The Azure CLI enables you to manage Azure resources directly from your terminal:

```bash
# macOS
brew install azure-cli

# Windows
winget install -e --id Microsoft.AzureCLI
```

### 1.3 Authenticate with Azure

After installation, log in to your Azure account and set up your subscription:

```bash
az login
az account list --output table
az account set --subscription "Your Subscription Name"
```

### 1.4 Create a Service Principal

For secure deployments, create a service principal with contributor permissions:

```bash
az ad sp create-for-rbac --name "nextjs-deploy" --role contributor \
  --scopes /subscriptions/$(az account show --query id -o tsv)
```

## Step 2: Preparing Your Azure Resources

### 2.1 Create a Resource Group

Organize your Azure resources by creating a resource group:

```bash
export AZURE_RG_NAME="your-resource-group"
az group create --name $AZURE_RG_NAME --location "eastus2"
```

### 2.2 Register Required Azure Providers

Ensure that necessary Azure services are registered before deployment:

```bash
az provider register --namespace Microsoft.ContainerRegistry
az provider register --namespace Microsoft.ContainerInstance
az provider register --namespace Microsoft.App
```

### 2.3 (Optional) Set Up a PostgreSQL Database

If your Next.js application requires a database, you can set up an Azure PostgreSQL server:

```bash
export AZURE_DB_SERVER="your-db-server"
export POSTGRES_USER="dbadmin"
export POSTGRES_PASSWORD="password"

az postgres flexible-server create \
  --name $AZURE_DB_SERVER \
  --resource-group $AZURE_RG_NAME \
  --location "eastus2" \
  --admin-user $POSTGRES_USER \
  --admin-password "$POSTGRES_PASSWORD" \
  --sku-name "Standard_B1ms" \
  --tier "Burstable" \
  --storage-size 32 \
  --backup-retention 7
```

For production, consider using the `General Purpose` tier with redundancy for improved availability.

## Step 3: Building and Deploying Your Next.js Application

### 3.1 Create an Azure Container Registry

To store Docker images, create an Azure Container Registry (ACR):

```bash
export AZURE_CONTAINER_REGISTRY="yourregistry"
az acr create \
  --resource-group $AZURE_RG_NAME \
  --name $AZURE_CONTAINER_REGISTRY \
  --sku Basic \
  --admin-enabled true
```

### 3.2 Build and Push Your Docker Image

Ensure your Next.js app has a `Dockerfile`, then build and push the image:

```bash
az acr login --name $AZURE_CONTAINER_REGISTRY

docker buildx build --platform linux/amd64 \
  -t $AZURE_CONTAINER_REGISTRY.azurecr.io/nextjs-app:latest \
  --push .
```

### 3.3 Deploy to Azure Container Apps

Set up an Azure Container App environment and deploy your application:

```bash
export AZURE_CONTAINER_INSTANCE="your-app-name"

az containerapp env create \
  --name "$AZURE_CONTAINER_INSTANCE-env" \
  --resource-group $AZURE_RG_NAME \
  --location "eastus2"

ACR_USERNAME=$(az acr credential show --name $AZURE_CONTAINER_REGISTRY --query "username" -o tsv)
ACR_PASSWORD=$(az acr credential show --name $AZURE_CONTAINER_REGISTRY --query "passwords[0].value" -o tsv)

az containerapp create \
  --name $AZURE_CONTAINER_INSTANCE \
  --resource-group $AZURE_RG_NAME \
  --environment "$AZURE_CONTAINER_INSTANCE-env" \
  --image $AZURE_CONTAINER_REGISTRY.azurecr.io/nextjs-app:latest \
  --target-port 3000 \
  --ingress external \
  --registry-server $AZURE_CONTAINER_REGISTRY.azurecr.io \
  --registry-username $ACR_USERNAME \
  --registry-password $ACR_PASSWORD \
  --secrets database-url="$DATABASE_URL" \
  --env-vars NODE_ENV=production NEXT_TELEMETRY_DISABLED=1
```

### 3.4 Retrieve Deployment URL

Check if your application is live by running:

```bash
az containerapp show \
 --name $AZURE_CONTAINER_INSTANCE \
 --resource-group $AZURE_RG_NAME \
 --query "properties.configuration.ingress.fqdn" \
 --output tsv
```

## Step 4: Managing Your Application

### Updating Environment Variables

Modify application settings post-deployment:

```bash
az containerapp update \
  --name $AZURE_CONTAINER_INSTANCE \
  --resource-group $AZURE_RG_NAME \
  --set-env-vars DATABASE_URL="new-database-url"
```

### Viewing Logs

Monitor application logs:

```bash
az containerapp logs show \
  --name $AZURE_CONTAINER_INSTANCE \
  --resource-group $AZURE_RG_NAME
```

### Scaling for Performance

Enable automatic scaling based on HTTP traffic:

```bash
az containerapp update \
  --name $AZURE_CONTAINER_INSTANCE \
  --resource-group $AZURE_RG_NAME \
  --min-replicas 1 \
  --max-replicas 10 \
  --scale-rule-name http-rule \
  --scale-rule-type http \
  --scale-rule-http-concurrency 50
```

## Conclusion

By deploying your Next.js application to Azure Container Apps with Docker, you gain a reliable and scalable hosting environment. With automatic scaling, comprehensive logging, and flexible environment configurations, Azure makes it easy to manage modern web applications.

For further reading:

- [Azure Container Apps Documentation](https://docs.microsoft.com/azure/container-apps)
- [Next.js Deployment Guide](https://nextjs.org/docs/deployment)
- [Docker Official Documentation](https://docs.docker.com/)

---

[View on echobind.com](https://echobind.com/post/deploy-nextjs-azure-cli)

---

# Navigating GPUs for AI in the Cloud

> Explore how to scale GPUs to power AI video processing in the cloud.

_By Matt Thompson · 2025-03-03_

In the world of artificial intelligence (AI), the demand for processing power has skyrocketed. While CPUs have long been the backbone of computing, GPUs (Graphics Processing Units) have emerged as the preferred choice for AI workloads. This blog will explore the advantages of using GPUs in the cloud, particularly for tasks such as AI tracking and video highlighting.

## Why GPUs?

GPUs are designed to handle multiple tasks simultaneously, making them ideal for the parallel processing required in AI applications. Unlike CPUs, which are optimized for sequential processing, GPUs can process thousands of threads at once. This capability is particularly beneficial for deep learning models, which require extensive computations on large datasets.

Given that most data science and machine learning models are developed in Python, it's important to understand a key limitation: Python's Global Interpreter Lock (GIL) means that even with multiple CPU cores, a single Python process can only execute one thread at a time. This limitation makes GPU acceleration even more crucial for AI workloads, as it allows us to bypass Python's threading constraints and leverage true parallel processing capabilities.

## AI Tracking and Highlighting Videos

While not every AI task needs a GPU, many complex computations, especially those involving large datasets or real-time processing, can significantly benefit from the parallel processing capabilities that GPUs offer. This is particularly true for tasks such as image recognition, natural language processing, and video analysis, where the speed and efficiency of GPUs can lead to faster model training and improved performance in production environments.

The use of GPUs in the cloud for AI tracking and video highlighting is a game-changer across various industries. With our clients we've seen all sorts of applications, such as monitoring patients in hospitals, physical therapy, analyzing downtown traffic patterns, and enhancing sports analytics. With the ability to process video feeds in real-time, GPUs excel at tracking movements, pinpointing significant moments, and creating engaging highlights. This capability not only boosts viewer engagement but also delivers critical insights for nurses, coaches, and players alike.

With companies like [Anthropic (Claude)](https://www.anthropic.com/news/anthropic-raises-series-e-at-usd61-5b-post-money-valuation) securing significant seed funding and open-source communities like [Hugging Face](https://huggingface.co/) continuing to grow, we are just scratching the surface of what is possible in AI development.

## Example Scenario

Let us take this sample video of two cute dogs.

<video controls src="https://cms.echobind.com/assets/a1ca90fc-4ed1-44e6-b24a-dcdb642ff086"></video>

For AI to track all the dogs in the video we first need to break this video down frame by frame.
We then run those frames through an AI model for image recognition, highlight what was found, and stitch these frames back together in a new video.

Leveraging models like [Ultralytics Yolo v8](https://docs.ultralytics.com/models/yolov8/) make this a relatively easy task.
While this example demonstrates the power of AI video processing, it raises important questions about scalability and infrastructure.
How do we scale this this service to be available for millions of users?!

## Scaling Challenges

We know how this all works for one video; AI leverages our GPU for efficiency, and the model does what it was trained to do. Until recent years, our focus has primarily been on CPU usage, especially in web applications. The challenge lies in how we present our static database or Excel data to users. This represents a different type of scaling. While web apps typically prioritize the number of users connected to a single CPU thread, AI and video analytics require a more dynamic approach. They must efficiently manage vast amounts of data and processing power to deliver real-time insights and analytics. While a web app can live within a fraction of a CPU -- our new AI tasks need the machines full resources to function. As we move forward, understanding how to scale GPU resources effectively will be crucial for maximizing the potential of AI applications in various industries.

## GPUs in the cloud

For this blog we are going to primarily focus on AWS. However, these same principles will apply to Microsoft Azure, Google, etc.

Amazon Web Services (AWS) offers a variety of services that make it easy to harness the power of GPUs for AI applications:

- **EC2 (Elastic Compute Cloud)**: AWS EC2 provides instances with powerful GPU capabilities, allowing you to run your AI models efficiently. You can choose from a [range of instance types](https://docs.aws.amazon.com/dlami/latest/devguide/gpu.html) optimized for different workloads. Amazon has even started to adopt open sourced images like [Bottlerocket/Nvidia containers](https://aws.amazon.com/blogs/containers/bottlerocket-support-for-nvidia-gpus/) to build upon. While these EC2 instances can be powerful on their own. It's still only one "machine" with a limited number of GPUs. Likely great for small apps or training a new model, but we want more!
- **ECS/Fargate**: Although Fargate does not support GPUs, ECS can still be leveraged to launch EC2 instances equipped with GPU capabilities. However, the available image types are restricted to "Amazon Linux w/ GPU" and Bottlerocket GPU images. While these options may suffice, it's essential to consider them when designing your architecture and Docker builds. ECS excels in load balancing and scaling full applications, but it doesn't fully address our specific needs. We have individual requests and processes that require GPU resources, and we don't necessarily want to scale an entire application for that. In the web application context, we often think of delegating these requests to a "worker"—a separate entity that can process tasks and notify us of the results. This is where "AWS Batch" comes into play.
- **AWS Batch**: Saving the best for last. For our batch processing requirements, AWS Batch can automatically allocate the appropriate amount of compute resources, including GPU instances, to efficiently execute your AI jobs. This service is ideal for handling large datasets or conducting complex simulations. AWS Batch will establish a base Compute Resource (EC2), a Job Definition (which specifies the resources needed to complete the task—such as 1 GPU), and a queue for all incoming requests. As requests come in, AWS Batch will dynamically provision additional EC2 resources to accommodate the demand. This greatly reduces our costs we now can run our web app on a normal CPU layer and only trigger GPU instances when needed to process with our AI Models.

Referring back to our Dog video example, we used an EC2 instance with the image type `g4dn.xlarge`—the key point here is that our base Compute instance is equipped with 1 GPU. When a request is received, a new job is queued based on our job definition. This definition specifies that we require 1 GPU for the task to execute. Consequently, for each incoming request, we will quickly spin up an EC2 instance, execute our processing commands, and then terminate that instance to minimize costs. If our base EC2 Compute Environment had 4 GPUs, we could handle 4 requests before needing to scale up to a new instance. Ultimately, the decision on the size of the instance depends on your specific requirements. For most applications, particularly as an "AI worker," 1 GPU is typically sufficient for the individual tasks we aim to perform.

Mix this in with a normal web app listening for these workers response, and we users can "fire and forget" all the videos they wish to process without bogging down our users experience. Once the batch worker completes, we'll save the results for the end user to enjoy.

## Conclusion

In summary, exploring the use of GPUs in the cloud reveals immense opportunities for AI applications. While we discussed several AWS services today, these concepts are broadly applicable across various platforms. Are we optimizing the entire application? Do we require a powerful machine for model training or to handle numerous user requests? By utilizing services such as AWS EC2 and AWS Batch, you can fully harness the capabilities of your AI initiatives. Stay tuned for more insights as we explore specific use cases and best practices in upcoming blogs.

<video controls src="https://cms.echobind.com/assets/cc875ef8-e3cc-4a50-a9d1-56d9f1d94139"></video>

---

[View on echobind.com](https://echobind.com/post/navigating-gpus-for-ai-in-the-cloud)

---

# Introducing Annoplan: Rethinking Project Estimation at Echobind

> How Echobind developed Annoplan, an in-house project estimation tool that consolidates designs, annotations, and user story creation into a single platform.

_By Michael Yared · 2024-12-26_

I’ve always embraced the challenge of building something new—whether it’s a product, a process, or a better way to collaborate. At Echobind, our curiosity led us to reexamine our internal tools, and one problem stood out as a clear opportunity for improvement: our project estimation workflow.

For years, we’ve told clients that project estimation is one of the hardest things we do—and we’ve gotten pretty good at it. But even with our expertise, the process was eating up more time and energy than we could afford.

The issue? Too many disconnected steps that drained our team’s focus. Estimating a large project required six people navigating between Whimsical for flowcharts, Figma for annotations, and spreadsheets for estimates. And once the estimate was complete, we still had to compile everything into a polished Business Requirements Document (BRD)—adding yet another time-intensive layer to the process.

We knew there had to be a better way. We needed a solution that streamlined the process, preserved the accuracy of our estimates, and allowed us to move faster without compromising quality. Most importantly, we wanted to maintain the collaborative, multiplayer nature of our workflow while significantly reducing the time each individual spent on it.

Enter **Annoplan**—our new in-house tool that’s transforming the way we estimate.

**The Before State: A Fractured Process**

Before Annoplan, estimating a project often felt like a chore. We’d lay out user flows in Whimsical, annotate designs in Figma, then track the granular details in Google Sheets. These tools are all great in their own right, but hopping between them slowed us down and left plenty of room for missing context. Sometimes a crucial detail got lost in translation; other times, estimates would drift apart from the original plan. No one was thrilled about this patchwork approach, and it was clear we had to rethink it.

**The Breakthrough: One Platform, Unified Vision**

What if we could have it all in one place? That’s the question that led us to create Annoplan. It’s a web application that brings our entire estimation workflow under one roof. Now we can:

* **Upload Designs and Annotate them Directly:** Instead of bouncing between tools, we take whatever we have – sketches, wireframes, or high fidelity design – and upload them. Once we have everything, we can quickly resort the screens and start annotating features in the same interface.
* **Create User Stories by hand or with AI:** Because each annotation corresponds to a user story, a prompt is shown after every annotation. The user has the ability to write the story manually, but more often than not, we let a large language model take the first pass. 
* **Collaborate on Estimates:** Each team member can input their own estimates, and Annoplan helps us spot discrepancies early, guiding us toward a unified vision. And just like with annotations, we can ask our LLM to take a pass at estimates.

It feels like a breath of fresh air. By removing friction, we can spend more time focusing on what actually matters in the application without worrying that any minor details were left behind.

![](https://cms.echobind.com/assets/d170d0db-f67a-4f11-bf49-b7c6e0a7cb3b)

**Bringing Fun Back into the Process**

Estimation doesn’t have to be painful. With Annoplan, the experience feels more like a friendly brainstorming session than a tedious chore. You’re simply pointing, clicking, and discussing in one place. The interface is intuitive, and incorporating AI-generated user stories and estimates adds a layer of excitement that I honestly didn’t think was possible in something as traditionally dry as estimation.

**Accurate, Efficient, and Ready to Share**

The best part for us is the speed. We’ve managed to cut our estimation time in half by consolidating tools. No more scrambling for the right link or duplicating efforts. And when it’s time to produce that final BRD for a client or internal reference, it’s just a few clicks away—easy to update, easy to maintain, and always reflecting our current thinking.

This might sound like a small shift, but trust me, it’s had a huge impact. Instead of dreading the estimation process, we’re embracing it. We’re delivering more accurate proposals, responding quickly to client feedback, and ultimately, working in a way that feels more human and less mechanical.

**Looking Ahead and Sharing the Journey**

Annoplan started as a passion project during our [investment time](https://echobind.com/careers)—an experiment in seeing what could happen if we cared as much about our own efficiency as we do about our clients’. It’s now become a critical piece of how we operate. We’re excited about the future potential, not just for us but for others who might benefit from a more unified approach to project estimation.

A heartfelt thanks goes out to the Echobind engineering team. Your creativity, adaptability, and willingness to try something new turned a spark of an idea into a tangible solution that’s making a difference in our day-to-day work.

We’d love to hear from you, too. What’s working in your estimation process, and where do you still feel the pain? If you’re curious about trying out Annoplan or have workflow pain points that you're looking to solve, [reach out](https://echobind.com/contact). Let’s keep finding better ways to build.

---

[View on echobind.com](https://echobind.com/post/introducing-annoplan-rethinking-project-estimation)

---

# Sharing Types and Code Between the Server and Client

> Usually you want to treat the server and client as completely separate worlds, but sometimes it's convenient to share code between them.

_By Alex Anderson · 2024-12-04_

Usually, server and client code shouldn't mix. This keeps client bundle sizes small and prevents unnecessary code from gumming up the server. `Uncaught ReferenceError: window is not defined`, anyone?

But there are some things you definitely want to share between them - especially types and constants. And it's perfectly safe to share them, so long as you follow a few guidelines.

### tl;dr

For sharing types, use `import type {SharedType} from '../../shared/types'`.

For sharing constants and utility functions, export them from a file that has no imports, so it doesn't import any server or client code.

### A Primer on Client and Server Bundles and the Dangers of Sharing Code

The process of taking a single codebase and creating separate compilations for both the client and server is still a relatively new idea, popularized by Next.js and server-side rendering. Frameworks and bundlers are still [improving the process](https://vite.dev/blog/announcing-vite6#experimental-environment-api) to make the experience seamless, efficient, and optimized.

JavaScript programs create a module graph any time they `import` or `export` from modules. That creates a dependency tree out of the program. When compiling an app, bundlers create separate trees for the server and the client, using rules and heuristics to decide which code should be included in each. For example, [the React Router framework automatically removes](https://reactrouter.com/explanation/code-splitting#removal-of-server-code) `loader` and `action` exports from the client bundle.

Where you get into trouble is when you use client-only or server-only code in places the framework doesn't account for. Things like Node's `fs` module or  the browser's `document.querySelector` function can't be used in the other environment - you just get errors. It's possible to shim these or add polyfills, but usually it should be avoided.

Plus, you want to keep your client bundle small, which is difficult to do if you're including a bunch of server-side code that isn't even executed on the client.

So how do you share code between the two environments without running into these problems

### Sharing Types

Sharing types is easy - just make sure you only import the type from the other module. If one module only imports types from the other module, when it is compiled the import statement will be removed entirely.

```ts
// This code...
import { NumberList } from './types'

const myNumbers:NumberList = [1,2,3]

// Becomes this...
const myNumbers = [1,2,3]
```

Even if the imported module has side effects, it's still excluded when only types are imported.

There's a problem, though. It becomes all too easy to forget which imports are types and which are values. Or you might be importing a type that is _also_ a value, like a class, and want to ignore the value part so it's not included in the bundle.

This is where [Import Type](https://www.typescriptlang.org/docs/handbook/2/modules.html#import-type) comes in. It ensures that you are only importing types which will be removed from your code.

```ts
// Bad - this imports the class and any modules it depends on
import { ServerOnlyClass } from '../server/utils'

const serverSideData:ServerOnlyClass = { /* ... */ }

// Good - this only imports the type, which is removed when compiled
import type { ServerOnlyClass } from '../server/utils'

const serverSideData:ServerOnlyClass = { /* ... */ }
```

### Sharing Code

Code is both easier and harder to share than types. There isn't a magical directive you can add to your imports to say "only import the stuff that I want." Relying on [tree-shaking for correctness usually leads to pain](https://github.com/remix-run/react-router/blob/main/decisions/0009-do-not-rely-on-treeshaking-for-correctness.md). In other words, it's a bad idea to expect your bundler to know exactly what stuff should go in the server build and in the client build - you need to help it.

That said, the solution is simple: Be explicit with your imports and exports. Recognize that if you share a module between the client and server, anything that module imports will also be shared.

For a list of constants, this is easy - just write the constnats in their own file with no imports. Simple utilities with no dependencies can also be easily shared with no concern.

Utilities and functions which import other files or NPM modules should be examined to make sure what they are importing is necessary in both environments. It's possible they can be used in both environments with no problems. It's also possible that you'll need to split similar looking functions into two separate files, one for the server and one for the client. 

### Wrapping Up

This is the upside of using TypeScript for both the client and the server - you can share code between the two - but not with impunity. Like everything in our work, you can build better by caring about your craft and understanding how the behavior of bundlers can affect how you structure your code.

---

[View on echobind.com](https://echobind.com/post/sharing-types-and-code-between-the-server-and-client)

---

# What is Machine Learning

> Follow Matt along his journey as we explore the fundamentals of machine learning.

_By Matt Thompson · 2024-09-13_

## Intro

If you read my last article on [What is AI?](https://mthomps4.com/blog/2024/what-is-ai), you'll know that AI is a broad field with many applications. At its core, AI is about creating machines that can learn and make decisions equal to or greater than humans.

Machine Learning is a subfield related to AI that focuses on building systems that can learn from data and make predictions or decisions without being explicitly programmed.
Lets dive in and explore the fundamentals of machine learning.

## What is Machine Learning?

> "the use and development of computer systems that are able to learn and adapt without following explicit instructions, by using algorithms and statistical models to analyze and draw inferences from patterns in data."
> 

As humans we learn primarily through observation, this is no different. Machine learning is a way for our machines to learn by example. These examples are broadly categorized into two types based on the nature of the data it works with: Structured and Unstructured Learning.

### Structured Learning

Structured learning works with well-organized, tabular data such as spreadsheets and databases. This type of data is easier to process and analyze, making it commonly used in applications like business analytics and financial forecasting.

### Unstructured Learning

Unstructured learning deals with complex, raw data such as text, images, audio, and video. It requires more sophisticated algorithms to process and analyze this type of data however, this is where a lot of the generative applications come into play. This approach is commonly used in applications like natural language processing and computer vision.

## Know your data

The main catch here, Machine Learning algorithms require a lot of data to train on. The output will only be as good as the foundation it was given. This is where all the hot topic ethical questions come into play. It is very easy to train model with a set of biased data, intentionally or unintentionally. More data is not always better either, it is important to understand the nuances of the data you are working with and how it can affect the outcome. Understand that an Unstructured learning approach will attempt to find patterns you may not have considered, but alas, it is all your data in which the model derives its patterns from.

## Learning Approaches

Machine Learning algorithms can also be classified based on their learning approach:

### Supervised Learning

Supervised learning uses pre-fabricated, labeled data for training. The algorithm learns to map inputs to known outputs. There are several types of supervised learning:

- **Classification**: Predicts discrete categories (e.g., spam detection)
- **Multi-class Classification**: Predicts multiple categories (e.g., image recognition)
- **Regression**: Predicts continuous values (e.g., house price prediction)

A solid example of this is the [Palmer Penguin dataset](https://www.kaggle.com/code/parulpandey/penguin-dataset-the-new-iris/input). You'll see the CSV has quite a bit of data for us to train a model on. From here we can predict the species of penguin, sex, or location based on its physical characteristics.

### Unsupervised Learning

Unsupervised learning works with unlabeled data. It finds patterns or structures in data without predefined outputs. Examples of unsupervised learning include clustering, dimensionality reduction, and anomaly detection. "Help me find the patterns in this data"

Each of these approaches has its strengths and is suited for different types of problems and datasets. The choice of which to use depends on the specific task, available data, and desired outcomes.

### Deep Learning

You may also hear the term "Deep Learning" which is a specialized subset of Machine Learning that uses neural networks with multiple layers (hence "deep") to model and process complex patterns in data. It's particularly powerful for handling large amounts of unstructured data and has revolutionized fields like image and speech recognition.

## Summary

With Machine Learning, we can create systems that can learn and make decisions equal to or greater than humans. This is one of the foundation blocks to building an AI system. These are powerful tools that can be used to solve some of the worlds most complex problems.

However, we must always consider the implications of our creations. "With Great Power, Comes Great Responsibility." We must be mindful of the data we use to train our models, and the decisions they make. It is our responsibility to use them wisely.

## Up Next

Machine Learning is just the first step in the AI journey. Not all "input" data is created equal. In the next article, we'll explore other areas of our AI System such as NLP, Computer Vision, and how they all come together to form the AI system we know today.

---

[View on echobind.com](https://echobind.com/post/what-is-machine-learning)

---

# What is AI

> Lets learn about AI together. What is it? and ways to use it.

_By Matt Thompson · 2024-09-12_

## Intro

Working at as a Software Engineer and Consultant, I have plenty of opportunities to see how AI can be impactful and solve real-world problems. However, as you can imagine, with all the hype around AI, there's also a lot of noise that comes along with it.

I decided to take a step back and learn more about AI and Machine Learning starting with the basics. To do this, I'll be following along with a few courses from [Datacamp](https://www.datacamp.com/) and eventually applying my knowledge to a real project for us to learn together.

The end goal is to have a solid foundation to build our own Models and deploy them through platforms like [Hugging Face](https://huggingface.co/models) or potentially taking the deeper dive into Microsoft Azure's AI services.

## So What is AI?

AI is a broad field with many applications, at its core it is about creating machines that can learn and make decisions equal to or greater than humans.
This looks similar to how Computer Science and Software work today. We take an input, process it with a known algorithm of some kind, and return an output.
However, not all Algorithms are created equal nor are they meant for AI. So what's the difference?

In traditional software algorithms, we define the "process" explicitly to calculate the output.
An AI system, on the other hand, uses algorithms that can learn from data and experience to make decisions or predictions.
Remember the point of AI is to make decisions that are human-like in nature.
AI encompasses several subfields and technologies, including:

- **Machine Learning:** Algorithms that improve through experience
    - **Deep Learning:** A subset of machine learning using neural networks
- **Natural Language Processing:** Enabling computers to understand and generate human language
- **Computer Vision:** Allowing machines to interpret and analyze visual information
- **Robotics:** Designing and creating intelligent machines that can interact with the physical world

These components often work together in AI systems to solve complex problems and make human-like decisions.

Disciplines such as Data Science, Mathematics, and Statistics play crucial roles in developing and working with AI systems. While AI and Machine Learning were once primarily the domain of specialists, they have become increasingly accessible to a wider audience. One of the most common and widely-used applications of AI today is Natural Language Processing (NLP), with chatbots like ChatGPT and Claude serving as prime examples.

## Why AI is important?

AI is important for several reasons:

- **Automation:** AI can automate routine tasks, freeing up human workers for more complex and creative tasks.
- **Efficiency:** AI can process large amounts of data quickly, leading to more efficient operations.
- **Innovation:** AI can help us discover new insights and solve complex problems that would be difficult or impossible for humans to tackle alone.
- **Personalization:** AI can tailor experiences to individual users, making them more relevant and engaging.
- **Cost Reduction:** AI can help reduce costs by optimizing processes and reducing waste.

## How does AI work?

AI systems typically follow a similar process:

1. **Data Collection:** AI systems start by collecting data from various sources. This data can include text, images, audio, or other forms of information.
2. **Data Preprocessing:** The collected data is then preprocessed to clean and prepare it for analysis. This includes tasks like removing duplicates, normalizing data, and splitting it into training and testing sets.
3. **Feature Extraction:** AI systems use feature extraction to identify important patterns and relationships in the data. This involves selecting the most relevant features and transforming them into a format that can be used to train a model.
4. **Model Training:** Once the data is prepared and features are extracted, the AI system uses a machine learning algorithm to train a model. This model is then used to make predictions or decisions.
5. **Model Evaluation:** After the model is trained, it is evaluated to ensure that it is accurate and effective. This involves testing the model on a separate dataset and checking its performance.

## Up Next

That's a lot of terms and concepts to take in, so let's take a break.
In the next post, I'll go over Machine Learning and its relationship to AI.
We'll break this down into structured and unstructured learning styles, and cover supervised and unsupervised learning.

---

[View on echobind.com](https://echobind.com/post/what-is-ai)

---

# Demystifying AI Integrations

> Learn how to integrate AI into your web apps with ease using Anthropic's Claude and more.

_By Matt Thompson · 2024-09-11_

## Intro

ChatGPT, Claude, Copilot, Bedrock, Gemini, and more.
In the ever-evolving landscape of web development, integrating AI capabilities might seem like a daunting task. But fear not! It's more accessible than you might think.

Let's break down the process and explore how you can add AI power to your web applications.

## The Building Blocks

AI integration in web apps is no different than consuming any other 3rd party service. At it's core, it consists of making an API call and reflecting data back to the end user. Breaking it down, we have a few key components:

- The Service: LLM (Large Language Model) to interface with. (Claude-sonnet, GPT-4o, etc)
- An API/SDK to communicate with the LLM. (Anthropic API, OpenAI API, etc)
- A UI layer to allow users to interact with our API.
- Prompt Engineer -- YOU the person asking your deepest darkest imposter syndrome induced questions.

From here the rest is simply data/state management in the UI. e.g. How do we take the response from our LLM and display it to the user.

## Hello World

How you choose to interact with Claude is up to you.
For most folks, this will be a web app.

In this example we will use Anthropic's API for Claude to answer a simple question and display the response to the user. As a bonus, we'll leverage some syntax highlighting to make the code snippets (artifiacts) claude returns more human readable.

However, if you are an engineer spending your day in the terminal -- you may find a quick terminal application works just as well. [Elixir CLI Example](https://mthomps4.com/blog/2024/anthropic-terminal-elixir/)

For both of these examples, we still leverage the same [Anthropic API](https://docs.anthropic.com/en/api/messages)!

## Getting Started: A Bare-Bones Approach

Let's start with a simple example using the Anthropic AI Typescript SDK:

```tsx
import Anthropic from '@anthropic-ai/sdk';

const getChatResponse = async (prompt: string) => {
  try {
    const anthropic = new Anthropic({
      apiKey: process.env.ANTHROPIC_API_KEY,
    });

    const response = await anthropic.messages.create({
      model: "claude-3-opus", // claude-3-sonnet, claude-3-haiku, etc.
      max_tokens: 1024,
      messages: [{ role: "user", content: prompt }],
    });

    console.log({ response })

    return response;
  } catch (error) {
    console.error({ error })
  }
}
```

This snippet sets up the client and returns a response from Claude based off the given `prompt`. Simple, right?

## Integrating with a UI (NextJS example)

Now that we understand the basic API interaction, let's integrate it into a user interface. We'll use Next.js to create a simple form that allows users to interact with Claude.

Here's how we can structure a basic React component:

1. We'll create a form with a text input for the user's question and a submit button.
2. We'll use React's useState hook to manage the input and response states.
3. When the form is submitted, we'll call our `action` function and update the UI with Claude's response.

This example is an over simplification of a chat application for the sake of clarity and doesn't represent a full production application. However, it demonstrates the core concepts.

Below you'll find the code for our example.

One thing to note, all of claude's content is returned as markdown. As a bonus, we've added `react-markdown` and `react-syntax-highlighter` to make the response more human readable!

If you've ever wondered how chatgpt, claude, or any of the other LLMs display code snippets, this is a good example. It's just Markdown!

Following the example below you can note at a high level a User can interact with our form updating the `input` state that is then sent to our `action` function in our submit handler.

This `action` function is where we make our API call to claude and handle the response.

Each time we call our `streamMessage` function, we pass in our `input` state and await the response.

We then take that response and update our `chatHistory` state which is a list of all the messages in the [chat.As](http://chat.as/) chatHistory updates, the dom is updated for the user to see the response.

![demo](https://cms.echobind.com/assets/f5edd5f1-f7f2-4b11-b083-b14cb9dec33e)


## Ways to improve

Again, this is a very simple example, but it demonstrates the core concepts. From here you can start to think about how you might want to structure your application.

Some ideas:

- Streaming Responses: For a more dynamic user experience.
- Error Handling: Gracefully manage API failures or rate limiting.
- Context Management: Maintain conversation history for more coherent interactions.
- Saving the Conversation: Implement a feature to save and retrieve conversations for future reference.

If you are in the React ecosystem, you may find Vercel's `ai` sdk [npm](https://www.npmjs.com/package/ai) to be a good fit for your needs. It provides a higher level abstraction for interacting with AI services and integrates nicely with Next.js actions!

Read more [here](https://sdk.vercel.ai/docs/ai-sdk-core/overview)

## AI is not just for Big Tech

Remember, AI integration isn't limited to tech giants. Small projects and individual developers can leverage these tools too. Whether you're building a personal blog, a productivity app, or a business tool, there's likely an AI use case that can enhance your project.

## The Flexibility of AI

While we've used Anthropic's Claude as an example, the principles apply to various AI services. Whether you're using OpenAI, Hugging Face, or even your own custom model, the integration process follows a similar pattern.

## The Code

A POC repo can be found [here](https://github.com/mthomps4/ts-claude).

*[page.tsx] The entry point of our applicaiton*

```tsx
import ClaudeChat from "./ClaudeChat";

export default async function Home() {
  return (
    <div className="min-h-screen w-full">
      <main className="bg-slate-200 rounded-lg m-4 p-10">
        <h1 className="font-bold text-4xl">TS Claude</h1>
        <ClaudeChat />
      </main>
    </div>
  );
}

```

*[ClaudeChat.tsx] The chat component that allows the user to input a message and submit it to Claude.*

```tsx
"use client";

import { useState } from "react";
import { streamMessage } from "./actions";
import ReactMarkdown from "react-markdown";
import { Prism as SyntaxHighlighter } from "react-syntax-highlighter";
import { vscDarkPlus } from "react-syntax-highlighter/dist/esm/styles/prism";

const ClaudeChat: React.FC = () => {
  const [input, setInput] = useState("");
  const [chatHistory, setChatHistory] = useState<string[]>([]);
  const [isLoading, setIsLoading] = useState(false);

  const handleSubmit = async (e: React.FormEvent) => {
    e.preventDefault();
    if (!input.trim()) return;

    setIsLoading(true);
    const userMessage = `You: ${input}`;
    setChatHistory((prev) => [...prev, userMessage]);
    setInput("");

    try {
      const response = await streamMessage(input);
      setChatHistory((prev) => [...prev, `Claude: ${response}`]);
    } catch (error: unknown) {
      console.error("Error:", error);
      setChatHistory((prev) => [
        ...prev,
        `Error: ${(error as Error)?.message ?? "Unable to get response"}`,
      ]);
    } finally {
      setIsLoading(false);
    }
  };

  return (
    <div className="flex flex-col h-[80vh]">
      <div className="flex-grow overflow-auto p-4">
        {chatHistory.map((message, index) => (
          <div key={index} className="mb-2">
            {message.startsWith("You: ") ? (
              <>
                <h3 className="font-bold text-lg">You:</h3>
                <p>{message.replace("You: ", "")}</p>
              </>
            ) : (
              <>
                <h3 className="font-bold text-lg">Claude:</h3>
                <ReactMarkdown
                  components={{
                    code({ className, children, ...props }) {
                      const match = /language-(\\w+)/.exec(className || "");
                      return match ? (
                        <SyntaxHighlighter
                          // @ts-expect-error what is this?
                          style={vscDarkPlus}
                          language={match[1]}
                          PreTag="div"
                          {...props}
                        >
                          {String(children).replace(/\\n$/, "")}
                        </SyntaxHighlighter>
                      ) : (
                        <code className={className} {...props}>
                          {children}
                        </code>
                      );
                    },
                  }}
                >
                  {message.replace("Claude: ", "")}
                </ReactMarkdown>
              </>
            )}
          </div>
        ))}
      </div>
      <form onSubmit={handleSubmit} className="p-4">
        <input
          type="text"
          value={input}
          onChange={(e) => setInput(e.target.value)}
          className="w-full border-2 p-2 rounded"
          placeholder="Type your message..."
          disabled={isLoading}
        />
        <button
          type="submit"
          className="mt-2 bg-blue-500 text-white p-2 rounded"
          disabled={isLoading}
        >
          {isLoading ? "Sending..." : "Send"}
        </button>
      </form>
    </div>
  );
};

export default ClaudeChat;
```

*[action.ts] The action that is called when the user submits a message. It streams the response from Claude and updates the UI with the response.*

```tsx
"use server";

import { Anthropic } from "@anthropic-ai/sdk";

export async function streamMessage(msg: string) {
  try {
    const apiKey = process.env.ANTHROPIC_API_KEY;

    if (!apiKey) {
      throw new Error("Anthropic API key not found");
    }

    const anthropic = new Anthropic({
      apiKey,
    });

    if (!msg) {
      throw new Error("Message is required");
    }

    const stream = await anthropic.messages.create({
      model: "claude-3-opus-20240229",
      max_tokens: 1024,
      messages: [{ role: "user", content: msg }],
      stream: true,
    });

    let fullResponse = "";
    for await (const chunk of stream) {
      if (
        chunk.type === "content_block_delta" &&
        chunk.delta.type === "text_delta"
      ) {
        fullResponse += chunk.delta.text;
      }
    }
    return fullResponse;
  } catch (error) {
    console.error("Error:", error);
    throw new Error("Error processing your request");
  }
}
```

## Wrapping Up

Integrating AI into your web applications doesn't have to be intimidating. Start small, experiment, and gradually expand your AI features. With the right approach, you'll be surprised at how quickly you can add powerful AI capabilities to your projects.
Remember, the key is to start simple and build from there. Happy coding!

---

[View on echobind.com](https://echobind.com/post/demystifying-ai-integrations)

---

# Simplifying Stripe Connect with Embedded Components

> How Stripe's embedded components ease the burden of implementing Custom Connect for a platform.

_By Matt Thompson · 2024-09-09_

## Introduction

Implementing a robust payment system for platforms that connect businesses with customers can be a complex endeavor. Stripe Connect has long been a go-to solution for marketplaces, SaaS platforms, and crowdfunding sites. However, the implementation process often required significant development effort and careful attention to compliance requirements. At times even feeling locked in or insecure about decisions made between Express, Standard, and Custom Connect. Enter Stripe's embedded Connect components – a game-changer in simplifying this process.

## The Challenge of Custom Connect

Traditionally, implementing Stripe Connect involved several challenges:

1. Building custom onboarding flows
2. Ensuring compliance with varying regulations across different countries
3. Maintaining and updating these systems as requirements change
4. Handling complex edge cases and user errors

These challenges often led to longer development cycles and increased the potential for errors or oversights in the implementation.

## Stripe's Embedded Components: A Solution

Stripe has introduced [components](https://docs.stripe.com/connect/get-started-connect-embedded-components) for Connect, which address many of these pain points. These pre-built, customizable UI components significantly reduce the complexity of implementing Connect. They are available as a plain JS SDK and React library to fit your needs. Here's how they help:

### 1. Simplified Onboarding

The embedded components provide ready-to-use UI elements for onboarding connected accounts. These components handle:

- Information collection
- Identity verification
- Bank account or debit card input

By using these components, platforms can dramatically reduce the time and effort required to create a smooth onboarding experience.

### 2. Automatic Compliance Updates

One of the biggest advantages of using Stripe's embedded components is that they automatically stay up-to-date with the latest regulatory requirements. This means:

- Less worry about keeping up with changing regulations
- Reduced risk of non-compliance
- Fewer resources dedicated to maintaining compliance

### 3. Customization and Branding

https://docs.stripe.com/connect/customize-connect-embedded-components
Despite being pre-built, these components offer a high degree of customization. Platforms can:

- Adjust the look and feel to match their brand
- Choose which information to collect
- Decide on the flow of the onboarding process

This flexibility ensures that platforms can maintain their unique identity while benefiting from Stripe's robust infrastructure.

### 4. Improved User Experience

The components are designed with user experience in mind. They offer:

- Mobile-responsive designs
- Clear error messaging
- Intuitive flows that reduce user confusion

This results in higher conversion rates for connected account onboarding.

## Implementation Example

https://docs.stripe.com/stripe-js/react
Here's a simple example from the [Stripe React Connect JS](https://github.com/stripe/react-connect-js) library on how you can leverage components for dashboards like Payment and Payout information.

```bash
npm install --save @stripe/connect-js @stripe/react-connect-js
```
------------

```typescript
import React from 'react';
import ReactDOM from 'react-dom';
import {loadConnectAndInitialize} from '@stripe/connect-js';
import {
  ConnectPayments,
  ConnectPayouts,
  ConnectPaymentDetails,
  ConnectComponentsProvider,
} from '@stripe/react-connect-js';

const fetchClientSecret = async () => {
  // Fetch the AccountSession client secret by making an API call to your service
};
const connectInstance = loadConnectAndInitialize({
  publishableKey: '{{pk test123}}',
  fetchClientSecret: fetchClientSecret,
  appearance: {
    variables: {
      colorPrimary: '#228403', //optional appearance param,
    },
  },
});

const App = () => (
  <ConnectComponentsProvider connectInstance={connectInstance}>
    <ConnectPayments />
    <ConnectPayouts />
    <ConnectPaymentDetails
      onClose={() => {
        console.log('closed');
      }}
      payment="pi_test123"
    />
  </ConnectComponentsProvider>
);

ReactDOM.render(<App />, document.body);
```

## Resources

For more information on Stripe Connect Components, check out the following resources:

- [Stripe Connect Components](https://docs.stripe.com/connect/get-started-connect-embedded-components)
- [Component List](https://docs.stripe.com/connect/supported-embedded-components)
- [Stripe React Connect JS](https://github.com/stripe/react-connect-js)
- [Stripe React Docs](https://docs.stripe.com/stripe-js/react)

---

[View on echobind.com](https://echobind.com/post/simplifying-stripe-connect-with-embedded-components)

---

# Browserless Puppeteer

> Skip the PDF dependencies by leveraging Browserless with Puppeteer.

_By Matt Thompson · 2024-09-04_

## Intro

During a recent migration of a service to Railway, we encountered a significant challenge with the Puppeteer package we were using for PDF generation. The package required numerous Linux dependencies, particularly for Linux-Chrome, which led to several issues:

1. Dramatically increased build times
2. Occasional build failures
3. Numerous warnings and troubleshooting logs, guided by Puppeteer's documentation:
    - [Puppeteer Linux Troubleshooting](https://pptr.dev/troubleshooting#chrome-doesnt-launch-on-linux)
    - [Puppeteer Chrome Troubleshooting](https://pptr.dev/troubleshooting#could-not-find-expected-browser-locally)

Initially, we considered creating a custom Dockerfile to manage these dependencies, as suggested in this [Puppeteer/Chrome nixpacks example](https://github.com/ryannono/Puppeteer-Railway-Buildpack/blob/main/nixpacks.toml).

However, our continued research led us to a more elegant solution: [Browserless](https://www.browserless.io/). We discovered that we could integrate Browserless within Railway to handle Puppeteer calls and manage all the necessary dependencies. This approach proved to be significantly simpler than building a custom Dockerfile, and the implementation process was surprisingly straightforward.

## The Migration

The migration ended up being a pretty easy process.

1. Create a new Railway app and select the ["Browserless" template](https://railway.app/template/0jqemX).
2. Update the `package.json` to remove the `puppeteer` dependency and instead use the `puppeteer-ci` package. (This does not include the chromium browser dependencies)
3. Include the new `BROWSER_WS_ENDPOINT` environment variable in the Railway app.
4. Update the code to connect to the Browserless instance. (see below)

```typescript
    const getBrowser = async () => {
      if (process.env.BROWSER_WS_ENDPOINT) {
        // Use Browserless for staging and production
        return await puppeteer.connect({
          browserWSEndpoint: process.env.BROWSER_WS_ENDPOINT,
        });
      } else {
        // Fallback to local Chrome instance if BROWSER_WS_ENDPOINT is not set for local development
        return await puppeteer.launch({
          headless: true,
          args: ['--no-sandbox', '--disable-setuid-sandbox', '--headless=new'],
          ignoreDefaultArgs: ['--disable-extensions'],
        });
      }
    };

    const browser = await getBrowser();
    // other logic here for generating PDFs

    const page = await browser.newPage();
    // continue with PDF generation per normal

```

In the above code, we're checking for the `BROWSER_WS_ENDPOINT` environment variable to be set. With this set, we can now leverage the `connect` method of puppeteer to connect to the Browserless instance rather than launching a local browser instance.

That was it! We were now able to leverage Browserless for PDF generation and not have to worry about any of the dependencies.

## Resources

Browserless isn't limited to Puppeteer; it's a versatile solution that also supports [Playwright](https://playwright.dev/) and [Selenium](https://www.selenium.dev/). Consider exploring Browserless for your automation needs across these popular browser automation frameworks.

- [Railway Browserless Template](https://railway.app/template/browserless)
- [Browserless](https://github.com/railwayapp-templates/browserless)
- [Browserless Docs](https://docs.browserless.io/#using-puppeteer)
- [Puppeteer Docs](https://pptr.dev/)

---

[View on echobind.com](https://echobind.com/post/browserless-puppeteer)

---

# Oops, I accidentally made our website faster by switching to Remix

> We migrated our site to a new hosting provider, and with it a new React framework. We expected the site to run a little slower. Our tests proved otherwise.

_By Alex Anderson · 2024-09-03_

Echobind cares very much about using the right tools for the job, but we’re pragmatic enough to know when it’s worth while to migrate tools and services to save a couple of bucks. 


Recently, we’ve been feeling that way about the hosting for this very website, so we decided to say goodbye to our good friends at [Vercel](https://vercel.com/) and host our website on [Railway](https://railway.app/). We made this decision to make our monthly costs a little bit more predictable, and to bring more of our sites under the same hosting umbrella.


This presented us with a small problem: Next.js. It [pairs wonderfully with Vercel](https://nextjs.org/docs/app/building-your-application/deploying#managed-nextjs-with-vercel), but requires [a bit more setup and infrastructure to run well when self-hosted](https://open-next.js.org/).


We’ve been exploring alternative frameworks, and decided to see if [Remix](https://remix.run/) would serve our needs well. Given that it’s also a React framework, porting everything over should be fairly easy, right?


### Migrating from Next.js to Remix


Moving the pages over from Next.js to Remix was actually easier than I expected. The Next.js site used App Router and React Server Components, but very few of those server components were nested.


In most cases, I could copy the page code into Remix, replace the `<Link>` tags with the Remix equivalent, and move any data fetching into the Remix `loader` function. For the nested components, I changed them so their data was passed as props instead of fetched directly in the component body. That was the bulk of the migration.


We also have a number of redirects [which Next.js handles out of the box](https://nextjs.org/docs/app/api-reference/next-config-js/redirects). In Remix, I had to create a function to process and handle those redirects for each request and run that function in the root route’s loader. 


```javascript
import { pathToRegexp } from "path-to-regexp";

const redirects = [
    {
      source: pathToRegexp("/tagged/:tag"),
      destination: "/topic/:tag",
      permanent: true,
    },
    {
      source: pathToRegexp("/blog-categories/:tag"),
      destination: "/topic/:tag",
      permanent: true,
    },
    // ...
];

async function processRedirect(pathname: string) {
  const paths = await redirects();
  for (const path of paths) {
    const match = path.source.exec(pathname);
    if (match) {
      // Match the params in the source to the params in the destination
      // This only supports a single URL param at this point. We could add more later
      const destination = path.destination.replace(
        /^\/.*\/(:.*)\/?$/g,
        (item: string, group: string) => item.replace(group, match[1])
      );
      
      // If we found a match, throw to tell Remix
      // to redirect to the correct page
      throw new Response(null, {
        status: path.permanent ? 301 : 302,
        headers: {
          Location: destination,
        },
      });
    }
  }
}
```


Another Next.js convenience that isn’t built into Remix is the `<Image>` component, which helps keep page loads fast by correctly sizing and positioning images. Fortunately, [our CMS](https://directus.io/) has image resizing built in, so we could have roughly the same effect by putting `width` and `height` on regular `<img>` tags and taking advantage of the CMS.


```javascript
// Images for blog post cards, resized to the maximum necessary size
<img
	src={`https://cms.echobind.com/assets/${image?.id}?key=blog-post-card`}
	alt={image?.description || title || ""}
	width={472}
	height={250}
	className={cn(
		"rounded-t-md grayscale group-hover:grayscale-0 transition-all duration-500 w-full max-h-64 object-cover object-center",
		{
			"grayscale-0": fullColor,
		},
	)}
/>
```

You might need something a little bit more sophisticated than what we're using. Depending on what CDN you're using, you might be able to take advantage of its image transformation services. [Unpic](https://unpic.pics) provides a really nice API for automatically creating `<img>` tags that take advantage of those image CDN transformations.

Next.js App Router comes with automatic caching and static page generation which you specifically have to opt-out of on a page-by-page basis. This hopefully makes pages really fast, but adds extra burden to developers to make sure the cache is invalidated at the appropriate times, either with [Incremental Static Regeneration](https://nextjs.org/docs/app/building-your-application/data-fetching/incremental-static-regeneration) or [On-Demand Revalidation](https://nextjs.org/docs/app/building-your-application/data-fetching/incremental-static-regeneration#on-demand-revalidation-with-revalidatetag). On our old site, we opted for the latter with automatic triggers in our CMS that sent HTTP messages to our site whenever we changed a post or page.


Remix, on the other hand, [relies on ](https://www.youtube.com/watch?v=bfLFHp7Sbkg)[`Cache-Control`](https://www.youtube.com/watch?v=bfLFHp7Sbkg)[ headers](https://www.youtube.com/watch?v=bfLFHp7Sbkg), which provides the same basic user experience without needing extra framework-level configuration. I just set a default `Cache-Control` header of `'public, max-age=300, s-maxage=3600, stale-while-revalidate'` on pretty much every page. Specifically, this says “Cache this in the browser for 5 minutes, and in a shared CDN cache for an hour. After that hour, the shared CDN cache will keep serving the stale cached content, but will re-fetch fresh content from the origin server. Hey, that’s just like ISR!


One last convenience of Next.js is automatically generating and caching Open Graph images for link embeds. For that one, [I followed this guide by Jacob Paris and](https://www.jacobparis.com/content/remix-og) turned to the same tools Next.js uses internally: [Satori](https://github.com/vercel/satori), which converts JSX into an SVG image, and [resvg](https://github.com/RazrFalcon/resvg), which turns an SVG into a PNG.


```javascript
import satori from "satori";
import { Resvg } from "@resvg/resvg-js";

export async function generatePng(jsx: JSX.Element) {
	const phantomFont = await fetch(
		new URL("https://echobind.com/fonts/PhantomSans0.8-Semibold.ttf"),
	).then((res) => res.arrayBuffer());

	const svg = await satori(jsx, {
		width: 1200,
		height: 630,
		fonts: [
			{
				name: "Phantom Sans",
				// Use `fs` (Node.js only) or `fetch` to read the font as Buffer/ArrayBuffer and provide `data` here.
				data: phantomFont,
				weight: 300,
				style: "normal",
			},
		],
	});

	const resvg = new Resvg(svg);
	const pngData = resvg.render();
	return pngData.asPng();
}
```


To avoid needing to generate these image every time a link is embedded, I upload the image to our CMS after it's generated. If the image for a post is already in the CMS, it just serves that instead of generating it again. 


---


In short, it took a bit of extra effort to switch to Remix. And I thought the payoff would just be an easy time to host (it was incredibly easy to put this new site up on Railway). I wasn’t expecting any other kinds of improvements or performance gains, so when we ran some benchmarks, I was shocked by what we saw.


### The Results


First off, Lighthouse. This is what our site looked like on Next.js:


![Lighthouse results showing 96 performance, 92 accessibility, 92 best practices, and 91 SEO](https://cms.echobind.com/assets/90f84db0-785c-4d9b-bb5b-9abd119f1a50)


And this is what our site looked like on Remix:


![Lighthouse results showing 98 performance, 100 accessibility, 96 best practices, and 100 SEO](https://cms.echobind.com/assets/eedf9eea-e2bf-4383-8ba3-5b9cc36049a7)


Again, that’s a Remix site hosted on Railway. Tough to say what exactly caused that 2 point performance improvement, but we won’t complain.


Then we tested it on [ahrefs](https://ahrefs.com/), to make sure all of our links and SEO juice was still good. We were shocked to find our health score go up by 3% to 98%, our internal URLs with errors count go down by 94 to 11, and shockingly the number of oversized images dropped from 96 to 2. 


In other words, what started off as a migration turned into a performance optimization.


And of course, this isn’t to say anything negative about Next.js or Vercel. They’re great tools and products built by great people. But switching our site to Remix and Railway paid off in spades. Not only that, but the Remix development experience feels more natural and straightforward to our developers, which makes building new features and maintaining our website all the more enjoyable.


---


If you’re looking for a great framework, pick Remix. And if you’re looking for a great team to help you build (or migrate) your site or app with Remix, [pick Echobind](https://echobind.com/contact).

---

[View on echobind.com](https://echobind.com/post/oops-i-accidentally-made-our-website-faster-by-switching-to-remix)

---

# The MVP Approach to App Development

> Start small with your app idea! Launch an MVP—a simple version to test and gather feedback. It’s like starting with a cheese pizza before the toppings! :pizza:

_By Claire Surma · 2024-08-23_

So, you've got a groundbreaking app idea that's going to change the world. Before you spend your life savings building a digital behemoth, let's talk about starting with an MVP. No, we’re not talking about the Most Valuable Player here, although it can be a game-changer. An MVP in the software world stands for Minimum Viable Product—your app's very own cheese pizza. Let me explain... 

### What the heck is an MVP?

An MVP is the most simplified version of your app or website that highlights only your core features in a way that still delivers enough value to users. The goal of an MVP is to validate if people actually want what you are selling. It allows app owners to launch quickly, gather feedback, and iterate.  

It’s like a chef serving a dialed-in cheese pizza—no fancy toppings (yet!), but next-level perfection crust and a cheese-to-sauce ratio that will guarantee return patrons, especially among the most active pizza lovers. You get customers chowing down on your delicious cheese pizza, and then you sit back and listen to what they are saying. What do the restaurant-goers love? What do they hate? Slowly, you start incorporating new toppings based on the comments you hear from real customers. With each new pizza release, you get more folks stopping by, and in turn, more feedback. By letting the customers unknowingly direct the menu, you build both dedicated fans and a pizza you are confident in to be a crowd-pleaser. 

Launching your product as an MVP means being okay with imperfection at first. Your application doesn’t have to be feature-heavy and flawless from day one. It’s about being crystal clear on your core features and then learning, adapting, and evolving. And hey, it’s way more fun than stressing over every little detail of the never-before-served PB&J and hot sauce pizza before you even know if there’s a market. Sometimes, your MVP launch will be the least painful way to realize the market isn’t there. 

### Why launch your new software idea as an MVP?

1. **Cost Efficiency and Risk Management** 
    
    Building a full-featured product costs time and money—lots of it. There are technical challenges, market acceptance issues, and changing user preferences. An MVP approach helps you manage these risks by focusing first on the must-haves, cutting down on initial costs and allowing you to tackle potential problems early, without having to sink a ton of resources into a fully developed product. Once you know your product idea is a hit, you can invest more confidently in adding bells and whistles. 
    
2. **Validate Market Need, Gather User Feedback, and Iterate** 
    
    Why build a product no one wants? It also doesn’t matter how many features your product has if you have no users. An MVP is your ticket to validating market demand. By putting out a simplified version, you can gather real-world data and make sure you’re on the right track. Launching an MVP allows you to gather user feedback right from the start. This helps you understand what users are most attracted to, what they couldn’t care less about, and where you can improve. Iterating based on real user input means a better product that keeps your audience coming back. Focus on the best feature, get users, and then listen to your audience to prioritize and iterate!
    
3. **Clarity on the “Killer Features” and Core Value Proposition** 
    
    An MVP forces you to hone in on your product’s core value proposition. By stripping away the non-essentials, you can focus on what truly sets your product apart and delivers the most value to users. This clarity is key to creating a strong product with a loyal user base. 
    
4. **[Pressure Indicating UI](https://echobind.com/post/pressure-indicating-ui) for Non-Essential Features** 
    
    Stripping non-essential features from your application’s MVP launch doesn’t mean your grand idea is all for naught; the non-essential features might come later after user behavior validates the need. One way to validate non-essential features is by including “pressure indicating UI tests” sprinkled throughout your MVP to confirm your assumptions before you pour time and money into them. Pressure indicating UI testing is a clever trick to validate what features resonate most with users. You create a clickable element on your site or app—let’s say, a bright blue button that says “Try Our New Feature!”—but the button doesn’t actually lead to the new feature. It’s a decoy, a test within a test. You can then track the clicks and get a direct measure of interest. Did a ton of users click the button? Great! That’s a strong indicator that there’s interest in your new feature. Was the button largely ignored? Maybe it’s time to rethink or refine the idea. You get genuine, unfiltered insights straight from real users who don’t know they are being tested, so their actions reflect true preferences and behaviors. This helps you prioritize development based on actual user demand.
    
5. **Scalability with Resource Optimization** 
    
    Resources are often limited in the early stages of product development. An MVP approach ensures that these resources are used efficiently. Starting with an MVP gives you the flexibility to scale based on user feedback and market demands. By focusing on the essential data-driven priorities, you can allocate time, talent, and budget where they’ll have the greatest impact. As you gather insights and validate your hypotheses, you can make informed decisions about which features to develop next. This iterative process ensures that your product evolves in a direction that aligns with user needs, market trends, and your available resources.
    
6. **Gain Fans and Early Traction for Long-Term Success** 
    
    Launching with an MVP helps you build momentum and generate buzz. Early adopters can become your biggest fans, spreading the word and attracting more users. This organic growth can provide invaluable marketing and help establish a loyal user base. Plus, early traction can attract potential investors and partners. By validating your product concept early, optimizing resources, and building a product that resonates with users, you pave the way for sustainable growth. An MVP isn’t the end game—it’s just the beginning of future version development and improvement.
    

Launching your app as an MVP isn’t skimping out, it is a savvy strategy. By focusing on what’s essential and starting with the cheese pizza basics, listening to your customers, and gradually adding those irresistible toppings, you’ll not only save time and money but also save yourself the headache of launching a full product that majorly misses the mark with your audience. From speeding up your time to market and validating market need to gathering user feedback and managing risks, an MVP lets you build a product that’s both valuable and viable. Remember, the MVP is just the beginning!

---

[View on echobind.com](https://echobind.com/post/the-mvp-approach-to-app-development)

---

# Prisma Two Ways

> Prisma has a default way to do migrations, where it manages everything from the schema. But there's nothing stopping you from migrating with raw SQL.

_By Alex Anderson · 2024-07-03_

[Prisma](https://www.prisma.io/) client makes it incredibly easy to manage and query relational databases. I love how easy Prisma’s schema definition language makes modeling complicated relationships.


### Way 1: Schema → Migration → Tables


For example, in this many-to-many relationship with multiple relationships, it’s pretty clear to see what’s going on, what’s required and what isn’t, and where the relationships all point:


```text
model User {
  id             String    @id @default(cuid())
  createdAt      DateTime  @default(now())
  email          String
  OrgUser        OrgUser[]
  InvitedOrgUser OrgUser[] @relation("InvitedBy")
}

model Org {
  id        String    @id @default(cuid())
  createdAt DateTime  @default(now())
  name      String
  slug      String    @unique
  OrgUser   OrgUser[]
}

// This is where org-specific user settings are stored
model OrgUser {
  id          String   @id @default(cuid())
  createdAt   DateTime @default(now())
  org         Org      @relation(fields: [orgId], references: [id])
  user        User?    @relation(fields: [userId], references: [id])
  invitedBy   User?    @relation("InvitedBy", fields: [invitedById], references: [id])
  name        String?
  role        String
  orgId       String
  userId      String?
  invitedById String?
}
```


And here’s that modeled as an ERD, courtesy [Prisma Editor](https://prisma-editor.vercel.app/).


![An ERD of the schema above](https://cms.echobind.com/assets/9631c7c0-79f7-432e-99e2-009aa869a641)


After writing this schema, you can run `prisma migrate dev` and it will automatically create a migration with all the changes that you have made to your schema since the last migration, and apply it to your database. Handy!


But for some, you might want to start with a SQL Migration and generate your tables from that. Prisma’s got a solution for that too!


### Way 2: Migration → Tables → Schema


First, create a new migration in the Prisma migrations folder. Note that migrations are applied in alphanumerical order, so it’s a good idea to name your migration based on the current timestamp, like Prisma does:


```sql
// /prisma/migrations/20240607153242_init/migration.sql
CREATE TABLE "User" (
    "id" TEXT NOT NULL PRIMARY KEY,
    "createdAt" DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
    "email" TEXT NOT NULL
);

CREATE TABLE "Org" (
    "id" TEXT NOT NULL PRIMARY KEY,
    "createdAt" DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
    "name" TEXT NOT NULL,
    "slug" TEXT NOT NULL
);

CREATE TABLE "OrgUser" (
    "id" TEXT NOT NULL PRIMARY KEY,
    "createdAt" DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
    "name" TEXT,
    "role" TEXT NOT NULL,
    "orgId" TEXT NOT NULL,
    "userId" TEXT,
    "invitedById" TEXT,
    CONSTRAINT "OrgUser_orgId_fkey" FOREIGN KEY ("orgId") REFERENCES "Org" ("id") ON DELETE RESTRICT ON UPDATE CASCADE,
    CONSTRAINT "OrgUser_userId_fkey" FOREIGN KEY ("userId") REFERENCES "User" ("id") ON DELETE SET NULL ON UPDATE CASCADE,
    CONSTRAINT "OrgUser_invitedById_fkey" FOREIGN KEY ("invitedById") REFERENCES "User" ("id") ON DELETE SET NULL ON UPDATE CASCADE
);

CREATE UNIQUE INDEX "Org_slug_key" ON "Org"("slug"); 
```


Once you’ve done that, you can apply the migration to your database by running `prisma migrate deploy`. 


Now that our tables are updated, we need to get that schema back down to our app so Prisma can generate the type safe client for our app. Fortunately, doing that is just a single command: `prisma db pull`


After running that command, the current structure of the database is put into your Prisma schema, nice and neat.


### Mix and Match


And there’s nothing stopping you from doing both ways in the same project. Some folks might prefer to write the schema first. Others might prefer writing raw SQL migrations. If you’re careful, have good version control, and aren’t doing too many manual things in your Prisma schema, overwriting the schema with `prisma db pull` shouldn’t be too big of a deal. If it is, you can still run it, and then use source control to make sure you’re only changing the stuff that you want to.


### Way 3: Schema → Tables


There’s another, forbidden way of using Prisma. I’m referring to `prisma db push`, which takes the current contents of your schema and puts it directly on your database. 


Yes, it gets the job done, but it’s heavy-handed. It doesn’t let you track changes or make subtle adjustments to tables before you alter them, like modifying column contents or moving data between columns. 


While it may sound tempting - why complicate things with an extra migrations step? - `prisma db push` runs the risk of accidentally overwriting or removing data. The Prisma docs have a lot more information about [when and why you might want to use ](https://www.prisma.io/docs/orm/prisma-migrate/workflows/prototyping-your-schema#choosing-db-push-or-prisma-migrate)[`prisma db push`](https://www.prisma.io/docs/orm/prisma-migrate/workflows/prototyping-your-schema#choosing-db-push-or-prisma-migrate)[.](https://www.prisma.io/docs/orm/prisma-migrate/workflows/prototyping-your-schema#choosing-db-push-or-prisma-migrate)


---


Personally, I prefer the balance of consistency, ease, and explicitness that comes from generating migrations from the schema. But maybe you really like writing SQL by hand. In either case, Prisma has options.

---

[View on echobind.com](https://echobind.com/post/prisma-two-ways)

---

# The House of Stripe

> Echobind is a Stripe Services Implementation Specialized Partner in 2024 and that honors extends into our business strategy side, too.

_By Zack Marty · 2024-06-10_

As a services implementation specialized partner with Stripe, we are often asked about whether our Stripe expertise extends into the business strategy side of the Stripe implementation. The short answer is yes, and if that is enough, then you can stop reading here, but I recommend that you keep going. When people first start thinking about Stripe it feels a whole lot like the below image. The money goes from the customer, through Stripe, and ends at your business. 

![](https://cms.echobind.com/assets/0dec8c72-d526-491c-83c7-cd810e217995)

It’s rarely this simple. Everyone would love for it to be this straightforward, but making sure that we build out the solution that aligns with your business goals and is executed strategically is of the utmost importance. The right strategy is similar to how plumbers think about building out the plumbing in a house. The way the average person thinks about plumbing is similar to the way that many think about Stripe. 

![](https://cms.echobind.com/assets/7957b113-37d8-4b3d-b08c-ac7cea96c108)

Though it may seem extremely simple, there are a number of variables that a plumber needs to consider when designing a good pipe system in a new home. Some of them are:

- Based on the water supply, what type and size of pipe do I need to use to ensure that the residents have adequate water pressure?
- How can I design the network of pipes such that water has the shortest distance to travel to and from each fixture?
- Where do the pipes need the most insulation to protect from excessive heat and cold?
- Where do I install pressure regulators to ensure that certain sections of the house have plenty of pressure while also guaranteeing that excess water pressure will not damage fixtures?
- How do I work within the space constraints of a given house based on the structure of the house and the number of required fixtures?

I could list many more considerations that a plumber will have through the house-building process, but this article is not about plumbing. It’s about how Echobind uses the right Stripe implementation strategy to help you reach your business goals.

Let’s take a look at one of our clients who had some novel needs and how we planned out the strategy to ensure that we met each and every one of their business needs.

![](https://cms.echobind.com/assets/56aa2612-d5d6-40ae-9150-546620a385ca)

### Their needs

Echobind’s client ran a platform that allowed users to donate to individuals and families who had fallen on hard times. Before they engaged with Echobind, they made every payment to the beneficiaries via paper check. However, many of these families could not wait for a check to arrive in the mail, so the client wanted donations and the disbursement of funds to move away from checks, especially since some checks never made it to their destination.  Other than those needs, they had a few others:

- They wanted site visitors to be able to tip the organization so that they could keep the site running. This meant that we needed to update the Stripe logic to make funds have multiple destinations.
- They didn’t want any of the Stripe fees to be deducted from the funds that the beneficiaries received. To do this, we organized the flow of money such that Stripe fees came directly from tips, and the money donated would arrive to the beneficiary in full.
- Oftentimes the campaign organizer and the end beneficiary were different people. This meant that we needed to create a way for beneficiaries to create a Stripe account that received funds from the campaign without them needing to be involved in the campaign.
- People would sometimes create campaigns for non-profit organizations with whom they did not have an association, so they still needed the ability for money to run through Stripe while also being able to cut a check at the end of the campaign.

This led to some exciting custom work that was outside of the bounds of Stripe’s boilerplate offerings. Echobind’s technical and product teams came up with a solution that allowed Echobind to exceed the client’s needs while also massively simplifying what the client thought would need to happen.  

### Your needs

Though that client’s needs were swiftly met, their needs are not your needs. So here are a few of the considerations we take into account when designing your Stripe implementation:

- Who needs to interact with the system?
- What platform will they use to interact with the system?
- How will they interact with it?
    - Are you making an online marketplace, a place people log into in order to pay bills, or is your organization generating payment links for services and the customers receive those payment links via WhatsApp message?
- What special regulatory considerations are needed in your industry?
    - Medicine is a far different beast than E-commerce, and we have done both.
- What special considerations are important to your organization?
- How much do we need to account for complexity vs simplicity on each side of a given transaction? In one instance we had a client who just needed to create a charge. The customer then needed to be able to dictate the pace at which they would pay the charge, allowing them to do full upfront payments or creating up to a five-year payment plan. This strategy significantly decreased defaults on payments by making them far more manageable for each customer.
- Do you need to prorate payments, like an apartment complex, or are you creating a subscription service that starts on the day it was created?

There is a whole lot more we think about when it comes to serving our client's strategic needs. Not only are we thinking about the Stripe of it all, but we also think about how the Stripe implementation will fit into your overarching product and business strategy.

If you have any questions about how we can help you with Stripe, feel free to contact lex@echobind.com.

---

[View on echobind.com](https://echobind.com/post/the-house-of-stripe)

---

# How To Build An Event Ticketing System with Astro and Directus

> Astro is excellent for content-driven websites, and pairing it with your favorite CMS creates the perfect combination.

_By Dennis Campos · 2024-06-07_

[Astro](https://astro.build/) is excellent for content-driven websites, and pairing it with your favorite CMS creates the perfect combination.

[Directus](https://directus.io/) offers a cloud-based service, Directus Cloud, as well as the option to run Directus locally. This guide will focus on setting it up locally, but you can also choose to set it up on the [cloud](https://directus.cloud/) if you prefer.

We will create a super simple event ticketing system with the following model:

![](https://cms.echobind.com/assets/6551357e-b292-4ce9-83f8-e2fecda30c74)

## Prerequisites

- Node.js ≥ 20
- Some knowledge of the Astro framework

## Set up Astro

Run the following command to initialize an Astro project

```bash
npm create astro@latest
```

Install Directus SDK

```bash
npm install @directus/sdk directus
```

I'm using Tailwind, but feel free to use what you're comfortable with or even skip CSS entirely.

```bash
npx astro add tailwind
```

Create a `.env` file. We will use SQLite, but you can choose the database you are most comfortable with. While Directus reads the `.env` file by default, you can choose to read a config file instead. For more options, please refer to the [documentation](https://docs.directus.io/self-hosted/config-options.html#configuration-options).

This serves as a good starting point for our `.env` file.

```bash
KEY="your_key"
SECRET="superSecret"

DB_CLIENT="sqlite3"
DB_FILENAME="./sqlite.db"

ADMIN_EMAIL="admin@echobind.com"
ADMIN_PASSWORD="test1234"

DIRECTUS_URL="http://localhost:8055"
```

If an admin email or password is not provided, Directus will supply default credentials, which will be displayed in the terminal.

## Set up Directus

Once your db and your config file is set up, run the following command:

```bash
npx directus bootstrap 
```

Now you should be able to run Directus locally: 

```bash
npx directus start
```

Visit http://localhost:8055 and log in with your credentials specified in the `.env`. 

If you are unfamiliar with Directus, feel free to explore before continuing.

## Creating our models

Refer to the model image displayed at the beginning of this article for assistance in creating the model and its fields.

To create our models:

- Click `settings` on the left side
- Select data model
- Create collections on the top right
- Name it `events` and click next.

I'm opting for the following fields provided by Directus: `date_created`, `date_updated`, and `status`. You may add or omit these options according to your needs. It won't affect the instructions in this guide.

![](https://cms.echobind.com/assets/1a8162d2-dfd8-4fc7-8503-ebb88a7d459d)

Now that we have successfully created our model, let's proceed to create our fields. You can refer back to the model image to add the necessary fields. For illustration purposes, I will guide you through the creation of one field. The process will be similar for the remaining fields.

- Create Field
- Select Input
- Under `key` input title and a type of `string`
- Select `require value to be set on creation`
- Save

Now that you know how to add a field, please continue adding the remaining fields according to the model image provided earlier.

Noting the `tickets` model, we will add a [many-to-one](https://docs.directus.io/app/data-model/relationships.html#many-to-one-m2o) relationship. This indicates that many tickets can belong to a single event.

Here is how it should look.

![](https://cms.echobind.com/assets/3b11c729-3d6c-4de4-b1c0-815a2477a2df)

![](https://cms.echobind.com/assets/2a3c2009-c0e9-45bf-a2ae-a2c4dd4e1cd0)

**Important -** To read, create, update and perform other tasks, we must provide access control. Otherwise, an error will occur in your application.

### Access Control

- Go to settings
- Access Control
- Select Public
- Click on the `read access` icon for the collections. It should change to a checkmark.

In our app, we are not creating or updating anything because we are handling these tasks through Directus. However, feel free to do so if you plan on expanding beyond this guide.

## Set up types and Directus client

Head back into our app and create a file name `directus.ts`  under `src/lib` 

Let's define our types based on our image model. Here is what it should look like:

```tsx
export type Event = {
  id: number;
  title: string;
  description: string;
  dateOfEvent: Date;
  location: string;
};

export type Ticket = {
  id: number;
  eventId: Event["id"];
  type: string;
  price: number;
  quantity: number;
};

export type Schema = {
  events: Event[];
  tickets: Ticket[];
};
```

We will use `rest`. Alternatively, you can opt for `GraphQL` if you prefer that.

```tsx
import { createDirectus, rest } from "@directus/sdk";

export const client = createDirectus<Schema>(import.meta.env.DIRECTUS_URL).with(
  rest()
);
```

This is how the entire file should look.

```tsx
// src/lib/directus.ts
import { createDirectus, rest } from "@directus/sdk";

export type Event = {
  id: number;
  title: string;
  description: string;
  dateOfEvent: Date;
  location: string;
};

export type Ticket = {
  id: number;
  eventId: Event["id"];
  type: string;
  price: number;
  quantity: number;
};

export type Schema = {
  events: Event[];
  tickets: Ticket[];
};

export const client = createDirectus<Schema>(import.meta.env.DIRECTUS_URL).with(
  rest()
);

```

## Add data in Directus

Head back to Directus and let's add some data.

I had ChatGPT generate some events for me. Here is the JSON file in case you want to copy and paste http://jsonblob.com/1247570720585539584 or create your own! And here is the data for tickets: http://jsonblob.com/1247582973435174912 

**Note:** You will want to attach the `eventId` to an event from your event data. The `ID` displayed in the link above is probably not going to match what you have. 

## Display data in Astro

It is time to display our added events from Directus. 

Head to our index file `src/pages/index.astro`   and fetch our data using Directus sdk

```tsx
// src/pages/index.astro
---
import { readItems } from "@directus/sdk";
import { client } from "../lib/directus";
import { formatDateToLocale } from "../utils";
import Layout from "../layouts/Layout.astro";

const events = await client.request(
  readItems("events", {
    fields: ["id", "title", "description", "dateOfEvent", "location"],
  })
);
---
```

Our markup

```tsx
// src/pages/index.astro

<Layout title="Welcome to Astro.">
  <div class="pt-10 pb-20 px-10">
    <h2 class="text-6xl font-bold mb-4">Events</h2>
    <div class="space-y-10">
      {
        events.map((event) => (
          <div class="flex w-[700px] shadow-lg rounded-lg">
            <div class="flex flex-col justify-center items-center p-4 bg-zinc-200">
              <p class="font-bold text-3xl">
                {formatDateToLocale(event.dateOfEvent).month}
              </p>
              <p class="font-bold text-4xl">
                {formatDateToLocale(event.dateOfEvent).day}
              </p>
              <p class="font-bold text-3xl">
                {formatDateToLocale(event.dateOfEvent).time}
              </p>
            </div>

            <div class="flex flex-col bg-zinc-50 p-4 space-y-7 w-full">
              <h2 class="text-3xl font-bold">{event.title}</h2>
              <p>{event.description}</p>

              <div class="flex justify-between">
                <p class="font-bold">{event.location}</p>
                <a href={`/event/${event.id}`} class="text-blue-500">
                  Learn More
                </a>
              </div>
            </div>
          </div>
        ))
      }
    </div>
  </div>
</Layout>
```

In a separate terminal, launch the development server. Make sure the Directus server is also running.

**Note:** The `formatDateToLocale` function above accepts a `Date` object and formats it into `month`, `day`, and `time` values as illustrated below. Feel free to create your own version.

The outcome:

![](https://cms.echobind.com/assets/a6bbcd18-2592-4c27-8613-38c123dad4f9)

## Display a single event

We can generate data based on an event using the parameters and Astro's `getStaticPaths()` function. More information is available [here](https://docs.astro.build/en/reference/api-reference/#getstaticpaths).

Create a file name `index.astro`  under `src/pages/event/[id]` and add the following:

```tsx
// src/pages/event/[id]/index.astro
---
import { readItems } from "@directus/sdk";
import { client, type Ticket } from "../../../lib/directus";
import { formatDateToLocale } from "../../../utils";
import Layout from "../../../layouts/Layout.astro";

export async function getStaticPaths() {
  const events = await client.request(readItems("events"));
  const tickets = await client.request(readItems("tickets"));

  return events.map((event) => {
    const eventTicket = tickets.find((ticket) => ticket.eventId === event.id);
    return {
      params: {
        id: event.id.toString(),
      },
      props: {
        event,
        ticket: eventTicket as Ticket,
      },
    };
  });
}

const { title, description, dateOfEvent, location } = Astro.props.event;
const { type, price } = Astro.props.ticket;
---
```

Our markup

```tsx
// src/pages/event/[id]

<Layout title="Event">
  <div class="max-w-4xl mx-auto bg-white p-8 rounded-lg shadow-md my-10">
    <h1 class="text-2xl font-bold mb-4">{title}</h1>
    <div class="event-details mb-6">
      <p class="mb-2">
        <strong>Description:</strong>
        {description}
      </p>
      <p class="mb-2">
        <strong>Date and Time: </strong>
        <span>{formatDateToLocale(dateOfEvent).day}</span>
        <span>{formatDateToLocale(dateOfEvent).month}</span>
        <span>{formatDateToLocale(dateOfEvent).time}</span>
      </p>
      <p class="mb-2"><strong>Location:</strong> {location}</p>
    </div>
    <div class="ticket-info mb-6">
      <h2 class="text-xl font-semibold mb-2">Tickets</h2>
      <p class="mb-2">
        <strong>Type:</strong>
        {type ? type : "General Admission"}
      </p>
      <p class="mb-2"><strong>Price:</strong> ${price ? price : "150"}</p>
      <div class="mb-4">
        <label for="quantity" class="block mb-1"
          ><strong>Quantity:</strong></label
        >
        <input
          type="number"
          id="quantity"
          class="border border-gray-300 p-2 rounded w-full max-w-xs"
          value="1"
          min="1"
          max="10"
        />
      </div>
    </div>
    <a
      href="#"
      class="purchase-button inline-block bg-blue-500 text-white py-2 px-4 rounded hover:bg-blue-600"
      >Purchase Ticket</a
    >
  </div>
</Layout>
```

Outcome

![](https://cms.echobind.com/assets/3738f1aa-549d-4352-8841-16485f5a40f8)

## Summary

In this guide, we built a simple event ticketing system using Astro and Directus. With Directus set up, we fetched and displayed event data in Astro, and even created dynamic routes for individual event pages. This project highlights how Astro and Directus can work together to create a powerful, content-driven event management system.

There are so many ways this can be improved and expanded. Whether you are building a simple event site or a full-featured application, this guide gives you the tools to get started and plenty of room to grow.


*Dennis Campos is a software engineer here at Echobind. Want to work with us? Reach out at hi@echobind.com anytime.*

---

[View on echobind.com](https://echobind.com/post/how-to-build-an-event-ticketing-system-with-astro-and-directus)

---

# Dynamic OG Images 

> Do you ever want more control over your OG images for SEO purposes? Maybe you want to overlay some text dynamically? A blog title, perhaps. Read on to see how we implemented this inside our Rails app.

_By Matt Thompson · 2024-06-05_

## Dynamic OG Images

Do you ever want more control over your [OG images](https://ogp.me/) for SEO purposes? Maybe you want to overlay some text dynamically? A blog title, perhaps.

While there are many ways to accomplish this, continue on to see how I used [MiniMagik](https://github.com/minimagick/minimagick) within [Rails Carrierwave](https://github.com/carrierwaveuploader/carrierwave?tab=readme-ov-file#using-minimagick) to generate just that. 

## Overview

A quick application overview before we dive in. 

```ruby
# modles/post.rb
class Post < ApplicationRecord
  mount_uploader :featured_image, FeaturedUploader
```

```ruby
# app/uploaders/featured_uploader.rb
class FeaturedUploader < CarrierWave::Uploader::Base
  include CarrierWave::MiniMagick

  storage :aws

  version :thumb do
    process resize_to_fit: [50, 50]
  end

  version :og do
    process resize_to_fill: [1200, 630]
  end
  
  # ...other options 
end
```

I have a standard Rails app with a `Post` Modal. 

That model has a `featured_image` column tied to Carrierwave through our FeaturedUploader class. In our current state, uploading an image to `featured_image` and saving the post will tell Carrierwave to generate two additional versions: a “thumbnail” that’s 50x50 and an “og” version that’s 1200x630 (recommended OG sizing). This is good on its own, but it only resizes our image. 

What if we wanted to do more? 
Insert MiniMagick options! 

## Overlaying Text

Our `Post` model also has a `title`. Let’s tap into that column for our text overlay. 

We will add a few more helpers inside our featured uploader and model. I’ll paste the code below, and then we’ll walk through what is happening. 

```ruby
# post.rb 
class Post < ApplicationRecord
  after_save :recreate_og_image

  def recreate_og_image
    return unless saved_change_to_title? || saved_change_to_featured_image?

    featured_image.recreate_versions!(:og) if featured_image.present? && title.present?
  end
```

```ruby
# app/uploaders/featured_uploader.rb

  version :og do
    process resize_to_fill: [1200, 630]
    # NEW LINE HERE
    process :add_text_overlay
  end
  
  private 
  
  def add_text_overlay
    title = title_text

    manipulate! do |img|
      img.combine_options do |c|
        c.gravity 'Center'
        c.pointsize 50
        c.draw "text 0,0 '#{title}'"
        c.fill 'white'
      end
    end
  end

  def title_text
    if model.present? && model.respond_to?(:title)
      model.title
    elsif title.present?
      title
    else
      'Draft'
    end
  end

  def manipulate!
    cache_stored_file! unless cached?
    image = ::MiniMagick::Image.open(current_path)
    yield(image)
    image.write(current_path)
  end
end
```

Let’s take this step-by-step. 

### Step 1: Adding the `after_save` Callback in the Post Model

In your `Post` model, add an `after_save` callback that triggers the recreation of image versions if the title has changed.

```ruby
class Post < ApplicationRecord
  after_save :recreate_versions_if_title_changed

  private

  def recreate_versions_if_title_changed
    if saved_change_to_title? && featured_image.present?
      featured_image.recreate_versions!(:og)
    end
  end
end
```

### Step 2: Adding the `add_text_overlay` Process in FeaturedUploader

In your `FeaturedUploader`, add the `add_text_overlay` process to the `og` version. When the OG version is recreated, this method will run again after resizing. Feel free to mix and match process methods per version. 

```ruby
 version :og do
    process resize_to_fill: [1200, 630]
    # NEW LINE HERE
    process :add_text_overlay
  end
```

### **Step 3 (The real logic)**

add_text_overlay uses `manipulate!` from Carrierwave::MiniMagick to kick us off.. but there’s one catch. If I’m uploading the image from the form, I have the raw image file in hand. However, if I’m calling this from an after_save hook (title change), I’ll have the MiniMagik instance of this image with pointers to the file. 

To help with this, we’ve added a `manipulate!` method to override the previous one. In this method, we check to see if we have the cached temp file from our form first, and if not, leverage MiniMagick to open the file it has in hand. This ensures we have a raw image file before doing extra manipulations. Likewise, you’ll notice we do the same for the title, as depending on the trigger, the title may come from the `model` or straight as a field reference. 

```ruby
  private 
  
  def add_text_overlay
    title = title_text
    # add some sanitation helpers here for special characters...

    manipulate! do |img|
      img.combine_options do |c|
        c.gravity 'Center'
        c.pointsize 50
        c.draw "text 0,0 '#{title}'"
        c.fill 'white'
      end
    end
  end

  def title_text
    if model.present? && model.respond_to?(:title)
      model.title
    elsif title.present?
      title
    else
      'Draft'
    end
  end

  def manipulate!
    cache_stored_file! unless cached?
    image = ::MiniMagick::Image.open(current_path)
    yield(image)
    image.write(current_path)
  end
```

### **The Options**

[MiniMagick](https://github.com/minimagick/minimagick) has a ton of options, and this post barely scratches the surface. If you are diving in, I would encourage you to give their docs a good read. 

Let’s take a closer look at this section of our code. Here, you can see that we are tapping into options to perform a few actions. We draw some white text centered on the page, with a point size of 50. 

```ruby
     img.combine_options do |c|
        c.gravity 'Center'
        c.pointsize 50
        c.draw "text 0,0 '#{title}'"
        c.fill 'white'
      end
```

## **Step 4 (Test it out!)**

It’s Rails. Assuming you have scaffolded some CRUD routes, we can save the title and a featured image to see our result. Opening up our show view, we can add the line below to tap into our `og` version of the file saved and see the results.    

```ruby
# views/posts/show.html.erb 
... 
  <%= image_tag @post.featured_image.og.url %>
```

**And that’s it!** 

*Local Rails Demo*

![my-cool-og-post](https://cms.echobind.com/assets/e3da637c-7dc2-4c27-925d-fda718573795)
## Next Steps

Tapping into MiniMagick more opens up endless possibilities, with multiple image overlays and more. 

![my-cool-og-post-with-images](https://cms.echobind.com/assets/81be0e66-ef21-45ba-a784-ef17673a364e)
👋🏼 **Until next time!**

---

[View on echobind.com](https://echobind.com/post/dynamic-og-images)

---

# Roll your own CDN 

> What are CDNs, do you need one and how to create your own with S3 and CloudFront.

_By Matt Thompson · 2024-06-05_

## TL;DR

In this article, we will cover CDNs, whether you need one, and how to create your own with S3 and CloudFront. If you're curious about any of this, read on!

## What are CDNs

What is a CDN? A Content Delivery Network (CDN) is a system of distributed servers that deliver web content to users based on their geographic location. This results in faster load times and improved performance, as content is served from a server closer to the user.

When it comes to CDNs for images, you've likely heard of major players like Cloudinary, Imgix, and ImageKit. These services excel with features like end-user cropping tools, extensive transformation options, and even new AI features to help enhance and edit. However, these benefits often come with significant costs and potential vendor lock-in. Additionally, features like external backups can quickly push you out of the free tier, making these services overkill for many use cases.

So, do you even need a CDN? 

## Evaluating CDNs

Before setting up a CDN, consider whether you actually need one. For simple apps with a few static images—such as logos and accent images—hosting them alongside your app under `public/assets/` may suffice. With hosts like [Vercel](https://vercel.com/), placing images into a `public` folder will leverage their own CDN as the app is distributed. A CDN becomes essential when serving numerous dynamic assets to a global audience. For instance, blogs and e-commerce sites with images and videos for each post or item benefit greatly from a CDN, as it improves load times and SEO, especially for users far from your primary server location. 

As previously mentioned, all of this can come at a cost if you aren’t careful. Are there other solutions? Of course! It’s 2024, we have all sorts of options. 

## Setting Up Your Own CDN with S3 and CloudFront

If you decide a CDN is right for you but don't need the extensive features of services like Cloudinary, setting up Amazon S3 and CloudFront can be a cost-effective alternative. You can upload images to S3 in a way that suits your application, and once there, CloudFront can serve them globally without any issues.

Below, we will go over step-by-step to see what it takes to roll your own CDN with AWS. 

To start, I’m going to assume you have the following: 

- An [AWS account](https://aws.amazon.com/) and basic working knowledge of the AWS console.
- A domain you wish to use for your CDN. (optional, but recommended)
    - Basic understanding of DNS to add a CNAME. (we’ll walk through it 🙂)

In our approach below with S3 and Cloudfront, you can create a base CDN for nearly free (outside our domain usage). Cloudfront / S3 costs are usage-based, and their free tier is quite extensive.  

[CloudFront Pricing](https://aws.amazon.com/cloudfront/pricing/)

![](https://cms.echobind.com/assets/edf53b5e-428e-4019-b1f3-ea3a2ea2e83c)

## Creating the Bucket

First things first: We need a place to store our images. Insert good ‘ol AWS S3, which is known for becoming the junk drawer for most website assets. Let us head over to the AWS Console to S3 and create a new bucket. Feel free to name this bucket whatever you’d like, preferably something that makes sense for your application and/or environment. Example:`mysite-dev-assets` (local dev) `mysite-assets` (prod). 

When creating the bucket, you’ll want to leave everything as PRIVATE and block all public access. We’ll update the Bucket Policy later to include the permissions we need.

![](https://cms.echobind.com/assets/0cfb9a53-b50e-4baf-b533-c30256da05b5)

While we are here, go ahead and upload an image to your bucket. Feel free to use any image you would like or our puppy friend below. Be sure to name the file something easy, as this will become part of our URL later.  `puppy.jpeg` > `Screenshot Something something today's date.jpeg`

![](https://cms.echobind.com/assets/24ca854e-6289-47cd-a165-dd558cde1831)

## Creating the CDN with Cloudfront

Alright, so now we have a bucket. Let's use CloudFront to create a CDN with our new bucket as the source. In AWS, search for CloudFront and navigate to its dashboard.  Select “Create Distribution”. If this is your first time, you may see a marketing landing page from AWS instead of the normal dashboard - the link should be on the right side in their standard yellow as “get started”.  

You should be brought to a screen like the one below. Under Origin Domain, find your newly created bucket. Once selected, the name will auto-fill as well. I tend to leave this be and let it match, but feel free to update it to your liking (remember the name should you change it).

![](https://cms.echobind.com/assets/14b69631-331c-4dd6-8425-433832651e2f)

The rest of the defaults should be good to start, but we’ll highlight a few to check here below. 

We’ll only need GET access from our CDN, and we’ll want to leave this as HTTP & HTTPS for now. 

**Protocol Access**

![](https://cms.echobind.com/assets/57ddc561-2854-4b0a-8ec3-a778961452d7)

**Logs**

One sneaky way AWS will hit your budget is with logs… unless you have a real need leave all the log options to “off” and “no” respectfully.

![](https://cms.echobind.com/assets/cee9f5de-a3d0-4edb-a7cf-5649e7814242)

**Firewall WAF**

This one is optional but worth pointing out. AWS offers some base protections for your CDN out of the box. You’ll note below that even at 0 requests, it’s a base $8.00 to add on. At something like 1 million requests, they estimate the WAF cost around $14.00. 

This seems like a nice addition, but it can be added anytime. We’ll skip this step for now, but feel free to enable it if you are okay with the base cost starting out. For our basic site, we’ll look at a free CDN (or close to it minus the domain).

![](https://cms.echobind.com/assets/52aa4fe6-2b02-4385-b8de-3ba1660c5b24)

**Settings** 

Keep all the recommendations for Settings as well. Using all edge locations doesn’t really affect your cost—recalling the image above, it’s usage-based, meaning traffic comes through CloudFront regardless of location. 

Note the section for the **Custom SSL Certificate.** We’ll be back here later to update this.

![](https://cms.echobind.com/assets/eb2df9ae-b8b7-4f40-86f1-4dae28b3f2b5)

**Click CREATE!** 

… spinning … spinning … AND Don’t close those toast warnings!

![](https://cms.echobind.com/assets/e119847f-31ac-49ab-ba78-38150a48d219)

If we’ve done everything correctly, AWS tries to warn you that the Bucket Policy will need to be updated. You should see a Toast message with a “Copy Policy” button. If not, that’s ok. We can still take note of the `ARN` from the dashboard above to add our new bucket policy. 

If you copied the Bucket Policy, you should end up with something like the following. If not, take note of the `ARN` and your bucket name to stitch together the JSON below. While we are still on the CloudFront distribution page, copy the `Distribution domain name` somewhere for future use. This is our new CDN URL (internal use). 

**Sample Bucket Policy**

```json
{
    "Version": "2008-10-17",
    "Id": "PolicyForCloudFrontPrivateContent",
    "Statement": [
        {
            "Sid": "AllowCloudFrontServicePrincipal",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::{YOUR_BUCKET_NAME}/*",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceArn": "{CLOUDFRONT_ARN}"
                }
            }
        },
    ]
}
```


## Bucket Policy (CDN Permissions)

Let us navigate back to S3 and our Bucket. 
Navigating to the permissions tab and scrolling down, you’ll see a white text box awaiting our new Bucket Policy. Let’s add the snippet above here and click save. 

This tells AWS that our CloudFront CDN has `GetObject` permissions for this specific bucket. i.e., it has read permissions for our future GET calls.

![](https://cms.echobind.com/assets/0dd779ef-591b-406e-8716-98414437468c)

## Testing our CDN

Remember that `Distribution domain name`; let's give it a whirl. 

On its own, you’ll hit a nasty AWS permission XAML screen. We don’t have any `index` page set for this route as it’s not a full “site,” and that’s okay. 

Rather, you’ll want to match your buckets folder/asset structure and try to access your image.

If you uploaded our `puppy.jpeg` image to your bucket earlier, your URL should look something like this. 

`your-domain.cloudFront.net/puppy.jpeg`

If everything checks out, you should see our puppy friend hosted by your new CDN in your browser. If not, double-check the Bucket Policy and CloudFront status. Ensure everything is deployed, permissions are correct, and the URL/image you are trying to access exists in your bucket. 

🎉🎉🎉

Take a moment to celebrate and grab a beverage. We have a CDN! 

🎉🎉🎉

Next, we’ll add a domain and IAM permissions to finish getting this tied into something we can use in the real world.  

## DNS, It’s always DNS

Our CloudFront domain works, but I would not recommend showing the internal AWS domain to end users. It’s not the end of the world for CloudFront, but we try to avoid it as an AWS best practice in general. The more we can hide internals from end users, the better. 

We can use a subdomain to alias our CDN via a CNAME if you have a domain handy. `assets.mysite.com/puppy.jpeg`  

### Adding a Subdomain Alias

Navigate to where your domain is hosted, including Route53, DNSimple, GoDaddy, etc. 

We aim to add a single CNAME for our new CDN Subdomain. 

**CNAME:** `assets.mysite.com.` (*Note the end `.` may not be needed for some sites*)

**Content/Value:** [`your-domain.cloudfront.net`](http://your-domain.cloudfront.net) (copy your CDN Domain here) 

**TTL:** Lower this to 1min or the smallest integer to kick everything off. Once set, we can bump this back up to the standard hour. 

**DNSSimple Example:**

![](https://cms.echobind.com/assets/f5bc4bba-3c87-4d20-900a-b7b79da8ce72)

### SSL Certificate

CloudFront expects everything to be over HTTPS. For everything to work properly, we’ll need an SSL cert for our new subdomain tied to our instance. 

Head back over to the AWS console, but leave a tab open for more DNS changes. 

In AWS, search for a service called `Certificate Manager`. We’ll use this to generate our SSL certificate. Similar to before, if this is your first time, you may see the landing page. Look for a “Request Certificate” button, and we’ll dive in. 

🚨The first thing you’ll want to check in the top right is that your AWS region is set to “N. Virginia ‘us-east-1’”. CloudFront has a requirement here for us-east-1. Once in ‘us-east-1’, we can continue with Request Certificate. 

Here, you’ll select `public` and land on the form for your SSL cert. 
You’ll only need to add your new subdomain to the `fully qualified domain name` list. *Note: if you want `www` as a part of this, add both here. (`assets.mysite.com` &[`www.assets.mysite.com`](http://www.assets.mysite.com))*

![](https://cms.echobind.com/assets/ac8eecb3-6615-4349-8994-cda97f7dab71)

Leave DNS validation, the default algorithm selected, and any tags (if you prefer), then click request. 

Once created, you should see the start of the new SSL cert pending with a new CNAME name and value for your domain. *(You may need to refresh this page as it continues processing to see the updates)*

![](https://cms.echobind.com/assets/92b5dfa2-6777-4aac-95e6-8a874f771270)

… and you guessed it. Navigate back to our DNS tab, and let's add that CNAME. Similarly, set the TTL here to something short until DNS has caught up and provisioned.  

*Note: If you already have an SSL Certificate from your domain provider for **the subdomain**, you can also use the `import` feature.* 

### Updating the CDN Settings

https://dnschecker.org/

We're almost there—DNS may take a bit to update. While we wait, let’s finish up our last step back in AWS. Under the CloudFront dashboard, let's select our distribution and click “Edit”.

There are TWO settings we’ll need to update here. 

**Alternate Domain Name (CNAME)**

This step is crucial for CloudFront to correctly associate the custom domain with your distribution and serve content over HTTPS using the appropriate SSL certificate.

![](https://cms.echobind.com/assets/bd001b6e-d503-44b8-8681-615c2a129f3b)

**Adding the SSL Cert to CloudFront** 

Find and select your new SSL cert.

![](https://cms.echobind.com/assets/2c6bd7f6-0c27-45ca-a716-9e5b84fc18cd)

**Click Save and wait for it to deploy…** 

## Testing… Take 2

Once deployed, you should be able to see `puppy.jpeg` under your new CNAME alias. 

[`assets.mysite.com/puppy.jpeg`](http://assets.mysite.com/puppy.jpeg)

![puppy.jpeg](https://cms.echobind.com/assets/d5945592-e73e-4c41-987f-fe7f19f1428d)

## Applications In Practice

We have a CDN 🎉… but how do we get images in it?!  

To get images into our source bucket, we’ll want to leverage an SDK with our app and utilize IAM keys for security. This could be any stack you choose, such as Node, Rails, C#, etc. The main change here is that we’ll need to update our Bucket Policy also to allow IAM keys for full CRUD operations. 

Depending on your stack, the SDK will guide you on using the IAM key and secret to perform S3 operations. I won’t try to cover all those options here. We’ll simply look to create the IAM role and update the bucket policy for any stack to utilize. 

Navigate to the AWS console one last time, and let's search for the `IAM` section. We will create a Programtic-only user and generate an API Key and Secret. Select the `Users` link on the left and `create a user`. Give this user a name specific to your application and environment for easy reference in the future (myapp-dev). Do NOT check the “access to console” option; our app will not need this. Next, click `attach policies directly` in the set permissions tab and search for “S3” in the new list. While you can refine which permissions you give these API keys, I’ll give it “[AmazonS3FullAccess](https://us-east-1.console.aws.amazon.com/iam/home?region=us-east-2#/policies/details/arn%3Aaws%3Aiam%3A%3Aaws%3Apolicy%2FAmazonS3FullAccess)” to start (for demo’s sake). Continue to review and create; here, you can download and copy your key and value sets. 

🚨Throw this in something like 1Password for future use - you will not see it again. 

Once created, you should land back on the user’s dashboard. 
Select your new user and take note of the `ARN` for that user.

It should look something like this: 

`arn:aws:iam::{some-id}:user/{my-user-name}` 

Copy this somewhere, and let's head back to our S3 bucket to make one final Policy change. 

We’ll want to include BOTH the CloudFront permission and now our IAM permissions.

```json
{
    "Version": "2008-10-17",
    "Id": "PolicyForCloudFrontPrivateContent",
    "Statement": [
        {
            "Sid": "AllowCloudFrontServicePrincipal",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::{YOUR_BUCKET_NAME}/*",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceArn": "{CLOUDFRONT_ARN}"
                }
            }
        },
        // NEWLY ADDED PERMISSION SET FOR IAM ROLE 
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "{IAM_USER_ARN}"
            },
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::{YOUR_BUCKET_NAME}",
                "arn:aws:s3:::{YOUR_BUCKET_NAME}/*"
            ]
        }
    ]
} 
```

## Summary

Congratulations. 

Now, when your application tries to upload or manage assets in this bucket, the IAM role has permission to do so. All while CloudFront and your domain are set to serve these assets as a CDN. 

We did it! 

Just remember, any time you want to use an asset — you’ll prefix it with your new [`assets.mysite.com`](http://assets.mysite.com) domain instead of the raw S3 path or internal CloudFront domain. 

## Bonus: Image Variants

As mentioned before, any stack/SDK can manage to upload images to your bucket. 
Multiple free solutions exist to convert larger images into different variations for application use. You could leverage the [Sharp](https://sharp.pixelplumbing.com/) or [ImageMagick](https://www.npmjs.com/package/imagemagick) kits in Node, for example. For Rails, you’ll likely leverage [Active Storage](https://guides.rubyonrails.org/active_storage_overview.html) or [Carrierwave](https://github.com/carrierwaveuploader/carrierwave), leveraging MiniMagick/Imagemagik in a similar way. 

The path here is up to you; the result is that you’ll have some async process to manipulate the raw image and leverage the S3 SDK to upload that new version to your source bucket. 

Below is a quick Rails / Carrierwave example: 
Here, we are leveraging MiniMagick to create a thumbnail and header variants. 

With Carrierave, we can also tack on our `asset_host` for a quick lookup later on when accessing this image from the model. We can create a quick util in our Model to nab the cdn_url on the fly.

```ruby
# app/uploaders/image_uploader.rb 

class ImageUploader < CarrierWave::Uploader::Base
  include CarrierWave::MiniMagick

  storage :aws

  def store_dir
    # This would store in S3 as post/2/images/{versions}.jpeg 
    "post/#{model.post_id}/#{mounted_as.to_s.pluralize}"
  end

  # Create different versions of your uploaded files:
  version :thumb do
    process resize_to_fit: [50, 50]
  end

  version :small_og do
    process resize_to_fill: [300, 157.5]
  end

  version :og do
    process resize_to_fill: [1200, 630]
  end

  def asset_host
    'https://assets.mysite.com'
  end

  # Add an allowlist of extensions which are allowed to be uploaded.
  # For images you might use something like this:
  def extension_allowlist
    %w[jpg jpeg gif png]
  end
end

```

------

```ruby
# A join table of Posts and Images 
class PostImage < ApplicationRecord 
  ... 
  mount_uploader :image, ImageUploader

  # psuedo code helper to get the cdn_url for thumb, og, or the raw image.
  # https://assets.mysite.com/post/3/thumb_puppy.jpeg 
  def cdn_url(type = :raw_image)
    *#[:thumb, :og, :small_og]*
    version_keys = image.versions.keys 

    uploaded_image = if version_keys.include?(type.to_sym)
                       image.send(type)
                     else
                       image
                     end

    "#{uploaded_image.asset_host}/#{uploaded_image.path}"
  end
end
```


*Matt Thompson is a senior software engineer here at Echobind. Work with him and our talented engineers by reaching out to us at hi@echobind.com today.*

---

[View on echobind.com](https://echobind.com/post/roll-your-own-cdn)

---

# How To Make A Fantastic & Informative Flowchart

> How to make a complex flow chart with easy-to-follow guidelines.

_By Zack Marty · 2024-06-03_

For anyone who has ever needed to make a flowchart, they can seem like a daunting task, especially when they become harder to read as they become more complex. If you need to make a complex flow chart, below are some guidelines for how you can make them easier to read for your audience.

These are not hard and fast rules, but they should generally be followed as well as possible. These rules do not necessarily apply to things like technical diagrams, but many of them can be used for technical diagrams that can get quite messy.

### **Rule 1. Multiple Arrows:**

When multiple arrows originate from one shape, they should come from a decision point, which is typically indicated by a diamond AND when they come from a diamond, efforts should be made to make them come from multiple sides. If they have to come from one side, they need to come from the same point. This is the longest rule, so don’t worry, they’ll get shorter as we go.

So let’s chat about these rules. The reason we create a decision point even when we don’t necessarily need one, is to prepare the viewer to know that we will be branching into different directions. You will have spots where something asks, “How do they log in?” and then you can proceed to show each of the ways in which a user will log in.

The reason we have them come from multiple sides rather than the same side is that it makes it visually easier to come back to when you have multiple arrows, and it makes it easier to give yourself breathing room while making the flow chart. In the event that you need to make them come from the same side, then you need to make them come from the same point. Why? Because it looks messy and unprofessional if they are just slightly off from each other.

![](https://cms.echobind.com/assets/05d33cbd-d885-4a77-a32d-5bad169800dd)

### **Rule 2. Words on Arrows:**

When words are entered on an arrow, they should be close enough to the point of differentiation that you don't need to move your eyes to see them. Oftentimes, when you have a point of differentiation that says something like, “Did the payment succeed?” followed by a yes and no scenario, you will place the Yes’s and No’s on the arrow instead of wasting space with a whole box.

Any time that you need to do this, your Yes’s and No’s should be as close to the point of differentiation as possible, ESPECIALLY if you have more than two options. Like “What color did they pick?” Red, green, blue could be the options. Red means the bomb explodes, Green means the timer on the bomb in the action movie speeds up, and blue means you successfully diffused it.

In this scenario, red, green, and blue on the arrows close to the point of differentiation makes it so that I don’t need to go searching for what choice was made along the flow chart. That being said, in the scenario of color choices, I might just make the arrows red, green, and blue.

![](https://cms.echobind.com/assets/a538af16-bd71-40f6-a592-589e7921d6d9)

### **Rule 3. Shape Assignment:**

Tasks should always have a designated shape associated with them. As mentioned before, I use diamonds for decision points, and I also use this quadrilateral shape to indicate an action that someone took, like “I click on the submit button.”

![](https://cms.echobind.com/assets/8ca95999-d384-42d8-a8e8-1c5a9f19e93f)

I tend to use this wide cylinder for any type of database entry, and I use rectangles for processes that happen, like “a timer appears on the screen.”

![](https://cms.echobind.com/assets/2504d9e1-73fb-4471-9987-7ff293cca33b)

If you’re going to use a quadrilateral for user actions, then always use the quadrilateral for any user action, and if you want to designate different users performing an action, then you can use another color rather than using a separate shape. The other part of this is that you don’t want an event to be listed on an arrow. If I ask the question. “Did they type the correct password?” then **Yes** and **No** can be listed on the arrows as designators, but you wouldn’t want the next action taken to be listed on the arrow. That action, event, or task should get a shape.

![](https://cms.echobind.com/assets/258d61f2-79dc-4952-beb9-a31de7d01263)

### **Rule 4. Shape Rules:**

The role that a given shape has should be consistent across a given diagram and the audience. To make information absorption as easy as possible, on a given flow chart, your shapes need to be consistent to the action or process they represent. Various blogs will claim that one shape should be used to indicate one thing or another, but ultimately, they just need to be consistent across a given diagram and the people to whom you show your flowcharts.

At some point last year, I went from user actions being rectangles to making them quadrilateral. It’s relatively insignificant to pretty much everyone except for me, but if someone new is looking at one of your charts, then they should be able to distinguish between the various actions and processes at a glance.

![](https://cms.echobind.com/assets/188df5f0-4d6f-463d-9051-53c30f970c07)

### **Rule 5. Don’t cross lines:**

If your lines cross, then you need to rearrange your diagram. This is simple. It’s better to have an arrow that takes a slightly wacky path than it is to have crossing lines. Crossing lines are hard to follow, and they create noise. When I use the term noise, I mean all of the extra junk information that does not lend directly to the information that you want to convey. Crossing lines are a distraction, and while some pieces of charting software have started to show a mini graphic that shows the line jumping over the other, it is still distracting and can create confusion where there shouldn’t be any.

![](https://cms.echobind.com/assets/7473b5b7-1f85-4659-b787-2e7164daf471)

In the top left image, we are crossing lines, and it adds a distraction to the flow without adding valuable information. In the bottom left we have an overlapping line. Now it is hard to tell if the top left line is multi-directional or if information is going in only one direction. The reader can’t know without asking the creator of the chart. In the right chart we have separated that line so it doesn’t cross anything, and I will often use a dotted line to convey to the reader that we have a looping scenario. Each added piece of information should be deliberate, and no noise should be added unless that noise is also adding valuable information for the person who is viewing the chart.

![](https://cms.echobind.com/assets/41ecbf28-e59f-486f-9309-fb2accd08e2d)

Even as we get into more complex charts we are able to follow all of these rules so that the diagram is easy to follow. None of these rules are hard and fast, but doing your best to follow them will make sharing and explaining flowcharts significantly easier for you and anyone else who may need to access it.

If you run into any other issues when creating flow charts, feel free to email me with questions and keep an eye out for my next series of rules where we will dive into the finer details that will make your flow charts stand out in spectacular fashion.

*Zack is a product strategist here at Echobind. Email him for tips, tricks and assistance at zack@echobind.com any time.*

---

[View on echobind.com](https://echobind.com/post/how-to-make-a-fantastic-and-informative-flowchart)

---

# Unlocking Success: The Benefits of Peer Feedback in Remote Tech Work

> Prioritize personal growth at your agency to ensure happiness and overall success for yourself and your company. Here are tips to do so.

_By Mariah Grey · 2024-05-24_

In the fast-paced environment of remote tech work, creating a culture of ongoing growth is among the most important for individual and company success. A great contributor to that improvement is peer feedback, giving benefits such as increased quality of work, creating an environment of collaboration, and ongoing development and learning. 

## **Improving the Quality of Work**

Feedback is a serious tool for improving the quality of work in remote tech environments. When teams come together and provide constructive criticism and share their insights, they grow together and can better identify and correct potential issues earlier in the development timeline. This leads to better quality deliverables and reduced errors.

Differing perspectives can provide increased problem-solving approaches, as team members with different skills and experiences might see alternative solutions than initially considered. This not only improves work quality but also garners a sense of shared ownership for the final product.

## **Cultivating a Culture of Collaboration**

Remote teams face the challenge of differing working styles and schedules. Peer feedback can address (and potentially alleviate some of) this by encouraging trust and open communication between colleagues. This empowers team members to share their thoughts and opinions without fear of judgment.

Collaborative culture goes far beyond just team projects. It can lead to improved communication, and foster a sense of camaraderie among distributed teams, which in turn can prevent feelings of isolation.

## **Encouraging Ongoing Learning and Development**

Being a remote worker requires ongoing learning to keep up with the ever-evolving tech and industry standards. Peer feedback allows team members to share their experiences and knowledge internally and allows others to collectively be on the cutting edge of the learning curve with the latest advancements and best practices. 

Receiving peer feedback gives people invaluable insight into where they have room for improvement as well as their strengths. This knowledge provides an opportunity for professional and personal development, giving team members options for skill enhancement and learning as needed. The entire team benefits by having an adaptable and skilled group.

## **Implementation**

Implementing effective peer feedback techniques in remote tech work requires a thoughtful approach. Here are key steps to ensure its success:

#### **Set Expectations**

Have a clear outline for giving and receiving feedback. Communicate the reason for the feedback, and emphasize its purpose for personal or professional development. Encourage using a positive, constructive tone to create continuous improvement. This looks like:

- Focus on the behavior, not the person: When giving feedback, be sure to focus on the specific behavior or action that needs improvement, rather than making personal attacks or criticism.
- Be specific and objective: Provide specific examples of what was said or done that needs improvement, and how it impacted the team or project. Use objective language and avoid making assumptions or judgments.
- Offer actionable solutions: Provide specific suggestions for how the person can improve and if possible, offer your support or other resources to help them implement the changes.
- Be timely: Provide feedback as soon as possible after an event, so it remains fresh in everyone's mind.

#### **Provide Training**

Offer training or a simple how-to document covering effective feedback approaches. This provides team members with the needed skills to appropriately give actionable feedback. It can also emphasize the importance of empathy and tact when giving feedback remotely.

#### **Use the Right Tools**

Using tools that facilitate collaboration and communication is a sure way to encourage feedback. Platforms such as video calls, messaging applications, and management tools open the doors to dialogue and feedback.

#### **Regular Cadence**

Set a schedule for feedback. Different settings call for different schedules, so it may be monthly, weekly, or more often. Regardless of the interval, having a cadence and sticking to it will ensure that peer feedback is ongoing and a consistent piece of the team's workflow.

---

Peer feedback in remote work is a powerful tool to improve work quality, foster collaboration, and promote ongoing development. By implementing clear expectations, training, using the right tools, and having a regular feedback cadence, remote tech teams can harness the full potential of peer feedback to achieve success 💫

*Mariah is a software engineer here at Echobind. Want to work with our incredible team? Reach out to us at [hi@echobind.com](mailto:hi@echobind.com) anytime.*

---

[View on echobind.com](https://echobind.com/post/unlocking-success-the-benefits-of-peer-feedback-in-remote-tech-work)

---

# Crafting Your App: 8 Discovery Steps for Decision-Making

> Prioritize research and discovery exercises before you spend a lot of money to build your app.

_By Eloisa Docton · 2024-05-22_

According to Google AI, the average app building cost is between $50,000 and $1.5M.

Naturally, this depends on the type of app it is, the features needed, and the additional services that are required for the app to work.

Money is definite, and we understand that. This is why planning for your app is important. The best way to plan for your app is by research and discovery exercises. With these exercises, we can discover opportunities, pitfalls, and—when necessary—pivoting to other solutions. 

## Why discovery and research?

Imagine inheriting a sizable sum from a long-lost wealthy relative. You have options: invest, pay debts, travel, educate your child, or, perhaps, finally develop that app you've long wanted. Take, for example, an app to help you focus on shopping goals at Target.

While you and I might find it useful, do all Target shoppers share this need? Some view Target as a therapeutic escape; an app might disrupt this. Imagine investing your inheritance in the app, only to find limited usage or widespread dissatisfaction. To prevent this, research is key. It reveals diverse user needs, allowing you to tailor the app for success.

## How to perform your own discovery

While experts can provide invaluable insights into your investment, there's no substitute for conducting your own discovery. At Echobind, [we offer numerous options to guide you](https://echobind.com/services), but starting with your own research is key. It provides clarity on your vision and accelerates your understanding of the problem you aim to solve.

![](https://cms.echobind.com/assets/630772de-eda6-4b98-8eb6-da50844d2659)

## DYI Discovery Step 1: Make a list

**The Who:** Start by considering the obvious users—like you and me—but also think about whether everyone in your extended network, including family and friends, would use it. What about other shoppers you see at Target? Are there certain types of people who might not use it, like those who dislike using phones or despise shopping altogether? Ensure your plan accounts for these potential users; their data will be invaluable later.

**The Why:** You likely have a good grasp of why you would use the app, but considering other potential users can uncover additional reasons for its utility. For instance, while you and I seek focus at Target, others may struggle elsewhere, like at Best Buy. Understanding these diverse needs can inform feature enhancements or potential pivots, revealing new opportunities. If half your users need it at Target and the other half prefer it for grocery or electronics shopping, you've struck gold.

**The How:** Consider how users would interact with the app. While smartphones are the primary platform, think about compatibility with tablets or desktops. Not all devices have constant data connectivity, and not all apps work seamlessly on every phone or in areas with poor reception. Understanding these technical requirements is crucial, especially if users need the app in-store where signal strength may vary. Ensuring optimal functionality regardless of device or location is key to user satisfaction.

![](https://cms.echobind.com/assets/2eeba492-73b5-4b86-be65-4e402180f37a)

## DYI Discovery Step 2: Make sense of the list

Now that you've gathered this data, it's time to define your problem and determine your solution.

**1. Who would use it?** People who shop, not just at Target. Focusing solely on Target shoppers could overlook opportunities with those facing similar challenges elsewhere (as shown by our 50% example).

**2. Why would people use it?** Because many tend to overspend at their favorite stores, and your app could offer budgeting assistance.

**3. How would people use it?** Given that shoppers are often on the go, a mobile app would likely be the most practical solution.

![](https://cms.echobind.com/assets/8fed2c24-5fda-45a2-8109-f5f1a83e94c5)

## DYI Discovery Step 3: Digging deeper

You've pinpointed who, why, and how the app will be used. Now, to ensure it caters effectively to all shoppers, aids in budget adherence, and is mobile-centric, we need more insight into these three aspects:

- **Demographics**: Understanding the user demographics will inform visual design and language choices within the app.

- **Socioeconomic status**: Grasping the financial circumstances of users will elucidate the true problem being addressed.

- **Operating systems**: Identifying the predominant operating systems *(iOS or Android)* among users will guide technological decisions. Is the user base primarily iPhone or Android users? Would focusing on one OS alienate too many potential users? This knowledge is crucial in determining the appropriate technology to employ.

![](https://cms.echobind.com/assets/e94fb9c6-135e-4ac3-8954-7be405cd4d54)

## DYI Discovery Step 4: Tracing steps

What are the steps users will take to use the app?
1. Get to the store
2. Fire up the app
3. See shopping list

Wait ... how will this shopping list get there? Let’s try this again:
1. Create a shopping list
2. Get to the store
3. Fire up the app
4. See the shopping list
5. See the items in the list highlighted in the map

Wait ... how will the app know what store you’re in? How will it know the store carries all of the products? Let’s try this one more time:
1. Create a shopping list
2. Connected to a store
3. Output any items not sold there, let you know
4. Get to the store
5. Make sure your phone knows your location
6. Fire up the app
7. See the shopping list
8. See the items in the list highlighted in the map

Easily, going through this exercise a couple more times will provide even more discovery. We quickly went from 3 steps to 8, in the same exercise. 

![](https://cms.echobind.com/assets/37593d43-e183-4fcf-9c68-83352e47110c)

## DYI Discovery Step 5: The Problem

Now, with the insights we've gathered, the problem becomes clear:

**The Problem**: People consistently overspend at their preferred stores, leading to detrimental effects on their budget.

![](https://cms.echobind.com/assets/6b752209-1ead-44ec-a87a-16295c35b9dd)

## DYI Discovery Step 6: The Answer

An app that allows for you to enter your shopping list, match it with the items at the specific store, and maps the store out for you to stay on target ... not just at Target! 

![](https://cms.echobind.com/assets/69e70b58-3bfb-49fd-8262-f2708b746091)

## DYI Discovery Step 7: Wait, does this already exists?

Even if you haven't encountered a similar app, conducting a quick competitive analysis is crucial to ensure there aren't existing solutions addressing the same problem.

In today's landscape, it's likely you'll find numerous similar apps. Therefore, it's essential to thoroughly assess each one, listing their features, comparing their strengths and weaknesses, evaluating their performance, reading reviews, and even testing them firsthand.

This comprehensive analysis provides a deeper understanding of your competition, potentially inspiring additional features or services you may wish to offer, either immediately or in the future.

![](https://cms.echobind.com/assets/b465ac63-5d04-4db7-9356-c343362ff700)

## DYI Discovery Step 8: Most Lovable Product

So far, we've identified who, how, and why people would use the app, and we've expanded its scope to include any store, not just Target. After examining competitors and validating ideas through research, it's time to assess our needs and budget. Here's what we believe is necessary:

- A mobile app compatible with both Android and iOS
- Shopping list storage capability
- Access to store inventory
- Store map integration
- Directions to item locations within the store

Considering these requirements, let's explore the technologies:

- Building with React ensures compatibility with both operating systems.
- Data storage is necessary for maintaining shopping lists.
- Accessing store inventory would involve collaboration with stores and may introduce security complexities.
- Store map integration may require reverse engineering existing solutions or exploring alternatives.
- Locating products within the store could utilize similar methods as store map integration.

Upon reflection, the need to connect to store inventory stands out. Do we truly require this? Could we find an alternative? Removing this requirement may impact the user experience, but let's reconsider:

- Users can still visit the store and find available items without additional connections.
- The only potential drawback is the need to visit another store to complete their shopping.

With this reassessment, we can refine our app's requirements and better align them with our budget and goals.

![](https://cms.echobind.com/assets/f98e91eb-2e73-4145-b574-f91e4ef73149)

## So, what’s the product?

We've made significant progress! Here's a summary of the essentials we've identified to ensure the app's usability:

- A mobile app developed using React (a development code that allows for the same app to work on either phone without the need to build 2 apps)
- Data storage functionality for saving shopping lists
- Location services integration to determine the user's current store
- Connection to the store's internal mapping system for item location

Even without additional connections, users can still visit the store and locate available items. The only potential inconvenience is the possibility of needing to visit another store to complete their shopping. 

![](https://cms.echobind.com/assets/cec7bf82-da5a-4053-84c6-2b18d20b1e66)

## Next Steps: Validation + Further Analysis

Now that we've established a solid foundation for the idea, it's time to review whether additional research is necessary and transition into validation.

Further research may involve examining existing store apps, such as Target's, to determine if they already offer features like saving shopping lists and displaying store maps. If they do, it might prompt us to consider another pivot.

This leads us to validation. If everything seems aligned with the app idea, a second round of research could involve building a prototype and testing it with various potential users. By recording their impressions, we can gather valuable feedback to refine and improve the app.

## In the end, we are constantly researching 

Staying ahead of the curve is key. Even as the app is developed and utilized, it's crucial to maintain focus on the factors considered from the outset. Success hinges on continuous attention to users, competitors, and emerging trends.

Alternatively, partnering with a company like Echobind can handle this for you, ensuring your app remains competitive and aligned with evolving market dynamics.

*Eloisa is a senior designer at Echobind. Work with her and the rest of the team by simply emailing us at hi@echobind.com anytime.*

---

[View on echobind.com](https://echobind.com/post/crafting-your-app-8-discovery-steps-for-decision-making)

---

# Rails on Railway 

> A senior software engineer talks cost cutting and evaluating necessary recurring payments as a developer.

_By Matt Thompson · 2024-05-13_

It’s no secret the year 2024 is one of re-evaluation and cost-cutting. As a Software Engineer, hosting the app is one of the unspoken costs that can chip away at us. For Rails specifically, I’ve seen these costs continue to grow. Today, we will explore ONE of the many options out there: [Railway](https://railway.app). I hope to continue this series with a few more options including Fly, Digital Ocean, and AWS.

## Past Resources

As a Rails developer, [Heroku](https://www.heroku.com/) used to be the industry standard, and for many folks, it still is. However, in my opinion, Heroku got the Salesforce sentence of death. We eventually started to use [Render.com](http://Render.com). For the longest time, I was happy with Render... that is until we started hitting some crazy production costs. For a hobbyist app - Render is still great, but let's compare some of the costs for a “real” app. https://render.com/pricing 

Most production Rails applications historically have had a server, a database, and until recently, a worker of some kind with Sidekiq w/ Redis.  Humble plug — Feel free to read more **[here on *“why you may not need Redis”*](https://echobind.com/post/you-may-not-need-redis-and-sidekiq)** in 2024. We can simply avoid that open-source drama altogether with something like [solid_queue](https://github.com/rails/solid_queue). 

With Render — anything past the “hobby” tier quickly grows to need something like Pro. 
That means we now have: 

- $20 per team member for access
- $25/mo for a STANDARD Service (let's pretend the app is ok here..)
- $85/mo for the worker
- $95/mo for Postgres
- $135/mo for Redis

Let's see here… carry the one and… Just No.

I couldn’t justify this—anyone who remembers the $5 droplet days would be shocked to see today’s market. Let's be honest: for some folks, there may be some justification for these costs, but try explaining this breakdown to a startup stakeholder.

![](https://cms.echobind.com/assets/1422a267-1503-4f01-803f-034baf658581)

## Railway Overview (TL;DR)

One of the selling points of Railway is **usage-based** cost. I’ve already subtly mentioned one cost-cutting solution of **[removing Redis/Sidekiq](https://echobind.com/post/you-may-not-need-redis-and-sidekiq)**. Usage-based can be a double-edged sword here depending on your needs. There’s never a silver bullet solution. There will always be tradeoffs. 

However, consider our growing startups, internal apps, and personal hobby apps. With an internal example app below, I was able to take those drastic Render costs and cut costs to the estimated breakdown below. 

So far, for a small worker, Rails server, and Postgres, I’m sitting at ~$12 a month. I’ll take it. With some hosting services, I can’t even stand up Postgres for under $15. This gets a little closer to the OG $5 droplet days.

If you are still in the exploration stages this is great. 
At some point, usage-based may not be the most cost-effective — but I’d imagine you are still better off here than with a tired price structure like Render. My current recommendation is that once usage-based becomes too much, you’re likely stable enough to start “enterprising” everything down in AWS/Azure. (more on that in a future post)

![](https://cms.echobind.com/assets/6862bf5d-e5f7-44ef-b9f8-f6618a2d3c0c)

## Running on Railway

Railway has two options to deploy a rails app. 
Both include the standard recommended approach of linking your GitHub account/repo to a particular branch (defaulted to `main`). I’m not going to cover that piece here as it has become pretty standard practice for a lot of services today, and they do a pretty good job of walking you through it. 

Start by creating a new project and follow the GitHub prompts. Before the first deployment, you’ll have a chance to enter any Environment Variables. Take a second to add anything you’d need — leaving out the DATABASE_URL for now. This would include RAKE_ENV, RAILS_ENV, NODE_ENV, PORT, RAILS_MASTER_KEY, SECRET_KEY_BASE, etc. (depending on your setup) 

**With Docker** 
With Rails 7 you have a Dockerfile out of the box. 
If you make zero changes and link a `rails new` app to Railway, it will auto-detect the Dockerfile and build using Docker. This honestly just worked out of the box and was a great experience. However, things start to get a little tricky if you want to introduce that worker thread. Maybe it’s an old hat habit, but I tend to lean into the second option here. 

**With a Procfile**
Good ‘ol Procfile. 
If you’ve deployed to Heroku and others in the past, this was the norm. Railway is also set to use a Procfile by default, so if you are migrating from Heroku or another, this should be straightforward. Railway even has some notes to cover that process in full [here](https://railway.app/heroku). 

For me and this sample app, I have the normal web app and solid_queue running in a side worker. 

```jsx
web: rake db:migrate && bin/rails server -b 0.0.0.0 -p ${PORT:-3000}
worker: bundle exec rake solid_queue:start
```

For this to automatically work with Railway, I renamed the Dockerfile to something bogus and pushed it back up with my Procfile. Railway then uses its nix-packs and leverages the Procfile to kick everything off. You should see both the web and worker logs when viewing the “deploy logs.” 

**Adding the Database** 

At this point, your app may still be failing in the build due to not having a Database. Lets go ahead and take care of that. The first thing I update in the code is to mark my Production config to use `DATABASE_URL` we don’t really have control over the database name here and honestly, I’d rather manage one ENV > all the pieces. 

```ruby
# database.yml 
production:
  <<: *default
  url: <%= ENV["MY_APP_DATABASE_URL"] %>
 
```

Don’t push just yet! 

Back in Railway, let's add our PG Database. 
Render has a handy CMD+K / Ctrl+K command for adding a new service (or finding the button in the dash). A menu should pop up, allowing you to search for “Postgres.”

![](https://cms.echobind.com/assets/977c8acf-d230-401d-b280-f0dc01b91d27)

Add the Postgres service and you should see both services running. 

![](https://cms.echobind.com/assets/7bfd4a8d-6aac-4348-a1b6-5924406e4d60)

Click on your repo application and click Variables. Railway has a quick helper to add the linked Postgres DATABASE_URL. This is super handy for ANY service you continue to add. 

![](https://cms.echobind.com/assets/39968437-9ab2-4e3d-92f7-6d4cfd66cd0b)

![](https://cms.echobind.com/assets/b831a267-b228-4e15-a206-ec9deb92b27f)

### Re-Click Deploy!

At this point, your new app should have all it needs to get rolling. From here monitor the build/deploy logs for anything specific to your application. 

## Conclusion

As I mentioned, there’s never a silver bullet solution for Software or deployment needs. That said, Railway does seem to offer some pretty solid Usage-based pricing that can take you pretty far. I’d highly consider having this as an option in your tool belt before buying into giant infrastructure (and the overhead that comes with it). 

Until next time! 🙂

*Matt is a senior software engineer at Echobind. Want to work with us on your next project? We'd love to help. Reach out to us at hi@echobind.com anytime.*

---

[View on echobind.com](https://echobind.com/post/rails-on-railway)

---

# You may not need Redis and Sidekiq

> A senior software engineer talks about not needing Redis or Sidekiq anymore.

_By Matt Thompson · 2024-05-13_

[In another post](https://echobind.com/post/rails-on-railway) I mentioned 2024 being the year of re-evaluation and cost cutting. 

It wasn’t long after starting some of these deployment evaluations that Redis caused a stir with its announcement of license changes. It’s always something, right? Most of my Redis interactions have been in Rails land, keeping globs of data in memory for quick access or the 1, 2 combo with Sidekiq. Add in the fact that a production Redis is stupidly expensive with services like Render. ($135/mo+ for the pro production version—ouch!) 

Accessing my own memory, I recalled some mention from last year's [Rails World](https://youtu.be/iqXjGiQ_D-A?si=9qt8EAWD0jNAU6Uz&t=2796) about leaning into the Hardware we already have. Memory access tools like Redis were invented/used when doing direct reads from an externally hosted database from a hard drive was slow (or slower). Today, we have Solid-State Drives, beefy cloud machines, shared data/edge resources, etc. To be clear, technology *has* actually advanced a bit; we have options. 

The Rails core community has been taking these thoughts and concepts to heart pushing and maintaining packages like [Solid Queue](https://github.com/rails/solid_queue) and [Solid Cache](https://github.com/rails/solid_cache).  We are already approaching Rails World 2024, where tickets sold out in 20 minutes. While I’m not able to attend, I’m excited to see where the conversations take us.  

**Solid Cache** 

https://github.com/rails/solid_cache

> Solid Cache is a database-backed Active Support cache store implementation.
> 
> 
> Using SQL databases backed by SSDs we can have caches that are much larger and cheaper than traditional memory only Redis or Memcached backed caches.
> 

Solid Cache is exactly what it sounds like. Why pay for an expensive in-memory Redis DB when your application is sitting inside an SSD, where reads and writes are crazy fast? Leveraging something like Postgres (which has also grown and scaled over the years) with SSD makes this a no-brainer for most use cases. 

**Solid Queue** 

https://github.com/rails/solid_queue

> Solid Queue is a DB-based queuing backend for [Active Job](https://edgeguides.rubyonrails.org/active_job_basics.html), designed with simplicity and performance in mind.
> 

Sorry, Sidekiq—you may no longer be needed either. In the same manner, we can leverage Postgres / SSDs to simply manage our jobs and processes. Even better, because this is DB-driven, we have direct insight into what is in the queue, what has failed, properties sent, etc. 

With a solid queue, you can even run this on the same thread as your application's thread via the Puma plugin. For example, I have an application with a small process that needs to run once per hour. This process doesn’t need a lot of resources; it’s not going to block the app and it completes in a few seconds. There’s no need for the added overhead of an additional worker thread — just tell the app to run the dang process. 

Again, even with a worker, comparing this to the overhead and costs of a full Sidekiq / Redis process is still a no-brainer for me. In a worst-case scenario, you beef up the box the Application/Postgres is hosted in. That is still a huge cost-saving difference from adding full in-memory services like Redis at scale.  

While there are alternatives to solid_queue like [good_job](https://github.com/bensheldon/good_job), both solid_cache and solid_queue are becoming an increased part of the Rails core packages, maintained under the Rails org. In my opinion, there’s no real need to look elsewhere, as these are built to directly interact out of the box with Active Job. 

## Summary

I don’t like to lay down blanket statements, especially in the Software industry. However, the use cases I once had for Sidekiq and Redis are closing. 

Simply put, do your homework. 
Don’t pay for services you don’t need. 

Until next time! 🙂

*Matt is a senior software engineer at Echobind. Want to work with us on your next project? We'd love to help. Reach out to us at hi@echobind.com anytime.*

---

[View on echobind.com](https://echobind.com/post/you-may-not-need-redis-and-sidekiq)

---

# Leveraging Stripe To Manage Your SaaS Entitlements

> This is how to use Stripe to manage your SaaS Entitlements.

_By Kishan Gajera · 2024-05-08_

If you have a software-as-a-service product, you likely have multiple subscription plans with different feature sets for your customers to choose from. For example, our [Labs](https://echobind.com/post/2024-the-year-of-products-at-echobind) project, [Kind Kiosk](https://kindkiosk.com/), has the following subscription plans:

![](https://cms.echobind.com/assets/393b736e-398e-4f70-8e71-1e78a6811d96)

Until recently, your back-end implementation was responsible for managing entitlements for a customer’s subscribed plan. It can get complex to keep your back-end in sync with the customer’s subscription throughout its lifecycle as recurring payments may fail or the plan is upgraded, downgraded, or canceled. 

Amongst many of the larger features announced at [Sessions](https://stripesessions.com/), Stripe quietly released a new [Entitlements API](https://docs.stripe.com/billing/entitlements). This API lets you create features which can then be assigned to products. As of writing this post, features can only be created using Stripe’s API and not through the Stripe Dashboard.

Continuing to use the example plans above, you’ll have the corresponding products in Stripe:

![](https://cms.echobind.com/assets/b70de9f7-4ea7-48fa-9e11-9b645959c0b7)

For customers subscribed to our “Growth” plan, they are allowed to create an unlimited amount of designations or causes. So let’s create a feature for this and assign it to our “Growth” product:

```tsx

const feature = await stripe.entitlements.features.create({
  name: 'Unlimited Causes/Designations',
  lookup_key: 'unlimited_designations',
});

// Assign the newly created feature to a product
const growthProductFeature = await stripe.products.createFeature(
  'prod_growth',
  {
    entitlement_feature: feature.id,
  }
);
```
You would repeat the above for all the features needed for your subscription plans. Now that all your features have been added to products, how can we use these to know which features a customer has access to? Stripe maintains a list of active entitlements for a customer when they subscribe to a plan and also keeps them up to date throughout the different events that may occur in the subscription lifecycle. Your app can be notified of changes to a customer’s entitlements by using [Stripe Webhooks](https://docs.stripe.com/webhooks).

Whenever the customer’s active entitlements change (for example, when they subscribe, change, or cancel a plan), the `entitlements.active_entitlement_summary.updated` webhook event will be sent. Here’s an example of the data your webhook endpoint will receive:

```json
{
  "object": {
    "object": "entitlements.active_entitlement_summary",
    "customer": "cus_MgWgA7lAKUOkm1",
    "entitlements": {
      "object": "list",
      "data": [
        {
          "id": "ent_test_61QL65z2ila6DkHsA41DvCN66DEZt1Z2",
          "object": "entitlements.active_entitlement",
          "feature": "feat_test_61QL64Bts1fTy44Im41DvCN66DEZtA3s",
          "livemode": false,
          "lookup_key": "unlimited_designations"
        }
      ],
      "has_more": false,
      "url": "/v1/customer/cus_MgWgA7lAKUOkm1/entitlements"
    },
    "livemode": false
  },
  "previous_attributes": {
    "entitlements": {
      "data": []
    }
  }
}
```

You’ll likely need to retrieve a customer’s entitlements frequently, so Stripe recommends persisting the active entitlements in your database for performance reasons rather than fetching them on demand using the [list API](https://docs.stripe.com/api/entitlements/active-entitlement/list). These can be persisted when processing the webhook event. If you’re using [Postgres](https://www.postgresql.org/), it could be as simple as having a `user_id` column and an `entitlements` column which is an array of the `lookup_key` value from Stripe’s active entitlement object:

![](https://cms.echobind.com/assets/51fd567b-5521-4e57-9760-1acf3cca448f)

Now throughout your codebase, you can quickly retrieve your user’s entitlements and implement access control to features of your product. By placing the burden on Stripe to maintain entitlements, that should simplify your implementation and keep you focused on implementing your actual product.

*Kishan is a senior software engineer at Echobind; want to work with him on a project? Write us an email at hi@echobind.com and we'll be in touch this week.*

---

[View on echobind.com](https://echobind.com/post/leveraging-stripe-to-manage-your-saa-s-entitlements)

---

# Become Safe to Disagree With

> This blog is for professionals who don’t feel safe disagreeing with others, to make sure your voice is heard in a safe way at your office, remote or in-person.

_By Zack Marty · 2024-05-06_

A treasured colleague recently told me, “I feel safe disagreeing with you.” I was touched insofar as someone told me that they felt safe with me, but what did it actually mean, how could I go about making sure that everyone felt that way with me, and how can I help foster an environment where more people feel safe disagreeing with their colleagues?

For those of us who don’t feel safe disagreeing with others, this blog is about helping you find a way to make sure your voice is heard in a safe way. For those who have no problem disagreeing with others, this blog is about how you can foster an environment that cherishes and recognizes healthy conflict.

### What is healthy conflict?

In short, healthy conflict is just a [constructive disagreement](https://www.linkedin.com/pulse/healthy-vs-unhealthy-conflict-workplace-thiru-damodharan-mba/). It’s when people are able to disagree with each other, and each party listens intently to understand and value the alternate positions that people present. Such conflict in the workplace breeds creativity, personal development, and stronger bonds with your workmates. It’s not always easy to pull off, and it is something that you need to foster within yourself as well as others. Healthy conflict requires a [strong ego](https://midsonshort.medium.com/the-difference-between-a-big-ego-and-a-strong-ego-3f103746dc44) from everyone involved.

Having a strong ego means that you can like and appreciate your own intellect while also understanding that others will have better ideas, and you need to internalize that disagreements are not a personal attack on your intellect. Sometimes your perspective comes from being in the weeds and theirs is from a more visionary standpoint. Sometimes their opinion comes from outside of the industry as a way to shake things up and yours comes from industry expertise. Either way, you likely both have good reasons to hold the opinions you have, and recognizing that will lead to healthier and more productive disagreements.  This took a lot of practice, and quite a few hours of self-reflection after I failed to disagree in a healthy and safe way on more than one occasion.

### How can I foster an environment of healthy conflict?

It's unrealistic to expect perfect agreement with colleagues every time. We all have off days where our responses may be less professional and our communication less effective than intended. When such situations arise, it's important to humble ourselves and offer apologies when warranted. Personally, I've found myself needing to apologize to my colleague Claire on more than one occasion.

While no one explicitly required me to do so, failing to apologize would likely strain our relationship, which is detrimental both personally and to the company as a whole. However, constantly finding oneself in a cycle of apologies isn't conducive to a healthy work environment. Therefore, as leaders and colleagues, it's vital to cultivate trust by honoring the [commitments we make to one another](https://hbr.org/2018/01/why-we-should-be-disagreeing-more-at-work).

These commitments are rarely spoken and are more often implied through our actions and general behavior. You can tell everyone who will listen that you can be trusted and that you value people’s input, but that doesn’t matter one iota if you routinely demonstrate that you are hostile toward critical input, never address your own shortcomings, and routinely break people’s trust. This all comes down to the simple idea that you need to treat people the way that you want to be treated. 

![](https://cms.echobind.com/assets/e15a3f2d-f932-41b9-8950-11e97b15cc72)

### So how do I actually start? Like this:

- Listen to criticism actively and respond thoughtfully instead of waiting to speak. Engage with the feedback rather than just collecting it to defend your own opinion.
- If you disagree with someone, jot down their points and reflect on them later. Emotions can cloud judgment, so taking time to process can reveal valid insights or the value in their perspective.
- If you've already considered and rejected an idea, explain why it doesn't work rather than dismissing it outright. This fosters constructive dialogue and understanding.
- Seek further clarification when needed. Asking for more detail demonstrates active listening and respect for others' perspectives. Make sure to do this often, especially when you understand 98% of what they said. That last 2% can make all the difference.

This is as lovely advice when you’re a leader/boss at your place of work or play, but how do we go about fostering a workplace of healthy conflict when we’re not the boss? And how do you make yourself heard?

### Being Heard

The difficult truth is that you need to lead if you have not been given a platform to be heard. If this can’t be done where you are, then you might be in the wrong place, but let’s assume you’re somewhere with people willing to hear you. You can lead without being the boss, and fostering healthy conflict when you aren’t the boss is all about leading by example. There are numerous ways to do this [without wielding power](https://hbr.org/2013/05/how-to-lead-when-youre-not-in).

This can be done by connecting people to each other at your workplace, being a curious contrarian, or asking a lot of questions. The way I have been most effective at this is by peeling back the layers of decisions to understand the roots. When you are able to peel back layers, one method being the [five why’s](https://www.mindtools.com/a3mi00v/5-whys), people will notice your curiosity and investigative nature. Though we are all supposed to care about our work, passion can shine through. 

### Getting Started

In a meeting, attempting to pick apart the intricacies of a decision, especially if it's your first time doing so, can often prove more disruptive than beneficial. Try to initiate this process with a single individual, preferably someone with greater decision-making authority or influence than yourself, whether through their official position or their sway among peers. Despite everyone's crazy schedules, most people are willing to set aside time for a one-on-one discussion with a colleague.

Once you've got their time, begin unpacking the decision, asking probing questions, and getting into the specifics. Over time, as you engage in these discussions, they will naturally begin seeking your input. This gradual approach alleviates the pressure of suddenly voicing opinions in a meeting, which can be daunting for those inexperienced in such situations. Your consistent presence and contributions will become expected and valued by those you've engaged with individually, leading them to actively involve you rather than requiring you to assert yourself.

### Conclusion

None of us are perfect, and not everyone wants to jump into the limelight. However, we all want to be heard, and we all want to hear from others. You can become easy to disagree with, and you can make it easier to disagree with others in a healthy way by starting with individuals and expanding from there. You will have to put yourself out there, and you need a strong sense of self to do it, but it gets a whole lot easier the more you do it. 

*Zack is a product strategist here at Echobind and would love to help you plan out the roadmap of your next big project. Let’s do this together; email us at [hi@echobind.com](mailto:hi@echobind.com) anytime.*

---

[View on echobind.com](https://echobind.com/post/become-safe-to-disagree-with)

---

# Our Takeaways from Stripe Sessions 2024 in San Francisco

> Stripe Sessions 2024 was an unbelievable event in San Francisco for Echobind. Here are our immediate takeaways from attending.

_By Kishan Gajera · 2024-05-01_

Our team is back from [Stripe Sessions](https://stripesessions.com/) and we are excited to share all the new updates. The Stripe team covered a lot of ground and we can’t wait to help our clients take advantage of all the new features that were released.

## New Features Announced

There were too many features announced at Sessions to cover in this post but we’ve highlighted a few features below that will have immediate positive impacts for our clients as well as our [Labs](https://echobind.com/post/2024-the-year-of-products-at-echobind) projects.

In general, a pattern we noticed throughout a majority of the features announced were:

- they can be directly configured through the Stripe Dashboard or using low-code solutions
- they allow imposing your business logic onto the Stripe platform

Both of these points result in you writing and maintaining less code and getting your product out there faster.

### Stripe Connect Embeddable Components

Stripe now has [17 embeddable components](https://docs.stripe.com/connect/get-started-connect-embedded-components) that can be used with [Stripe Connect](https://stripe.com/connect). This has greatly reduced the complexity and development time needed to build Connect implementations. With this low-code solution, it allows you to embed different pieces of Stripe functionality directly into your app:

![](https://cms.echobind.com/assets/23ecdf48-3cce-4faf-a07e-7eb755a51adf)

In our past implementations, we have found the [Stripe Hosted Onboarding](https://docs.stripe.com/connect/custom/hosted-onboarding) flow to provide the most friction and confusing experience for end-users so the component we’ll focus on migrating to in many of our projects is the [Account Onboarding component](https://docs.stripe.com/connect/supported-embedded-components/account-onboarding). 

We’ve already started improving the onboarding experience for our Labs product, [Kind Kiosk](https://kindkiosk.com/). In the screenshot below, you can see the differences in UI between the two approaches. On the left, we have the hosted onboarding flow, where a user has to click a button to be redirected away from our app to a Stripe hosted page. On the right, we have embedded the account onboarding component customized to use our Kind Kiosk brand colors which provides a much more seamless flow to our users.

![](https://cms.echobind.com/assets/02365fe7-b7b3-44bd-a644-a7d962bdeb89)

### Stripe Sigma AI Assistant

Many of our clients have been leveraging [Stripe Sigma](https://stripe.com/sigma) to create reports to pull various data they need out of Stripe. In order to use Sigma, you need to know how to write a SQL query, which likely means a developer would need to get involved.

It’s now possible to use natural language to generate the SQL query which breaks down the barrier for accountants and other roles to use Sigma. We are looking forward to introducing this to our clients:

![](https://cms.echobind.com/assets/186a57dd-c465-4cc0-92b5-4ed46b2095f0)

### Payment Methods

Stripe has continuously been making improvements to increase conversions for their [Checkout](https://stripe.com/payments/checkout) suite and they’ve released a number of enhancements around payment method presentment. Stripe has also added more payment methods options such as [Amazon Pay](https://pay.amazon.com/) and 50+ others that can be easily enabled through the Stripe dashboard.

With the number of payment method options increasing, it can be difficult to know which ones are appropriate to present to your customer. We learned that Stripe now takes on the burden of this with [Dynamic Payment Methods](https://docs.stripe.com/payments/payment-methods/dynamic-payment-methods) which uses their AI models trained on millions of businesses to help present the right payment methods to user based on their location, currency, device type, browser, transaction amount, and other factors.

In addition to this, Stripe announced additional options for managing presentment by configuring [payment rules](https://docs.stripe.com/payments/payment-method-rules) or setting up [experiments for A/B testing](https://docs.stripe.com/payments/a-b-testing) through the Stripe dashboard:

![](https://cms.echobind.com/assets/3ce987e1-536c-4dff-9085-c9b7f8937e70)

## Echobind’s Stripe Partnership

We’ve been [partners](https://stripe.partners/) with Stripe since the start of their partnership program and we are proud to announce that we've been [officially recognized as a Stripe Services Implementation Specialized Partner](https://stripe.partners/directory/echobind) in 2024, the highest achievement in the Stripe Partner Ecosystem.

![](https://cms.echobind.com/assets/fe464594-fd57-4726-bd38-09bacc991969)

The Stripe Services Implementation Specialization is awarded to partners who have demonstrated excellence in leading successful implementations, driving user activations, and passing Stripe's capabilities assessment, showcased by their proficiency in delivering high-quality services to customers.

We've worked hard [to learn the intricacies of Stripe's software](https://echobind.com/partners/stripe) and align it with our client's needs to create the most seamless, effective marketplaces imaginable. This indicates that you're partnering with a proven services provider, skilled in Stripe implementation and dedicated to your success. In short? We want to give you the most professional (and effective) experience possible.

We're excited about the opportunity to partner with you to showcase our Stripe skillset and how quickly we can push your company forward.

*Kishan is a senior software engineer here at Echobind. Want his expertise on your next big project? Shoot us a note at hi@echobind.com and we'll chat all about it.*

---

[View on echobind.com](https://echobind.com/post/takeaways-from-stripe-sessions-2024)

---

# Project Management Tools and Adapting to Client Workflows

> How to customize your project management strategies to sync with your clients' workflows effectively.

_By Claire Surma · 2024-04-30_

## Introduction

At Echobind, we believe that understanding and adapting to the unique needs of each client is not just an approach but a necessity. This blog post delves into how we customize our project management strategies to sync with our clients' workflows, tools, and overall business ethos, ensuring our exceptional projects are matched with high-level processes.  

## **Customizing Project Management to Client Needs**

From startups to established enterprises, the diversity in workflow and technology stack is vast and varied. To navigate this diversity, Echobind does not just apply a standardized template of management practices; instead, we tailor our strategies. This adaptability is not merely about staying flexible; it’s about embedding our processes into the client's operation. 

For instance, when working with tech startups, we often encounter a dynamic and fast-paced environment where decisions and directions can pivot rapidly. For these clients, our project management approach focuses on agility and transparency, employing tools and methodologies that support quick changes and easy updates. Conversely, when we engage with more established companies, the emphasis might shift towards integrating with legacy systems and adhering to stricter protocols, which requires a different set of tools and a more measured pace.

![](https://cms.echobind.com/assets/1b19b593-27a9-43ad-af7e-5f51ffd95db0)

## Tools Echobind Team Members Love

A critical aspect of our adaptable project management strategy is the tools we employ. At Echobind, we select tools not just based on our preference but based on what will work best for the client’s environment and project needs. Here’s a look at some of the tools our team members prefer and how they cater to different project requirements:

### Project Management Tracking:

- **[Linear](https://linear.app/)**: Is the newest project management tool designed by and for software development teams. It excels in managing tasks, tracking bugs, and organizing sprints in a clean, intuitive interface that minimizes clutter and maximizes productivity. Linear makes it really easy for our internal and client teams to track milestone progress and is ideal for technical client’s that value speed in their project management processes.
- **[Shortcut](https://www.shortcut.com/)**: Formerly known as Clubhouse, Shortcut is a great tool for both technical and non-technical team members. Shortcut enables teams to track progress, prioritize tasks, and comprehensive burndown reporting, making it a preferred choice for both waterfall and agile teams aiming for rapid development cycles. Shortcut is a great tool for client’s to easily review task progress, comment on features, and approve epics.
- **[ClickUp](https://www.clickup.com/)**: ClickUp is versatile and can be tailored for various teams, making it suitable for both developers and creatives. It combines features of project management, document storage, and task tracking, all in one platform, making it a robust tool for managing complex projects.

### Client Communication:

- **[Loom](https://www.loom.com)**: Loom has revolutionized how we communicate changes and updates to clients. By allowing us to create quick videos explaining complex issues or showcasing new features, Loom helps reduce miscommunication and speeds up approval processes.
- **[Slack](https://slack.com/) or [Discord](https://discord.com/)**: Instant messaging platforms like Slack and Discord are vital in maintaining day-to-day communication. They foster a sense of community and immediacy, which is crucial for agile projects and continuous integration environments.
- **[Google Hangouts](https://hangouts.google.com) or [Zoom](https://zoom.us/)**: For more formal meetings, presentations, or when dealing with clients who prefer face-to-face interaction, these tools ensure that we maintain effective communication irrespective of geographical distances.

### User Flow Mapping and UI/UX Design Approvals:

- **[Whimsical](https://whimsical.com/)**: Whimsical is a versatile tool that excels in creating clear and engaging user flow diagrams, wireframes, and mind maps with a user-friendly interface that supports real-time collaboration. This tool streamlines the design approval process by facilitating easy communication and rapid feedback from all stakeholders.
- **[Miro](https://miro.com/):** A visual collaboration platform that is highly beneficial for product managers involved in strategy development and project planning. It provides an expansive digital whiteboard where teams can create user flow diagrams, brainstorm ideas, map out product roadmaps, and more. Miro's strengths lie in its ability to facilitate strategic sessions and gather inputs from various stakeholders, making it an essential tool for high-level planning and decision-making in product development.
- **[Figma](https://www.figma.com/):** Figma is a comprehensive design tool that enables simultaneous UI/UX design, prototyping, and feedback gathering. Its collaborative features allow team members and stakeholders to interact directly on the platform, enhancing workflow efficiency. Figma is ideal for managing design approvals due to its integrated commenting and version control capabilities.

![](https://cms.echobind.com/assets/f4f8e6e9-a12e-4a56-a04a-b47593b2eeb1)

## **Challenges and Solutions in Custom Project Management**

Customizing project management to fit each client’s unique needs comes with its set of challenges. One major challenge is the alignment of tools and processes between the teams. Often, integrating new tools into an existing framework can be disruptive and may meet resistance. To counter this, Echobind focuses on extensive onboarding sessions and regular training workshops to ensure that everyone is on the same page.

Another challenge is maintaining the balance between flexibility and control. While adapting to client needs, it is crucial to ensure that the project does not deviate from its core objectives and timelines. We achieve this balance by setting clear, adaptable goals and maintaining continuous communication with all stakeholders.

## **Conclusion**

At Echobind, our approach to project management is not one-size-fits-all. We understand the unique challenges and needs of each project and client, adapting our tools and techniques to offer customized solutions.

Our strategic thought process in organizing and tracking project progress, coupled with our flexibility in tool integration, sets us apart in delivering projects within timelines and budgets.

For prospective clients looking for a digital agency that is adept at the latest project management practices and committed to customizing these practices for success, Echobind is a partner you can trust.

*Claire is a project manager right here at Echobind and would love to help you hit your software goals this year. Reach out to us at [hi@echobind.com](mailto:hi@echobind.com) anytime.*

---

[View on echobind.com](https://echobind.com/post/project-management-tools-and-adapting-to-client-workflows)

---

# Does Your Product Need A Facelift?

> Brand redesigns and a spring cleaning of your look are imperative. Let's see if it's time for you to hire a designer for an update or a full change.

_By Eloisa Docton · 2024-04-26_

Is your product feeling dated? Have other competitors appeared since you launched?

Your product might need a brand refresh. 

## Every Brand’s Ugly Truth

All brands reach a point of needing a change, sometimes it’s a simplification, an expansion, a complete rebrand, and, sometimes, a brand facelift (or refresh).

There is a lot of misconception on whether or not you think you are ready for a rebrand. Rebranding takes an intense amount of research, A/B and market testing, feedback gathering, brand psychology, and the list goes on.

In short, rebranding takes a large amount of effort, and budget, which is why it’s more common for a brand to undergo an update than it is to rebrand.

![](https://cms.echobind.com/assets/95c63416-33ad-40e0-9fba-f1caede96916)

## What is a Product Facelift?

A brand refresh refers to the process of updating and revitalizing elements of a brand's identity, messaging, and visual aesthetics while retaining its core values and essence. It involves making strategic changes to modernize the brand and better align it with current market trends, consumer preferences, or shifts in the company's positioning.

### Here are some key components to keep in mind:

![](https://cms.echobind.com/assets/a83bb1fa-81e2-4220-8dd3-93784d034d53)

## Market Research

Conducting market research and gathering customer feedback to inform the refresh process and ensure the changes resonate with the target audience.

![](https://cms.echobind.com/assets/ee02e95f-3a49-4deb-8f47-aebb2240ad06)

## Messaging

A brand refresh often involves refining the brand's messaging, including its tagline, brand voice, and communication style, to ensure it resonates with target audiences and reflects the brand's current values and objectives.

![](https://cms.echobind.com/assets/99fc319d-dfe2-4911-a318-7e6a50fcbfa8)

## Brand Strategy

This is when you reevaluate the brand's positioning, target audience, competitive landscape, and overall marketing strategy to identify opportunities for improvement and growth.

![](https://cms.echobind.com/assets/29627c63-416e-4014-be9e-84e013992cd4)

## Visual Identity

This involves updating or modernizing the brand's logo, color palette, typography, imagery, and overall design elements to give the brand a fresh look while maintaining recognizability.

![](https://cms.echobind.com/assets/f29c4ecd-1259-4c87-a2ee-29c76257aa24)

## Transfer Findings to Product

Once we have learned from our research and have created the branding refresh, we are then ready to create the new UI for your digital product. This includes background colors, buttons, fonts, graphics, and all visual elements. 

We also take the opportunity to polish the user’s experience to ensure that the branding, messaging and flow perform as expected.

Sometimes these User Experiences require complete overhauls, but sometimes small tweaks can also provide the product with the right push to move the dial towards more positive results. This allows for small changes and bigger, more measurable impact.

So, where does your brand fall in this list? We're happy to help you determine just that. 

*Eloisa is a senior designer here at Echobind and is ecstatic at the thought of working on some killer designs for you this year. Don't hesitate to reach out at hi@echobind.com*

---

[View on echobind.com](https://echobind.com/post/does-your-product-need-a-facelift)

---

# Echobind Labs Update: Let's Talk Q2

> Echobind Labs wrapped up Q1 with momentum and gears up for an even stronger Q2 with Kind Kiosk, Wayfound, ApprovalStack and SceneFlow.

_By Chris Ball · 2024-04-23_

In March, I said 2024 was the [Year of Products](https://echobind.com/post/2024-the-year-of-products-at-echobind) at Echobind. We are now firmly in Q2, so let’s take a look at what we’ve been up to.

## How did our Q1 products fare?

As a reminder, we announced two products for Q1. [Kind Kiosk](https://kindkiosk.com) and [Wayfound](https://wayfound.app).

### Kind Kiosk is off to a great start

First, we (slightly) changed the name. “Kind Kiosk” felt better than “KindKiosk” the more we used it.  We released updates to tackle some of the most requested features we heard from prospective customers. [Check out our March roundup](https://kindkiosk.com/blog/whats-new-with-kind-kiosk-march-2024).

We’ve talked to numerous stand suppliers and have even started work with a local metal fabricator to create a simple, cost-effective way to mount the card reader. We’ll share more about that journey in the future.

Kind Kiosk has a solid enough foundation and plenty of interest, so we’ve made it a standalone company.

### Wayfound needs more validation

We’ve been using newly-created social media handles (TikTok, Instagram and X) as the primary outlet to test Wayfound. While we have generated some amount of interest via direct conversations, we need some more time to fully validate the idea with external product people. 

The goal of Wayfound is to provide a lightweight roadmapping solution. The software should be easy to understand and produce beautiful results with minimal effort. For client services companies, roadmaps are a constant and routine part of the job, especially for proposals. We hope we can alleviate some of the burden of creating these.

As projects mature, a complex roadmapping tool that integrates into your issue tracker might be a better fit. But when you’re planning a new project where things are fluid, you need the ability to put something together quickly and iterate on it.

We are learning that the space is a bit saturated and getting existing product people to try something simple is harder than it sounds. We’re doubling down on agencies as the target customer and are directly contacting folks in our network and running some small scale ads to gauge interest. 

---

## Let’s talk Q2

With Wayfound requiring further validation, we spent some time thinking about our next few products. Here’s what we’ll be focusing on this quarter (alongside Kind Kiosk and Wayfound).

### Product Launch #3: ApprovalStack

All client services companies work on approvals. Each of those companies have likely been in a situation where a verbal approval was given but not documented. Often, this results in some confusion or awkwardness. But it can get much worse! Clients may revisit decisions from 6 months ago and be upset about deadlines or budgets. “I never said that” can be a costly phrase.

We set out to solve this problem in an elegant way. To get an approval on a major decision, all you need to do is:

- Add the request to your project in ApprovalStack
- Send an approval link to the designated approvers via email (optionally adding others)
- The approver views the request, without needing to login. All they need to do is hit “approve” or “reject”. Rejections require a comment as to why.

On top of capturing decisions and approvals, a formalized process lends weight to the decisions being made, and it can help ensure that decision makers are considering everything before the click “Approve.”

Check out [ApprovalStack](https://approvalstack.com) and let us know what you think!

![](https://cms.echobind.com/assets/3d739f02-f565-4000-b3b3-ca35c28c9273)

### Product Launch #4: SceneFlow

Everyone has a routine before joining a video call, starting a coding session, or setting up a livestream. You might set your video window to a certain location on the screen and add notes under it. You might set a Slack status or Do Not Disturb mode. Maybe you turn on a light and pause your music.

SceneFlow aims to help you handle all of these tasks, automatically.

We are working on a POC and are currently creating a landing page and branding. We are targeting a landing page launch on or before 4/29/24. Here’s a sneak peek!

![](https://cms.echobind.com/assets/79d15088-db38-4d12-9b6b-83e031011d49)

## Process Improvements

We’ve started to fall into a pattern of one larger product and one smaller product per quarter. So far, it feels like a good balance, but may change as we get further along. 

We have been using Linear’s update feature to efficiently share multiple product updates across the team. These updates can be quite long, so it’s nice to have the shortened snapshot in our main #labs channel.

![](https://cms.echobind.com/assets/b40dbc95-c2fd-40d9-a204-69699760cc36)

![](https://cms.echobind.com/assets/35f7d53f-9caf-42aa-895a-6850909f9770)

New product pitches will happen during a pitch session halfway through the quarter. Previously we were doing this during our weekly labs status meeting. We’ve also changed the format of our weekly meetings to the following:

For each product: (5 min max per product)

- Top Product Priority
- Challenges or blockers

 Group Discussion (15 min max)

- More on challenges and product priorities
- Anyone looking for labs work to do?

I’m really excited about the work our team is doing, and can’t wait to recap our Q2 progress.

*Chris is Echobind’s Chief Technology Officer. Excited about Labs and want to reach out to learn more? Don’t hesitate to email us at [hi@echobind.com](mailto:hi@echobind.com) anytime.*

---

[View on echobind.com](https://echobind.com/post/echobind-labs-update-how-did-q1-2024-go)

---

# Why You Need A Designer For Your Project

> Designers are crucial when building software and here's exactly why you need one.

_By Eloisa Docton · 2024-04-18_

While design is not only about creating beautiful products, studies show that aesthetically-pleasing products evoke positive emotions, suggest higher quality, enhance user engagement, contribute to a positive brand image, and influence consumer purchasing decisions. By prioritizing aesthetics alongside functionality, companies can create products that resonate with users and drive business success.

## What does a designer do?

In the digital world, there are a ton of different designers. Some are generalists, which means they can do a little bit of everything, and, some are more specialized and know their craft well.
Below is a simplified explanation of the types of designers you might need for web or app development.

![](https://cms.echobind.com/assets/830a4673-0348-4c8d-8dcb-65f03c081823)

- **Graphic Designers:** often work with clients or teams to understand their needs and develop creative assets like graphics, branding, and illustrations that align with brand identity and objectives.
- **UX Designers:** research user needs, behaviors, and preferences to inform design decisions. They employ user testing and feedback to iterate and refine designs, aiming to optimize usability and enhance overall user satisfaction.
- **UI or Visual Designers:** create visually-appealing and intuitive user interfaces. They ensure that the user is delighted through their entire experience.
- **Product Designers:** work on various stages of the product lifecycle, from ideation and concept development to prototyping and production. They conduct research to understand user preferences and market trends, then use this information to design. They collaborate with cross-functional teams, including engineers, marketers, and stakeholders, to ensure that the final product aligns with business objectives and user requirements.

## 3 ways designers add value to a product

Designers play a crucial role in not just creating visually-appealing products but also ensuring that users have a smooth and enjoyable experience while interacting with them. Here's a breakdown of how designers achieve this:

1. **Streamlining User Activities:** Designers analyze how users interact with a product or service and identify areas where the user experience can be simplified and streamlined. This involves removing unnecessary steps, reducing complexity, and optimizing workflows to make it easier for users to accomplish their goals efficiently.

![](https://cms.echobind.com/assets/01945bb0-6572-4022-85cc-a8cc7ba36606)

2. **Maintaining Usability and Adoption:** Designers continuously monitor the usability of the product by gathering feedback, conducting usability testing, and analyzing user behavior metrics. By staying informed about how users engage with the product, designers can identify pain points or areas of friction and make iterative improvements to enhance the overall user experience. Additionally, they ensure that new features or updates are adopted smoothly by users through intuitive design and effective communication.

![](https://cms.echobind.com/assets/d5cd3b6e-eead-4320-92bb-d83848ced7a9)

3. **Suggesting Solutions for Cost Reduction and Increased Market Share:** Designers are not only concerned with the user experience but also with the business impact of their designs. They propose solutions that not only improve usability but also contribute to lowering the cost of customer acquisition and support. By optimizing the user experience, designers can help attract and retain customers more effectively, reducing the need for costly marketing campaigns and support interventions. Moreover, by creating products that users love and find easy to use, designers can increase customer retention and loyalty, ultimately leading to increased market share for the company.

![](https://cms.echobind.com/assets/e2c80d1d-f778-41cd-9d20-2269c0ab75e5)

In summary, designers play a multifaceted role in improving the user experience by streamlining activities, maintaining usability and adoption, and suggesting solutions that not only enhance the user experience but also contribute to cost reduction, increased customer retention, and market share growth. Through their expertise in design thinking and user-centered design principles, designers drive value for both users and businesses alike.

*Eloisa is a senior designer here at Echobind and would love to work with you on your next big project. Reach out to us at hi@echobind.com*

---

[View on echobind.com](https://echobind.com/post/why-you-need-a-designer-for-your-project)

---

# Rendering Tailwind-styled PDFs from Rails View Templates using Grover

> How to render Tailwind CSS-styled PDFs directly from Rails view templates using Grover.

_By Deloris Thompson · 2024-04-15_

In this tutorial, we'll dive into the process of rendering Tailwind CSS-styled PDFs directly from Rails view templates using Grover. By following these steps, you'll be able to seamlessly integrate Tailwind CSS into your PDF documents while retaining the flexibility of Rails view rendering.

## **Prerequisites:**

Before we begin, make sure you have the following prerequisites:

- Basic knowledge of Rails
- Installed Tailwind CSS and Grover gems
- Access to an existing or new Rails application
- Run all commands in the desired projects folder

### **Step 1: Creating the Tailwind PDF Stylesheet**

To get started, let's create a new Tailwind CSS stylesheet specifically for PDFs. Open your terminal and run the following command:

```bash
touch public/tailwind_pdf.css
```

### **Step 2: Configuring Grover for Rails View Templates**

Next, configure Grover in your Rails controller to render the PDF directly from a view template.  Here's a sample code snippet to guide you:

```ruby
 # Render the view template to PDF
 view = ApplicationController.new.view_context
 
  html = view.render({
    # Point to the template or partial you want to use
    partial: "",
    # pass any locals you need
    locals: {}
  })

  # Generate the PDF using Grover
  pdf = Grover.new(html,
    # You can change the format to A3, A4, A5, Legal, Letter, Tabloid
    format: "A4",
    puppeteer: { args: ["--no-sandbox"] }
    ).to_pdf

    # Create a temporary file to store the PDF
    temp_pdf = Tempfile.new(["preview", ".pdf"], Dir.tmpdir)
    temp_pdf.write(pdf)
    temp_pdf.close

    # Log the temporary file path
    Rails.logger.info "PDF file created at #{temp_pdf.path}"

    # Return the path of the temporary file
    temp_pdf.path
  ```

### Step 3: Adding Tailwind through a style tag

We can add style tags to our PDF by passing an array of style tag options to `style_tag_options`  and including our new `tailwind_pdf.css` file.  Let's update Grover to use it, we can also add `printBackground` if our page contains background graphics.

```ruby
# Exisiting code
pdf = Grover.new(html,
        format: "A4",
        printBackground: true,
        style_tag_options: [{ path: "public/tailwind_pdf.css" }],
        puppeteer: {
          args: ["--no-sandbox"]
        }).to_pdf
# Exisiting code
```

### **Step 4: Recompiling Tailwind CSS**

The `tailwindcss-rails` gem creates an input file that generates an output file containing the CSS in `app/assets/builds/tailwind.css`.  Running `rails tailwindcss:build` or `rails assets:precompile` updates that output file and is the same CSS used in our application.  Let’s update our Tailwind.css file by running `rails assets:precompile` and copy it to the Tailwind PDF stylesheet. Run the following command in your terminal:

```bash
bundle exec rails assets:precompile

# This should point to where you are compiling assets
cp public/packs/tailwind.css public/tailwind_pdf.css

```


### **Conclusion:**

Following these steps, you can render Tailwind CSS-styled PDFs directly from Rails view templates using Grover. This approach allows you to maintain consistent styling across your web application and PDF documents, providing a seamless user experience.

*Deloris Thompson is a senior software engineer at Echobind. Want to work with her and the entire team? Don’t hesitate to reach out at [hi@echobind.com](mailto:hi@echobind.com) anytime.*

**Additional Resources:**

- [Tailwind CSS Documentation](https://tailwindcss.com/docs/installation)

- [Grover Documentation](https://github.com/Studiosity/grover)

---

[View on echobind.com](https://echobind.com/post/rendering-tailwind-styled-pd-fs-from-rails-view-templates-using-grover)

---

# Cloudflare D1 Prisma Migration Script

> Cloudflare D1 and Prisma work together now, but you have to run the migrations yourself. So we wrote our own script to make the process more convenient.

_By Alex Anderson · 2024-04-05_

Cloudflare D1 and Prisma [now work together](https://blog.cloudflare.com/prisma-orm-and-d1) using a new adapter! This is great if you want the convenience and developer experience that Prisma provides, while using the ultra-fast, globally-available database built into Cloudflare Workers and Pages.

However, the adapter doesn't support Prisma migrations out-of-the-box. Instead, you have to generate the migrations manually using `prisma migrate diff`, and then apply them manually using `wrangler d1 migrations apply`.

We wanted to simplify this process further by creating a simple migrations CLI. It automatically detects your Prisma schema and database bindings in `wrangler.toml`, but all of that is configurable. And since you're copy/pasting the file into your codebase, you can tweak it however you like.

Here's how to use it:

1. Follow the instructions in the [Cloudflare blog post](https://blog.cloudflare.com/prisma-orm-and-d1) for getting Prisma and D1 set up in your project. The [gist that has the migrate script also summarizes the setup instructions](https://gist.github.com/alexanderson1993/0852a8162ebac591b62a79883a81e1a8).
2. Download the `migrate.ts` file from [the gist here](https://gist.github.com/alexanderson1993/0852a8162ebac591b62a79883a81e1a8) and put it in the `prisma/` folder in your project.
3. Add `"db:migrate":"npx tsx prisma/migrate.ts"` as a script to  your `package.json` file.

Now you can create and apply your migrations by running `npm run db:migrate create`.

Enjoy!

---

[View on echobind.com](https://echobind.com/post/cloudflare-d1-prisma-migration-script)

---

# Quick Tips from a Product Designer: Brand Fonts

> A senior designer's tips and tricks about using brand colors when designing for a client.

_By Eloisa Docton · 2024-04-03_

Fonts play a critical role in branding, and selecting the right font is vital. Not all fonts are equal; some may require additional licensing or may not be compatible with certain technologies.

![](https://cms.echobind.com/assets/c40c6a64-1d60-4375-9eca-18c2b42e4625)

## Tip #1: Font legibility

Font accessibility is paramount, with readability being a key factor. Fonts should be legible even at smaller sizes to ensure user comprehension.

While there are many guidelines, there’s not a single test out there to determine if your fonts are accessible or not. Here are some of the most common things that should be ensured when it comes to fonts:

- **Context of use:** Headers, body copy, data, small UI text, and CTA’s all have specific purposes, so it’s important to ensure that the fonts are tested in all scenarios to ensure the user can read your communication.
- **X-height:** In general, fonts with larger x-height appear more legible, so they are often used for small captions and other small text.
- **Counters and apertures:** Balanced spacing within letter curvatures and opening allow for the text to be more legible
- **Stroke weight**: Not all fonts have different weights, so it’s important to find fonts that have a wide-range of weights so they can be used in the various UI elements needed in digital products.
- **Color Contrast**: Text should have enough contrast to meet usability standards. There is more detailed information in [this blog post](https://echobind.com/post/quick-tips-from-a-product-designer-brand-colors) that I wrote, as well. Font accessibility is paramount, with readability being a key factor. Fonts should be legible even at smaller sizes to ensure user comprehension.

![](https://cms.echobind.com/assets/c14dced3-c970-482b-9a00-7e2a9d8065dd)

## Tip #2: Font family

While it may not always be required, it is generally advisable to consider exploring readily-available fonts, such as those offered by [Google Fonts](https://fonts.google.com/). These fonts are known for their wide compatibility with digital products, making them a convenient and accessible option for various design projects.

An easy way to verify what type of use a font was designed for is by paying attention to the name. Fonts with “text” in the name are typically highly-legible and designed specifically for body copy whereas fonts with "display" in the name are better for headers or copy at larger text sizes.

In branding, it's typical to utilize multiple font families based on their specific use. For instance, fonts used for titles tend to be thicker and more decorative compared to those used in content. Designers often mix and match popular fonts to achieve effects.

![](https://cms.echobind.com/assets/105f5a81-8aa9-48dd-8ff0-1186180b2fce)

## Tip #3: Select a font scale with appropriate sizes for your project

While we usually include approximately 8 or more text sizes for a product, generally speaking, it’s more important to understand the accessibility needs of your product to determine what will work best. However, most digital products will use something like:

- Minimum size of 12pt, used for captions and some UI components that use minimal space (like system messages and captions)
- Paragraph size of 16pt, used widely through the product

Things like titles, subtitles, buttons, and other UI elements will have unique sizes based on the font used, the product designed, and the user needs. 

![](https://cms.echobind.com/assets/774ec325-58b1-4da8-98f4-3cc7d237a753)

## Tip #4: Testing fonts

While there is no one single test to ensure fonts meet usability standards, we rely on thoughtful design where we use appropriately-sized fonts for their use and screen size, and user feedback to understand the readability of the content and UI elements. 

Ensure font readability across different devices and environments. Consider user feedback and online resources to select the most suitable fonts for the product, even if it means introducing a new one to the brand.

![](https://cms.echobind.com/assets/2305e6e1-9cd0-4ef2-ab37-e2fa87fe8f03)

## Tip #5: Font pairing

If you pay attention to the way this very blog post is laid out, and how the fonts are used, you can see a great example of font pairing. We deep dive into hierarchy [in this post](https://echobind.com/post/5-minute-redesigns-improving-hierarchy-in-2-steps) from last month. Things to take into consideration:

- Titles are typically large-scale and heavier in weight. They serve as prominent identifiers for sections or topics. Sans fonts are commonly used for titles, while Sans Serif fonts in heavier weights, all caps, or with other stylistic variations are also popular choices to make them stand out.
- Paragraph fonts are scaled to fit the reader's needs, typically ranging from 14px to 20px. They are the main body of text and should be chosen for readability and legibility.
- Subtitles are scaled larger than paragraph text but smaller than titles. They provide additional context or information beneath the main title. Like titles, they may also be heavier in weight for emphasis.
- Table Fonts are used in tables and should prioritize readability, especially considering the smaller scale of information within cells. Sans fonts are often avoided in favor of fonts with better legibility at small sizes.
- CTA Fonts (call to actions, like buttons and links) will often be a stylized version of the paragraph font, heavier weights, captions, spacing are often variations.
- UI Fonts are used to help the user through their journey, such as alerts, error messages, and descriptions, etc. They're usually scaled in the smallest readable text, around 12px.

![](https://cms.echobind.com/assets/b60536d3-65d4-4aa7-8e65-74543b2589c9)

## In Short

Every single one of these tips is a simplified recommendation, and they actually work! Some key takeaways:

- Fonts have a very important role in digital products; they help the user understand the screens and what is being asked of them.
- It takes the user a shorter amount of time to complete tasks as the eyes will signal the brain as it matches the way the font looks to the context.
- The use of certain fonts need to be excluded from digital products because they don’t play nice with technology.
- As always, accessibility should always triumph over the use of branding fonts.

*Eloisa is a senior designer here at Echobind. If you're interested in working with us, don't hesitate to reach out at hi@echobind.com*

---

[View on echobind.com](https://echobind.com/post/quick-tips-from-a-product-designer-brand-fonts)

---

# Client Satisfaction & Feedback: A Guide for Account Managers

> Experienced account managers know how to obtain client feedback effectively and use it in best ways possible for their agency.

_By Lex Meola · 2024-04-01_

Welcome to the high-stakes world of account management, where the satisfaction of your clients reigns supreme.

As an account manager, your ability to navigate the delicate balance of client satisfaction and feedback directly correlates to amount of success you’ll have.

Let's dive into the crucial aspect of your role with a blend of professionalism and a sprinkling of humor.

1. **The Power of Satisfaction**: Client satisfaction isn't just a metric; it's the lifeblood of your business. Satisfied clients are not only more likely to remain loyal but also to become ambassadors for your brand. It's like having a loyal fanbase who can't stop singing your praises – and who doesn't want that? No one. The answer is no one. Everyone wants it.

2. **Embracing Feedback**: Feedback, while sometimes daunting, is an invaluable tool for growth. It's the compass that guides you towards improvement and innovation. Think of it as the GPS for your journey towards client satisfaction – occasionally recalculating, but always leading you in the right direction.

3. **The Art of Active Listening**: As an account manager, your ability to actively listen is your secret weapon. It's not just about hearing what your clients say; it's about understanding their needs, concerns, and aspirations. Think of it as tuning in to your favorite podcast – except instead of improving your health and wellness or nerding out on true crime, you're dialing in to the voice of your client to improve their experience. 

4. **Finding the Balance**: Balancing the demands of multiple clients can sometimes feel like juggling chainsaws while riding a unicycle – challenging, but not impossible. The key is prioritization and effective time management. Know when to say yes, when to say no, and when to ask for help. After all, even the most skilled jugglers need a safety net. I was at a show once where they didn’t put one up. It was…devastating to say the least. The bowling pins were fine though.

5. **Turning Challenges into Opportunities**: Every challenge is an opportunity in disguise. Whether it's a client complaint or a missed deadline, approach it with a solutions-oriented mindset. Think of it as turning lemons into lemonade – except instead of a refreshing beverage, you're serving up stellar client service.

6. **Continuous Improvement**: The pursuit of client satisfaction is a journey, not a destination. It's a marathon, not a sprint. Embrace a culture of continuous improvement, always striving to raise the bar higher. Think of it as climbing a never-ending staircase – challenging, but with breathtaking views at every step. 

In conclusion, navigating client satisfaction and feedback is both an art and a science.

It requires a delicate balance of professionalism, empathy, and a willingness to embrace feedback with open arms. So, my fellow account managers, let's approach this challenge with confidence, determination, and just a hint of humor – because after all, laughter is the best medicine for even the most daunting tasks.

*Lex Meola is Echobind’s account manager; feel free to [schedule a 15-minute call with her](https://savvycal.com/lexmeola/dcf1e6ba?sid=56a72085-047c-424e-b277-a17fb391a84a&from=2024-03-31) during the week via her SavvyCal. Whether you [want to hire Echobind](https://www.echobind.com/contact) or just need someone to chat account management with, she’s a great resource for it all.*

---

[View on echobind.com](https://echobind.com/post/navigating-client-satisfaction-and-feedback-a-professional-guide-for-account-managers)

---

# A Developer’s First Two Weeks with an Apple Vision Pro

> A software developer spent two weeks with the Apple Vision Pro and gives his hot takes.

_By Brandon Richey · 2024-03-29_

Last month, Apple finally shipped the long-rumored (and possibly one of their worst-kept secrets) Apple Vision Pro. I'll admit that my initial reactions were a healthy mix of curiosity and skepticism. As a developer, I'm constantly seeking tools that not only enhance our productivity (and get me closer to my childhood vision of a totally VR computing space, thank you Hackers "flying through the computer" montages). Enter the Vision Pro, a device that has been making waves for its innovative approach to spatial computing and app integration. After spending one month with the Vision Pro, here's a deep dive into my experience and the valuable lessons learned.

## Is the Simulator Enough?

Short version: no. Apple thankfully provides some really great device simulators to help you build products with XCode, and their Vision OS device simulators are thankfully continuing this tradition. However, throughout my time with the device, it became clear that simulators pale in comparison when building complex applications, especially if those applications rely on either spatial functionality or AR functionality. Using it with the actual Vision Pro offers a unique, immersive testing environment that simulators simply cannot replicate, providing invaluable insights into the user experience of spatial and augmented reality apps. If you're building Apple Vision Pro apps, then yes, you're definitely going to need one at some point.

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/928465475?h=3d2cbf4119&amp;badge=0&amp;autopause=0&amp;player_id=0&amp;app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="Brandon Richey's First Two Weeks with Apple Vision Pro"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

<br />

## The Ultimate Productivity Companion

The Vision Pro proved to be the perfect sidekick for couch-based productivity, and I say this as someone with a REALLY big monitor for development. Pairing it with my Macbook Pro opened up a new dimension (see what I did there?) of comfort and efficiency, making it an indispensable tool for developers who cherish the flexibility of working from any corner of their home, without losing any of the critical screen real-estate I've come to expect from my stationary work desk. Even after a month of using it, doing anything on the couch (or frankly anywhere away from my main development rig) usually means picking up the Vision Pro first and taking it and my laptop with me.

## A Developer's Dream: Tools and SwiftUI

Developing for the Vision Pro is not just feasible; it's a pleasure. The plethora of tools available, coupled with the simplicity and power of SwiftUI, makes developing engaging apps a breeze. Whether it's designing intuitive UIs or integrating complex functionalities, the Vision Pro environment is surprisingly developer-friendly, making it an exciting platform for innovation. SwiftUI is a great framework to build apps in and it's great that they put it front and center when building new Apple VisionOS apps.

## BYOGDS (Bring your own game development skills)

For those versed in game development, transitioning to creating spatial apps for the Vision Pro feels like a natural progression. The skills acquired in game development, such as spatial reasoning and 3D modeling, are directly applicable and highly beneficial. This cross-compatibility not only eases the learning curve but also enhances the quality and depth of the apps developed. Hope you know your quaternions! I haven't messed around with Unity's tooling yet, but that's on my list.

## Comfort: A Work in Progress

While the Vision Pro excels in many areas, comfort is one aspect that needs attention. The single nylon strap falls short in providing the necessary support for extended use. Investing in a dual strap for the top and back of the head is essential for achieving the comfort level required for long development sessions or simply enjoying the device for leisure. I've seen all kinds of homebrew bands and things that hope to fix or at least alleviate some of this, but VR raccoon-face remains an issue even after years of VR headsets.

## The Uncanny Valley of Personas

![](https://cms.echobind.com/assets/5b7eed90-bc29-45a9-b7bf-3016ecdccb19)

*Hands also suffer from the uncanny valley: it looks very virtual and there’s no “hand scanning” functionality, so it’s just enough to be a little off-putting*

The attempt at creating lifelike avatars or "Personas" within the Vision Pro ecosystem is ambitious. However, it currently resides in the uncanny valley, where the avatars are realistic enough to be unsettling yet not lifelike enough to feel genuine. The few meetings I've tried so far with Zoom and their persona avatar concept were off-putting and generally just creepy. That is, at least when the meetings worked...

## And the Sheer Cliff of Audio Troubles with Zoom

![](https://cms.echobind.com/assets/63e4bb59-d5af-4740-bc5b-1b646a88837c)

*Frowning also doesn’t work.*

...because in an era where remote work and virtual meetings are the norm, the Vision Pro's integration with popular apps like Zoom is crucial, and the app just does not function well. This is a significant drawback for developers and professionals who rely on seamless communication for collaboration. As soon as those issues are fixed, this app will be more usable. Until then, I wouldn't hope for this to be your day-to-day meeting and work device. 

Unless you want to be *that* person. Persona. Whatever you want to call it.

## Ergonomics and Battery Life: A Balancing Act

The Vision Pro strikes a good balance in terms of ergonomics and battery life. While it's slightly on the heavier side, it's not a deal-breaker. The device manages to maintain a level of comfort that supports prolonged usage, and the battery life has proven to be satisfactory for day-to-day tasks and development work. Overall, I give it a B+.

## Not Just Another Gaming Device

Apple's decision to orient the Vision Pro towards apps, rather than gaming, is a strategic move that aligns well with its ecosystem. The "hand tracking by default" decision significantly reduces friction, making the device more accessible and intuitive for a wide range of applications. This focus has the potential to redefine how we interact with digital content and develop applications. It also really only takes that 30-minute demo in the Apple Store to "get it"; after that pinching, pulling, zooming, and moving feels pretty intuitive, and holding the dial to recenter/regroup windows feels quick and simple.

## The Price Point Dilemma

The Vision Pro's capabilities are undeniably impressive, but its adoption is ultimately tied to its price point. At its current pricing, it remains a premium offering that may not be accessible to all Apple enthusiasts. However, I'm convinced that if the device were priced at $1,500 or less, it would become a staple in every Apple home, given its potential to revolutionize productivity and entertainment. Watching Mad Max: Fury Road on this thing, in full 3D, in my own personal theater, in super high resolution was an absolute dream and in my mind is *THE* way to watch that movie. I have yet to try anything else on it, though I'm excited to watch a lot more!

## Conclusion

If the Vision Pro is indicative of where the AR/VR/XR/Spatial ecosystem is going, then I'm really excited to see how things shape out. There are some hurdles, to be sure, and that price point is...frankly not going to win anyone over. But if you look at the Vision Pro as more of a preview of coming attractions, it's hard to not get excited about what that really could mean for developers, for consumers, and for everyone in-between. It's the perfect merger of entertainment, productivity, and technology, and as the price goes down, the functionality gets more refined, and more developers start to envision what we can really do with technology like this, I can't help but be excited about what a broader consumer audience for this could bring.

![](https://cms.echobind.com/assets/1c4a8710-c150-4477-853e-f41b111acfa3)

I still don't have my "flying through my file system in 3D" functionality yet, though.

**Brandon is a senior software engineer here at Echobind. [Reach out to him on X](https://twitter.com/diamondgfx) anytime or email us at hi@echobind.com to build software for you within the spatial ecosystem Brandon wrote about above.**

---

[View on echobind.com](https://echobind.com/post/a-developer-s-first-two-weeks-with-an-apple-vision-pro)

---

# Quick Tips from a Product Designer: Brand Colors

> Read these quick-hitter tips and tricks all about brand colors and how to properly use and understand them in your design work.

_By Eloisa Docton · 2024-03-25_

We often work with clients who have branding guidelines that they acquired from agencies or in-house teams. These guidelines usually focus more on marketing aspects like merchandise, online presence, and social media while overlooking user experience (UX).

![](https://cms.echobind.com/assets/cce38ff3-09fe-45c8-849e-fc44b5c9473a)

When creating digital products, usability and accessibility are prioritized. Sometimes, branding guidelines don’t quite meet usability standards, requiring extra work to prioritize usability over branding. This could be avoided by considering usability needs early in the branding process.

While creating a user-friendly product requires research, knowledge, tools, and testing, there are simple tips to start the branding and UX journey effectively.

## Colors

![](https://cms.echobind.com/assets/27ebf829-1b41-48b8-8b51-d3ae2339f862)

There's a vast array of colors available for digital use. It's essential to consider color combinations and their intended purposes. Users associate certain colors and symbols with specific actions or feelings, based on color psychology. For instance, red signifies passion and alertness, making it suitable for highlighting important information like errors.

![](https://cms.echobind.com/assets/ac8e5a62-3801-4127-83c7-036f4f9667e4)

When creating palettes, there is also a need for multiple neutral shades. We use those for backgrounds and UI elements. Having multiple colors to choose from ensures tighter brand control and harmony across products.

![](https://cms.echobind.com/assets/e8bae6f8-9984-4b37-9c89-a988ba9c6e66)

When designing branding, it's important to avoid overwhelming users with excessive use of colors. Colors like red, green, and yellow also convey messages and should be used judiciously, as these colors are also used for common UI for semantics. 

Color combinations should prioritize contrast for usability. Testing color usability against background and text is crucial, with resources like the [WebAIM website](https://webaim.org/articles/contrast/) offering valuable insights.

![](https://cms.echobind.com/assets/1c2ea604-f5fb-4bd3-80dc-fffe644e2e38)

## Example
Let's examine a sample brand kit comprised of a logo, primary colors, and designated fonts.

![](https://cms.echobind.com/assets/8b1bc441-9715-4d98-80d3-f72ae5f8091f)

We begin by evaluating the colors designated for links and buttons, which are common UI elements in most products. For this example, we’ll use magenta:

![](https://cms.echobind.com/assets/e011120d-3dae-419b-bd88-00d95c9cc704)

In our tests, it's evident that magenta does not contrast effectively with white but performs better with black.

However, considering the accessibility rating, it appears that small fonts may only achieve partial accessibility. In this case, we may need to explore tints of the color, which derive from the main color. They are lighter and darker shades of the same color. We’ll lean on lighter for this exercise, as the background is dark; however, if you have a light color background, it will be best to lean towards darker tones.

![](https://cms.echobind.com/assets/af105c99-2517-40e2-a5c4-19aefef6def6)

The additional colors are derived from the original magenta. Now, we can test those against black or white to see if we can get to a better usability rating:

![](https://cms.echobind.com/assets/a0218c0c-0dfe-4c97-97d5-d0505f7f1c26)

Now that we’ve updated the magenta to a lighter tint, the accessibility rating on the black text increases, so this is what we would use. 

In a real-life scenario, we may repeat this exercise with each color if we find it necessary, use sophisticated tools, and even test with users to land on the best option for your product.

That’s it! In summary, integrating minor UX considerations at the outset enhances the design process and minimizes the need for extensive brand adjustments and unnecessary marketing revisions.

*Eloisa is a senior designer here at Echobind. If you're interested in working with us, don't hesitate to reach out at hi@echobind.com*

---

[View on echobind.com](https://echobind.com/post/quick-tips-from-a-product-designer-brand-colors)

---

# Demystifying ESLint Configurations: A Helpful ESLint CLI Command

> Frustrated by conflicting ESLint configs? This microblog entry reveals a magical CLI command to debug hierarchies and untangle settings.

_By Mike Cavaliere · 2024-03-18_

Hey there, fellow developers! I want to drop a quick but incredibly handy tip that's been a lifesaver for me, especially when wrestling with those pesky linter configs and VSCode auto-formatting quirks. Here it is: **`eslint --print-config <file.js>`**. Yep, that's the command you need to keep in your toolkit (docs [here](https://eslint.org/docs/latest/use/command-line-interface#--print-config)).

Why is it so useful, you ask? Well, this nifty little command does something super valuable – it reveals the actual ESLint configuration applied to your JavaScript file. We've all been there, setting up ESLint, tweaking rules, only to find our VSCode doing its own thing when auto-formatting. It's like that one puzzle piece that just won’t fit, no matter how hard you try. But, fear not! This command is like the magnifying glass that brings into focus what's really going on with your configurations.

So next time you find yourself in a tangle with ESLint rules, or VSCode seems to have a mind of its own, remember this command. It’s a straightforward, no-nonsense way to get a clear view of the ESLint configurations at play. Debugging and configuring become much more manageable, saving you time and, let's be honest, a bit of sanity. Keep coding and stay efficient!

*Mike is a senior software engineer at Echobind; [give him a follow on X](https://twitter.com/mcavaliere).*

---

[View on echobind.com](https://echobind.com/post/demystifying-es-lint-configurations-a-helpful-es-lint-cli-command)

---

# 10 Terms All Account Managers Need To Know When Working With Software Engineers

> Here are 10 terms all account managers need to know when working with software engineers.

_By Lex Meola · 2024-03-13_

I remember it like it was yesterday.

I was sitting in a conference room with four senior engineers. One of whom everyone at the company referred to as “Zucky,” akin to Mark Zuckerberg. The imposter syndrome wasn’t just in the room with me, it was breathing down my neck, constantly reminding me that I didn’t understand the context of the meeting and therefore, didn’t deserve to be there.

For those of us who are more business-focused, participating in a discussion that is overtly technical can feel painful. As the imposter syndrome creeps in, we feel uncomfortable and quite frankly, lost.

I’d love to go over 10 terms I got a hold of that have helped drive technical conversations and reduce the discomfort I experience when I lose the plot of a discussion.

## **Let’s break it down**

Account managers serve as a crucial bridge between clients and internal teams, ensuring smooth communication and successful project outcomes. When collaborating with software engineers, having a solid understanding of technical terminology is essential for effective coordination and relationship-building.

In this blog post, we'll explore the top 10 terms every account manager should know when working with software engineers:

1. **Agile Methodology:**
Agile is a project management framework characterized by iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. Understanding Agile principles helps account managers grasp project timelines, priorities, and the iterative nature of software development.
2. **User Story:**
A user story is a concise description of a software feature from an end-user perspective, typically written in non-technical language. Account managers should understand user stories to effectively communicate client needs and priorities to the engineering team.
3. **Backlog:**
The backlog is a prioritized list of features, enhancements, and fixes that need to be addressed in a software project. Account managers should be familiar with backlog management tools like [Jira](https://www.atlassian.com/software/jira) or [Trello](https://trello.com/) to track project progress and prioritize tasks effectively.
4. **API (Application Programming Interface):**
An API is a set of rules and protocols that allows different software applications to communicate with each other. Account managers should understand APIs to facilitate discussions around integrations, data exchange, and system interoperability.
5. **MVP (Minimum Viable Product):**
The MVP is the simplest version of a product that satisfies customer needs and allows for iterative development based on user feedback. Account managers should understand the concept of MVP to manage client expectations and prioritize features for early release.
6. **Deployment:**
Deployment refers to the process of releasing a software application or feature into a production environment for end-users to access. Account managers should understand deployment pipelines, version control systems, and release management practices to coordinate product releases effectively.
7. **Testing (Unit, Integration, Regression):**
Testing is a crucial aspect of software development to ensure product quality and reliability. Account managers should understand different types of testing, including unit testing (testing individual components), integration testing (testing interactions between components), and regression testing (ensuring new changes don't break existing functionality).
8. **Scalability:**
Scalability refers to a system's ability to handle increasing workload or user demand without sacrificing performance. Account managers should understand scalability considerations to anticipate future growth and ensure the software can accommodate evolving needs.
9. **DevOps:**
DevOps is a cultural and technical movement that emphasizes collaboration and automation between software development and IT operations teams. Account managers should understand DevOps principles to facilitate communication and collaboration between development and operations teams.
10. **SLA (Service Level Agreement):**
An SLA is a contractual agreement between a service provider and a client that defines the level of service expected, including metrics such as uptime, response time, and resolution time. Account managers should understand SLAs to manage client expectations and ensure service delivery meets agreed-upon standards.

I can’t stress it enough: Effective communication between account managers and software engineers is essential for successful project delivery.

By familiarizing themselves with these top 10 terms, account managers can enhance collaboration, streamline project management, and ultimately deliver better outcomes for clients and stakeholders.

*Lex Meola is [Echobind’s trusty account manager](https://echobind.com/post/lex-is-ready-to-talk-to-you). Reach out to her at any time (lex@echobind.com) if you’re interested in working with us, or even [grab 15 minutes on her SavvyCal](https://savvycal.com/lexmeola/dcf1e6ba?sid=b20642b3-ce77-4271-bbbd-d6db4301d5b3).*

---

[View on echobind.com](https://echobind.com/post/10-terms-all-account-managers-need-to-know-when-working-with-software-engineers)

---

# A Simple Start to Caching

> Speed up apps by caching work in the right place.

_By Alex Anderson · 2024-03-11_

Apps do work; work takes time. Spend too much time doing work, and users get frustrated.

Naturally, you can try to speed up the work somehow - make your code do less work, optimize slow code paths, put your servers closer to databases. But alas, for some situations even the fastest programs are still too slow.

Fortunately, much of the work to do is work that’s already been done before. Can’t we just… reuse that work? 

![](https://cms.echobind.com/assets/1ffc9976-4432-4890-865a-8f5aafd6c09d)

*It’s not cheating, it’s just looking at work that’s already been done.*

In the context of web apps, that work could be CPU-bound, like performing a costly calculation, or IO-bound, like downloading files from the server or fetching data from a database By storing the result of that work, you can skip the work the next time you need it.

The basic principle is simple: Every possible bit of data is identified with some key, like `user-1` or `/favicon.ico` or `fibonacci-25`. Before getting the data from its source, we check the cache to see if it’s already there. If it is, great! We return the data. If not, we do the expensive operation, put the result in the cache, and return that to the user. 

Sounds simple, right? What could possibly go wrong?

### Cache Keys

For starters, you’ve got to be careful about making sure you put enough information into your keys. Take this filter menu for example.

![](https://cms.echobind.com/assets/18106c9c-48db-4cfb-b397-fd1a40c1e9bf)

Suppose we wanted to cache the results for a user. Here, we’ve got five categories of things. Type and Color can be multiple values at the same time, while Price can be a granular scale of values. How do you come up with a cache key for this data?

It’s important to remember that cache keys need to exactly represent the data they store. Suppose we forget to include the `color` input in our cache key. Maybe the cache key is something like `${sort}-${inStock}-${priceLow}-${priceHigh}-${types.join(',')}`. 

Our first user comes, filters by red products, and the results get put in the cache with the key `selling-false-0-35-`, which is the default key.

Then the next user comes along and filters by yellow. The cache key is `selling-false-0-35-`. 

See the problem?

Because we’re missing `color` in our cache key, user 2 will get the same results as user 1, even though they requested a totally different set of colors.

This also illustrates how as your cached function has more inputs, the cache key becomes more complicated. Eventually your cache key becomes so granular that it might not even be worth it to cache the data at all.

It wouldn’t be a problem if we had unlimited storage, but alas - you will eventually run out of space and something will have to be removed from the cache.

But there’s another, likely more important, reason for removing things from the cache - eventually the underlying data will change. Unless the cache is updated with it, now your cache is returning outdated data.

### Cache Invalidation & Eviction

> There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
> 

In an ideal world, any time the underlying data changes, you could determine exactly what cache keys use that data and just delete those items. This provides the most granular, exact caching that is always up-to-date, but it can take effort to do well.

Alternatively, the cache itself can make sure the data is fresh. Perhaps it includes a `modified` date that it can use to quickly query the source database to know if the data has changed.

A safer fallback - one that risks returning outdated data, but can still work most of the time - is to set some kind of cache expiration or eviction policy. For example:

- items only remain in the cache for n seconds
- items are removed from the cache at a specific time
- the cache only contains n number of items, removing the oldest item (LRU, or least-recently used), infrequently accessed items (LFU, or least-frequently used), or a random item when a new item is added
- treating items as stale after a certain time and returning the old cached entry while new data is fetched - also knows as “stale while revalidate”

Which combination of strategies you use depends on what the data is and where it is cached. For example, a static website might use the `Cache-Control` header to have the browser cache the site for a certain amount of time, while a dynamic filter like we saw above might only keep a certain number of cached filters using a server-side LRU cache.

### Cache Storage

For web apps, there’s a whole spectrum of places where you might want to cache:

- Server Cache: server-side, sometimes private, cached data that persists between requests. Might be shared between servers using an external data store like Redis.
- Request Cache: cached data that persists for the duration of a request to avoid multiple fetches to the same resource and solving the n+1 problem in GraphQL servers. [Dataloader](https://github.com/graphql/dataloader) and [React.cache](https://react.dev/reference/react/cache) are both examples of request caches.
- CDN Cache, or Shared Cache: cached data that is replicated in datacenters across the world. The data might come from multiple servers and be consumed by multiple clients.  Shared caches can be instructed to cache HTTP responses using the `Cache-Control: s-maxage` directive.
- HTTP Cache: the browser version of Shared Caches. Also controlled using the `Cache-Control` header. There’s no real way to invalidate the HTTP Cache without the user specifically clearing it, so it’s good to be cautious with long expires times. It works especially well for static assets that don’t change frequently, like images, CSS files, or JavaScript. Often these assets have content hashes in their filenames, which treats them as new cache entries when the filename changes.
- Browser Cache: persistent storage within browsers that can be accessed through JavaScript and Service Workers. This includes the [Caches API](https://developer.mozilla.org/en-US/docs/Web/API/Cache), which service workers can use to replace responses to requests to support offline access, [IndexedDB](https://web.dev/articles/indexeddb) for persistent storage, or in-memory caches like [TanStack Query](https://tanstack.com/query/latest) that are cleared when the page is closed or refreshed.

Each of these has different uses, capabilities and limitations. They can be used individually, or together within the same app to speed it up. Naturally you don’t have to use all of them at the same time. 

As a rule of thumb, start with HTTP caching followed by Server Caching. Those two will provide the biggest speed improvements with relatively low effort.

---

Hopefully this helps clear up some of the basics of caching. In the future we hope to have a whole series of blog posts going into the intricacies of each of these caching strategies. Until then, may your data be fresh and your caches invalidate when you want them to.

*Alex is a senior software engineer at Echobind. [Follow him on X](https://twitter.com/ralex1993).*

---

[View on echobind.com](https://echobind.com/post/a-simple-start-to-caching)

---

# 2024: The Year of Products at Echobind

> Echobind is building new products in 2024 thanks to our new "labs" initiative. Introducing KindKiosk and Wayfound.

_By Chris Ball · 2024-03-06_

I’m excited to officially announce the start of something new for Echobind. We’re building and launching products!

## A long time coming

At some point, every agency (and for that matter every developer, designer, and product person) considers building their own products. Most of us have a side project graveyard full of half-baked ideas as proof.

I’ve talked about products at Echobind for *years*, and in 2024 we’re committing to it.

## Why?

Many reasons. As Echobind the company, we gain:

- new sources for potential leads
- additional credibility by showing what we’re capable of
- opportunity to diversify revenue
- a chance to own and continuously iterate on something

As Echobind the team, we:

- learn through building. We’ve built and shipped many products on behalf of our clients. Labs—our official entity name for working on these products—will be our space to continuously build, explore, and refine our own ideas.
- get an opportunity to wear different hats. Our engineers can work on product. Our designers can work on marketing. Our strategy team can do sales. It’s a great way to expand our individual skill sets. As a bonus, we gain a better understanding for what our coworkers go through on client projects!
- have a place to experiment with cutting-edge technology, like the **[Vision Pro](https://www.apple.com/apple-vision-pro/)** (more on that soon!)

Because the consulting side of Echobind covers salaries and expenses, Labs can focus entirely on product validation, execution, and generating revenue. That significantly reduces our risk, and provides an easier path to profitability. 

Speaking of profitability, we are treating Labs as a separate entity from Echobind. It’s all the same crew, but different revenue and expenses.

![](https://cms.echobind.com/assets/32654cb8-91eb-411c-bdb9-188524e10a96)

## 2024 Roadmap

- **Get Organized.** In February, we established the **PROduct Validation and Evaluation (PROVE)** team. PROVE exists to ensure all of our ideas keep moving, and is a cross-discipline group of product managers, designers, and developers. Anyone on the team can join the Friday PROVE huddle. During the huddle, we give overall Labs updates and product pitches. We talk about our approach and framework. It’s off to a great start.
- **Set Goals.** We will launch two products per quarter. That’s aggressive, but it’s also attainable. There’s no time to waste, which forces us to focus. There’s only one caveat: if any product gains significant traction, we may pause launches temporarily to direct energy appropriately. That would be a good problem to have.
- **Market, Analyze, and Grow.** Product marketing is an area we don’t often get to focus on at Echobind. We will now. All products and marketing sites will leverage [Posthog](https://posthog.com) at launch, and we’ll use that data to drive product decisions.
- **Review and Decide.** Each quarter we will review the performance of all products and decide on next steps. We will look for strong indicators of interest (or lack thereof), evaluate the effort we’ve put in, and read conversations with potential customers to understand how products are being used.

So with that, it’s time to unveil what we’re working on in Q1!

## Product Launch #1: Kind Kiosk

[Kind Kiosk](http://www.kindkiosk.com) is a standalone, customizable kiosk used to increase donations. With just a few taps, donors can give via card, Apple Pay, or Google Pay. In an age of QR codes and countless online donation pages, we’re focused on the in-person experience. Those magical moments at an event or physical space where donors are most likely to give.

![](https://cms.echobind.com/assets/56cdae8a-d35a-43bd-b641-0795830ba429)

*The donor experience can be customized to match your brand. The designation for donations, copy, and  “quick donate” buttons are all configurable.*

We’ve been working on Kind Kiosk with limited bandwidth for a while now. With the formation of Echobind Labs, we’re excited to say it will officially launch at the [Nonprofit Technology Conference](https://www.nten.org/gather/ntc) in Portland, OR on March 13th.

![](https://cms.echobind.com/assets/901aa4f0-bc4c-4b50-be59-c5dcb95f003d)

*The Nonprofit Technology Conference is the official launch for Kind Kiosk.*

Imagine a fundraising dinner, basketball game, museum, zoo, or animal shelter. How about a kiosk in the office that allows employees to give to a different charity each month? There are so many exciting possibilities. We can’t wait to see how it’s used.

![](https://cms.echobind.com/assets/2d419dc5-f098-4000-ade8-deee22d4c23d)

*The admin dashboard. Understand how each kiosk performs, and get a snapshot of your donations.*

Kind Kiosk has been a really fun product to build. It’s not a typical SaaS. It uses hardware. We’re taking a fully-managed “white glove” approach. Though the overall process feels familiar, there’s quite a bit that feels new. On a personal note, I’m really proud of this one.

If you’re interested in learning more, visit [kindkiosk.com](http://kindkiosk.com?utm_source=ebblog&utm_medium=web) or [book an intro call](https://savvycal.com/kindkiosk/intro) with us!

![](https://cms.echobind.com/assets/fee11815-b328-46d5-8150-db00c4a5ea92)

*Our launch stickers and a test run of branded packing tape. Packing up and shipping the kiosk hardware should be an interesting endeavor!*

---

## Product Launch #2: Wayfound

Our second product for Q1 is [Wayfound](https://wayfound.app/). We’ve used every roadmapping software available, but we always find ourselves defaulting to using Google Sheets. It’s easy. 

The problem with Sheets is that it’s not a great deliverable. We want to wow our clients at every step. So we set out to create something that’s almost as easy to use as Sheets, and looks beautiful in a proposal or as a final deliverable.

![](https://cms.echobind.com/assets/9c1ad41a-98c9-4d6b-9cfd-bf791ef52a1e)

*The Wayfound waitlist page. Yes the logo looks a little bit like React. We don’t care at this stage.*

We’ve also tried using [Shortcut](https://www.shortcut.com) and [Linear](https://linear.app) to generate a roadmap. As great as those tools are, they don’t work well for us in proposals or early deliverables, especially when on-the-fly edits are needed. Once a project is in the design or build phases and has tickets to work against, they work much better. 

Check out Wayfound ([https://wayfound.app](https://wayfound.app?utm_source=blog)) to learn more and join the waitlist. If your team might use a product like this, we’d love to [hear from you](mailto:hi@echobind.com).

## Closing out Q1

We have four weeks to finish the MVP for Wayfound. Q2 is just around the corner. The PROVE team has heard multiple product pitches, and we have more on the way each week. Look for a Q1 Labs recap post at the end of the month and more about our plans for Q2.

We’re excited to keep shipping!

*Chris Ball is Echobind’s CTO and CoFounder; [connect with him on LinkedIn](https://www.linkedin.com/in/chris-r-ball/) any time.*

---

[View on echobind.com](https://echobind.com/post/2024-the-year-of-products-at-echobind)

---

# Noise Reduction in Core Concept Conversations

> A breakdown by product manager Zack Marty about the types of "noise" that exist in his agency work, and how to approach it when it arises.

_By Zack Marty · 2024-03-05_

Noise is one of the many reasons that most office workers don’t have their offices located adjacent to a concert venue. Noise makes it hard to concentrate, it doesn’t add anything beneficial to our work, and it makes me wonder why anyone thought that the open-concept office space would be of any benefit to people who need to do any kind of deep work.

Noise, especially the kind that we can’t predict, has a way of making everything else more difficult. When we do tasks that require a bit of thinking, we often find ways to reduce the noise around us to aid in concentration. So when I talk about noise in reference to product management and software development, I am referring to all of the added stuff that doesn’t benefit the core conversation being had. Noise reduction applies to many industries, but today we will focus on product management and software development. 

### The added stuff

When we have conversations about how features will work, we typically use hypothetical scenarios to explore a given feature. This allows us to connect with the feature and talk it through in a way that gets us further away from the theoretical implementation and a little closer to how it will actually work. In the below example, one of our clients wanted to build a semi-social mobile application and had a specific way that they wanted the sorting algorithm to work on a user’s feed. The goal was to ensure that people received attention on their social posts rather than the way many apps currently work where the goal is to get social posts to snowball. Let’s take a look below at how their proposed solution would work.

![](https://cms.echobind.com/assets/60d8a236-b842-44ba-b8d0-eed54a483ba7)

### What makes this noisy?

This example is relatively simple since their proposed version of the sorting algorithm doesn’t take any sort of time decay into account. If a user’s social post receives ‘likes’ of some sort, then it gets thrown to the bottom of the pile. They are essentially punishing users for receiving attention on their social posts. It was not hard to convince our client that this would not be a good way to implement the sorting algorithm. So, where is the noise? The noise comes from the fact that the social posts themselves have absolutely nothing to do with the sorting algorithm. We don’t need to see that the first social post involved going to the mall or that the third social post shows the user doing a cartwheel. So how do we remove some of the noise?

![](https://cms.echobind.com/assets/7f988c9b-b4f6-4417-b6b5-43261c98c459)

In this version, we can easily show off the sorting algorithm without needing to show the contents of the social posts themselves. This is a great way to reduce noise. Rather than showing actual posts, we just have placeholders. Is there a way that we can reduce noise even further? Yes. In the above version, we create noise by using almost identical text. It takes a moment or two in order to identify and indicate to what you are referring. In more complex scenarios, talking about ‘social post 1’ vs ‘social post 2’ is surprisingly laborious and can confuse people when there are no major demarcations between the posts. While we reduced noise in one way, we also made more noise since it is easier to identify skirts and cartwheels than social post 1 and social post 2. 

### Why not just use numbers?

The next question that should arise is, “Why not just use numbers? One and two are distinct values.” The issue we create here is that there is a value and sequence cognitive load that accompanies numbers due to our long relationship with numbers as people. Again, it simultaneously reduces and increases noise. My suggestion is below:

![](https://cms.echobind.com/assets/a1437b31-3776-4237-89c7-8e17bda2163a)

In the above example, each of the placeholders for social posts are conceptually and visually distinct. When I first made this visualization, I used a panda where the crab is, but I replaced it with a crab so that it would be more conceptually distinct from the bear despite them both being visually distinct. There are plenty of other visuals that you can use to create distinct journeys for your audience to follow, but I like the animal images since they are typically known by the audience rather than something I might need to explain to someone. However, despite all of our concentration on visuals, the animals / social posts are not as important as the core concept to discuss, which is the sorting algorithm. The animal pictures just allow us to think about placeholders less than we think about our core concept. 

### Do you have other examples?

Of course, I would not have made the above title if I didn’t. In a discussion with a client, we need our client to help us understand the relationship between a few different people who would be using or connected to their software. For their crowdfunding platform, we needed to better understand the relationships between the different parties. Let’s start by dumping the explanation into a paragraph.

A campaign organizer can create a campaign for themselves or someone else. Each campaign has a beneficiary. That beneficiary is not always the person who receives the funds raised. When the client did all of this via human interaction and check writing, it wasn’t much of a problem. They had people behind each interaction. However, they wanted to make sure that there was a delineation between the beneficiary and the recipient, who could also be the organizer. They also needed a next of kin added in the event that the beneficiary / recipient could not accept the funds for one reason or another, and this all needed to be abundantly clear to the campaign organizer on the front end of the experience. So how did we visually represent this?

![](https://cms.echobind.com/assets/204ed6b8-c02b-4b64-9a48-1a3c8a38a403)

Organizing the information this way allows everyone involved to point to representations of the individuals rather than needing to use names that can get complicated quickly. When we first started to identify the individuals we said things like, “Okay let’s assume that Officer Santiago wanted to create a campaign for Sergeant Jones, but Sergeant Jones passed and we need to make sure that his spouse receives the money raised in the campaign…” While this first sentence is not terribly complicated, it quickly becomes complicated when you have to keep remembering names to keep individuals straight. By using ducks, dogs, cows, and bears, you make remembering each individual significantly easier, and you spend more time thinking about the core concept and the way it might need to be represented on the front end. On top of making discussions easier, it makes future knowledge transfers easy as well. If I show this to a designer later and talk through it, they will be able to easily understand the various relationships that need to be thought about to design an intuitive experience. 

### Conclusion

All of the visualization tools we use in a meeting or when presenting to others can be amazing when it comes to complex conversations and concepts. However, we need to be careful to not introduce noise into the process and make having these conversations more difficult. The more of our brain power that goes into discussing the core concept rather than all of the unimportant details that surround the core concept, the better. One word of warning is to make sure that when you start to hack and slash at the noise, you don't also cut out important details that aid in understanding. That can be just as detrimental as having too much noise.

*Work with Zack and all of his talented visuals by [reaching out to us via our contact form](https://www.echobind.com/contact), or don't hesitate to write us an email at hi@echobind.com*

---

[View on echobind.com](https://echobind.com/post/noise-reduction-in-core-concept-conversations)

---

# The Undeniable Power of Microinteractions

> Microinteractions are highly prioritized at Echobind both in design and in development. Software needs to connect with its users at a deeper level.

_By Eloisa Docton · 2024-03-01_

Today, over half of all businesses have apps, offering extensive reach to connect with their customers. It's crucial to ensure that these connections are as meaningful and helpful as a client contacting someone within your business.

At Echobind, we prioritize the end-user in everything we do. Our process focuses on identifying the best path towards your business goals by solving problems for your users, often leveraging microinteractions to achieve this.

And in our minds, these are *impossible* to just skip over.

![](https://cms.echobind.com/assets/3fbf414a-a159-43ae-a701-5e41c89f9c73)

*Credit: Abdul Latif*

## Microinteractions are everywhere, all the time

If you use apps like Amazon and Uber, you have experienced well-thought-out microinteractions, even if you didn't realize it. 

Microinteractions are the small, subtle moments within a user interface or product experience that contribute to overall user satisfaction. These interactions are brief, focused, and task-oriented, providing feedback, communicating status, or assisting users in specific actions.

From a design standpoint, microinteractions are crafted to enhance usability, engagement, and satisfaction. They encompass animations, sounds, visual changes, or other dynamic elements that respond to user input or system events. These details significantly impact user perception and interaction with a product or interface.

![](https://cms.echobind.com/assets/70bce39c-ce83-45b8-ab26-1dafbfbf1355)

*Credit: sitiotecno*

I like to compare the experience to the difference between using a GPS vs a paper map. With technology, you can get to your location faster, and probably safer because you can keep your attention on the road straight ahead.

Studies suggest that microinteractions can increase user interaction by 30%, contributing to enhanced engagement and interaction metrics. Here's how:

- **Enhanced User Experience (UX):** Microinteractions provide instant feedback, clear visual cues, and subtle animations, guiding users through the app interface for a seamless and enjoyable experience.

![](https://cms.echobind.com/assets/4575ae53-3c9f-4238-915a-b6b39a2ca770)

*Credit: alifia*

- **Increased User Engagement:** Users feel more engaged when encountering microinteractions that respond to their actions, encouraging exploration and interaction with the app.

![](https://cms.echobind.com/assets/83397eb4-2349-4241-81f0-d680018e754e)

*Credit: Sergei Tarasenko*

- **Improved Usability:** Well-designed microinteractions assist users in completing tasks efficiently, confirming selections, indicating progress, or providing error messages, thus enhancing usability and user-friendliness.

![](https://cms.echobind.com/assets/9f4f8bea-c28c-448e-917b-9fa0f0ce4a6e)

*Credit: Tre Ishak*

- **Emotional Connection:** Microinteractions evoke positive emotions and delight among users, creating memorable experiences that foster an emotional connection with the app. It makes them want to use it more and continue to open it again and again.

![](https://cms.echobind.com/assets/3966511b-0fd4-4591-8997-70fe0dd306d0)

*Credit: Dev Ashish Deval*

- **Faster Task Completion:** Microinteractions provide instant feedback, aiding users in navigating the app efficiently, leading to increased productivity and satisfaction.

![](https://cms.echobind.com/assets/0a15e208-69e3-4494-95b9-5366e1f5a790)

*Credit: KimTomasik*

https://echobind.com/post/the-undeniable-power-of-microinteractions Apps prioritizing user experience through thoughtful microinteractions retain users better and foster long-term loyalty.

![](https://cms.echobind.com/assets/e78506c2-4946-4ff5-a683-835463e7fff4)

*Credit: John Boe*

- **The Main Takeaway:** Investing in well-designed microinteractions enhances app success, creating meaningful and delightful experiences for users. 

![](https://cms.echobind.com/assets/ee0c7101-e920-4ff7-86d2-a4551b718c88)

*Credit: Abdul Latif*

## **We pride ourselves on this work**

Let us design the best experiences imaginable for you and your technology. Like we said, we want users of your software to feel like it was specifically created for them. Easy to use and just an overall joy to tap or click around.

Don’t hesitate to [reach out via our contact form](https://www.echobind.com/contact), or fire off an email to us at hi@echobind.com.

Happy microinteraction-ing!

---

[View on echobind.com](https://echobind.com/post/the-undeniable-power-of-microinteractions)

---

# Deep Dive Into Extending tsconfig.json

> Here's how to get your typescript code to conform to the same settings throughout the project, from senior software engineer Cully Larson.

_By Cully Larson · 2024-02-27_

You have a monorepo with a client app, an API, and some shared packages. You want your typescript code to conform to the same settings throughout the project. The easiest way to do that is to create a `tsconfig.json` file in the root project folder and then have each package extend it.

**packages/tsconfig.json**

```json
{
  "compilerOptions": {
    "strict": true,
    "moduleResolution": "Node16",
    "module": "Node16"
  }
}
```

**package/tools/tsconfig.json**

```json
{
  "extends": "../tsconfig.json",
  "compilerOptions": {
    "baseUrl": "./",
    "rootDir": "./src",
    "outDir": "dist"
  }
  "exclude": ["./dist", "./node_modules"]
}
```

This works great. However, you notice that all of your packages use the same `baseUrl`, `rootDir`, `outDir`, and `exclude`. So why not just put those in the base `tsconfig.json`?

**packages/tsconfig.json**

```json
{
  "compilerOptions": {
    "strict": true,
    "moduleResolution": "Node16",
    "module": "Node16",
    "baseUrl": "./",
    "rootDir": "./src",
    "outDir": "dist"
  },
  "exclude": ["./dist", "./node_modules"]
}
```

**package/tools/tsconfig.json**

```json
{
  "extends": "../tsconfig.json"
}
```

The problem is the paths in a `tsconfig.json` are relative to the folder that that specific `tsconfig.json` file is in, and not the `tsconfig.json` doing the extending. So in this example, all the paths in `packages/tsconfig.json` are relative to the `packages/` folder, even when `packages/tsconfig.json` is extended (i.e. extending doesn’t change the folder that paths are relative to). And it doesn’t matter if you put `./` in front of the path or not.

So, in our last example above, if we run `cd packages/tools && tsc --showConfig`, we’ll get:

```json
{
    "compilerOptions": {
        "strict": true,
        "moduleResolution": "node16",
        "module": "node16",
        "baseUrl": "..",
        "rootDir": "../src",
        "outDir": "../dist"
    },
    "files": [
        "./src/tool.ts"
    ],
    "exclude": [
        ".././dist",
        ".././node_modules"
    ]
}
```

See how the paths all point to the parent folder? They are not relative to the `packages/tools` folder. That means we always have to define `baseUrl`, `rootDir`, `outDir`, `include`, and `exclude` in the child `tsconfig.json` (the one that extends the base `tsconfig.json`).

## There’s more to `exclude`

That last sentence isn’t the whole story for `exclude`. You can actually define `exclude` in the base `tsconfig.json` if you use wildcards. To illustrate this, let’s look at an example with `allowJs: true` to highlight something:

**packages/tsconfig.json**

```json
{
  "compilerOptions": {
    "strict": true,
    "allowJs": true,
    "moduleResolution": "Node16",
    "module": "Node16"
  },
  "exclude": ["./dist", "./node_modules"]
}
```

**package/tools/tsconfig.json**

```json
{
  "extends": "../tsconfig.json",
  "compilerOptions": {
    "baseUrl": "./",
    "rootDir": "./",
    "outDir": "dist"
  }
}
```

Build the `tools` project (`tsc --build`), and then run `tsc --showConfig`:

```json
{
    "compilerOptions": {
        "strict": true,
        "allowJs": true,
        "moduleResolution": "node16",
        "module": "node16",
        "baseUrl": "./",
        "rootDir": "./src",
        "outDir": "./dist"
    },
    "files": [
        "./dist/src/tool.js",
        "./src/tool.ts"
    ],
    "exclude": [
        "../dist",
        "../node_modules"
    ]
}
```

See that `files` includes `dist/src/tool.js`? That file is not being excluded. However, if we use wildcards in the `exclude` property in the base config:

**packages/tsconfig.json**

```json
{
  "compilerOptions": {
    "strict": true,
    "allowJs": true,
    "moduleResolution": "Node16",
    "module": "Node16"
  },
  "exclude": ["**/dist", "**/node_modules"]
}
```

And run `tsc --showConfig` again:

```json
{
    "compilerOptions": {
        "strict": true,
        "allowJs": true,
        "moduleResolution": "node16",
        "module": "node16",
        "baseUrl": "./",
        "rootDir": "./src",
        "outDir": "./dist"
    },
    "files": [
        "./src/tool.ts"
    ],
    "exclude": [
        "../**/dist",
        "../**/node_modules"
    ]
}
```

Notice that `dist/src/tool.js` is no longer included. This is because the wildcard `**/dist` matches `packages/tools/dist` too, even though it’s relative to the `packages/` folder.

That means you can define `exclude` in the base config and have it affect the extending packages. You just have to use wildcards. You might still opt not to define `exclude` in the base `tsconfig.json` and force each package to define its own since will avoid potential issues if someone forgets a wildcard or a package has other folders that need to be excluded.

On a side note, you could use a single star (e.g. `*/dist`) too and it will work the same way.

## What about `include`?

`include` works the same way as `exclude`. However, the wildcard solution does not work in the base `tsconfig.json`. You’d think it wouldn’t work because it will match all the files in any folder named `src` in the project, but it’s weirder than that. For example, let’s say you have another project in `packages/api` with a file named `src/handler.ts`. If you then run `cd packages/client && tsc --showConfig`, you’ll get:

```json
{
    "compilerOptions": {
        "strict": true,
        "allowJs": true,
        "moduleResolution": "node16",
        "module": "node16",
        "baseUrl": "./",
        "rootDir": "./src",
        "outDir": "./dist"
    },
    "files": [
        "../api/src/handler.ts"
    ],
    "include": [
        "../**/src"
    ],
    "exclude": [
        "dist"
    ]
}
```

Your `client/src/tool.ts` file isn’t even in the list. That’s because `tsc` matches the first folder it finds named `src` and doesn’t keep looking. The `packages/api/src` folder is searched first and `tsc` doesn’t continue on to look at `packages/client/src`.

So you will have to define `include` in each of the child `tsconfig.json` files.

## Some other things

It’s worth noting that when you extend a `tsconfig.json`, the properties in `compilerOptions` are merged. And when both files define the same property, the child `tsconfig.json` wins. However, this is not the case with `include` and `exclude`. If you define them in the child `tsconfig.json`, that exact value will be used; it won’t be merged with the value from the base `tsconfig.json`.

We used a monorepo for these examples, but you could run into this situation in a single-project repo as well. For example, if you want to override `tsconfig.json` in a `tests/` folder or a folder with Storybook stories.

*Cully is a senior software engineer who you can [follow on X here](https://twitter.com/cullylarson). Feel free to reach out to us for any and all of your technology-building needs at hi@echobind.com. Or hit our [contact page](https://echobind.com/contact).*

---

[View on echobind.com](https://echobind.com/post/deep-dive-into-extending-tsconfig-json)

---

# The Unseen Value of Completing Side Projects

> We've all got side projects as software engineers. And they range in topic and intensity. Here's how Dennis Campos would categorize them.

_By Dennis Campos · 2024-02-22_

We all have them - the graveyards of side projects. These ventures linger in the shadows, often half-finished or untouched, reminiscent of relics in a forgotten tomb. Yet, within these endeavors lie hidden treasures, often overlooked and undervalued. This is particularly true for developers, though the insights here resonate across various professions.

## Provides diversification

Side projects serve as a sandbox for developing skills. They provide engineers with a unique platform to experiment with new technologies, methodologies, and concepts that they may or may not encounter in their day-to-day role. The exploration is not about learning a language or tool but about embracing a holistic approach to problem-solving, and creativity. You will adapt to more patterns and make connections to your work. 

## Fulfillment and Creative Outlet

Aside from professional benefits, side projects can serve as a creative outlet and provide a sense of personal achievement and fulfillment. They allow engineers to explore areas they are passionate about, independent of the constraints typically found in their primary job. Side projects also create space for self-expression, enabling engineers to bring their unique ideas to life, experiment without fear of failure, and cultivate a sense of pride in their individual accomplishments.

## Industry Trends

The tech industry is constantly evolving, making it challenging to keep up with current trends. Side projects provide a practical way to stay up-to-date with emerging technologies, ensuring that we remain relevant in our field. Showing other developers that you are actively involved in your craft, open to challenges, and constantly seeking knowledge can create a positive impression. This can foster collaboration and provide opportunities for learning.

## Conclusion

So, continue working on those side projects, even if you end up abandoning them in your GitHub graveyard.

I leave you with this [commitstrip](https://www.commitstrip.com/en/2014/11/25/west-side-project-story/?) image that captures the outlook of side projects.

![](https://cms.echobind.com/assets/ba84e0b8-11af-4ede-9d18-1273aa1e24a9)

Ready to bring your vision to life, no matter the scale? Let's collaborate to turn your ideas into reality. [Get in touch with us today](https://echobind.com/contact).

---

[View on echobind.com](https://echobind.com/post/the-unseen-value-of-completing-side-projects)

---

# Why Video Has Always Been The Key

> Content creator Sean Ely dives into his history and love of videography as well as why he's so thrilled to be doing marketing for you at Echobind.

_By Sean Ely · 2024-02-20_

Since 2009, all I’ve ever been excited to do is make videos.

I borrowed a friend’s camcorder and somehow won a [nationwide basketball trick shot contest](https://youtu.be/tPBNaJW9PXU?si=1JpkvEC_ucDWAhM0) with my college roommate during our senior year, where I shot and edited a montage of us making ridiculous baskets that we scripted. From that moment on, I was hooked.

Learning how to cut scenes together from trial and error in Windows Movie Maker was a high I’d never experienced before.

![](https://cms.echobind.com/assets/80cc99ae-ee32-406f-9b52-25914c8e3df7)

But for the last four years leading up to that day, I had been studying to be a print journalist. Not a video editor. I hustled down leads and treated the Associated Press Stylebook like the Bible. I interned in small newsrooms, freelanced at magazines and obsessed over my writing classes like Mozart treated sheet music. 

How did a few late nights of editing suddenly have me wanting to change the entire direction of my future? With videography, of course. Not basketball. I was a 5-foot-nothing kid who spent the semester eating Pasta Roni every meal.  I wasn’t exactly “league ready” despite the grand prize giant check that arrived to my apartment.

![](https://cms.echobind.com/assets/86bdb816-a564-490c-a13a-894925552038)

So I thought to myself, “What if I could combine video editing ***AND*** reporting into the perfect job?”

Upon graduation two months later, I clung to the field of “multimedia”, where I could meet people and tell their stories as a reporter both in writing, as well as on camera and in the editing room, putting it all together on newspapers’ websites as one complete package.

And for years, that’s what I did. At the root of it all, I realized why this “work” was so intriguing to me: Narrative.

No matter who or what I was interested in, I wanted to properly tell their story in an easily-digestible way, with a proper beginning, middle and end. I became addicted to taking a topic that not everyone was familiar with, and making it the most intriguing thing in their lives that day.

And a few years later, I added a third love to the mix: Marketing.

![](https://cms.echobind.com/assets/4729bbf9-9c0c-4ba0-8f51-95bef76b819c)

A friend passed along a job posting where a startup marketing company was paying four people across the country to wear a different company’s logo on their T-shirts every day of the week, and make a video that marketed their brand in a way never seen before. Write a script, film and edit the video, and upload it to the internet. Every day, for years.

Uh, did someone create this opportunity specifically for me?

The research and writing? Journalism. The cameras and editing software? Videography. The unique brand awareness and call-to-action mindset? Marketing. 

This is exactly what I was meant to do in my career. [So I made a video resume to stand out from everyone](https://youtu.be/6PSIRB5w-rk) and got the job.

## Fast forward a decade, and here we are today at Echobind

After having freelanced with Echobind for years—[helping this amazing agency tell their story](https://vimeo.com/774491346?share=copy)—I was fortunate enough to come aboard full time to do my favorite type of work every day.

Making videos and marketing strategies for companies that believe in technology and staying ahead of their competition…while telling *their* unique stories? Of course.

I get to research innovative brands top to bottom and provide my thoughts on how they can flourish best in their landscape. And it's work I'm ecstatic to provide *your* company if you work with us, alongside beginning to create informative, high-energy videos that summarize what you do best.

It can live on your homepage, be pinned to the top of your socials or work as an email marketing asset to show everyone what you’ve built. It accents your technology and overall design work beautifully.

**Remember**: There’s nothing like well-done visual communication. Whether it’s a studio movie or an eight-second TikTok, we are more enamored by video in 2024 than any other consumable medium.

Bringing together my love of video alongside focusing so passionately on your storyline and what makes you special is something I cannot wait to dive into with you.

![](https://cms.echobind.com/assets/7444238c-af95-4ce9-bc82-d9b39a56430f)

## A whopping 91% of people have watched an “explainer video” to better learn about a product or company

And 69% of consumers believe a product demo best assists them when making a purchase. Yet, only 47% of marketers have invested in these videos despite 88% of marketers “believing it’s important to their strategy.”

Since I've arrived at Echobind, we can now prioritize video content more than ever before.

I’m ecstatic to work this year alongside Echobind's wildly-talented engineers, product specialists and designers to give our clients the most well-rounded set of software imaginable, from how it looks to how it works.

If you're passionate about video and want to chat more, visit our [contact page](https://echobind.com/contact).

---

[View on echobind.com](https://echobind.com/post/why-video-has-always-been-the-key)

---

# NativeWind for Universal Styling in Expo

> NativeWind merges Tailwind CSS with React Native, streamlining dev for web & mobile. It features universal styling, precompiled styles, and enhances the developer experience with Expo.

_By Isaiah Grey · 2024-02-15_

In the quest for a unified and efficient development workflow across web and mobile platforms, NativeWind emerges as a transformative solution. By harnessing the power of Tailwind CSS, NativeWind offers React Native developers a universal style system that's precompiled, fast, and feature-rich. This blog post explores how NativeWind enables consistent styling experiences across platforms, enhances developer experience, and ensures code maintainability within the Expo framework.

### The Power of NativeWind in Cross-Platform Development

NativeWind's philosophy centers on providing a consistent styling experience, irrespective of the platform. It achieves this through several key features:

- **Universal Styling:** Adapts the best style system for each platform, ensuring your components look and perform optimally whether on the web or native.
- **Precompiled Styles:** Leverages Tailwind CSS's compiler to generate styles at build time, minimizing runtime overhead.
- **Fast Runtime:** A minimal runtime efficiently applies responsive styles without compromising performance.
- **Developer Experience:** Offers plugins for easy setup and enhanced intellisense support, improving the development workflow.
- **Rich Feature Set:** Supports dark mode, arbitrary classes, media queries, themes, custom values, and plugins, along with pseudo-classes like hover, focus, and active.

### Implementing Universal Styling with NativeWind

Let's demonstrate how to build a responsive, styled component using NativeWind within an Expo project. We'll focus on creating a component that benefits from NativeWind's universal style system, including responsive and UI state styles.

#### Setting Up Your Expo and NativeWind Environment

Ensure your development environment is set up with Expo and NativeWind. First, create a new Expo project if you haven't already:

```bash
expo init MyUniversalApp
cd MyUniversalApp
```

Then, follow NativeWind's installation instructions to integrate it into your project. This may involve adding NativeWind and its Babel plugin to your project dependencies and configuring your Babel setup to use NativeWind's plugin for style precompilation.

Follow the instructions in the [NativeWind documentation](https://www.nativewind.dev/quick-starts/expo) to set up NativeWind in your Expo project.

#### Creating a Responsive Component with NativeWind

With NativeWind, you write your components using Tailwind CSS classes directly in React Native code. NativeWind's Babel plugin and build-time processing ensure these styles are efficiently applied across platforms.

```jsx
import React from "react";
import { Text, View } from "react-native";

const ResponsiveCard = () => {
  return (
    <View className="flex-1 items-center justify-center bg-white dark:bg-gray-800 p-4">
      <Text className="text-slate-800 dark:text-slate-200">
        Responsive Styling with NativeWind
      </Text>
    </View>
  );
};

export default ResponsiveCard;
```

This component utilizes Tailwind's utility classes for styling, including responsive and dark mode variants. NativeWind ensures these styles are correctly applied whether your app runs on the web or a native platform.

### Best Practices for Using NativeWind in Expo Projects

- **Leverage Precompiled Styles:** Maximize build-time style generation to reduce runtime overhead and improve app performance.
- **Utilize Rich Styling Features:** Explore and use NativeWind's support for pseudo-classes, responsive design, and device state styles to create sophisticated UIs.
- **Focus on Developer Experience:** Take advantage of NativeWind's development plugins and intellisense support to streamline your workflow.

NativeWind represents a significant advancement in cross-platform development, offering a universal style system that brings the best of Tailwind CSS to React Native. By integrating NativeWind into Expo projects, developers can enjoy a consistent, efficient, and feature-rich styling experience across web and mobile platforms. Embrace NativeWind to elevate your cross-platform development to new heights.

### Bonus: Enhancing Cross-Platform Compatibility with `@expo/html-elements`

When building components that need to run smoothly across different platforms, including web projects outside of Expo, such as a Next.js app, [@expo/html-elements](https://www.npmjs.com/package/@expo/html-elements) comes as a savior. This package provides a suite of universal semantic HTML elements as React components, optimizing for SEO and accessibility while ensuring an optimal UI across iOS, Android, web, and desktop apps.

#### Why Use @expo/html-elements?

- **SEO and Accessibility Optimization:** Using `@expo/html-elements` enhances your website's SEO and makes your native apps more accessible to physically impaired users.
- **React-Native-Web Compatibility:** It takes full advantage of react-native-web accessibility rules whenever possible.
- **Universal Component Rendering:** For example, the `H1` component renders as `<h1 />` on the web, a `UILabel` on iOS, and a `TextView` on Android, all while accepting styles from the StyleSheet API.
- **TypeScript and Style Support:** Ensures full TypeScript support across platforms and allows using `href` on a Text element without additional patches.

#### Setting Up `@expo/html-elements`

To start using @expo/html-elements in your project, simply install the package:

```bash
yarn add @expo/html-elements
```

Then, import and use it in your components:

```jsx
import { H1 } from "@expo/html-elements";

const MyComponent = () => <H1>This is a header</H1>;

// This component will render as an H1 on the web and as a Text component in React Native with the appropriate attributes and styles.
// Web    => <h1 aria-level="1" dir="auto" role="heading">This is a header</h1>
// Native => <Text role="header" style={[Custom]}>This is a header</Text>
```

#### Supported Components

`@expo/html-elements` supports a wide range of HTML elements, providing a React component for each. Here are some of the supported elements:

- **Text Elements:** `H1`, `P`, `B`, `I`, and more, each rendering appropriately across platforms.
- **Layout Elements:** `Div`, `Header`, `Footer`, `Section`, `Nav`, and others, adapting to the correct semantic element on the web and View equivalents on native platforms.
- **List Elements:** `UL`, `LI`, offering the traditional list presentation.
- **Other Elements:** `A` for links, `Table` and its related components for tabular data, ensuring a consistent look and feel across devices.

For a full list of supported elements, refer to the [package documentation](https://www.npmjs.com/package/@expo/html-elements).

These components automatically adapt their rendering based on the platform, ensuring that you consistently use the correct semantic and accessible component for iOS, Android, and the web.

Integrating `@expo/html-elements` into your Expo project not only streamlines the development process across platforms but also ensures that your components are semantically correct, accessible, and SEO-friendly. This package bridges the gap between native and web development, allowing you to focus on crafting excellent user experiences while it handles the nuances of platform-specific rendering.

***Learn more about Echobind's [React Native capabilities](/services/react-native-app-development).*** 

### Resources

- [Expo Documentation](https://docs.expo.dev/)
- [React Native Documentation](https://reactnative.dev/docs/getting-started)
- [TailwindCSS](https://tailwindcss.com/)
- [NativeWind](https://www.nativewind.dev/)
- [Expo HTML Elements](https://www.npmjs.com/package/@expo/html-elements)

---

[View on echobind.com](https://echobind.com/post/native-wind-universal-styling-expo)

---

# Product Manager and Project Manager Roles Explained 

> Project managers and product managers work in tandem as a synchronous 1-2 punch to ensure your project's success. They are crucial in what we do at Echobind.

_By Claire Surma · 2024-02-13_

At Echobind, we're proud of our track record in creating exceptional web and mobile applications for a diverse range of clients, from nimble startups to Fortune 500 powerhouses. A key factor in our projects' success lies not just in the technical skill of our development and design teams, but also in the strategic and organizational direction of our Product and Project Managers. Yet, we sometimes encounter clients questioning the necessity of these roles in their projects. Let's explore what Product and Project Managers do, and how they work together to ensure project success.

## **Understanding the Roles**

![](https://cms.echobind.com/assets/7a007216-7bc5-4d75-b444-6abb4570febf)

### **Product Manager: The Visionary**

Product Managers at Echobind are the visionaries who ensure your project transcends being a mere fix to becoming a lasting solution to core user issues. By deeply understanding market needs, user expectations, and business goals, they set a clear, strategic direction for the product. This involves:

- **Defining the Product Vision:** Establishing a clear, strategic vision for the product and ensuring that every feature developed aligns with this vision and the user's needs. This includes identifying success metrics and crafting user flows that serve as the blueprint for your application.
- **Prioritization**: Deciding what features to build and in what order, to deliver maximum value to the users while aligning with business objectives.
- **Stakeholder Alignment:** Ensuring that all stakeholders, including clients, developers, and designers, are aligned with the product's goals and understand the roadmap.
- **User Feedback:** Incorporating user feedback into the development process to ensure the product meets market demands and user expectations.
- **User Acceptance Testing:** Managing client user acceptance testing, and ensuring the final product aligns perfectly with the initial vision for a seamless project handoff.

![](https://cms.echobind.com/assets/02c52ffa-a567-478e-96ac-7e05fcadfc88)

### **Project Manager: The Orchestrator**

Project Managers are the orchestrators, planning and executing the project to ensure timely delivery within scope and budget. They are your advocates, focusing on logistics, facilitating seamless team coordination, and managing risks so that your project stays on track. As your main point of contact, they ensure efficient resource allocation and clear communication across all project stages. Their duties include:

- **Project Planning:** Defining the project's scope, setting timelines, and allocating resources.
- **Team Coordination:** Facilitating communication between team members and ensuring that everyone has the information and tools they need to perform their tasks effectively.
- **Risk Management:** Identifying potential risks and developing mitigation strategies to keep the project on track with timelines and budget.
- **Quality Assurance:** Monitoring project feature development progress and making adjustments as needed to ensure the final product meets quality standards.

## **Why Both Roles Are Essential for Success**

While their focus areas differ, both Product Managers and Project Managers are essential for the success of a software development project. Here's why:

- **Strategic Alignment and Execution:** Product Managers ensure that the product being developed aligns with business goals and user needs, while Project Managers ensure that the project is executed efficiently and effectively. Bottom line, they help you build a better product.
- **Risk Reduction:** Sometimes clients are too involved in the nitty gritty details of a product to see the larger issues. Having both roles collaborate on a project helps identify and address risks from both a product and project standpoint, reducing potential project pitfalls.
- **Resource Optimization:** Product Managers and Project Managers work together to ensure that resources, including time, budget, and team skills, are allocated optimally to meet project objectives. Ultimately, this saves clients money, especially when a launch deadline is important.
- **Enhanced Communication:** These roles serve as vital communication hubs, ensuring that all stakeholders are informed and aligned throughout the project lifecycle.

Our strategy team's involvement in projects is not just an added service; it's a fundamental part of project success. The detailed involvement of our product and project managers in every phase of the project, from initial discovery workshops to post-launch retrospectives, ensures improved communication, efficiency, and a final product that truly delivers on its promise.

*To work with a dedicated strategy team on a project right here at Echobind, don’t hesitate to reach out to us at hi@echobind.com. And get ready to have all your ducks in a row to make the best product possible.*

---

[View on echobind.com](https://echobind.com/post/product-manager-and-project-manager-roles-explained)

---

# 5 Minute Redesigns: Improving Hierarchy in 2 Steps

> Efficiency at Echobind is a staple of our business, especially when it comes to incorporating smart design into our development work.

_By Kaila VanSumer · 2024-02-05_

At Echobind, we place a lot of importance on efficiency. This often means we’re trying to accomplish *a lot* with minimal resources. This mindset has a way of hyper-focusing our attention on the things that matter most so we can maximize the time and money we invest in projects.

This can be witnessed frequently in the collaboration between our engineering and design teams. Sometimes, projects are staffed with engineers but not with a dedicated designer. In these cases, our engineers will sometimes ask a designer to make suggestions about small improvements they can make to a screen without having to invest a lot of time.

Recently one of our engineers dropped this screen into our Slack and asked for a quick 80/20 analysis and design recommendations on how to improve it.

![](https://cms.echobind.com/assets/a0725809-3950-4d38-ad83-c77fdcb3ce5c)

The biggest problem with this screen is that there are three main elements that feel like they have equal amounts of visual weight even though they’re not all equal in importance. 

![](https://cms.echobind.com/assets/b2a6e244-0123-4519-9323-a7c58da57513)

This is a common challenge when designing UI, and for a screen like this it can be tackled with 2 simple steps:

1. Assign a priority to each element
2. Use ✨Design Magic✨ to give the right amount of visual weight to each element based on importance

When we’re finished, the screen should feel balanced, and the most important elements should attract the most attention while the least important should be present but not distract from the main thing.

## Step 1: Assign a Priority to Each Element

First, let’s assign a priority number to each of the 3 elements we identified previously.

![](https://cms.echobind.com/assets/3c41ab73-2f13-477b-93db-7969ef4ab41a)

For this screen, the most important element is the “Scan Barcode” section since that’s the main action most users are going to want to take on this screen.

The second is the “Scan a barcode to get started” section, which is actually a way for the user to manually enter a barcode number if they’re unable to scan the barcode for some reason.

The least important element is the welcome message and number of orders completed. The orders completed is a nice number to know, but it doesn’t need to take center-stage; it just needs to be somewhere on the screen where the user can find it if they need it.

## Step 2: Adjust Visual Weight Based on Priority

Now that we’ve identified what’s most important, let’s use some basic design principles to make adjustments to each element.

**Remove the Least Important Element from Center Stage**

The [Interaction Design Foundation](https://www.interaction-design.org/literature/topics/center-stage#:~:text=Center%20stage%20is%20a%20design,important%20when%20carrying%20out%20tasks.) defines center stage as ”a design pattern where the most important information, panel, window, or toolset appears prominently at the center of the user interface.” So one way we can de-emphasize the least important element is by removing it from the center.

Let’s put the welcome message and the orders completed text in a row at the top. We’ll also further de-emphasize the orders completed text by removing the container border, decreasing the font size, and making it lighter gray in color.

![](https://cms.echobind.com/assets/d342dcdf-4e6e-4284-9438-73f12f1e2a06)

**Make the Most Important Element Stand Out**

As it is, this design already does a decent job of making the “Scan Barcode” section stand out, but it’s still competing a lot with that chunky input and “Submit” button. Additionally, the microcopy doesn’t give the user any information about *why* they should scan a barcode.

We’re going to fix this using a couple different techniques. 

First, we can update the copy and add some secondary text that gives the user more context. We’ll make sure the header is large, dark, and bold while keeping the secondary text smaller, lighter, and regular weight. 

Next, we can put the “Scan Barcode” section in a white container and give it a subtle drop shadow to make it stand out from the background. We’ll also make the background a light gray color instead of white to further emphasize this separation.

![](https://cms.echobind.com/assets/8480ba51-8bc3-4f03-8438-0f954a09b9eb)

Nice! This is already looking much better. But as I mentioned before, that input and “Submit” button are still taking up quite a bit of space and competing with the main section.

**Compare Elements of Medium-Priority to Other Elements**

The biggest problem with the input and “Submit” button is that they’re too large compared to everything else on the screen. The help text is also too dark and doesn’t let the user know that the input is an alternative method to scanning, so we’ll fix that while we’re at it.

By updating the copy, making the text lighter, and decreasing the size of the input, now everything feels *just* right.

As a side note, placeholder text can be problematic for a number of reasons including not being readable by some screen readers, so I always recommend using a label and ditching placeholder text altogether. Adam Silver has a great [blog post](https://adamsilver.io/blog/the-problem-with-placeholders-and-what-to-do-instead/) on this if you’re interested in learning more.

![](https://cms.echobind.com/assets/f8c5cfde-8423-4736-94db-387e880ff689)

So there you have it! This redesign took me about five minutes, didn’t cost the engineer much time to implement, and had a big impact on the overall usability of the product.

---

[View on echobind.com](https://echobind.com/post/5-minute-redesigns-improving-hierarchy-in-2-steps)

---

# Lex Is Ready To Chat

> Account manager Lex Meola has returned from maternity leave and loading up her schedule to help take companies to the next level.

_By Echobind Staff · 2024-01-31_

Before we could even finish clapping for her, the incomparable Lex Meola was already diving right back into her workload. No surprises there whatsoever.

A huge congrats to our account manager who is officially back from maternity leave after the birth of her ridiculously-adorable daughter Aria. Don’t worry, we’re way ahead of you: Yes, she’s got pictures to share. Don't hesitate to ask. 

![](https://cms.echobind.com/assets/18ba2ed5-517a-4c7f-8ee1-dc4ef782f053)

Lex is queen bee around here when it comes to hiring and working with Echobind this year, and her schedule is now officially open for business. [Grab time with her](https://savvycal.com/lexmeola/dcf1e6ba) to chat about one (or all) of the following:

- How to create a digital strategy or accelerate your plans
- Dive deep into creative design work
- Integrate a new web application alongside your website
- ...or maybe you just want someone to hash out which trends your company should consider paying attention to this year in order to stand out

Lex is your gal.

She’s happy to chat about how we can work together to push your technology further this year. Feel free to [snag a time slot on her calendar](https://savvycal.com/lexmeola/dcf1e6ba), or email her directly at lex at echobind.com. 

We [can’t wait to chat with you](https://echobind.com/contact).

*Team Echobind*

---

[View on echobind.com](https://echobind.com/post/lex-is-ready-to-talk-to-you)

---

# Tips for dealing with time

> There are lots of ways to make mistakes when working with dates and times. Here are some quick tips to avoid those footguns.

_By Cully Larson · 2024-01-16_

It’s happened. You have to write some code that uses dates and times. You head to the bathroom to have a little cry in private only to realize a coworker was in there the whole time and now you have to explain yourself. Sorry, I lost my train of thought. You’re back from the bathroom, your coworker is back-channeling stories about your little cry, and you’re about to start writing date/time code.

If this is your first rodeo, or your second rodeo, or really it doesn’t matter how much rodeo experience you have, footguns await you (metaphorical footguns unless your code is being used in some kind of self-firing gun which is not a good idea, please stop working on that project). Here are some tips to help you avoid a few of those footguns. You’re still going to shoot yourself in the foot (again, likely metaphorically) because of timezones and daylight saving time, but hopefully these tips will reduce the number of shots to those precious piggies.

## Include units in your variable names

You have some variables that will hold periods of time. Maybe `timeout`, `retryTime`, `activationDelay`, etc. When you write the code, you’ll know what units of time those variables hold (e.g. seconds, milliseconds, days). But the next dev to come along, or your future self, won’t know. You’ll have to track down the code where the value is eventually used and hope that it gives some indication of the units. But it isn’t always that clear and either way it’s a waste of time tracking down that logic.

To avoid this, you should always include the units of time in your variable names. For example, `timeoutMs`, `timeoutSeconds`, `retryTimeMinutes`, `activationDelayDays`. That way it’s always clear what units of time those variables hold.

You may also be able to use something like branded types to guarantee units. Though that can add some complexity to your app that might not be necessary if you use good naming conventions.

## This is good for timestamps too

It’s worth noting that including units in your variable names is also very helpful with timestamps. Since milliseconds and seconds are both used for timestamps, it can be challenging to know which is used in a particular variable. Including the units in your timestamp variables names (even in your database field names) will clear up this ambiguity. For example, `createAtMs`, `modifiedAtSeconds`, etc.

## Include conversions in comments

You have some magic numbers in your code; something like:

```jsx
const activationDelaySeconds = 10800;
```

But how long is 10,800 seconds? Well, let’s leave a comment:

```jsx
const activationDelaySeconds = 10800; // 3 hours
```

You’ve probably seen comments like this before. The problem is, what if someone comes along and changes the value but forgets to change the comment:

```jsx
const activationDelaySeconds = 14400; // 3 hours
```

Unless you can recognize that 14,400 seconds is not 3 hours, you’ll never know that the comment is wrong. Whoever looks at this code will think the activation delay is 3 hours and very likely waste time figuring out why activation isn’t happening at the expected time.

Instead of just commenting the value with an easier-to-read format, include the entire conversion in the comment:

```jsx
const activationDelaySeconds = 10800; // 10800 seconds = 3 hours
```

That way if someone comes along and changes the value without changing the comment:

```jsx
const activationDelaySeconds = 14400; // 10800 seconds = 3 hours
```

It will be clear to whoever looks at it that 14,400 seconds is not 3 hours. It will also make it harder for the person who made the original change to forget to change the comment.

Some people use multiplication to make the value more clear:

```jsx
const activationDelaySeconds = 3 * 60 * 60;
```

This is more clear than a magic number, but it’s slightly harder to scan; you have to pause and perform the math at least a bit before understanding what the value is. It’s also error-prone. It’s easy to mess up the math and hard to notice it’s messed up. I would still leave a comment when using this method to indicate intent.

## Use variables for magic numbers

Another option for documenting magic numbers is to do something like this:

```jsx
const threeHoursInSeconds = 3 * 60 * 60;
const activationDelaySeconds = threeHoursInSeconds;
```

This is self-documenting and it’s unlikely someone will change the value of `threeHoursInSeconds` directly because then it won’t be “three hours.”

This isn’t necessarily better than leaving conversion comments. It’s just another option.

## Use UTC until you can’t

Working with timezones opens up an exotic variety of opportunities to make mistakes. The easiest way to narrow the surface area for those problems is to not deal with timezones until you absolutely have to. A simple way to do this is to keep your dates in the UTC timezone unless you’re displaying information to the user. At that point, convert it to the user’s local timezone.

This can be a challenge in Javascript because the input and output of the Date object are usually in the “local” timezone. To get around this, it’s often helpful to prefer timestamps over Date objects. Timestamps also have the benefit of being easily serialized and used by other programming languages.

## Remember daylight saving time

If you’re ever working with periods of time (comparing dates, scheduling events, etc), remember that daylight saving time exists.

If your date comparison is over a long enough period, you might lose or gain an hour to DST.

If you’re scheduling an event, there’s a chance the event could happen twice if DST falls back an hour, or never happen if DST springs forward an hour.

If you’re writing a unit test that deals with time, it might pass in October and fail in December because of DST.

DST does not start and end on the same dates each year. DST starts on the second Sunday in March at 2am and ends on the first Sunday in November at 2am. Remember that since the clock moves forward by an hour at the beginning of DST, the times between 2:00am and 2:59am never happen on that day (2am becomes 3am immediately). And because the clock moves back an hour at the end of DST, the times between 1:00am and 1:59am happen twice on that day (2am becomes 1am).

You may be able to completely avoid these issues by using dates/times in the UTC timezone.

## Be careful around boundaries

If you’re working with a date/time that might end up close to the boundary between one day and the next, be careful. It’s easy to be off by one hour, minute, second, and end up on the “wrong” side of that boundary. The problem with bugs like this is you might not notice it unless you’re testing at the exact right time. A couple of ways to help prevent issues around boundaries is to include unit tests for those boundary times, or to simply think, “How will this work if it runs at 23:59, just before midnight? Or at 0:01, just after midnight?”

## Conclusion

As we part company in this tenuously together journey, remember that you will shoot yourself in the foot around dates and times (please don’t build that self-firing gun), and in those moments of suffering it will be difficult to remember that you will have shot yourself in the foot far fewer times with all this togetherly garnered knowledge and so put all your effort into remembering because therein lies some simple hope for a bright side and what better thing to shove in the face of your gossipy coworker (a real Janet, a real Chad) than a bloody foot that very well could have been bloodier.

---

[View on echobind.com](https://echobind.com/post/tips-for-dealing-with-time)

---

# Elevate Your Remote Work Setup With These Staff Picks

> The Echobind staff shares their favorite, unique work-from-home items that help workday efficiency and put them in the best headspace every single day.

_By Sean Ely · 2023-12-12_

Since Echobind's inception, we've worked hard to gather the best people around. From software engineers, to project managers to product strategists, we cling to individuals who love quality work, push to challenge themselves to learn more and at the end of the day, are just [solid human beings](https://echobind.com/about) at their core.

The take 'em home to meet the parents kinda thing, ya know? Not that you would, that would be *extremely* random, but the sentiment remains. You could if you wanted, they're THAT well-rounded. Sorry, let's move on.

Also since our company's launch in 2015, we've been fully remote. The work-from-home craze? Uh, yeah, that's less of a craze and more of just another Monday. Which means, we know a thing or two about efficient, yet cozy home office setups.

I pinged our staff to pass along their favorite items that help make their individual workdays more enjoyable. Whether it's a piece of technology to level up their projects or even a blanket that keeps them cozy throughout the day, I wanted to hear about it all.

With the holidays coming up, there's no better time to have this list handy. You can buy for someone, or just snag an item for yourself. You earned it.

### The Echobind Staff Recommendations List:

![Steelcase leap v2 chair](https://cms.echobind.com/assets/4552009e-7bc0-49f7-91f2-10f8294f8920)

**The [Steelcase Leap V2](https://www.btod.com/steelcase-leap-v2) Office Chair**: *Pressure-free seat foam, customizable tilt and arm adjusters, wildly comfortable.*

Cully Larson and Brandon Richey agreed this is "the best office chair" they've used in their careers. Cully even said, "I had some lower back pain that basically went away after getting this chair."

It's currently 50% off on [btod.com's website](https://www.btod.com/steelcase-leap-v2), which is professionally refurbished to alleviate the pricetag.

![](https://cms.echobind.com/assets/c1a7546e-84d7-4dae-a098-3f8a90a272e6)

**Kinesis [Freestyle Edge RGB](https://gaming.kinesis-ergo.com/product/freestyle-edge/) Gaming Split Mechanical Keyboard**: *20-inch adjustable linking cable, one-handed gaming and ergonomic typing, RGB backlighting*

Matt Thompson said it "eases my shoulder, wrist and (overall) developer hunch."

And for those who want a more modest version and smaller pricetag, the [Freestyle2 version](https://www.amazon.com/Freestyle2-Ergonomic-Keyboard-Standard-Separation/dp/B00CMALD3E/ref=asc_df_B00CMALD3E/?tag=hyprod-20&linkCode=df0&hvadid=309776868400&hvpos=&hvnetw=g&hvrand=14758081964623279940&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9014169&hvtargid=pla-570218617643&mcid=41fdadf5fd8c34ccafa02de263bdc538&gclid=CjwKCAiA98WrBhAYEiwA2WvhOhHvbQ5Nw8pqvvS3eHIuZwwfk5oVYvo77uBvlrQxzS0VbkAjhn4V7xoC4kkQAvD_BwE&th=1) is available for half the price.

![](https://cms.echobind.com/assets/82565842-a0ff-437a-9451-f5a43a7a7ff1)

**Blender Bottle's [Koda Water Jug](https://www.blenderbottle.com/products/koda?variant=31536931045443)**: *74-ounce capacity, leakproof lid, carry handle, measurement markings* 

Alex Anderson swears by this beauty, not only for its design, but the fact he only has to refill it once to hit his daily water quota (because we're all sick of running and forth to the kitchen, let's be honest). And at $14.99, you can't beat the price for the quality of the bottle. 

![](https://cms.echobind.com/assets/9d275309-06cb-4937-819c-36aba3e3c179)

**[reMarkable 2](https://remarkable.com/store/remarkable-2) Paper Tablet**: *Writes like real paper, converts to a digital file.*

It's a digital tablet but it writes like real paper. And then converts it all to typed text. Oh, and the battery lasts two weeks. And it integrates with Google Workspace, too. "I take notes on that and import into Obsidian," said Brandon Richey.

![](https://cms.echobind.com/assets/87447174-0278-4048-8b15-01d19f224c64)

**Rigstne [Coffee Mug Warmer](https://www.amazon.com/Rigstne-Coffee-Mug-Warmer-Portable/dp/B0CDQ56N1P/ref=sr_1_5?crid=24HY4JNQTYXBJ&keywords=rhinestone%2Bcoffee%2Bmug%2Bwarmer&qid=1702400826&sprefix=rigstne%2Bcoffee%2Bmug%2Bwarmer%2Caps%2C113&sr=8-5&th=1)**: *Lightning-fast heat-up time, four temperature options, timer function* 

This thing heats up your beverage in less than 30 seconds and even can be used to help melt candle wax to release aroma in the room. "You just can't go wrong with a good mug warmer," said Brandon Richey. And for $25.99 and 100+ ratings over 4.5/5, we can see why a lot of people love it.

![](https://cms.echobind.com/assets/836d46e4-3aaa-4603-9d48-5d25cc63de8d)

**Selk'bag [Original Wearable Sleeping Bag](https://selkbagusa.com/)**: *Synthetic insulation, soft polyester shell, machine washable, crazy warm* 

Our own Cully Larson loves dropping this one in Slack. People buy one for camping, and then they use it all-year round. Also, if you want to work outside on your patio in the winter, or in an igloo you made with your kids, this comes in handy. Seriously, you could.

![](https://cms.echobind.com/assets/6b5e5b23-3542-4181-9e36-62dd8f06ae9a)

**Homemade desk with butcher block slab**: *Sleek, practical, lateral room for days*

And finally, we're so excited to show you Mariah Grey's desk setup which truly delivers on both aesthetics and functionality. "I like long deskspace set ups," said Mariah. If you were looking for the motivation to create a new desk setup, this is it going into 2024. So, so clean.

Have an item you swear by? [Feel free to fire ideas over to us on X](https://twitter.com/echobind) and keep the conversation going.

---

[View on echobind.com](https://echobind.com/post/elevate-your-remote-work-setup-with-these-staff-picks)

---

# Make Progress, Even When You’re Stuck

> The 15-Minute Rule is relatively straightforward: If you spend 15 minutes (or for the larger scoped problems, longer than estimated) on the same problem without making progress, stop and ask for help.

_By Mariah Grey · 2023-11-17_

Here at Echobind, we’re constantly approaching design, strategy, and engineering challenges that take quite a bit of time. Our goal is to work smarter, not harder to solve these issues. We recognize that working *******smarter******* is about finding the most efficient methods and increasing effectiveness. When we do this, we’re better with our time. With that in mind, we live by the 15-minute rule. It’s a simple way for our team to ask for help and recognize the signs that it’s time to loop someone else in. 

### What is the 15-minute rule?

The 15-Minute Rule is relatively straightforward: If you spend 15 minutes (or for the larger scoped problems, longer than estimated) on the same problem without making progress, stop and ask for help. If help isn’t available, move on to something else and come back to the original problem when you can get another set of eyes. 

If you google the “15-Minute Rule,” you’ll find a variety of ways people apply it. For some, it’s similar to our approach — essentially preventing us from going down hours-long rabbit holes and spinning our wheels on a problem. For others, it’s to help limit procrastination. The spirit of the rule, however it’s applied, is time boxing. 

### Benefits of the 15-minute rule

Normally, getting another person to work with you helps reveal a better approach - perhaps one you didn’t know or see initially. 

Some of the challenges we handle require a lot of time and focus, but the fifteen-minute rule helps us recognize when we are spending *too* much time on a problem.

It can help with procrastination. Sometimes, that next ticket might seem daunting, but knowing that you can spend fifteen focused minutes on it before asking for help is the push you need.

### When to follow the 15-minute rule

The more time we spend trying to resolve an issue, the more likely we are to become fatigued and start making mistakes.  We may become more focused on the problem and less focused on the bigger picture. This leads to less creativity as we become trapped in a narrower way of thinking. Cue the ✨ 15-minute rule ✨. 

So, how do you know when it is time to ask for help?

1. You have been working on a problem for more time than estimated, with little progress.
2. You feel overwhelmed or blocked and can’t see a way forward.
3. You don’t yet have the experience in this area to solve the problem on your own.
4. The consequences of not solving this problem will impact your project. 

Knowing it’s the right time to ask for help is important for our professional growth and leads to better problem-solving skills in the future. The next time you find yourself stuck on a problem, reach out for help.

---

[View on echobind.com](https://echobind.com/post/make-progress-even-when-you-re-stuck)

---

# UX Best Practices for Designing Signup and Login Forms

> When you design any app, chances are good you’ll need to design signup and login screens. Here are some best practices for designing signup and login flows.

_By Kaila VanSumer · 2023-10-26_

## Introduction


When you design any app, chances are good you’ll need to design signup and login screens. Not only are these screens ubiquitous, they’re also some of the first screens new users will see when using your app, which makes them great places to invest in user experience. Here are a handful of best practices we follow at Echobind when designing signup and login flows for the apps and websites we design and develop.


## Signup


### Ask for as little information as possible


The biggest lever you can pull to improve the UX of your signup form is to only ask for information that is essential. It’s tempting to ask users for data that _might_ be useful, but this puts unnecessary burden on the user, erodes trust, and often decreases conversion rates. It helps if you pretend every field in your signup flow must justify its necessity. For each field ask yourself the following questions:

- How will these data be used?
- By whom?
- For what purpose?

If you (or your client) can’t come up with a specific and direct answer to all three of these questions for a field, then that field should not be added to the signup flow.


### Show password requirements as help text


Most apps will have requirements for passwords for security reasons. This includes things like minimum character counts, capitalization rules, and special character requirements. If your app has password requirements, it’s best to show these requirements to the user when and where they are relevant (i.e. as help text near the password form field).


If your app has simple password requirements that can fit on a single line, add that line below the label and above the form field.


![](https://cms.echobind.com/assets/9ee03254-c1f8-47ef-ab3e-7168231e830d)


If your app has multiple password requirements that can’t fit on a single line, add the requirements as bullet points directly below the form field.


![](https://cms.echobind.com/assets/591f6a20-d192-498d-a8b8-8be2d1d6a74c)


### Don’t make the user confirm their password, let them see their password


Instead of making the user confirm their password, give them the ability to show or hide it using an icon or text toggle. Making users confirm their password decreases conversion and causes more user corrections. In [one case study](https://www.zuko.io/blog/should-you-use-confirm-password-on-your-forms-and-websites-case-study), the authors were able to increase the conversion rate by 56.3% by removing the confirm password field. In [Why the Confirm Password Field Must Die](https://uxmovement.com/forms/why-the-confirm-password-field-must-die/), UX Movement had this to say about the case study:


> Once they removed the confirm password field and replaced it with an unmasking option, the number of user corrections decreased. Not only that, but it increased form starts, completions and the conversion rate.


Not bad ROI for such a simple change.


![](https://cms.echobind.com/assets/690afb07-bd58-47a8-890b-ead5f9b33230)


### Link to the login screen


For users who already have an account, make it easy to switch to the login screen by providing a link.


![](https://cms.echobind.com/assets/f13b8006-5fbe-4baf-923c-98a2dc86a39c)


### Validate once the user clicks submit instead of using live validation


As Adam Silver points out in his article [The Problem with Live Validation and What to Do Instead](https://adamsilver.io/blog/the-problem-with-live-validation-and-what-to-do-instead/), live validation can cause many problems for users including users not noticing errors as they appear (which sort of defeats the whole purpose of validation). Instead of live validation Adam recommends validating the form only once the user has clicked `Submit`. This allows the user to clearly see which fields need to be fixed and fix everything at once rather than switching between answering questions and fixing mistakes.


## Login

### Allow the user to recover their password and put the link somewhere near the password field

People forget passwords all the time. Your login form should make it easy for users to recover it. Put the `Forgot your password` link near the password field. I generally like to put it below the form field on the left for easy eye tracking.
![](https://cms.echobind.com/assets/bedaf889-37b5-4477-be3c-d43d2967c2f6)

### Allow for social login single sign-on (SSO)


Single sign-on using social accounts is a modern convenience that many users have come to expect. It’s easier than typing out your email and having to remember multiple passwords for different apps. It can also reduce failed login attempts.


To reduce cognitive load for users, we recommend adding no more than 3 social login options. According to the [State of Consumer Identity Trends 2023](https://www.loginradius.com/resource/consumer-digital-identity-trend-report-2023) report, Facebook and Google are the most popular social logins, so adding those is a good bet. You should only add a third option if you have evidence that the majority of your target audience uses another social platform more than Facebook or Google.

![](https://cms.echobind.com/assets/105bbb89-946d-4c0c-8554-29e7f28f0004)


### Allow for fingerprint authentication and FaceID when possible


Similar to SSO, fingerprint authentication and FaceID give users a convenient alternative to the standard login method. The [State of Consumer Identity Trends 2023](https://www.loginradius.com/resource/consumer-digital-identity-trend-report-2023) report found that passwordless login (e.g. magic links, fingerprint authentication, FaceID, etc.) had the highest user retention of any authentication method. If you have the time and budget, adding alternative login methods, such as social SSO and passwordless login, gives users control over their experience and can increase retention.


### Remember what the user has already typed


If a user enters incorrect login credentials, show an error message but do not remove the email and password they entered. The user should not have to re-type their email between password attempts, and the password they entered may just contain a typo that can be easily corrected. Similarly, if the user clicks `Forgot password`, the reset password screen should remember the email they entered on the login screen.


### Link to the signup screen


For users who don’t already have an account, make it easy to switch to the signup screen by providing a link.

![](https://cms.echobind.com/assets/a5503346-e028-43aa-a74e-a7160e9b1546)


## Other Tips


### Don’t use “sign up” and “sign in” together


Using terms for account creation and login that are too similar to each other, such as “sign up” and “sign in”, can be confusing for users. Instead, use terms that are distinct from each other.


Options include:

- Sign up / log in
- Register / log in
- Register / sign in
- Create account / log in
- Create account / sign in
- Join / log in
- Join / sign in

As a side note, “sign up” is the verb “signup” is the noun. Same for “log in” / “login”.


### Don’t autofocus the first form field


As Adam Silver points out in his article [The Problem with Automatically Focusing the First Input and What to Do Instead](https://adamsilver.io/blog/the-problem-with-automatically-focusing-the-first-input-and-what-to-do-instead/), autofocusing the first input leads to problems for keyboard use, screen readers, and on mobile. The simple solution is to put the user in control and let them focus the first input on their own.


If you have other tips or best practices you follow when designing signup and login forms, let us know [on Twitter](https://twitter.com/echobind).

---

[View on echobind.com](https://echobind.com/post/designing-signup-and-login-forms)

---

# Embedding Remix in Directus

> In this mad-science experiment, we combine the Directus CMS with the Remix framework in a single package that enjoys the features of both.

_By Alex Anderson · 2023-10-16_

Who’s ready for some mad science? 🧑‍🔬


[Directus](https://directus.io/) is a self-hosted, all-in-one CMS platform written in JavaScript. You hook it up to some SQL database, build a data model, and it gives you a REST and GraphQL API for getting your data. Plus it manages files, users, roles and permissions, automated workflows, simple analytics dashboards, and all kinds of other stuff. PLUS, if you want you can create extensions to give it even more capabilities!


[Remix](https://remix.run/) is a server-side framework that lets you create dynamic, server-side rendered apps with React and web platform primitives, like FormData, Request, and Response. It’s fast and powerful, but its most valuable feature is how easy it is to add great user experience to a site, like pending UI states, optimistic updates, and smooth error handling.


It’s trivial to use Directus with Remix - just point a [Remix loader](https://remix.run/docs/en/main/route/loader) at your Directus endpoint to get whatever data you need for a route. But you’ll still need to find a place to host two separate apps - one for Remix and one for Directus.


Wouldn’t it be nice if you could run both of them together?


## Peeking Inside Directus


Directus itself is built on top of some pretty common JavaScript libraries, like [Knex](https://knexjs.org/) for building database queries and [Vue](https://vuejs.org/) for building UIs. Incidentally, it also uses [Express](https://expressjs.com/) as its web server.


When you make what’s called an “endpoint extension”, Directus gives you an Express router which you can use to add custom endpoints to your Directus instance.


```javascript
// An example endpoint extension.
// You can access it at /greet/intro on your Directus instance
export default {
	id: 'greet',
	handler: (router) => {
		router.get('/intro', (req, res) => res.send('Nice to meet you.'));
	},
};
```


The Directus examples focus on using endpoint extensions to build local proxies to other services, like Stripe or Twilio. But endpoints don’t just have to be used for APIs. It’s a regular Express router, which means it can return whatever you want.


As it turns out, Remix happens to have an Express adapter, which converts its `req` and `res` into Web API `Request` and `Response` objects for Remix to consume. Handy.


…you see where I’m going with this.


## Mixing Oil and… Different Oil


The plan is to have one repository that includes our Remix app, our Directus instance, and a Directus extension to connect them.


To begin, we’ll create a basic Remix app with the `create-remix` CLI.


```javascript
npx create-remix@latest
```


Doesn’t matter what template you use, they should all work.


Next, let's make a new extension for Directus inside our Remix app folder. The purpose of this extension is to serve our static files and call the Remix request handler. We’ll use the handy extension SDK they provide:


```javascript
npx create-directus-extension@latest
```


We’ll choose “endpoint” as our extension type and it’ll scaffold a simple extension for us.


By default endpoint extensions make the route start with the name of the extension, but you can override that by passing in an “id” to the endpoint config, which becomes what it uses for the route.


 Now you might be wondering “Is Directus going to limit us to only have our app run at some sub-URL?” Funny enough, no. If you pass an empty string for the ID of your endpoint, your endpoint now lives at the top of the route tree and your Remix app can handle any request coming into the server (aside from those specifically handled by Directus, like `/admin` or `/assets`.


> I imagine this is an oversight on the part of Directus - an unintended behavior. If they ever patch it so this doesn’t work (which I hope they don’t), you will have to host your Remix app at a specific sub-route. The [`publicPath`](https://remix.run/docs/en/main/file-conventions/remix-config#publicpath) Remix config will be helpful in this case.


First things first, let’s serve our static assets. The `serve-static`is a handy way to do that. It will automatically find our files, apply caching headers, and pass on the request if a file isn’t found. Install it in your extension folder with NPM.


```text
npm install serve-static
```


 Now add handlers for the `public` and `public/build` folders. For file paths, we’re assuming that Directus is being run from the root of the Remix project, which is how we’ll set it up in a minute.


```javascript
import { defineEndpoint } from "@directus/extensions-sdk";
import serveStatic from "serve-static";
import * as path from "node:path";

const __dirname = process.cwd();

const serve = serveStatic(path.resolve(__dirname, "public"), {
  maxAge: "1h",
});
// Built files have hashed filenames, so they can be cached forever.
const serveBuild = serveStatic(path.resolve(__dirname, "public/build"), {
  maxAge: "1y",
  immutable: true,
});

export default defineEndpoint({
  id: "",
  handler:(router, context) => {
		router.all("*", (req, res, next) => {
	    // Handling for Directus URLs
	    if (req.url.startsWith("/auth/login") || req.url.startsWith("/admin")) {
	      return next();
	    }
	    serveBuild(req, res, () => {
	      serve(req, res, () => {
					next();
	      });
	    });
	  });
  },
});
```


> There might be better ways to do this than nesting `serve` inside `serveBuild`. Consider this implementation merely for illustrative purposes.


Then we need to create our request handler. We’ll need to import our built Remix server and pass it to the Express request handler. This includes creating a [`getLoadContext`](https://remix.run/docs/en/main/route/loader#context) function, which grabs some data from the `req` object and the Directus context and makes them available to our Remix loaders and actions.


```diff
+ import { createRequestHandler } from "@remix-run/express";
+ import * as url from "node:url";
import * as path from "node:path";
// ...

+ const BUILD_PATH = path.resolve("./build/index.js");
+ const BUILD_URL = url.pathToFileURL(BUILD_PATH).href;
+ let build = await import(BUILD_URL);

+function getLoadContext(context) {
+  return (req: any) => {
+    return {
+      ...context,
+      schema: req.schema,
+      accountability: req.accountability,
+    };
+  };
+}

export default defineEndpoint({
  id: "",
  handler:(router, context) => {
+		const request handler = createRequestHandler({
+			build,
+			getLoadContext: getLoadContext(context),
+       });
		router.all("*", (req, res, next) => {
	    // Handling for Directus URLs
	    if (req.url.startsWith("/auth/login") || req.url.startsWith("/admin")) {
	      return next();
	    }
	    serveBuild(req, res, () => {
	      serve(req, res, () => {
+		    requestHandler(req, res, next);
	      });
	    });
	  });
  },
});

```


Congratulations! That’s our entire extension. We could add [a bit more code to handle live reload](https://remix.run/docs/en/main/guides/manual-mode) and file watching in development, but this is all we need at the moment as a minimum viable product.


We will need to get our un-built extension built and into the extensions folder… Except the extensions folder doesn’t exist yet! Directus will create one the first time we start it up. Let’s do that now.


Run `npx directus@latest init` and follow the prompt. If you’re just playing around with this, choose SQLite so you don’t have to set up a separate database. Once that’s done, Directus will create an empty extensions folder and a `.env` file.


Build your extension by running `npm run build` from within the extension folder. Then move the resulting `index.js` file to `/extensions/endpoints/{extension_name}/index.js` so Directus can pick it up.


You can configure where that `index.js` file ends up by adding some config to your extension’s `package.json` file. This should do the trick to automatically put it in our extension folder:


```text
// package.json
{
	"directus:extension": {
    "type": "endpoint",
    "path": "../extensions/endpoints/{extension_name}/index.js",
    "source": "src/index.ts",
    "host": "^10.1.11"
  }
}
```


We’ll also need to adjust our `.env` file a little bit by adding some things to the top.


```text
# Where to redirect to when navigating to /. Accepts a relative path, absolute URL, or false to disable ["./admin"]
ROOT_REDIRECT="false"
# Required for the Remix app to work
CONTENT_SECURITY_POLICY_DIRECTIVES__SCRIPT_SRC="array:'self','unsafe-inline','unsafe-eval'"
```


The first makes it so visiting `/` doesn’t automatically redirect to `/admin`. The second overrides some content security policy directives allowing the browser to execute some `<script>` tags inserted into the page by Remix.


## It Lives!


With that, we can run `npx directus@latest start` and see our app start up. We can know our extension has loaded if it appears in the first startup messages Directus prints, but we know for sure if we visit [`http://localhost:8055/`](http://localhost:8055/) and see our app come to life!


Then we can go to ``https://localhost:8055/login`` and log in to Directus to see the data studio. Nifty!


So what does this do for us? For starters, we get direct access to our Directus database and file store without having to jump through a bunch of extra hoops. For example, fetching a blog post looks like this:


```javascript
// /app/routes/post.$slug.tsx
export async function loader({context, params}) {
  const itemsService = new context.services.ItemsService("posts", {
    schema: context.schema as any,
    accountability: { admin: true, role: "" },
  });
	
	const [post] = await itemsService.readByQuery({
    limit: 1,
    filter: { slug: { _eq: params.slug }, status: { _eq: "published" } },
    fields: ["*"],
  });

  if (!post)
    throw new Response(null, {
      status: 404,
      statusText: "Not Found",
    });

  return { post };
}
```


This will save a tiny bit of time since our Remix app doesn’t have to send an HTTP request to get the data — it’s connected straight to the database through Directus.


> If we wanted, we could also directly access the Knex instance with `context.database`, or any of the other tools that Directus provides through the context.


How about loading images? We just point our image tags at `/assets/{image_id}` and Directus serves the image, regardless of where it’s stored (did you know Directus lets you [configure any number of image storage providers](https://docs.directus.io/self-hosted/config-options.html#file-storage), including any S3-compatible provider? Nifty!) Directus even has rudimentary image transformation built-in, so you can make sure each image is correctly sized and is in the right format so your pages load fast and you don’t have cumulative layout shift issues.


How about authentication? Using [`remix-auth`](https://github.com/sergiodxa/remix-auth)'s Form strategy and the Directus Authentication service, we can easily check an email and password against the Directus database.


```javascript
// This is the authenticator from remix-auth
authenticator.use(
  new FormStrategy(async ({ form, context }) => {
    let email = form.get("email")?.toString().toLowerCase();
    let password = form.get("password");

    const authService = new context.services.AuthenticationService({
      schema: context.schema,
      accountability: { admin:true, role: "" }
    });
    const usersService = new context.services.UsersService({
      schema: context.schema,
      accountability: { admin:true, role: "" }
    });
    
    const auth = await authService.login(undefined, { email, password });
    if (!auth) throw new Error("Invalid email or password");

		// Login was successful, find the user.
    const [user] = await usersService.readByQuery({
      filter: {
        email: { _eq: email },
      },
    });
    if (!user) throw new Error("Invalid email or password");
    return {
      id: user.id,
      email: user.email,
      avatar_url: user.avatar ? `/assets/${user.avatar}` : undefined,
    };
  }),
  "directus",
);
```


What about authorization? Directus already has a robust role-based access control system that we can take advantage of, using the Data Studio to create roles and assign them to users, and then checking the user’s assigned role.


All of this, plus the awesome Data Studio, plus everything Remix provides (great error handling, streaming responses, nested routes, etc.), all in one nice little package.


## What’s the Catch?


This might seem too good to be true, and you’d be right. There are definitely sharp edges here. I already mentioned how this takes advantage of a loophole in the endpoint extension API, which might be patched someday.


Also, the dev and build pipeline is a little clunky, since you have to run three processes to get everything up and running.


Another thing to consider: Directus only works with SQL databases and Node.js hosts, so don’t try deploying this to Cloudflare or something. Long-running servers only. Though it works great in hosts that support Docker or Nixpacks.


Directus does support horizontal scaling, and it should work just fine with this setup, but I’ve not confirmed it so _caveat emptor._


Finally, one disappointing aspect of Directus is that it doesn’t seem to support image CDNs, which means it’s serving every image from itself. That’s not terrible for small sites that don’t have to load instantly, but you’ll probably want to put it in front of a cloud CDN. Or better yet, create a little proxy route within Remix that automatically caches images to an image CDN when they’re first requested, and then pulls from the image CDN from that point on. There’s lots of opportunity here!


## Where Do I Sign Up?


If you want a pre-built template that includes all of this, [check out this example repo](https://github.com/alexanderson1993/examples/tree/directus-extension/directus-extension). Or you can just run this command:


```javascript
npx create-remix@latest ./my-app --template https://github.com/alexanderson1993/examples/tree/directus-extension/directus-extension
```


> Once my PR gets merged into the [Remix Community Examples repo](https://github.com/remix-run/examples) I’ll update this blog post to point there.


That repo includes all of the instructions, along with all the niceties you’d expect from a Remix app, like hot reloading and TypeScript.


Enjoy your new favorite hackathon stack!

---

[View on echobind.com](https://echobind.com/post/embedding-remix-in-directus)

---

# The Step-by-Step Guide to Conducting an App Critique

> This blog post explains the benefits of app critiques, emphasizing their speed, actionable insights, and suitability for resource-constrained projects.

_By Kaila VanSumer · 2023-10-09_

## What is an app critique?


An app critique is a professional review of the visual design, interaction design, and usability of an app or part of an app. It’s conducted by a professional UX designer or product designer.


An app critique is typically an activity used by interviewers to assess a product designer’s ability to assess apps, but app critiques aren’t just great for interviews. They can be used by freelance product designers or product designers at design and software agencies in their day-to-day job. App critiques can be done quickly and provide outsized value to clients because the end result is a list of actionable next steps that will improve their app.


## Why we love app critiques


App critiques are great because they’re:

- faster than some other UX methods
- give clients an actionable list that will improve their app immediately
- are a great place to start if a client doesn’t have the resources to invest in UX right now

### Faster Feedback


Conducting an app critique is fast because it only involves one product designer and one method of review. For something like a UX audit, another type of app review, the designer typically conducts stakeholder interviews, user research, competitive analyses, and a heuristic evaluation. Additionally, the final findings report takes a lot of time to write and can be lengthy to read. Full UX audits are valuable when you have the time and resources to dedicate to big redesigns. App critiques on the other hand are much faster and can be completed on tight timelines for less money.


### Actionable results


The end result of an app critique is a combination of a Figma file with annotated screenshots of the app along with a document outlining the steps one can take to have the biggest impact with a few key changes. Clients receive both detailed notes on the most noticeable problems along with actionable ways to fix them. Often larger audits have extra detail, and it can be unclear what to do next to improve the app.


### Great place to start


Any UX professional would recommend investing as much as you can afford into the user experience of your app, but we recognize sometimes resources are limited. Rather than leaving UX out of your product development altogether, conducting an app critique will give you a sense of what can be changed easily and immediately and what needs further consideration or research. Then you can make an informed decision about what to invest in and improve next.


While app critiques won’t uncover usability problems for complex interactions and they’re not as thorough as usability testing with real users, they’re a great way to identify visual or interaction patterns that don’t follow best practices. When conducted by an experienced product designer, app critiques highlight UX issues that are obvious to an expert but might be missed by stakeholders.


 Need a qualified UX professional to critique your app for you? [Get in touch](/contact)


## How we conduct app critiques at Echobind


At Echobind, we follow a simple, 4-step process for our app critiques. A critique can be completed by one designer, usually in a day or two.


### Step 1: Take screenshots


The first thing we do is ask our clients to identify the top 1 to 3 flows in their app that need the most attention. We then take screenshots of all the screens in those flows. Designers on our team use MacBooks, so we typically use the native screenshot capability, but you could also use a third-party screenshot software like [Monosnap](https://monosnap.com/).


### Step 2: Add screenshots to Figma


After we’ve taken our screenshots we create a Figma file for the critique and upload the images. You can learn how to upload images to Figma [here](https://help.figma.com/hc/en-us/articles/360040028034-Add-images-and-videos-to-design-files). We typically arrange all the screens for a given flow vertically in their own column. We have a unique column for each flow and label the columns accordingly.


### Step 3: Add feedback using Figma comments


Once we’ve uploaded and organized all our screenshots we start the critique. We go through the app screen by screen noting our thoughts using Figma’s commenting feature as we go. Typically we set aside a large chunk of time to put all our comments in at once. It’s easy to notice patterns and synthesize thoughts about the biggest problems this way.


![Here’s what a finished app critique looks like in Figma](https://cms.echobind.com/assets/2c362717-53a9-4481-8662-b94db823c2df)


### Step 4: Organize notes and recommendations in Notion


We add high-level notes and specific recommendations to a document in Notion. This document is more of a summary and synthesis of all the notes we made in Figma. We give the client both the Figma file and the document at the end. We use different outlines depending on the project, but here’s a good example of some of the areas we usually include:

	1. Overview
	2. Visual Design
	3. Interaction Design
	4. Layout
	5. Hierarchy
	6. Navigation
	7. Accessibility
	8. Bugs
	9. Nits

## Conclusion


App critiques are fast, simple to do, and can provide a lot of bang-for-the-buck design feedback for clients, especially when they’re not sure if they’re ready to invest in more in-depth UX and design for their product. This makes app critiques ideal for startups who need a UX professional to look over their app before they launch or for companies who’ve been around a while but have underinvested in design and want to improve their product quickly. If this sounds like you and your product could use a little design love, [say hey](/contact).

---

[View on echobind.com](https://echobind.com/post/conducting-an-app-critique)

---

# Stacked pull requests with squash merge

> How to use stacked pull requests with squash merge and avoid all the pitfalls.

_By Cully Larson · 2023-10-05_

[Stacked pull requests](https://blog.logrocket.com/using-stacked-pull-requests-in-github/) can be super useful. Even if you don’t know them by that name, you’ve probably used them (or wanted to use them). However, if you’re using stacked pull requests along with [squash merge](https://docs.gitlab.com/ee/user/project/merge_requests/squash_and_merge.html), there are some footguns you’ll want to avoid.

But first, what are stacked pull requests? A stacked PR is one that is based on another PR. Stacked PRs are useful if you ever open a PR and then want to work on another feature that uses code from the original PR, but you don't want to wait for a review/merge. You can branch off of the original PR and then, when you submit the new PR, base it on the original PR's branch. So let's say you do the following:

```bash
# start on your main branch
git checkout main
# create a new feature branch
git checkout -b feature-a
# make some changes
git add -A
git commit -m "feat: Feature A"
git push
# open your PR for feature-a
# start another feature branch, based on feature-a
git checkout -b feature-b
# (notice we branched off of the feature-a branch)
# make some changes
git add -A
git commit -m "feat: Feature B"
git push
# open a PR for feature-b. set the base branch in the PR to feature-a.
```

You’ll end up with a PR for `feature-a`, based on `main`, and another PR for `feature-b`, based on `feature-a`.

Once you’re at this point, and you plan to squash-merge your PRs, there are a few things to keep in mind:

## 1. Base your second PR on the first PR’s branch

When you create your second PR (for `feature-b` in our example) in Github, or whatever service you use, set the base branch to `feature-a`. If you set it to `main`, you’ll see all the changes from `feature-a` and `feature-b` in your diff.

## 2. Don't merge the second PR until the first PR is merged

Don't merge the second PR until the first PR is merged. If you do, it will merge *into* the first PR's branch (not `main`). Basically, your second PR will become a single commit on your first PR. This is almost certainly not what you want. Instead, mark the second PR as a "draft" until the first is merged to prevent it from being merged by mistake.

## 3. Squash merges don't preserve commit history

Squash merges don't preserve the commit history of your branch when it merges into `main`. It squashes all the commits into one commit on `main`. So once your `feature-a` branch is merged into `main`, git won't know that all those `feature-a` commits are now in `main` (just in one big commit). As a result, your `feature-b` PR will still have all those commits from `feature-b` in its commit history. Also, you won't necessarily be able to easily merge `main` into `feature-b` at this point.

To resolve this, if you want a clean commit history in your PRs, you'll have to do an interactive rebase and remove all of `feature-a`'s commits from `feature-b`:

```bash
# backup your project folder before doing this
git checkout main
git pull
git checkout feature-b
git rebase -i main
```

**WARNING**: Before doing this, make sure that `feature-b` is up-to-date with `feature-a` (it has all of `feature-a`'s commits). If you don’t do that, you’ll likely run into conflicts with your rebase. **You should not have any conflicts during this rebase.** If you do, it’s a sign that something was missed. Abort the rebase, resolve the issue causing the conflict, and try again. Don’t push forward with the rebase if there are conflicts.

## 4. There’s a process for pulling changes from `main`

While you have your stacked PRs open, if you want to pull some changes in from `main`, you should first merge `main` into `feature-a` and then merge `feature-a` into `feature-b`. *Do not* merge `main` into `feature-b`. Since `feature-b` is not based on `main`, it would mess up your git history and make your final merge of `feature-b` into `main` a pain.

To make this illustration more clear, let's say you have another feature that's based on `feature-b`. Let's call it `feature-c`. Your branch structure looks like this:

```
main -> feature-a -> feature-b -> feature-c
```

If you wanted to pull a change from `main` into these branches, you would:

```bash
# get the latest from main
git checkout main
git pull
# merge main into feature-a
git checkout feature-a
git pull
git merge main
# merge feature-a into feature-b
git checkout feature-b
git pull
git merge feature-a
# merge feature-b into feature-c
git checkout feature-c
git pull
git merge feature-b
```

---

[View on echobind.com](https://echobind.com/post/stacked-pull-requests-with-squash-merge)

---

# A case for ternaries in JSX

> Why you should use ternaries when rendering JSX.

_By Cully Larson · 2023-09-12_

Kent C. Dodds has a great article on why you should “[Use ternaries rather than && in JSX](https://kentcdodds.com/blog/use-ternaries-rather-than-and-and-in-jsx).” I paste a link to it whenever I see `condition && render` instead of ternaries in a PR review. But I sometimes get a quite valid response, saying that it isn’t a problem in the specific situation in the PR. `condition && render` is only really a problem when `condition` could be a number. For example:

```tsx
function Something() {
  const isValid = false;
  const name = "";
  const users = [];

  return (
    <>
      <div>Boolean: {isValid && "has boolean value"}</div>
      <div>String: {name && "has name value"}</div>
      <div>Number: {users.length && "has number value"}</div>
  )
}
```

In this example, no message will be displayed for “Boolean” and “String”. However, “Number” will show a message of `0` (see [Kent’s article](https://kentcdodds.com/blog/use-ternaries-rather-than-and-and-in-jsx) to find out why this happens).

So why can’t we use `condition && render` for booleans, strings, and any other truthy value, and just avoid it for numbers? That reasonable. It avoids the real issue. However, there’s another problem with this approach: when you’re doing a PR review, you have to pay close attention to every `condition && render` in the PR and figure out whether it will create the bug Kent describes.

The response I’m proposing in this article is that the cognitive load required to mentally parse all `condition && render` conditions in order to find out if they will accidentally render a `0` is a waste of time. **It’s easier to just never allow them and use ternaries instead**. You’ll never hit this bug, you’ll avoid annoying debates in your PR reviews, and you won’t need to figure out if a condition could reduce to `0`.

## What to do?

If you decide to get rid of `&&` rendering, how would you enforce that decision on a project? You could leave a link to this article whenever you see a `condition && render` in PR review, but that’s not fun and it creates an opportunity to rehash the decision.

Thankfully there’s a lint rule for this called [react/jsx-no-leaked-render](https://github.com/jsx-eslint/eslint-plugin-react/blob/master/docs/rules/jsx-no-leaked-render.md). Just install the [eslint-plugin-react](https://www.npmjs.com/package/eslint-plugin-react) plugin and add this to your ESLint config:

```json
{
  "react/jsx-no-leaked-render": ["error", { "validStrategies": ["ternary"] }]
}
```

There’s also a `coerce` strategy that forces you to coerce the `condition` to a boolean for it to be valid (or you can allow `coerce` and `ternary`, which is the default).

Whatever strategy you choose to support, this will guarantee your project will be free of risky `condition && render` statements and you’ll never need to have the `&&` vs. ternary conversation in your PR reviews ever again.

Note that, at the time of writing this article, the `react/jsx-no-leaked-render` rule is a little overeager in finding `&&` conditions in JSX. It will call out `&&` when setting props, not just when used for rendering. See this issue for details: https://github.com/jsx-eslint/eslint-plugin-react/issues/3292

---

[View on echobind.com](https://echobind.com/post/a-case-for-ternaries-in-jsx)

---

# Using SQL Server with Node on MacOS and Windows

> SQL Server isn't simple to access on MacOS and Window. Here's a function we use to make it easier.

_By Cully Larson · 2023-08-28_

We’ve had a few projects at Echobind where we needed to create a script that runs on a Windows server, accesses a Microsoft SQL Server database, and does some stuff with that data. All of our devs work on Macs and most of us know TS really well. So, we’d prefer to write complex scripts in TS and develop on MacOS.

Easy enough. Reach for the [mssql](https://www.npmjs.com/package/mssql) library and start working. That’ll go just fine during development. You might have a Microsoft SQL Server database running in Docker on your Mac, developing against some dummy data, and everything goes smoothly. But that innocent joy, that childlike season of wonder where you blow on the dandelions of summer and laugh as little seeds of code float effortlessly into the sunny blue sky of familiarity, will die when you start testing your script on a Windows machine and you will cry the salty tears of interoperability.

You can’t just `import mssql from 'mssql'` and go on using `mssql` on Windows. Windows has a special version of `mssql` that you need to import, `mssql/msnodesqlv8.js`. And does `mssql/msnodesqlv8.js` work on MacOS? No, of course it doesn’t! You can’t even import `mssql/msnodesqlv8.js` on MacOS! Why would you even ask that?

At this point, you’re left with a situation where you need to import one library on MacOS and another on Windows, and the one you import on Windows, you must never, under any circumstance, import on MacOS. And the weeping commences.

Well, dry those salty tears. We have cried them for you. Just copy/paste the snippet below:

```tsx
import mssql from 'mssql';

type MSSql = typeof mssql;

let _mssql: MSSql;

async function getMssql() {
  if (!_mssql) {
    // Windows
    if (isProduction()) {
      // The normal mssql lib doesn't work on Windows and even importing this
      // mssql/msnodesqlv8 library on MacOS will fail. So we have to conditionally
      // import it.
      _mssql = (await import('mssql/msnodesqlv8.js').then((m) => m.default)) as MSSql;
    }
    // MacOS (or whatever)
    else {
      _mssql = mssql;
    }
  }

 return _mssql;
}
```

This will import `mssql` on MacOS and Windows (that’s fine), but will only import `mssql/msnodesqlv8.js` in production (on Windows). The `getMssql` function will decide which version of `mssql` you need, cache it (so it doesn’t need to reimport on every call), and return it.

Thankfully, the rest of your application doesn’t need to know that this witchcraft occurred; `mssql` and `mssql/msnodesqlv8.js` have the same interface. `getMssql` is the scapegoat of your codebase. It suffers so the rest of your application can live on in peaceful ignorance of its sacrifice.

You can read the [mssql](https://www.npmjs.com/package/mssql) library docs for this, but here’s a short example of how you’d use `getMssql`:

```tsx
const mssql = await getMssql();

await mssql.connect(config);

const result = await mssql.query`select * from users where id = ${id}`;

const users = (results.recordset || []);
```

---

[View on echobind.com](https://echobind.com/post/using-sql-server-with-node-on-mac-os-and-windows)

---

# Ditch process.env, use a typed config

> Centralize your configuration and it make type-safe.

_By Cully Larson · 2023-08-14_

You have some values in your application that need to change depending on what environment or situation the app is used in. You decide to pass that configuration into your app using environment variables and access them using `process.env`. Great decision! Your app is portable, your configuration isn’t hard-coded, and you aren’t exposing secrets in your codebase.

But now you have a bunch of `process.env` references all over the place. Every dev on the team uses them in a different way. It’s hard to track what is even required to configure your app, let alone what those configuration values actually need to be. It’s the wild west.

There’s a better way! Centralize your configuration in one place and never look at a `process.env` again. This article will go over a configuration best-practice that has worked well at Echobind on a number of our projects.

## Centralize Configuration

Rather than having configuration spread all over your application, put it in one place. A simple version of that might look like:

```tsx
// config.ts
export const config = {
  stage: process.env.NODE_ENV,
	app: {
    port: process.env.APP_PORT,
  },
  db: {
    host: process.env.DB_HOST,
    username: process.env.DB_USERNAME,
    password: process.env.DB_PASSWORD,
    name: process.env.DB_NAME,
    port: process.env.DB_PORT,
  },
  cache: {
    lifetimeMs: process.env.CACHE_LIFETIME_MS,
  },
  features: {
    darkMode: {
      enabled: process.env.FEATURE_DARK_MODE_ENABLED,
    },
  },
};

export type Config = typeof config;
```

All your `process.env` access is in one file. It’s easy to see what you need to configure you application. And you get type safety for free!

Now whenever you want to use a config value, you can do:

```tsx
import { config } from "@/config";

if(config.features.darkMode.enabled) {
  // get dark
}
```

This is good, but it could be better. One problem with `process.env` values is that they are either `string` or `undefined`. You’ll constantly have to check whether a value is defined before using it. And what if you want a number or a boolean? What if you want to provide a default value if a value isn’t set?

## Coerce Configuration

To get our config values into a more useful form, let’s coerce them using some helpful functions:

```tsx
export function envToString(
  value: string | undefined,
  defaultValue?: string
): string | undefined {
  return value === undefined || value === "" ? defaultValue : value;
}

export function envToNumber(
  value: string | undefined,
  defaultValue?: number
): number | undefined {
  return value === undefined || value === "" ? defaultValue : Number(value);
}

export function envToBoolean(
  value: string | undefined,
  defaultValue?: boolean
): boolean | undefined {
  if (value === undefined || value === "") {
    return defaultValue;
  }

  // Explicitly test for true instead of false because we don't want to turn
  // something on by accident.
  return ["1", "true"].includes(value.trim().toLowerCase()) ? true : false;
}
```

Now we can use those functions to convert our config values into more usable types:

```tsx
export const config = {
  stage: envToString(process.env.NODE_ENV),
  app: {
    port: envToNumber(process.env.APP_PORT, 3000),
  },
  db: {
    host: envToString(process.env.DB_HOST),
    username: envToString(process.env.DB_USERNAME),
    password: envToString(process.env.DB_PASSWORD),
    name: envToString(process.env.DB_NAME),
    port: envToNumber(process.env.DB_PORT),
  },
  cache: {
    lifetimeMs: envToNumber(process.env.CACHE_LIFETIME_MS, 3600000), // 3600000ms = 1h
  },
  features: {
    darkMode: {
      enabled: envToBoolean(process.env.FEATURE_DARK_MODE_ENABLED),
    },
  },
};
```

Now our configuration values can be strings, booleans, or numbers. And we can provide default values if we want to set a field to something if no value is set in `process.env`. However, we have a couple more problems. First, our values could also be `undefined`. We could fix this with TS so that if a `defaultValue` is provided, the return value won’t be `undefined`.

Even with that change, we will still have a second problem: There is no validation of our config. If we’re missing a required value, a value is out of range, etc. our app will continue along with confidence.

## Validate Configuration

So let’s validate it! [Zod](https://zod.dev/) is a great tool for this. We’ll define a schema to make sure our configuration is correct:

```tsx
import { z } from "zod";

const configSchema = z.object({
  stage: z.string().nonempty(),
  app: z.object({
    port: z.number().positive(),
  }),
  db: z.object({
    host: z.string().nonempty(),
    username: z.string().nonempty(),
    password: z.string().nonempty(),
    name: z.string().nonempty(),
    port: z.number().positive(),
  }),
  cache: z.object({
    lifetimeMs: z.number().positive(),
  }),
  features: z.object({
    darkMode: z.object({
      enabled: z.boolean(),
    }),
  }),
});

export type Config = z.infer<typeof configSchema>;

export const config = configSchema.parse({
  stage: process.env.NODE_ENV,
  app: {
    port: envToNumber(process.env.APP_PORT, 3000),
  },
  db: {
    host: envToString(process.env.DB_HOST),
    username: envToString(process.env.DB_USERNAME),
    password: envToString(process.env.DB_PASSWORD),
    name: envToString(process.env.DB_NAME),
    port: envToNumber(process.env.DB_PORT),
  },
  cache: {
    lifetimeMs: envToNumber(process.env.CACHE_LIFETIME_MS, 3600000), // 3600000ms = 1h
  },
  features: {
    darkMode: {
      enabled: envToBoolean(process.env.FEATURE_DARK_MODE_ENABLED),
    },
  },
});
```

If our config is invalid, the schema check will throw an exception. If our application continues running past the check, we know our config is valid.

That checks all our boxes. Configuration is centralized, typed, and valid. Though there are still a few improvements we can make.

## How to handle “stage”

In our config, “stage” would be something like `production`, `staging`, `development`, `test`, etc. It basically tells us what environment our application is running in. This can be helpful if we want to do different things in our app based on the environment.

```tsx
export const stages = ["production", "staging", "development", "test"] as const;

export type Stage = (typeof stages)[number];

const configSchema = z.object({
  stage: z.enum(stages),
  // ...
});

export const config = configSchema.parse({
  stage: envToString(process.env.NODE_ENV, "development"),
  // ...
});
```

And some other helpful functions around stage:

```tsx
function notEmpty<TValue>(value: TValue | null | undefined): value is TValue {
  return value !== null && value !== undefined;
}

function getStage(stages: Stage[]): Stage {
  if (!stages.length) return 'development';

  for (const stage of stages) {
    // if any of the provided stages is not production,
    // assume we aren't in production
    if (stage !== 'production') {
      return stage;
    }
  }

  return stages[0];
}

function isStage(potentialStage: string): potentialStage is Stage {
  return stages.includes(potentialStage as Stage);
}

const stage = getStage(
  [process.env.NODE_ENV, process.env.NEXT_PUBLIC_APP_ENV].filter(notEmpty).filter(isStage)
);
```

## Fail earlier

One issue with the current configuration is that Typescript won’t tell us if it knows we’ve passed a bad value to our config. We won’t find that out until runtime. We can resolve this using `satisfies`:

```tsx
export const config = configSchema.parse({
  stage: envToString(process.env.NODE_ENV, "development"),
  app: {
    port: envToNumber(process.env.APP_PORT, 3000),
  },
  db: {
    host: envToString(process.env.DB_HOST),
    username: envToString(process.env.DB_USERNAME),
    password: envToString(process.env.DB_PASSWORD),
    name: envToString(process.env.DB_NAME),
    port: envToNumber(process.env.DB_PORT),
  },
  cache: {
    lifetimeMs: envToNumber(process.env.CACHE_LIFETIME_MS),
  },
  features: {
    darkMode: {
      enabled: envToBoolean(process.env.FEATURE_DARK_MODE_ENABLED),
    },
  },
} satisfies Config);
```

Notice the `satisfies Config` at the end of our config object. This will tell TS that the object needs to be of type `Config`. TS will then warn us if it knows one of our values isn’t correct. The downside here is that the return of the `envTo` functions can be `undefined`, so TS will complain about that. We could leave out the `satisfies` or always provide default values and update the `envTo` functions to not return `undefined` if a default value is provided:

```tsx
// overload envToString so we know what the return value will be if a default
// value is provided
function envToString(value: string | undefined, defaultValue: string): string;
function envToString(
  value: string | undefined,
  defaultValue?: undefined
): string | undefined;
function envToString(
  value: string | undefined,
  defaultValue?: string
): string | undefined {
  return value === undefined || value === "" ? defaultValue : value;
}

// overload envToNumber so we know what the return value will be if a default
// value is provided
function envToNumber(value: string | undefined, defaultValue: number): number;
function envToNumber(
  value: string | undefined,
  defaultValue?: undefined
): number | undefined;
function envToNumber(
  value: string | undefined,
  defaultValue?: number
): number | undefined {
  return value === undefined || value === "" ? defaultValue : Number(value);
}

// overload envToBoolean so we know what the return value will be if a default
// value is provided
function envToBoolean(
  value: string | undefined,
  defaultValue: boolean
): boolean;
function envToBoolean(
  value: string | undefined,
  defaultValue?: undefined
): boolean | undefined;
function envToBoolean(
  value: string | undefined,
  defaultValue?: boolean
): boolean | undefined {
  if (value === undefined || value === "") {
    return defaultValue;
  }

  // Explicitly test for true instead of false because we don't want to turn
  // something on by accident.
  return ["1", "true"].includes(value.trim().toLowerCase()) ? true : false;
}
```

Using these version of the `envTo` functions, if a default value is provided to e.g. `envToBoolean`, the return type will be `boolean`, not `boolean | undefined`. Forcing default values may not be the desired behavior if you want to initially allow `undefined` values to be set and then fail during the zod schema check.

## Putting it all together

Leaving out the `satisfies` example above, this is the result:

```tsx
import { z } from "zod";

function envToString(
  value: string | undefined,
  defaultValue?: string
): string | undefined {
  return value === undefined || value === "" ? defaultValue : value;
}

function envToNumber(
  value: string | undefined,
  defaultValue?: number
): number | undefined {
  return value === undefined || value === "" ? defaultValue : Number(value);
}

function envToBoolean(
  value: string | undefined,
  defaultValue?: boolean
): boolean | undefined {
  if (value === undefined || value === "") {
    return defaultValue;
  }

  // Explicitly test for true instead of false because we don't want to turn
  // something on by accident.
  return ["1", "true"].includes(value.trim().toLowerCase()) ? true : false;
}

const stages = ["production", "development", "test"] as const;

type Stage = (typeof stages)[number];

const configSchema = z.object({
  stage: z.enum(stages),
  app: z.object({
    port: z.number().positive(),
  }),
  db: z.object({
    host: z.string().nonempty(),
    username: z.string().nonempty(),
    password: z.string().nonempty(),
    name: z.string().nonempty(),
    port: z.number().positive(),
  }),
  cache: z.object({
    lifetimeMs: z.number().positive(),
  }),
  features: z.object({
    darkMode: z.object({
      enabled: z.boolean(),
    }),
  }),
});

export type Config = z.infer<typeof configSchema>;

export const config = configSchema.parse({
  stage: envToString(process.env.STAGE),
  app: {
    port: envToNumber(process.env.APP_PORT, 3000),
  },
  db: {
    host: envToString(process.env.DB_HOST),
    username: envToString(process.env.DB_USERNAME),
    password: envToString(process.env.DB_PASSWORD),
    name: envToString(process.env.DB_NAME),
    port: envToNumber(process.env.DB_PORT),
  },
  cache: {
    lifetimeMs: envToNumber(process.env.CACHE_LIFETIME_MS, 3600000), // 3600000ms = 1h
  },
  features: {
    darkMode: {
      enabled: envToBoolean(process.env.FEATURE_DARK_MODE_ENABLED),
    },
  },
});
```

## Why not use zod for everything?

Zod does have the ability to coerce values. But it’s not ideal, especially for booleans. And it probably doesn’t handle `undefined` like you want it to.

We could implement the `envTo` function using something like `preprocess`, but it’s messy.

In the end, we’ve found the `envTo` functions to be a simpler, cleaner, more predictable, and easier-to-understand solution than going with zod for everything.

## Conclusion

Why conclude? You don’t need me to tell you what you learned. In this article we went over the things you learned from reading it and we can rest assured you learned those things. Just copy/paste the “Putting it all together” code block.

---

[View on echobind.com](https://echobind.com/post/ditch-process-env-use-a-typed-config)

---

# RenderATL Microblog

> Mariah reports about all the awesome things she learned at RenderATL.

_By Mariah Grey · 2023-08-07_

After two years with Echobind, I finally took advantage of one of our perks — conference attendance. And goodness, what a place to be. RenderATL had it all - the tech content, the food, the music. Atlanta is a culture hub, and that was highly evident at RenderATL. The featured speakers came from diverse backgrounds and were clearly field experts. Their knowledge of All The Things™️ React and JavaScript related was inspiring. Let me share a handful of snippets from their talks, in case you missed my [Twitter](https://twitter.com/echobind/status/1664398734736719872)[ takeover](https://twitter.com/echobind/status/1664398734736719872).


One of the features of RenderATL was a workshop on [Remix](https://remix.run/docs/en/main) fundamentals. Since it was my first hands-on experience with Remix, it was great to learn the basics. Biggest takeaway: [pathless routing](https://remix.run/docs/en/main/guides/routing#pathless-layout-routes).


The remaining days were talk-centric. Development talks covered:

- Generative AI and the tools that utilize it in our industry such as code generation tools (like [CoPilot](https://github.com/features/copilot), more on that later!) and 3D printers.
- Using transitions to take React apps to the next level with [React 3 Fiber](https://docs.pmnd.rs/react-three-fiber/getting-started/introduction), [Framer Motion](https://www.framer.com/motion/), and [React-Spring](https://www.react-spring.dev/).
- Web development on the bleeding edge, where I learned about utilizing [Vercel](https://vercel.com/) and edge workers along with pinning, which allows you to prevent (most) latency 🤯.
- Thinking like a hacker, and the easiest ways to avoid those attacks. Using security tools and integrating manual security checks into your workflows, along with regularly (but not too often) updating your dependencies.
- When testing AI, ensure that you are defining the capabilities you want to test for and make sure to test for biases. Sometimes, no AI is the right answer.
- The new stuff in CSS land was mind-boggling: Things like [OKLCH](https://developer.mozilla.org/en-US/docs/Web/CSS/color_value/oklch), [View transitions](https://developer.mozilla.org/en-US/docs/Web/API/View_Transitions_API), and [Container query units.](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_container_queries) Check them out.
- Becoming a [CoPilot](https://github.com/features/copilot) super user —Try writing high-level task descriptions, iterate on solutions, and keep relevant files open in the editor.
- The importance of mental models and how words matter: if a problem feels complicated, make it a human problem before you code it. Simplify where you can, to form a point of reference and understanding.
- Strategies for debugging the hard stuff: when you're in the weeds of bug hunting, slow down, take a break, and console.log will be your best friend.
- [SSR with Suspense in React 18!](https://www.telerik.com/blogs/suspense-server-react-18) It allows us to create a much smoother user experience with the fallbacks that suspense allows.
- Thinking across the framework barriers! Celebrating the diversity of frameworks and using the best parts of each to build framework-agnostic tools.

Not every talk at RenderATL was development focused, and there were plenty of chances to hear more about becoming a better manager (with some stellar info for devs moving toward that path):

- Being intentional about aspects of leadership such as giving feedback, encouraging ambitions, and knowing the mindset and impact goals of the person you’re supporting.
- Developer relations and how to encourage active communication, community contribution, and being your authentic self within the welcoming culture they’ve created (Echobind uses all of the suggested strategies ✨).
- Once you make that leap from dev work into managing, how to reflect on the type of manager you want to be (or NOT be), what your triggers are, and choosing when to be flexible versus when to be rigid.

The final talk focused on what’s next in web development and was prefaced with "You're going to hate this".  It might be true since he was predicting a shift toward no-code solutions. As developers, we have the opportunity to either learn new tools or build better ones. Here's to the future!

---

[View on echobind.com](https://echobind.com/post/whats-up-renderatl)

---

# React Server Components Tips

> React Server Components change the mental model for building apps in React. Use these tips to unlock their powerful capabilities.

_By Alex Anderson · 2023-07-17_

It’s here - the official data fetching solution for React is React Server Components. They do come with a bunch of caveats: 

- RSC requires deep bundler integration, so you’re best off using a framework like Next.js.
- RSC enforces strict component tree structures and module composition.
- When using RSC, any interactive code must be done in a special client component.

But they come with a bunch of benefits too:

- You can fetch data inside your components, and it Just Works™.
- You can avoid data fetching waterfalls that are common with client-side fetching.
- You can stream data using `<Suspense>` to speed up the initial page load.
- You can execute more code on the server without shipping it to the client, keeping bundle sizes smaller.

On the whole, I think RSC is worth it, but it does come with a new mental model. If you’re just getting started with them, here are some tips to help you build apps with RSC.


> As of writing, the only React Server Components implementation with any degree of adoption is Next.js App Router, which has its own conventions on top of Server Components. That said, this guide should still be applicable to any eventual Server Components implementation.


**Tip 1: Make More Components**


In the past, there weren’t really guidelines on how much stuff to put inside a component. Since it’s all “Just JavaScript”, and calling components is kinda like calling functions, you could put as many `<div>`, `data.map()`, and whatever else you want inside a component. React doesn’t care.


Except now it does. First you used `React.lazy` to separate components for code splitting. Now with RSC, client components have to be split out, not just into their own component but their own _file_. Any streaming data needs to be split into its own component and wrapped in `<Suspense>`.


Don’t resist. Don’t try to build everything in one component, or even in one file. As soon as you get an inkling that some markup or logic should be in its own component, don’t hesitate - just split it out


**Tip 2: Use Client Components Freely**


There’s a good deal of moaning over the fact that a lot of existing React libraries don’t work in RSC anymore. And while it’s true that they _can’t_ work in a server component, that doesn’t mean you can’t use them in a client component. After all, once you cross the `"use client"` barrier, it’s as if you weren’t using server components at all. And you can still render those client components inside server components and pass props to them.


Take React Query for example. The [official docs](https://tanstack.com/query/latest/docs/react/guides/ssr#using-the-app-directory-in-nextjs-13) even demonstrate a pattern where you create your query client in a client component and then render that at the top level of your server component, so the query context is available to the whole app. And while [you might not need React Query](https://tkdodo.eu/blog/you-might-not-need-react-query) or those other libraries with React Server Components, there’s nothing stopping you from using them just like you always have.


If you need interactivity, like event handlers, `useState`, `useRef`, or `useEffect`, don’t hesitate to break that component into its own file, and add `"use client"` to the top.

It is worth noting, though, that any component rendered inside the client component (eg. not passed in the children prop) will also be considered a client component, so not every client component needs `"use client"`. You can think of `"use client"` as an explicit boundary between server components and client components, the place where the components transition between the data fetching world and the interactive world.

> Another misconception about client components is that they can still be server-side rendered, just like pre-RSC components. Think of RSC + SSR in four phases: Render the RSCs, SSR the entire React app, send the app to the browser, hydrate the app. Using RSCs in your app only adds the first step; the other three are present in any SSR'd React app. 

But if you still need to do data fetching inside those client components, you’ll need to be thoughtful about how your components compose.


**Tip 3: Build Components for Composition**


![React Server Components Diagram](https://cms.echobind.com/assets/561ab1a0-10c8-4e98-abf4-f1412405a7bc)


This kind of diagram has been around ever since React Server Components were first announced at the end of 2020, but it’s incredibly misleading. It implies that client components can render server components and vice versa. In reality, only server components can render other server components; client components can’t. 


And that makes sense. Once a client component is rendered on the client, how does it execute that server code? Is the client magically able to make calls to the database? No, that’s silly. One of the immutable rules of RSC is that client components can’t render server components.


But there is a literal loophole in this: Using component composition, you can render a server component _on the server,_ but as a child of a client component. Just like you can pass server-fetched data as props from a server component to a client component, you can pass rendered server components _as props_ to client components too.


Here’s a trivial example:


```javascript
"use client";

export function LoaderButton({children}) {
  const formStatus = useFormStatus();

  return (
    <Button type="submit" variant="secondary">
      {formStatus?.pending ? <LoaderIcon className="animate-spin" /> : children}
    </Button>
  );
}
```


> Note that I am using server actions hooks and patterns in these examples, which as of writing are alpha status. The API and conventions will likely change, such as `useFormStatus` and passing a function to `<form action={likeAction}>`, but the principles I’m demonstrating are stable. 


You might look at this and say “So what? I write components with children all the time.” What’s special here is that I can pass a component that fetches data as the child of this button.


```javascript
// This is a server component
async function LikeCount({postId}) {
	const likes = await getLikeCount(postId)
    
    return <>{likes}</>
}

function LikeForm({postId, likeAction}) {
  return <form action={likeAction}>
    <LoaderButton><LikeCount postId={postId}/></LoaderButton>
  </form>
}
```


This works with any prop, not just children. In fact, you could have several props which all accept React elements, and each of them could render a different server component.


Again, the only caveat with this approach is that the server components have to be rendered by another server component, so you might end up doing multiple layers of passing children in your client components.


**Tip 4: Don’t Forget Shared Components**


Client components are easy to spot - just look for “use client” at the top of the file. 


Server components are a little trickier. The first component in a server component tree is always a server component, so you can follow the server component tree down until you run into a client component. And if you find an `async function MyComponent()` component, it’s most likely a server component.


But there’s a third flavor that is compatible with _both_ server components and client components. Shared Components neither fetch data nor have interactivity. They might have a bit of logic and render some markup, but that’s it. Because they’re so simple, they can be rendered in server components _and_ client components without issue. 


So even if a component isn’t fetching any data, there’s no need to slap a `"use client"` at the top of the file. In fact, you should only do that if the component is explicitly using client-only features - again, those features include event callbacks, `useState`, `useEffect`, `useRef` - the kind of things that kind of require a browser to run.


**Bonus Tip: Server Actions** 


As a counterpart to Server Components fetching data, the React team has introduced Server Actions for performing mutations. Think of Server Components as GET requests, and Server Actions as POST requests.


Server Actions are currently in alpha status, so don’t expect much documentation or stability. But if you decide to venture even further along the bleeding edge, here’s a tidbit about error handling.


For Server Components, all errors are handled by wrapping the component in an Error Boundary (which is a client component, by necessity) and declaratively displaying the error message there.


Server Actions, on the other hand, are more imperative, being fired through user interaction. So instead of just throwing errors and setting up messy error boundaries to handle them, just treat the errors as data and return them.

[This tweet from Dan Abramov](https://twitter.com/dan_abramov/status/1654336219919048704?s=20) suggests putting errors into React state (requiring that your [server actions are called from a client component](https://nextjs.org/docs/app/building-your-application/data-fetching/server-actions#usage-with-client-components)) and reveals that first-class support for this kind of situation will be included in React someday.


---


That’s all! If you can think of any other tips for using React Server Components, hit us up on Twitter.  

*Edit: Added a section about how `"use client"` isn't required for all client components, and how client components can still be server-side rendered. Thanks to Dan Abramov for the suggestion and feedback.*

---

[View on echobind.com](https://echobind.com/post/react-server-components-tips)

---

# Figma Navigation Prototype

> A step-by-step tutorial about prototyping an interactive navigation bar with states in Figma.

_By Lexi Namer · 2023-05-16_

![The different states of the final navigation bar including active, hover, and empty.](https://cms.echobind.com/assets/596eab18-17ca-498f-962d-1c66186c9d20)


Prototyping different navigation states is a crucial step in the design process. It helps visualize and test the different interactions that users will encounter in the app and helps our engineers understand what to build. At Echobind, we use [Figma](https://www.figma.com/) to design and prototype. Here is a short step-by-step tutorial about how to use components to quickly and easily design and prototype an interactive navigation bar with default, active, and hover states. 


### 1. Create a nav item and turn it into a component- this will be your “Default” state


![Right click on a designed navigation element and click “create component”](https://cms.echobind.com/assets/b1b7110f-c0e1-4d35-975e-5b0da0be5f15)

### 2. Add variants to the default nav item component for “Active” and “Hover”


![Create different variants of the initial navigation item components and label them as your different states such as hover or action](https://cms.echobind.com/assets/e016e536-d755-410b-a75f-190f811d98bf)

### 3. Style the different states however you would like them to appear


![Style each of the different states so they are visually different](https://cms.echobind.com/assets/b20db25f-fc35-4fb6-855a-727b051e838f)


### 4. From the Prototype tab, add “hover” interactions from the default and active variants to the hover variant


![Using Figma’s prototyping function, add an interaction from the default and active variants to the hover variant](https://cms.echobind.com/assets/6cbe9c52-1f7a-4f76-8b97-3a5b70b0f49f)


### 5. Repeat steps 1-4 for the button


![Do the same thing that you did in in previous steps for a CTA button](https://cms.echobind.com/assets/658dae98-548d-4f55-b515-93c41e702813)


### 6. Using your nav item and button components, design a header and turn it into another component


![Create a navigation component and add in the different nav items and button as a component](https://cms.echobind.com/assets/115aff90-6680-4697-8cd6-38ec94ca9239)


### 7. Set up your pages using the component header and change the property for each of the current page’s nav item to “Active”


![Set up all of the pages using the header component that you just created and change the property for each of the current page’s nav item to “active”](https://cms.echobind.com/assets/e3b80028-7e2e-4795-befb-1347733fce99)




### 8. From the Prototype tab, add “click” interactions from all of the nav items between the different pages.


![Prototype all of the pages so they connect to each other](https://cms.echobind.com/assets/97cb1837-53ce-4253-bf14-0835cd97453f)


### 9. You must do this between all of the pages that you want to link between (don’t forget the home page).


![Each of the nav items on each page must be connected individually](https://cms.echobind.com/assets/496f0bc9-f900-4e6a-bdbf-8afca8b5eb73)


### 10. Set the device size from the prototype tab, click the play button, and watch the magic happen!


![The different states of the final navigation bar including active, hover, and empty.](https://cms.echobind.com/assets/d4f1729c-13d3-4a1e-826c-4a04377fa004)

---

[View on echobind.com](https://echobind.com/post/figma-navigation-prototype)

---

# Satisfying TypeScript: How the 'Satisfies' Keyword Can Simplify Your Code

> This blog post discusses the benefits of using the 'satisfies' keyword in TypeScript to avoid issues with inferred types and improve code quality.

_By Dennis Campos · 2023-05-03_

It is satisfying… Ok, I admit that was a bad pun, but I couldn't resist! In this blog post, I want to discuss how great the `satisfies` keyword is for TypeScript and give you an idea of when to use it. This topic was inspired by [Matt Pocock](https://twitter.com/mattpocockuk). Note that the `satisfies` keyword is available in TypeScript version 4.9 and later.


When we define an object with properties, TypeScript can infer the types of those properties.


```typescript
const dogs = {
  breed: 'Labrador Retriever',
  age: 3,
  favoriteToys: ['squeaky ball', 'rope toy'],
  size: 'medium'
}
```


![](https://cms.echobind.com/assets/021c8f63-b373-4d65-94d1-a872a751779e)


If we let TypeScript infer types, we may run into issues such as misspelling a word like `breed` as `brede`.


One way to avoid this is by using a utility type:


```typescript
type DogToys = [string, string];

const dogs: Record<'breed' | 'size' | 'age' | 'favoriteToys', string | number | DogToys> = {
  breed: 'Labrador Retriever',
  age: 3,
  favoriteToys: ['squeaky ball', 'rope toy'],
  size: 'medium'
}
```


Now, if we misspell any word in our properties, TypeScript will alert us!


However, there is still an issue here. Attempting to access a property and convert it to something using a JavaScript method will result in an error.


```typescript
dogs.size.toUpperCase(); // throws an error
```


![](https://cms.echobind.com/assets/ff35e63c-9007-4603-ac21-44e13b5f8142)


TypeScript doesn't know whether it's supposed to be a string or a number. One way to fix this is by using a conditional statement.


```typescript
if(typeof dogs.size === 'string) {
	dogs.size.toUpperCase();
} // TS is happy.
```


However, this can become an issue as the app grows.


This is where the keyword `satisfies` comes in.


```typescript
type DogToys = [string, string];

const dogs = {
  breed: 'Labrador Retriever',
  age: 3,
  favoriteToys: ['squeaky ball', 'rope toy'],
  size: 'medium'
} satisfies Record<'breed' | 'size' | 'age' | 'favoriteToys', string | number | DogToys>
```


Now, when we hover over `dogs`, we can see the types for each property, and there is no risk of misspelling a word. Additionally, you can remove the conditional statement.


![](https://cms.echobind.com/assets/e1791c06-b8a2-46ca-893d-0ccb60a3ffc2)


```typescript
dogs.size.toUpperCase(); // TS is happy!
```


Let's explore how we can use this in a framework like Next.js.


```typescript
import { GetServerSideProps, InferGetServerSidePropsType } from 'next'

const getServerSideProps: GetServerSideProps = async (ctx) => {
  return {
    props: {
      session: true
    },
  }
}

type Props = InferGetServerSidePropsType<typeof getServerSideProps>
```


Our type Props gives us back the following:


```typescript
type Props = {
    [key: string]: any;
} 
```


By using the `satisfies` keyword, we can obtain the actual types of the props, as well as the types of `GetServerSideProps`.


```typescript
const getServerSideProps = (async (ctx) => {
  return {
    props: {
      session: true,
      db: 'prisma'
    },
  }
}) satisfies GetServerSideProps

type Props = InferGetServerSidePropsType<typeof getServerSideProps>
```


And we will receive this type: 


```typescript
type Props = {
    session: boolean;
    db: string;
}
```


TADA! I hope these examples help you see the value of using the `satisfies` keyword. It can be very satisfying to use!

---

[View on echobind.com](https://echobind.com/post/satisfying-typescript)

---

# Managing Migrations with Directus with Prisma

> Directus and Prisma work great together, so long as you can figure out how manage syncing data models between the two.

_By Alex Anderson · 2023-04-26_

Directus and Prisma are both powerful tools on their own. [Directus](https://directus.io) lets us model and store data with an easy-to-use interface. [Prisma](https://www.prisma.io) works on the other side of our data, with an ORM connected directly to our database for quick and easy access.


It sounds like a match made in heaven, no? But there are a few sharp edges around getting set up and running migrations that you’ll need to smooth out to use them together. 


### Why use Prisma with Directus?


Directus can power websites on its own. It includes both a REST and GraphQL API for accessing the data in its collections, and these might be good enough for your website. But if you’re worried about high traffic putting your Directus instance under heavy load, or if you plan to do complicated joins, having direct access to the underlying database is a huge win.


And that’s one of the best features of Directus - it’s only a layer on top of your database, and it leaves you the option of directly accessing your data when the need arises.


> Note that you only have direct database access if you are using Directus Enterprise or self-hosting your own Directus instance. 


Of course, the benefit of Prisma is how easily it allows you to access your data from within an app.


### Migrations Woes


One of Directus’ most useful features is its ability to directly update your database, adding new fields and tables as needed for your app.


And Prisma has a powerful migration engine which tracks which migrations have run so your database doesn’t go out of sync.


Unfortunately, these two methods for updating your database tables directly conflict with each other. Prisma migrations are so strict that if your Directus and Prisma models go out of sync at all, Prisma will insist that you reset your entire database. Ouch.


On the other hand, Directus is fickle about how all of its tables are set up and organized. The relationships and column types all have to be just right, something that’s hard to do when hand-writing a `prisma.schema` file. One column out of place and Directus refuses to work.


### What Works


In all my testing, I found it was best to let Directus be in charge of changing and editing the schemas, and have Prisma mirror the Directus generated database. Using the [Directus CLI](https://docs.directus.io/self-hosted/cli.html), a new project can be created with `directs bootstrap`. After you’ve created your database models using the Directus app, you can run `directus schema snapshot` to generate a snapshot file, which represents the current state of all of your models. The snapshot it creates can be committed to version control so you can apply it elsewhere with `directus schema apply`.


> Of course, this means only using Directus to edit your database models from a development environment, committing them to version control, and applying the schema as part of your production deploy process. To me, that seems much safer than editing production columns and tables willy-nilly.


On the Prisma side, you can sync up your `schema.prisma` simply by running `prisma db pull` and then generate your Prisma client with `prisma generate`. You can still take advantage of Prisma’s  database seed feature by running `prisma db seed` after the database has been set up, giving your new Directus instance some structured data to get started with. 


Sometimes it might be helpful to write your fields or table names in one way on Directus, but in another way in your app, like using PascalCase for your Directus tables, but snake_case in your app. 


[`@@map`](https://www.prisma.io/docs/concepts/components/prisma-client/working-with-prismaclient/use-custom-model-and-field-names#using-map-and-map-to-rename-fields-and-models-in-the-prisma-client-api)[ and ](https://www.prisma.io/docs/concepts/components/prisma-client/working-with-prismaclient/use-custom-model-and-field-names#using-map-and-map-to-rename-fields-and-models-in-the-prisma-client-api)[`@map`](https://www.prisma.io/docs/concepts/components/prisma-client/working-with-prismaclient/use-custom-model-and-field-names#using-map-and-map-to-rename-fields-and-models-in-the-prisma-client-api)[ and relation names](https://www.prisma.io/docs/concepts/components/prisma-client/working-with-prismaclient/use-custom-model-and-field-names#using-map-and-map-to-rename-fields-and-models-in-the-prisma-client-api) are your friend. Like the name implies, Prisma will automatically map the table and column names however you specify, and it will even try to keep those mappings in place when you run `prisma db pull`.  If you’re using VS Code with the Prisma extension, it becomes trivially easy when using the `F2` key (the “Rename Symbol” function). Running that automatically adds the appropriate directives to the model or field.


![](https://cms.echobind.com/assets/0be8a2d7-0279-4a11-88a2-f31c5e1bf9e6)


Once you’ve got your Prisma schema set up, it should be smooth sailing. Prisma will make sure your data matches the schema Directus expects, so any data you insert from your app will be available and editable as if you created it within Directus.

---

[View on echobind.com](https://echobind.com/post/managing-migrations-with-directus-and-prisma)

---

# Figma’s Beta Component Property Authoring Feature

> Stop the Figma file scavenger hunt with Figma's new component property authoring features. Learn how to expose nested instances and make quick changes to your art board components.

_By Jacob Galito · 2023-03-29_

### Surfacing Component Properties to the Art-board Level


You’re new to an existing client project that a fellow coworker has been working on for months. Here comes that all-too familiar thought: how was the Figma file built? You can feel your palms getting clammy. Thus begins your grueling journey to clicking around various art boards, components, chips, and sifting through the wall of meticulously-crafted colors, fonts, and various other patterns. 


I’m probably not alone in feeling that there’s got to be a better way of navigating a new-to-you Figma file in order to provide value to both your team and the client.


Gone are the days, not really but follow me for kicks, of needing to have your finger on the command and click on buttons, cards, and various other components on layouts in order to make quick changes. We’re probably all guilty of this; even in our own files. 


Figma released a feature that allows you to author component properties which allows you to expose nested instances. To put it plainly, you are now—if you have successfully set your components up—able to click on an art board and see more useful adjustable properties on the right panel of all components that exist inside of an art board.


I’ve recently created a template for Request for Proposals (RFPs) and will be using it here to help illustrate how to get started with authoring component properties; how to set up various properties of components; and then how to expose those properties at the highest level.


### How to Get Started with Authoring Component Properties

- Go to your account settings
- Select the account tab
- Find `Component Properties (Beta)`
- Turn on `Try new component property authoring features` toggle

![](https://cms.echobind.com/assets/05aa4e05-168f-4734-99d3-c1407c4519b9)


### Layout Planning — Page Layouts and Components


This section is merely to illustrate how you could be thinking of elements in your layout as components and how they might be used as a system even from the planning/wire frame phase. 


At this point, you should explore layouts by creating wire frames either in Figma or drawing—in this case, I drew out my wireframes. 


The layouts represented below aren’t all of the possible options for a product such as an RFP template but for the sake of making this a more bite-sized article I’ll just be providing some examples that was explored.

![](https://cms.echobind.com/assets/4e71c820-dd2c-4d08-9a53-e0197c934bdd)

![](https://cms.echobind.com/assets/0dd6ac75-9064-4c0e-90e8-7ef60f168f31)

![](https://cms.echobind.com/assets/a21341d9-7c04-458b-b777-cbcf093eaf71)

![](https://cms.echobind.com/assets/371c5227-7dfd-459b-b38e-ae06218baead)

![](https://cms.echobind.com/assets/21849ea5-3d4e-458f-9679-4715268d6f76)

From this layout exploration, you’ll notice that there are a lot of common aspects that are present such as treatment for light and dark as well as the anticipation for there being variants for components such as logos, symbols, header and body text, imagery and backgrounds. All of these take into account consideration for how versatile the template could be for contrast of foreground color and background color.


### [Cover page diagram](https://www.figma.com/file/LmoEIPiiKRnjtGllOktZRv/RFP-Template-Diagrams?node-id=1-2534&t=eItqPCUZF01w3SZV-4)


![](https://cms.echobind.com/assets/a2d23545-27ac-41ce-aa2d-a5f90502aca1)


Now, let’s fast forward to having all finalized layouts completed. At this point, we’ve created light and dark variants for all necessary components but we also need to take into account variants for background images, text, etc. that can be driven at the art-board level. How might we do this, you ask? 


### [Overview page diagram](https://www.figma.com/file/LmoEIPiiKRnjtGllOktZRv/RFP-Template-Diagrams?node-id=19-2962&t=eItqPCUZF01w3SZV-4)


![](https://cms.echobind.com/assets/4010ab32-4b49-4f03-960a-d7067b7a4c2a)


### How to Set Up Component Properties


In this component example, light and dark variants were created but the text layers haven’t been created as component properties yet. Component Properties are one of the keys to surfacing booleans, variants, instances, and text to the top level.


After having created the component for the eyebrow, we then need to target the text on the component so that we can nominate it as an editable property. 

- Click on the text layer
- Click on the `Content` button that is circled below
- Create a `Name` for the property and a `Value` for the default text
- Press `Create property` to confirm

![](https://cms.echobind.com/assets/acdec1c6-18aa-4b7e-bd39-ed1d098b1dbc)


![](https://cms.echobind.com/assets/06344338-5486-468d-b86b-79506749dad4)


![](https://cms.echobind.com/assets/40c0d4e9-073f-4250-a364-4a8ed26fc854)


Once this is done, we are then able to quickly edit the text on the right panel by clicking on any component instance of the eyebrow. Now that you have created the Label component property, let’s test how it’s working so far.


![](https://cms.echobind.com/assets/a6ba93b3-74ad-4ef9-b187-393a628b8589)


### How to Author Component Properties at the Highest Level


Depending on the need, you might have a container that holds multiple components and all of the contained components might all have properties that you’ll want to have authored. To do this, you’ll have to go to `Properties` and click the `+` button then you should see the `Expose properties from` **`Nested instances`** .  


_If you don’t see this option in the dropdown there aren’t any nested instances with component properties in the selected component or you’ve selected an instance vs the main component._


![](https://cms.echobind.com/assets/4cea86ae-d655-47a1-929b-3be143782e21)


![](https://cms.echobind.com/assets/9ef2534f-2fc9-4b85-b040-16f2a22554e6)


Now, at this point, we have nested components contained within a component that contains a series of other component instances as well—but still isn’t the final layout just yet. In order to allow these properties to move forward to the top, we will need to go back into the properties menu and select the nested properties that we would like to be exposed.


![](https://cms.echobind.com/assets/64c90475-6158-47c9-92fc-5a08e14fd478)


**Component Properties from Art Board Level**


Let’s review: we have created components that have properties and have been added to a parent component that contains other component instances that are all composed in a fashion to our liking. We now then need to add that top level component—let’s just call it the foreground component—and add it to a final layout that already contains our background image component.


At this point, these are the final steps you’ll need to take in order to expose your component properties:

- Add an instance of the foreground component to the final layout
- Click on the final layout component and expose the properties of the foreground component
- Create an instance of the final layout
- You are now able to see all of the exposed component properties

![](https://cms.echobind.com/assets/7f33d8a3-fb1e-47f3-a10c-62c57a0f108a)


These steps may all seem complicated and a bit nuanced, but I think that if the end result is eliminating having to remember how a Figma file is structured prior to being able to add value, this feature will help enable that.

---

[View on echobind.com](https://echobind.com/post/figmas-beta-component-property-authoring-feature)

---

# Data Validation and Error Handling Best Practices

> The goal of this article is to expand on some features of data validation and error handling that we have found helpful at Echobind.

_By Cully Larson · 2023-03-21_

The goal of this article is to expand on some features of data validation and error handling that we have found helpful at Echobind. It’s geared toward applications and APIs that are ultimately consumed by casual end users (i.e. people who aren’t developers). This isn’t an exhaustive list.

## Validate data and handle errors from the beginning

The simplest time to implement validation and error handling is at the beginning of a project. Plan how you want it to work before starting your project, and then devote some extra time to the first few features of the app to really get validation and error handling dialed in. These features will probably be copied/pasted into other features in the app down the road, so it pays to get them working the way you want early on.

## Helpful messaging

The users of your application are humans. Your messaging should reflect that. Error messages should:

- Use complete sentences.
- Explain what went wrong.
- Give the user a next step.

### Use complete sentences

![This form has two one-word error messages for its fields: “Required” and “Invalid.”](https://cms.echobind.com/assets/c750d1f2-e54f-48bf-b5f3-3a339fa1109d)

This example is common enough. You fill out a form, hit submit, and get some one-word error messages. Instead, use complete sentences:

![The “Required” error message has been replaced with “Please provide a name” and the “Invalid” error message has been replaced with “Please provide a valid email address.”](https://cms.echobind.com/assets/20da5961-43e6-455b-aa63-cedd93b6ab56)

### Explain what went wrong

If a user encounters an error state in your application, it isn’t enough for them to know _that_ something went wrong. Without information about _what_ the problem is, they won’t know what they can do to resolve it. Was the issue caused by something they did? Is it a problem with the application? Will it be resolved if they come back later?

To clarify, the goal here isn’t to give the user a technical understanding of the inner workings of your application. It’s to help them understand the problem so they can take appropriate action.

It isn’t always possible to tell the user what went wrong, but try to give them something.

Starting with an example of an error message that doesn’t include an explanation:

![](https://cms.echobind.com/assets/6a01ff8a-552f-4480-bf47-d40f3d614bb4)

So what went wrong? Is there an issue with the form values? Did I lose my internet connection? Is the API server down? Will this issue be resolved if I try again? Maybe if I try again in an hour?

Some better examples might be:

![Error message: “There were some problems with the form values provided. See the error messages below.”](https://cms.echobind.com/assets/975b5bc2-c83e-42f1-acb6-d3fd1ed700f3)

This tells the user the problem is with the data they provided in the form. They can look at individual form errors to fix them.


![Error message: “We weren’t able to connect to our servers to complete this request. Please check your internet connection and try again.”](https://cms.echobind.com/assets/8d8624d8-85c9-4783-8d43-2da529a99be1)

This tells the user the issue is likely with their internet connection. Once their internet is working, they can try again.


![Error message: “Something went wrong on our end and this account could not be created. Please try again or contact our support team if the problem persists.”](https://cms.echobind.com/assets/abb7b6ff-3279-4308-8270-eaa79f7a5434)

This tells the user that the issue is with the app itself. They can try again, but if the problem keeps happening, there’s probably nothing they can do to fix it. Notice that we’re also telling the user that the thing they’re trying to do didn’t happen. They aren’t left wondering if the account was created or not.


### Give the user a next step

Sometimes it isn’t intuitive to casual users what they can do to resolve an error. Giving the user a next step helps them understand how to complete the action they’re trying to perform. Explain how to resolve the error, ask the user to try again, direct them to some documentation, provide a link to a contact form to report an issue, etc.

Sometimes this step is implied in the explanation of what went wrong and doesn’t need to be explicitly stated (e.g. “Your password must be at least 6 characters long.”—the next step is clear).

Let’s use the examples from the previous section to illustrate this:

![Error message: “There were some problems with the form values provided.”](https://cms.echobind.com/assets/142e35b3-e7aa-45bc-ac8c-03c76c87a8e3)

This is helpful, the user knows the problem is with the form values. But what’s wrong with the form values? How can the user find out what they need to fix?


![Error message: “There were some problems with the form values provided. See the error messages below.”](https://cms.echobind.com/assets/2652949c-aa67-47bd-94ca-5c701455e70e)

This tells the user that there’s more information in the form itself. They can look at individual field errors to find out what to fix.

This isn’t always necessary. If the form field errors are always visible on the same screen as this higher-level error message, it will likely be clear to the user what needs to be fixed. However, if the form is long enough, the user might need to scroll down to see the field errors. In this case, it’s helpful to tell them to look for field errors in the form.

Another example:

![Error message: “We weren’t able to connect to our servers to complete this request. Please check your internet connection and try again.”](https://cms.echobind.com/assets/97620e11-cfa5-47c6-8495-f78490df54f7)

This tells the user that the issue is likely caused by their internet connection and that restoring that connection will solve the problem. If this issue could also be caused by the remote server being down, it would be good to include the next steps for that as well:

![Error message: "We weren’t able to connect to our servers to complete this request. Please check your internet connection and try again. If the problem persists, try contacting our support team.”](https://cms.echobind.com/assets/1d35f2e7-54ae-43f4-84d0-19d0ceb3f516)

Last example:

![Error message: “Something went wrong on our end and this account could not be created. Please try again or contact our support team if the problem persists.”](https://cms.echobind.com/assets/7e1b86b2-86fb-40a6-a130-5a366dd3e3e2)

In this case, we might not know exactly what went wrong. But we can still give the user some options. Maybe it’s a fluke and trying again will resolve it. If not, they can contact the support team (with a link to that page) as a last resort.

## Human messaging

Never expose implementation details in your error messages. Your consumers don’t need to know that there was a foreign key constraint issue in your database query. This means you should likely not be sending some library’s exception message along to your consumers.

![A form with a “foreign key constraint” error message.](https://cms.echobind.com/assets/2e54e366-465a-4938-83b5-a9a571032b3c)

You’ve probably seen error messages like this before. It probably came directly from an exception on the server. Maybe from code like this:

```javascript
app.post('/user', (req, res) => {
  try {
		// add the user to the database
  }
  catch (err) {
    res.status(500).send(err.message)
  }
})
```

There are two issues with messages like this:

1. They aren’t helpful to the user.
2. It exposes the implementation details of your application. This can pose security risks. If someone sees the error message above, they get a lot of information about how your app works: it uses Postgres, there are two tables named “Table3” and “Table1”, and there’s a foreign key named “Table3_DataID_fkey”.

As a general rule, you should never display an exception message to your users. They rarely contain the information you want your users to see.

Instead, in this case, it’s probably best to just return a more helpful error message from the server. Another option is to catch the error on the client side, ignore the message from the server, and pass your own message along. This isn’t ideal since server error messages can be much more specific about the problem (e.g. you could potentially tell the user that the database is down if that’s helpful to them). With client-side messages, they will likely have to be very general (unless you use error codes in your messages, which we’ll explore later).

Server-side error messages that are directed toward the end user are also helpful because you don’t need to include a lot of error message management on your client side. Just trust the server to only provide messaging that you want the user to see.

```javascript
app.post('/user', (req, res) => {
  try {
		// add the user to the database
  }
  catch (err) {
    res
      .status(500)
      .send(`Something went wrong on our end and this account
             could not be created.`)
  }
})
```

## API messaging

Since most of the APIs we build at Echobind are essentially consumed by casual users (through a client-side app), it makes sense for us to format all of our API error messages in such a way that they can always be displayed directly to the user. So we apply all of the messaging best practices in this document to the error messages returned from the API.

This is beneficial because the API can return very specific error messages and we only need to manage messaging in one place (the API).

There are some occasions where we need to change the messaging on the client side (e.g. we want to add a link to “customer support”). Since we’re using error codes (details below), we can always target specific error messages to be overridden.

## Error categories

Your API should make a clear distinction between an unexpected server error (e.g. your database is down) and invalid form data (e.g. a required field is missing). This will allow your front end to ask the user to take another look at their data or inform them that something unexpected happened.

For a REST API, this could be as simple as returning a 500 response status (e.g. couldn’t connect to the database) or a 400 status (e.g. invalid form data).

It should also be said that your client should be aware of this distinction and respond accordingly.

## Error codes

Each of your API error messages should have a unique code. This allows the consumer to find out exactly what went wrong (match the error code) or do things like provide an alternative message, translate the message into another language, etc. E.g. `{message: "Please provide a valid email address.", code: "EMAIL_INVALID"}`.

Error codes are a contract just like the rest of your API. You should not change or remove error codes without updating your API version.

For example, if a user is trying to create a new blog post in your app and there’s already a blog post with the same name, you might want to show the user a link to the original post. The server will return an error in this case, when the blog form is submitted. Without error codes, you won’t know that the error returned indicates that the blog already exists or if it’s some other error. In the worst case, you’d need to test the content of the message to see if it’s the one you’re looking for.

```javascript
const response = await createBlogPost(data);

if(!response.success) {
  if(response.errors.some(message => message.includes("already exists"))) {
    // fetch the original post and show it to the user
  }
}
```

This is obviously a problem because the error message might change at some point. However, if your error messages have error codes, and you know those codes will never change, you could do something like this:

```javascript
const response = await createBlogPost(data);

if(!response.success) {
  if(response.errors.some(error => error.code === "BLOG_POST_TITLE_EXISTS")) {
    // fetch the original post and show it to the user
  }
}
```

Or if you don’t like the error message that the server provides (it isn’t a complete sentence, doesn’t explain what went wrong, and doesn’t give a next step), you could provide your own:

```javascript
const errorMessageMap = {
  "BLOG_POST_TITLE_EXISTS" => `A blog post with this title
  already exists. Please change the title so that it's unique.`,
}
```

## Client-side vs. server-side validation

Ideally, you’ll validate data on the client and on the server. You want to validate on the client because it creates a more responsive experience for the user. You want to validate on the server because you need to verify certain constraints before performing actions there.

That said, if you do validate on both the client and the server, you need to guarantee that you’re performing the same validation on both. You don’t want your client to throw an error on data that your server would accept, and vice versa.

You could do this by just copying/pasting the same validation code on your client and server. However, this will almost certainly lead to situations where you change a validator on one side but forget to make the same change on the other.

The better (and, we go a step further and say, only) way to do this is if you can share the code between your client and server. Some frameworks, like Next.js, allow this out of the box. But you could also do it using a monorepo, with a shared library between your client and server.

If this isn’t an option, then just do validation on the server. This will almost certainly be snappy enough for most apps. If validation feedback from the server isn’t as fast as it needs to be, then revisit how you’re doing validation at that point.

There will very likely be some validation tasks that cannot be done on the client (e.g. validation that requires database access). In those cases, share as much validation as you can between the client and the server, and then just perform those extra validation tasks on the server.

## Targeted form messaging

If there are errors in your form fields, you want to display those error messages next to the field itself. You don’t want to do this:

![A form with a top-level error message saying, “Please provide a name. Please provide a valid email address.”](https://cms.echobind.com/assets/a347f99e-6e72-422a-b5d2-27d08a23e5be)

Instead, you want to do this:

![A form with an error message next to the Name field saying, “Please provide a name,” and an error message next to the Email field saying, “Please provide an email address.”](https://cms.echobind.com/assets/4334a336-6d41-4587-956e-cf0ae4c81e9b)

In order to do this, your error reporting will need to accommodate these kinds of form fields:

- **Primitives**. Normal form data (e.g. strings, numbers, dates, etc).
- **Objects**. You may also want to support fields that are a combination of other fields (e.g. `{name: {firstName: string, lastName: string}`). This is usually a bad idea, but since your top-level data is essentially an object, you might as well implement error reporting that supports it so that your nested error logic will work well with them.
- **Lists**. Often you’ll want to allow users to add multiple entries for a field (e.g. multiple contact phone numbers). Each list item could be a primitive, an object (i.e. each entry will have its own fields), or a list. It’s a good idea to support infinite nesting in this way.

No matter how your forms are composed (e.g. primitives, objects, lists, nested objects/lists), you should be able to target an error message at any single field—even if it’s deeply nested in something like a list → object → list → primitive.

You’ll likely want to support multiple error messages per form field. Sometimes there are multiple things wrong with data and you’ll need to be able to report that to the user (e.g. “Your password must be at least 6 characters long” and “Your password must contain at least one capital letter.”). Therefore, all error message fields should be arrays (even if you only have one error message).

There are a few ways to do this. The simplest is to create an array of errors, each with a “path” to the field, a code, and a message:

```javascript
{
  errors: [
    {
       code: "EMAIL_INVALID",
       path: ["reviewers", 3, "contact", "email"],
       message: "Please provide a valid email address.",
    }
  ]
}
```

This is flexible enough to allow for multiple messages per field, and any level of field nesting. In the example above, it’s clear that the form has a list of `reviewers` (probably allowing the user to add an arbitrary number of them), this is the 4th item in the list (index `3`), and each reviewer has a `contact` field that has an `email` sub-field.

## Handle failed requests

Always handle failed requests. A request can fail for countless reasons: the server is down, the user’s internet connection is down, request data is invalid, there was an exception while processing the request, etc. Don’t just assume requests will always succeed. This includes fetching and mutating data. If a request fails, the user should be notified and given a next step, and your app itself should respond appropriately (e.g. don’t move along as though the request succeeded).

## Handle loading states

Always handle loading states. This includes fetching and mutating data. If data is being fetched or mutated, that should be clear to the user. If data is being mutated, it’s likely you’ll want to make some restriction to the user’s interaction until the mutation completes (e.g. don’t allow the user to interact with or submit a form again).

## Conclusion

There are certainly more items to add to this list and more to be said about each one. But the main takeaway is to be thoughtful and intentional about validation and error handling in our applications. It’s a frequently overlooked aspect of development, but the consequence is that it’s just as frequently something that makes us disappointed with the apps we use ourselves. We get stuck in weird states, we read unhelpful error messages, we watch loading spinners that never end, all because some application developers didn’t handle errors properly.

Validation and error handling can be something we continuously wrestle with and only address when the stars align and we’re lucky enough to encounter an error state during development. But with some upfront planning and time, it can be a part of our apps that “just works” and creates a great experience for our users.

---

[View on echobind.com](https://echobind.com/post/data-validation-error-handling-best-practices)

---

# Our Approach to Fonts

> Helping our design team save time by creating a repository for free fonts.

_By Lexi Namer · 2023-03-03_

## Sourcing fonts was leading to unexpected costs


While many of our clients come in with an existing brand already in place, we often have work on projects that don’t have an existing design system or chosen web fonts. As designers, we utilize many resources for sourcing fonts, including Adobe Fonts and independent font foundries. However, when it came time to build software that could scale for our clients, we ran into challenges with font licensing. Hosting a font in a server can quickly become a recurring cost that our clients are forced to absorb year over year and requires separate licenses from each foundry. 


## A font repository approved by our design team


As a design team, we decided to create a font repository with free and open-source fonts that could be used in all types of products, from websites to mobile apps. Instead of spending hours at the start of each project searching for fonts, reading licenses, and then testing them in visual concepts, this repository saves time, improves design efficiency, and ensures that every font that our team designs with can be easily utilized by our engineers. 


We started by creating a checklist of criteria that every font must meet in order to become an approved font. 

- Open source to be used without additional licensing
- Multiple styles (ie: italics, regular, bold) for flexibility and variety
- Must have web font + desktop font (.ttf/woff),
- Flexible use for headers and body copy.

## Curating and visualizing a diverse selection of fonts


To begin building the repository, we sourced fonts from [Typewolf's Definitive Guide to Free Fonts](https://www.typewolf.com/free-fonts) and conducted brainstorming exercises with the team. The result was a curated list of 50 diverse fonts that the entire design team loved. We then created created a repository in [Notion](https://www.notion.so/), which is Echobind’s preferred tool. The most time consuming but valuable part of building the repository was designing a visual font specimen that our team could use to quickly scan all the approved fonts in various styles. Each font has a card that includes the category, classification, number of weights, download url, and additional tags.


 


![](https://cms.echobind.com/assets/409de9e8-7f0c-4053-9da9-d87a32e17444)


We worked on this project in our [investment time](https://echobind.com/post/the-roi-of-self-directed-investment-time-for-software-engineers) at Echobind so it took us about two months from start to finish. The final result is a repository of approved fonts that our team can quickly and easily access, saving time and improving our workflow. It will also help new designers at Echobind get up to speed on our preferred fonts, especially if they don’t have deep expertise in typography. 

We highly recommend creating a repository for any design team looking to improve their workflow. Below is a peek of what the repository looks like in Notion. 


![](https://cms.echobind.com/assets/88046fa8-3c8a-429a-b9b6-e985b597b228)

---

[View on echobind.com](https://echobind.com/post/approach-to-fonts)

---

# Project Starts: Ubiquitous Language

> Ubiquitous Language is a shared language between developers, business stakeholders, and users that can reduce misunderstandings and improve productivity.

_By Zack Marty · 2023-02-23_

When starting a new project as its manager or a member, one of the most important steps you can take is to establish [ubiquitous language](https://martinfowler.com/bliki/UbiquitousLanguage.html#:~:text=Ubiquitous%20Language%20is%20the%20term,language%20between%20developers%20and%20users.). Establishing ubiquitous language involves getting everyone to speak the same language, [use the same jargon](https://www.agilealliance.org/glossary/ubiquitous-language/#q=~(infinite~false~filters~(postType~(~'page~'post~'aa_book~'aa_event_session~'aa_experience_report~'aa_glossary~'aa_research_paper~'aa_video)~tags~(~'ubiquitous*20language))~searchTerm~'~sort~false~sortDirection~'asc~page~1)), and have the same definitions in their head of what that jargon means. This is as simple as asking, **“What do you mean when you say that?**” Is it possible that you will look silly? Absolutely, but I would rather look silly than remain ignorant of the language being used and possibly lose control of a project when everyone’s jargon diverges.


![](https://cms.echobind.com/assets/71276b06-92da-43da-a9b0-14b5b2b41218)


When you have yet to establish ubiquitous language, you almost always run into a fun term in linguistics called [lexical ambiguity](https://www.thoughtco.com/what-is-lexical-ambiguity-1691226).


### **An ambiguous joke**


*“I have a really nice step ladder. Sadly, I never knew my real ladder.”*


Lexical ambiguity is when you have an identical or similar word that means slightly different things to different people. This happens because that term has not been explicitly defined.


A common lexical ambiguity in product and software is the term _User Story_. Most people’s definitions are pretty close. However, you can run into annoying communication issues when you don’t line up definitions with the rest of your team. 


### **Some User Story Definitions**

- It could be the informal, natural framework for describing your feature or a requirement from a given user’s perspective. `As a < type of user >, I want < some goal > so that < some thing happens >`.
- Some people consider a user story to be the ticket itself in relation to Jira, shortcut, or some other ticket tracking software. Shortcut even uses the phrase ‘Create Story’ on the button to create a new work ticket.
- For some people, user story and requirement are synonymous.

None of these definitions are wrong. None of them are objectively correct either, so the goal of ubiquitous language is to have shared definitions across the board. 

<div style="position: relative; padding-bottom: 56.25%; height: 0;"><iframe src="https://www.loom.com/embed/2226c13ba1c041d89b8df304e06ff6a5" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen style="position: absolute; top: 0; left: 0; width: 100%; height: 100%;"></iframe></div> <br>

For a more recent example, we had a kickoff meeting with a client where they kept referring to Group 1 and Group 2. They were referring to customers who were in a certain part of the process to getting onboarded. As the meeting continued I noticed that people kept using Group 1 and Group 2 for different points in time within the onboarding process, so I simply asked, “Who is Group 1? What does it mean?” Understandably, the team was silent.


The next step was to say, “Okay let’s define group 1, group 2, any other groups, and then document those groups for when other people don’t know what they mean. 


Whether you almost know what someone is saying or you know that other might not know, don’t hesitate to ask, “What do you mean when you say that?”


When you establish ubiquitous language or a shared glossary, you chop out many of the communication problems that can naturally crop up with your new team.

---

[View on echobind.com](https://echobind.com/post/project-starts-ubiquitous-language)

---

# Cultivating a Healthy Remote Work Culture

> Cultivating a Healthy Remote Work Culture

_By Krystalyn Bauer · 2023-02-17_

Echobind has been a remote organization since its inception, but we have seen the remote work revolution accelerate tremendously over the past few years for the rest of the world. What started as a necessary measure for the safety of employees for many businesses turned into a new way of life and work. Since we were remote before it was cool to be remote, I wanted to share a few tips on how to cultivate a healthy remote work culture. 


### Communicate openly and frequently


Communication is key in any remote work environment. Make sure to keep your team informed about important updates, changes, and goals. Regular check-ins and virtual team meetings can help keep everyone on the same page and reduce any feelings of isolation or disconnection. We use Slack to communicate throughout the day and I meet with our team members monthly for a wellness check and to catch up. Our team particularly loves the FYIF (Fill You In Friday) videos our CEO puts together with company updates married with great tunes and incredible graphics.

<iframe src="https://giphy.com/embed/26FmQIj4UtKCbm5I4" width="480" height="480" frameBorder="0" class="giphy-embed" allowFullScreen></iframe><p><a href="https://giphy.com/gifs/cbc-funny-comedy-26FmQIj4UtKCbm5I4">via GIPHY</a></p>

### Foster trust and accountability


Remote work requires a high level of trust and accountability between team members. Encourage your team to take ownership of their work, set clear expectations, and meet deadlines. Trust your team members to work independently and collaborate effectively without constant supervision. Our team conducts [retrospectives](https://echobind.com/playbook) on all of their projects to discuss what went well, what they learned, and where they can improve.

<iframe src="https://giphy.com/embed/3o7buf7MXgQtl9kQrm" width="480" height="480" frameBorder="0" class="giphy-embed" allowFullScreen></iframe><p><a href="https://giphy.com/gifs/schittscreek-schittscreek-pop-poptv-comedy-tv-funny-eugenelevy-danlevy-3o7buf7MXgQtl9kQrm">via GIPHY</a></p>


### Prioritize well-being


Remote work can blur the boundaries between work and personal life, making it harder for employees to disconnect and relax. Encourage breaks, prioritize self-care, and create a[ ](https://echobind.com/post/40-hours-are-optimal)[healthy work-life balance](https://echobind.com/post/40-hours-are-optimal). We share our wellness wins and goals in our fitness-focused slack channel and cheer each other on. I make sure to highlight our wellness and EAP resources periodically, and we use 15five to keep track of our well-being each week. 


<iframe src="https://giphy.com/embed/SuIllCjjdA9bWWyqcD" width="480" height="480" frameBorder="0" class="giphy-embed" allowFullScreen></iframe><p><a href="https://giphy.com/gifs/cbc-schitts-creek-SuIllCjjdA9bWWyqcD">via GIPHY</a></p>


### Foster a sense of community


It can be easy to feel disconnected when working remotely. Social connection is important for maintaining a healthy remote work culture. Provide opportunities for [virtual activities](https://echobind.com/post/virtual-holiday-event) that are not forced or mandatory. We have a standing calendar block on Wednesday afternoons for informal water cooler chat or for someone to host a virtual game like Skribble or Jeopardy. We also love the donut app in slack that provides random pairings for coffee chats. 


<iframe src="https://giphy.com/embed/14SBB8m1Gb4bDz7ANu" width="480" height="480" frameBorder="0" class="giphy-embed" allowFullScreen></iframe><p><a href="https://giphy.com/gifs/schittscreek-14SBB8m1Gb4bDz7ANu">via GIPHY</a></p>


### TLDR


Cultivating a healthy remote work culture requires open communication, trust, work-life balance, social connection, mental health support, and gifs don’t hurt either. By following these tips, you can create a positive remote work culture that fosters collaboration, productivity, and well-being.

---

[View on echobind.com](https://echobind.com/post/cultivating-healthy-remote-work-culture)

---

# Rails Scopes: Create Faster, Cleaner Queries

> Scopes provide cleaner code and remove the need for multiple class methods. They also allow combining multiple scopes and do not contain overly complicated logic

_By Deloris Thompson · 2023-02-15_

With the use of `scopes`, a developer can create a fast query and add additional methods like `pluck` that would otherwise throw an error.


### Why use Scopes?


Scopes allow a developer to create reusable code instead of a method in the [controller](https://guides.rubyonrails.org/action_controller_overview.html)[.](https://guides.rubyonrails.org/action_controller_overview.html)  Scopes also return an `ActiveRecord::Relation` object, opening the door for combining multiple scopes.


Let's look at one example where scopes are better:


```ruby
def member_ids
	member_emails = ['john.smith@example.com', 'm.jackson@example.com', 'bob.smith@exmple.com']

Account.where(email: member_emails)
end
```


### How to Create:


`scopes` are created inside a [method](https://guides.rubyonrails.org/action_controller_overview.html#methods-and-actions).  While not required, adding additional arguments is possible.


Ex:


scope :name_for_method, →(arguments NOT required) {query is inserted here!}


```ruby
# Grab all users with a certain role (roles is an array) 
scope :admin, { where('? = ANY(roles)', 'Admin') }
```


This will allow using the method globally for the class.  A class in Ruby is a controller.  It also has methods.


	```ruby
	@group.announcements.manager_all_messages(current_user)
	```


Or grab all accounts with a certain role.  This is created inside the **method** file for your Ruby class.


```ruby
def admin
  Account.admin.pluck(:id)
end
```


### Conclusion:


Scopes provide cleaner code and remove the need for multiple class methods.  They also allow combining multiple scopes and <u>do not contain overly complicated logic</u><u>.</u>


### Resources:

https://guides.rubyonrails.org/action_controller_overview.html#what-does-a-controller-do-questionmark

---

[View on echobind.com](https://echobind.com/post/rails-scopes-faster-cleaner-queries)

---

# Wielding Cynefin for Non-managers

> Wielding Cynefin for Non-managers

_By Zack Marty · 2023-02-02_

Before we jump into how one can wield Cynefin, let’s first describe what it is and why one would use it. You can head to Cognitive Edge’s site [here](https://thecynefin.co/) to learn more about it, watch my Product Talk [video](https://www.loom.com/share/dd9ec2e220484c03aa9d857e5c35d476?sharedAppSource=personal_library) to understand the very basics, or you can skip to the paragraph below. The creator of Cynefin, David Snowden, also does a fantastic introduction on [youtube](https://youtu.be/N7oz366X0-8). 


Now that I have gotten some of the linking out of the way, Cynefin is a sense-making framework. Its goal is to guide action based on the habitat, scenario, or social situation in which you find yourself. It does not spit out an answer for you based on some input. It helps guide how to think about and tackle problems rather than telling you an answer. Any type of model that tries to spit out a distinct answer for you is going to have limited applicability and will probably stop helping you long before you stop using it. When consultants and other business folk hear about some new way of doing things, they try to apply it to everything, and you end up going through the motions of some strange new practice that doesn’t apply to selling or making widgets. You can’t apply the quadratic formula (-b±√(b²-4ac))/(2a) to everything, so it makes me wonder why consultants and others try to apply their formula to everything.


Cynefin isn’t a formula, so it won’t provide the answers. It can help guide actions. So let’s take a look:


![From Cognitive Edge with some edits](https://cms.echobind.com/assets/5cf5882e-5d0d-490a-8ead-83e6166180cc)


The above model is Cynefin’s framework and a map of how we conceptually move through different domains depending on the intricacy of the situation where we find ourselves. It’s a simple layout of how you can think about the domains in which you reside at any given time. When I say domain, I am talking about the nature of a given scenario, problem, or situation. So let’s keep it simple and start with the simple domain. 


# Simple


The simple domain is just that, simple. It is where thoroughly categorized and defined social situations and work come into play. “[Best Practices](https://www.investopedia.com/terms/b/best_practices.asp)” is the most relevant here, because someone has predefined the decisions that we need to make when we encounter a simple scenario. For example, if a customer comes into my store and presents me with an item that they want to purchase, then I would complete the transaction in the following fashion:

1. Customer presents an items or items to purchase.
2. I scan the item(s).
3. I tell the customer how much it will cost.
4. They give me money.
5. I probably give them a receipt, and I give some sort of indication that we have completed the transaction.

Most transactions proceed in this fashion, and they will likely continue to proceed in this fashion as long as people purchase things in person. Even when transactions become more complicated or there are other issues that arise, most stores have automatic protocols for how to handle such issues. 


### Considerations in the Simple domain


The manager’s job is to train people on the best practices involved in something within the simple domain. Their boss’s boss probably designed those best practices or implemented them from someone else’s example. As a non-manager, you don’t necessarily need to improve upon something involving best practices. It is your job to execute best practices effectively and without any major speed bumps. The place where you can shine within the simple domain is incremental improvements to a process. Take the above transaction for example. One might incrementally change the process by always handing the customer a receipt rather than asking if they want one. When I go to CVS, they just hand me my mile-long receipt rather than asking me if I want one, forcing me to stand there for a moment wondering if that receipt for my candy bar should be retained. Is it an improvement in the process? It might save time or it might make customer interaction better since you aren’t forcing an arbitrary decision upon the customer. 


A common mistake that people make in the simple domain is in their attempts to reinvent a process. Frustration comes for the worker when a manager says, “[We have always done it this way](https://www.forbes.com/sites/forbeslacouncil/2019/01/28/the-most-dangerous-phrase-in-business-weve-always-done-it-this-way/?sh=b1f75e540f7e),” but it is a relevant response when the way they’ve been doing it has so far been effective. Fear not, because “We have always done it this way,” is almost always a terrible response as you move toward the complex and chaotic domains. 


If you are operating in the simple domain as part of your job, you can make important contributions, but set your expectations toward minor enhancements rather than trying to replace a functioning process with an entirely new process that you think might be slightly more functional. The beauty of minor enhancements is that you can often implement them by yourself and present your findings to management later, leading to improvements that you just created. Hopefully the simple domain does not slide off a cliff into chaos as your job will become that much harder if nobody realizes that the simple processes are actually chaotic. 


# Complicated


The complicated domain is where you find experts in specialized fields. These experts will sense the stimuli, analyze them, and respond based on the best course of action. For example, when you go to the doctor’s office for the first time, they ask you extensive questions about what they call your [chief complaint(s)](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7161385/), and then you usually need to fill out a form about your medical history and often a family history. The doctor will then take all of this information to get a sense of what the root cause of your chief complaint could be. Often it is simple. Congratulations, you broke your leg, but when it is slightly more complicated and elusive the physician needs to sense all of the different variables rather than walk into the room and hand you a pamphlet saying, “Well here is a list of things it could possibly be based on just your first statement.” In the sensing portion, gathering information and expertise is paramount to the success of your endeavor. For a manager, this means gathering experts when attempting to solve a complicated problem.


In a hospital setting with a very complicated case, they might gather an assortment of specialists who have seen the patient’s set of symptoms. For something involving cars, a manager may gather an assortment of cars to identify how to best solve a given car’s problem. For you, it works a little differently. If you’re not in management, you often can’t just gather up the experts and set them loose on the problem. In the complicated domain, you’re often either the one tasked with solving the problem and likely a manager, or you’re an expert in a field who is supposed to help solve that problem. When you are neither of those, there are a few things you can do that will benefit you and your organization:


**Start to become an expert in problems that show up routinely.** 


This may be simple. For instance, you might be excellent at writing very concise emails. Look above to see that this person is not me. Or you might understand something like Tailwind, Material UI, or a number of other tools that can benefit those who might need it.  I became an expert in Jira so that I can quickly solve any problem related to the administration or use of Jira in general. Jira is so complicated that you often see it on people’s resumes.


**Learn to identify the experts (****This is an expertise in itself)****.** 


When I first arrived at Echobind, my primary goal was to figure out what everyone excels at. When you know who the experts are, finding solutions to problems becomes much easier. Instead of banging your head against the wall, it becomes better to ask the expert. I am often asked to identify the individual who knows about a certain subject. When directly asked about something, I always know who I can talk to in order to get the required information. It is always better to say “I know who can answer that,” rather than just, “I don’t know.”


**Learn to identify when an expert is needed.** 


At Echobind, we have clients who have novel approaches to new problems, and it is not always easy to know when an expert needs to be consulted. When it comes to our medical clients and dealing with HIPAA, we always know when an attorney needs to be consulted rather than trying to wing it and put a client in hot water. Getting the right experts in early can save you and your clients a lot of money in the long run, and it can prevent you from attempting to solve a problem that has already been solved or attempting to solve a problem in a way that leads your organization into a regulatory gray area. 


With these personal practices, you can become an effective participant in complicated domains that require more than best practices and have yet to travel to more chaotic domains. 


# Complex


Complex and complicated seem like very similar domains, but there is an important difference.


![](https://cms.echobind.com/assets/955cf258-e2c8-4aea-88f3-447f5973c86e)


When you work within a complicated domain, experts can help you navigate the information that has been gathered until they reach a solution to the problem, or they can at least lead you to what the likely outcome is based on that information. Contrast that with the complex domain. Even for someone who routinely operates within a complex domain, it may not be obvious what is going to lead to a solution.


A common example of a complex domain is that of a battlefield. On the battlefield, any experienced commander will tell you that you can’t apply the same solution to every situation, even when the scenarios are quite similar to ones they have seen before. If you have ever heard [“No plan survives contact with the enemy,”](https://quoteinvestigator.com/2021/05/04/no-plan/) it’s partly due to the complex nature of a battle. The complex domain is dependent on [exaptive or emergent practices](https://cynefin.io/wiki/Exaptive_triggers). This means you are going to discover practices and methods based on your experience with vaguely similar scenarios. 


### How do exaptive or emergent practices apply to you?


As an individual contributor, it will be your job to supply new approaches to your managerial staff that rhymes with what they have seen before. You don’t need to rip the box apart in order for your new ideas to take hold, and ultimately you don’t want to. The biggest and most important challenge you will face is convincing your manager(s) that you are in a domain where you cannot apply best practices. 


Best practices have absolutely no business being in a complex domain. Best practices have bounded applicability, which means that they have limited value depending on the scenario in which they are applied. Often, best practices only apply to extremely narrow scopes. In a military engagement, you would not hear a commander refer to flanking as a best practice that should be applied to every scenario. It can be effective in many engagements, useless in some, and quite impossible in others, so it should never be called a best practice. So how do you convince your managers that best practices don’t apply to your situation? Apply it quickly and expertly, then collect the data. Managers don’t want to hear that it doesn’t work before you do it, so there is a chance that you need to apply their best practice as well as apply your own idea to make a comparison. 


![![Photo by Jason Dent on Unsplash
](https://s3.us-west-2.amazonaws.com/secure.notion-static.com/6faab7c3-fa24-4853-a133-0dbb57622d54/jason-dent-JVD3XPqjLaQ-unsplash.jpg?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=AKIAT73L2G45EIPT3X45%2F20230202%2Fus-west-2%2Fs3%2Faws4_request&X-Amz-Date=20230202T193209Z&X-Amz-Expires=3600&X-Amz-Signature=cd86ec5ee6afd05bc27fc2f835bbeed54f7dda0cfe6dd6e21e32e3203d0497de&X-Amz-SignedHeaders=host&x-id=GetObject)](https://cms.echobind.com/assets/50ec6b6c-56e5-46bd-8164-d2646325eebb)


This is where you will see things like A/B tests. Google famously A/B tested 50 separate [shades of blue](https://bharathbalasubramanian.medium.com/data-driven-decisions-googles-50-shades-of-blue-experiment-996f01819a97) in order to decide which shade of blue will net them more ad revenue. A/B testing is a pretty common practice in making a decision, and something like testing so many shades of blue would be more emergent than best. 


# Chaotic


The chaotic domain is one of the worst domains to be in, and if you routinely find yourself in the chaotic domain, it might be better to find a new job rather than try to be effective in it. If you are wondering what a chaotic environment would be like, think 9/11, Hurricane Harvey, or any unprecedented disaster. In a product manager’s world, this means disastrous site crashes and a near-constant need to merge directly into the main branch in the hopes that your hotfix will correct everything while your phone continues to buzz with the aggression of every executive stakeholder. 


Characteristics of the Chaotic category:

- The immediate priority is containment
- The solution does not have to be the best, as response time is more important
- Once you’ve stopped the leak, you can take a breath and determine which sector the problem fits into
- No one knows what the answer looks like with certainty
- Look for what works first instead of the right solution
- Many decisions to make, no time to think
- Immediate action to reestablish order

### So what do you do?


First, you need to identify yourself in such a chaotic environment. Are you a ‘first responder’ or are you in a position that cannot immediately affect the problem? If you’re the first responder, there is no time for data gathering, and finding the source is not going to fix the chaos right now. You need to ignore management for the most part unless they have information that will help you plug the leak or put out the fire. 


Are you not one of the devs on the ground? Then you need to be Guy Fieri During the California wildfires, routinely cooking food for the brave [firefighters battling wildfires](https://abc7.com/dixie-fire-california-fires-wildfire-guy-fieri/10977532/).


![](https://cms.echobind.com/assets/af23ec4f-04f9-4ffb-a3bb-d057c8ba8289)


Be useful and get out of the way. If your organization is routinely in a chaotic situation, then it might be time to evaluate your continued attendance. 


### Final Thoughts


No matter which domain you are in when solving problems or working toward a common goal without the authority that comes with a management title, your first priority becomes identifying the type of domain you’re in. Then you need to act in such a way that brings the most value without getting trapped in best practices with bounded applicability. Management can get stuck in the methods that helped them succeed without reevaluating if those practices still bear fruit. A good manager can have outdated practices and still know when they have a valuable member of their team, and the domain you find yourself in will dictate how much you can upend traditional paradigms.

---

[View on echobind.com](https://echobind.com/post/Wielding-Cynefin-for-Non-managers)

---

# The ideal mobile app design process

> A peek at what goes on behind the scenes during the UI/UX design phase of a mobile app

_By Lexi Namer · 2023-01-25_

There is so much going on behind the scenes of the design for a mobile app. Mobile app design requires the expertise and knowledge of how different operating systems work and common design patterns and affordances that users expect to see in a modern application. As UI/UX designers, if we are successful at our jobs, we enable a smoother, more efficient engineering phase and mitigate a lot of usability issues once your app launches. This gives you an app that your customer will want to sign up for and use over and over. 


Here are just some of the things that we often do during the design process. This list also doesn’t include things we do implicitly, like copyediting, image sourcing, and graphic creation.  


![](https://cms.echobind.com/assets/961032b2-dc36-4926-8cd8-27a9c7593a3c)


## **Wireflows**


Wireflows are a helpful design artifact that combines wireframes and user flows in a visual way. They are a fast and inexpensive way to understand the interaction design of your app and ensure that we have considered every touchpoint that a user will take from start to finish.


![](https://cms.echobind.com/assets/fcff3a55-8c5d-458a-8527-1cc3bad143be)


## **Design Concepts**


Just like anything, it is rare that the first idea will be the best, and exploring different design concepts early in the design phase allows us to quickly explore different ideas to understand what solution is the most viable. This can range from visual exploration to app layouts.


![](https://cms.echobind.com/assets/f28a8245-dc4d-45dc-9516-1e2f0e726f36)


## **Wireframes** 


Wireframes are a core component of the mobile app design process. They illustrate the structure, function, and layout of all of the screens in an app and allow us to focus our efforts on ensuring the right functionality and features are present in the interface.


![](https://cms.echobind.com/assets/f8315b53-feeb-4396-bfd4-05e57509f3fe)


 


## **Visual design**


Visual Design is what most people think of when they talk about designing an app or website. It’s the part of the process where we make all the major decisions about typography, color, images, UI components, and other visual details. It’s how your brand is applied in product.


![](https://cms.echobind.com/assets/e67c0976-cd5d-46a8-8c3d-46a4b1cde72a)


## **Mockups** 


Mockups are the finished designs that most closely resemble what your final app will look like and help your app stand out from your competitors. It is where we take your visual design and brand and apply it to the wireframes to have a cohesive, beautiful app


![](https://cms.echobind.com/assets/c61835fc-2032-4d20-8cf0-9573cd54a44c)


## **Prototypes**


Prototypes are cost-effective ways to simulate and test how the app will function and feel. They are generally created in a design software (we use Figma) and are used to share ideas with stakeholders, catch any bugs, and make handoff easier between design and engineering.


![](https://cms.echobind.com/assets/b25b6277-05fc-4cb0-9695-8b6b51e1b275)


## **Usability Testing**


Usability testing is a method of testing the functionality and ease of use of a product where we use the prototypes to test your app’s functionality with potential customers. Research has shown that testing with just 5 people can identify 85% of usability issues of a product.


![](https://cms.echobind.com/assets/c37b9cf2-4ddf-4bc2-9c61-dc5ff083d61b)


Source: [Userbrain](https://www.userbrain.com/en/features/)


**Design QA**


Just like in software development, design requires ample time for ensuring quality. Design QA includes labeling all of the design elements, checking for bugs and inconsistencies, and ensuring the engineers have a full understanding of what they need to build and how it should function.  


![](https://cms.echobind.com/assets/f13c047a-4b07-4c44-b5ea-bf03f24f1f4d)


At Echobind, we treat each project differently, which is why we use a flexible design process based on the needs of your business and customers that we uncover during the discovery phase. In an ideal design process, we show you work in progress early and often so we can incorporate your feedback in the designs. Designing a mobile app takes a lot of time, exploration, and skill to be done successfully and investing in design is one of the most important things you can do to ensure that your mobile app is successful.

---

[View on echobind.com](https://echobind.com/post/ideal-mobile-app-design-process)

---

# ‘Metaprogramming’ Filters w/ Rails-GraphQL

> How Ruby’s ClassMethods helped to create some solid GraphQL helpers for filtering data.

_By Matt Thompson · 2023-01-18_

First off, if you have no idea what Metaprogramming is or how it could apply to GraphQL in Ruby, don’t worry. Most people hear this term and view it as magic land that few have a reason to venture into… and for the most part, they may be right. Do you really need all that overloading and extra class utils? Of course not, there are _plenty_ of giant Ruby files. However, it does feel good when you to able to those files clean and organized for your day-to-day work. 

The only assumption I’ll be making here is that you have some basic understanding of Rails [`scopes`](https://guides.rubyonrails.org/active_record_querying.html#scopes) and GraphQL.  

In fact, there’s a good article that addresses ruby metaprogramming here: [https://www.toptal.com/ruby/ruby-metaprogramming-cooler-than-it-sounds](https://www.toptal.com/ruby/ruby-metaprogramming-cooler-than-it-sounds)


Today, I wanted to address how the mystical unknown of Ruby’s ClassMethods helped to create some solid GraphQL helpers for filtering data. 


## The Scenario 


Let’s set up the scenario… 


In GraphQL (or any API setup) you may wish to create filters for your queries. Shocker I know… but imagine ‘Jim’ needs to search through the company's past consultations by the sales rep's name or the customer's name. 


“No problem, Jim!” 


![](https://cms.echobind.com/assets/a20d18e9-0a8d-47e4-8030-9975b260d22a)


## The Code 


Let's take a look at the schema we have to work with. In this example, we have a `consult` that is assigned to both a `user` and a `sales_rep`. So to recap in our example Jim the sales rep needs to query Consults based on the folks’ names. 


```ruby
create_table "users", force: :cascade do |t|
    t.text "email", null: false
    t.text "first_name", null: false
    t.text "last_name", null: false
		t.text "full_name", null: false // before save join
		// other values...
end

create_table "sales_reps", force: :cascade do |t|
    t.text "email", null: false
    t.text "first_name", null: false
    t.text "last_name", null: false
		t.text "full_name", null: false // before save join
		// other values...
end

create_table "consults", force: :cascade do |t|
    t.bigint "user_id", null: false
    t.bigint "sales_rep_id", null: false
    t.string "consult_type"
    t.text "notes"
		t.date "created_on", default: -> { "CURRENT_TIMESTAMP" }

		// other values...
    t.index ["sales_rep_id"], name: "index_consults_on_rep_id"
    t.index ["user_id"], name: "index_consults_on_user_id"
  end
```


Sweet, not too bad of a request — let's take a look at what this should look like w/ GraphQL and work backward a bit.


```graphql
query($userFullName: StringFilters, $salesRepFullName: StringFilters){
      consults(userFullName: $userFullName, salesRepFullName: $salesRepFullName) {
          id
					notes
					user {
						id
						firstName
						lastName
					}
					salesRep {
						id
						firstName
						lastName
					}
				}
	}

```


Wait! what are `StringFilters` ?!


Does the end user want an exact match or a fuzzy match? include a set of values? exclude? do they need a range of values? Who knows… 


When building out an API I never want to assume how folks want to interact with the endpoints I’m building. They should be dynamic and flexible. Today it's Jim, tomorrow it's Pam, then the whole accounting firm drops a bomb of chili on our app. 


Let’s simply protect ourselves and build out a Filter class that can be flexible enough to support folks as we continue to grow up front. 


```ruby
module Types
  module Filters
    class StringFilters < Types::Base::BaseInputObject
      description 'A way to filter string fields.'

      argument 'contains', String, required: false
      argument 'startsWith', String, required: false
      argument 'endsWith', String, required: false
      argument 'equals', String, required: false
      argument 'gt', String, required: false
      argument 'gte', String, required: false
      argument 'lt', String, required: false
      argument 'lte', String, required: false
      argument 'notIn', [String], required: false, description: "['value1', 'value2']"
      argument 'in', [String], required: false, description: "['value1', 'value2']"
    end
  end
end
```


## The ‘issue’ 


Here is where we start to get into our issue, at some point, we need to resolve these filters and get said data… the issue we have no clue what filters the end consumer may use. That’s kinda the point. While we could litter our GQL resolver with a ton of logic we really want to let our Models and Active Record handle this kind of thing. So far nothing has been truly GraphQL-specific. Rather we simply have a consumer asking for some filtered data. 

With that in mind, lets aim to keep that logic out of GQL and in a place where we can leverage it throughout the app.  


Well in rails land, that generally means adding some `scope`(s) to our models — let's build some scopes in our `Consult` model that can handle this. 


```ruby
scope :user_name_contains, lambda { |query|
  joins(:user).where("users.full_name" ILIKE ?", '%' + sanitize_sql_like(query) + '%')
}

scope :user_name_equals, lambda { |query|
  joins(:user).where("users.full_name": query)
}
```


**Wait a second?!… hold up! Hit the brakes!**


![](https://cms.echobind.com/assets/7de9f786-fd60-465d-bf93-78ac474fd062)


Let's think about this at scale for a second. 
We now have:

- A list of String Filters that could be scoped to MULTIPLE fields on my Model
- Some of those fields are tied to a relation
- What happens when Pam and Accounting actually do ask for more…

Holy cow Batman, that’s a lot of scopes to add to our models… GROSS!!


There has to be a way to keep this clean and DRY…


## Solution Time!


Insert some fun metaprogramming and new class utils. To be frank this stuff is always confusing to me at first so let's take a look at the end result first and we’ll chat about what’s going on. 


**{Model}.rb**


```ruby
class Consult < ApplicationRecord
  include GqlScopeHelpers
  @filterable_args = %i[sales_rep_full_name user_full_name user_id sales_rep_id created_on]
  include_relational_string_filters_for(SalesRep, 'full_name')
  include_relational_string_filters_for(SalesRep, 'id')
  include_relational_string_filters_for(User, 'full_name')
  include_relational_string_filters_for(User, 'id')
  include_date_filters_for('created_on') 

class User < ApplicationRecord
  include GqlScopeHelpers
  include_string_filters_for('full_name')

class SalesRep < ApplicationRecord
  include GqlScopeHelpers
  include_string_filters_for('full_name')
```


**list_consults.rb (GQL Resolver)**


```ruby
module Queries
    module Consults
      class ListConsults < BaseQuery
        type Types::ConsultType.connection_type, null: false
        description 'Filter/View All Consults'

        argument :sales_rep_full_name, Types::Filters::StringFilters, required: false
        argument :user_full_name, Types::Filters::StringFilters, required: false
        argument :user_id, Types::Filters::StringFilters, required: false
        argument :sales_rep_id, Types::Filters::StringFilters, required: false
        argument :created_on, Types::Filters::DateFilters, required: false

        def authorized?(_query = nil)
          is_sales_rep? || is_user? # helper utils from BaseQuery
        end

        def resolve(args = {})
          # scope consults to the current user
          query = ::Consult.context_user(context[:current_user])
          
          # build up the query and apply all filters
          ::Consult.apply_scope_filters(query, args)
        
				rescue StandardError => e
          Sentry.capture_message("GQL: List Consults: #{e}")
          raise GraphQL::ExecutionError, "Unknown Error #{e}"
        end
      end
    end
  end
end
```


**gql_scope_helpers.rb**


```ruby
module GqlScopeHelpers
  extend ActiveSupport::Concern

  module ClassMethods
    # Should match app/graphql/types/filters/string_filters.rb
    def include_string_filters_for(key)
      scope :"#{key}_contains", ->(query) { where("#{key} ILIKE ?", '%' + sanitize_sql_like(query) + '%') }
      scope :"#{key}_starts_with", ->(query) { where("#{key} ILIKE ?", sanitize_sql_like(query) + '%') }
      scope :"#{key}_ends_with", ->(query) { where("#{key} ILIKE ?", '%' + sanitize_sql_like(query)) }
      scope :"#{key}_equals", ->(query) { where("#{key}": query) }
      scope :"#{key}_gt", ->(query) { where("LENGTH(#{key}) > ?", query) }
      scope :"#{key}_gte", ->(query) { where("LENGTH(#{key}) >= ?", query) }
      scope :"#{key}_lt", ->(query) { where("LENGTH(#{key}) < ?", query) }
      scope :"#{key}_lte", ->(query) { where("LENGTH(#{key}) <= ?", query) }
      scope :"#{key}_not_in", ->(query) { where.not("#{key}": query) }
      scope :"#{key}_in", ->(query) { where("#{key}": query) }
    end

    def include_relational_string_filters_for(klass, relational_field)
      key = "#{klass.to_s.underscore}_#{relational_field}"
      join_name = klass.name.underscore.to_sym
      pluralized = join_name.to_s.pluralize

      # Previously had these as .merge klass.send -- some keys collide and conflict with `merge` once compiled to SQL e.g. "full_name"
      scope :"#{key}_contains", lambda { |query|
                                  joins(join_name).where("#{pluralized}.#{relational_field} ILIKE ?", '%' + sanitize_sql_like(query) + '%')
                                }

      scope :"#{key}_starts_with", lambda { |query|
                                     joins(join_name).where("#{pluralized}.#{relational_field} ILIKE ?", sanitize_sql_like(query) + '%')
                                   }
      scope :"#{key}_ends_with", lambda { |query|
                                   joins(join_name).where("#{pluralized}.#{relational_field} ILIKE ?", sanitize_sql_like(query))
                                 }

      scope :"#{key}_equals", lambda { |query|
                                joins(join_name).where("#{pluralized}.#{relational_field}": query)
                              }

      scope :"#{key}_not_in", ->(query) { joins(join_name).where.not("#{pluralized}.#{relational_field}": query) }
      scope :"#{key}_in", ->(query) { joins(join_name).where("#{pluralized}.#{relational_field}": query) }
    end

    def include_date_filters_for(key)
      scope :"#{key}_equals", ->(query) { where("#{key}": query) }
      scope :"#{key}_gt", ->(query) { where("#{key} > ?", query) }
      scope :"#{key}_gte", ->(query) { where("#{key} >= ?", query) }
      scope :"#{key}_lt", ->(query) { where("#{key} < ?", query) }
      scope :"#{key}_lte", ->(query) { where("#{key} <= ?", query) }
      scope :"#{key}_not_in", ->(query) { where.not("#{key}": query) }
      scope :"#{key}_in", ->(query) { where("#{key}": query) }
    en

    # args: [{:name => {:contains => "asdf"}}, {:created_on => {:lt => "2022-09-09"} }]
    def apply_scope_filters(composed_query = self, args)
      args.keys.each do |arg|
        next unless @filterable_args.include?(arg)

        # {:contains => "asdf"}
        hash = args[arg]

        # .send(:name_contains, "asdf")
        hash.keys.each do |key|
          composed_query = composed_query.send(:"#{arg}_#{key}", hash[key])
        end
      end

      # return compiled results
      composed_query
    end
  end
end


```


Alright, I know that’s a lot but let's step through this. 


The first thing you’ll notice is our GraphQL Resolver is SUPER clean with a single helper method. 


`::Consult.apply_scope_filters(query, args)`


Our consult model is fairly clean as well considering. With seven lines of code we’ve supported: 

- All the filter support for Sales Rep Names
- All the filter support for User Names
- All the support to filter through Rep Ids and User Ids
- All the support to match created dates and filter by date ranges

But how — 


The magic lies in our new GQL Scope Helpers file. 


Taking a look back at our original scopes, if you notice, the SQL here doesn’t really change. What does change is the Model name, Field, and Query data the end consumer will pass in. Smells like a function to me… and why stop at one filter, lets support them all! 


The cool thing about using ClassMethods here is that by requiring our new helper the Model is able to run these functions when we go to build and compile. Let’s take another look at the Concern Model. 


```ruby
class Consult < ApplicationRecord
  include GqlScopeHelpers
	... 
  include_relational_string_filters_for(User, 'full_name')  
  include_relational_string_filters_for(User, 'id')
```


When we go to build and run our app with `rails c` you can actually see ALL of the scopes got applied to the model. 


Neat! 


![](https://cms.echobind.com/assets/65b1b296-184f-404c-885b-30fa7ad82dbf)


## So how does this work?


The last magical helper is our `apply_scope_filters` method and `@filterable_args`. Because these methods are all going to be run and compiled with the models, @filterable_args can be defined per Model. Apply Scope Filters is going to take ALL the args passed from our GraphQL endpoint (again… or other). @filterable_args is simply a guard when mapping over the args, if the key does not match one of our scope filters — we continue on. If it does… we are able to do some more magic with `{model}.send` This allows us to call a method, in our case a `scope` on the model, and continue to build our Query until we're finally ready for Active Record to do its thing. 


```ruby
# args: [{:name => {:contains => "asdf"}}, {:created_on => {:lt => "2022-09-09"} }]
    def apply_scope_filters(composed_query = self, args)
      args.keys.each do |arg|
        next unless @filterable_args.include?(arg)

        # {:contains => "asdf"}
        hash = args[arg]

        # .send(:name_contains, "asdf")
        hash.keys.each do |key|
          composed_query = composed_query.send(:"#{arg}_#{key}", hash[key])
        end
      end

      # return compiled results
      composed_query
    end

```


In the end, what we are left with is a composed_query that includes ALL the allowed filters defined. Let's take that for a spin in `rails c` as well. 


![](https://cms.echobind.com/assets/19c3b4c0-1748-4cbe-81d0-e05f530daa3c)


Using this in our GQL Resolver we now know that ANY combination of filters the consumer sends *should pass right through and build up to an efficient Active Record Query. Even better, with tools like `Dataloader` out of the box with `rails-graphql` — we are ensured to not loop and slam our DB for the world by accident. 


## Conclusion 


```ruby
# user.rb
class User < ApplicationRecord
  include GqlScopeHelpers
  include_string_filters_for('full_name')
  # ...
end

# list_consults.rb
module Queries
    module Consults
      class ListConsults < BaseQuery
        type Types::ConsultType.connection_type, null: false

        argument :user_full_name, Types::Filters::StringFilters, required: false
				# other args...

        def resolve(args = {})
          # build up the query and apply all filters
          ::Consult.apply_scope_filters(::Consult, args)
        
				rescue StandardError => e
          Sentry.capture_message("GQL: List Consults: #{e}")
          raise GraphQL::ExecutionError, "Unknown Error #{e}"
        end
      end
    end
  end
end
```


So was all the setup worth it?!


Time will tell, but for this scale project, I believe so. This setup was actually simple to test e2e by ensuring that GQL filters were working as expected and giving us even more confidence in our ClassMethods helper file. 


For now, all I can say is that my dev brain is a lot happier reading a slim model and resolver in comparison to the nested scope chaos it could have been. While building these methods may be overkill for some, I do enjoy the ability to quickly support the requests continuing to come in. The API is still flexible, open, and so far maintainable. That’s all we can ask for.

---

[View on echobind.com](https://echobind.com/post/metaprogramming-filters-rails-graphql)

---

# MVC flavors with Prisma Middleware and Extensions

> We are React and Prisma Fans. Extensions mixed with Prisma’s Middleware functionality are exactly what we needed.

_By Matt Thompson · 2023-01-12_

Here at Echobind, we are huge React and [Prisma](https://www.prisma.io/) fans. We’ve even built our own template called [Bison](https://github.com/echobind/bisonapp) which leverages all of our favorite tools including a [Prisma Factory](https://github.com/echobind/prisma-factory) lib that we are working on re-releasing soon. While these tools are fantastic, coming back over from a non-React stack (Rails at the time) I found myself feeling like something was missing. I kept reaching for full Model classes wanting that MVC feel. While yes, “we aren’t in Kansas anymore Toto” it felt like something I *should* be able to handle at the Model/Database level in our stack. 


I went searching for a way to add helpers, before/after hooks, virtual fields, etc to our Models. While we could create some helper util, add logic somewhere, all the things. My colleague [Alex](https://twitter.com/ralex1993) informed me of some magic Prisma had just released called [Extensions](https://www.prisma.io/docs/concepts/components/prisma-client/client-extensions). This mixed with Prisma’s [Middleware](https://www.prisma.io/docs/concepts/components/prisma-client/middleware) functionality opened the door for MVC heart to experiment with what I had been missing out on. 


## Middleware


 Middleware provides a great way to: 

- Create audit trail logs
- Add a before/after save hook
- Return a virtual field alongside the model

_** As a best practice, leverage the Model and action to avoid running your logic all the time._ 


```typescript
prisma.$use(async (params, next) => {
  if (params.model == 'User' && params.action == 'create') {
    // Logic only runs for the create action and User model
  }
  return next(params)
})
```


## Extensions 


Extensions provided a great way to create new helper methods on the Model itself to mimic a “Class” like feel. For example, on our `User` model, I was able to create a new method called `signUp` that created a set of default relations for that User. Mixed with Middleware, I was also able to conditionally send this new person a Welcome Email and/or Opt-In message for SMS. Again, while we could have all sorts of logic sprinkled around. Having this logic all be together at the Model level is fantastic in my opinion. For me, this solves the “But what if we forget to call ‘x’” concerns and keeps everything bundled and consistent.  


## Conclusion 


It works! 
Admittedly, there are ways to create a `signUp` util that “keeps it all together” without Prisma extensions. That said, I’m still loving having this control at the Prisma/Database level and it makes my MVC brain smile seeing the potential this will have as Prisma and React continue to evolve.

---

[View on echobind.com](https://echobind.com/post/mvc-with-prisma)

---

# Typescript Generics

> TypeScript Generics are a way to pass types just like you would pass parameters. They help us create flexible components that are also type-safe.

_By Jennifer  Watanabe · 2023-01-11_

If you’re learning TypeScript you’ve probably came across Generics. Generics are a way to pass types just like you would pass parameters. The benefits of using Generics is that you can make reusable components that accept different types and are therefore also type safe. Generics are not the same as the `any` type since you will be telling TypeScript what type your Generic is when you pass it in.


First let’s declare an object that we want to use:


```typescript
interface DogBreed {
  averageHeight: number[];
  isGoodDoggo: boolean;
  name: string;
}

// An object that satisfies the DogBreed type
const maltese: DogBreed = {
	averageHeight: [7, 8, 9],
	isGoodDoggo: true,
	name: "Maltese",
};
```


Now let’s make a class that uses the `DogBreed` type:


```typescript
// A class that accepts dogs and keeps track of them
class DogKennel {
	dogs: DogBreed[] = [];
	
	// A function within DogKennel that accepts an object of the type DogBreed and adds it to the dogs array
	admitDog(newDog: DogBreed) {
		this.dogs.push(newDog);
	}
	
	// A function within DogKennel that logs the dogs array to the console
	getAllDogs() {
		if (!this.dogs.length) {
			console.log("The Kennel currently has no dogs.");
			return;
		}
		
		console.log("The Kennel currently has the following dogs:");
		console.log(this.dogs);
	}
}
```


With the `DogKennel` class we can create as many DogKennels as we want and admit some dogs!


```typescript
const PetStoreKennel = new DogKennel();

PetStoreKennel.admitDog(maltese);
PetStoreKennel.admitDog(maltese);
PetStoreKennel.getAllDogs();

const VeterinarianKennel = new DogKennel();

VeterinarianKennel.getAllDogs();

const FosterHomeKennel = new DogKennel();

FosterHomeKennel.admitDog(maltese);
FosterHomeKennel.getAllDogs();
```


This is great if all we had in the world were dogs. But what about these animals?


```typescript
// An object that satisfies the CatBreed type
const tabbyCat: CatBreed = {
  isKindOfMean: true,
  mostRecentlyDestroyedObject: "couch",
  name: "Tabby Cat",
};

// An object that satisfies the ReptileBreed type
const redFootedTortoise: ReptileBreed = {
  diet: ["vegetables", "fruit", "hay", "berries"],
  lifeSpan: 50,
  name: "Tortoise",
};

// An object that satisfies the BirdBreed type
const cockatiel: BirdBreed = {
  canWhistle: true,
  name: "Pretty Bird",
  primaryColor: "#d2e75f",
};
```


How can we rewrite `DogKennel`  to accept these other animals? With Generics we can pass the type we want the class to accept.


```typescript
class Kennel<SomeAnimalBreed> {
	animals: SomeAnimalBreed[] = [];
	
	admitAnimal(newAnimal: SomeAnimalBreed) {
		this.animals.push(newAnimal);
	}
	
	getAllAnimals() {
		if (!this.animals.length) {
			console.log("The Kennel currently has no animals.");
			return;
		}
		
		console.log("The Kennel currently has the following animals:");
		console.log(this.animals);
	}
}

const PetStoreKennel = new Kennel<DogBreed | CatBreed | ReptileBreed | BirdBreed>();

PetStoreKennel.admitAnimal(maltese);
PetStoreKennel.admitAnimal(tabbyCat);
PetStoreKennel.admitAnimal(redFootedTortoise);
PetStoreKennel.admitAnimal(cockatiel);
```


This allows us to add type safety to our classes. So if we tried to add a non-animal to `Kennel` we would get an error:


```typescript
// An object that satisfies the type Vehicle
const camry: Vehicle = {
	make: "Toyota",
	model: "Camry",
	numberOfWheels: 4,
};

// This causes an error:
// Argument of type 'Vehicle' is not assignable to parameter of type 'DogBreed | CatBreed | ReptileBreed | BirdBreed'.
PetStoreKennel.admitAnimal(camry);
```


Because `SomeAnimalBreed` is just a name for a type we can replace it like this:


```typescript
class Kennel<Type> {
	animals: Type[] = [];
	
	admitAnimal(newAnimal: Type) {
		this.animals.push(newAnimal);
	}
	
...
```


But often you’ll see it simplified even further with a `T`:


```typescript
class Kennel<T> {
	animals: T[] = [];
	
	admitAnimal(newAnimal: T) {
		this.animals.push(newAnimal);
	}
	
...
```


You can simplify things further by extending the different Breed interfaces to something even more generalized like `Animal` type and pass that as the Generic to `Kennel` like this: `const PetStoreKennel = new Kennel<Animal>();`


Read my Beginner Blog on TypeScript:


[https://echobind.com/post/converting-javascript-to-type-script-with-react-native](https://echobind.com/post/converting-javascript-to-type-script-with-react-native)


Read more about Generics:


[https://www.digitalocean.com/community/tutorials/how-to-use-generics-in-typescript](https://www.digitalocean.com/community/tutorials/how-to-use-generics-in-typescript)


[https://www.typescriptlang.org/docs/handbook/2/generics.html](https://www.typescriptlang.org/docs/handbook/2/generics.html)

---

[View on echobind.com](https://echobind.com/post/typescript-generics)

---

# An A-Frame State Management Example

> A-Frame is a framework built on top of three.js that makes creating 3D experiences for web much easier.

_By Samantha Shackelford · 2023-01-06_

### Background


Thanks to [Investment Time](https://echobind.com/post/the-roi-of-self-directed-investment-time-for-software-engineers), a couple of coworkers and I embarked on creating a 3D Record Store! This project contained a lot of learning by doing since A-Frame/3D development was new to us. A-Frame is a framework built on top of three.js that makes creating 3D experiences for web much easier.  The challenge that I'd like to focus on describing in this blog post is how to click on a record, display its data, and play its music.


[image](https://s3.us-west-2.amazonaws.com/secure.notion-static.com/812174d9-5bd9-4d45-9736-fdd9f3d27244/Demo.mov?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=AKIAT73L2G45EIPT3X45%2F20230106%2Fus-west-2%2Fs3%2Faws4_request&X-Amz-Date=20230106T211416Z&X-Amz-Expires=3600&X-Amz-Signature=8576037edfa54958ff6f4047eb98ef6f9b57a699f6e160a4574483097e026acf&X-Amz-SignedHeaders=host&x-id=GetObject)


I’ve created this stripped down version of the project on Glitch to contain only the elements necessary to demonstrate how we did this: 


 [https://glitch.com/edit/#!/lime-balanced-dinghy](https://glitch.com/edit/#!/lime-balanced-dinghy)


![](https://cms.echobind.com/assets/6ffd9db8-f0f8-4a6c-82cd-706f92e2fefa)


In the left panel of the Glitch project, you can see/edit the code and in the right panel you can interact with the output selecting an album to play its music.


# Let’s get into it!


### Enabling cursor click events with a camera


First, in order to enable navigating around the scene with our arrow keys and clicking with our 2D browser cursor we created a camera entity and applied a `cursor` property with a value of `rayOrigin: mouse`. 


```html
<!-- Mouse as Cursor -->
<a-camera>
	<a-entity cursor="rayOrigin: mouse"></a-entity>
</a-camera>
```


### Add on-record-click method to Records


![](https://cms.echobind.com/assets/3690c7ca-b576-4b47-ad91-1152085de8be)


Each record on the shelf is its own A-Frame entity. On each of the record entities we attached a custom `on-record-click` handler that we wrote (imported as a script at the top of the HTML file). 


Passed through the `on-record-click` handler is a `jsonData` object which contains the information for the record: song, album, artist & sound. 


```html
<a-entity
   id="cover18"
   gltf-model="#record18"
   shadow="receive: true; cast: true"
	 cursor-listener
   **on-record-click='jsonData: {"song": "Paper Ships", "album": "Dead Mans Bones", "artist": "Dead Mans Bones", "sound": "src:url(https://cdn.glitch.global/e8ce53d8-7f00-41aa-9601-6170b37afa32/paper-ships.m4a?v=1665756945121)"}'**
></a-entity>
```


### Save the music info to state


In order to easily save state, we imported the `aframe-state-component` ([https://www.npmjs.com/package/aframe-state-component](https://www.npmjs.com/package/aframe-state-component)) package:


```html
<!-- Aframe State Component: Manage application state and bind it to parts of the application to automatically react to state changes. -->
<script src="https://unpkg.com/aframe-state-component@6.6.0/dist/aframe-state-component.min.js"></script>
```


When clicking on a record, the `on-record-click` handler parses the JSON object and then calls the `setCurrentSong` function (defined in `state.js`) to store the current `musicInfo` (song, album, artist, sound).


```javascript
AFRAME.registerComponent("on-record-click", {
  init: function () {
    this.el.addEventListener("click", function (evt) {
      
      let json = this.components["on-record-click"].data.jsonData;
      if (json) {
        let musicInfo = JSON.parse(json);
        this.emit("setCurrentSong", musicInfo);
      }
      
    });
  },
});
```


Notice the `emit` function that passes the name of the setState handler (in this case “setCurrentSong”). This comes from the `aframe-state-component` package we imported earlier


### State.js


Where state is stored and setState handlers are defined in the `state.js` file (shown below). Among those handler’s is the `setCurrentSong` function that was just shown above to be passed through the `emit` function when an album is clicked. Here you can see that the `musicInfo` is passed along as well and is set to current state.


```javascript
AFRAME.registerState({
  initialState: {
    buttonText: 'Play Music',
    songIsSelected: false,
    currentSong: '',
    currentAlbum: '',
    currentArtist: '',
    currentSound: ''
    isMusicPlaying: false,
  },
  handlers: {
		**setCurrentSong: function(state, musicInfo) {
      state.songIsSelected = true;
      state.currentSong = musicInfo.song;
      state.currentAlbum = musicInfo.album;
      state.currentArtist = musicInfo.artist;
      state.currentSound = musicInfo.sound;
    },**
    setMusicPlaying: function(state) {
      let newButtonText;
      state.isMusicPlaying = !state.isMusicPlaying
      if(state.isMusicPlaying) {
        newButtonText = 'Pause Music'
      } else {
        newButtonText = 'Play Music'
      };
      state.buttonText = newButtonText;
    }
  }
});
```


### bind__


Thanks to `aframe-state-component` we can also access state and `bind__` its value to A-Frame entities to affect their render output.


This is the UI Panel entity we created in index.html:


```html
<!-- UI PANEL -->
<a-box
  id="menu"
  **bind__visible="isSongSelected"**
  position="1.77 1.57 -3.34"
  height="1.2"
  width="1"
  depth=".001"
  color="black"
  material="opacity: 0.6"
>

  <!-- Current Song Title -->
  <a-entity
    **bind__text="value: currentSong"**
    position=".61 .36 .01"
    scale="2 2 2"
  ></a-entity>

	<!-- Current Artist -->
  <a-entity
    **bind__text="value: currentArtist; color: white"**
    scale="1.5 1.5 1.5"
    position=".36 .25 .01"
  ></a-entity>

	<!-- Current Album -->
  <a-entity
    **bind__text="value: currentAlbum; color: white"**
    position=".12 .149 .01"
  ></a-entity>

  <!-- Play/Pause Music Button -->
  <a-box
    on-button-click
    **bind__sound="currentSound"
    bind__visible="isSongSelected"**
    primitive="box"
    id="button"
    height=".2"
    width=".4"
    depth=".025"
    position="0 -0.15 0.01"
    color="pink"
  >
    <a-entity
      **bind__text="value: buttonText"**
      text="color: black"
      position=".38 0 .025"
    ></a-entity>
  </a-box>

</a-box>
```


Notice that the current song title entity contains a `bind__text` attribute which passes the `currentSong` stored in `state.js` to the `value` of the text attribute. Thus rendering the text of the current song! The same applies to the current artist and album entities.


## Resources

- [Supermedium’s Collection of Aframe Components](https://supermedium.com/superframe/) is a nifty list of packages that appear in a lot of example projects on a-frame’s site.
- Guide for building UI in A-Frame: [https://glitch.com/~aframe-building-ui](https://glitch.com/~aframe-building-ui)
- The aframe-state-component: [https://www.npmjs.com/package/aframe-state-component](https://www.npmjs.com/package/aframe-state-component)

---

[View on echobind.com](https://echobind.com/post/an-a-frame-state-management-example)

---

# Server-Side Translations w/ NextJS

> How I was able to get translations working on the server in Next.js.

_By Matt Thompson · 2023-01-05_

You know the idea: if you have to spend a lot of figuring something out and/or it was hard to find on the interweb… you should probably write about it. If for no other reason than being kind to your future self. So, hello future me 👋🏼! 


Recently I spent way too long trying to get translations to work server-side inside a NextJS API route. I did not expect it to become the issue it did. At first, I blamed the weak coffee, but then I continued to dive in. To my surprise there wasn’t a well-documented answer. I validated some claims in Discord, got a handful of responses that led me down a decent path, and now here I am to share my findings.


## The Issue 


So, what was I trying to do… 


I’ve been working a ton with Twilio lately. I have started pulling together some concrete examples in an app for future us/me. Specifically, in this scenario, I was working with SMS and simply wanted to supply a translated body for the message going out. Easy enough, right? Grab the user's locale, translate the “Welcome, Johnny!” message, and fire away. In previous stacks translations become a class service util and, well, you just use them - anywhere and everywhere - without really thinking too much about it. 


Off I go to do just that. I set up my `public/locale` folder. Created an `sms` namespace with my test message, added to my API call, and… 💥


Huh?! 


Did I miss something in the config?


I decided to validate on screen via the client. 


Yup, that worked?! What the… 


After searching around I came to find out that the majority of React/NextJS pieces are client driven utils. Meaning all that config and setup is meant for the React useHook. There wasn’t a non-client facing utility to be found… or at least the weak coffee was not helping me find it. Then I went hitting all the channels to see what I could be overlooking.


## The Solution 


Create a global i18n instance that can be passed around for both the Server and the client and leverage `i18next-fs-backend` for our API routes. Below you’ll see we have three methods the main `createI18nClient` and two utils I created that wrap the client for quick use `translator` and `translate`. The translator returns the client mapped to the namespace, locale, and translate going ahead and doing the good thing by returning our translated body text.


```typescript
// https://discord.com/channels/752553802359505017/1046900384481951754/1047052679492419614
import path from 'path';
import { readdirSync, lstatSync } from 'fs';

import i18n, { InitOptions } from 'i18next';
import i18nextFSBackend from 'i18next-fs-backend';
// import { i18n as i18nConfig } from 'next-i18next.config';
import { I18n, InitPromise, CreateClientReturn } from 'next-i18next';

let globalInstance: I18n;
const localesFolder = path.join(process.cwd(), '/public/locales');

type TranslatorProps = {
  template: string;
  ns: string[];
  args: object;
  lng?: string;
};

type UseTranslatorProps = {
  ns: string[];
  lng?: string;
};

type CreateInstanceProps = {
  locale?: string;
  namespaces: string[] | readonly string[];
};

const createI18nClient = ({ namespaces }: CreateInstanceProps): CreateClientReturn => {
  let instance: I18n;

  const config: InitOptions = {
    initImmediate: false,
    fallbackLng: ['en'],
    // NOTE: pass in locale to make this dynamic -- originally imported from 'next-i18next.config' compile issue in CI
    // fallbackLng: i18nConfig.defaultLocale,
    ns: namespaces,
    // lng: i18nConfig.locales.includes(locale) ? locale : i18nConfig.defaultLocale,
    lng: 'en',
    // preload for server side -- preload ['en']
    preload: readdirSync(localesFolder).filter((fileName) => {
      const joinedPath = path.join(localesFolder, fileName);
      return lstatSync(joinedPath).isDirectory();
    }),
    backend: {
      loadPath: path.join(localesFolder, '{{lng}}/{{ns}}.json'),
    },
    load: 'all',
    // return empty string instead of key if something went wrong
    saveMissing: true,
    saveMissingTo: 'all',
    missingKeyNoValueFallbackToKey: true,
    parseMissingKeyHandler: (key) => {
      console.log('Missing Key:', key);

      return '';
    },
    // useSuspense to avoid first render issues
    react: { useSuspense: true },
    // debugging info
    debug: false,
  };

  if (!globalInstance) {
    globalInstance = i18n.createInstance(config);
    instance = globalInstance;
  } else {
    instance = globalInstance.cloneInstance(config);
  }

  let initPromise: InitPromise;

  if (!instance.isInitialized) {
    instance.use(i18nextFSBackend);
    initPromise = instance.init(config);
  } else {
    initPromise = Promise.resolve(i18n.t);
  }

  return { i18n: instance, initPromise };
};

export default createI18nClient;

// returns 't' as you would expect
export const translator = ({ ns, lng = 'en' }: UseTranslatorProps) => {
  const { i18n } = createI18nClient({ namespaces: ns, locale: lng });

  return i18n.t;
};

// Just do the good thing... I don't care about my options here.
export const translate = ({ template, ns, args, lng = 'en' }: TranslatorProps) => {
  const { i18n } = createI18nClient({ namespaces: ns, locale: lng });

  const { t } = i18n;
  return t(template, { ...args, ns });
};
```


## In Practice 


Because this import is now global util — they both work consistently the same, as expected! 🎉


### Client Side 


```typescript
import { translator } from '../utils/i18n-translator';
...
const t = translator({ ns: ['common'] });
const welcomeMessage = t('welcome', { firstName });
```


### Server Side 


```typescript
import { translator } from '../utils/i18n-translator';
...
const t = translator({ ns: ['common'] });
const welcomeMessage = t('welcome', { firstName });
```


## Conclusion 


While there may be room for improvement here, I’m happy where this landed. I was able to start translating messages from my API as expected, and I now have a better understanding of NextJS and its translation setup.

---

[View on echobind.com](https://echobind.com/post/server-side-translations-with-nextjs)

---

# 3D Optimization for Web—How I Got a Model From 26MB Down to 560KB

> For Q4 investment time, I worked on creating a scrollable, 3D website with a coworker using R3F. From this project, I’d like to highlight my process for optimizing 3D models for web.

_By Jacob Galito · 2023-01-05_

With my [investment time](https://echobind.com/post/the-roi-of-self-directed-investment-time-for-software-engineers) at Echobind, as well as my own free time, I’ve been slowly learning webGL libraries such as three.js, Mozilla’s/Super Medium’s [A-Frame](https://aframe.io/), Google’s [model-viewer](https://modelviewer.dev/) and, more recently, [React-three-fiber](https://docs.pmnd.rs/react-three-fiber/getting-started/introduction)(R3F).


For Q4 investment time, I worked on creating a scrollable, 3D website with a coworker using R3F. From this project, I’d like to highlight my process for optimizing 3D models for web. From that process, I was able to reduce the main 3D model from 26MB down to 560KB. 


### **What is React-three-fiber?** 


Frameworks such as[ ](https://threejs.org/)[three.js](https://threejs.org/) make programming with webGL easier. Furthermore, libraries such as R3F—which abstracts three.js more—make working with 3D experiences on the web even easier. 


[Three.js example](https://codesandbox.io/s/three-js-example-0zgl3b)


[R3F example](https://codesandbox.io/s/react-thee-fiber-example-qtd9gk)


### **Load time issues**


One of the challenges that we faced while working on this scene was how to minimize load time on the client side. Our first approach was to create a load screen. However, since our 3D models files size was too large (26MB),  it was taking too long to load. When it finally loaded, the interactive animations were slow and choppy. To correct these issues, I wanted to find a way to minimize the file size.


### **My approach to the problem**


The primary contribution to the large file size was the complexity in our 3D model as well as its associated textures. So, I took on the responsibility of exploring how to minimize our loading time by optimizing our 3D model. I also discovered that there were too many materials and meshes in our scene. By minimizing both of these components, it would reduce the file size of the exported model. Here are the steps that I took:


## Step 1 - Optimizing meshes, deleting polygons and combining objects


![](https://cms.echobind.com/assets/01f7ee64-56a8-46da-96e8-073aeeda85a3)


### **Optimization**


Since we were concerned about this scene not running well on the web, I wanted to remove any potentially unnecessary polygons on the meshes in the blender project. This was done using the decimation modifier. I typically start with reducing the mesh ratio to 0.5 and reduce lower if it doesn’t cause any unwanted artifacts. This step was repeated for most of the meshes.


### **Deleting Polygons**


![](https://cms.echobind.com/assets/f9175b04-f4fe-40be-8edc-d8a8276e077c)


In an effort to help with unwrapping, as well as removing anything that won’t be showing up in the final view, I removed all polygons that were at the bottom of all meshes, such as the bottom portion of the snow mesh. This was done by going into edit mode > face selection using the select lasso. This step was repeated for most of the meshes.


### **Combining meshes**


In order to get started with combining meshes, I needed to determine which meshes make sense to combine. In the end, I combined all objects in the scene that are on top of the snow on the ground and floor meshes—minus the picture frame. I decided to do this because they would all fit into the same UV space well and wanted them all to have the same size materials. The snow took up a considerable amount of space and adding it to the same UV space would reduce the scale of all of the objects; which would lower the quality of the textures for the objects as well. From there, I wanted to combine all meshes associated with the picture frame—minus the glass and photo—since I wanted to be able to add as much quality into the photo image. The glass needed its own material to prevent any transparency issues will other parts of the scene that didn’t need transparency. I renamed the meshes appropriately to their contents: `objects, frame, glass, photo, floor, snow` as well as their associated materials.


![](https://cms.echobind.com/assets/51d7b3f2-fe52-4417-8e8e-8e78da6875fa)


This resulted in reducing the scene from 65 individual meshes to 6 objects of related meshes. Combining meshes actually increases the blender file size, but helped me to remove any potential duplicates in the scene and quickly select a large amount of polygons in the scene in order to manipulate them easier for the following steps.


![](https://cms.echobind.com/assets/c5e18905-c7dd-4f07-b5d3-8e9c1d1badf8)


## Step 2 - UV Packing


Before I was able to unwrap and pack the UVs together, I needed to associate all of the polygons of each mesh into one material. At this point there were a lot of materials within the project. So, first what needed to be done was to remove all unused `orphaned` materials. By deleting all `orphaned` materials, I reduced the materials in the scene from 71 materials down to 6 materials.


Here’s the results of the unwrapped `objects`:


![](https://cms.echobind.com/assets/faf98882-b6d0-4bcc-a921-b1d8531c7d5f)


Here’s the results of the unwrapped picture `frame`:


![](https://cms.echobind.com/assets/cabf6d32-9423-406d-8190-2805222d7eee)


All of the remaining meshes were unwrapped as well.


## Step 3 - Material IDs


Material ID grants you the ability to quickly select a section of a mesh that you have determined will have a specific material added to that section. Instead of adding several materials to one mesh, which can add more to the files size of the model, we can take advantage of material IDs and translate these selections of a mesh into one single texture that can be used in step 5.


To do this, I created various materials with high contrasting colors. After all of the polygons of the `objects` mesh and picture `frame` mesh had various colored materials added to it, I then baked the colors out so they were added to the UV coordinates of the meshes. 


![](https://cms.echobind.com/assets/2880b6c7-4381-4aaf-8b67-4764de20f4f5)


![](https://cms.echobind.com/assets/26aa6e9d-6772-4d27-b665-180714b7c0fd)

![](https://cms.echobind.com/assets/a2fa07cf-59d0-4c22-8839-fd72f050fdab)




## Step 4 - Baking Material IDs


The process of baking, for this purpose, is to take all of the color information, from the various colored materials I had just added, and project those colors onto a texture. 


This is the resulting material ID maps that were baked out, as shown above. Some things to note before baking materials in Blender:

- Change the render mode to `cycles`
- Turn off any `direct` and `indirect` lights
- Ensure you have selected the diffuse map in shaders viewport
- Select the duplicate mesh that has the colors added
- Have the mesh with the unwrapped UVs be your active selection
- Ensure that `Bake Type` is `Diffuse`
- Press `Bake`

![](https://cms.echobind.com/assets/ad5dba1f-c181-4567-9b45-82c7246a437a)


![](https://cms.echobind.com/assets/036c456a-a307-4592-97f5-6d16cc673244)


![](https://cms.echobind.com/assets/fd329e66-6c86-4a37-bda9-b4baf4245ece)


![](https://cms.echobind.com/assets/823d0641-b929-4b8c-8df7-b8f720ddae0a)


The final step in Blender was exporting everything as .fbx as well as export out all material ID textures.


## Step 5 - Material Creation in Substance Painter


![](https://cms.echobind.com/assets/83a9692b-4b8e-4b06-9cac-37f2caa121a9)


Substance Painter is one of my favorite 3D tools. It can make the texturing process so much fun and contextual. It’s basically photoshop for 3D models.


### **Set up**


![](https://cms.echobind.com/assets/67f39b59-726f-4c2b-ae9a-8f53a498bf80)


While importing the .fbx, I also imported in the material ID textures for `objects` mesh and picture `frame` mesh. 


### Masking and selecting material IDs


![](https://cms.echobind.com/assets/2daf818b-cc37-4db0-8407-5af0895c0225)


After baking the mesh maps (normals, world space normals, ambient occlusion, curves, etc.) I then created folders for each color of the `objects`mesh and picture `frame` mesh and used a mask to select each material id to attribute to the mask. This is how we’re able to add different colors and textures to part of a mesh.


![](https://cms.echobind.com/assets/c81a1e44-af56-4a4c-bdef-8ec2ebe80560)


### Exporting and **Combining baseColor and ambient occlusion**


![](https://cms.echobind.com/assets/ec784921-8ff6-4edb-85f6-46afca063d62)


Since the desired result we’re going for is not so realistic, I decided to only export out the `baseColor` and `ambient occlusion` but since I wanted to add the shadow/lighting from ambient occlusion to the baseColor I needed to combine the two into one texture. In order to do this, I needed to add a new preset in the `export textures` viewport.


## Step 6 - Adding baseColor in Blender


![](https://cms.echobind.com/assets/97bb36fb-f923-4b36-a529-9b264048b862)


This step is really quick. I just needed to add the baked texture results from Substance Painter and add them to each material’s `baseColor`. After that, I exported everything as a `.glb`. At this point, the exported file size was **5.1MB**.


![](https://cms.echobind.com/assets/80edac58-9a59-4351-81b6-b11e73db4557)


## Step 7 - glTF Compression


### [gltf.report](http://gltf.report) tool


Now that the model is textured and exported from Blender, I uploaded the model to [gltf.report](http://gltf.report) to compress the `.glb` more. 


After uploading the model in to gltf.report, I then clicked on the `script` tab. From there I reduced the texture size from 1024 x 1024 down to 128 x 128 and clicked `Run` then `Export` afterward.


![](https://cms.echobind.com/assets/12826323-405d-414e-ab3f-8265cb738fbe)


The results got the file from **5.1MB** down to **3MB**. The resulting reduced mesh was then added to the project under `/public/meshes/`.


### **gltfjsx command-line tool**


Before running the next step, it’s important to install `nvm` and install an earlier version of node. Otherwise, you’ll probably get error when running `gltfjsx`.


```c
NVM ls
NVM use 14.20.0
```


Before I could run the command-line tool, I needed to change directories from the project folder to where the mesh is located. Otherwise the results would be added to the project folder.


```c
cd /public/meshes/
```


Now, I was able to run `gltfjsx`


```c
npx gltfjsx main_scene.glb -T
```


The result of running `gltfjsx` provides a smaller `.glb` file as well as a `react.js` component of the 3D model. The results reduced the file from **3MB** down to **581KB.** 


If you don’t want to mess with installing gltfjsx, and earlier node versions, you could also go to [https://gltf.pmnd.rs/](https://gltf.pmnd.rs/) but results may vary.


And here’s the final result at **560KB**


![](https://cms.echobind.com/assets/b885b64b-a264-4f16-aeae-564a5abd7b88)


Here are the results from `gltfjsx` for `main_scene.js`:


```javascript
/*
Auto-generated by: https://github.com/pmndrs/gltfjsx
*/

import * as THREE from 'three'
import React, { useRef } from 'react'
import { CycleRaycast, useGLTF } from '@react-three/drei'
import { GLTF } from 'three-stdlib'


export function Main(props) {
  const { nodes, materials } = useGLTF('/meshes/main_scene.glb')
  return (
    <group {...props} dispose={null}>
      <mesh geometry={nodes.floor.geometry} material={materials.floor} position={[-0.01, 0, -0.61]} />
      <mesh geometry={nodes.Snow.geometry} material={materials.Snow} position={[0, 0, -0.61]} />
      <mesh geometry={nodes.objects.geometry} material={materials.objects} position={[1.13, 0.28, 0.53]} rotation={[-Math.PI, -0.09, -Math.PI]} />
      <mesh 
        // onClick={() => {console.log('frame clicked')}}
        geometry={nodes.frame.geometry} material={materials.frame} position={[-0.02, 1.27, -1.89]} rotation={[Math.PI, -0.02, Math.PI]} />
      <mesh 
        onClick={() => props.setModalIsOpen(true)}
        geometry={nodes.photo.geometry} material={materials.photo} position={[-0.02, 1.24, -1.89]} rotation={[Math.PI, -0.02, Math.PI]} scale={0.09} >
          {/* testing out how to add cursor pointer based on mouse over the photo */}
          {/* docs here https://github.com/pmndrs/drei#cycleraycast */}
          {/* example use of useCursor https://codesandbox.io/s/ny3p4?file=/src/App.js:977-983 */}
          <CycleRaycast
            preventDefault={true} // Call event.preventDefault() (default: true)
            scroll={true} // Wheel events (default: true)
            keyCode={9} // Keyboard events (default: 9 [Tab])
            onChanged={(objects, cycle) => console.log(objects)} // Optional onChanged event
            onPointerOver={() => {console.log('hovered')}}
          />
        </mesh>
      <mesh geometry={nodes.glass.geometry} material={materials.glass} position={[-0.02, 1.27, -1.89]} rotation={[0, 0.02, 0]} />
    </group>
  )
}

useGLTF.preload('/meshes/main_scene.glb')
```


[Here’s the full 3D website project](https://holidaycard.vercel.app/)


## Thanks


We wouldn’t have been able to learn this process—among everything R3F and three.js—if it wasn’t for Bruno Simon’s new R3F lessons, and Paul Henschel’s Gumroad course. Thank you both for sharing your knowledge!


### Resources


[three.js - JavaScript 3D library ](https://threejs.org/)


[A-Frame - Make WebVR](https://aframe.io/)


[3D Model-Viewer Embed ](https://modelviewer.dev/)


[React Three Fiber Documentation](https://docs.pmnd.rs/react-three-fiber/getting-started/introduction)


[Blender how to Reduce Poly Count and Bake Textures](https://youtu.be/Yx9TvvnxCAM)


[What are colour IDs and how do we use them?](https://youtu.be/4tbE5dp4-Mo)


[I wish I knew this before using React Three Fiber](https://youtu.be/DPl34H2ISsk)


[gITF Report ](https://gltf.report/)


[GitHub - pmndrs/gltfjsx: Turns GLTFs into JSX components ](https://github.com/pmndrs/gltfjsx)


[GLTF → React Three Fiber ](https://gltf.pmnd.rs/)


[Bruno Simon’s course](http://threejs-journey.com/)


[Bruno’s Twitter](https://twitter.com/bruno_simon?s=20&t=8hNOPK57upYJuhYW3EhYow)


[Paul Henschel’s course](https://0xca0a.gumroad.com/l/B4N4N4S)


[Paul Henschel’s twitter](https://twitter.com/0xca0a?s=20&t=8hNOPK57upYJuhYW3EhYow)

---

[View on echobind.com](https://echobind.com/post/3D-Optimization-for-Web-26mb-down-to-560kb)

---

# How to Use Notion Databases

> Notion’s databases offer more substantial spreadsheet functions to structure and track large datasets .

_By Claire Surma · 2023-01-05_

Our fully-remote Echobind team relies on Notion for internal process documentation. We are fans of the tool because it allows for easy collaboration and manipulation of data. As a Q4 initiative, we updated internal checklists so we can start 2023 off with streamlined and consistent processes. To do this, we leveraged Notion’s databases because they offer more substantial spreadsheet functions to structure and track large datasets. 


## This article walks you through:

- How to Create a Table Database
- An Overview of the Five Database Views
- How to Filter Your Database Properties

---


## How To Create a Table Database in Notion

1. Click `New Page` found at the bottom left of your Notion screen
2. Select `Table` from the database options in the  New Page menu.

![](https://cms.echobind.com/assets/d972947a-8eb7-41c1-bb30-717de4886bfc)

3. Enter pieces of content you want to track into the first column. *Unlike spreadsheets, each content cell in the first column can open up into its own Notion page where you can view all properties and add additional notes.

![](https://cms.echobind.com/assets/fb50aaab-a4a4-41b7-989d-21f42c0961ea)

4. For the remaining columns, you can add properties you want to include in your database by clicking the `+` on the first row. You can edit property names and type by clicking on the current title. My favorites include:

	**Select Tags**: To easily sort the status of the to-do. 


	![](https://cms.echobind.com/assets/22818fb6-6cd9-4ca0-b630-3944639d3948)


	**Due Dates:** To visualize and track when tasks must be complete. You can even use notion to set reminders. 


![](https://cms.echobind.com/assets/c0907987-9c53-44b7-93d2-16049eb46355)

   **Person Responsible:** To ensure everyone is aware of who is taking lead on tasks.


![](https://cms.echobind.com/assets/f9244218-5a77-4d49-9950-83f19d95cf04)


---


## Overview of Notion Database Views


Once you enter the information you want to track in your database, you can add additional database views by clicking the `+` to the right of your current table view. You can add multiple views to the same database. This is helpful to view the same information in different ways and allows you to quickly navigate between views to fit your needs. 


![](https://cms.echobind.com/assets/4e285150-7491-4bd1-8278-443b3a99c184)


Each of the view options will restructure the information you inputted in the original table view. These views include: 

1. **Board:** This view will structure your data into a kanban board for easy project planning and flow tracking.

![](https://cms.echobind.com/assets/a56dcc68-652e-4f7f-8cf6-306aaee844a2)

1. **Timeline**: This view will show your data in a gantt chart for project scheduling and data planning.

![](https://cms.echobind.com/assets/86324b60-0792-440c-8678-513f35344cc7)

1. **Calendar:** This view inputs your data into a calendar month for event planning and scheduling.

![](https://cms.echobind.com/assets/4ab764a1-8072-435e-83d1-8b44c19eddd9)

1. **List:** This view is a simplified list of all pieces of content you track in the first table view column for bookmarks and notes.

![](https://cms.echobind.com/assets/123ea2c2-3d72-4bf5-b670-84b3bf327dc5)

1. **Gallery:** This view shows a grid of cards that can be helpful for mood boards, index cards, and recipes. Each card can be edited to show images contained in the `Files & media` property or content inside each page.

![](https://cms.echobind.com/assets/51e531ab-bc16-4f51-90e8-db93b8b721fd)


---


## How to Filter Your Database Properties 


Within any of the database views, you can add filters to easily sort and categorize your data set based on inputted properties. These filters can be simple (based on one property) or advanced (dependent on multiple property criteria).


![](https://cms.echobind.com/assets/151e401c-8a06-49f2-8ec9-a1b247021202)


To add a filter in your database:

1. Click `filter` at the top right
2. From the dropdown, select the property to filter by.
3. This filter will now be listed at the top of your database. You can then click the property filter to choose how you’d like to filter your view.

![](https://cms.echobind.com/assets/f29e6210-784f-4826-8106-2dea094b2406)

1. When one filter or more filter has been applied, you can add another by clicking `+ Add Filter` at the top of your table.

There is no limit to the number of filters you can apply!

---

[View on echobind.com](https://echobind.com/post/how-to-use-notion-databases)

---

# Test Stripe Subscriptions with Test Clocks

> Testing Stripe Subscription is tricky. Test clocks are like micro-universes that can simulate any advancement in time.

_By Alex Anderson · 2023-01-05_

**tl;dr**: Testing Stripe Subscription is tricky. Test clocks are like micro-universes that can simulate any advancement in time. Any customers created in the test clock universe, and any subscriptions attached to those customers, participate in the time travel.


[Stripe Subscriptions](https://stripe.com/billing) provide an easy way to have customers pay on a regular basis. There’s a lot of opportunity for complicating them, though. Subscriptions support trial periods, when the customer isn’t charged for a number of days, or [Subscription Schedules](https://stripe.com/docs/billing/subscriptions/subscription-schedules) which let you change the products or discounts on a subscription.


Testing these features is tough since we can’t control the flow of time, which has a pesky habit of passing at one second per second. Theoretical time travel methods, like [yeeting yourself at the speed of light](https://en.wikipedia.org/wiki/Twin_paradox), likely won’t help in this situation.


Fortunately, Stripe Test Clocks give us a way to control the flow of time for specific subscription objects.


### [Test Clocks](https://stripe.com/docs/billing/testing/test-clocks)


There are a few steps to use test clocks:

1. Go to the Stripe dashboard and turn on test mode.
2. [Create a test clock](https://dashboard.stripe.com/test/test-clocks).
3. Create a customer in that test clock.
4. Create a subscription of that customer.
5. Advance the test clock into the future by a number of days or months.
6. Check the results.

All of this can be done from the Stripe API as well. Just pass a `test_clock` parameter when creating your Stripe customer, and any subscriptions attached to that customer will advance with the test clock.


I recently needed to test a complicated subscription behavior. The app needed the ability to skip a customer’s subscription payment for one month. It did this with subscription schedules — it would apply a one-month free trial to the subscription while pushing the end date back by a month. So a customer with a 6 month subscription that skipped two months of payments would still only pay 6 times, with the payments split across eight months.


![A list of invoices showing the initial payment and then six months of subscription payments with two skips](https://cms.echobind.com/assets/703a7e5b-7a29-4075-9718-3c97d0ab421f)


I tested this by first creating a test clock and a customer in that test clock. I took the customer ID and manually inserted it into my apps test database for a new test user.


![](https://cms.echobind.com/assets/2bbfdc0a-01b0-474a-915e-fc43418a4840)


Now anything that I do in the app as that customer, including creating new subscriptions, will be included in the Stripe Test clock. I created a 6 month subscription, which I could see in the Test Clock dashboard.


![](https://cms.echobind.com/assets/226d4266-168a-4c40-a771-4d11eedb151b)


Next, I used the “Skip Payment” feature in my app, which updated the subscription schedule like I described above. I checked the subscription to see the month long trial added and the end date pushed back by a month.


Then to make sure everything sorted out correctly, I advanced my test clock by a few months and checked the subscription again. 


When I initially built this feature, I found a bug that added a prorated amount to the subscription because of the mid-subscription trial period. If I hadn’t used test clocks to test this feature, the bug would have persisted to production causing customers to overpay.


After advancing the clock a few times, I checked the end state of the subscription. Once I found all of the payments and skipped months exactly the way I expected, I knew the feature was ready to ship.

---

[View on echobind.com](https://echobind.com/post/test-stripe-subscriptions-with-test-clocks)

---

# Extending Types for Prisma Extensions in NextJS

> The issue is that now the type

_By Matt Thompson · 2023-01-04_

If you read my [previous post](https://echobind.com/post/playwright-with-next-auth), you’ll note that I was very excited to try out Prisma’s new [Extensions](https://www.prisma.io/docs/concepts/components/prisma-client/client-extensions) alongside their [Middleware](https://www.prisma.io/docs/concepts/components/prisma-client/middleware) and try out various use cases. When test driving I did hit a snag rebuilding the Types for our new extension to pull through. 


If you are running Prisma with NextJS you’ve probably followed this initial best practice doc: [https://www.prisma.io/docs/guides/database/troubleshooting-orm/help-articles/nextjs-prisma-client-dev-practices](https://www.prisma.io/docs/guides/database/troubleshooting-orm/help-articles/nextjs-prisma-client-dev-practices)


Here we define `prisma` in the `global` object so that we don’t create a bazillion instances of Prisma and have the world crashing down on us. If you are using Typescript, this `global` instance was probably Typed. in our case we had: 



```typescript
declare global {
  // eslint-disable-next-line no-var
  var prisma: PrismaClient | undefined;
}
```


## The Issue 


The issue is that the type `PrismaClient` has no clue about our new Extensions or the types within. In this use case, we are attempting to create a new `signUp` method on the `User` model.


```typescript
const extendedPrisma = prisma.$extends({
    model: {
      user: {
        async signUp(args: SignUpArgs): Promise<UserWithRelations> {
          return await prisma.user.create({
            ...args,
          });
        },
      },
    },
  });
```


So how do we fix this?…


## The Solution


Turn `const prisma` from the previous example into a function that returns the newly created `extendedPrisma` context. When setting the global prisma value we use this value and Type instead. Now when we import `prisma` it should include our new model action `signUp` and type validations as seen below.


### The Code


```typescript
import {
  Prisma,
  PrismaClient,
  Profile,
  User,
} from '@prisma/client';

export const defaultUserSessionIncludes = {
  profile: true,
} as Prisma.UserCreateArgs['include'];

export type UserWithRelations = User & {
  profile: Profile;
};

// Set default prisma logs. More logs in debug mode.
const logOptions: Prisma.LogLevel[] = process.env.DEBUG ? ['query', 'error'] : ['error'];

type UserCreateArgsWithProfile = Omit<Prisma.UserCreateArgs['data'], 'profile'> & {
	// Require Profile for signup  
	profile: Prisma.UserCreateArgs['data']['profile']; 
};

// mimics Prisma.UserCreateArgs
type SignUpArgs = {
  data: UserCreateArgsWithProfile;
  include?: Prisma.UserCreateArgs['include'];
};

const extendedPrismaClient = () => {
  const prisma = new PrismaClient({
    log: logOptions,
  });

  const extendedPrisma = prisma.$extends({
    model: {
      user: {
        async signUp(args: SignUpArgs): Promise<UserWithRelations> {
          return await prisma.user.create({
            ...args,
          });
        },
      },
    },
  });

  return extendedPrisma;
};

export type ExtendedPrismaClient = ReturnType<typeof extendedPrismaClient>;

/**
 * Instantiate prisma client for Next.js:
 * https://www.prisma.io/docs/support/help-articles/nextjs-prisma-client-dev-practices#solution
 */

declare global {
  // eslint-disable-next-line no-var
  var prisma: ExtendedPrismaClient | undefined;
}

export const prisma = global.prisma || extendedPrismaClient();

if (process.env.NODE_ENV !== 'production') {
  global.prisma = prisma;
}

export async function disconnect() {
  await prisma.$disconnect();

  return true;
}

export async function connect() {
  await prisma.$connect();

  return true;
}
```


![](https://cms.echobind.com/assets/03b90276-0ad6-4326-91aa-5a23880b80cd)


### If you are using Next-Auth


One other note if you are using Next-Auth. 
We kept hitting a snag with the types for Next-Auth’s `PrismaAdapter`


Again, it expects a type of `PrismaClient` but we want to pass our new `ExtendedPrismaClient` type instead. 

There was a weird type of error trying to recast this for some reason complaining about Prisma’s `$use` missing on our type. Remembering this is still in the **Experimental Phase.** We didn’t try to dive in too hard here, rather we cast as `unknown` first before passing along the types expected for the adapter. While not ideal, it does work and is something we’ll monitor as Prisma continues to wrap this feature up. 


```typescript
export const authOptions: NextAuthOptions = {
  adapter: CustomPrismaAdapter(prisma as unknown as ExtendedPrismaClient),
  ... 
}

function CustomPrismaAdapter(p: ExtendedPrismaClient) {
  const prismaAdapter = PrismaAdapter(p as unknown as PrismaClient);
...
}

```


## That’s all folks!


Remember to restart that Typescript Server folks. 🙂
I kept battling this a few times only to realize I needed to “turn it off and on again”.  Once set, you’ll be ready to keep tacking on new extensions and middleware!

---

[View on echobind.com](https://echobind.com/post/extending-types-for-prisma-extensions-in-nextjs)

---

# Creating a Brand Guide From Scratch: Documenting Echobind’s New Visual Identity

> Echobind launched a new website and visual identity near the end of 2022, and with that came the need for a brand guide to help all us use our brand assets in a way that consistently communicates who we are.

_By Kaila VanSumer · 2023-01-04_

The past few months, Echobind's design team has been hard at work creating a new brand guide for the company. We launched a new website and visual identity near the end of 2022, and with that came the need for a brand guide to help all employees use our brand assets in a way that consistently communicates who we are to potential clients and new hires.


## **What is a Brand Guide?**


A brand guide is essentially a manual for a company's brand. It includes all of the important information about the brand's visual identity, such as the logo, colors, typography, and voice and tone. It's important for a company to have a brand guide because it helps ensure that their brand is being presented consistently across all channels and platforms. Brand consistency drives brand recognition and helps build trust with clients. When a brand is consistently presented, it becomes easier for customers to recognize and remember, which can lead to increased loyalty.


## **How We Created Our Brand Guide**


### Auditing Our Existing Brand


We started with a brand audit. We used [Figjam](https://www.figma.com/figjam/) to collect our previous brand guides, our website redesign files, and other brand decks for inspiration. 


Here’s what the Figjam file looked like:


![](https://cms.echobind.com/assets/cab1bbe4-e743-4741-8aa3-dc503fc9ad9d)


### Defining the Outline


Once we completed our audit, we outlined the sections we wanted to include in our new brand guide. Many brand guides include more detailed sections on things like target market, buyer personas, illustration, iconography, and other topics, but we narrowed our list down to only the essential parts of our brand that were directly relevant to the brand collateral our employees create on a regular basis.


Here’s the table of contents we decided on:


![](https://cms.echobind.com/assets/5feba655-750c-4477-8c07-67c6c49b53a7)


### Writing the Content


Next, we wrote the content for each section and designed slides using [Figma](https://www.figma.com/) (our favorite design and prototyping tool), dropping in helpful visuals and assets along the way. We organized the slides in Figma from left to right, giving a title slide to each section.


Here’s what the work in progress looked like:


![](https://cms.echobind.com/assets/4a4d584a-26b3-44ed-a0bb-a0d4d2cc0c8f)


In addition to guidelines about our brand's visual identity, we also included some general tips on how to improve your design skills. We knew many of the employees who would be using this guide would not be full-time designers. Adding general tips empowers our non-designer colleagues to create with confidence without feeling like they need to ping our design team before sending out a newsletter or posting to social media.


Here’s the short list of design tips we included:


![](https://cms.echobind.com/assets/5a1ad18f-79b6-4ac7-ba5d-8915b9780c98)


Where appropriate we linked to useful assets like our repository of approved logos and our component library in Figma. We also wrote content on how to use the guide to make it easy to navigate based on what you’re trying to accomplish - sort of a Choose-Your-Own-Adventure Brand Guide.


While we still need to write a section for imagery and accessibility, we’ve made a lot of progress on putting together a guide that helps define the most important parts of our brand and makes it easy for all Echobind employees to use our brand assets correctly.


### Our 2022 Brand Guide


<iframe style="border: 1px solid rgba(0, 0, 0, 0.1);" width="800" height="450" src="https://www.figma.com/embed?embed_host=share&url=https%3A%2F%2Fwww.figma.com%2Fproto%2FHaGFh8s0z985sTsIAgxFiv%2FEchobind-Brand-Guide-2022%3Fpage-id%3D0%253A1%26node-id%3D2%253A2%26viewport%3D-1645%252C464%252C0.75%26scaling%3Dcontain" allowfullscreen></iframe>


### Free Brand Guide Checklist


If you are creating a brand guide of your own we’ve created a free Brand Guide Checklist that you can get below. If you use it, be sure to tweet us [@echobind](https://twitter.com/echobind) with a picture of your own brand guide.

[Download Brand Guide Checklist](https://www.dropbox.com/s/dfktgrev6nxbipv/Brand%20Guide%20Checklist.pdf?dl=0)

---

[View on echobind.com](https://echobind.com/post/creating-a-brand-guide-from-scratch)

---

# Echobind’s Virtual Holiday Event

> There are many fun options for virtual holiday celebrations, and our team landed on a gingerbread house competition this year.

_By Krystalyn Bauer · 2022-12-22_

The holidays are a wonderful time for celebrating and gathering, and being a fully remote team should be no exception.   There are many fun options for virtual holiday celebrations, and our team landed on a gingerbread house competition this year.  As a team of engineers, designers, and strategists, this was right up our alley. 


To spice it up, we found a few different styles of gingerbread house kits from one retailer: a Barn, Camper and Candyland house.  The team chose their own style, we coordinated the purchase, and the competition allowed for any additions.  Some of the gingerbread houses collapsed under pressure, some of them were impressively built just like the display, and some of them were imagined into incredibly unique and creative structures. 


We voted on three winners who received prizes, but the magic of this event was really in the anticipation of the competition and sharing our displays. Being able to step away from our screens and use our creativity and skills in a fun way was a gift in itself.  We would definitely recommend this holiday event 10/10 and will be doing again.  


Even if a gingerbread house competition is not quite your team’s style, finding time to gather your team to celebrate the holidays is a great way to boost morale, lift spirits and end the year on a high note. 


Check out some of our awesome gingerbread builds, and have yourself a happy little holiday!


![](https://cms.echobind.com/assets/d41ba104-b55f-4a55-9aba-89e6d101ffa5)

---

[View on echobind.com](https://echobind.com/post/virtual-holiday-event)

---

# Instant Site Updates with On-Demand Revalidation and Directus

> Live the CMS dream by having your changes instantly appear whenever you update your CMS while not sacrificing page load speeds.

_By Alex Anderson · 2022-12-15_

Everybody loves a fast website, but there’s a balance between page speed, capabilities, and developer experience. For a lot of websites, a Static Site Generator like Next.js ticks all the right boxes. They essentially pre-cache every page in the site at build-type. But that’s also the biggest downside to SSGs — long build times.


When your website pulls in data from many remote sources, it’s tough to know what pages changed and which stayed the same. So they just build all of them. When your site is based on lots of rapidly-updating data with a lot of pages, that’s a recipe for agonizingly long build times.


Next.js has a bunch of features to help with this. `getStaticPaths` lets you choose which pages to pre-build and which to generate at runtime when a user requests them. And [Incremental Static Regeneration](https://nextjs.org/docs/basic-features/data-fetching/incremental-static-regeneration#on-demand-revalidation) will show visitors the pre-built pages while generating a fresh version in the background on a revalidate interval.


```javascript
export const getStaticProps = async (context) => {
  const data = await fetchBlogData(context.params.slug);

  if (!data) {
    return { notFound: true };
  }
  // Revalidate the page at most once every 60 seconds
  return { props: data, revalidate: 60 };
};
```


It’s a great middle-ground solution - users still get fast page loads and they’ll eventually get the freshest data. But with a pull-based architecture like this, there’s not a lot more we can do to make this load faster. Instead, we need some kind of notification from our data providers that certain pages need to be updated.


### [On-Demand Revalidation](https://nextjs.org/docs/basic-features/data-fetching/incremental-static-regeneration#on-demand-revalidation)


For the longest times, static hosts have offered webhooks that let CMSs and other data providers say when a site should be rebuilt with new data. For example, a new blog post is added, the webhook is called, the site is rebuilt, and after a time the blog post is live.


On-Demand Revalidation is a feature of Next.js that takes this idea and lets you target specific pages with surgical precision. Instead of a webhook for the entire site, On-Demand Revalidation starts in a Next.js API route. In it, we can call a special API on `res.revalidate` which lets us pass the page path to revalidate. When we call it, Next.js will revalidate just that page in mere moments, publishing the freshest data possible in mere moments.


```javascript
export default async function handler(req, res) {
  // Check for secret to confirm this is a valid request
  if (req.query.secret !== process.env.REVALIDATION_SECRET) {
    return res.status(401).json({ message: "Invalid token" });
  }

  try {
    await Promise.all([
			res.revalidate(`/post/${req.query.post}`), 
			res.revalidate("/blog")
		]);
    return res.json({ revalidated: true });
  } catch (err) {
    // If there was an error, Next.js will continue
    // to show the last successfully generated page
    return res.status(500).send("Error revalidating");
  }
}
```


Notice that we’re calling `res.revalidate` for both the individual post page and for the blog index page. This makes it so any new blog post or updated titles correctly appear in the blog index. If we had separate index pages for each blog post tag, we’d want to revalidate those too.


Now we just need a way to call this whenever we change a post.


### Calling Webhooks with Directus Flows


Every CMS and data provider is different. Hopefully yours has some way to perform some logic, like calling a webhook, when a change happens to some part of data. In [Directus](https://directus.io/), we do this with flows.


![](https://cms.echobind.com/assets/edeaf94f-c8e7-4398-9bfa-c378cc7f8d9c)


Flows allow us to respond to _triggers_ by chaining _operations_ to each other. We’ll configure an Action trigger which listens for the `item.create`, `item.update` and `item.delete` scopes on the `Posts` collection.


![](https://cms.echobind.com/assets/5771a402-d66c-47cd-9bcf-6bbcc4359343)


> Debugging flows can be a little bit tricky. Fortunately, the flow’s sidebar shows a running log of all of the times the flow runs. This can help track the changes in the data as the flow progresses through the operations.


Next, we need to fetch the post object from the database so we know what slug to send to our revalidate API. This is included in the `item.create` actions, but not always for `item.update`, so we need to grab it ourselves. For that, we’ll use a `Read Data` operation that fetches from the Posts collection using the `$trigger.keys` as the ID to fetch.


![](https://cms.echobind.com/assets/aceee599-97d0-4ed5-b131-a192d457f093)


> `$trigger.keys` comes from the trigger. It’s a list of IDs for all of the items that were affected. Run your flow and check the logs to see the other data that is provided by the trigger. 


The final operation is to send the post slug to the API route webhook. In the code above you can see the post slug is on the `post` query param. We also pass a `secret` query param that is included in our Directus flow to keep third-parties from abusing our revalidate endpoint.


![](https://cms.echobind.com/assets/ca1294ed-d67a-4a2c-8bc2-6d4c10f36fe1)


That’s all we need! After saving the flow, we can publish, edit, or delete blog posts and the published site should update almost instantly, or at very least significantly faster than the 60 second revalidate timer.


Of course, this could be expanded to many other uses. An e-commerce website could list remaining quantity on an item that is always up-to-date. A comments section could be statically rendered while still showing the latest comments as soon as they are posted. That’s what the power and flexibility of this API can do for you.

---

[View on echobind.com](https://echobind.com/post/instant-site-updates-with-on-demand-revalidation-and-directus)

---

# Playwright with Next-Auth and PrismaOverview 

> Let's go over how to quickly configure Playwright with Next-Auth in a Next.js application.

_By Matt Thompson · 2022-12-05_

You may have heard some rumblings in previous [blogs](https://echobind.com/post/why-we-ditched-graphql-for-trpc) and [tweets](https://twitter.com/alexdotjs/status/1589960174495625216) about Echobind moving to tRPC, and our team working on what we are calling [Bison 2.0](https://github.com/echobind/bisonapp). While tRPC is exciting, it is not the only change we are looking into. Over the past year, we have consistently started to leverage [Next-Auth](https://next-auth.js.org/), and have hit countless time sinks with Cypress. Next-Auth obviously plays into our stack built around NextJS, but testing it with Cypress always proved to be a bit… wonky. Having to build custom commands to use node and DB Factories, intercepting, mocking, and worst of all those `.then` waterfalls — Gross. 


Insert [Playwright. ](https://playwright.dev/)


I’m happy to say Playwright has A LOT going for it out of the box in comparison. 


Today, I wanted to go over how to quickly configure Playwright with Next-Auth. I was excited to see Playwright had already taken Authentication into account out of the box. There are many options, but the most exciting for me is the ability to save our user sessions into a `storageState` for multiple user roles and re-use them in our specs. No more `beforeEach` where we need to check the Database, create a User, Login, intercept the call, mock the return, wait for the redirect, oh wait what was I testing again…


Oh right, As an Admin I simply want to log in. Geez


Playwright has a whole section on Authentication, but we are going to specifically look at the multiple signed roles section found [here](https://playwright.dev/docs/test-auth#multiple-signed-in-roles). 


## Sounds great! Where’s the code… 


If you haven’t set up Playwright before, follow their quick setup here. [https://playwright.dev/docs/intro#installing-playwright](https://playwright.dev/docs/intro#installing-playwright)


Once set, you should have a `playwright.config.ts` file. (You did choose Typescript right?!) 


We are going to add two lines to our default config. A `globalSetup` and `globalTeardown`.


```typescript
// playwright.config.ts

const config: PlaywrightTestConfig = {
  globalSetup: require.resolve('./tests/e2e/global-setup'),
  globalTeardown: require.resolve('./tests/e2e/global-teardown'),
}
```


If you are familiar with Jest, or any other testing lib, this should sound straightforward enough. We are going to have two files that do something before and after ALL of our tests run. Here I’ve included these in my `test/e2e/` directory, just be sure you have the right file path and we’re all set here. 


Let’s take a look at our `global-setup` file. (I’ve also included my `constants` file for reference) 


```typescript
// tests/e2e/global-setup.ts

import { chromium, FullConfig } from '@playwright/test';
import { Role } from '@prisma/client';

import { UserFactory } from '../factories';

// Shared Below...
import { ADMIN, APP_URL, LOGIN_URL, USER } from './constants';

async function globalSetup(_config: FullConfig) {

  // These User Factories are specific to our boilerplate
  // The goal here is to create an Admin and User for your future specs 

  const _adminUser = UserFactory.create({
    email: ADMIN.email,
    emailVerified: new Date().toISOString(),
    roles: [Role.ADMIN],
    password: ADMIN.password,
    profile: {
      create: {
        firstName: ADMIN.firstName,
        lastName: ADMIN.lastName,
      },
    },
  });

  const _user = UserFactory.create({
    email: USER.email,
    emailVerified: new Date().toISOString(),
    roles: [Role.USER],
    password: USER.password,
    accounts: {},
    profile: {
      create: {
        firstName: USER.firstName,
        lastName: USER.lastName,
      },
    },
  });

	// The fun part! 
  const browser = await chromium.launch();
  const adminPage = await browser.newPage();
  await adminPage.goto(LOGIN_URL);
  await adminPage.locator('data-test=login-email').fill(ADMIN.email);
  await adminPage.locator('data-test=login-password').fill(ADMIN.password);
  await adminPage.locator('data-test=login-submit').click();
  await adminPage.waitForNavigation();
  await adminPage.waitForURL((url) => url.origin === APP_URL, { waitUntil: 'networkidle' });
  // This saves everything about `adminPage` so far into a named `storageState` 
  await adminPage.context().storageState({ path: ADMIN.storageState });

  const userPage = await browser.newPage();
  await userPage.goto(LOGIN_URL);
  await userPage.locator('data-test=login-email').fill(USER.email);
  await userPage.locator('data-test=login-password').fill(USER.password);
  await userPage.locator('data-test=login-submit').click();
  await userPage.waitForNavigation();
  await userPage.waitForURL((url) => url.origin === APP_URL, { waitUntil: 'networkidle' });
  // This saves everything about `userPage` so far into a named `storageState`
	await userPage.context().storageState({ path: USER.storageState });

  // We are done for now :) 
	await browser.close();
}

export default globalSetup;
```


```typescript
// tests/e2e/constants.ts

export const APP_URL = 'http://localhost:3001';
export const LOGIN_URL = 'http://localhost:3001/login';

// This is primarily args for our DB Factories 
// storageState is the named path/file where Playwright will save our session
export const ADMIN = {
  email: 'brainiac@lex.com',
  firstName: 'Lex',
  lastName: 'Luther',
  password: '1amBrainiac!',
  storageState: './temp/adminStorageState.json',
};
export const USER = {
  email: 'clark@thedaily.com',
  firstName: 'Clark',
  lastName: 'Kent',
  password: 'krypton8!',
  storageState: './temp/userStorageState.json',
};
```


Let’s walk through this in a bit more detail. 


After creating our Users for future scenarios, we’ll create a `browser` instance in playwright. From there we can open a specific `page` for each user. `adminPage` and `userPage` respectfully. Now for the fun part, each page/browser has `context` Playwright can keep track of and a `storageState` where all of this information can live until you want to call it again. 


Looking at our `adminPage` calls, you’ll see we have instructed Playwright to navigate to the `LOGIN_URL` and log the user in before saving anything to `storageState`. This means, when we go to use the state for admin, we’ll already have an Admin User signed in to our app, cookies saved, and in our case redirected back to the home page ready to go. 


In a `beforeEach` scenario, you might perform all these same steps minus the storageState save.  The beauty here is I don’t have to worry about creating a `beforeEach` block for _**every**_ spec. 


This means: 

- Fewer DB hits
- Faster Specs
- Less maintenance and cleanup

## Test Example 


Having our Admin and User defined in the global setup means we can make use of `test.use({ storageState: 'file-path-to-storage' });` 


Our home page is a simple welcome message with the Users name. 


```typescript
// pages/index.tsx

<Center>
  <Heading data-testid="welcome-header">
    {welcomeMsg}
  </Heading>
</Center>
```


```typescript
// tests/e2e/auth.spec.ts

import { Page, test, expect } from '@playwright/test';

import { ADMIN, APP_URL, USER } from './constants';

test.describe(() => {
  test.use({ storageState: USER.storageState });

  test('Can Login as a User', async ({ page }: { page: Page }) => {
    await page.goto(APP_URL);
    await page.waitForURL((url) => url.origin === APP_URL, { waitUntil: 'networkidle' });
    await page.waitForSelector('internal:attr=[data-testid="welcome-header"]');

    const welcomeHeader = await page.getByTestId('welcome-header');
    const welcomeMsg = `Welcome, ${USER.firstName}!`;
    await expect(welcomeHeader).toContainText(welcomeMsg, { ignoreCase: true });
  });
});

test.describe(() => {
  test.use({ storageState: ADMIN.storageState });
  test('Can Login as an Admin', async ({ page }: { page: Page }) => {
    await page.goto(APP_URL);
    await page.waitForURL((url) => url.origin === APP_URL, { waitUntil: 'networkidle' });
    await page.waitForSelector('internal:attr=[data-testid="welcome-header"]');

    const welcomeHeader = await page.getByTestId('welcome-header');
    const welcomeMsg = `Welcome, ${ADMIN.firstName}!`;
    await expect(welcomeHeader).toContainText(welcomeMsg, { ignoreCase: true });
  });
});
```


For each of these, we use the StorageState path for each user. Navigate back to the home page, and assert that we see our Welcome text. 


A quick run with `yarn playwright test` and 1… 2… 3… ✅


## Conclusion 


From async/await, the ability to run factories, and having robust options when testing different scenarios, Playwright has been a joy to work with so far in comparison. While this strategy may not work for every scenario, I’m a lot more confident in the tools Playwright has provided to be successful long term. Stay tuned for a more in-depth comparison as we continue to build out.

---

[View on echobind.com](https://echobind.com/post/playwright-with-next-auth)

---

# React vs React Native: How Different Are They, Really?

> Before building React Native applications, web developers and managers often ask just how much knowledge transfers over from React on the web. This article attempts to answer that question from a number of different perspectives.

_By Mike Cavaliere · 2022-12-01_

Over the years that I’ve been working with React (circa 2014) and React Native (circa 2016), I’ve had everyone from engineers to CEOs to product people ask me some form of the question, **"What are the differences between React and React Native?"** Developers want to know how much they have to learn, managers want to know how much their team’s velocity will be affected, and what other considerations there are. 



TL;DR: **mobile application development** is a very different world from **browser-based application development**, so naturally developers will need to learn new tools, paradigms and techniques. Even though the core React API is the same, you're coding for smartphones and tablets instead of browsers, and those have a very different set of rules. In parallel, managers will have to provision some new services for their React Native projects to run effectively. But there’s a lot more to it; I encourage you to read on.


## Things that translate over well from React Web to React Native

There’s a good amount of knowledge that _will_ translate for React web developers. Enough, in fact, that this is why React Native is such a compelling choice for web engineers to start working on mobile applications. Here are things that React developers will not have to learn from scratch when starting to work with React Native. 

### Core React API and concepts

A component is a component is a component. Class-based components and functional components operate the same way in React Native as on the web. You still should [think in React](https://beta.reactjs.org/learn/thinking-in-react) apply all of your React best practices like using [composition](https://reactjs.org/docs/composition-vs-inheritance.html) and [lifting state up](https://reactjs.org/docs/lifting-state-up.html). 

### React architectural concepts

State management, orchestrating HTTP requests, synchronizing client and server state: all these things will apply to React Native. The differences will only arise when the device layer comes into play (for example, if you have to store data on the client, [`window.localStorage`](https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage) doesn’t exist, but [`AsyncStorage`](https://react-native-async-storage.github.io/async-storage/) does.)

### React performance optimization best practices

Many of the JavaScript-based performance optimization techniques that are specific to React will still apply. Namely, the use of `React.memo()`, `useMemo()` and `useCallback()` operate identically. Anything related to build optimization will be different, and React Native requires some additional attention to optimization (more on that below). 

### Third-party tools

Many tools for monitoring, error reporting, analytics, etc. have SDKs that translate over well. I'm thinking Sentry, Datadog, MixPanel, others. 

### Pure JavaScript libraries

`npm` packages that don’t rely on native code or CSS will also work well in React Native. Yes you can still use your beloved `lodash`, `axios`, `react-hook-form`  and React Query / Tanstack Query. State management libraries like Redux, MobX, XState, and so on are fine as well. 


## Things that are quite different between React Web and React Native

As you’ll notice, this section is a lot longer than the previous one 😁  React development principles will certainly translate over to native well; but it’s important to realize that React isn’t a magic bullet. Developers will still need to learn plenty about mobile development in general, and specifically how to do things well in RN.

### Hardware

The biggest paradigm shift when going from React web to React Native is perhaps the obvious one: you’re now building apps for completely different devices that run in a completely different environment. Mobile hardware can do things browsers can't, so that's a perk. But it also means new learning. Push notifications, in-app purchases and haptics are things that are now natively supported and have their own APIs for.

### Layout and Styling

React Native uses the [Yoga](https://yogalayout.com/) engine under the hood, which allows you to use CSS properties to layout your React Native UI in a way that translates really well. Layout in Yoga is limited to Flexbox and absolute/relative positioning, however; there is no CSS grid and no `display` attribute. This keeps things simpler and more performant, but if developers are accustomed to using other layout techniques on the web, they’ll need to adjust to this new limitation. 

React Native does come packaged with block-level ([`<View>`](https://reactnative.dev/docs/view-style-props) ) and inline ([`<Text>`](https://reactnative.dev/docs/text-style-props)) which can be thought of to parallel `<div>` and `<span>` in html. They support a fair bit of common CSS properties: borders, backgrounds, typography and so on are all in there. But as before, don’t expect fancier properties like `calc()` to be available. 

### Library availability

CSS-based UI libs don't make sense on mobile; your new options include [NativeBase](https://nativebase.io/), [React Native Elements](https://reactnativeelements.com/) and others). Some web-based UI libs do have RN siblings though - such as [React Native Material](https://www.react-native-material.com/) and [React Native Paper](https://reactnativepaper.com/) (for Material-UI),  and [tailwind-rn](https://github.com/vadimdemedes/tailwind-rn) (for Tailwind). This just means new decisions to make, some learning, and new paradigms for how to use the new libs. 

### Library Differences

A great many React libraries do indeed work on React Native as well, which is a great perk for the platform. It’s worth noting that some will have slight configuration changes to make them work on React Native. This is understandable since the environments are different (DOM vs no DOM, hardware differences, and so on). 

[`react-hook-form`](https://react-hook-form.com/get-started#ReactNative), for example, uses `<form>` tags on the web. But since HTML doesn’t exist in React Native, `react-hook-form` requires developers to wrap their forms in a `<Controller>` component, which does work in RN. 

### Navigation

As a user, you already know that moving around a smartphone app is completely different than on a web app. [`react-navigation`](https://reactnavigation.org/) is the most common navigation lib for mobile (runner-up: [`react-native-navigation`](https://wix.github.io/react-native-navigation/docs/before-you-start/)). Both are fairly different from [`react-router`](https://reactrouter.com/en/main), [Next.js's router](https://nextjs.org/docs/routing/introduction), and so on. Not only do developers have to learn new APIs for this, they’ll have to think differently to plan out complex navigation properly. It’s all very achievable, but I wouldn’t advise assuming that the effort is trivial. 

### Development and developer experience (DX)

Some development tools for the web are similar (Chrome debugger, mostly) to those for React Native, but other aspects are very different (working with the [metro bundler](https://facebook.github.io/metro/), using [Flipper](https://fbflipper.com/), AsyncStorage debugging, more). Some techniques developers will use are the same (breakpoints and console logging), but others are different (knowing when to restart the packager vs reinstall the app on device).

Testing while you develop anything is crucial; the iOS simulator and Android emulators let you simulate a variety of devices. Naturally the iOS sims only run natively on a Mac, which is worthy of note, as this is a roadblock for any dev team that uses Windows or Linux and doesn’t have a Mac readily available. 

Dev machine setup is also more time-consuming, and can be quirky. Devs will need to have both XCode and Android Studio installed beforehand, so that builds will compile and emulators on both platforms exist for running code. `watchman` is also a prerequisite along with `rvm` (or `rbenv`) and CocoaPods — but it’s important to note that our beloved [Expo](https://expo.dev/) makes a lot of this _way_ easier. (It’s one of the many reasons we use it for all of [our React Native projects at Echobind](https://echobind.com/services/react-native-app-development).)

Lastly, both the iOS simulator and Android emulators have limited or no support for certain features of smartphones: haptics, geolocation, app store purchases, and the camera, just to name a few. It’s best to have at minimum one real device for each operating system to properly test with while developing. 

### Performance optimization

Besides React optimization (which is arguably more necessary on mobile), developers will now have different hardware and a different internal architecture to work with. They’ll have to know about the [JS and UI threads](https://brooklinmyers.medium.com/react-native-understanding-threads-e026c7d62bb2), and different (and IMO more challenging) ways to avoid jank and prevent crashing. Memory and energy consumption are now even more important, since mobile devices are more limited in these areas. 

And they’ll have to use new performance analysis tools. Have a look at React Native’s [performance overview](https://reactnative.dev/docs/performance) page just to get a sense of the approach. 

The stakes are also higher for both devs and product teams on mobile - crashes and bad performance are huge killers of App Store reviews. 

## Other React Native differences that engineering leads and managers should know about

Besides all of the technical differences, development process is different for web vs mobile apps, so naturally it also will be for React vs React Native apps. So here are some of the process-related considerations for how your dev team’s workflow will be affected when transitioning from React web to mobile development.

### Deployments and releases

You can deploy to prod without restriction on web; on mobile you have to deal with both app stores, which can be cumbersome and slow especially for the initial release/approval process. You have to fill out _**lots**_ of documentation before the first time you release to production.

Even distributing a beta version of your app for non-developers to test, either for formal QA or for casual testing, can be a process. It’s not as easy as just deploying anymore; depending on your distribution method and which app store you’re working with (more so for iOS distributions than Google, FWIW) you may have to add each tester to the portal manually, then kickoff another build for them to be able to access it. 

We use tools to simplify all of this at Echobind (like [Expo Application Services](https://expo.dev/eas), [GitHub Actions](https://github.com/features/actions) and others), but we make sure to accommodate time for this in our project budgets since it can be non-trivial to set up. 

### Testing and QA

Unit testing with Jest and React)Testing Library is similar on React Native; developers use the same syntax (and the React Native version of React Testing Library), so there isn’t a huge paradigm shift there. Developers will have to mock out different third-party libraries on native, though, since unit test suites won’t be able to run native code. 

End-to-end testing is completely different on React Native, however. None of the Selenium-based E2E testing tools will work; neither will newer tools like Cypress or Playwright. You may have expected this - these are all DOM-based, and there’s no DOM in React Native. So instead developers will have to learn [Detox](https://wix.github.io/Detox/) or [Appium](https://appium.io/). 

Also since it’s mobile, you can’t avoid manual testing completely, no matter how much you automate. Plan to allocate time for testing setup in each project, since [TestFlight](https://developer.apple.com/testflight/) and [Play Store](https://support.google.com/googleplay/android-developer/answer/9845334?hl=en) configuration are non-trivial (especially the former). Once again, [EAS makes this easier](https://docs.expo.dev/build/internal-distribution/), so save yourself frustration and use it.

And with every release, plan time to manually test each build on each platform.

### DevOps

Continuous Integration/Continuous delivery are a different animal for React Native apps as well. You may end up making different choices on services and tools to use, and setting them up separately. 

Firstly, keep in mind that if you’re building for both Android and iOS, you’ll need to run your CI builds on a Mac (at least for the iOS builds). Which means that you’re gonna pay a LOT more for your build runs than on Linux boxes. Look at EC2’s cheapest mac instance compared to it’s cheapest Linux instance (which has more powerful hardware):

![Comparison of pricing for Linux vs Mac instances on Amazon EC2: a 6-core CPU is 790.59 USA per month on a Mac instance, compared to 327.77 USD for a Linux instance with 16 cores](https://cms.echobind.com/assets/6d538df3-7fd1-469b-9a6c-abaf3b03b3ab)

And similarly, GitHub Actions’ per-minute pricing for Linux vs MacOS instances:

![Comparison of per-minute pricing for GitHub Actions Linux vs Mac instances: a 3-core Mac instance is 0.08 USD per minute vs 0.008 USD for a 2-core Linux instance, or 0.032 for an 8-core Linux instance](https://cms.echobind.com/assets/9cd62861-e2a6-410a-95e3-b6edf98d8237)

A MacOS instance costs 2.5 times as much Linux instance with almost three times the processing power; but compared to a Linux instance with one less CPU core, the Mac instance costs 10 times as much (!!).

That’s just a visual way to say that you’ll need to think through your CI setup carefully, for more reasons than one.

At Echobind for example, we typically setup [Expo Application Services (EAS)](https://expo.dev/eas) and [GitHub Actions](https://github.com/features/actions) for our React Native client projects and internal projects. Builds get triggered by a PR merge to `main`; GitHub Actions runs JS-related automation (linting, typechecking, unit tests, etc), then hands off control to EAS to do the actual builds and releases. 

For us, this setup provides the a good balance of ease of setup, features, DX and reasonable costs. It also makes testing a lot easier since people can scan install builds to their phones just by scanning a QR code. But one CI setup doesn’t fit all projects, so choose yours carefully. 

---

This is a fairly thorough list of differences between React for the web and React Native; please keep all of these things in mind when starting to learn React Native (if you’re a developer) or transitioning your dev team to React Native (if you’re a manager). Planning accordingly will save you a lot of time and frustration, and reduce surprises. 

***Learn more about our [React Native capabilities](/capabilities/react-native-app-development).***

---

[View on echobind.com](https://echobind.com/post/react-vs-react-native-how-different-are-they)

---

# Keeping a Remote Team Connected with Echobind’s 2022 Summit

> Our annual summit allows our team to build on our foundation of community and provides opportunities for new, shared experiences.

_By Krystalyn Bauer · 2022-11-23_

<div style="padding:75% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/774491346?h=9f350dc20d&amp;badge=0&amp;autopause=0&amp;player_id=0&amp;app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture" allowfullscreen style="position:absolute;top:0;left:0;width:100%;height:100%;" title="Echobind_Summit2020_ShorterVideo_v2 (1).mov"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

Our annual summit allows our team to build on our foundation of community and provides opportunities for new, shared experiences. We find our summit to be invaluable for a few reasons. We get to reflect on the work we have been doing and align on where we want to iterate.  We get to deepen our connections as teammates and colleagues in person. With our refreshed alignment and strengthened connections, we elevate our collective skills as a team. This year, we focused on communication and problem-solving skills, which are crucial for our remote team of software engineers, designers, and strategists.


After a two-year hiatus from our summit, we were ready to make up for lost time. We set out from all over the U.S. to gather at C Lazy U Dude Ranch in Granby, CO. We had a blast doing all the ranch things, but the magic really sparked during our workshops where we got to dive deeper into communication and problem-solving. The discussions we had and the challenges we shared created invaluable takeaways to bring home to our daily work life. We went beyond just getting to know each other and learned how to support each other better at work.

![](https://cms.echobind.com/assets/17ba1a87-c458-4566-8da9-95056085f344)


Our team had the chance to participate in activities like horseback riding, hiking, archery, scavenger hunt, and (a crowd favorite) our murder mystery dinner while also meeting our colleagues - some of us for the first time. The ranch provided a really fun setting for us to get out of our everyday routines and comfort zones and try new things. Some of us rode a horse for the first time and some of us learned that ax throwing is wildly therapeutic. 



![](https://cms.echobind.com/assets/85bd2599-9b02-44e6-9b76-839da13a59e1)


Our annual summit is one of the largest investments Echobind makes. While much of the ROI is intangible, we survey our team to measure their satisfaction and were thrilled to see 100% responded that our annual retreat was valuable and achieved the goal of fostering stronger relationships among colleagues. We can say with confidence that the experiences we had as a team were priceless. Our hope is that the magic stays palpable throughout the year.


![](https://cms.echobind.com/assets/c8f65ed9-a596-4091-afd2-67493b98918c)

---

[View on echobind.com](https://echobind.com/post/keeping-a-remote-team-connected-with-summit)

---

# How to Use Your iPhone as a Webcam

> Did you know that Apple has enabled the iPhone to work as a webcam? But that’s not all. You can now use it in a new view Apple calls Desk View, which allows you to share your desk surface.

_By Jacob Galito · 2022-11-17_

Did you know that Apple has enabled the iPhone to work as a webcam? But that’s not all. You can now use it in a new view Apple calls Desk View, which allows you to share your desk surface. 

![](https://cms.echobind.com/assets/80ea888a-dfc7-427b-b410-e1da78155c75)

## **What could I use this for?**


If you are training or teaching anyone on any streaming services that requires showing you go through a process, this might help provide more context. For example:

- Teaching an online course and working through math problems
- Illustrating or painting
- Note taking and sharing with the group
- UI/UX design—wire framing

## Setting up your devices


Here are the initial set up steps for your operating systems:


**after iOS 16 and MacOS Ventura are out of beta, all of these steps will probably not be needed and just skip to searching for “Desk View”.

- **Sign in or sign up**—You’ll want to go to [Apple’s Beta Software Program ](https://beta.apple.com/sp/betaprogram)and sign up, if you haven’t already, or sign in (This should be the same email account you use for your Apple account.)
- Next, you’ll want to select ‘enroll your mac’
- **Back up your computer**—You’ll be prompted to back up your computer or you can choose to move ahead
- **Enroll your mac**—this will download the Mac OS Public Beta Profile .dmg file
- **Update OS**—Once it’s downloaded, click on the Apple icon > System Preferences > and you should see the available Ventura OS update
- **Repeat these steps on** **your iPhone**—While your computer is updating, go to your iPhone and go to [Apple’s Beta Software Program](https://beta.apple.com/sp/betaprogram/guide#ios) and click the iPhone tab

### Opening Desk View


Simply do a search, either go to the search icon or press command + spacebar and search for desk view. After you launched it once, you can drag and drop it to the left side of your dock to make it easier to get to.


![](https://cms.echobind.com/assets/a68f93cc-6409-4439-b90d-744fc2df01aa)


 


![](https://cms.echobind.com/assets/dd4b706f-9ff1-48da-94e4-8d1dcac11a6c)


### Other things needed

- A Magsafe iPhone case
- A Magsafe Popsocket

or

- A phone stand
- A small tripod

### Other useful tools

- [**Hand Mirror app**](https://handmirror.app/)—desktop tool for checking if your camera is working (and if you have anything on you before a call!)
- [**Krisp app**](https://krisp.ai/)—very handy tool for audio setup for video calls

### **Gotchas**


You might discover that this app quits working if you’ve updated one device and not the other. So if you ever run into that issue, go to your device settings and ensure that you are up-to-date with the latest beta releases.

---

[View on echobind.com](https://echobind.com/post/how-to-use-iphone-as-webcam)

---

# Conditionally Render Fields Using React Hook Form

> Learn to conditionally render fields using React Hook Form! View step by step examples or get all the information you need with a TL;DR.

_By Preston Kelly · 2022-11-15_

How can you conditionally render fields using React Hook Form? Continue reading for a step by step guide on how I got there. I'll also highlight some common pitfalls you may encounter. To begin, I created a simple form with [Tailwind](https://tailwindcss.com/) styling. This form displays a first name input, submit button and a checkbox that checks to see if the user has a last name.


### TL;DR


Use React Hook Form's built-in `watch` function to watch for changes to an input field. Next, use React’s `useEffect` hook to `register` and `unregister` the fields.


```typescript
<form>
  <div className="flex flex-col">
    <input
      placeholder="First Name"
      className="border-2"
    />
    <div className="flex justify-between">
      <label htmlFor="lastNameCheck">Last Name?</label>
      <input
        id="lastNameCheck"
        type="checkbox"
      />
    </div>
    <input
      placeholder="Last Name"
      className="border-2"
    />
    <button type="submit" className="bg-gray-500">
      Submit
    </button>
  </div>
</form>
```


When we're creating a new input, we'll want to register that field with React Hook Form using the `register` function. We'll spread the `register` function on the input and give it a name. This name will be something that we can reference later on when we're looking to conditionally remove the field.


### Handle Form


Now, let’s register our fields and create a simple `onSubmit` function that will console log our form data. I’ve also included a `User` type that we’ll use to tell React Hook Form’s `useForm` function what type of data we’ll be including.


```typescript
import { useForm } from "react-hook-form";

type User = {
  firstName: string;
  lastNameCheck: boolean;
  lastName: string;
};

export const Form = () => {
  const { register, handleSubmit } = useForm<User>();

  const onSubmit = (data: User) => console.log(data);
  return (
    <>
      <form onSubmit={handleSubmit(onSubmit)}>
        <div className="flex flex-col">
          <input
            {...register("firstName")}
            placeholder="First Name"
            className="border-2"
          />
          <div className="flex justify-between">
            <label htmlFor="lastNameCheck">Last Name?</label>
            <input
              id="lastNameCheck"
              type="checkbox"
              {...register("lastNameCheck")}
            />
          </div>
          <input
            {...register("lastName")}
            placeholder="Last Name"
            className="border-2"
          />
          <button type="submit" className="bg-gray-500">
            Submit
          </button>
        </div>
      </form>
    </>
  );
};
```


### Create Variable


Next, we'll create a variable using React Hook Form's built in `watch` function that will "watch" or keep track of field changes. This watch function give us updates along the way. For simplicity, we’ll name our variable `watchLastNameCheck`, and this variable will track any changes to our “lastNameCheck” checkbox.


```typescript
const { register, handleSubmit, watch } = useForm<User>();
const watchLastNameCheck = watch("lastNameCheck");
```


If you enter “Hello” into the First Name input and click the submit button, you’ll see data for the first name and checkbox fields in the console.


![](https://cms.echobind.com/assets/899ce44a-65d3-4ec7-8ec0-dd75dbdbb1ba)


If we were to click on the "Last Name?" checkbox, enter in “World” and click submit again, we'll see that our `lastName` field is now returning in the console.


![](https://cms.echobind.com/assets/066be05d-3310-460e-b48e-0b320b558c65)


### Possible Pitfall


What happens if a user unchecks the checkbox? When a user unchecks the checkbox, we still see the `lastName` field outputting to the console and this is something we do not want! Returning empty or null fields can lead to errors down the road. We'll only want information from fields that we've entered data into and are visually rendered on the page.


The solution? We'll add in a `useEffect` to check the `watchLastNameCheck` variable we setup earlier. We'll register that input only when we need it. When a user unchecks our checkbox, we'll “unregister” the field using the built in `unregister` function from React Hook Form.


```typescript
const { register, handleSubmit, unregister, watch } = useForm<User>();
const watchLastNameCheck = watch("lastNameCheck");

useEffect(() => {
  if (watchLastNameCheck) {
    register("lastName");
  } else {
    unregister("lastName");
  }
}, [register, unregister, watchLastNameCheck]);
```


You'll see that when you now check and uncheck the checkbox, the console output only displays the information we need. The `useEffect` removes the `lastName` field from our form data if the checkbox is not checked. I’ve gone ahead and added a check to only display the `lastName` field when the checkbox is active.


Full code:


```typescript
import { useEffect } from "react";
import { useForm } from "react-hook-form";

type User = {
  firstName: string;
  lastNameCheck: boolean;
  lastName: string;
};

export const Form = () => {
  const { register, handleSubmit, unregister, watch } = useForm<User>();
  const watchLastNameCheck = watch("lastNameCheck");

  useEffect(() => {
    if (watchLastNameCheck) {
      register("lastName");
    } else {
      unregister("lastName");
    }
  }, [register, unregister, watchLastNameCheck]);

  const onSubmit = (data: User) => console.log(data);
  return (
    <>
      <form onSubmit={handleSubmit(onSubmit)}>
        <div className="flex flex-col">
          <input
            {...register("firstName")}
            placeholder="First Name"
            className="border-2"
          />
          <div className="flex justify-between">
            <label htmlFor="lastNameCheck">Last Name?</label>
            <input
              id="lastNameCheck"
              type="checkbox"
              {...register("lastNameCheck")}
            />
          </div>
          {watchLastNameCheck ? (
            <input
              {...register("lastName")}
              placeholder="Last Name"
              className="border-2"
            />
          ) : null}
          <button type="submit" className="bg-gray-500">
            Submit
          </button>
        </div>
      </form>
    </>
  );
};
```

---

[View on echobind.com](https://echobind.com/post/conditionally-render-fields-using-react-hook-form)

---

# Why we ditched GraphQL for tRPC

> While we normally use GraphQL to get data from the server to the client, tRPC provides a simpler, more streamlined experience for our developers, helping us make better apps for clients.

_By Alex Anderson · 2022-11-08_

At Echobind, we’re committed to building the best software we can for our clients. As we choose our technology stack, we have to balance a number of tradeoffs, including stability, flexibility, scalability, and the speed of development. We wrap our favorite tools in a starter repository we call [Bison](https://github.com/echobind/bisonapp). 


We adopted GraphQL in Bison to give our apps end-to-end type checking, with type safety from the database all the way to the UI. It’s served us well, and has been the API layer for dozens of apps developed by Echobind.


We’re always looking for ways to improve our processes, so when we noticed [tRPC](https://trpc.io) starting to become popular, we decided we would take a look. What we saw impressed us, so we’ve decided to adopt tRPC as the official API layer for Bison.

> We've made the change to tRPC in the `canary` branch, which means it isn't fully released yet. If you want to see what it took to make this migration in Bison, take a look at [this commit](https://github.com/echobind/bisonapp/commit/60899f889344e547a2d3e680de97b20a0a754410)


### What is tRPC?


tRPC and GraphQL serve the same purpose: Getting data from the server to the client. GraphQL is a specification which allows the client to request specific data, which the server resolves into a response with just the fields that were requested.


tRPC, on the other hand, lets the client call server-defined procedures, passing along any relevant inputs and getting back a response. Inputs are type checked at runtime using validator libraries like [Zod](https://github.com/colinhacks/zod), and the types of the procedures are inferred from the server to the client. While you can make direct `fetch` calls to tRPC’s API, it includes a wrapper around [React Query](https://tanstack.com/query/v4/), a caching layer that provides an excellent user and developer experience.


Both GraphQL and tRPC are perfectly compatible with React and React Native and have first-party client-side library support. Both support end-to-end type checking, with GraphQL requiring a codegen step. And both are fast enough for our purposes.


Here’s what that looks like in practice, with mostly equivalent examples for both GraphQL and tRPC. First, let's look at GraphQL, both defining the resolver and fetching on the client (excluding any generated code):


```typescript
// On the server
export const User = objectType({
  name: 'User',
  description: 'A User',
  definition(t) {
    t.nonNull.id('id');
    t.nonNull.date('createdAt');
    t.nonNull.date('updatedAt');
    t.nonNull.list.nonNull.field('roles', { type: 'Role' });

    // Show email as null for unauthorized users
    t.string('email', {
      resolve: (profile, _args, ctx) => (canAccess(profile, ctx) ? profile.email : null),
    });
  },
});

export const UserRole = enumType({
  name: 'Role',
  members: Object.values(Role),
});

export const UserWhereUniqueInput = inputObjectType({
  name: 'UserWhereUniqueInput',
  description: 'Input to find users based on unique fields',
  definition(t) {
    t.id('id');
    t.string('email');
  },
});

export const findUniqueUserQuery = queryField('user', {
  type: 'User',
  args: {
    where: nonNull(arg({ type: 'UserWhereUniqueInput' })),
  },
  resolve: async (_root, args, ctx) => {
    return await ctx.db.user.findUnique({ where: prismaArgObject(args.where) });
  },
});

// On the client
export const QUERY = gql`
  query User($id:ID!) {
    user(id:$id) {
      name
    }
  }
`;

export const UserCell = ({userId}:{userId:string}) => {
	const { data, loading, error } = useUserQuery({
    variables: {
      where: { id: userId },
    },
  });

  // ...
}
```

And then the same, but using tRPC instead:


```typescript
// On the server
export const defaultUserSelect = Prisma.validator<Prisma.UserSelect>()({
  id: true,
  email: true,
  createdAt: true,
  updatedAt: true,
  roles: true,
  profile: { select: { firstName: true, lastName: true } },
});

export const userRouter = t.router({
  find: t.procedure
    .input(
			z.object({ 
				id: z.string().optional(), 
				email: z.string().optional() 
			})
		)
    .query(async ({ ctx, input }) => {
      const user = await ctx.db.user.findUniqueOrThrow({ 
				where: input,
				select: defaultUserSelect 
			});

      if (!isAdmin(ctx.user) && user.id !== ctx.user?.id) {
        return { ...user, email: null };
      }

      return user;
    }),
});

// On the client
export const UserCell = ({userId}:{userId:string}) => {
	const { data, loading, error } = trpc.user.find.useQuery({id:userId})

  // ...
}
```


The difference between these two examples highlights the initial reason we switched from GraphQL to tRPC.


### Less Boilerplate


You’ll notice in the code samples above, tRPC is able to do the same work with much fewer lines of code. In fact, when we migrated Bison to tRPC, we added 1,765 lines of code while _removing_ 3,373 - a net change of 1,608 lines of code!


This is partially because GraphQL famously has the [“Double declaration problem”](https://wundergraph.com/blog/solving_the_double_quintuple_declaration_problem_in_graphql_applications_how_to_not_repeat_yourself) - there’s a lot of repeating yourself, especially if you’re using TypeScript. Tools like GraphQL codegen help with this, but it’s still a _lot_.

1. Define the database schema (Prisma)
2. Define the API schema (Nexus)
3. Write a GraphQL Operation (gql)
4. Define the response type definition (GraphQL codegen)
5. Define the query (Apollo Client)

tRPC trims this down significantly.

1. Define the database schema (Prisma)
2. Define the procedure (tRPC router)
3. Define the query (tRPC client/React Query)

The simplicity speaks for itself.


### Avoiding Code Generation


In both cases, we can achieve end-to-end type safety, which is table-stakes for our apps, but the method of achieving this type safety is much more complicated with GraphQL, requiring three layers of code-generation:

- [Prisma](https://www.prisma.io) generates types from our database schema.
- [Nexus](https://nexusjs.org) generates types from our database schema.
- [GraphQL Codegen](https://www.the-guild.dev/graphql/codegen) generates frontend types and React hooks from our GraphQL request definitions.

This code generation doesn’t come without its consequences. For one app we built at Echobind, Nexus generates a 2000 line type file while GraphQL codegen generates an 8200 _dense_ type file. All of that takes a long time for the type checker to parse and check, both when running `tsc` and in VSCode.  We often need to restart our VSCode language server because it gets bogged down with all of the type checking it has to do.


tRPC instead relies on one very large assumption: Your server is written in TypeScript, and is colocated with the client code. tRPC has you define a server-side router for your procedures, then export the type of that which Typescript automatically infers, and then import that type to be used on the client-side. Since types are automatically removed when Typescript code is compiled, there is no extra code added to the client bundle, and no extra types to slow down the type checker. Just type safety.


### Client Bundle Size


It’s no secret - the less JavaScript you ship to your users, the better their experience will be. To build great software, you need _some_ JavaScript, but if an alternative comes along that uses _less_ JavaScript, it’s worth a second look.


Let’s compare the client-side dependencies needed for both approaches. These numbers were calculated by putting the packages through [bundlephobia.com](http://bundlephobia.com) and tracking the “minified + gzip” sizes.


| **GraphQL**                 | **tRPC**                      |
| --------------------------- | ----------------------------- |
| @apollo/client: 40kb        | @trpc/client: 4.4kb           |
| apollo-upload-client: 1.5kb | @trpc/react-query: 1.8kb      |
| graphql: 39.7kb             | @tanstack/react-query: 12.7kb |
|                             | @trpc/next: 4.8kb             |
| **TOTAL: 81.2kb**           | **TOTAL: 23.7kb**             |


The GraphQL bundle is almost 3.5 times the size of tRPC, which means that much more loading time for sites that use it. 


> As an aside, we could still get the bundle size savings while using GraphQL by combining React Query with a GraphQL request library like the conveniently-named `graphql-request` (7.9kb). 


### React Query & Cache Management


A frequent bug we’ve run into building with Apollo Client has to do with updating the cache after a mutation. If you create your queries right, and if your mutations return the correct data, mutations are supposed to automatically update its fancy normalized cache. But that’s rarely how it works out in practice. 


This could be a classic case of “you’re holding it wrong”, except it’s not clear what the correct solution is. Do we need to use `refetchQueries`? That gets kind of messy depending on which variables are being used for the query. Maybe we should use `writeQuery` or `writeFragment`? That has the same pitfalls, plus we have to write a bunch of extra code to surgically alter the cache. It shouldn’t be this hard to keep the cache up to date after a request. 


It’s impossible to overstate how many nice things React Query provides out of the box. Compared to Apollo Client’s incredibly complicated normalized cache, React Query is a walk in the park. tRPC simplifies it further by keying the cache entries to each procedure. Triggering a refetch is as easy as running `utils.user.find.invalidate({ id: user.id })`.


Along with it comes easy mutation handling, simple patterns for optimistic updates (along with rollbacks in case there are errors), and heuristics for automatically refetching data so it stays fresh. Combined with tRPC’s type safety, React Query is the most delightful way to fetch data on the client.


### IDE Improvements


The methods tRPC 10 uses for type checking have some surprising and convenient side effects. Since the frontend queries are type checked based on the backend procedures, VS Code’s “Go To Definition” feature works _across the network boundary_. I can click on a procedure definition in a client-side file and it will take me right to where that procedure is defined on the server-side.

<div style="position: relative; padding-bottom: 66.91449814126395%; height: 0;"><iframe src="https://www.loom.com/embed/46b60b16261b45f9b1345da760256ba6" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen style="position: absolute; top: 0; left: 0; width: 100%; height: 100%;"></iframe></div>


It gets better. Not only can we jump to the file, if we use VS Codes “Rename All Instances” on an input or procedure name, those changes also propagate between the server and client.


<div style="position: relative; padding-bottom: 61.997703788748574%; height: 0;"><iframe src="https://www.loom.com/embed/51c8057410f14aa396b23b8171b31e8e" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen style="position: absolute; top: 0; left: 0; width: 100%; height: 100%;"></iframe></div>


Even with the fancy GraphQL codegen, this just isn’t possible with the way GraphQL works. Having these tools right in the IDE is a huge win for convenience and productivity.


## What did we lose?


Very rarely does a major change like this not have downsides, and leaving GraphQL is no exception. As we’ve made the jump, there are a handful of things GraphQL provided for free that require a bit more effort using tRPC.


### Field Requests


The most obvious is that the client doesn’t get to pick which fields it fetches, whereas GraphQL allows the client to define exactly the fields it wants for any request. There are two workarounds. 


First, a tRPC procedure could be defined with an input where the client can request certain fields. This might take a bit of finagling to get the input and output types to line up, but would provide a similar experience to GraphQL. 


However, I think a better option is to embrace the simplicity of having the client accept whatever the server returns. In my experience, over-fetching is not as big of a problem as many people make it out to be. If there is a particular procedure that returns far too much or not enough data, there’s nothing wrong with creating a second procedure that returns data more closely scoped to what the client needs.


### Field Resolvers


Another huge benefit of GraphQL is the ability to create custom resolvers on a field-by-field basis. The default is to just pass through whatever value the parent resolver provided for that field, but GraphQL makes it really easy to combine and transform fields, even using arguments from the request as part of the transformation. Common examples include a virtual `fullName` field which combines the `firstName` and `lastName` fields, or a `date` field which lets the user choose what format they want for the date.


This is another case where tRPC can get around the limitation either by using an input or creating a new procedure to provide the transformed data. Probably my biggest lesson in using tRPC: Creating a new procedure is cheap. So long as they are named well, having many procedures is not a bad thing.

### Introspection and Documentation

GraphQL is famous for its self-documenting API. As part of the spec, GraphQL servers can publish an introspection query, which lets anyone see what objects, queries, and mutations the server supports. It’s great for visibility and learning what the API supports.

tRPC has no such introspection query. In fact, it isn’t great for creating a public facing API. The types themselves work great for building first-party apps, but if you want to open your API up to third parties, you’ll have to create your own documentation. 

There is an [OpenAPI Extension](https://github.com/jlalmes/trpc-openapi) for tRPC that can be used to create a more REST-like API from your procedures, and that in turn can be used for auto-generating documentation. But if my app needed to offer third-party API access, I would likely reach for GraphQL again.

### Colocated TypeScript Only

One of the best things about GraphQL is that it isn’t actually a technology, it’s just a specification. That means anyone can create a GraphQL server or in any language. So long as it matches the spec, it will work across whatever platform it's used on, whether it be Ruby, JavaScript, Elixir, or Python. That’s part of the reason GraphQL codegen is so valuable. It allows schema definitions and types to be generated regardless of the backend that hosts the GraphQL server.

The same can’t be said for tRPC. Its type checking only works if the server is written in TypeScript, since the client needs those TypeScript types to enjoy its type safety. It’s possible in the future that servers that implement the tRPC HTTP spec could be written in other languages, but they would require a codegen process to make the proper types available to the client.

And, if your tRPC server is located in a different repository, you’ll have to figure out a way to get the generated types into your client app to enjoy the type safety. tRPC works best when the client and server are either part of the same app, like with Next.js, or part of a monorepo.

## Conclusion

tRPC has proven to be exactly the tool that Echobind needs for building our client’s apps. GraphQL may be powerful and capable, but the boilerplate and complexity it requires often slows us down and makes it difficult to build robust, responsive sites. With tRPC, we hope to double down on our commitment to building the best possible software we can for ourselves and our clients.

---

[View on echobind.com](https://echobind.com/post/why-we-ditched-graphql-for-trpc)

---

# Book Review: Ask Your Developer by Jeff Lawson

> A true TL;DR of Ask Your Developer, by Jeff Lawson. Claire shares her favorite takeaways from this great read.

_By Claire Surma · 2022-11-03_

**tl;dr** A quick summary of three main themes in *Ask Your Developer: How to Harness the Power of Software Developers and Win in the 21st Century*, by Jeff Lawson.

![](https://cms.echobind.com/assets/1d930968-a4e6-4d9c-b122-eae3e25023ab)

★★★★

Jeff Lawson is a lifelong software developer and serial entrepreneur, turned co-founder and CEO of Twilio. In his book, ‘Ask Your Developer’, Jeff recounts his windy road to founding Twilio in 2008 and how it grew into a multi-billion dollar company and then became a publicly traded company in eight years. Without getting too into the tech weeds, he shares how AWS works based on his early experience at Amazon and how Twilio simplifies customer communications. But ‘Ask Your Developer's’ real "meat and potatoes" is Jeff's rich storytelling and real-life examples of how a culture of continuous experimentation and creativity paired with open communication between developers and customers yields more successful products and both happier employees and end users.

As a strategy team member at Echobind, a software development agency, here are my three favorite takeaways from the book.

**Innovation = Experimentation + Iteration**

Jeff encourages teams to shed the traditional rigid company culture where mistakes get punished and instead celebrate on-the-job learning and testing.  And with that added on, to  be comfortable with "disproving hypotheses," or in other words, "failure." Jeff sees code as a creative medium and developers as creative problem solvers who probably got into engineering because they like consistent new challenges that allow them to learn and expand horizons. Everyone benefits when engineers are presented with the customer's problem (not a list of requirements) and asked to experiment with their creativity to build a solution within existing safeguards — time restraints, data structures, code paths, etc.

**A Culture of Small Teams is Key**

Beyond an open learning environment woven into the development process and supported top-down, Jeff also values a culture of unity and collaboration across departments. The full small project team involved in building the product — developers, creative, customer service, etc. — should meet regularly to test and review progress together.  Doing this together allows for early detection of blockers, pivot needs, and holistic solutions. By encouraging a culture of agile flexibility and small project team autonomy keeps everyone on a project connected to the problem and accountable to the customer. Jeff reminds us that the best solutions don’t always come from the loudest or highest-ranked person, and when small teams are valued, quieter voices can be heard.

**Customers and Engineers Should Be Communicating, Early and Often**

A customer-centric company consistently visits and re-visits customers' needs in relation to its outputs and self-corrects when there is a disconnect. Throughout the book, Jeff reiterates this importance by having customers share the problems they are trying to solve via software directly with the engineers and for developers to remain in the customer feedback loop throughout the development lifecycle. Developers are solving real-life problems, and Jeff thinks it is essential for them to know the humans behind the problems and the nuanced depth and _whys_ of the issue. Humanizing the customer and their problem will bring purpose to the developer's work and heighten their instincts when making effort versus expected value estimations and quick decisions that impact product features and functions.

Jeff’s relatable tone and storytelling make ‘Ask Your Developer’ an easy choice for the non-coder wanting to read a book about software. If you work closely with software developers, this book is a good starting point on strategic ways you can better support engineers, the development process, and the end product.

**Resources**

- [Official Website](https://www.askyourdeveloper.com/)

---

[View on echobind.com](https://echobind.com/post/ask-your-developer-book-review)

---

# What’s the difference between artifacts and cache in GitHub Actions?

> When should you use artifacts and when should you use Cache in @ GitHub Actions? Our lead software developer Cully Larson provides some of the best use cases for each.

_By Cully Larson · 2022-10-27_

GitHub Actions has a couple of ways to store files: artifacts and cache. They have enough functional overlap that it can be difficult to decide which is best to use. Rather than look at the capabilities of these actions (there are enough articles out there on that), let’s look at situations where you would want to use each one.


## Tl;dr

- Use artifacts if you want to share files between jobs in the **same workflow** or view/download files after a workflow has been completed.
- Use cache if you want to share files **between workflows** (e.g. between the workflows run by multiple PRs or commits).

## Artifacts


Artifacts essentially allow you to do two things: store files that will persist after a job is completed, or share files with another job in the same workflow. You would use artifacts if you want to:

- Access files after a job has been completed. For example: logs, test coverage, screen recordings of e2e tests, etc. GitHub Actions will allow you to view or download these files.
- Produce files in one job and use them in another job in the same workflow. This is the more interesting use case and the one that can seem to have some overlap with the cache action.

An example of using artifacts to share files between jobs is a project build step. Let’s say you’re using GitHub Actions to test your application and you have unit tests, API tests, and E2E tests. Each of these test suites needs its own environment and can run in parallel as long as those environments are isolated. So you decide to split your workflow into three jobs:

1. Unit tests
2. API tests
3. E2E tests

As you set up this workflow, you realize that each job needs to build the application. So why not create another job for the build step and then share the build between the other jobs? You can do this with artifacts.

![](https://cms.echobind.com/assets/23ae19ac-c378-4bcb-8054-8018d365f449)

The “Project Build” job stores the build files as an artifact and the other jobs download the build files before running. That way the build only happens once.

You can do this with cache as well. However, cache files are shared between workflows (not just within a single workflow), you would need to know that the files used to build your project have not changed. This can be a challenge and might not be something you want anyway. Since artifacts are only accessible within a specific workflow, you don’t need to worry about other workflows grabbing them by accident.


## Cache


GitHub Actions cache allows you to store files that can be used between workflows. It is recommended for files that won’t change often, or at least won’t change on every run of the workflow. However, if you can think of a reason to share files between workflows, even if they change on every run, then cache is the way to go. You can even use it to share files between jobs in the same workflow. Though, as we’ve seen, artifacts are likely going to work better for that.


The frequently cited use case for cache is storing project dependencies (e.g. npm, pip, Gradle, etc.). These may not change frequently between PRs/commits. So caching them and sharing them between workflows (i.e. between the runs from PRs and commits) makes sense.


But you can be more creative with cache if it solves your problem. For example, if you need to download a large database that doesn’t change frequently between builds, you can use cache to store it. Basically, as long as you need to access some files between workflows, use cache.


## Resources

- [https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts](https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts)
- [https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows](https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows)

---

[View on echobind.com](https://echobind.com/post/difference-between-artifacts-and-cache-in-GitHub-Actions)

---

# How Businesses Benefit from Integrating with Stripe

> Not only can Stripe help a company accept various payment methods, it can enable recurring payments, invoicing, decrease fraud, and overall optimize revenue.

_By Claire Surma · 2022-10-12_

Our team is consistently exploring new ways we can better support our customer’s big ideas, expand their reach, and grow their revenue streams. For that reason, Echobind recently became a [Stripe](https://stripe.com) consulting partner, getting a number of our people trained and certified in Stripe’s products.


## What is Stripe?

Stripe is a platform for payments infrastructure. In its simplest form, the Stripe platform enables businesses to accept various payment methods — credit or debit cards, mobile wallets, and buy now / pay later services — and securely transfer customer funds into their business account(s). But Stripe also does a whole lot more! It can enable apps to accept recurring payments, handle invoicing easily, decrease fraud, refund charges, and overall optimize a company’s revenue. 


## Why should anyone care about payments processing?

The most recent [Census Bureau's Annual Retail Trade Survey](https://www.census.gov/programs-surveys/arts.html) reported e-commerce sales increased by $244.2 billion, or 43%, in the first year of the pandemic. With this continued e-commerce boom ballooning online transactions, it is important for businesses to safely position themselves in the digital economy in order to participate in customers’ purchasing and spending trends. This is why our Echobind team has dedicated time and resources to becoming experts in developing and implementing online payment solutions.


## Who Uses Stripe?

- As a customer, you have definitely paid a business via Stripe products
- eCommerce companies accepting one-time customer payments, like [Papier](https://stripe.com/en-hu/customers/papier)
- B2B SaaS companies accepting recurring payments, like [Slack](https://stripe.com/customers/slack)
- Marketplace or SaaS Platforms accepting one-to-one or one-to-many payments, like [InstaCart](https://stripe.com/customers/instacart) or [Shopify](https://stripe.com/customers/shopify)
- Online content creators
- Individuals with small businesses all the way to large Fortune 500 enterprises


## Why Use Stripe?

Numbers sometimes speak louder than words. Here are a few stats on why many companies use Stripe’s platform: 

- increases cart conversion rates by 35%
- reduces fraud by 32%
- accepts 135+ currencies in 47+ countries

Here are some features of the Stripe platform:

- A seamless customer checkout experience
- Collects, routes, and pays money globally
- Flexible pricing options (per seat, fixed fee, or usage-based)
- Accepts coupons, free trials, prorations, and overages
- Comprehensive financial health reporting
- Third-party systems (ERPs and CRMs) integration
- Compliance requirement guides
- Security features that encrypt and protect financial information

Any business processing payments can integrate with Stripe products to improve their checkout experience, reduce fraudulent charges, and accept more forms of payment online. Our Echobind team members from Engineering, Strategy, and Community and Partnerships received comprehensive training on Stripe products to become Stripe Practitioner, Implementation Architect, and Developer Certified. This means we have a team of experts ready and available to help in advising on payment processing needs, implementing eCommerce payment solutions, and integrating Stripe APIs into apps and platforms for our clients.

_**(To learn more about how Echobind works with Stripe, visit to our [Stripe partner page](/partners/stripe))**_

---

[View on echobind.com](https://echobind.com/post/how-businesses-benefit-from-integrating-with-stripe)

---

# Export Multiple Frames in Figma to a Single Multi-Page PDF

> When you export multiple frames using Figma’s asset export, the resulting output is a separate PDF file for each slide. Here’s how to export a single, multi-page PDF in Figma.

_By Kaila VanSumer · 2022-10-10_

At Echobind we make _a lot_ of slide deck presentations. Our preferred design tool for everything is Figma, but when you export multiple frames using Figma’s traditional asset export option in the design panel on the right, the resulting output is a separate PDF file for each of your slides. This is fine if you want to spend extra time combining your slides together in Preview and making sure they’re in the right order after you’ve exported them, but for those of us who have better things to do there’s a much easier way to export your slide deck into a single, multi-page PDF. Here’s how:


## Step 1:


Make sure all your frames are 1) on the same page and 2) in order from left to right, top to bottom. This is how Figma will read the order and will ensure all your slides are ordered correctly once they’re exported.

![](https://cms.echobind.com/assets/4181b7d2-c69e-419d-aa32-d2afbd07d287)

## Step 2:


Next, select your frames by clicking and dragging on the canvas to highlight all the frames. You can also hold `shift` and click each frame to select if that’s easier. Note: the order in which you select the frames will not affect how the slides are ordered once they’re exported; that’s determined by how the frames are arranged in Step 1.

![](https://cms.echobind.com/assets/a13746e0-c9e2-4d01-8790-19d62645bc66)

## Step 3:


With your frames selected, click on the Figma icon dropdown in the top left corner of the screen. Hover over `File` and then click `Export frames to PDF…`. Name and save your file, and you’re done!

![](https://cms.echobind.com/assets/20cf7658-00e0-417b-8c7a-cec5d4942ad0)

**Bonus** If your PDF is too large to send via email, you can reduce the file size in Adobe Acrobat or Preview. This is usually found under `File` and the command will be something like `Reduce file size` or `Compress PDF`. Alternatively, you can use Adobe’s free [PDF compression tool](https://www.adobe.com/acrobat/online/compress-pdf.html).

---

[View on echobind.com](https://echobind.com/post/export-a-pdf-from-figma)

---

# Why Our Team is Stripe Certified; Yes, Including Non-Developers

> Turning our team members into Stripe Certified Developers and Implementation Architects helps us help our clients.

_By Mike Cavaliere · 2022-10-04_

Stripe’s incredibly robust ecosystem allows our clients to accept more payments in more elaborate and customized ways than ever. And software agencies like us can quickly implement these complex solutions with an ease that did not exist a decade ago. Turning our team members into Stripe Certified Developers and Stripe Certified Implementation Architects helps us further that goal. 


## Stripe is Powerful…Projects are Complex


Stripe's APIs themselves—from Checkout to Billing to Payments—are incredibly intuitive and a joy to work with. Our clients’ business models can be much more complex. 


Take, for example, one of our projects in the real estate space, a mobile app. The owners of the app needed to allow their customers to subscribe to multiple services provided by different businesses as a bundled subscription so that users could make a single payment. After each successful payment, the submitted amount would be split and transferred into appropriate Connect accounts for every service provider. 


Each Stripe API we used—Connect, Elements, and Billing—is straightforward and extremely well-documented. But to implement a solution like the above one, each developer needs to know the capabilities of Stripe’s tools so that planning the architecture is less risky and implementation goes smoothly. 


## What Stripe Developers Learn


Being certified gives our engineers access to thorough training resources and testing provided by Stripe. After undergoing Stripe Developer training, our engineers have a more solid understanding of:

- Which Stripe product to use for different use cases
- Internal Stripe APIs, limitations, and capabilities
- All about the payments industry: credit processors, fraud, chargebacks, etc
- What happens behind the scenes when payments are accepted: the full lifecycle of a charge

And since it’s developer-specific training, they also learn:

- Technical best practices
- Project launch best practices
- How to thoroughly use Stripe’s UI tools in development, testing, and production

## What Stripe Implementation Architects Learn


Our employees who have received Stripe Implementation Architect certification get a similarly deep understanding of the Stripe platform, its products, and the industry. They also work hands-on with Stripe’s APIs during training and on projects. But in addition, they receive training and testing on the specifics of:

- Architecting large-scale, complex payment flows with Stripe products
- Project planning for complex Stripe implementation projects
- Strategies for determining business needs and choosing approaches accordingly
- Lots more tools for proposing and executing the right solution for the project

## What Non-Developers Learn about Stripe


Others in our organization have also undergone Stripe Sales Training or general Stripe product training and business fundamentals. This keeps them knowledgeable about things that are very important for our customers, such as common payment needs of different business models (SaaS apps, marketplaces, eCommerce apps), and a good understanding of Stripe products, just like the developers and architects. 


By having even non-developers trained on these things, everyone working on a Stripe implementation project can work together to ensure that we’re taking the right approach at all times. 


## Knowledge is Power…and Quality


We are always looking for ways our team members can remain a few steps ahead when it comes to technical and strategic expertise. 


After training like this, our engineers have a more solid knowledge of the industry and finer details of all things Stripe. That level of understanding, combined with their hands-on experience implementing payments solutions, means that:

- they’ll ship code that is rock-solid
- they’ll be more likely to spot risks in project planning
- they’ll solve technical problems more wisely

And for our architects: 

- they’ll account for all stakeholders and business goals when doing discovery
- they’ll propose the most comprehensive solution that targets all of those goals using Stripe products efficiently
- they’ll work with our developers to execute it to perfection

The end result: solving the right problem, with the right tools, in the right timeline - providing the right solution for our clients. 


## Doin’ it (Stripe) Well


As we specialize in software solutions that integrate Stripe payment processing products, it is important that our whole team — both code-facing and client-facing members — is confident in their Stripe expertise. Having a qualified, Stripe-certified team offers the highest value to our customers. This allows us to provide better and faster service when advising on payment processing needs, building and implementing Stripe payment solutions, and integrating Stripe APIs to brand specifications.

_**(To learn more about how Echobind works with Stripe, visit to our [Stripe partner page](/partners/stripe))**_

---

[View on echobind.com](https://echobind.com/post/why-our-team-is-stripe-certified)

---

# Slicing TypeScript Literal Strings

> Using TypeScript’s literal inference, we can pull specific segments out of literal strings. This can help reuse types and keep our code DRY.

_By Alex Anderson · 2022-09-29_

Template literal strings are a powerful feature of TypeScript that makes it easy to create and modify literal string types. In this post, we’ll look at the syntax TypeScript provides for both adding and removing parts of a literal string type. This is especially handy when creating reusable types to dynamically access object keys.


> You can see the types used in this post in [this TypeScript playground](https://www.typescriptlang.org/play?#code/MYewdgzgLgBAZgJwK4EsoGERLFCMC8MA3jDAFCmkCGADjQDYCmAXAIwA0pFlARlWPyrMArJ3KUYIBPwDmLAMxkAvmTJQAnjUbxkaANKN1BGAGtDIODA1aLO1Biw4IAblXXtie5mxQDRwgAGACREnvqGSt44Aa4A9LESpAB6APxumtoAmgAiKAiMwFAo4HiEAERQIDRlMAA+MGXAjDiMCDX1ZTwgUJUAtmWu7jAAGrn5hcWQxmVMcFDtDU0tbXUNCCgyABbzgxkwAAogEGiTxsFEOXkFRSVKALQho1cTtzFk8YkwqelaMEh0rWAVAgjAAYroHD4-GcQgBVAEIIEggA8YV8hgAfJFHFAAu8Ep8vmk1HsIPQUE0ACbg+zQwhoqLooyMAAeUGalLw5xQYDgrTsaAAclReoxsT4AjAUgKoMLRTBmDAwIwAG6tOIEiTfACQZFAkFgjF6VBQ9AAgpTKfkIKUGlR+JTWhBwAABAqbEA8HmUgB0oH6u1+RpN9GyIGNPOMZG17lswdNFqtjBtMFZ7LAnJg52g6zAMiULpCPL5CBglPDJrASh9IRzPPzkuj0vLEbA5G1iuVaoQziAA).


### Literal String Types


Most string types can represent _any_ string, the same way that a JavaScript string value could contain any string.


```typescript
let fruitName:string = "apple";
fruitName = "banana";
```


But sometimes a particular value should only contain _certain_ strings. A common example is a value that references the keys of an object. For that, we put the exact values the string can be in a union of [literal string types](https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#literal-types).


```typescript
const fruitCounts = {  apple:1,  banana:5,  orange:3}
type fruitKey = "apple" | "banana" | "orange";
```


> An easier way to get the keys of an object is using `typeof` to get the type of the object and `keyof` to get the keys of that object type. It has the same effect as the manual list we wrote out above.


There are often situations where the literal types don’t match how the values are used. Suppose we had our `fruitKey` type, but instead of matching those keys exactly, the `fruitCounts` object had slightly different keys.


```typescript
const fruitCounts = {  
	appleCount:1, 
	bananaCount:1, 
	orangeCount:1
}
```


Rewriting our `fruitKey` list would be annoying. What if, instead, TypeScript could automatically rewrite those keys to match a new pattern?


### Template Literal Types


TypeScript provides that functionality through [template literal types](https://www.typescriptlang.org/docs/handbook/2/template-literal-types.html). They look just like JavaScript’s template literal strings - you can even interpolate other types in the middle of the literal string - but instead of string values, they transform literal string types.


```typescript
type fruitCountKey = `${fruitKey}Count`;
// type fruitCountKey = "appleCount" | "bananaCount" | "orangeCount"
```


> Notice how the template literal type operates on each of the items in the type union, distributing the transform across all of them.


One thing to bear in mind is the computational complexity of generating these types. Combining a union of three types with a static string will yield a union of three types, but template literal types let you combine multiple unions together that would include every permutation. 


```typescript
type YDirections = "top" | "center" | "bottom";
type XDirections = "left" | "center" | "right";
type Position = `${YDirections}-${XDirections}`;
// type Position = "top-center" | "top-left" | "top-right" ... [6 more]
```


> The type above only generated 9 results, but adding more terms would increase that exponentially. At a certain point, it will give up and throw  an error, but even before that point it can slow down your type checking as TypeScript generates all the possible options. Sometimes, it’s probably best to stick with `string`.


TypeScript [includes helpers ](https://www.typescriptlang.org/docs/handbook/2/template-literal-types.html#intrinsic-string-manipulation-types)for adjusting the capitalization of literal strings too. They include `Uppercase<>`, `Lowercase<>`, `Capitalize<>`, `Uncapitalize<>`.


```typescript
type uppercaseFruitCountKey = `${Uppercase<fruitKey>}Count`
// type fruitCountKey = "APPLECount" | "BANANACount" | "ORANGECount"
```


Suppose we were going the other way though - we had an object with keys for `appleCount`, etc. and we wanted to _remove_ `Count` from the string literal. For that, we combine template literal types with conditional types.


### Conditional Types & Inference


[Conditional types](https://www.typescriptlang.org/docs/handbook/2/conditional-types.html) are a more advanced feature of TypeScript that let you change a type based on a condition. In essence, a conditional type says “If this type _extends_ (or matches) this other type, then replace it with that type. Otherwise, replace it with yet another type.” For example, here’s a conditional type that removes `null` and `undefined` from a type union by replacing them with `never`.


```typescript
type NonNullable<Input> = Input extends null | undefined ? never : Input
```


This type says “If `Input` is either `null` or `undefined`, replace it with `never` (which removes it from the union). Otherwise, keep `Input` in the union.”


[Conditional ](https://www.typescriptlang.org/docs/handbook/2/conditional-types.html#inferring-within-conditional-types)[_inference_](https://www.typescriptlang.org/docs/handbook/2/conditional-types.html#inferring-within-conditional-types) takes it a step further, by tapping into TypeScript’s inference system to pull types out of other types. We can use it to unwrap a `Promise<>` type to get at the resolved value.


```typescript
type UnwrapPromise<Input> = Input extends Promise<infer ResolvedType> 
	? ResolvedType
	: Input;
```


This type says “If `Input` is a `Promise<>` type, infer what the resolved type of that promise is (the type inside the brackets of `Promise<>`), pull it out into its own type called `ResolvedType`, and have that be the final type. Otherwise, have the final type be `Input`.”


The `infer` keyword works for more than just generic `Promise<>` types too. In fact, it can be used to pull out function parameters, return values, and, yes, even parts of a template literal string.


### Template Literal Inference


Remember, we have a union of literal strings that looks like this.


```typescript
type fruitCountKey = "appleCount" | "bananaCount" | "orangeCount"
```


We want to remove the “Count” from each of those strings, leaving us with just the fruit names. Or in other words, we want to pull the fruit name out into a new type. What we can do is create a template literal type that matches the `${fruitName}Count` pattern, and use `infer` to pull the fruit name into a type.


```typescript
type fruitKey = fruitCountKey extends `${infer fruitName}Count` 
	? fruitName 
	: never;
// type fruitKey = "apple" | "banana" | "orange";
```


This type says “If fruitCountKey matches the pattern `${fruitName}Count`, meaning it ends with ’Count’, then grab that first part of the string, put it in a `fruitName` type, and have that be the final type. Otherwise, return never, which removes that item from the union entirely.”


And, of course, this can be be used with even more complicated patterns combining literal types, string types, and inference - such as this one which successfully pulls the domain name out of an email address.


```typescript
const emailAddress = "team@echobind.com";
type emailDomain = 
	typeof emailAddress extends `${string}@${infer domain}.${string}` 
	? domain 
	: never;
// type emailDomain = "echobind"
```


Remember, any of these types only work in development with literal types. When the program is actually run, all of these types are removed from the code, so this doesn’t replace runtime code. Instead, these tools can help you adjust and transform your types to provide better type safety and editor auto-completion without writing a bunch of extra code.

---

[View on echobind.com](https://echobind.com/post/slicing-typescript-literal-strings)

---

# Getting Started with Next.js, GraphQL and React Query (1/3)

> Curious about Next.js, GraphQL, or React Query but not sure where to start? Follow along with Preston for a three-part series on setting up and using all three.

_By Preston Kelly · 2022-09-28_

## TL;DR


Add a GraphQL endpoint, and wrap your app with `QueryClientProvider` from [@tanstack/react-query](https://tanstack.com/query/v4). Next, create an async function and use `GraphQLClient` from [graphql-request](https://github.com/prisma-labs/graphql-request) to request data.


## Create Next App


Start by creating a basic [Next.js](https://nextjs.org/) app with the following command, `npx create-next-app@latest --ts` . This command will create a new Next.js app with a TypeScript configuration, hence the `--ts` flag. Head to the `/pages` directory and you'll notice an `index.tsx` page and an `_app.tsx` page. You'll see an `/api` directory. This is where we'll add our GraphQL server.


Let’s transition to configuring the server. Create a new file in the `/api` directory and name it `graphql.ts`. This file will serve as the single endpoint we need for GraphQL. To import GraphQL we'll need 3 packages. Install these packages with this command `npm install apollo-server-micro micro graphql`.


Inside our new file, we are going to create our GraphQL [types](https://www.apollographql.com/docs/apollo-server/schema/schema) and [resolvers](https://www.apollographql.com/docs/apollo-server/data/resolvers/). In a typical app, you’d want to create a new file for these and import them elsewhere in the app. For this app, we'll create our types and resolvers in the same file. Let’s create a User type that has an id, firstName and lastName field. We’ll also add a Query type, which we will need when we create our resolver.


```typescript
// pages/api/graphql.ts
const typeDefs = gql`
	type User {
		id: ID
		firstName: String
		lastName: String
  }
	type Query {
		getUser: User
  }
`;
```


The next step is to create the resolvers or in other words, tell GraphQL where to look for the data. In most cases, the resolvers will connect to your database or an external API source. In our case, we’ll return some hard-coded data. I’ll add an id of 1, a firstName of “Hello” and a lastName of “World”. Now that we have our types and resolvers set up, the next step is to pass these to `ApolloServer`.


 


```typescript
// pages/api/graphql.ts
const resolvers = {
  Query: {
    getUser: () => ({ id: "1", firstName: "Hello", lastName: "World" }),
  },
};

const apolloServer = new ApolloServer({
  typeDefs,
  resolvers,
});
```


The final step is to create our handler function that will become our Next.js API route. Inside this handler function, we have to do two things. The first is to start the server. We then have to use `apolloServer.createHandler` to connect Apollo Server to Next.js. We’ll also disable bodyParser since this is handled by default in GraphQL.


```typescript
// pages/api/graphql.ts
import { gql, ApolloServer } from "apollo-server-micro";
import { NextApiRequest, NextApiResponse, PageConfig } from "next";

const typeDefs = gql`
  type User {
    id: ID
    firstName: String
		lastName: String
  }

  type Query {
    getUser: User
  }
`;

const resolvers = {
  Query: {
    getUser: () => ({ id: "1", firstName: "Hello", lastName: "World" }),
  },
};

const apolloServer = new ApolloServer({
  typeDefs,
  resolvers,
});

const startServer = apolloServer.start();

export default async function handler(
  req: NextApiRequest,
  res: NextApiResponse
) {
  await startServer;
  await apolloServer.createHandler({
    path: "/api/graphql",
  })(req, res);
}

export const config: PageConfig = {
  api: {
    bodyParser: false,
  },
};
```


## React Query


Let’s switch to the front end so that we can add [React Query](https://tanstack.com/query/v4) to our app. To begin, we'll need some packages for React Query. Install the packages we need with this command `npm install graphql-request @tanstack/react-query`. Head over to `/pages/_app.tsx` and create a `QueryClient` imported from `@tanstack/react-query`. We’ll wrap our app with `QueryClientProvider`, passing our `QueryClient` as the client parameter. This will allow us to access React Query throughout our entire app.


```typescript
// pages/_app.tsx
import "../styles/globals.css";
import type { AppProps } from "next/app";
import { QueryClient, QueryClientProvider } from "@tanstack/react-query";

// Create a client
const queryClient = new QueryClient();

function MyApp({ Component, pageProps }: AppProps) {
  return (
    <QueryClientProvider client={queryClient}>
      <Component {...pageProps} />
    </QueryClientProvider>
  );
}

export default MyApp;
```


We can now create a function that will allow us to query for our user on the back end. We’ll use `GraphQLClient` and pass in the GraphQL endpoint that we made. We can then use this to make requests. To query for our user, we need to add a `gql` statement and pass it as a parameter to a `graphQLClient` request. We’ll then use this function by passing it to React Query’s `useQuery` hook, along with a key `get-user`. From this hook, I’ve destructured the isLoading state and the data. I’ve added an if statement to check if the data is loading. All we have to do now is display the data using some styling from [Tailwind](https://tailwindcss.com/) and a couple of `p` tags. 


```typescript
// pages/index.tsx
import type { NextPage } from "next";
import { useQuery } from "@tanstack/react-query";
import { GraphQLClient, gql } from "graphql-request";

const UserQuery = gql`
  query getUser {
    getUser {
      id
      firstName
			lastName
    }
  }
`;

const graphQLClient = new GraphQLClient("http://localhost:3000/api/graphql");
const fetchUser = async () => {
  return await graphQLClient.request(UserQuery);
};

const Home: NextPage = () => {
  const { isLoading, data } = useQuery(["get-user"], fetchUser);

  if (isLoading) return <p>Loading...</p>;

  return (
    <>
      <div className="flex h-screen w-screen justify-center items-center">
        <div>
          <p>{data.getUser.id}</p>
          <p>{data.getUser.firstName}</p>
					<p>{data.getUser.lastName}</p>
        </div>
      </div>
    </>
  );
};

export default Home;
```


## Conclusion


As you can see, adding GraphQL to a Next.js app takes only a few steps. Today, we created a Next.js app with a TypeScript configuration. We created a GraphQL server with types and resolvers, and added React Query to query for our hard-coded data. I encourage you to extend this project. Create a new type, create a resolver for that type, and add a new function to query for that data using React Query. 


## Resources


[https://tailwindcss.com/](https://tailwindcss.com/)


[https://tanstack.com/query/v4](https://tanstack.com/query/v4)


[https://nextjs.org/docs/basic-features/typescript](https://nextjs.org/docs/basic-features/typescript)


[https://www.apollographql.com/docs/apollo-server/schema/schema](https://www.apollographql.com/docs/apollo-server/schema/schema)


[https://www.apollographql.com/docs/apollo-server/data/resolvers/](https://www.apollographql.com/docs/apollo-server/data/resolvers/)


[https://www.apollographql.com/docs/apollo-server/api/apollo-server/](https://www.apollographql.com/docs/apollo-server/api/apollo-server/)

---

[View on echobind.com](https://echobind.com/post/getting-started-with-nextjs-graphl-and-react-query)

---

# Design… It’s like Building a House

> Good design goes far beyond aesthetics and is one of the most important things you can invest in while building a product.

_By Lexi Namer · 2022-09-27_

A 5 Minute Video Explainer

<div style="position: relative; padding-bottom: 56.25%; height: 0;"><iframe src="https://www.loom.com/embed/d0369186695e4fdbb1c7f3251065b341" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen style="position: absolute; top: 0; left: 0; width: 100%; height: 100%;"></iframe></div>


### What is Design


A product can be beautiful but if it doesn’t function well, it won’t be a good experience. Design goes beyond aesthetics and is a complex form of communication and problem solving. It is one of the most important things you can invest in while building a product to increase sales and revenue, foster brand and customer loyalty, and reduce development cost and time. 


Did you know that first impressions are 94% design related[^1] and 88% of online shoppers[^2] say they wouldn’t return to a website after having a bad user experience? Google now ranks websites based on UX, so having a great experience means you have an edge over your competitors. 


To understand some of what goes into the design process at Echobind and why investing in design is a smart business move, let’s consider how a house gets built. To build a beautiful and quality house, each of these aspects are critical, inform each other, and cannot be done in isolation. Design is the same and helps ensure you have a product customers love. 


### Laying the Ground Work


You wouldn’t buy the first plot of land you saw without doing your homework, getting a survey, exploring the neighborhood, understanding the zoning laws, and talking to friends and family, and the same goes for product development. Without doing discovery and research, you are making a big investment in product development based on assumption. Designers conduct market research, look at competitors, and interview you and your customers to validate all ideas, ensuring that the product you build is exactly what needs to be built to meet your business and customer needs. 


### Building the Structure 


Next comes the structure. You wouldn’t start wiring the electric or picking out paint colors without ensuring the architecture is approved and the structures are sound. As designers, we rely on UX or user experience design to ensure that every step of your product is cohesive and has been intentionally laid out from the first moment someone lands on your product to when they leave. 83% of customers[^3] say a seamless experience across all devices is important, and we rely on responsive design techniques and industry design standards to ensure your product works just as well on a phone as it does on a desktop. 


### Designing the Interiors


Only after research has been done and the structure is in place do we focus on the UI or the user interface. Just like paint colors and the interior design of house can make someone feel confident and comfortable, interface design does the same. It is a strategic form of visual communication that leaves your customer with an elegant, cohesive, and delightful experience across all devices that reflects your brand and mission. We focus on the smallest of details across layout, typography, color usage, interactions, and design patterns to ensure that your product is just as beautiful as it is functional. 


### Approving and Maintenance 


Once the house is built, it requires exhaustive approvals and tests to ensure that it is up to code and is ready for you to call home. In design, we use usability testing which catches up to 85% of errors before your product goes development or market. And once you are all moved in, a house requires regular maintenance and support to stay up to date. As trends evolve, customer needs shift, and your business changes, your product needs to be regularly maintained. Just as you would regularly test your air conditioner, designers use testing, audits, and other, and accessibility audits to ensure it is ADA compliant. 


### The Swiss Army Knife of Product Development


As UI and UX designers, we are not just painters, but researchers, strategists, architects, interior designers, handymen and so much more. Throughout the design process, we ensure that each and every step of your product is a modern and seamless experience across all devices, ensuring that every customer has a great experience. 


Additionally, by investing in design at the start of your project, it can save a tremendous amount of time and money over the course of the product development. Fixing a problem[^4] in development costs up to 10 times more than fixing it in design, and up to 100 times more if the product is already in market. 


At Echobind, we offer a full array of software design services and can help you discover the right solution, design a new product, improve and existing product, or even augment your internal team. Our process is iterative and flexible based on your needs, timeline, and budget, and our team is ready to help.


[^1]: https://www.researchgate.net/publication/221516871_Trust_and_mistrust_of_online_health_sites
[^2]: https://www.toptal.com/designers/ux/ux-statistics-insights-infographic
[^3]: https://www.fullstory.com/blog/digital-experience-consumer-survey/
[^4]: https://s3.amazonaws.com/coach-courses-us/public/theuxschool/uploads/The_Trillion_Dollar_UX_Problem.pdf

---

[View on echobind.com](https://echobind.com/post/what-is-design)

---

# Using the currentColor CSS Property with SVG

> The CSS currentColor property is a powerful tool for passing colors down the cascade, including to SVG elements.

_By Alex Anderson · 2022-09-26_

The `currentColor` property provides the current text color of the selected element. The CSS cascade makes it so the child’s text color matches the parents, but the `currentColor` property can be used for any other color property as well, like background or border colors.

```css
.parent {
  color: red;
}

.child {
  border-color: currentColor; /* Also red */
}
```


This also includes properties on [SVG](https://en.wikipedia.org/wiki/Scalable_Vector_Graphics) elements on the page. Using `currentColor` as the `fill` or `stroke` color on a shape or path will have that element take on the text color of its parent. It even works with a CSS animation. 


<iframe height="300" style="width: 100%;" scrolling="no" title="CurrentColor SVG" src="https://codepen.io/alexanderson1993/embed/qBojRqV?default-tab=html%2Cresult" frameborder="no" loading="lazy" allowtransparency="true" allowfullscreen="true">
  See the Pen <a href="https://codepen.io/alexanderson1993/pen/qBojRqV">
  CurrentColor SVG</a> by Alex (<a href="https://codepen.io/alexanderson1993">@alexanderson1993</a>)
  on <a href="https://codepen.io">CodePen</a>.
</iframe>


It’s important to remember that this only works if the SVG is rendered directly on the page - it won’t work if the SVG is loaded with an `<img>` tag.

---

[View on echobind.com](https://echobind.com/post/currentcolor-css-property-with-svg)

---

# Make Prisma Ignore a Migration Change

> How to avoid resetting your database when you need to change a Prisma migration after it has been run.

_By Cully Larson · 2022-09-23_

Have you ever made a change to a Prisma migration and received a warning like this when you run `prisma migrate`:


```text
The migration `20220805133548_my_migration` was modified after it was applied.
? We need to reset the PostgreSQL database "mydb" at "example.com:3033".
Do you want to continue? All data will be lost.
```


This warning appears because Prisma tracks changes to migrations. If a migration has been applied and is later modified, Prisma will know it and assume the database is out of sync with your migration. Since it can’t know exactly what was changed and only selectively apply those changes, it opts for re-applying all of the migrations.


This is almost always what you want to happen. Changing a migration will likely cause your database to not match what is in your migrations. You probably should re-apply all your migrations at that point. However, sometimes you want to make a change to a migration file that wouldn’t cause a change to your database. For example:

1. Adding a comment to a migration. The migration still makes the same changes to the database it did before. But the file has changed, so Prisma will notice it.
2. Adding something like an `IF NOT EXISTS` statement to a query. This may not change the functionality of the query. It will still e.g. `CREATE` something like it did before. It just won’t `CREATE` it if it already exists.
3. A third reason. You know what it is (it’s whatever you have in mind that isn’t one of the reasons above).

It should be noted that what is to follow is almost certainly a bad idea to do in production. It’s likely only going to be reasonable to do as part of your dev process. For example, if you’re working on a PR, you apply a migration, realize you want to add a comment to the migration, and then you don’t want to re-apply the migration and lose some test data you’ve set up.


## Tell Prisma to ignore the changes


So we need to somehow tell Prisma that this change is fine and it should be ignored. We can do that by creating a new checksum for the migration file and then overwriting the checksum for that migration in the database (again, not a great idea in production or if you care about your database).


## Generate a new checksum


You can create a new checksum for the migration file using this command:


```bash
shasum -a 256 prisma/migrations/20220510001642_my_migration/migration.sql
```


This will produce a value like:


```text
fc27e97b9a61877f7f59d59a69c8c0bd2cd3271bc44b9f208800ed458d18a10b  prisma/migrations/20220510001642_my_migration/migration.sql
```


You’ll want the first value, the random looking string: `fc27e97b9a61877f7f59d59a69c8c0bd2cd3271bc44b9f208800ed458d18a10b`


## Update the database


Now we need to update the database with our new checksum. Use your favorite database client and look at the `_prisma_migrations` table. This might be hidden in some database clients, so you’ll need to mess around with settings until it shows up. Prisma uses this table to track data about migrations. We’ll be looking at the `migration_name` and `checksum` columns.


Find the entry in the database for your migration:


```sql
SELECT "id", "migration_name", "checksum"
FROM "_prisma_migrations"
WHERE "migration_name" = '20220510001642_my_migration'
```


It will show you something like:


```sql
id: f8b25a66-0020-4a32-9a56-7441665d9eda
migration_name: 20220510001642_my_migration
checksum: 6c2def14f22254ead278f805a5e63641319d546d2739de65da5fd98f615ba56b
```


Now update the `checksum` to the new value we generated:


```sql
UPDATE "_prisma_migrations"
SET "checksum" = 'fc27e97b9a61877f7f59d59a69c8c0bd2cd3271bc44b9f208800ed458d18a10b'
WHERE "migration_name" = '20220510001642_my_migration'
```


## Conclusion


That’s it! Prisma now thinks it has applied your migration because the checksum in the database matches the current checksum of the migration file. You should be able to run `prisma migrate` again without any issues. Remember that this will not actually apply your migration again. As far as Prisma is concerned, it has already been applied.

---

[View on echobind.com](https://echobind.com/post/make-prisma-ignore-a-migration-change)

---

# Dynamic CMS-driven Redirects with Next.js

> Redirects send a request for one page to another page, and are crucial for maintaining good SEO. We can manage these with our own Next.js app and any CMS.

_By Alex Anderson · 2022-09-22_

Despite our best efforts, websites change all the time. Content from multiple pages might be combined into one, or maybe the title of a page has changed, causing the URL to change with it. But what happens to the links to these pages on other websites? Redirects are the solution built right into the foundations of the web.


[An HTTP redirect](https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections) simply takes an incoming request to the _source_ URL and tells the web browser to request the _destination_ page instead. Redirects are essential for maintaining search engine optimization and making sure that outside visitors coming to your website aren’t greeted with a 404 page.


The trick is how to tell your server what sources to go what destinations and making sure these run on every request.


### Storing Redirects


We could just have a static list of redirects in code, but that makes it so only developers can update those redirects. Often it’s content creators or marketers without programming experience who make these changes.


Instead, we’ll store our redirects in a content management system. There are literally _dozens_ of CMS tools out there, including Wordpress, Sanity.io, StoryBlok and Contentful. The key feature you need is the ability to modify the schema to support custom collections and fields. For today, I’ll be using [Directus](https://directus.io).


First, we’ll create a collection called `Redirects`. We only need three columns: `source`, `destination`, and `permanent`.


![](https://cms.echobind.com/assets/5c7a262a-bdaf-47a8-b269-925a9b02a3b8.png)


Then we can use the CMS to add whatever redirect records we may need.


Finally, we need to query our CMS to get all of the redirect records. Directus automatically generates a REST and GraphQL API for any collections you create. Here’s the GraphQL query that we’ll use to get our redirects. 


```graphql
query Redirects {
  Redirects {
    source
    destination
    permanent
  }
}
```


Your CMS might be different, but all of them have some way to get the data out, whether it be an HTTP API or an SDK of some kind. I’ll leave it as an exercise to the reader to figure out how that works in your particular circumstances.


> For some CMSs, you might need to adjust the permissions or use an API token to access the data in your Redirects collection. I chose to make the Redirects collection publicly accessible, but you might want to restrict it.


Now that our redirects are stored and we have a way to get them, we need to teach our server how to apply them to requests.


### Serving Redirects


If we were using a traditional server-side framework like Express, Fastify, or Koa, we could run middleware on every request that checks the URL and sends the redirect response if needed.


```javascript
const redirects = [];

function redirectMiddleware(req, res, next) {
  const pathname = new URL(req.url).pathname;

  const redirect = redirects.find(item => item.source === pathname)

  if (redirect) {
    const statusCode = redirect.permanent ? 308 : 307
    return res
			.set("Location", redirect.destination)
			.status(statusCode)
			.send()
  }

  return next();
}

// ...

app.use(redirectMiddleware)
```


> It is possible to further optimize this code for performance and capability, perhaps by transforming our list into a map keyed by the source, but for our purposes this works just fine.


That’s great for a dedicated server, but lots of apps these days are built with Next.js. While it does have support for [being embedded in a custom server](https://nextjs.org/docs/advanced-features/custom-server), Next.js is much happier being served from serverless functions. How can we ensure our redirects are checked on every page?


### Next.js Middleware Redirects


Middleware has been stable since Next.js 12.2. This allows you to write a lightweight function which is run before every request. If you deploy your site on a fancy hosting platform like Vercel or Netlify, they’ll even run your middleware _on the edge_, which means close to your users. This makes middleware an excellent choice for running fast, simple checks as users browse your website.


This example comes straight from the [Next.js Middleware documentation](https://nextjs.org/docs/advanced-features/middleware). It shows how you can hard-code redirects, or even use in-code logic, to redirect users. 


```graphql
// middleware.ts
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'

// /about-2 is the destination
export function middleware(request: NextRequest) {
  return NextResponse.redirect(new URL('/about-2', request.url))
}

// /about/:path* is the source
export const config = {
  matcher: '/about/:path*',
}
```


Notice that `matcher` at the bottom? This is the `source` that we’ll be redirecting the user from. It tells Next.js to only run the middleware when the user visits a page that matches one of the matchers. 


You see, middleware might be fast, but it still adds time to the request. If it runs on every request it’s going to slow down every request. This is especially true if we’re making a request to our CMS every time a user visits a page. And we can’t dynamically set the matcher values — Next.js requires that those are static strings. No variables allowed.


Middleware is still great when you need to redirect based on complicated logic involving headers, cookies, or other factors. But it’s going to be a bit too slow to use on every single page.


Fortunately, Next.js has _another_ feature which has been around even longer than Middleware. It might not be as powerful as Middleware, but it’ll work great for our purposes.


### [Next.js Redirects](https://nextjs.org/docs/api-reference/next.config.js/redirects)


Static redirects have been around since Next.js 9.5 and can be configured in `next.config.js` using an async function. That function returns a list of objects with `source`, `destination`, and `permanent` — exactly what we’re storing in our CMS. 


When the Next.js app is compiled, it will call the `redirects` function to create a static list of redirects. Then, for every request, it will quickly check the request URL against the redirect list and send the user to the right page. 


This _does_ mean we’ll need to rebuild our app any time the redirects list changes, but that likely won’t happen often, and most CMSs allow you to automatically call a webhook whenever a record is added or changed. We can call a URL provided by our hosting platform to trigger a new build. Here’s what that looks like using Directus Flows.


![](https://cms.echobind.com/assets/d9f90e7a-a605-4776-8335-6423daeae308.png)


And what about the code? The way we set up our collection means the data is already in the shape Next.js expects. We just make the request and put it in the list of redirects.


```javascript
// next.config.js
const { default: request, gql } = require("graphql-request");

async function redirects() {
  let cmsRedirects = [];
  try {
    const results = await request(
      `${process.env.NEXT_PUBLIC_DIRECTUS_URL}/graphql`,
      gql`
        query Redirects {
          Redirects {
            source
            destination
            permanent
          }
        }
      `
    );

    cmsRedirects = results.Redirects;
  } catch (err) {
    console.error("Error getting CMS redirects:", err.message);
  }
  
  return cmsRedirects;
}

module.exports = {
  redirects,
  // ... more config here
}
```


Add a redirect to the collection, deploy this to your hosting platform, and you should see any requests to the `source` bring you to the `destination` page. Excellent!

---

[View on echobind.com](https://echobind.com/post/dynamic-cms-driven-redirects)

---

# Ten Tips for Effective (and Less Frequent) Meetings

> Here are ten ways Echobind strives to control the number of meetings on our team members' calendars while making the essential virtual meeting as productive, meaningful, and engaging as possible.

_By Claire Surma · 2022-09-21_

Echobind is a fully remote software company with employees from all departments—creative, strategy, development, and partnerships—scattered across 15 states. Our remote culture relies on virtual communication as our primary tool for internal collaboration and strategic planning, as well as client-facing exchanges. Not surprisingly, although unfortunate, a Harvard Business Review survey recently noted that [71% of employees regard meetings as unproductive and inefficient](https://hbr.org/2017/07/stop-the-meeting-madness), and over half of those surveyed found unproductive meetings kept them from their meaningful work. Even more unfortunate for us, research suggests that[ the remote meeting consistently ranks at the top for being poorly run, not engaging, and ineffective](https://www.stevenrogelberg.com/virtual-meetings). Gulp!


Here are ten ways Echobind strives to control the number of meetings on our team members' calendars while making the essential virtual meeting as productive, meaningful, and engaging as possible.

1. **Create an agenda for every meeting and make it visible to all meeting invitees beforehand.** The process of creating an agenda will help the facilitator ensure the intention is clear and weighty enough to warrant a meeting. Once an agenda is drafted, share it with all invitees and seek input from key stakeholders on additional topics that should be included. It is best to save meeting agendas in a place that is easy for attendees to access.
2. **Highlight anticipated actions or questions needing answers on the shared meeting agenda**. While there is a time and place for morale-boost gatherings (watercooler chats, occasional office celebrations, etc.) and the information meetings (company updates, quarterly reports, etc.), most meetings are action-focused. Aligning on the collective goals or outcomes of a meeting beforehand will help attendees stay on topic during the meeting and make recapping the accomplishments easier.
3. **Consider an email with bulleted action items instead of a meeting** if there isn't enough robust content to develop a meaningful meeting agenda.
4. **Contemplate the cost of the meeting and who needs to be in attendance.** Don't over-invite and utilize "required" and "optional" meeting invites. More attendees on a virtual call tend to lessen productivity. Remember, virtual meetings can always be recorded and shared with those whose presence is non-essential. Optional invites require a culture of trust in a colleague's ability to control workday productivity. To go back to point one, sharing meeting agendas beforehand will help optional invitees discern if their presence is needed.
5. **Leverage video recordings in place of live** **meetings.** This is especially helpful when a discussion is unnecessary or when sharing demos or product how-tos that may benefit from repeat watching. Echobind uses Loom videos as a substitute for non-essential internal and external meetings. Loom is an excellent tool because of its analytics to review who watched, and the call-to-action button features.
6. **Be a conscientious meeting facilitator and prime attendees for action.** Steven G. Rogelberg, researcher and author of[ The Surprising Science of Meetings: How You Can Lead Your Team to Peak Performance](https://www.stevenrogelberg.com/the-surprising-science-of-meetings-by-steven-rogelberg), gives the following tips on leading effective meetings: welcome folks as they enter (login), express gratitude for attendance, initiate meeting with a clear objective, and recognize accomplishments.
7. **Keep videos on during meetings whenever** **possible** to encourage the facilitator and attendees to minimize outside distractions and avoid multitasking. Video also gives visual cues to the facilitator on engagement.
8. **Wrap up meetings with intention.** Be mindful of the established end time; with five minutes left, revisit the anticipated actions on the meeting agenda and recap accomplishments. As a group, identify all decisions made, clearly state the individuals responsible for follow-up actions, and agree on the due dates of those actions.
9. **Adopt a company-wide communication app to exchange quick questions and needs to help avoid non-essential meetings**. At Echobind, we use Discord internally and lean into direct messages and public topic board features. We also utilize Slack for our external and client-facing communication.
10. **Promote a company-wide "heads down day"** free from meetings and also free from guilt when denying or rescheduling non-necessary outside meeting requests.

We have seen the benefits when focused energy transforms meetings. Virtual meetings don't have to be a time-suck. When done with intention, meetings are a valuable tool for developing strategy, decision-making, and productivity.


**Resources:**

- [https://hbr.org/2017/07/stop-the-meeting-madness](https://hbr.org/2017/07/stop-the-meeting-madness)
- [https://www.stevenrogelberg.com/virtual-meetings](https://www.stevenrogelberg.com/virtual-meetings)

---

[View on echobind.com](https://echobind.com/post/ten-tips-for-more-effective-and-less-frequent-meetings)

---

# Running Cypress tests in parallel in GitHub Actions

> Making Cypress run in parallel can speed up your build times and help you have more confidence your app works correctly.

_By Cully Larson · 2022-09-16_

End-to-end tests can take forever to run. And what are they really doing with their time? Clicking some buttons, typing some text, and engaging in a lot of waiting around. E2e tests have got to spend—I don’t know for sure, so I’ll make up a number—half their time just waiting for things to happen. If they’re essentially idle a lot of the time, it makes sense to run e2e tests in parallel.


[Cypress](https://www.cypress.io/) supports [parallelization](https://docs.cypress.io/guides/guides/parallelization). However, and I’ll leave it up to the reader to decide why this is the case, Cypress doesn’t make it very clear that in order to run tests in parallel you need a Cypress Dashboard account. Cypress Dashboard is what coordinates processes and load balances tests.


Cypress Dashboard has a free tier. That might work for some projects. It could be worth paying for a plan for enterprise projects. They have some features that are appealing beyond parallelization. But what if you don’t want to pay for a plan?


There’s a project called [Sorry Cypress](https://sorry-cypress.dev/) that does something very similar to Cypress Dashboard. They have paid plans if you want them to host the dashboard. Or you can host your own for free. But, stick with me here, what if you don’t want to pay anything and you don’t want to host your own dashboard service? Read on, dear reader.

## Split up our jobs

This is an article about running tests in GitHub Actions. So let's talk about jobs. By the end of the article, we’ll create a job that runs the e2e tests in parallel. Each of those jobs will likely need a production build of the project to run against. But rather than have each individual e2e job build the project, we’ll perform the project build in its own job and share the build with the e2e jobs.

```yaml
name: CI

on: [push]

env:
  NODE_ENV: test
  DATABASE_URL: postgresql://postgres:postgres@localhost/myapp_test?schema=ci

jobs:
  build:
    name: Build
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Setup Node
        uses: actions/setup-node@v2.1.2
        with:
          node-version: 16.13.2
          cache: yarn

      - name: Install packages
        run: yarn install --frozen-lockfile

      - name: ESLint
        run: yarn lint

      - name: Check TypeScript
        run: yarn typecheck

      # Build app
      - name: Build App
        run: yarn build

      # Save build for other jobs
      - name: Save build folder
        uses: actions/upload-artifact@v2
        with:
          name: the-build
          if-no-files-found: error
          path: build
          retention-days: 1
```


Now we can use this build in our e2e jobs. If you have other jobs besides e2e tests (e.g. unit tests, API tests, stress tests, etc) you can use the build in them as well.


## An end-to-end job

As a baseline, let’s look at our e2e job without parallelization.


```yaml
e2e:
  name: e2e Tests
  runs-on: ubuntu-latest
  needs: build

  services:
    postgres:
      image: postgres:13.2
      ports: ['5432:5432']
      # Make sure the database is ready before we use it
      options: --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5
      # These need to be set on the service or it won't start for some reason
      env:
        POSTGRES_USER: postgres
        POSTGRES_PASSWORD: postgres
        POSTGRES_DB: myapp_test

  steps:
    - name: Checkout code
      uses: actions/checkout@v2

    - name: Download the build
      uses: actions/download-artifact@v2
      with:
        name: the-build
        path: build

    - name: Setup Node
      uses: actions/setup-node@v2.1.2
      with:
        node-version: 16.13.2
        cache: yarn

    - name: Install packages
      run: yarn install --frozen-lockfile

    - name: Run Cypress e2e tests
      uses: cypress-io/github-action@v4
      with:
        # we have already installed all dependencies above
        install: false
        start: yarn test:server
        wait-on: 'http://localhost:3001'
        command: yarn cypress run
      env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

    - name: Upload Cypress Screenshots
      uses: actions/upload-artifact@v1
      # Only capture images on failure
      if: failure()
      with:
        name: cypress-screenshots
        path: cypress/screenshots

    - name: Upload Cypress Logs
      uses: actions/upload-artifact@v1
      # Only capture logs on failure
      if: failure()
      with:
        name: cypress-logs
        path: cypress/logs

    - name: Upload Cypress Videos
      uses: actions/upload-artifact@v1
      # Only capture videos on failure
      if: failure()
      with:
        name: cypress-videos
        path: cypress/videos
```


This will run all of our tests in one job. To begin our parallelization journey, we need to run multiple versions of this job. We can do that with a [matrix strategy](https://docs.github.com/en/actions/using-jobs/using-a-matrix-for-your-jobs).


```yaml
strategy:
    fail-fast: false
    matrix:
      containers: [0, 1, 2, 3, 4]
```


This will run our e2e tests in five different jobs/containers. However, as it is, each job will do the same thing; they will each run all of our tests.


## Split up our tests


We need a way to split our tests up. We could use an orchestration service like Cypress Dashboard or Sorry Cypress, as discussed. But without something like that, we need a way to split our tests up [deterministically](https://en.wikipedia.org/wiki/Deterministic_algorithm) (the same way every time), so that each of our five e2e jobs knows which tests it should run, each of the tests is only run once, and none of the tests are left out (all of them are run).


`cypress run` has a `--spec` argument that allows us to define which test files should be run. If we can split our test files up, we can pass them to `--spec`, and only those test files will be run. But how to split up our tests? The simplest approach is to get a list of all the test files, sort them in a consistent way, and then divide them evenly among each of our e2e jobs. We need a script for that.


```typescript
// cypress-spec-split.ts

import fs from 'fs/promises';
import globby from 'globby';
import minimatch from 'minimatch';

// These are the same properties that are set in cypress.config.
// In practice, it's better to export these from another file, and
// import them here and in cypress.config, so that both files use
// the same values.
const specPatterns = {
  specPattern: 'tests/e2e/**/*.cy.{ts,tsx,js,jsx}',
  excludeSpecPattern: ['tsconfig.json'],
};

// used to roughly determine how many tests are in a file
const testPattern = /(^|\s)(it|test)\(/g;

const isCli = require.main?.filename === __filename;

function getArgs() {
  const [totalRunnersStr, thisRunnerStr] = process.argv.splice(2);

  if (!totalRunnersStr || !thisRunnerStr) {
    throw new Error('Missing arguments');
  }

  const totalRunners = totalRunnersStr ? Number(totalRunnersStr) : 0;
  const thisRunner = thisRunnerStr ? Number(thisRunnerStr) : 0;

  if (isNaN(totalRunners)) {
    throw new Error('Invalid total runners.');
  }

  if (isNaN(thisRunner)) {
    throw new Error('Invalid runner.');
  }

  return { totalRunners, thisRunner };
}

async function getTestCount(filePath: string): Promise<number> {
  const content = await fs.readFile(filePath, 'utf8');
  return content.match(testPattern)?.length || 0;
}

// adapated from:
// https://github.com/bahmutov/find-cypress-specs/blob/main/src/index.js
async function getSpecFilePaths(): Promise<string[]> {
  const options = specPatterns;

  const files = await globby(options.specPattern, {
    ignore: options.excludeSpecPattern,
  });

  // go through the files again and eliminate files that match
  // the ignore patterns
  const ignorePatterns = [...(options.excludeSpecPattern || [])];

  // a function which returns true if the file does NOT match
  // all of our ignored patterns
  const doesNotMatchAllIgnoredPatterns = (file: string) => {
    // using {dot: true} here so that folders with a '.' in them are matched
    // as regular characters without needing an '.' in the
    // using {matchBase: true} here so that patterns without a globstar **
    // match against the basename of the file
    const MINIMATCH_OPTIONS = { dot: true, matchBase: true };
    return ignorePatterns.every((pattern) => {
      return !minimatch(file, pattern, MINIMATCH_OPTIONS);
    });
  };

  const filtered = files.filter(doesNotMatchAllIgnoredPatterns);

  return filtered;
}

async function sortSpecFilesByTestCount(specPathsOriginal: string[]): Promise<string[]> {
  const specPaths = [...specPathsOriginal];

  const testPerSpec: Record<string, number> = {};

  for (const specPath of specPaths) {
    testPerSpec[specPath] = await getTestCount(specPath);
  }

  return (
    Object.entries(testPerSpec)
      // Sort by the number of tests per spec file, so that we get a bit closer to
      // splitting up the files evenly between the runners. It won't be perfect,
      // but better than just splitting them randomly. And this will create a
      // consistent file list/ordering so that file division is deterministic.
      .sort((a, b) => b[1] - a[1])
      .map((x) => x[0])
  );
}

export function splitSpecs(specs: string[], totalRunners: number, thisRunner: number): string[] {
  return specs.filter((_, index) => index % totalRunners === thisRunner);
}

(async () => {
  // only run this if called via the CLI
  if (!isCli) {
    return;
  }

  try {
    const specFilePaths = await sortSpecFilesByTestCount(await getSpecFilePaths());

    if (!specFilePaths.length) {
      throw Error('No spec files found.');
    }

    const { totalRunners, thisRunner } = getArgs();

    const specsToRun = splitSpecs(specFilePaths, totalRunners, thisRunner);

    console.log(specsToRun.join(','));
  } catch (err) {
    console.error(err);
    process.exit(1);
  }
})();
```


_Note that this script was roughly adapted from_ [_this one_](https://gist.github.com/hosuaby/dd5d0c52bc20558568ae17c5a6d8ceef)_._


Run the script like this: `yarn --silent ts-node --quiet cypress-spec-split.ts 5 2` where `5` is the total number of jobs, and `2` is the number of the current job (starting with `0`). The second parameter is needed so that we know which job to assign test files to (each job gets its own, unique set of tests).


Essentially, this script:

1. Fetches a list of all the e2e test files.
2. Naively tries to figure out how many tests are in each file.
3. Sorts the list of tests by the number of tests in each file.
4. Assigns each file to a specific job (i.e. the number value of `thisRunner`). It attempts to evenly divide the tests between jobs. That’s why they’re sorted by the number of tests in each file, so that one job doesn’t end up with all the files with the most tests. Without this, some jobs could take much longer than others. Even so, it’s unlikely that the script will exactly evenly divide the test files. That’s one upside of an orchestration service (it will divide tests more evenly). But in practice, this works well enough.
5. Outputs the list of tests for a job so that it can be directly passed to `--spec`.

To run our tests, we will update the e2e test step in the workflow and use our script:


```yaml
- name: Run Cypress e2e tests
  uses: cypress-io/github-action@v4
  with:
    # we have already installed all dependencies above
    install: false
    start: yarn test:server
    wait-on: 'http://localhost:3001'
    # NOTE: This doesn't work. Keep reading to find out why.
    command: yarn cypress run --spec $(yarn --silent ts-node --quiet cypress-spec-split.ts 5 ${{ matrix.containers }})
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
```


The `5` is the total number of jobs and `${{ matrix.containers }}` is the number of the job from our matrix (i.e. one of `[0, 1, 2, 3, 4]`; which is why we start them from zero).


However, we have a problem. Unfortunately, [cypress-io/github-action](https://github.com/cypress-io/github-action) doesn’t allow us to use [command substitution](https://www.gnu.org/software/bash/manual/html_node/Command-Substitution.html), environment variables, or [context values](https://docs.github.com/en/actions/learn-github-actions/contexts). We could just run the test command manually instead of using `cypress-io/github-action`:


```yaml
- name: Run Cypress e2e tests
  run: >
    doppler run --preserve-env --
    yarn start-server-and-test 'yarn test:server' http://localhost:3001
    "yarn cypress run --spec
    $(yarn --silent ts-node --quiet scripts/cypress-spec-split.ts 3 ${{ matrix.containers }})
    "
```


But that can end up being a bit complicated with waiting for test servers to start, etc. `cypress-io/github-action` does that for us, along with a lot of other things. And `cypress-io/github-action` will continue to improve. Using it is a better option in the long term.


If we want to keep using `cypress-io/github-action`, we need to create another script that basically just runs `cypress run` and fills in the `--spec` argument.


```typescript
// cypress-ci-run.ts

/**
 * This script runs Cypress tests in CI. It exists because we need to get split
 * up the tests between multiple runners, but we can't run that script in a way
 * that will pass a value to --spec directly, using cypress-io/github-action's
 * `command` property. It just won't let us include an env variable or do
 * command substitution.
 *
 * So, we can either just not use cypress-io/github-action or use a script like
 * this one to run the tests.
 */
import { exec } from 'child_process';

type GetEnvOptions = {
  required?: boolean;
};

function getEnvNumber(varName: string, { required = false }: GetEnvOptions = {}): number {
  if (required && process.env[varName] === undefined) {
    throw Error(`${varName} is not set.`);
  }

  const value = Number(process.env[varName]);

  if (isNaN(value)) {
    throw Error(`${varName} is not a number.`);
  }

  return value;
}

function getArgs() {
  return {
    totalRunners: getEnvNumber('TOTAL_RUNNERS', { required: true }),
    thisRunner: getEnvNumber('THIS_RUNNER', { required: true }),
  };
}

(async () => {
  try {
    const { totalRunners, thisRunner } = getArgs();

    const command = `yarn cypress run --spec "$(yarn --silent ts-node --quiet scripts/cypress-spec-split.ts ${totalRunners} ${thisRunner})"`;

    console.log(`Running: ${command}`);

    const commandProcess = exec(command);

    // pipe output because we want to see the results of the run

    if (commandProcess.stdout) {
      commandProcess.stdout.pipe(process.stdout);
    }

    if (commandProcess.stderr) {
      commandProcess.stderr.pipe(process.stderr);
    }

    commandProcess.on('exit', (code) => {
      process.exit(code || 0);
    });
  } catch (err) {
    console.error(err);
    process.exit(1);
  }
})();
```


This script:

1. Pulls the total number of jobs (`totalRunners`) and the number of this job (`thisRunner`) from env variables.
2. Executes the `cypress run` command with `--spec`.

## Put it all together


Taking all we’ve built up so far and with our scripts located in `scripts/cypress-spec-split.ts` and `scripts/cypress-ci-run.ts` (relative to the root of the project), we get this workflow:


```yaml
name: CI

on: [push]

env:
  NODE_ENV: test
  DATABASE_URL: postgresql://postgres:postgres@localhost/myapp_test?schema=ci

jobs:
  build:
    name: Build
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Setup Node
        uses: actions/setup-node@v2.1.2
        with:
          node-version: 16.13.2
          cache: yarn

      - name: Install packages
        run: yarn install --frozen-lockfile

      - name: ESLint
        run: yarn lint

      - name: Check TypeScript
        run: yarn typecheck

      # Build app
      - name: Build App
        run: yarn build

      # Save build for other jobs
      - name: Save build folder
        uses: actions/upload-artifact@v2
        with:
          name: the-build
          if-no-files-found: error
          path: build
          retention-days: 1
  e2e:
    name: e2e Tests
    runs-on: ubuntu-latest
    needs: build

    strategy:
      fail-fast: false
      matrix:
        # Run copies of the current job in parallel. These need to be a
        # continuous series of numbers, starting with `0`. If you change the
        # number of containers, change TOTAL_RUNNERS below.
        containers: [0, 1, 2, 3, 4]

    services:
      postgres:
        image: postgres:13.2
        ports: ['5432:5432']
        # Make sure the database is ready before we use it
        options: --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5
        # These need to be set on the service or it won't start for some reason
        env:
          POSTGRES_USER: postgres
          POSTGRES_PASSWORD: postgres
          POSTGRES_DB: myapp_test

    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Download the build
        uses: actions/download-artifact@v2
        with:
          name: the-build
          path: build

      - name: Setup Node
        uses: actions/setup-node@v2.1.2
        with:
          node-version: 16.13.2
          cache: yarn

      - name: Install packages
        run: yarn install --frozen-lockfile

      - name: Run Cypress e2e tests
        uses: cypress-io/github-action@v4
        with:
          # we have already installed all dependencies above
          install: false
          # build: yarn build
          start: yarn test:server
          wait-on: 'http://localhost:3001'
          command: yarn ts-node scripts/cypress-ci-run.ts
        env:
          # the number of containers in the job matrix
          TOTAL_RUNNERS: 5
          THIS_RUNNER: ${{ matrix.containers }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

      - name: Upload Cypress Screenshots
        uses: actions/upload-artifact@v1
        # Only capture images on failure
        if: failure()
        with:
          name: cypress-screenshots
          path: cypress/screenshots

      - name: Upload Cypress Logs
        uses: actions/upload-artifact@v1
        # Only capture logs on failure
        if: failure()
        with:
          name: cypress-logs
          path: cypress/logs

      - name: Upload Cypress Videos
        uses: actions/upload-artifact@v1
        # Only capture videos on failure
        if: failure()
        with:
          name: cypress-videos
          path: cypress/videos
```


I tried to make this as general as possible, but it’s not going to exactly fit everyone’s needs. I’m hoping it gives you enough to work with if you want to adapt it to your specific use case.


## Results


At Echobind we’ve been running this solution in a production app for a while. When we rolled it out, it dropped CI runtimes from 30-40 minutes down to about 20 minutes. The "billable time" was roughly the same as it was before; maybe a few minutes more due to the overhead of setting up each parallel job.


We played around with the number of jobs. The benefit of adding more quickly diminishes.

- Two jobs save about 5-15 minutes.
- Three jobs save about 7-17 minutes.
- Four jobs save about 9-19 minutes.
- Five jobs save about the same as four.

Run times for GitHub Actions are wildly inconsistent, so these values are general and not exact.


We decided to go with three concurrent jobs. Going up to 4-5 jobs didn’t add enough benefit to make it worthwhile. But you can experiment and see what works for you.


## Rant


Cypress should do this out-of-the-box. There’s no reason it can’t implement naive test splitting internally, just as we’ve done above. And it would do a better job of it. I mean, [Playwright](https://playwright.dev/docs/test-parallel) does it. Hopefully, Cypress will get on board someday and this article will become a useless artifact of progress.


## Conclusion


Who reads conclusions? I’m just going to tell you what we did. You either read the article and did all the things and don’t need me to remind you, or you skimmed the article and got what you needed and skipped this part (that’s what I would have done). So no one is reading this except whoever is reviewing this article before publication—thanks for the review, btw!


Anyway, what did we do? We split up our GitHub Actions workflow into multiple jobs, we spilt our tests up so that we can run them in parallel, and we set up a job matrix for our e2e tests so that multiple jobs run at the same time.


## What’s next?


Well, you could adapt this to run your local e2e tests in parallel. That’s a bit tricky if they all share the same database. But keep your eyes on this space, because exactly that is coming soon!


## Resources

- [https://docs.cypress.io/guides/guides/parallelization](https://docs.cypress.io/guides/guides/parallelization)
- [https://sorry-cypress.dev/](https://sorry-cypress.dev/)
- [https://docs.github.com/en/actions/using-jobs/using-a-matrix-for-your-jobs](https://docs.github.com/en/actions/using-jobs/using-a-matrix-for-your-jobs)

---

[View on echobind.com](https://echobind.com/post/running-cypress-tests-in-parallel)

---

# CSS Custom Properties for Stacked Transforms

> The power that CSS Transforms provide is undeniable. Stacking CSS transforms lets you choose the order that the transforms are applied.

_By Alex Anderson · 2022-09-14_

### tl;dr

- Use the transform properties, like `rotate` or `translate` to apply transformations.
- Combine CSS custom properties for each transformation to apply stacked transforms from different selectors

# Stacked Transforms


The power that CSS Transforms provide is undeniable, but it comes at a cost. Anyone who’s ever tried to combine transformations using multiple selectors will tell you - it’s not as easy as you’d think.


Take a look at this 


```css
.box {
  width: 50px;
	height: 50px;
	background-color: rebeccapurple;
}
.rotate {
	transform: rotate(45deg);
}
.translate {
	transform: translate(100px, 0px);
}
```


Suppose you were to use them with this HTML element: `<div class="box translate rotate"></div>`. What do you think the result would be?


Since the `.translate` class is below the `.rotate` class in the CSS file, the styles override, and the `translate` property isn’t combined. The end result is a box that is translated 100px to the right. The rotation is completely ignored.


Fortunately, new properties have been [added to most browsers](https://caniuse.com/mdn-css_properties_translate) which allows each transform to be applied separately.


```css
.rotate {
	rotate: 45deg;
}
.translate {
	translate: 100px 0px;
}
```


This neatly solves that problem, but it introduces another one. 


### Applying Multiple Transformations


It’s not obvious, but applying multiple transformations with the `transform` property actually _stacks_ the transformations. If you apply a `rotate` before a `translate`, the element will actually translate based on the rotation that was previously applied. The same thing goes for a `scale` translation - it multiplies any `translate` transforms by however much the element was scaled.


<iframe height="300" style="width: 100%;" scrolling="no" title="Transformation Stacking" src="https://codepen.io/alexanderson1993/embed/preview/VwXrBOM?default-tab=css%2Cresult&editable=true" frameborder="no" loading="lazy" allowtransparency="true" allowfullscreen="true">
  See the Pen <a href="https://codepen.io/alexanderson1993/pen/VwXrBOM">
  Transformation Stacking</a> by Alex (<a href="https://codepen.io/alexanderson1993">@alexanderson1993</a>)
  on <a href="https://codepen.io">CodePen</a>.
</iframe>


The separate `rotate`, `scale`, and `transform` CSS properties apply their transforms atomically, without considering other transforms which might have been applied. In other words, the separate transform properties do _not_ stack.


Sometimes stacking transforms is exactly the behavior you want, but you once again run into the problem of combining transforms from different selectors. To solve that, we need to be a little tricky.


### Custom Property Transforms


Using CSS Custom Properties, we can create selectors which let us change individual transform properties without overriding the entire `transform`. We create a separate CSS Custom Property for each transform property we want to change, and then combine them all in a single `.transform` class. Here’s what that looks like.


```css
.transform {
  --translate-x: 0;
  --translate-y: 0;
  --rotate: 0;
  --scale-x: 1;
  --scale-y: 1;
  transform: translateX(var(--translate-x)) translateY(var(--translate-y))
    rotate(var(--rotate)) scaleX(var(--scale-x)) scaleY(var(--scale-y));
}
.rotate-45 {
  --rotate: 45deg;
}
.translate-x-100 {
  --translate-x: 100px;
}
```


Then we can apply our classes like this: `<div class="box transform rotate-45 translate-x-100">`.


> If this looks a lot like atomic CSS libraries,[ like Tailwind](https://tailwindcss.com), you’d be right! This is exactly the technique Tailwind uses to apply transforms.


This doesn’t give us much flexibility for stacking our transforms, though. It only lets us apply translates, then rotations, then scales. Fortunately, creating separate classes that alter the order is trivial at this point.


```css
.transform-rotate-first {
	transform: rotate(var(--rotate)) translateX(var(--translate-x)) 
    translateY(var(--translate-y)) scaleX(var(--scale-x)) scaleY(var(--scale-y));
}
```


Adding that class to our element would make it rotate first, then translate the element using whatever angle it was rotated to.


<iframe height="300" style="width: 100%;" scrolling="no" title="Transformation Classes" src="https://codepen.io/alexanderson1993/embed/preview/ExEbepw?default-tab=css%2Cresult&editable=true" frameborder="no" loading="lazy" allowtransparency="true" allowfullscreen="true">
  See the Pen <a href="https://codepen.io/alexanderson1993/pen/ExEbepw">
  Transformation Classes</a> by Alex (<a href="https://codepen.io/alexanderson1993">@alexanderson1993</a>)
  on <a href="https://codepen.io">CodePen</a>.
</iframe>

---

[View on echobind.com](https://echobind.com/post/css-custom-properties-for-stacked-transforms)

---

# Finding flaky Cypress tests by simulating a slow network

> Tracking down flakey tests is a challenge, but maybe slowing down your network can help track down the problem.

_By Cully Larson · 2022-09-09_

[https://www.loom.com/share/baf4691603084259aa4d2d06e3c517cb](https://www.loom.com/share/baf4691603084259aa4d2d06e3c517cb)


You have some flaky tests in Cypress: sometimes a test fails, sometimes it doesn’t, or different tests fail every time you run your test suite.


They might be flaky because **some of your tests are ending while a network request is still pending** or **a request fires after Cypress thinks the test has ended**. Your test tears down, another test sets up, and then your request goes through and fails.


Often you can locate these tests by **simulating a delay in your API responses**. This is especially helpful if the **tests are failing in** [**CI**](https://en.wikipedia.org/wiki/Continuous_integration) **only and not locally**. Simulating a delay essentially makes the problem more consistent. It doesn’t just crop up some of the time, when you lose the [race condition](https://en.wikipedia.org/wiki/Race_condition), it always happens. Here’s an example using GraphQL and Next.js:


```typescript
// pages/api/graphql.ts

const sleep = (delay: number) => {
  return new Promise<void>((res) => {
    setTimeout(res, delay);
  });
};

export default async function handler(req: NextApolloHybridRequest, res: NextApiResponse) {
	await sleep(500); // simulate slow network

  return server.createHandler({ path: GRAPHQL_PATH })(req, res);
}
```


And then run your tests again. You'll likely see errors in all the places where this issue happens.


Tip: The culprit is probably the test _before_ the one that fails since it's the one that made the request.


To resolve this, make sure your test confirms that the request went through (using `cy.intercept` and `cy.wait`, [examples here](https://www.kgajera.com/blog/2022/07/14/flaky-cypress-tests-due-to-unfinished-network-request/) and [here](https://docs.cypress.io/api/commands/wait#Alias)) or that it's looking for something on the page that will only appear when the request is complete (e.g. a success/error message). One caveat with looking for something on the page: your app might be doing optimistic updates (showing that something worked before the request is complete), so it might not be as reliable.


Remember to remove this delay before committing your changes.

---

[View on echobind.com](https://echobind.com/post/finding-flaky-cypress-tests)

---

# Echobind Ships Expo TypeScript Template 2.0.0

> We are excited to announce we have shipped a new version of our Expo React Native TypeScript template. Here are the latest changes.

_By Jenn Robison · 2022-08-23_

We are super excited to announce we have shipped a new version of our [Expo](http://expo.dev) [React Native](https://reactnative.dev/) [TypeScript](https://www.typescriptlang.org/) template. You may not even know we had a template out there, but our team has been busy using the first version on our mobile application projects, and we were ready to embrace some of the latest changes in the React Native & Expo communities.

Not familiar with our template? Here’s the tl;dr (too long; didn’t read)…

* An opinionated [Expo](https://docs.expo.dev/) Bare Workflow template that will allow you to start a new React Native project quickly with TypeScript, Prettier, ESLint, and some custom configurations to improve the development process. 💖

You might ask why Echobind has a template. Similar to our open source project, [Bison](https://github.com/echobind/bisonapp), we have implemented the same solutions many times for our clients, so why not make it an easy-to-use format and share it with the community?

**What’s new?**

This newest version of the Expo template upgrades from SDK version 44.0.2 to bring it current with the latest 46.0.2 (as of publishing this article). Check out [Expo’s blog](https://blog.expo.dev/expo-sdk-46-c2a1655f63f7) about the release of this version, as there are some really great improvements. This includes the upgrade from React 17 to 18, bringing in the latest and greatest of React Native and the new architecture of version 0.69.x.

There are several dependency updates for StoryBook and React Native Navigation, among others.

It’s super simple to give our template a try! Simply create a new Expo project and reference our template with the following command: 

```bash
expo init --template @echobind/expo-typescript
```

***To learn more about Echobind's React Native capabilities, visit our [React Native capabilities page](/services/react-native-app-development).***

---

[View on echobind.com](https://echobind.com/post/echobind-ships-expo-typescript-template-2-0-0)

---

# How to Blog in 10 Doable Steps

> Aug 17, 2022 | If you’ve ever experienced staring at a blank screen waiting for the words to come, this guide will help you find success in publishing a truly exceptional blog post.

_By Alex Anderson · 2022-08-17_

We’ve all been there. You know “content creation” is the trendy thing to do these days - you’ve gotta build that audience somehow! You figure the lowest-effort way to do that is writing a blog. The benefits are clear:

* Blogs are a great way to share knowledge and ideas broadly.
* Blogs are excellent for SEO and organic traffic.
* Blogs don’t need the expensive equipment that video and podcast production does.
* Blogs also don’t need consistency like a newsletter. Write whenever you feel like without sticking to a schedule.

In short, a low barrier to entry. Perfect for the first-time creators. You buy a domain, spend way too long setting up the perfect website, and finally sit down to write your first post.

As you write, you start to realize that maybe setting up the site was the easy part. You had a pretty good idea for the blog post, but putting it into words is more challenging than you thought.

If you’ve ever experienced staring at a blank screen waiting for the words to come, this guide will help you find success publishing a truly exceptional blog post.

As a software developer, I take large, complicated tasks and break them into smaller, more manageable tasks. For example, if I’m building an e-commerce checkout, my smaller tasks include wiring up the payment provider, creating a form for collecting contact information, writing a function to validate the shipping address, etc.

We can use the same technique to break up writing a blog post into smaller steps. Let’s go through the steps and see how they work in practice.

There’s value in considering all these steps, but feel free to adapt or omit any of them depending on how long your blog post is. A 300 word post likely won’t need a full-blown outline, but could benefit from finding a story.

## Pick a Topic

For many reasons, this first step is the most important. Find a topic to write about - hopefully something that is both interesting to you and provides value to your readers. In other words, write about something that someone else would enjoy reading about.

This isn’t as hard as it sounds - you writing about your topic means there is at least one person in the world interested in that topic, and it’s likely you aren’t alone in that. One topic-inspiring question is “What did I learn today?”

It’s a good practice to keep a topic journal. You’ll often think of topics at random times throughout the day. Having a place to quickly note them will make it easier for you to find those ideas later.

Obviously the topic guides what you write about, but it also informs how _long_ your blog post will be and how long it will take to write.

There’s a spectrum of _breadth_ and _depth_ of topics. You could take a very narrow topic, like “How to wash your hands” and spend a few hundred words on it. But a much deeper treatment that goes into why hand washing is important, the history of hand washing, the effects of good vs poor hand washing, and several different hand-washing techniques could fill a whole book.

Meanwhile, a broad but shallow “history of programming languages” topic that gives a survey without getting into specifics wouldn’t take very long to write. Unsurprisingly, going deep into such a broad topic could yield dozens of books.

My advice: Start small. Keep your blog post under 500 words. Your goal should be to deliver as much value to the reader in as small a package as possible, a skill that develops with practice. If your topic is simply too broad or too deep to keep small, consider breaking it into smaller topics and creating a series of blog posts.

Twitter has excellent examples of high value to word ratio. Just look for programming hot tips tweets or threads that break down complicated topics.

Remember, the goal here is to publish, not just curate ideas. When you’re ready to write, pick the topic you’re most excited about.

## Educate, Inform, or Entertain?

All media or “content” serves at least one of three purposes for viewers: Educate, Inform, or Entertain.

Educational material is usually the broadest and deepest, providing more practical information about the topic. Think textbooks, video courses, or open-source project documentation.

Media that informs might still be broad, but significantly less deep. Television news epitomizes this - there’s only so much airtime, so anchors hit the highlights and move on to the next story. This kind of blog post usually condenses a lot of knowledge and research into a more digestible package, just giving most interesting bits without sharing all the details. Email newsletters, press releases, many development tutorials, and “This week in X” blog posts demonstrate an information focus.

Entertainment exists for amusement. This media tugs at our emotions and brain neurotransmitters to give us a satisfying feeling after we’ve consumed it. Not all entertainment is strictly “funny” or “comedic” - horror or action movies give us their own form of enjoyable thrill, but a blog post that lands a few good jokes is definitely entertaining to read.

Guess which one of these readers enjoy the most? Yep, that’s right - entertainment. There’s a place for dry educational material or terse information, but the types of blog posts you likely want to write should always be entertaining. Otherwise, readers will lose interest and bail.

You might notice that many of these overlap across different media. A Bob Ross painting show is primarily educational, but the way he dispenses life advice alongside paintbrush technique make the show delightful and entertaining.

Think of educate, inform, and entertain as levers that you pull throughout your blog post. Make sure to keep a healthy helping of entertainment, usually by presenting the education or information in an interesting, enjoyable way. Avoid excessive formality - it can be off-putting and distracts from the actual value the blog post presents.

One last time for emphasis: Entertain. Entertain. Entertain. If you want your reader to like what you’ve written, make sure it’s entertaining.

## Research & Brain Dump

Now for the first bit of actual writing! This part is simple - take whatever you can think of about your topic, and get it out of your brain and onto paper - er - screen. If you don’t have enough knowledge in your brain about your topic, go find it somewhere, put it in your brain, and then write it down.

Read other blog posts or books, watch videos, listen to podcasts, take courses, talk to experts or friends, experiment, and most of all _ponder_. Think about your topic and the angles you might want to take as you write about it.

Of course, you might already know all that’s needed to write your blog post, and that’s great! Rush through this step and move on. The deeper and more broad your topic, the more time you’ll want to spend here.

This is also a good time to do SEO analysis on the topic you are writing about. See if there are any searchable angles worth pursuing to get the best SEO possible on the blog post. Ahrefs is a good tool for this.

## Find the Story

Humans _love_ storytelling. We can’t help it! Something about a beginning, middle, and end all tied together with a narrative is just so satisfying. Even better is when we _relate_ to the story being told. That makes narrative a _critical_ element in making entertaining media.

I’m not saying you need to start every blog post with “Once upon a time…” or create some cheesy hypothetical situation (like I did). But you need to provide some element to explain why your blog post exists. Why should your reader care about what you’ve written?

An easy trick: start with some problem, and promise a solution by the end of the blog post. The storyline could go through why the problem is a problem in the first place, possible solutions and why they fall short, and land on the actual solution and why it is superior. It’s a great way to hook interest, since any reader who has the same problem will be thrilled to eventually find the solution, and might find interest in the journey that gets them there.

I find it helpful to write a “Narrative Statement” - a single sentence that encapsulates the entire message I want to deliver with my blog post. It serves as a guidepost for the rest of the writing process, something I can look at to know if I’m on the right track.

## Outline

If the narrative statement is a single guidepost, an outline is a map showing the path our reader will follow as they read the blog post.

Your outline consolidates your ideas into distinct sections, while still making it easy to move ideas around. Writing your outline can help you make sense of your brain dump. It’s a checklist to make sure you include everything that you want to talk about in your blog post.

Treat your outline like a three act play, with a distinct beginning, middle, and end.

Act 1 is all about introductions - what’s the setting, who are the characters, and what is the main conflict driving the plot? The introduction should tell the reader why they should care about the rest of the blog post, and whether they are the intended audience. This should happen fast with a “hook” in the first paragraph - something so compelling that the reader wants nothing more than to keep reading.

Act 2 fleshes out the the conflict more - what is the problem we’re trying to solve, and how can we solve it? This is usually the largest chunk of the blog post.

Act 3 ties up loose ends and puts a bow on the whole thing. The conclusion of a blog post often reiterates what happened in act 1 and 2, but that’s not required. They frequently include extra materials or references the reader can look at for deeper learning. Don’t overthink this, though. For smaller blog posts especially, a conclusion isn’t even necessary.

Once you’ve got your three acts, use your brain dump to add bullet points underneath each act, fleshing out more specific details. Add as many levels of bullets as you want. I like to make bullets for each of the section headers, and then add a few details that I don’t want to miss. Don’t write too much here, just ideas. Save the writing for the next section.

## (Finally) Start Writing

The time has finally come for you to take your reader on this journey. You have your narrative statement guidepost, your outline map, and hopefully a plan for keeping it entertaining while getting the message across.

Start with the hook to catch attention and keep the reader interested. Share the narrative. Deliver the information. Educate. Whatever you need to do. Keep it conversational. Make every sentence make the reader want to read the next sentence.

There are a [bajillion guides to better writing](https://www.google.com/search?q=tips+for+better+writing), so I'll keep this section brief. My one suggestion: If you want to get better at writing well, read good writing. Here is some of my favorite writing as examples:

* [A Complete Guide to useEffect](https://overreacted.io/a-complete-guide-to-useeffect/) \- Deeply educational, but an excellent narrative keeps it interesting.
* [Building a Magical 3D Button](https://www.joshwcomeau.com/animation/3d-button/) \- A masterclass in hook writing.
* [The State of Being Stuck](https://mathwithbaddrawings.com/2017/09/20/the-state-of-being-stuck/amp/) \- An excellent anecdote, and the pictures add color to the whole piece.
* [Not Your Problem](http://howtomakeanrpg.com/a/not-your-problem.html) \- The prose is dripping with voice - you can hear the intonation of each sentence as you read it.

Also, be sure to finesse your title. Despite pithy sayings, _everyone_ judges a book by its cover and a blog post by its title. Your title is your one shot to get the reader to click. Say what you will about clickbait, but it works. My rule: It doesn’t count as clickbait if the blog behind the click delivers a lot of value.

Finally, only say what you intended to say, and then be done. There’s no need to bore readers by drawing things out.

## Jazz It Up

If you’re a really good writer, your words will speak for themselves. For the rest of us mere mortals, our blog posts likely need _something_ else to keep the reader engaged.

It’s mostly about avoiding walls of text - anything to break things up visually to make the reading experience a little more enjoyable. Here are some suggestions:

* For longer blog posts, split sections with headers. It makes the blog post easier to skim and adds a necessary visual separation between the different sections.
* Take advantage of **formatting!** Underline, **bold**, _italicize,_ emoji _🥳,_ add color - whatever you need to get your point across. Formatting can even be used to tell helplessly dumb really funny jokes.
* Add quotes and asides. If your research found a relevant quote from an expert, throw it in there! If you’ve got extra thoughts that don’t fit with the overall flow or topic but are still interesting, add them in too. See if you can format these to separate them from the rest of the blog post appearance.
* Throw in some visual aids. Pictures, diagrams, graphics, comics. The stick figures in _The State of Being Stuck_ probably took minutes to make, but add an extra dimension of value to the post. [Excalidraw](https://excalidraw.com) is an excellent low-effort tool for creating diagrams.
* If you’re writing about something code-related, include a formatted code block or an embedded CodePen or CodeSandbox. Bonus points if the embed is interactive.

## Draft & Revise

There’s nothing wrong with publishing your first draft - I do it all the time. But I’m _100% confident_ that your _second draft_ will be mounds better than your first.

At a minimum, you’ll catch any grammar and spelling mistakes that might have accidentally crept in. It’s also possible that you’ll think of other, better ways to present the information in your blog post.

The key thing here is time. It’s difficult to be objective about your writing if you dive right into the second draft on the heels of your first. Instead, give it at least a day to settle. Sleep on it, so to speak, and give it a re-read the next day with a clear head.

Also, one of the most powerful revision tools is reading aloud. Yes, aloud. Vocally. A conversational blog post should read aloud naturally. Sections that feel weird in your mouth as you say them are prime candidates for revision.

Finally, try throwing your blog post into an editing tool like [Hemmingway](https://beta.hemingwayapp.com), which tells you how long and how readable your blog post is, and gives specific recommendations for how to improve it. Don’t feel like you have to follow every suggestion, but it can give you ideas for areas to look at.

## Get Reviews

One of the hardest things about writing is getting out of your own head. You have ideas and notions for how things should be written, but all of us have blind spots. That’s why getting others involved is a crucial part of the writing process.

Whether you have a friend who gives your final draft a once-over, or a trusted partner who collaborates with you every step of the way, a reviewer can either point out areas you can improve, or give you the confidence that your blog post is ready to publish.

Remember, you don’t have to follow all of your reviewer’s suggestions. Consider all of them, but remember that ultimately you are the author.

## Publish & Share

The time has come! There are likely a number of finishing touches to throw in - a cover image, SEO keywords, tags, and whatever else you need. But the main attraction is done. Throw it in your CMS of choice, smash “Publish”, and bask in your newfound celebrity!

…but before you do that, do a quick double-check to make sure everything looks good. Often, when pasting into a CMS of some kind, the formatting gets off. A quick check of the published post pays off.

Once the post is live, don’t forget to let people know about what you’ve written. To get the most eyeballs on it, do the full social media tour - Twitter, Facebook, LinkedIn, Reddit, Instagram, Hacker News, Slack, Discord - wherever there are people you think might be interested in your thing, post it. This is not the time for modesty - it’s time to showcase your work to the entire world.

Then sit back and relax. Sometimes people enjoy watching the page view analytics while others don’t. I once had a blog post that had a huge spike in traffic. Come to find out someone had posted it on a social media site and a _ahem_ lively discussion was happening. (Another tip: maybe avoid reading the comments. It’s better for your mental health 😅).

And with this blog post published you can focus your attention on other things. Like writing the next blog post!

## A Note on Procrastination

Let’s take it back to the beginning. You’ve got an idea, you’ve got an inkling of how you want to write it, but you can’t bring yourself to start.

This relates to the physical principle of _momentum_. Objects in motion tend to stay in motion, while objects at rest don’t spontaneously move. Motivation works the same way. Once you get started, you’ll be surprised by how far you go. It’s the starting that’s tough. [This blog post](https://www.deprocrastination.co/blog/3-tricks-to-start-working-despite-not-feeling-like-it) provides some ideas for doing just that.

My recommendation: _write crap_. Write the worst possible words that you can, just to get _something_ on to the page. If you finish your writing session and all that you have is crap, that’s okay. At least you did something. You can try for better words next time.

If even that is too difficult to do, you might need a bit of self-guided emotional therapy.

Take a few moments and think about how you feel about writing your blog post. Sometimes, those feelings block us from recognizing the small, practical steps we can take towards progress. Merely _recognizing_ those feelings can help us break through the block and actually start working.

**My advice to the young writer is likely to be unpalatable in an age of instant successes and meteoric falls. I tell the neophyte: Write a million words–the absolute best you can write, then throw it all away and bravely turn your back on what you have written. At that point, you’re ready to begin. \~ David Eddings**

For me, writing is satisfying in its own right, even if I never publish. But I can see how others might detest the idea of writing. But like many things in life, improving and learning to enjoy an activity comes with practice.

Hopefully you’ll find some of these suggestions and ideas helpful. The most important advice, though: practice. The more you write, the better you’ll get.

Now if you’ll excuse me, I’ve got another blog post to write.

---

[View on echobind.com](https://echobind.com/post/how-to-blog-in-10-doable-steps)

---

# My Journey In Tech

> Why and how I transitioned into Tech (UI/UX design) and what I’ve learned in 10 years.

_By Alex Silcox · 2022-08-11_

I've been in the tech industry for almost 10 years. My path toward becoming an engineer was unconventional from the typical CS path. When I started my journey, I was a college student pursuing graphic design. Prior to that, I had been a henna artist and aspiring artist. My knowledge of coding had been limited growing up, mainly involving CSS to customize my Myspace profile (does that date me a bit?). So while in college, learning to code was an investment to be a better designer, wanting to understand the limitations and possibilities of web technology at the time.

That investment quickly became a passion—I switched my major, spent my free time learning code, helping my peers, and took every opportunity to learn and build. I worked on personal, freelance projects and internships to build my portfolio. Within a couple of years, I found myself in my first full-time development role. Since then I've worked across multiple companies, from small agencies to mid-size corporations of various industries and projects. The last two years have been spent as a Senior Software Engineer at [Echobind](https://echobind.com/), a digital agency dedicated to providing bold, beautiful, and bulletproof web and mobile solutions for our clients.

With this experience, I’ve learned some valuable lessons that not only helped me become a better engineer but also kept me interested in this industry, and put me on a career path I never expected years ago. Here are some of the things I’ve learned over time:

## There is No Linear Path

To start, there’s no linear path toward growth. It’s not as much of a shock or stigma now, but back when I discovered coding as a career path, [boot camps had just started to take root](https://venturebeat.com/2015/11/08/coding-bootcamps-are-replacing-computer-science-degrees/) and I was fortunate to be one of the early adopters of online learning. This path enabled me to become a software engineer and showed me that success didn’t have to be achieved one way. Over time, I’ve only seen the field become more diverse, with many engineers with non-traditional backgrounds who are changing the development landscape. Like my own path, seeing the success of others has continued to shape my thinking that embracing unconventional can sometimes lead to the best opportunities toward growth and success, and we want to foster that the best we can.

## Stay curious and ask questions

There is no amount of experience to negate the need to ask questions. In fact, asking questions is often the best channel for communication and learning, whether it’s how a feature or a piece of code works, or how another developer would approach a problem. Even as a senior engineer, I’m often curious about how others solve problems or implement code because there is always something new to learn or better approaches than my own, and a significant resource to learn is those around you. There are countless examples I’ve come across in my career, but one that comes to mind was when first learning about using object literal lookups instead of switch statements. This was all because of asking a coworker how they would approach returning from functions based on a value with many possibilities. It was a game changer for me and really reinforced how important asking others can be because the best ideas often come from others. There’s a time and place, but you’re only limiting yourself and your growth if you think you have to solve it all.

## Know your audience

At some point in your career, you’ll realize the importance of communicating to different audiences—beyond the diagrams and tech jargon. At one of my previous jobs, I worked closely with our UX designer prototyping a sharing feature for a healthcare mobile app. Alongside them, we discussed the flow of authorization to allow a user to share their information with other users. At one point, they had a bewildered look on their face trying to understand what it would take to implement this, in both design and code. The UX lead stopped us and asked us to explain this in another way. Knowing they were lost, we restarted the conversation by finding the right way to help bridge the gap.

One of the engineers in this scenario kept trying to bridge the gap with more tech jargon and traditional whiteboarding. But it was only causing more confusion. Realizing this person was a visual person and needed a relatable example, we switched gears. In this case, we found an analogy (ironically Starwars) that ended up working perfectly to explain the transactions that needed to take place for our sharing service to work. We cemented it further by sketching this transaction on the whiteboard. It may have not been a perfect example, but it was enough to get the point across. The point of the story is, that sometimes flowcharts or tech terms are not enough, and you will need the right soft skills to play to your audience.

## Code for your future self and others

![https://i.redd.it/hwqj7yx9vm211.jpg](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/bojl48tlgvgnoyqpnqxj.jpg)

It’s bound to happen in your career (more often than you’d like) that you’ll run into code that is cryptic or overly complicated with no documentation of what it’s doing and the steps to get there. Often times code was written this way out of laziness, to appear intelligent or to try to solve it all with little attention to future-proofing. Without proper documentation, likely those who work on it will struggle to understand what or why it was implemented, or the learning curve will be too steep without the original author to explain. This will lead to headaches and complications. So do yourself and others a favor, and code for readability with:

* Reusable code, but when it makes sense the most sense. Avoid overly generic functions that leave the question of what are we getting or expecting. **Each function or variable name should represent the result of the code or the value it holds**.
* Break code down into digestible pieces. If your functions are handling multiple tasks, ask yourself if it’s possible to break it down so that it’s easier to understand.
* Code with a natural flow in mind. If the code seems like magic or isn’t clear how things are interacting, it is an enemy, not a friend.
* Leave the code in a better place. If you run into code that could be optimized, do so if you have the time.
* Write comments when needed. While function/variable naming should be sufficient to describe what should be expected, comments will still help to describe the inner workings of a function. Documenting what the function does can provide better context for a named function or variable, especially if there is insider knowledge to some handlings within the function.
* Write for diversity. Everyone has different learning styles, if you can try to approach your code and your PRs with this mindset, it will be beneficial to your team.

## Fighting burnout, knowing your limits, and learning to honor your boundaries.

It’s possible that at some point in your career you’ll experience fatigue or [developer burnout](https://revelo.io/blog/software-engineer-remote-burnout). Coding is taxing on the brain, but there are so many external factors that can cause a breaking point if not mitigated or managed. I’ve suffered through bouts of burnout multiple times in my career during various projects, teams, etc. Even in my engineering role at Echobind, I’ve experienced burnout on client projects I’ve worked on as I’ve lost interest in the things that use to motivate me. As someone who has lived through seasons of anxiety and depression, I’ve become practiced to recognize and prioritize fighting burnout.

It’s important to recognize when it happens, know and honor your limits, and proactively make changes or seek resources to help reduce or eliminate the burn. Some changes can include:

* Prioritize physical and mental boundaries
* Seek out things you do care about inside and outside work
* Surround yourself with those who inspire and have your back
* Be transparent about needs and seek help
* Find opportunities to have fun, be creative, and give back
* Prioritize rest, vacations, and even breaks

While there is a very valid nuclear option (aka quitting your job), it’s best to analyze if there’s no other recourse before seeking this one out. Developer burnout is nothing to be ashamed of, and there are resources and communities out there to help you prevent, fight, and thrive.

## Lastly, pursue your purpose and find opportunities that will support it

I’ll be honest, I have struggled with my path as an engineer over time. When I first started my career, I was very passionate about learning, building, and creating. It fulfilled many aspects of the things I craved and found fulfillment in. I have worked on many projects and with some fun technologies. Over time I found my motivations for being an engineer shifted, and I began to question if this was still the right path for me. Turns out it is, but I had to make a change to support the things I cared about—mentorship, community, and supporting others toward their success.

It’s incredibly important to find and foster the things that really matter to you to continue in this (and any) industry, and be okay acknowledging when those things have changed. If you’re struggling to find fulfillment in your work, take the time to start asking yourself what really matters to you, what opportunities (whether at your company or community) are available to support them, and what’s holding you back from pursuing them. Sometimes this will lead to a direct shift in your career, sometimes it will lead to fostering it elsewhere. Regardless of how it directs you, you will need to be ready to embrace it when it happens because it may be the best thing you can do for yourself (and others).

---

[View on echobind.com](https://echobind.com/post/my-journey-in-tech)

---

# Bison Release 1.12.0

> We're excited to ship another version of Bison that not only improves the web apps we build for our clients, but also the developer experience of working on Bison apps.

_By Kishan Gajera · 2022-08-09_

We're excited to ship another version of [Bison](https://github.com/echobind/bisonapp) that not only improves the web apps we build for our clients, but also the developer experience of working on Bison apps.

Not familiar with Bison? It's [Echobind's](https://echobind.com/) starter repository for full-stack Next.js web apps. Check out the links below for more background on Bison and how to use it:

* [Overview of Bison](https://vimeo.com/447643624)
* [Creating Your Own JAMStack Blog in No Time with Next.js and Bison](https://blog.echobind.com/creating-your-own-jamstack-blog-in-no-time-with-next-js-and-bison-a3cdd507fd61)

## Upgrade to Next.js 12 and React 18

As always, there are so many improvements introduced with each version of [Next.js](https://nextjs.org/), and we’re excited to upgrade to the [latest version](https://nextjs.org/blog/next-12). In particular, we’ve been taking advantage of the new [middleware](https://nextjs.org/docs/advanced-features/middleware) feature to protect pages and API routes.

This year, we are also looking into more ways to utilize React 18 features such as [server components](https://nextjs.org/docs/advanced-features/react-18/server-components) and [streaming rendering](https://nextjs.org/docs/advanced-features/react-18/streaming) to improve performance for client-side interactivity.

In order to upgrade to React 18, this also required an upgrade to [Chakra](https://chakra-ui.com/) 2.0, so be sure to follow their [migration guide](https://chakra-ui.com/guides/migration) if you’re upgrading an older Bison app.

## Prisma

Upgrading to the latest Prisma also provides many new features. One to highlight is how we are handling running seed scripts. We’ve introduced a new pattern for seeding development and production environments using two scripts, yarn db:seed and db:seed:prod respectively. Refer to our [documentation](https://github.com/echobind/bisonapp/blob/canary/packages/create-bison-app/template/prisma/SeedsAndScripts.md) to see how to organize your seed data and scripts.

## TypeScript

We've upgraded Bison to use the latest version of TypeScript, [4.6.](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-6.html) In addition to that, we've also enabled the [strict compiler option](https://www.typescriptlang.org/tsconfig#noImplicitAny) and refactored the codebase to be even more strongly typed. This will help to enforce best practices to ensure all variables are typed which results in a more maintainable codebase.

### Path Aliases

We’ve introduced the following path alias that will allow us to have cleaner imports by avoiding the use of relative imports:

```jsx
"paths": {
  "@/*": ["./*"]
},

```

We’ve refactored all relative imports in the template to use this new alias, here’s one example:

```jsx
// Using relative import
import { prisma } from '../../lib/prisma';

// Using path alias import
import { prisma } from '@/lib/prisma';

```

## ESLint

Our [eslint-plugin-echobind](https://github.com/echobind/eslint-plugin-echobind) has been upgraded to use ESLint 8\. In addition to this, we also found and fixed a loophole in our CI that was allowing lint errors into the repository.

## Windows

We’ve fixed a long-standing [issue](https://github.com/echobind/bisonapp/issues/127) that prevented creating a new Bison app on Windows. With many more improvements planned for our CLI, we’ve updated our CI to run our CLI tests on Windows to ensure all features work on Windows going forward.

## Contributing to the Bison Template

Check out our [contributing guide](https://github.com/echobind/bisonapp/blob/canary/CONTRIBUTING.md) for more information on how you can help out. Whether it's reporting bugs, creating pull requests, or participating in discussions, all contributions are welcome!

---

[View on echobind.com](https://echobind.com/post/bison-release-1-12-0)

---

# Benefits of Implementing TypeScript Early

> When you’re getting started on a new project, does it make sense to start off using TypeScript or to implement it later when it becomes more of a must-have? Let’s dive into when and why it’s better to start early.

_By Mariah Grey · 2022-06-30_

When you’re getting started on a new project, does it make sense to start off using TypeScript or to implement it later when it becomes more of a must-have? Let’s dive into when and why it’s better to start early. 

### **Find errors earlier, with fewer bugs**

When you develop an application in JavaScript, your flow might look like this:

1. Make a change
2. Go to the app and check the changed part and run the affected tests.
3. Find out if anything broke.

With TypeScript, you can make the change and immediately be alerted by a compiler error message or IDE real-time feedback to any type errors. Of course, the TypeScript compiler won't resolve every problem and won't warn you about all bugs, but it helps speed things up.

The type information is also checked by the TypeScript compiler. The compiler will tell you when your code is not type-safe. It’s the classic benefit that type checking brings: _Catching bugs earlier in the development process_. You will catch and fix bugs during development instead of your customers finding them when your app is in production. The TypeScript compiler has a strict option that enables stronger type checking. With the strict option enabled, it can flag more potential problems.

It’s best to not use the strict mode when migrating an existing JS project to use TypeScript. In a TypeScript migration project, starting with the strict checks disabled makes it possible for you to have the build passing and the program running with less effort. If you enable the strict checks, you’ll need to do more significant refactoring such as defining the types to make the compiler happy.

It should be noted that this industry is using several techniques to catch bugs. Typescript and its static type checking are only one of these techniques. Some of the other recommended practices include Test Driven Development (TDD), pair programming, code reviews, design reviews, and linting.

If you are using TDD and code reviews, you are likely already efficient in finding bugs early. In this case, adding TypeScript will not have as significant of an impact on improving quality. You should consider your situation and try to determine whether the benefits of TypeScript will outweigh the costs of implementation.

### Achieve b**etter syntax completion in IDEs**

If you are using an IDE like VSCode, you will get better syntax completion with TypeScript. Maybe it doesn't sound like a huge developer experience bump, but each little improvement potentially saves you time. Another plus: when you can define the type or interface once and not have to constantly remember the structure, you can focus on writing better business logic.

### R**efactor more easily from JavaScript**

Imagine you’ve joined a project and have the task of adding a new feature, but that feature is connected with legacy code. TypeScript will help by alerting you when you’ve made a change and need to update the same piece somewhere else within the file.

Valid JavaScript code is _also_ valid TypeScript code, so you can migrate your codebase file by file. Usually, using strict mode in TypeScript is good practice but in this case, you’d start with false to prevent hundreds of compilation errors. Once all the files have been updated to use TypeScript, setting strict mode to true will give you a standard to stick with. 

Begin by setting a few configurations inside the `tsconfig.json` file:

```jsx
`"strict": false,` 

`"allowJs": true, // will allow using .js files without checking the type 
"skipLibCheck": true // will skip checking types in used libraries`

```

With those options, you can migrate from JS to TS file by file, simply changing the extension from `.js(x)` to `.ts(x)`, adding types in the files, and fixing any errors that pop up along the way.

### Feel c**onfident about the codebase**

JavaScript is weakly and dynamically typed, so when you initialize a variable with the value `let query = ''`, you may later do something by mistake, such as `query = true`, and it will be valid JS code.

When using TypeScript, you can't change the type of the variable, so if you make the `let query = ''` variable, it will be `string` type and you won't be able to change its type by mistake. If you want to let a variable be more than one type, you always do it explicitly using union type, for example, `string | number`. TypeScript makes your code predictable and explicit. 

### **Work as a team**

JavaScript is adequate when working alone, but it’s sub-optimal for teams.

It’s suitable for quick development. When working solo, It doesn’t matter if the code is hard to understand for others, as long as it makes sense to you. Most likely, you can understand it well enough to maintain it on your own.

JavaScript allows for rapid development partly because it does not require any types or interfaces to be written. You are not “wasting” any time in writing this typing.

I recently started working on a huge JavaScript codebase that had been authored by one developer over several years. My task was to implement a small enhancement, but I was unable to do it in a straightforward or easy-to-implement way because it was too hard for me to understand what was going on in the code.

The original developer was able to still make changes to it, but for me, the code did not make sense. The coding style, or the lack of it, made it impossible for me to understand.

Type declarations are part of what makes the code easier to understand. You can immediately see from the type declarations what data the function takes in. Interfaces describe the structure and typing for all complex parameters. There is no need to inspect the calling code, the function implementation, or the unit tests, to figure out what fields these complex objects are composed of.

A shared understanding of the code becomes _vital_ when you are working as a team. Added type information brings better understanding.

### **Typing**

As mentioned on its official website, **TypeScript is JavaScript with added Type annotation**. Now, the question may arise whether a statically typed language is better than a dynamically typed language. The answer is: it depends. Because of its type system, TypeScript has the following advantages over JavaScript:

* It is easier to understand
* It is faster to implement using modern IDEs
* It is quicker to refactor
* It gives better performance

### Language D**esign**

There are many other typed JavaScript languages. What makes TypeScript unique is the language design. Anders Hejlsberg is a veteran programming language designer who has previously developed programming languages like Delphi, Turbo Pascal, and C#. He used those experiences to design TypeScript as a clean, elegant programming language.

Most of the other programming languages first design their type system and then use it. But TypeScript designers first looked at the JavaScript use cases and later developed the type system so that it retrofits the JavaScript use cases. Also, unlike the C-family languages, which use nominal types, TypeScript uses structural types. Structural types are a way of relating types based solely on their members, unlike nominal types which say that two variables are type-compatible if and only if their declarations name the same type.

TypeScript uses some of the most advanced type systems like [Union Types, Intersection Types, Differentiating Types, Nullable Types, Conditional Types, and Type Inference.](https://www.typescriptlang.org/) 

In terms of language design, it is comparable to other modern languages like Kotlin, Go, or Rust.

### D**evelopment Scaling**

Due to its type system, elegant language design, and IDE support, TypeScript will lead to better development scaling compared to JavaScript in a large project. It is no wonder that the official slogan of TypeScript is: “**JavaScript that Scales.”** As development scaling is a significant factor in today’s software development industry, an increasingly large number of corporations and large open-source projects are using TypeScript.

### **Developers Love It**

The TypeScript team at Microsoft has done an excellent job designing TypeScript as a pragmatic modern programming language. Their hard work is vindicated as the software development community loves TypeScript. 

A language can have excellent features, but it does not mean that the language will be popular. Also, some languages gain popularity (like Scala and CoffeeScript) but quickly fade away.

Fortunately for TypeScript, it is already a trendy language. According to the GitHub Contributions, TypeScript has entered the Top 10 List (ranked 7th) and is one of the fastest-growing languages. It ranked fifth with a 161% increase in adoption last year. With almost 12 million downloads every week, it is one of the fastest adopted technologies within the JavaScript landscape.

### **Open Source**

Microsoft first created TypeScript in 2014\. As Google was also planning to develop a similar typed JavaScript at that time, Microsoft and Google collaborated together to bring you TypeScript. It is also open-source with a very permissive Apache 2.0 license. Currently, TypeScript is supported by many other large corporations and software development communities. The following JavaScript frameworks have either implemented or plan to implement TypeScript:

* Angular
* Vue
* Ember
* Svelte

With its enterprise-friendly features, which are very valuable in writing and maintaining a large code-base, more and more large companies are turning to TypeScript.

### **Superset Of JavaScript**

Another killer feature of TypeScript is that it is typed JavaScript with some extra features which are not yet in JavaScript but may come in the future.

When TypeScript first added Class and Module support, JavaScript did not have them. Once JavaScript incorporated them, TypeScript aligned itself with JavaScript. TypeScript looks at the ECMAScript **[specification](https://www.ecma-international.org/publications/standards/Ecma-262.htm),** and **[TC39 committee](https://github.com/tc39)** and implements Proposal, Draft, or Candidate features ahead of JavaScript. Most of the time, JavaScript ends up implementing the same features. For example, here are some TypeScript features that are not yet in JavaScript:

* Optional Chaining
* Nullish Coalescing
* Enum Type
* ECMAScript Private Fields
* Top-Level await

With a three-month release cycle, TypeScript can add proposed ECMAScript features much faster than official JavaScript does.

### When don’t you want to implement TypeScript?

There are times you won’t want everything that TypeScript has to offer - for a simple landing page where JavaScript is only used for toggling class or another simple case, TypeScript isn’t worth implementing. Also, you have to remember that to take full advantage of TypeScript, you have to learn to use it on a sufficient level, and it can take some time. Other reasons include:

* Quick prototypes are easy to develop with JavaScript
* Single-use scripts (migration scripts etc.) are an excellent fit to be done with JavaScript

JavaScript has the following advantages over TypeScript for its dynamic type:

* No additional compiling step
* Concise and succinct code
* No need to learn the “extra” type system
* Easier to write higher-level abstraction without a type system

TypeScript does not come for free. There is some cost associated with using it:

* It takes effort to write type annotations and maintain them
* Type annotations add clutter to the code base

### Conclusion

In the end, it comes down to your project and the amount of time and effort needed, and your team will have to weigh the pros and cons of implementation. If you decide to add TypeScript to your project, the benefits will appear quickly, from better code completion to bug prevention, and it will improve your teams’ lives when it comes to their code.

---

[View on echobind.com](https://echobind.com/post/benefits-of-implementing-typescript-early)

---

# Spring Peaks at Echobind

> After a two-year hiatus from our Annual Summit tradition, we planned spring peaks across the country to bring our fully remote team together.

_By Krystalyn Bauer · 2022-06-08_

Here at Echobind, we are a fully remote, nationally distributed team. We can be found in the four corners of the US and anywhere in between. One of our most beloved perks is our Annual Summit where we get our team together IRL to do something fun, somewhere awesome. After a two-year hiatus from our Annual Summit tradition, we wanted to make up for lost time but our Annual Summit isn't scheduled until later this year.

Queue: Spring Peaks.

Spring Peaks are our newly exercised regional meetups. Our first Spring Peak took place in sunny San Diego in the beautiful area of Encinitas. A short day of coworking, _office donuts required_, followed by tacos near the beach was the perfect start for many of us to meet each other for the first time in person. Our first Spring Peak was full of incredible views, great food, and lots of laughs.

![Team dinner](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/pwzil1cdamwgyvsbvgm7.jpg)

![Plate with steak, carrot, and potatoes](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/x5thugmsc6gsiap9ov4b.jpg)

![Sunset with palm trees](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/xcxx2h6i1t9qzb8hkv9e.jpg)

![Company photo](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/ztl6ytxozwajtwfvg2nw.jpg)

For our next Spring Peak, we moved up to the Pacific Northwest where our crew met for a little coworking and a little friendly competition at Top Golf. Our team was able to meet one of our newest Echobind Babies and also enjoyed great food, and lots of laughs.

![Woman smiling and man holding baby](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/now2mbjnpzn3j3riyelh.jpg)

![Chicken and waffles on a plate](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/b88vuppfggktifwsz4su.jpg)

![Women playing golf](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/lfhd0cgbtkcwzzv1ciau.jpg)

Next we flew south to the Sunshine State where our team gathered at [React Miami](https://www.reactmiami.com/) for some conference fun and learning, great food, and lots of laughs. (Are you sensing the theme here?)

![Company photo at dinner](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/hh8luaryztlpeyckcf3x.jpg)

![Two women holding signs at React Miami](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/h3sh6fnrzcdlpn7yr7ul.jpg)

![Company photo at lunch](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/ujcqqmfdmzvueprkhvbw.jpg)

![Table with seafood dinner](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/bt9ins3jbj5vvqqz5eqg.jpg)

We kept the coastal theme going and headed to Brooklyn, NY. The first stop was obviously for bagels & lox, and then continued our theme of coworking, great food and lots of laughs. The view of the city from Harriet's Rooftop Bar did not disappoint!

![Board with a bagel, lox, and cream cheese](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/ciopoteyqrs08pgz3ziw.jpg)

![Men standing on New York roof top](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/wkr4lkkqhuonhcw6ophh.jpg)

![Women smile in front of water in New York](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/wkinawwyl5vuyjfpgjdl.jpg)

![Company photo at dinner](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/dyqha3xmrr3kminbxyne.jpg)

Venturing back down south, but inland this time, a group of our engineering team went to [RenderATL](https://www.renderatl.com/) for fried chicken, hip hop music, and all things software engineering. The food, laughs and great company continued.

![Company photo at Render ATL](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/odqhdxmnglsfu6yfbecy.jpg)

![Hand holding food](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/ulaywvukqm4rymqdkh4w.jpg)

![Echobind logo on DJ booth](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/y8xeamc53ge7kcwpivjw.jpg)

![Company photo with swag](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/hbvpxkmyiv4ccbh4zdfn.jpg)

We are stoked to plan our last, but not least, Spring(ish) Peak in KY before we all get together for our annual summit this fall. If things go as planned and stay on theme, this Peak may need its own blog post!

![Map of the United States](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/ylflscaupc2o3y6bvlqj.jpg)

Our get-togethers are invaluable for our company and culture, and help strengthen connections so that our team can continue to thrive. Having a little fun never hurts, either.

---

[View on echobind.com](https://echobind.com/post/spring-peaks-at-echobind)

---

# Custom React Hook Guide: Build a Kanye Quote app with React Native

> Let's reveal the closely held secrets around creating custom React Hooks with React with a lyrical twist.

_By Mickey Martinez · 2022-05-19_

Today’s objective is to reveal the closely held secrets around creating **custom** **React Hooks** with **React.** Only a chosen few have been gifted this knowledge, so if you’re ready to elevate your game ride with me to the finish line. 

We’ll accomplish this with the help of Mr. West, the Yeezus of knowledge, by building a **React Native app** that hits a **public Kanye Quotes API** and returns data through a **custom React Hook**. Specifically, we’ll leverage the **`useEffect`** and **`useState`** Hooks, two of the most commonly used hooks in the [React Hooks API](https://reactjs.org/docs/hooks-reference.html). 

> _Hooks are functions that let you “hook into” React state and lifecycle features from function components. Hooks don’t work inside classes — they let you use React without classes._

If you’re new to React, the cool thing is that **Hooks** are the _**exact same**_ in **React Native** and **React.js**. With Hooks, we no longer need to write **class components** to manage state or query data — eliminating pesky lifecycle method bugs like `componentDidMount`, `componentDidUpdate` and `componentWillUnmount`. Instead this guide will pair **functional components** with **React Hooks**, demonstrating how to reuse stateful logic and manage side effects across components.

Since the concepts of Hooks are platform agnostic, I’ve chosen to crank out a fully functional RN mobile app — focusing on `iOS`. 

Enough of the abstract talk, **buckle up cuz we about to [ball so hard](https://www.youtube.com/watch?v=gG%5FdA32oH44&t=30s) .. ya you know the rest!**

![Kanye West driving with Jay-Z](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/bduptucglrshgw7nu6qc.gif)

## Getting started

### API

The API will be serving up a mix of certified Kanye West quotes, and I’ll be sharing a few of my favorite verses too. By the end you’ll have gone from College Dropout to the Graduation 🚀🐻. 

🎵”_Ain't nobody expect Kanye to end up on top_  
_They expected that College Dropout to drop and then flop”_ \- [\*Last Call](https://www.youtube.com/watch?v=cpbeS15sHZ0), The College Dropout\*

Visiting the **[Kanye West API](https://api.kanye.rest/)** in your browser, you’ll see it returns a very simple JSON response of a randomized Kanye quote. Refresh and a new quote is displayed. Many times APIs will return a much larger JSON response, for example also including the album name, song title, release date, etc. For today, a simpler response will allow us to practice mastering the craft.

![Kanye West API screenshot](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/hoxk2bxgjhgj2hfac8pn.png)

Viewing a quote from the Kanye West API endpoint in browser

### React Native `Expo` Build

I’ll be going with the **Expo CLI Quickstart** option to create a new React Native project.

💡**Tip:** If you’re new to React Native, check out the **[Setting up the dev environment](https://reactnative.dev/docs/environment-setup)** docs. I recommend beginners **starting with the Expo CLI route** vs. React Native CLI.

![React Native guide screen](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/fltultni8pergdz2c1qv.png)

**Open your terminal** of choice, make sure Node is installed, and then **install the Expo CLI command line utility tool** using `npm` or `yarn`.

With Expo CLI installed, **create a new React Native project** named **`KanyeQuoteApp`** by running the following commands in your terminal:

```bash
# Creates project named KanyeQuoteApp
expo init KanyeQuoteApp

```

![Expo code running in terminal](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/omt2of5mpotpemhmkemc.png)

**Choose the** `blank` **template** and hit `enter`. _Expo will do the rest from here!_

![Expo code running in terminal](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/y01vzznztuuudo54wphd.png)

Now **switch into** the `KanyeQuoteApp` directory, **open VS Code**, and **start the development server**:

```bash
# Navigate to project directory
cd KanyeQuoteApp
# Open project in VS Code 
code .
# Start server. Equivalent to: expo start 
yarn start 

```

![App.js file in Visual Studio Code](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/jld4sf4i7akicie2ilno.png)

Viewing the default KanyeQuoteApp project in VS Code

Since React Native projects are for mobile devices, you’ll need to **open an iOS simulator.** _If you develop on Android, launch an emulator with Android Studio_. To **open an iOS simulator** with Expo Go, **press `i` in the terminal**, or use the dev tools in the browser and click `Run on iOS simulator`.

![Expo options in terminal](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/w7jozzmvqbg9bvhcejpu.png)

Expo Go CLI tools in terminal

💡**Tip**: _Make sure Xcode and Expo Go are installed. View the Expo docs on setting up [iOS simulator](https://docs.expo.dev/workflow/ios-simulator/) and [Expo Go](https://docs.expo.dev/get-started/installation/#2-expo-go-app-for-ios-and) app._

![Sample app on iPhone](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/kh3m4aptwlidpdhcuf5o.png)

Default iOS app on iPhone 12

Once launched, the default iOS app will look similar to the image above. A blank white canvas for us to go full Pablo Picasso on. So let’s **pop in the _Kanye West [Get Right for the Summer](https://www.youtube.com/watch?v=ylT16QB6Uig&t=47s)_ _workout tape_**, and really **switch the style up!**

![Kanye dancing gif](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/fx4mshsvkgkrtkjbhwpw.gif)

**Grab the stylized template** from my [GitHub repo](https://github.com/CrypticMick/kanye-quotes-app-rn/blob/b877baf5f697f7aee83191878b16226b663042fc/App.js), **replace everything** in `App.js` and **Save.** _Expo Go should automatically reload the app whenever a file is changed._ If not, try `command + r` on device, or `r` in terminal. [Commit 1](https://github.com/CrypticMick/kanye-quotes-app-rn/commit/b877baf5f697f7aee83191878b16226b663042fc)

![Kanye West Quotes app home screen](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/jilg5oxg1xzxxeskbijg.png)

Updated app with stylized template

**Ayyy** that looks like the vibe I’m going for, now it feels like _we on an_ _[ultralight beam](https://www.youtube.com/watch?v=6oHdAA3AqnE)!_

## Building out the `useEffect`

With styling complete, **let’s focus on getting the `useEffect` Hook built out** and functional in `App.js`. Once it’s working as intended, we’ll then move that hook to its own file where it will be remixed into a custom hook — therefore _**accessible**_ and _**reusable**_ by our entire app. 

In `App.js` **import** `useEffect` from React:

```jsx
import React, { useEffect } from "react";

```

Now **add an empty** `useEffect()` above the `return` block:

![Code in VS Code](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/betykqhfnefwuuu5mcqk.png)

The `useEffect` hook takes a **callback** **function** as it’s first argument, and an **_optional_ dependency array** as the second argument. 

```jsx
useEffect( callback, dependency ) // dependency is an array

```

In our case, we’re starting with no dependencies, so your gut may be saying “we don’t need the optional dependency array.” While true, excluding the dependency array causes the effect to run with _**every render**,_ potentially creating unforeseen performance issues like an infinite loop\*.\* By adding an **empty [dependency array](https://reactjs.org/docs/hooks-effect.html#tip-optimizing-performance-by-skipping-effects) `[]`**, we’re letting React know to run this effect _**only**_ _**when**_ the component **mounts** and **unmounts**. 

Within the callback function, **create an async function** named `fetchKanyeQuote` that **awaits** the response data from a `fetch` call to the Kanye API. More details on `async`/`await` [here](https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Asynchronous/Async%5Fawait). Be careful to not make the callback function itself async, as that will cause issues with data calls being out of sync. Instead target your inner functions within the effect’s callback. 

```jsx
useEffect(() => {
  const fetchKanyeQuote = async () => {
    await fetch("https://api.kanye.rest/");
  };
}, []);

```

Previously, we’d opt to **chain together a few Promises** — [promise chaining](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Using%5Fpromises#chaining) — to make use of the API data. You can take a look at that [approach here](https://github.com/CrypticMick/kanye-quotes-app/commit/6e30b4a87234793f7f4d2e308111ad4f40aed3f5). 

A **more modern approach** is to use `try/catch` blocks instead, assigning the responses to variables we can easily reuse. Below, `fetch()`returns a promise containing a JSON response that is assigned to the `res`var. Then, using the `json()`method we can pass that along as a JavaScript object that’s assigned to the `data`var. Check it out below:

```jsx
// useEffect with a modern try/catch block
useEffect(() => {
  const fetchKanyeQuote = async () => {
    try {
      const res = await fetch("https://api.kanye.rest/");
      const data = await res.json();

      console.log(data);
    } catch (error) {
      console.error(error);
    }
  };

  fetchKanyeQuote();
}, []);

// Promise chaining approach for comparison
useEffect(() => {
    const fetchKanyeQuote = async () =>
      await fetch("https://api.kanye.rest/")
        .then((res) => res.json())
        .then((data) => {
          console.log(data);
        })
        .catch((error) => {
          console.error(error);
        });

    fetchKanyeQuote();
  }, []);

```

To **confirm the Promise was successful**, you can `console.log` the `data` var and see the structure of the response. _Remember to call the `fetchKanyeQuote()`function at the end of the useEffect as seen above._

![JSON object](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/tpayouvc2kgcmkoz4i9v.png)

**In the terminal** we should see the simple structure of the `data` object: A `quote` property that has a radomized Kanye quote. To **access and display the quote**, we’ll need to tap into `data.quote` but first we need a way to save this quote in memory. [Commit 2](https://github.com/CrypticMick/kanye-quotes-app-rn/commit/869fc79f0a72397b3109a8dc8760af3c812678fa) 

🎵”_How you say broke in Spanish? Me, no hablo”_ \- [Dark Fantasy](https://www.youtube.com/watch?v=UTH1VNHLjng), M.B.D.T.F

## Store Data Response in State (`useState`)

So how do we store this quote (`data`) in memory — state in React — _and display it on screen?_

![Kanye West gif](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/geq06trvgsqkau14pdte.gif)

Well Sway, this is where the `useState` hook shines _bright like a [diamond](https://www.youtube.com/watch?v=rYuLutMe81k)_ 💎💎

**Import** `useState` from React and then we need to initialize state before the `useEffect`. The standard `useState` hook is structured like so: 

```jsx
const [stateVar, setStateVar] = useState(initialState);

```

In our case, the `initialState` of the `stateVar` variable should be set to an **empty string** `""`. Then we’ll use the **setter function** `setStateVar` to update the `initialState` value with an actual quote from the API. 

💡**Tip:** With the `useState` hook, you never want to alter `stateVar` directly, instead always use the setter function. Doing so will not trigger a re-render. 

Since we can name `stateVar` anything we’d like, let’s go with `quote`. And `setStateVar` will be `setQuote`.

```jsx
// Assigning initial value of quote var to an empty string
const [quote, setQuote] = useState("")

```

Now **we can replace** `console.log(data)` with our **setter function** `setQuote(data.quote)`. This is the proper way to update the `quote` variable when using the `useState` hook. 

```jsx
import React, { useEffect, useState } from "react";

export default function App() {
    const [quote, setQuote] = useState("") // useState structure

useEffect(() => {
  const fetchKanyeQuote = async () => {
    try {
      const res = await fetch("https://api.kanye.rest/");
      const data = await res.json();

      setQuote(data.quote); // setter function updates initialState value
    } catch (error) {
      console.error(error);
    }
  };

  fetchKanyeQuote();
}, []);

```

At this point, we’ve made an async call to the API requesting a Kanye West quote and awaited the response. We then converted that to an object, and passed that value to our setter function which **updates** the `quote` var. Only thing left to do is **display the quote on device**. 

In the `return` block, within the `<Text>` component **replace the hard coded text** “_I Love You Like Kanye Loves Kanye”_ **with the** `quote` **variable** and **Save**. _The `quote` variable needs to be wrapped in curly braces `{}`._

![Kanye West quote app next to Visual Studio code](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/xwnezikyk2tc2isdxox6.png)

Updating hard coded text to display an actual Kanye quote from the API via useState

_[Lamborghini Mercy](https://www.youtube.com/watch?v=7Dqgr0wNyPo)_, your device should now be lookin’ fly to death and serving up fresh snippets of Ye. 

🎵“_Let the suicide doors up_ 
_I threw suicides on the tour bus_ 
_I threw suicides on the private jet_ 
_You know what that mean, I'm fly to death”_ \- [Mercy](https://www.youtube.com/watch?v=7Dqgr0wNyPo), Good Music - Cruel Summer

![Kanye West gif](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/rv9ytwygwln8xzhtowzn.gif)

This confirms both of our hooks are doing exactly what we want, fetching data and storing that data in state. 

For the moment, to fetch a new quote you’ll need to reload the app by pressing `r` the terminal. As a bonus I’ll eventually make the `More Kanye` button functional, so that it’ll fetch a new quote when pressed. 

Don’t _[runaway](https://www.youtube.com/watch?v=EMnQwBTJnMM)_ now, we’re on to the good part! [Commit 3](https://github.com/CrypticMick/kanye-quotes-app-rn/commit/286a46aa4d559816e4191dff44272da0ececa2b5)]

## Custom Hook 🪝

Here’s where we take our working logic and **remix it into a custom hook**.

![Kanye West gif](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/mpmxdqloqwnsastmqd0r.gif)

> A custom Hook is a JavaScript function whose name starts with ”**use**” and that may call other Hooks

**Create a new file** named `useRandomQuote.js` — the file naming here intentionally starts with `use` to signify that it’s custom hook. 

Scaffold out a **functional component named** `useRandomQuote` and **import** `useEffect` and `useState`:

```jsx
// useRandomQuote.js
import { useEffect, useState } from "react";

const useRandomQuote = () => {

};

export default useRandomQuote;

```

**Reopen** `App.js` and cut out **the entire** `useEffect` block, as well as the line of code we need to manage state `[quote, setQuote]`. **Paste** this block of code within the **body** of the `useRandomQuote` function.

![Code running in Visual Studio Code](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/cslvyikiv8y4ackdkonc.gif)

Be sure to **return the** `quote` **variable within useRandomQuote** so that we can make its present value available wherever the custom hook is used.

```jsx
// useRandomQuote.js
import { useEffect, useState } from "react";

const useRandomQuote = () => {
  const [quote, setQuote] = useState(""); // useState structure

  useEffect(() => {
    const fetchKanyeQuote = async () => {
      try {
        const res = await fetch("https://api.kanye.rest/");
        const data = await res.json();

        setQuote(data.quote); // setter function to update initial state val
      } catch (error) {
        console.error(error);
      }
    };

    fetchKanyeQuote();
  }, []);

  return quote; // remember to add this line
};

export default useRandomQuote;

```

**Reopen** `App.js`, **import the custom hook**, and assign it to a variable named `kanyeQuote`. 

```jsx
import useRandomQuote from "./useRandomQuote";

```

![File in Visual Studio Code](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/wumax11z6ux8fkwencqa.png)

Assigning the custom hook to kanyeQuote var

Finally, **update the variable** from `quote` to `kanyeQuote` and **Save**. If a new quote renders like before, you’ve **successfully implemented a working custom hook**! [Commit 4](https://github.com/CrypticMick/kanye-quotes-app-rn/commit/2ff31d2b35157771eee88a265699368958819c51)

💡 _If the quote is blank, double check that you returned the_ `quote` _variable within_ `useRandomQuote()`.

![Kanye West quote app next to Visual Studio Code](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/xwmbawd4r3xqdh3zyrko.gif)

Using our custom hook to display a new Kanye quote

That’s all it takes to share logic between components with React Hooks. As your app grows, the custom hook can be used again and again! 

We’ve covered how a `useEffect` helps us grab API data, store that data locally with `useState`, and then house all that logic in a custom hook. I hope **you’re feeling like a _[Monster](https://www.youtube.com/watch?v=pS6HRKZQLFA)_** at this point! I know _[I’m definitely in my zone](https://www.youtube.com/watch?v=gG%5FdA32oH44)_. 

Beyond custom hooks knowledge, you also have a modern React Native build — for some of you a first! \[[Completed project](https://github.com/CrypticMick/kanye-quotes-app-rn)\] 

If you’re thinking, _[**Nah Nah Nah**](https://www.youtube.com/watch?v=Mxs-ZMfyurU)_ he never showed us **how to make the button work**, I got you. Hit the **Bonus section** below. And if this is the end, \*_take it [Eazy\*!](https://www.youtube.com/watch?v=6kVZ5rsKLS4)_

🎵”_The Lyor Cohen or Dior Homme, that's Dior Homme not Dior homie”_ 
_\-_ [Devil in a New Dress](https://www.youtube.com/watch?v=sk3rpYkiHe8), M.B.D.T.F

## **Bonus: Fixing the `Button` with `onPress`**

At the moment, a **new quote requires restarting the app**. This would be terrible UX in an app, which is why I wanted to break down the solution. **The fix** requires something to trigger the `useEffect` hook to **refetch a new Kanye quote.** The new quote is then passed back to the `kanyeQuote` variable and finally updated on device.

We can **tap into the** `onPress` **prop** in `<TouchableOpacity>`, and pass through a function that is triggered when the button is pressed. This function needs to tell the custom hook that we want a new quote. There are a few ways to make this happen. 

In my approach, I’ll be **passing a parameter** to the `useRandomQuote` hook, adding the param to dependency array, which will trigger the hook to run again if the param value changes. 

In `App.js` let’s **set up an iterator** with `useState` and then **pass the setter function** to `onPress` to update the value of `i`.

```jsx
// Iterator to trigger custom hook
const [i, setI] = useState(0);

```

Locate the `onPress` prop and add the `setI` setter function. 

```jsx
// Update onPress prop with setter function
<TouchableOpacity style={styles.button} onPress={() => setI(i + 1)}>

```

Now **add the** `i` **parameter to the custom hook in order to** **re-fire the hook if the value changes** — this will happen when the button is pressed, as the value of `i` will change from `0` to `1`. 

```jsx
const kanyeQuote = useRandomQuote(i); // add i as a parameter

```

![App.js file in Visual Studio Code](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/hxtdvxwn2hwipljtwnuk.png)

Lastly, open up `useRandomQuote.js` and **receive the `i` param**, then **pass it to the dependency array**. **Save these changes** and test out the `More Kanye` button. Your button should be serving up fresh quotes each time it’s pressed! [Commit 5](https://github.com/CrypticMick/kanye-quotes-app-rn/commit/c4a873bd52e226899be87cd0997877e0ded24214)

![File in Visual Studio Code](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/onahxearxgn343h41zgq.png)

Receiving i param and adding to useEffect dependency array

![Kanye West quote app](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/q3lvy5hsrrm5xwb9grfh.gif)

**That’s a wrap** on the bonus content. You’ve come along way with Ye! If you’re a fan, here’s [Yandhi](https://youtu.be/URJSG09Nm4s), an unreleased project of his. **Keep grinding** and soon you’ll be a _[\*\*Champion](https://youtu.be/L1SEEMkc-qw)_ of hooks\*\*. 

🎵 “_So drive slow homie, you never know homie ... you need to pump your brakes and drive slow, homie” - Drive Slow, Late Registration_

---

[View on echobind.com](https://echobind.com/post/custom-react-hook-guide-build-a-kanye-quote-app-with-react-native)

---

# Out and About at React Miami

> Conferences are an excellent opportunity to learn new concepts and ideas, network with the community, and have a fantastic time with colleagues.

_By Echobind Team · 2022-04-28_

## **React Miami**

[React Miami](https://www.reactmiami.com/) was this past week, April 18 - 19\. It was an opportunity our team did not want to miss out on, especially with the beautiful, warm Miami weather and beaches! Conferences are an excellent opportunity to learn about languages and frameworks, learn new concepts and ideas, network with the community, grow as an engineer, and have a fantastic time with colleagues.

If you have never attended an in-person conference or have considered attending, we highly recommend it.

### **Meeting New People**

Meeting new people tends to be scary for most people. There is untapped knowledge and resources out there for you, just waiting for you to go out of your comfort zone. Taking risks, regardless of the outcome, becomes a personal growth experience.

Interacting with people at tech conferences is a great way to meet others in the same industry as you. Sharing ideas and knowing that other people have the same aspiring goals as you is refreshing.

If you are not comfortable speaking with strangers, you can try the Pac-Man method. Typically at conferences, you will see a group of 3 or more. You can slowly approach the group and start listening to the person talking. It can be awkward, but you would be surprised at how often it results in a handshake and a short introduction. The method has not failed us, and it is an excellent chance to meet new people.

![photo of the echobind team at dinner after React Miami](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/n1qo6g0ffld2hzhfmxdg.jpg)

### **Goals for the Team**

1. Talking with the speakers after their talk.
2. Pictures of people we met.
3. Networking and letting companies know about Echobind and what we can do to help.
4. Look for talent, recruit new members to the Echobind team
5. Provide giveaways to the community.

### Our **day-to-day:**

**Day 1:**

Kicking off the first day of the event, we made our way to a brunch hosted by React Miami. The brunch was located at the [Marseilles Hotel](https://www.marseilleshotel.com/), with beautiful scenes of the famous Miami beach.

![Marseilles Hotel](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/rryp1oum6pzywgcb7pc8.jpg)

We met some great people, and we spent most of our morning talking with other conference attendees. Brunch concluded after a couple of hours, and we headed to the conference.

The team arrived early to get badges and check out the parent conference, [eMerge Americas](https://emergeamericas.com/). After our initial walk-through of eMerge Americas, we made our way to React Miami’s first talk by [Nader Dabit](https://twitter.com/dabit3), a Developer Relations Engineer at [Edge & Node](https://edgeandnode.com/). Dabit gave a fantastic talk on “The Technology Stack for the Decentralized Web.”

Next up on the list was [Lee Robinson](https://twitter.com/leeerob), Director of Developer Relations at [Vercel](https://vercel.com/), who gave a talk on “Expectation vs. Reality of Marketing Websites.” His presentation structure captured the audience by showing live examples. Lee provided great insight into problems developers can run into when using frameworks other than NextJS.

The team initiated conversations with various types of companies. Companies attending eMerge Americas ranged from start-ups to Fortune 500 companies. Notable companies attending the conference included [Toptal](https://www.toptal.com/), [Vonage](https://www.vonage.com/), and [Flatfile](https://flatfile.com/). Each had exciting booths and fantastic employees. The employees gave great insight into the company and how their product can increase workflow. The team continued to hand out stickers and business cards along the way, growing our partnerships and clients.

**Day 2:**

Day two kicked off with a 9 am arrival to eMerge Americas. The team was able to see the best tennis player in the world, [Serena Williams](https://twitter.com/serenawilliams), talking about all things web3.

![eMerge Americas](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/wmqtdrv57hywskepnpsi.jpg)

We made our way to the React Miami conference happening next door to see the one and only [Kent C. Dodds](https://twitter.com/kentcdodds), Co-Founder, Director of Developer Experience at [Remix](https://remix.run/). Kent showed examples of how easy it is to get things running with RemixJS and why we should use it over other frameworks. Kent started to break down why this framework should be used in your next project.

Another notable talk came from [Jenn Creighton](https://twitter.com/gurlcode). Jenn's talk titled “Debugging Async JS” highlighted the importance of knowing where to start. Jenn gave a fantastic insight into some pitfalls, going as far as showcasing some unique ways to debug async javascript.

After Jenn’s talk, the team heard an inspirational talk from [Jerome Hardaway.](https://twitter.com/JeromeHardaway) Jerome is a self-taught developer who founded [Vets Who Code](http://vetswhocode.io). Jerome pairs with American Veterans, teaching them how to code and providing vets the opportunity to get back into the workforce.

We had the opportunity to learn more about accessibility from [Isabela Moreira](https://twitter.com/isabelacmor), a Software Engineer at [Microsoft](https://www.microsoft.com/en-us/). Isabela did a great job informing us of resources to make websites more accessible and how we can use that knowledge to pass accessibility audits for the future. Isabela shared how frustrating it can be for someone when a website is not accessible to them. As a new engineer in the industry, it was an eye-opener and something that should be important to the developer community to ensure our websites and applications are accessible. It’s great to work with a team that already keeps accessibility in mind, helping clients with audits and implementing best practices.

The team enjoyed various talks for the rest of the day. We left with a deeper understanding of web3 and made new friends!

**Day 3:**

The team spent the final day of our trip co-working in one of CIC Miami’s amazing office spaces. [CIC Miami](https://cic.com/miami) borders Miami's famous Wynwood district.

![CIC Miami office](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/d0lj564wksc1c8wdfhef.jpg)

Wynwood Art District - Miami, FL

![Wynwood Art District](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/gzv3sd5ubuvzlvqgrmi4.jpg)

The team had the opportunity to co-work together, which is refreshing because Echobind is a remote-first company—sharing ideas, pair programming, and talking about what we enjoyed during the conference and how we can implement some of those ideas in our work.

**Echobind**

If you are looking to grow your career, Echobind is currently hiring. Click [here](https://echobind.com/careers) to learn more about Echobind.

**Conclusion:**

We hope our journey and insights help you when attending a conference in the future. The takeaway is to try to get out of your comfort zone yet feel comfortable. Thank you for reading, and we would love to hear about your experiences at conferences.

![Echobind React Miami logo](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/jgrnfci5m8s3iwo5ssbe.png)

Authors:[ Dennis Campos](https://echobind.com/team/dennis-campos) and [Preston Kelly](https://echobind.com/team/preston-kelly)

---

[View on echobind.com](https://echobind.com/post/out-and-about-at-react-miami)

---

# Prioritizing Solutions Over Features

> Zack Marty shows how the way in which companies can sometimes prioritize features over solutions.

_By Zack Marty · 2022-04-06_

In this short video I show an example of the way in which companies can sometimes prioritize features over solutions. Before someone says that they need an app to solve a problem, fully understanding the basics of the problem is necessary to arrive at a real solution that lets you discover the needed features. At Echobind, finding the solution to a problem takes priority over cranking out features. A customized solution requires a strong discovery process that fully immerses itself in the problem’s context.

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/693647428?h=69a5048fdf&amp;badge=0&amp;autopause=0&amp;player_id=0&amp;app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture" allowfullscreen style="position:absolute;top:0;left:0;width:100%;height:100%;" title="Portfolio Demo: Homecare Communications"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

When you understand the problem fully, the solution almost comes through osmosis.

---

[View on echobind.com](https://echobind.com/post/prioritizing-solutions-over-features)

---

# Reduce repeated code in Jest tests with it.each

> Reduce repeated code in Jest tests with it.each. This approach allows users to cover more ground with test cases!

_By Kishan Gajera · 2022-03-31_

When writing tests, I often find myself repeating test cases with only minor changes. A common example of this is when testing different values for a form or API endpoint and expecting certain validation errors. 

Below is an example of what I'm referring to. These are two tests that are testing a GraphQL mutation to log a user in.

```jsx
describe('invalid email', () => {
  it('returns an Authentication error', async () => {
    await UserFactory.create({ email: 'foo@wee.net' });

    const variables = { email: 'fake', password: 'fake' };
    const response = await graphQLRequest({ query, variables });
    const errorMessages = response.body.errors.map((e: GraphQLError) => e.message);
      
        expect(errorMessages[0]).toBe("No user found for email: fake");
  });
});

describe('invalid password', () => {
  it('returns an Authentication error', async () => {
    const user = await UserFactory.create({ email: 'foo@wee.net' });

    const variables = { email: user.email, password: 'fake' };
    const response = await graphQLRequest({ query, variables });
    const errorMessages = response.body.errors.map((e: GraphQLError) => e.message);

      expect(errorMessages[0]).toBe("Invalid password");
  });
});

```

Both of these tests do the following:

1. Creating a user in the database
2. Make GraphQL request for the login mutation
3. Check the error messages returned from the server

The only difference between the two tests are the variables passed to the GraphQL mutation and the expected error messages.

Another approach to writing the tests to reduce code repetition is using [it.each](https://jestjs.io/docs/api#testeachtablename-fn-timeout). This allows us to write the test once and loop over it using different data in each iteration. Using this approach, our tests could be rewritten like this:

```jsx
it.each([
  {
    variables: { email: 'fake' },
    error: 'No user found for email: fake'
  },
  {
    variables: { password: 'fake' },
    error: 'Invalid password'
  },
])
('returns error: $error', async ({ variables, error }) => {
  const user = await UserFactory.create({ email: 'foo@wee.net' });
  const response = await graphQLRequest({
    query,
    variables: {
      email: user.email,
      password: 'fake' ,
      ...variables,
    }
  });
  const errorMessages = response.body.errors.map((e: GraphQLError) => e.message);
  expect(errorMessages[0]).toBe(error);
});

```

Now, we have an array of test cases passed to `it.each` that specify the variables to use in the GraphQL mutation and the expected error message. This is the array that will be iterated through. So, our test will run for each element and the element will be accessible in our test.

You should also notice that we're using `'returns error: $error'` for the title of the test. The `$error` references the `error` property in our test case objects. We do this to give each test case a unique title so if it fails, we know which case caused the failure.

We can easily add more test cases without needing to copy and paste. In this example, it might also be good to test when the `email` or `password` are undefined. To do this, we would just add the following elements to the array:

```jsx
[
    {
    variables: { email: undefined },
    error: 'Email is required'
  },
  {
    variables: { password: undefined },
    error: 'Password is required'
  },
]

```

I hope you saw how using this approach, you reduce repeating code and also can cover more ground with your test cases!

---

[View on echobind.com](https://echobind.com/post/reduce-repeated-code-in-jest-tests-with-it-each)

---

# TypeScript - Generic Types

> This is a tutorial on what generic types are in TypeScript, how to use them, and when you might find a use case for them.

_By Dominic Sherman · 2022-03-30_

Generic types provide a way to dynamically define types within TypeScript so that you can more accurately type functions and helpers. This is a tutorial on what generic types are, how to use them, and when you might find a use case for them. This assumes you have a basic understanding of TypeScript and are looking to level up your knowledge.

### Example - Removing Nulls from Arrays

Suppose you had a common problem in your application with arrays containing null values. This could be data coming from your server or somewhere else, but it can be a very annoying problem to deal with because then every time you want to use this array, you have to check every value for nullability. For example:

```javascript
const res = await fetch('/foo');
const data = await res.json();

return data.map((data) => {
	if (data) {
		// do something
	} else {
		// what do I do???
  }
});
```

Most of the time, we would probably just filter out any values that are `null` and then return the data.
```javascript
const res = await fetch('/foo');
const data = await res.json();
const dataWithoutNulls = data.filter((data) => data !== null);

return dataWithoutNulls.map((data) => {
	// do something
});
```
This works fine, but not something we’d want to do every time we need to fetch data. So we’d probably add a helper function for it, and maybe add it to a fetch middleware or something like that.

```javascript
const removeNulls = (dataWithNulls) => {
  return dataWithNulls.filter((x) => x !== null);
}

const res = await fetch('/foo');
const data = await res.json();
const dataWithoutNulls = removeNulls(data);

return dataWithoutNulls.map((data) => {
	// do something
}); 
```

If we introduce TypeScript to this scenario, that makes things a little bit more complicated. If our requests are strongly typed, which is common and easy now with [GraphQL](https://www.graphql.org) and [codegen](https://www.graphql-code-generator.com/), then we have to make sure our function to remove nulls is also properly typed. Let’s try this without adding any types to our function first. For the example, we’ll set up some data that can either be an interface type or null:

```javascript
interface FooType {
	foo: string;
	bar: number;
}

const withNulls: (FooType | null)[] = [{ foo: "foo", bar: 1 }, null, { foo: "bar", bar: 2 }];
const value = withNulls[0]; 
```

If I try to pull a value out of my `withNulls` array, TypeScript knows it might be `null` (hovering over `value` shows that its type can be `FooType | null`):

![Helper Function](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/axiewgowd6sw2vwlizzl.png)
  
Let’s add our helper function:
```javascript
const removeNulls = (dataWithNulls) => {
  return dataWithNulls.filter((x) => x !== null);
}

const withoutNulls = removeNulls(withNulls);
const nonNullValue = withoutNulls[0];
```

If we look at the type on `nonNullValue`, its shown as `any` now:

![nonNullValue typed as withoutNulls[0]](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/rrbngtxopkizn0klxx1c.png)
  
Since we don’t have any types on our function, TypeScript will just default everything to `any`. While this “works”, [it defeats the point of TypeScript](https://thoughtbot.com/blog/typescript-stop-using-any-there-s-a-type-for-that) because now whenever we use the function we lose all context as to what the type was. At that point, we are essentially writing JavaScript. Let’s try to add some types to our function.

For the inputs and outputs of our function, we want it to receive an array that is either the `FooType` or `null` , and then return an array that is only `FooType`:
  
```javascript  
const removeNulls = (dataWithNulls: (FooType | null)[]): FooType[] => {
	// ...
} 
```

Great, that looks right, and it looks like it worked to properly maintain the types after being run through the function (hovering over `nonNullValue` shows its value to be `FooType` rather than `FooType | null`:

![const nonNullValue is now FooType](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/zcxijbfx9ntwzpafq9io.png)

While our function definition works now, we’ve introduced a problem within our function itself. The`filter` function doesn’t know how the logic of our predicate is working, so it thinks even after filtering the type of the function hasn’t changed and doesn’t match what we’re saying we’re returning. Here’s the error we’re getting:

```javascript
Type '(FooType | null)[]' is not assignable to type 'FooType[]'.
  Type 'FooType | null' is not assignable to type 'FooType'.
    Type 'null' is not assignable to type 'FooType'.ts(2322)
```

![TypeScript code](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/edufnsmtihrc3zukdjlt.png)

In order to properly type this, we need to define a predicate type as the return value of our filter function, which looks like this:

```javascript
const removeNulls = (dataWithNulls: (FooType | null)[]): FooType[] => {
	// predicate on callback
  return dataWithNulls.filter((x): x is FooType => x !== null);
}
```

Looks like everything is working now, but as I’m sure you’ve noticed, this function only works for `FooType` What if we needed to do it for a different type? This is where generic types come in. Without them, we’d have to write a new function for every type that we want to use, which kind of defeats the purpose of the function.

Our goal here would be to write a utility function that allows users to consume it while using their own types. If we review TypeScript’s documentation, we can see that generics are the way to do properly do this. TypeScript allows for something called a type variable, which is a special kind of variable that that works on types rather than values. From the `Hello World of Generics` TypeScript docs, we can see the basic identity function usage of type variables:

```javascript
function identity<Type>(arg: Type): Type {
  return arg;
}
```

This type variable Type ”allows us to capture the `type` the user provides (e.g. `number`), so that we can use that information later”.

Let’s try to use a type variable in our function to maintain the type passed by the user. Our goal with our type variable would be to receive our argument as an array of our type (`T`) or `null`, and return an array of just our type (`T`). That would look like this:

```javascript
const removeNulls = <T>(dataWithNulls: (T | null)[]): T[] => {
  return dataWithNulls.filter((x): x is T => x !== null);
}
```

Since we have the argument `dataWithNulls` defined using our generic type variable `T`, we can either explicitly pass `T` when calling the function or let TypeScript infer it for us.

```javascript
// valid
const withoutNulls = removeNulls<FooType>(withNulls);

// also valid
// since withNulls is type (FooType | null)[], TypeScript knows that T must be equal to FooType
const withoutNulls = removeNulls(withNulls);
```

Now that we are using our generic type, we can double check our example to make sure it still works. Looking at the type of `nonNullValue` from above, we can see that its type is still just `FooType` instead of `FooType | null`, except now our function works for more than just `FooType` 🥳
![TypeScript code](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/nl2x3nsjuqoqqfvkp4s2.png)

Now that we have a basic understanding of generics and why they can be useful, let’s look at a more complicated example.

### Example - Removing Nulls from Objects

Suppose I wanted to remove the nulls from the values of an object. This is a similar problem, but requires a much different solution. Here’s my example type:

```javascript
interface BarType {
  [key: string]: string | number | null;
}
```

I’d like to write a function that removes any fields that are null off of it and returns the type correctly. Our first pass might look like this:

```javascript
interface BarType {
  [key: string]: string | number | null;
}

interface BarTypeWithoutNulls {
  [key: string]: string | number;
}

const removeNulls = (objectWithNulls: BarType): BarTypeWithoutNulls => {
  return Object.keys(objectWithNulls).reduce<BarTypeWithoutNulls>((acc, key) => {
    const value = objectWithNulls[key];

    // only add to accumulator if value is not null
    if (value !== null) {
      acc[key] = value;
    }

    return acc;
  }, {});
}
```

The JavaScript looks correct, and the types “work”, but as we found earlier it only works for this specific type and we have to redefine our new type without nulls. In order to define a type of an object that removes the null, we’ll need our **type** to receive a generic type. Something like this:

```javascript
type ObjectWithoutNulls<T> = {
  // now what??
}
```

Our goal here is to recreate our generic type `T` in this new type but make sure we are excluding the nulls. What this means is that we want our type to map over all of the keys in `T`, and set the value of our type to be whatever the value of the generic type would be, except exclude `null`. If we look at [TypeScript’s documentation on mapped types](https://www.typescriptlang.org/docs/handbook/2/mapped-types.html), we can see that the syntax for that looks like this:

```javascript
type ObjectWithoutNulls<T> = {
	[K in keyof T]: // get the value?
}
```

Since we have `K` as a key of `T`, that allows us to just pull `T[K]` to get the type value off of `T`:
```javascript
type ObjectWithoutNulls<T> = {
	[K in keyof T]: T[K];
}
```
All we’ve done now though is create an identity type, which gives us back whatever we give it. If we want to exclude nulls from the value on `T`, we need to take advantage of the `Exclude` type built into TypeScript:

```javascript
type ObjectWithoutNulls<T> = {
	[K in keyof T]: Exclude<T[K], null>;
}
```

Another thing we need to do for this type is to enforce what types can be passed to it. Going to the [TypeScript documentation on generic constraints](https://www.typescriptlang.org/docs/handbook/2/generics.html#generic-constraints), we can use the `extends` keyword to achieve this. We want our type to accept any generic type that is a [`Record`](https://www.typescriptlang.org/docs/handbook/utility-types.html#recordkeys-type) with keys that are anything or `null`. We can use `keyof any` here, which generates a type that can be any of the base types (`string | number | symbol`). It is important here to note the difference between `any` and `keyof any: any` will allow anything to be passed (even another object), while `keyof any` just breaks down to only allow `string | number | symbol`.  The final type looks like this:

```javascript
type ObjectWithoutNulls<T extends Record<string, keyof any | null>> = {
	[K in keyof T]: Exclude<T[K], null>;
}
```

Now we can use our type as the return value of our helper function:

```javascript
// use the same generic constraint that we use in ObjectWithoutNulls
const removeNulls = <T extends Record<string, keyof any | null>>(objectWithNulls: T): ObjectWithoutNulls<T> => {
  // cast Object.keys(type) to be keyof T since it generates a string[] by default
  return (Object.keys(objectWithNulls) as (keyof T)[]).reduce((acc, key) => {
    const value = objectWithNulls[key];

    // only add to accumulator if value is not null
    if (value !== null) {
      // value is still listed as keyof T here, so we need to exclude null now that we've checked for it
      acc[key] = value as Exclude<T[keyof T], null>;
    }

    return acc;
  }, {} as ObjectWithoutNulls<T>);
}
```

Now let’s set up an example to test it out:
```javascript
const withNulls: BarType = {
  foo: 'foo',
  bar: null
}

const value = withNulls['foo'];
```

If we look at the type of `value`, we can see that it can be `string | number | null`, as expected:

![TypeScript code](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/wdmlyijjvdhiuygouorq.png)
When we run this through our `removeNulls` function, we can see that a value off of the object after removing nulls is just `string | number` 🚀

```javascript
const withoutNulls = removeNulls(withNulls);
const nonNullValue = withoutNulls['foo'];
```
![TypeScript code](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/g0vx1wenyps9bxvh5zt1.png)

We can also double check that our generic constraint works correctly and only allows objects, by trying to pass `[null]` to the function. We see the following error, showing that we have this properly set up:

```javascript
<div class="w-embed w-script"><pre><code class="language-javascript line-numbers"><script>Argument of type 'null[]' is not assignable to parameter of type 'Record<string, string | number | symbol | Record<string, any> | null>'.
  Index signature for type 'string' is missing in type 'null[]'.ts(2345)
  ```
### Example - Removing Nulls from Objects Recursively

The final example is one that you might not run into often but can still help you understand some more advanced TypeScript concepts. In this example, let’s take the previous example and try to make it work for nested recursive objects. Here’s our example type:

```javascript
interface BarType {
  [key: string]: string | number | BarType | null;
}
```
Now, a value can be either a string, number, null, or another object. We can see that because of our generic constraint on the function/type, this type is not currently allowed to be passed to our function:

```javascript
<div class="w-embed w-script"><pre><code class="language-javascript line-numbers"><script>Argument of type 'BarType' is not assignable to parameter of type 'Record<string, string | number | symbol | null>'.
  'string' index signatures are incompatible.
    Type 'string | number | BarType | null' is not assignable to type 'string | number | symbol | null'.
      Type 'BarType' is not assignable to type 'string | number | symbol | null'.ts(2345)
```
![TypeScript code](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/cvlgxzlve7sd60mmabte.png)

To fix the constraint, we’ll want to allow `Record<string, unknown>` as another value passed to the function/type:
```javascript
type ObjectWithoutNulls<T extends Record<string, keyof any | Record<string, unknown> | null>> = {
  [K in keyof T]: Exclude<T[K], null>;
}

// use the same generic constraint that we use in ObjectWithoutNulls
const removeNulls = <T extends Record<string, keyof any | Record<string, unknown> | null>>(objectWithNulls: T): ObjectWithoutNulls<T> => {
	// ...
}
```

Let’s set up a quick example to test the type of a recursive field:
```javascript
const nonNullNestedValue = typeof nonNullValue === 'object' ? nonNullValue['foo'] : nonNullValue; 
```

Looking at the type of `nonNullNestedValue-`, we can see that its type is still `string | number | BarType | null`:

![TypeScript code](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/gp8hldmju3i5l6cjwdv5.png)

In order to make this new type work recursively, we’ll need to take advantage of generic constraints, recursion, and conditional types. With [conditional types](https://www.typescriptlang.org/docs/handbook/2/conditional-types.html), we can check if a type extends another type, and decide the output based on that. So in this scenario, we want to check if the value we are looking at is another object (if it `extends` our generic constraint), and if so call our type again with our value, but still excluding nulls. That syntax looks like this:

```javascript
<div class="w-embed w-script"><pre><code class="language-javascript line-numbers"><script>type ObjectWithoutNulls<T extends Record<string, keyof any | Record<string, unknown> | null>> = {
  [K in keyof T]: T[K] extends keyof any | null ? Exclude<T[K], null> : ObjectWithoutNulls<Exclude<T[K], keyof any | null>>;
}
```

![TypeScript code](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/zxlxc72f8amsnxdy2llj.png)

It’s not the prettiest looking type, but looking at the type on our value now we can see that it works! `nonNullNestedValue` now shows its type as `ObjectWithoutNulls<BarType>`:

![](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/qyogik6q1q9tdbrmilmn.png)

Once you have a solid grasp on the syntax for generic types, constraints, and conditional types, you’ll find that reading and understanding the source code for libraries written in TypeScript, like Apollo Client and React Query, will become much easier. These concepts are frequently used in those places. The ability to properly type usages of these libraries cannot be understated, as well as ensuring any utility functions that you write are properly typed.

---

[View on echobind.com](https://echobind.com/post/typescript-generic-types)

---

# New ECMAScript Features to Help Get You Through Your Day

> Mar 29, 2022 | Let's explore some of the newest features that will have a significant impact on the way we write code in javascript.

_By Cory  Bosselmann · 2022-03-29_

Programmers are always looking for new ways to make their lives easier, and I’m no different. That’s why I will occasionally find myself perusing the latest ECMAScript specification for features that may help me with my day-to-day. Today I’d like to draw some attention to some of the newest features that I believe will have a significant impact on the way we write code in JS.

## **The .at() method**

The .at() method allows for the use of “negative indexing” of basic JS iterables (Array, String, TypedArray). This is a feature in other languages, like Python, and is something JS developers have been asking for for quite some time now.

Why doesn’t negative indexing an array work when using bracket notation? This is because the \[ \] syntax is not exclusive to Arrays and Strings. It applies to all objects. Referencing arr\[-1\] yields undefined, because you are really trying to reference the property of an object with a key of “-1”.

#### Getting the last item in an array using arr\[arr.length — 1\]

```javascript
const arr = [1, 2, false, 'foo'];

const lastItem = arr[arr.length -1]

console.log(lastItem) // Outputs: 'foo'
view raw
```

Having to name the indexable class twice has always felt a bit clunky to me. In addition to being overly wordy, this method does not lend itself to indexables returned by a function.

```javascript
function returnArray() {
  return [1, 2, false, 'foo'];
}

const tempArr = returnArray();

console.log(tempArr[tempArr.length -1]; // Outputs: 'foo'
view raw
```

### Using .slice

Negative indexing is supported by the .slice method (as well as .splice) and functions as desired.

```javascript
const arr = [1, 2, false, 'foo'];

const lastItem = arr.slice(-1)[0];

console.log(lastItem); // Outputs: 'foo'
```

Using the .slice method also gets rid of the need to store an array returned from a function in a variable before referencing it.

```javascript
function returnArray() {
  return [1, 2, false, 'foo'];
};

console.log(returnArray().slice(-1)[0]); // Outputs: 'foo'
```

What to note here is that the return value of .slice is itself an array, and so we need to append the \[0\]. While this syntax is more flexible than the first, I still believe it is not the most readable.

Let’s see how this would be achieved with the .at() method.

```javascript
const arr = [1, 2, false, 'foo'];

// last item in array
console.log(arr.at(-1)); // Outputs: 'foo'

// second-to-last item
console.log(arr.at(-2)); // Outputs: false

function returnArray() {
  return [3, 4, true, 'bar'];
};

// works with anonymous values
console.log(returnArray().at(-1)); // Outputs: 'bar'
```

Terse. Flexible. Readable.

### Object.hasOwn()

The new Object.hasOwn() method is meant to be a replacement for Object.hasOwnProperty(). It is used to check if a property exists on a given object.

```javascript
const obj = {
  foo: 'bar'
};

console.log(Object.hasOwn(obj, 'foo')); // Outputs: true 
```

The main difference between the two methods is that Object.hasOwn() only checks for properties owned by a given object, and ignores properties inherited from Object.prototype. This is useful because methods on Object.prototype may not always be available.

Such is the case for objects created with Object.create(null)

```javascript
// methods on Object.prototype are not available here
const object = Object.create(null);

console.log(object.entries());
// Uncaught TypeError: object.entries is not a function 
```

The added benefit of this is that it negates the need for third-party implementations like [lodash.has](https://www.npmjs.com/package/lodash.has).

### Numeric Separators

I am a big proponent of readability, so the addition of numeric separators is a feature that’s had me pretty excited. Numeric separators allow for the use of an \_ to create a grouping of integers making it easier for developers to quickly decipher large numbers.

```javascript
const largeNum = 1000000000;

const readableLargeNum = 1_000_000_000; // Same number as above 
```

### Logical Assignment Operators

The new ECMAScript specification introduces a set of logical assignment operators similar to ones found in other languages like Ruby, and can save you a few lines of code.

### Logical OR Assignment

Assigns when the value to the left of the operator is falsey.

```javascript
// before
let x = undefined;
if (!x) {
  x = 5;
}

console.log(x); // Outputs: 5

// after

let y = undefined;
y ||= 5;

console.log(y); // Outputs: 5 
```

### Logical AND Assignment

Assigns when the value to the left of the operator is truthy.

```javascript
// before
let x = 5;
if (x) {
  x = 6
}

console.log(x); // Outputs: 6

// after
let y = 5;
y &&= 6;

console.log(y); // Outputs: 6 
```

### Logical Nullish Assignment

Assigns when the value to the left of the operator is nullish (null or undefined).

```javascript
let x = null;
x ??= 5;

console.log(x); // Outputs: 5 
```

#### Resources

All of the features mentioned here have reached Stage 4, and are supported by most modern browsers. Here are some links to the documentation in case you would like to learn more.

[.at() method](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global%5FObjects/Array/at)

[Object.hasOwn()](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global%5FObjects/Object/hasOwn)

[Numerical Separators](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Lexical%5Fgrammar#numeric%5Fliterals)

[Logical OR Assignment](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Logical%5FOR%5Fassignment)

[Logical AND Assignment](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Logical%5FAND%5Fassignment)

[Logical Nullish Assignment](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Logical%5Fnullish%5Fassignment)

---

[View on echobind.com](https://echobind.com/post/new-ecmascript-features-to-help-get-you-through-your-day)

---

# Inspiring Kids to Pursue a Future in Tech

> Mar 28, 2022 | Hustle N’ Code is an annual Hackathon event in Los Angeles sponsored by TXT: Teens Exploring Technology with the goal to inspire and encourage underserved youth to pursue computer science.

_By Jennifer  Watanabe · 2022-03-28_

![Three women posing at Hustle N' Code](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/tgkw2jlfmtyhqmxeg04b.jpg)

[Hustle N’ Code](https://exploringtech.org/programs/hustlencode) is an annual Hackathon event in South Central Los Angeles sponsored by [TXT: Teens Exploring Technology](https://exploringtech.org/home). TXT’s goal is to inspire and encourage underserved youth to pursue computer science. Many of these youth aren’t exposed to the typical resources of their peers that would allow them to explore an interest or career in computer science.

At Hustle N’ Code, boys and girls up to 18 years old form groups to solve an issue they see in their community. The hackathon is an all-day event that focuses on identifying a problem in their community and brainstorming a solution to that problem, whether that is a website, app, or some other solution involving code. Professional developers then mentor and guide them on creating their website or app from wireframe designs to implementation and final presentation.

![Hustle N’ Code](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/pc37a1vleyi0mayozod5.jpg)

From my experience volunteering at this hackathon, it is less about the cool prizes but the exposure to tech that many of the kids I was mentoring did not have. All of them were fascinated by code that they eventually wrote themselves. They were excited to see the end result show up on their screen.

### Tips on Working with Youth

1. **Let them answer the prompts on their own.** It’s not their project anymore if they weren’t the ones to see the issue and brainstorm a solution. I believe this also helps teach kids how to problem solve.
2. **Keep it simple.** I saw a lot of volunteers attempt to teach Javascript in the first ten minutes. Almost all of these kids have never seen HTML and weren’t old enough to be customizing their MySpace profiles when that was all the rage. Basic HTML is a great place to start, the syntax is not complicated and you can see results instantly on the screen.
3. **Let them go at their own pace.** At Hustle N’ Code the groups are split randomly so younger children can be in the same group as high schoolers. The younger children are generally happy with learning basic HTML and changing the color of their text, while the older kids may pick that up quickly and move on to creating buttons and hooking up basic click logic. I found that hand holding the older kids later in the event worked great and allowed them to be more creative.
4. **Let them be curious.** In my experience letting some of the kids be free to explore HTML and express what they were curious about worked better than trying to assign them concrete tasks that would win us the competition. This was especially true for very young children and shy kids.
5. **Let them write the code.** It makes kids feel like they did it themselves when they actually did it themselves. Writing the code for them may be faster but fails to reinforce the knowledge that they’re trying to learn. After hand holding them through a few lines they usually pick up what to do and can finish the rest with minimal supervision.
6. **Make it fun!** The goal of the hackathon is to inspire interest in computer science and the best way to do that is to make it fun! When I let my group choose their own images or write whatever they wanted they were way more engaged even if the things they chose were maybe not the best choices to win the competition.

It was a joy to see some of the kids in my group take the knowledge they had learned in such a short time and apply it to other areas of their code. Some of them were so engrossed they continued to tweak their code even when the hackathon was over.

Working with kids isn’t the easiest thing to do in general and teaching HTML on top of it is even harder but it’s worth it!

---

[View on echobind.com](https://echobind.com/post/inspiring-kids-to-pursue-a-future-in-tech)

---

# Safely Alter Postgres Columns with USING

> Discover the USING clause and how its magic can be employed to alter table columns in Postgres.

_By Cully Larson · 2022-03-25_

## But first, Arrays

Postgres has this super useful data type called [Array](https://www.notion.so/echobind/%5B%3Chttps://www.postgresql.org/docs/13/arrays.html%3E%5D%28%3Chttps://www.postgresql.org/docs/13/arrays.html%3E%29). Not to throw out an obscure term without defining it, an “array” is a sort of list of things 😉. Have you ever wanted to associate a row in your database with a list of things? Without the array type, you’d have to create a join table. This might be the best option in some cases, but if you just want to add a few items to each row, or if you want to do the same thing for multiple lists of items, Postgres arrays to the rescue!

At Echobind we recently had a situation where we needed to alter a column from a scalar (a `projectType` enum field) to an array (each row could be classified under multiple “project types”). A simple `ALTER TABLE` query, right?

```javascript
CREATE TYPE "ProjectType" AS ENUM ('BILLABLE', 'NONBILLABLE');

CREATE TABLE "Proposal" (
  "id" TEXT NOT NULL,
  "projectType" "ProjectType" NOT NULL,

  PRIMARY KEY ("id")
);

INSERT INTO "Proposal" VALUES ('a001', 'BILLABLE');

ALTER TABLE "Proposal" ALTER COLUMN "projectType"
SET DATA TYPE "ProjectType"[]; 
```

Well, we have a problem. This query will fail if any rows have a non-null value in `projectType`. We could just set all the values to `null` (we would also need to allow `null` values in that column), but that would destroy our data. We could create a migration script, but that seems like a lot of work.

## Finally, USING

Thankfully Postgres has us covered once again! It provides the [USING](https://www.notion.so/echobind/%5B%3Chttps://www.postgresql.org/docs/13/sql-altertable.html%3E%5D%28%3Chttps://www.postgresql.org/docs/13/sql-altertable.html%3E%29) clause.

> The USING clause specifies how to compute the new column value from the old.

It’s basically a “function” that takes the old value in the column and generates a new value (spoiler: it does even more than that!). We can use `USING` in our original `ALTER` query to do something like this:

```javascript
ALTER TABLE "Proposal" ALTER COLUMN "projectType"
SET DATA TYPE "ProjectType"[]
USING ARRAY["projectType"]; 
```

This tells Postgres to take the value in `projectType` (before the `ALTER` is applied), put it into an array, and use that as the value for the `projectType` column after the `ALTER` is applied. With this version of the query, we don’t destroy any data.

```javascript
ALTER TABLE "Proposal" ALTER COLUMN "projectType"
SET DATA TYPE "ProjectType"
USING "projectType"[1]; 
```

This tells Postgres to use the first value in the `projectType` array (Postgres arrays start at one—I’m sure there are reasons, but still 🤷) as the new value. But as I hinted before, this will only be non-destructive if you haven’t added any more items to the `projectType` array (i.e. it only has one value in each row). If it has more than one value, you’ll lose all of them except the first.

## The rumors are true, there’s more

I know, how could it get better? Well, lay aside those low expectations and prepare to be astonished; `USING` is so much more powerful. When building your `USING` clause, you can use:

1. Any of the columns in your table (not just the one being modified).
2. Any Postgres function.
3. Explicit casting.
4. A fourth thing.

### All the columns

`USING` doesn’t limit you to just the column you’re altering. You can use any of the columns in your table. Let’s say you have a table like this that tracks some metrics:

```javascript
CREATE TABLE "Metric" (
  "id" TEXT NOT NULL,
  "url" TEXT,
  "authorizedVisits" INTEGER,
  "unauthorizedVisits" INTEGER,
  "summary" TEXT,

  PRIMARY KEY ("id")
);

INSERT INTO "Metric" VALUES ('b001', '/products', 30, 60, 'You have 90 total visits.'); 
```

This was a bad decision; `summary` should not be human-readable text. It would be better if it was just the total number of visits and we could use it in code however we want:

```javascript
ALTER TABLE "Metric" ALTER COLUMN "summary"
SET DATA TYPE INTEGER
USING "authorizedVisits" + "unauthorizedVisits"; 
```

With this, we’re altering `summary` to be the sum of the `authorizedVisits` and `unauthorizedVisits` columns.

And just to cover all our bases, we could roll this back with:

```javascript
ALTER TABLE "Metric" ALTER COLUMN "summary"
SET DATA TYPE TEXT
USING 'You have ' || "summary" || ' total visits.'; 
```

### All the functions

Want to do some more complex manipulation? You can use Postgres functions in `USING`. Let’s say we’ve been storing a timestamp in the MySQL DATETIME format (`YYYY-MM-DD HH:MI:SS`). But then we come to learn that Postgres has its own timestamp data type (we’re always learning as developers; no shame in not knowing the best chili dog toppings at our first rodeo).

```javascript
CREATE TABLE "Message" (
  "id" TEXT NOT NULL,
  "from" TEXT,
  "to" TEXT,
  "message" TEXT,
  "sentAt" TEXT,

  PRIMARY KEY ("id")
);

INSERT INTO "Message" VALUES (
  'c0001',
  'George',
  'Elaine',
  'You should''ve seen the look on her face! It was the same look my
father gave me when I told him I wanted to be a ventriloquist!',
  '2022-02-02 22:22:22'
); 
```

Postgres has a built-in function for converting strings to timestamps, `TO_TIMESTAMP`, and we can use it in the `USING` clause:

```javascript
ALTER TABLE "Message" ALTER COLUMN "sentAt"
SET DATA TYPE TIMESTAMP(3)
USING TO_TIMESTAMP("sentAt", 'YYYY-MM-DD HH24:MI:SS'); 
```

This converts our DATETIME string value into a native timestamp, using the specified format.

And to stay on brand, we can roll it back with:

```javascript
 ALTER TABLE "Message" ALTER COLUMN "sentAt"
SET DATA TYPE TEXT
USING TO_CHAR("sentAt", 'YYYY-MM-DD HH24:MI:SS'); 
```

### Boring, explicit casting

When you change the data type of a column with `USING`, Postgres will do its best to cast the current value to the new type. But sometimes it can’t (where is my ‘90s dream of an artificial intelligence utopia) and you need to explicitly define how you want Postgres to cast your value.

Let’s say we have some JSON data, but we’re storing it in a `TEXT` field. We want to convert that to a fancy `JSON` field:

```javascript
CREATE TABLE "House" (
  "id" TEXT NOT NULL,
  "specs" TEXT,

  PRIMARY KEY ("id")
);

INSERT INTO "House" VALUES (
  'd0001',
  '{"size": 1500, "sizeUnits": "sf", "bathrooms": 12}'
);

ALTER TABLE "House" ALTER COLUMN "specs"
SET DATA TYPE JSON
USING "specs"::JSON; 
```

Without the `USING` clause, Postgres would complain:

> column "specs" cannot be cast automatically to type json

But with the explicit cast it works just fine.

Postgres can cast JSON to TEXT on its own, so we can roll this back without `USING` (sad, I know). But just to include one more example, here’s what it would look like doing it explicitly:

```javascript
ALTER TABLE "House" ALTER COLUMN "specs"
SET DATA TYPE TEXT
USING "specs"::TEXT; 
```

### Dare to dream, a fourth thing

I was really hoping this would be “You can even use subqueries 🤯”. But we dreamt too big. Even `USING` has its limits.

### All good things

Are you still reading? It’s over. Go home. I am contractually obligated to say that in this article we covered the `USING` clause and how its magic can be employed to alter table columns in Postgres. We looked at so many shiny examples of using `USING` with columns and functions and casting and not (maybe someday, in the machine utopia) subqueries.

#### Resources

* [Postgres Arrays](https://www.postgresql.org/docs/13/arrays.html)
* [Postgres ALTER TABLE](https://www.postgresql.org/docs/13/sql-altertable.html)

---

[View on echobind.com](https://echobind.com/post/safely-alter-postgres-columns-with-using)

---

# What I Wish I had Known as a Woman in Tech

> Mar 23, 2022 | Do not be intimidated, the number of women in the industry is growing and it is possible to find your dream career in the tech industry.

_By Shae Trissler · 2022-03-23_

## **Don't Be Intimidated**

Growing up my uncle would talk about his job in the tech industry and I was always so intrigued. I also used to think there is no way I could do that. It always sounded like you had to be a 4.0 college student and have multiple degrees to be able to work in such an industry. I was too intimidated to even ask what it would take or how to start. So I went to college got my business degree and worked in the corporate world for 5 years. I finally got the courage to start inquiring about tech and what it might take for me to get into the industry. When I thought of the tech industry I thought: you had to know how to code or at least be able to understand the code. I think that was just an excuse for why I didn't research it sooner. Yet I told myself not to be intimidated, you have to put in the hard work and push yourself to learn.

## **Women in Tech Statistics**

In that same breath I thought it seemed to be a very male dominated industry and that was intimidating. There were very few women to look up to or ask for advice. Even today the stats show: 28% of the workforce in 51 of the top US tech companies are women, with 50% of the total labor force in the US being women. Girls have been steered away from science and math which has limited the access and opportunities into these fields. Women have been working to show that the tech industry needs to support more hiring of women. There are many benefits to hiring and promoting women in the tech industry. One of many being that according to the [Peterson Institute for International Economics](https://www.piie.com/publications/wp/wp16-3.pdf) \- Firms where 30% of leaders are women have a 15% increase in profitability (a net profit margin that is more than 1 percentage point higher) compared with similar firms with no female leaders.

![Board meeting](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/bc1iztnusxxqvcutkr3s.jpg)

## **It is Possible**

When I started my career I wasn’t sure my path, but once I got going I knew that Project Management was an area I could see myself succeed. I have always been very organized, loved helping take projects from start to finish, assisting cross functional teams, and helping finding solutions to remove impediments. Being a Project Manager also opened the doors to different industries and gain knowledge on how to successfully be the glue between all teams. I set my sights on getting a Project Management position within the tech industry because tech drives everything. It is fast-paced, ever changing and our future. I was lucky enough to start my career in web development and have since moved on to be a Project Manager at Echobind helping build apps and I could not be happier.

### **What I Wish I Had Known** 

Do not be intimidated, the number of women in the industry is growing and it is possible to find your dream career in the tech industry (without knowing how to code). Things can still be intimidating even to this day but it also makes it exciting, challenging, and worth it!

**Resources:**

<https://www.bcg.com/en-us/publications/2021/benefits-of-women-in-tech>

<https://www.aauw.org/resources/research/the-stem-gap/>

<https://www.forbes.com/sites/forbesbusinesscouncil/2022/02/15/women-in-tech-why-and-how-to-gain-visibility/?sh=4bfc92582940>

---

[View on echobind.com](https://echobind.com/post/women-in-tech-what-i-wish-i-had-known)

---

# Build the Best Products with the LeanUX Framework

> Mar 22, 2022 | The LeanUX framework is a tool to help make more educated decisions and to inspire passion for the product vision along the way.

_By Mari Triphahn · 2022-03-22_

One of the most challenging questions we answer as product managers is “What are we going to build next?”. As if answering this question isn’t challenging enough, it can be equally as challenging to get all of your team members and business stakeholders bought into your vision. When I came across the LeanUX framework, I was instantly intrigued by the realistic, yet empathetic approach that this method takes to understanding your business and users. It encourages us to collaborate with all of the right minds to be able to best align on all areas of a product, and ultimately answer that looming question.

The Lean UX framework is defined in the [LeanUX book, authored by Jeff Gothelf and Josh Seiden](https://www.amazon.com/Lean-UX-Creating-Great-Products/dp/1098116305/ref=sr%5F1%5F1?crid=2GYC8ABWESRUD&keywords=leanux&qid=1647995150&sprefix=%2Caps%2C240&sr=8-1), as “_A design approach that brings the true nature of a product to light faster, in a collaborative, cross functional and user centered way.”_ It encourages us to “..._build a shared understanding of the user, their needs, our proposed solutions and our definition of success.”_ LeanUX was created with a focus on design thinking, but it also highlights the value of bringing together important minds from all areas of your team. This framework combines waste reducing and continuous iteration principles from the lean and agile methodologies and applies those to enable teams to collaborate on their own destiny, encourages them to understand and empathize with their customers, and eliminates the fear of failure in order to foster innovation.

So, who should participate in filling out the LeanUX Canvas? It’s important to gather a good, well rounded group of team members. These will likely come from product, design, engineering, and maybe some additional business stakeholders if their input is going to be helpful to the conversation. To paraphrase from the book, “_No one position/role (devs, design, product, etc.) has all of the answers, the more diverse your team is the more innovative and broad-reaching the solutions the team generates_”.

![Lean UX Canvas screenshot](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/wdy2jnmsntooip6ebu5e.png)

## Step 1: Define Your Business Problem

Identifying a problem to solve is necessary to creating a great product, but often I find that this metric gets lost as products get built, or isn’t clearly communicated across a team at the beginning.For younger products, this may be relatively easy to answer, but may also encourage additional conversations between your team members to align on what your organization intends to achieve. If you are using the LeanUX canvas on a more mature product, your product and organization may have many problems it wants to solve, but aligning on one area will allow you to fire all of your weapons at a single problem, rather than spreading out that impact to multiple problems and therefore not accomplishing any of them. The business problem should answer questions about the current state of the product, why we created it/want to create it in the first place, and why it’s not meeting expectations.

## Step 2: Align on Business Outcomes

Business outcomes are measurable changes in human behavior and are the goals or key results you want to focus on achieving. Knowing these metrics upfront help you align on how you will define success, and can potentially impact your decision making during the solutions & hypothesis steps. These could be things like improving conversion rate by 10% or improving retention by 20%, something quantifiable that we can use to measure success later on.

## Steps 3 & 4: Understand your Users

Next, you will shift to a more customer empathetic mindset. Your product may serve more than one user type, but in order to limit your focus, it’s important to choose one user type as a group that we are focusing on improving the experience for. This is where you would re-visit or create user personas if you do not already have them defined. For your chosen persona you should also document the challenges they are having with the product or what’s preventing them from achieving the most optimal experience. Once you have clearly understood your users in step 3, you will also need to align on the outcomes & benefits you hope to deliver for these customers in step 4\. An example of a user with a corresponding outcome could be that an office manager “Stacy” who is moderately tech savvy wants to be able to more easily schedule lunches for their office employees and Stacy’s current solution is preventing them from doing this efficiently. Our outcome for the office manager would be to allow her more time back so she doesn't have to stay late that day to catch up on work and ultimately miss out on time with her family.

## Step 5: Brainstorm Solutions

The solutions category is the largest on the canvas for a reason, you should be encouraging your team to actively ideate during this phase, since ultimately that is how to best foster innovative ideas and solutions. It’s important to keep your business and user problems and outcomes in mind when brainstorming solution ideas, since ultimately they will be how you measure success. Your solutions can be as small as features or as large as new products, depending on the scope of your problems.

## Step 6: Formulate a Hypothesis

In the next section, you will take categories 2-5, and formulate a hypothesis statement with them. You will likely have multiple hypotheses, but you will need to pick the most important one to move forward with. The [Hypothesis Canvas](https://jeffgothelf.com/blog/the-hypothesis-prioritization-canvas/) is a great tool that will help you visualize which of your hypothesis statements will make the biggest impact. Using my previous example, I would create a hypothesis statement that’s something like:“We believe we can improve conversation rate by 10% if Stacy the office manager was able to order lunch for her team members more quickly rather than opt to stay late at work on days she orders lunch, with the ability to repeat a previous order.”

## Steps 7 & 8: Identify Risks and Getting Started

Once you have identified the hypothesis you will be testing, the last 2 categories (What’s the most important thing to learn first? And what’s the least amount of work you can do to learn the next important thing?) are presented as questions to help you figure out how to get started without being wasteful with your capacity. Any risks and assumptions you identify are things we will want to test first, as their outcomes could greatly impact our overall hypothesis and cause us to want to steer in another direction (fail fast) or continue to push further into our experimentation. Continuing with my hypothesis statement from above, maybe I would need to validate my assumption that users build recurring orders manually by digging into the data, or maybe I need to watch a user walk through the application to validate my assumption of where they get slowed down the most. If any of these assumptions were disproven, then I wouldn't need to spend my time building that solution and would have saved myself a ton of time and frustration.

Ultimately, the LeanUX framework is here as a tool to help you make more educated decisions, and to inspire passion for the product vision along the way, to quote _LeanUX_ one last time, remember “_The deployment of code is not the measure of success, it's the positive impact you have on your customers_”

---

[View on echobind.com](https://echobind.com/post/build-the-best-products-with-the-lean-ux-framework)

---

# How To Get Your iOS App Into TestFlight and Test It

> With TestFlight, Apple offers testing for two types of groups, internal and external. This article focuses on your internal group, which would likely be the first group to test your app.

_By David Barkman · 2022-01-20_

You’ve been working hard on your iOS app and you have the next [App Store Editor’s Pick](https://developer.apple.com/app-store/app-store-awards-2021) ready or at least some major features built and you’d like to get a second or another ten pairs of eyes on it for feedback, testing, and to make sure you’re not the only person who finds it useful. If you’re going to make Editor’s Pick, after all, broad usefulness is key! You’re new to Xcode though and you’ve heard horror stories about certificates, keys, provisioning profiles, and just how Xcode can be so daunting on its own. In the old days, before Apple added the [Automatically Manage Signing](https://developer.apple.com/support/code-signing) option to Xcode, it was definitely more work and I followed my fair share of tutorials to understand the process.

With [TestFlight](https://developer.apple.com/testflight), Apple offers testing for two types of groups, internal and external. This article focuses on your internal group, which would likely be the first group to test your app. Internal testers should be people you know since you are actually adding them to your App Store account. External testers will be people from the public you solicit to test, but may not necessarily know. They’ll be added to a different group and will not have access to your App Store account, just the app through TestFlight. Also external testing requires a limited review by Apple before you can publish to that group, internal testing requires no review. Finally, internal is limited to 100 testers, while external can be up to 10,000 testers.

Even though the process is much easier, it still requires many steps and you may still hit a few speed bumps along the way. With this article, I’ll lay out step by step how to get your new app out of Xcode and into AppStoreConnect for internal testing. I’ve included screenshots and descriptions for pretty much every step so you’re not left wondering what comes next, at any point.

Finally, this article is focused on iOS native development with Xcode. At Echobind, we also build mobile apps using [React Native](https://reactnative.dev/). With React Native, you’re able to build an app once, in [JavaScript](https://www.javascript.com/) or [TypeScript](https://www.typescriptlang.org/) and then publish to both Apple’s App Store and Google’s Play Store. React Native also gives you the ability to bridge over to Swift for complex functions needing to get closer to the device’s hardware.

## 1\. Developer Account

The most foundational step to getting into TestFlight is your Apple developer account. If you don’t already have an account, go to [https://developer.apple.com](https://developer.apple.com/) and sign up. Go ahead, I’ll wait here.

A quick note about Apple Developer accounts. It will cost you $100 US per year. In my mind, this is completely worth it. First, Apple provides for free an outstanding IDE in Xcode, most developers barely even scratch the surface of its capabilities. Second, they provide a platform to distribute and sell your apps, marketing within the store for the best apps, read good quality and useful apps and not those who paid to be upfront. Finally, they provide plenty of reports and data to help you manage your app development business. Oh yeah, also a robust testing platform in TestFlight!

Ok, developer account in hand, now where to put it. Follow these steps:

* Open Xcode preferences by clicking on the **Xcode** menu in the top left and click **Preferences** or simply press ⌘, (command + comma).
* Click on the second tab, **Accounts**
* Click the + (plus) button in the bottom left

![](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872444/echobind_blog/vli1g4l7fj2rto9mpwfj.png)

* Select **Apple ID**
* Click **Continue**
* Enter the Apple ID and Password for your Apple Developer account
* Click **Next**

Your accounts tab should now look something like this:

![](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872444/echobind_blog/ld7yggsmiwovtprivy5l.png)

## 2\. Set your version and build number

Every archive uploaded to the App Store needs a unique version and build number combination. My practice is to only change the version when I’m doing an actual, production release to the public. Between each production release though, I might upload many updates to TestFlight and those are tracked with build numbers.

Xcode starts you with version 1.0 and build 1\. These are perfectly acceptable, although I add a bit more information to my build number. I set the build number to the date I uploaded it, in this format: YYYYMMDD plus an increment in case I upload more than one build per day. If I uploaded one today, my first upload would have a build number of 2022011801, I’d then increment the ending 01 portion if I uploaded any more builds today, then tomorrow, reset back to 01.

For version, there are many schemes used to version software, the most popular being [Semantic Versioning](https://www.geeksforgeeks.org/introduction-semantic-versioning) or SemVer. SemVer uses three components in the version number, Major.Minor.Patch. Your first release could be 1.0.0 and then your next version after fixing a bug could be 1.0.1\. If you add a new, useful feature, you might set your version to 1.1.0 and so on. Here at EchoBind, we also follow the SemVer standard. For your first release, I recommend setting it to 1.0.0.

You can set the version and build numbers within the **Targets** settings, **General** tab:

![](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872444/echobind_blog/zg2upil8oatjiwnft9le.png)

## 3\. Create an Archive

Now that your developer account is setup and your build number and version are in place, you can upload to the App Store. The next major step is to create an Archive of your app to be uploaded, do this by following these steps:

* In the toolbar, where you normally select your real device or a simulator, either select a real device or select: **Any iOS Device (arm64)**. If you have a simulator selected, you can’t archive.

![](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872444/echobind_blog/ceojdy2gbgbkedowjxwi.png)

* Click **Product** at the top, to open the Product menu

![](https://res.cloudinary.com/echobind/image/upload/f_auto, dpr_auto/v1661872444/echobind_blog/t9etkzhb4zemd3ffdd2j.png)

* Click **Archive** (if Archive is grayed out, make sure you don’t have a simulator selected in the toolbar)

You’ll see a few different status messages in the toolbar and once complete, the **Organizer** window will appear.

![](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872444/echobind_blog/m42rje4jwgxppknjrlhl.png)

## 4\. Distribute App

In the Organizer main list of Archives, you’ll see the archive you just created. The date should be today’s date and the **Version** column should show the version number and build number in parentheses. Select that archive and click the **Distribute App** button.

For the next set of screens, I almost always go with the defaults. As you build more advanced apps or integrate different CI/CD methods, these might change. For your first upload though, the defaults should work fine. We’ll show each screen below with the default selected:

* For **Select a method of distribution**, select **App Store Connect** and click **Next**

![](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872444/echobind_blog/nldzzt09sgi1sqroqya0.png)

* For **Select a destination**, select **Upload** and click **Next**

![](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872444/echobind_blog/hk3cvvb00lo4h3nd0pbl.png)

* For **Preparing app record**, you will only see this screen the very first time you’re uploading your build. Everything on this screen should be what you selected when you first created your app in Xcode. If everything looks correct, click **Next**.

![](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872444/echobind_blog/bfp2yfquvkn4vdrglck7.png)

* For **App Store Connect distribution options**, leave the three options checked and click **Next**

![](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872444/echobind_blog/lm0fuhmc9fte8izplsmg.png)

* For **Re-sign “_your\_app\_name\_here_”**, select **Automatically manage signing** and click **Next**

![](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872444/echobind_blog/dehyhegs7eita9mwgxxy.png)

* For **Review _your\_app\_name\_here_.ipa content**, have a brief look and make sure something doesn’t stand out as weird or look completely wrong. If you took the defaults, everything here should be fine, it’s ok if you don’t yet know what some of this is. If nothing looks terribly out of place, click **Upload**.

![](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872444/echobind_blog/nxy7xrpz4hhtzczudky3.png)

Several messages will be displayed and this process will run for several seconds. If everything went well, you’ll be presented with a nice, big, green check mark.

* Click **Done** to close this window and you can also close the **Organizer** window.

![](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872444/echobind_blog/dpsjmmyaiiro24utwodc.png)

Take a break, refill your drink and do half a dance, you’re about half way through the process.

## 5\. App Store Connect, Users

While App Store Connect is processing your upload, let’s setup your testing team. Perform the following steps:

* Open your browser and go to [http://appstoreconnect.apple.com](http://appstoreconnect.apple.com/)
* Login with the account you created earlier
* Click **Users and Access**

![](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872444/echobind_blog/nshydmz2gmirv0nslx89.png)

* Click the blue + (plus) button at the top of the list

![](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872444/echobind_blog/u7riarzfjmj9hkapa9x8.png)

* Enter your tester’s First Name, Last Name and Email
* Check **Developer** to give them enough access to download and test your app
* Under **Apps**, either select the specific app you want this user to test or select All Apps so they can test any apps you upload.
* For the **Additional Resources** section, I usually leave those blank.
* Click **Invite**

![](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872444/echobind_blog/cbyegjzfolmswnw8k38z.png)

Your tester will receive an email invite they’ll need to respond to before you can assign them in TestFlight.

Repeat the above steps for any other testers you need to setup.

## 6\. TestFlight Test Team

If you’re still on the **Users and Access** screen, click **App Store Connect** in the top left, then click **My Apps.**

![](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872445/echobind_blog/vrvuiryzzhjwqk0ueaaz.png)

Your new app should be listed on the next screen with the weird, wireframe logo, we’ll fix that too.

* Click on your app and then click **TestFlight** tab

If your build is not displayed, it is processing in the background and may take some time to show up. You will receive an email once your build is processed and at that point your build should appear.

![](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872446/echobind_blog/jeipxtfs1pcp263u3dn7.png)

In the meantime, let’s setup your test team. Perform the following steps:

* Still in the TestFlight tab, click the blue + (plus) next to **Internal Testing**
* In the **Create New Internal Group** window, give your test team a name. I recommend leaving **Enable automatic distribution** checked, that way your test team will be automatically emailed as soon as you release a new build for testing.

![](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872445/echobind_blog/apexvvw552uomi8aibzu.png)

You’ll now have a section of the page titled **Testers (0)**.

* Click the blue + (plus) next to that title and select from your list of testers.

![](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872445/echobind_blog/udzahhgww21hqdxpsbtx.png)

* Click **Add** and you’ll be returned to the TestFlight screen with your selected testers displayed.

![](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872444/echobind_blog/kat37xkdvugn6ciugycc.png)

NOTE: Testers must accept the initial invite before they can be added here. Once you add them here, they’ll receive another email inviting them to test the app. Testers must then install the TestFlight app on the device that is assigned to the email they gave you for their testing account.

## 7\. TestFlight, finally!

If you’ve made it this far, give yourself a pat on the back, I promise this gets easier after you’ve done it a few times.

Once you’re logged into App Store Connect, click on your app and then click on TestFlight.

Your processed build will appear under the Version you set before creating the archive, **Version 1.0** in my case. In the **Status** column, it should say ⚠️ **Missing Compliance Manage.**

* Click **Manage**

![](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872446/echobind_blog/jeipxtfs1pcp263u3dn7.png)

This next section you’ll have to answer for yourself, because it’s dependent on how you coded your app. My app doesn’t use any encryption or make calls to an **https** domain, so I’m selecting **No**.

![](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872445/echobind_blog/bho1jnaa1oylwi49e5om.png)

If you select **No** here, the button **Start Internal Testing** will turn blue. Click that button and voilà, you’ve made it! The testers you setup previously should now be receiving emails, inviting them to accept and start testing your app.

If you selected **Yes** above, you’ll have a few more screens to review. Read through them carefully, they’re mostly self-explanatory. Apple provides some good guidance [here for export compliance](https://help.apple.com/app-store-connect/#/dev88f5c7bf9). Also, if you’re based in the US, you can review the [US Department of Commerce information here](https://www.bis.doc.gov/index.php/documents/regulations-docs/445-category-5-part-2-information-security), concerning software exports outside of the US. Once you get to the last screen, you’ll have the blue **Start Internal Testing** button. Click that and your testers will be notified!

## 8\. Testing

The easiest way for a tester to get access to the app is to:

* Install TestFlight from the App Store
* Open their email on the device and look for the app invite email
* Tap on the highlighted **TestFlight** word in their email and TestFlight should open, giving the tester the option to install your app.

## 9\. Bonus, fix the wireframe icon

![](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872445/echobind_blog/gjzl4rvzwcq0h9tqejul.png)

Until you submit your app for review, you won’t have a reason to choose a build for submission, but this is actually the step that also adds your icon throughout App Store Connect. You’ll choose a newer build once you’re ready to submit to the App Store, but in the meantime, this will just make things look nicer.

* Click on the **App Store** tab at the top and scroll down to **Build**
* Click the **Select a build before you submit your app** button and choose any recent build that already has your icon.

![](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872445/echobind_blog/uirhkujxt993b9ssjikh.png)

The **Build** section should then look like this. It might take a few minutes to show up everywhere, logging out and back in should do the trick if your icon is still not showing up.

![](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872445/echobind_blog/iqrvpzzbblghmjh8wozp.png)

## Summary

Good testing makes for a good app and a good experience for your users. Take the time in your app development process to test thoroughly and solicit testing help from others. If you’re looking for internal testers, hit up your friends, family and coworkers. Once you’re ready for external testing, post across social media or look for established online groups that your app would target and ask for help within their forums. Most people are excited to be an early tester of a new app and are happy to report bugs and give feedback.

The process outlined above will get a long way down your development path. At some point, once your app grows or you’re producing multiple apps, you may want to implement a full Continuous Integration / Continuous Deployment scheme to automate the above process. Here at Echobind, we’ve established an automated build process to save time, reduce errors and deploy changes faster (more about that on [our React Native capabilities page](/services/react-native-app-development)).

If this tutorial helped you or if you get stuck anywhere in this process, post in the comments below and I’ll try to help out. If you get an error along the way, search for the error online, in all the usual places, and you’ll likely find the answer, that’s how I’ve gotten this far myself!

Thank you for taking the time to read through this, I hope it helps you as much as the earlier tutorials helped me!

***Learn more about our [React Native capabilities](/capabilities/react-native-app-development).***

---

[View on echobind.com](https://echobind.com/post/how-to-get-your-ios-app-into-testflight-and-test-it-for-xcode-13)

---

# Creating Custom Icon Fonts in React Native and Expo

> Icons are a common UI element used to provide visual information and cues to users of what an element represents.

_By Alex Silcox · 2022-01-17_

Icons are a common UI element used to provide visual information and cues to users of what an element represents. In [React Native](https://reactnative.dev/) apps, we’re given a number of options when it comes to free and open-source icon sets to apply to our projects, such as [FontAwesome](https://fontawesome.com/), [Google Material Community Icons](https://materialdesignicons.com/), [Ionicons](https://ionic.io/ionicons), and more. While there are countless options for us pre-packaged, sometimes the options available don’t fit the design or a design system introduces a custom icon set just for the project. So what are our options then?

Generally, there are two routes developers take. The most common route is to create these icons via SVGs. While this is a popular solution, this could be cumbersome to set up and difficult to maintain if the custom icon set grows in time. Most of the time SVGs are handled as an individual component. Icon fonts are still a great choice for large-scale custom icon sets to scale over time. They:

* Automatically scale.
* Can be referenced directly from the same Icon component, making them accessible with all of those icon sets into the same package.
* Are hosted in a single file locally or on a CDN and you can easily choose any icon to display using the corresponding class or code (or Glyphmap).

Of course, icon fonts do have their limitations such as:

* Icon fonts don’t support multiple colors. An icon can only be styled one color at a time.
* Limited animations. Unlike SVGs, where each path or element can be animated individually, icon fonts cannot be treated the same way because they are not vectors.

If icon fonts fit your needs, fortunately for us [react-native-vector-icons](https://github.com/oblador/react-native-vector-icons) already provide an easy way to create custom icon sets. So let us get started:

## The tools you’ll need:

* **React Native Vector Icons** — If you’re using Expo (managed or bare workflow), you can utilize the Expo wrapper for react-native-vector-icons <https://docs.expo.dev/guides/icons/?redirected#createiconset>. Otherwise install react-native-vector-icons directly: <https://github.com/oblador/react-native-vector-icons#custom-fonts>)
* **Nucleo Icon Manager** <https://nucleoapp.com/> (Free desktop app for Mac/Windows) — For this article, I chose to utilize Nucleo Icon Manager app. There are other popular SaaS SVG and icon managers (both desktop and web) to choose from such as [Fontello](https://fontello.com/) and [Icomoon](https://icomoon.io/app/#/select). However, these have their own configurations with React Native Vector Icons, and for this article, I wanted to focus on how to convert SVGs to icon fonts without these SaaS.
* For demo purposes, I’ll be using the [Helium](http://tympanus.net/codrops/2014/10/10/freebie-helium-icon-set/) SVGs to convert to icon fonts, but you may wish to use any custom SVGs of your choosing.

## Setting up your project

For this example we are using the Expo workflow, Expo already bundles a wrapper around `react-native-vector-icons` in the `[@expo/vector-icons package]`(<https://docs.expo.dev/guides/icons/>). You just need to import the modules directly into your projects like so in the root file:

```javascript
// App.tsx
import { createIconSet } from '@expo/vector-icons';
```

For projects not built with Expo, you can still follow along and install the `react-native-vector-icons` the package is as you would expect for a React Native app:

`$ yarn add react-native-vector-icons`

## Generating Icons with Nucleo

With `@expo/vector-icons` set up in your project, you are ready to bring in your custom icons.

With Nucleo installed and opened, we’ll want to create a new icon set by importing our Helium icons (linked [above](https://www.notion.so/Creating-Custom-Icon-Fonts-in-React-Native-and-Expo-cdd2a4faf5624844a874c36c306ac920)). To create a new set, click the ‘import icons’ button in the top left, or right-click on the left panel > New Set. Another option is to drag your icons over the app (keep in mind you can only import SVG files, all other formats will be ignored). Name the new set and save “Create New Set”.

![Import icons modal](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/fkxlsj2mseyxumlxtlyr.jpg)

_Importing the Helium icon set_

Once all of your icons are imported to the Nucleo app you can select them and “Export” the font file (note that the screenshot below it shows the number of selected icons to the left of the highlighted “Export” button):

![Icons in Visual Studio Code](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/kprt0pewtjtohu3vulzg.png)

Nucleo allows you multiple methods of exporting. Select “Icon Font” and configure as needed for the outputted font, including any metadata about our custom font. When you’re happy with it, choose “Export Icons”.

![Export icons modal](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/tozoxmdcajdmtqd0ktyf.png)

Once exported in this new directory, you’ll be provided with several outputted files and folders. You will want to locate the `unicodesMap.json` in the root directory, and `Helium.ttf` inside the fonts directory. Copy these files and locate them to your React Native project codebase, typically within an `assets` directory.

## Using the custom icon font

When importing custom fonts in Expo, it is recommended to make sure your font is loaded before rendering. You can use the `useFonts` hook (or [Fonts.loadAsync ](https://docs.expo.dev/guides/using-custom-fonts/#using--fontloadasync--instead-of-the)for class-based components) before rendering the component. Below is a simple example of importing our fonts into our app.

```javascript
// App.tsx

import React from 'react';
import { Text, View } from 'react-native';
import AppLoading from 'expo-app-loading';
import { useFonts } from 'expo-font';

//If importing icon set directly into App.tsx
import { createIconSet } from '@expo/vector-icons';
const Icon = createIconSet(glyphMap, 'Helium', 'helium.ttf');

import glyphMap from './assets/fonts/unicodesMap.json';

export default props => {
  let [fontsLoaded] = useFonts({
    'Helium': require('./assets/fonts/Helium.ttf')
  });

  if (!fontsLoaded) {
    return <AppLoading />;
  } else {
    return (
      <View style={{ flex: 1, justifyContent: 'center', alignItems: 'center' }}>
       {Object.keys(glyphMap).map((icon, i) => (
        <>
        <Icon  name={icon} size={50} />
        <Text>{icon}</Text>
        </>
       ))}
      </View>
    );
  }
};
```

It’s also very easy to move Icon as its own component. Since the `createIconSet` method returns a React component, we can just export it as default in its own directory and file. The Icon component in turn inherits props from `vector-icons` so you can adjust each Icons color, size, and styling.

```javascript
// ./components/Icon.tsx

import { createIconSet } from '@expo/vector-icons';
import glyphMap from '../assets/fonts/unicodesMap.json';

export default createIconSet(glyphMap, 'Helium', 'Helium.ttf');
```

Then in our `App.js` file, replace the variable we created earlier with our imported Icon component:

```javascript
// App.tsx

// If importing directly into App.tsx
// import { createIconSet } from '@expo/vector-icons';
// const Icon = createIconSet(glyphMap, 'Helium', 'helium.ttf');

import Icon from './components/Icon'

...
```

And that should be it! You should be able to load your app and see your new icons. Easy peasy!

![Heart, thumb down and up icons in browser](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/hrv6j2nidckvvijbpr9n.png)

You can find an example of the tutorial [here](https://snack.expo.dev/@sparklefaeriecoder/custom-icon-fonts) for further reference and experiment more with custom Icon fonts.

***Learn more about our [React Native capabilities](/capabilities/react-native-app-development).***

---

[View on echobind.com](https://echobind.com/post/creating-custom-icon-fonts-in-react-native-and-expo)

---

# SectionedFetchRequest, sweet, sweet automagic goodness!

> From time to time though, you come across a function that substantially makes the world a better place. SectionedFetchRequest, new this year for SwiftUI 3, is just such a function.

_By Echobind Team · 2022-01-07_

Every good language API includes functions made to help you in some way, write less code, manage tedious tasks, process thousands of records in milliseconds and other, generally useful features. From time to time though, you come across a function that substantially makes the world a better place. [SectionedFetchRequest](https://developer.apple.com/documentation/swiftui/sectionedfetchrequest), new this year for [SwiftUI 3](https://developer.apple.com/xcode/swiftui/), is just such a function.

## Background

I recently worked on an app listing daily activities I was tracking. I wanted to group those activities by day, to make the UI look a little nicer and make it easier to find activities from a certain day. For this app, each row in the UI was made up of one or more records from the database, so I couldn’t easily group them with a standard List component. In order to build a grouped-by-day view, I had to write an algorithm that built a multidimensional array for the [SwiftUI List component](https://developer.apple.com/documentation/swiftui/list) to consume and display my grouped list. The code for the algorithm was over 100 lines long and included SwiftUI components since as part of the list, I was also including the view that would be navigated to when tapping on the row. I later refactored some of the view code into a separate view, but still had to manage a representation of the view in the algorithm. This refactor saved a few lines of code, but didn’t change the overall structure, the same decisions still had to be made to create the same multidimensional array.

### After much searching and reading Stack Overflow answers…

Using the algorithm and multidimensional array worked, but I didn’t have a tight connection to the database. This app is also connected to [iCloud](https://developer.apple.com/icloud/cloudkit/), more automagic to be covered in a future post, so incoming changes couldn’t be displayed until the user refreshed the view manually. This clumsy connection to the database started to manifest in other bugs and I knew this wasn’t a good solution. After much searching and answer reading on [Stack Overflow](https://stackoverflow.com/a/67923054/543844), I stumbled on SectionedFetchRequest. The clouds parted and sunbeams shown to illuminate this gem of a function, ahem, once I read all the documentation and saw how it was used in a [sample project](https://developer.apple.com/documentation/coredata/loading%5Fand%5Fdisplaying%5Fa%5Flarge%5Fdata%5Ffeed)!

![Man standing with arms out during sunset](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/xetfuqthfa5qiw7km4h9.jpg)

### Voilà!

With a new column in my Records table and three new lines of code, and over 100 fewer lines of old code, I was able to implement a grouped view that was very tightly connected to the database. iCloud updates would propagate to the Core Data database and the view would immediately update, without any user interaction, showing the new data!

This line is part of creating a record object that populates the CreatedDay field for an activity record:

```javascript
recordObject.createdDay = currentDateTime!.formatted(date: .abbreviated, time: .omitted)
```

These two lines of code set up the “Sectioned” Fetch Request and the “Sectioned” Fetch Result consumed by the List component:

```javascript
@SectionedFetchRequest(sectionIdentifier: \\\\.createdDay, sortDescriptors: [SortDescriptor(\\\\.createdDay, order: .reverse), SortDescriptor(\\\\.fieldOrder, order: .forward)], animation: .default)
private var records: SectionedFetchResults<String?, Records>
```

In the above code, I specified the section identifier as _createdDay_, and sorted by _createdDay_ in reverse order to show the most recent records first. I also included a second sort field, _fieldOrder_, to control how records are shown in the detail view, more of a good example of using multiple sortDescriptors. The second line is the result, [SectionedFetchResults](https://developer.apple.com/documentation/swiftui/sectionedfetchresults) with the results still in a multidimensional array, but not one I had to build.

Using the SectionedFetchResults (records) (not new code):

```javascript
List(records) { section in
  Section(header: Text(section.id!)) {
    ForEach(section) { record in
```

### Show me more!

Apple has provided a sample app, downloadable from here: <https://developer.apple.com/documentation/coredata/loading%5Fand%5Fdisplaying%5Fa%5Flarge%5Fdata%5Ffeed>, that includes a good example of SectionedFetchRequest and SectionedFetchResults, in addition to some other good gems. Open this project in Xcode and search for SectionedFetchRequest to see how it’s being used. For Apple’s official developer documentation on SectionedFetchRequest, [check here](https://developer.apple.com/documentation/swiftui/sectionedfetchrequest) and for SectionedFetchResults [go here](https://developer.apple.com/documentation/swiftui/sectionedfetchresults).

This is just one of many nuggets in SwiftUI. I’ll be back here soon to share more as well as other Swift and SwiftUI goodness like iCloud integration. What golden nuggets of goodness have you found in SwiftUI or Swift. Let’s continue the conversation in the comments below.

---

[View on echobind.com](https://echobind.com/post/sectionedfetchrequest-sweet-sweet-automagic-goodness)

---

# Achieving Work-Life Balance in the Technology Industry

> Dec 13, 2021 | Echobind is on a mission to create a remote work environment that invests in its employees and contractors through investment time.

_By Alexis Mathews · 2021-12-13_

The balance between work and life within the technology industry oftentimes falls heavily toward more work than life. This leads to burnout, decreased productivity, and oftentimes a complete departure from the industry as a whole. The technology industry would benefit from striving to do better at retaining quality talent, achieving a better balance between billable hours vs. investing in employees, and finding value in employee growth and development. Achieving work-life balance in the technology industry has fallen short in recent years resulting in an overall decline in work satisfaction among contractors and employees.

Echobind is on a mission to create a remote work environment that invests in its employees and contractors through investment time. The purpose of investment time is to allow work-related growth through personal interest projects, topical research, and educational opportunities related to industry topics. This devoted time each week allows for refreshment, interest-led projects, and a break from work-related tasks to facilitate personal and professional growth opportunities. Unfortunately, investment time is available at very few technology companies.

[Matt Thompson](https://echobind.com/team/matt-thompson), a lead engineer at Echobind reflects upon his experience with investment time: “Investment time for a lot of companies tends to be an idea if anything. I was surprised to find Echobind taking personal investment seriously when I joined. As a remote consultant, in the tech industry, it is easy to burn out. Having dedicated hours each week for internal meetings and research sets strong boundaries with both your clients and personal life. The saying ‘You can’t help others until you help yourself’ comes to mind. Work isn’t defined by the number of hours, but rather the value. I tend to think of Echobind and my career goals as another client project that needs my attention each week. During this time, I’ve helped refine our processes as a company, contributed to open-source software, mentored, lead a cohort, developed course material, and much more. All of this without feeling guilty of the hours spent to do so. It is a part of my job to self-invest and in turn invest in others around me. This stacks throughout the company and our culture. At Echobind we strive for a solid work-life balance. Having investment time ensures that folks aren’t feeling the need to ‘take work home’. We provide the value for our clients, then take those learnings offline as multipliers for the next project coming in. This is a top-down initiative at Echobind. Our own CEO talks about the ideal [40-hour workweek](https://echobind.com/post/40-hours-are-optimal). The end goal is to keep our team encouraged and happy about their career. No one benefits from burnout and high turnover. I’ve seen plenty of folks completely change their careers due to imbalance. While nothing is perfect, I’m glad to be a part of a company striving to make a conscious effort.”

The conscious effort to maintain work-life balance at Echobind permeates all aspects of the company culture. Celebrations of a published ebook that came out of personal investment time, a new app that was developed from a personal interest project, or even a new code shortcut presented during a lighthearted weekly team meeting create an environment within Echobind that encourages and promotes personal growth.

Echobind UX/UI designer, [Kaila VanSume](https://echobind.com/team/kaila-vansumer)r shares, “I’ve used my investment time at Echobind for everything from reading textbooks on information architecture to exploring how to pair fonts well to writing blog posts on usability testing. As a product designer working in an agency setting, I’m often on projects where one day I’ll be working closely with the C-Suite of a company to put together a strategic UX vision for an app, and the next day I’ll be designing interactive button components for a pattern library in Figma. The work is quite varied, and my investment time allows me to explore more broadly and learn skills that make me a better designer for our clients. I never feel like I have to ‘stay in my lane’ as a designer because I don’t know how to do something. Instead, I feel free to look for ways to add more value, knowing I have time and bandwidth to learn the necessary skills to do so. I don’t come from a traditional design background, so I have some gaps in my knowledge of design practices and principles. I’ve been able to fill those gaps quickly and become more confident in my visual design skillset because I have dedicated time every week to invest in myself.”

Time every week to invest in yourself, just imagine the possibilities!

[Zack Marty](https://echobind.com/team/zack-marty), Product Manager at Echobind shares, “The first thing I worked on with my investment time was investigating some of my hunches about some client work I had. It gave me time to step back and analyze the situation, which allowed me to create [The Spaceship of Theseus](https://echobind.com/post/the-spaceship-of-theseus) blog post. I think some of the value of investment time for the strategy team is to hone and develop our arguments for certain initiatives as well as analyze the situations we are entering as contractors. As a strategist though, the most important thing I think I can develop are my soft skills.”

Developing new personal skills and growing in knowledge-based skill sets are just a few ways that investment time at Echobind allows contractors and employees to achieve work-life balance.

[Jennifer Robison](https://echobind.com/team/jenn-robison), Director of Engineering shares, “As an engineer, professional development and continual learning is imperative. If you aren’t learning you are falling behind as technology changes so rapidly. There are new frameworks, libraries, languages, and more. It can be a bit overwhelming if you are already working 40+ hours per week on a specific project, and then you are trying to use more cognitive space to learn something new or even to work towards improving, or automating, something you do on a regular basis. At Echobind, we give our employees investment time every week, which falls WITHIN their 40 hours. In my career this is only the second team where this was an opportunity, most companies expect you to continue to grow but on your own time. During our investment time, you can explore areas that you are not familiar with, maybe you are primarily a front-end developer, you could focus on getting up to speed with backend development, maybe with a goal of GraphQL for example. An example of investment time for myself was getting very deep with E2E (End to End) testing with Detox for React Native which led to several conference talks and a webinar presentation. Not only did that help my technical skills, but also my communication and presentation skills. The outreach and interaction with the community is a huge plus.”

Weekly investment time for all of our employees facilitates not only employee growth and development but also company growth as a whole. Technology agencies succeed when the team as a whole is succeeding. Investment time is just one of the ways that Echobind ensures employee and agency-wide growth over both the short and long term.

[Mike Cavaliere](https://echobind.com/team/mike-cavaliere), Senior Engineering Strategist adds, “[Investment time](https://echobind.com/post/the-roi-of-self-directed-investment-time-for-software-engineers) allows us to get better at what we do, outside of the constraints of what projects we’re able to work on day to day. We also get to work on what we want to learn, as opposed to what we get to learn over the course of a project. Investment time is more targeted than learning via projects (which is still great); meaning I might be great at React since I use it on client projects, but I can get better at a specific aspect of React that may not have happened on a previous client project (BUT it might come up in a future one). Investment time gives us the ability to work on skills that aren’t part of our core job description, but are great for our careers such as presenting, writing, or skillsets for completely different directions.” Cavaliere’s investment time accomplishments include his [Cut into the Jamstack book](https://www.cutintothejamstack.com/), [blog posts](https://echobind.com/team/mike-cavaliere), [an emoji battle game](https://github.com/mcavaliere/emoji-battle), and various book analyses.

Echobind invests in its fully remote team. Want to learn more and explore our current open opportunities? [Get to know us and explore our agency culture](https://echobind.com/culture).

---

[View on echobind.com](https://echobind.com/post/achieving-work-life-balance-in-the-technology-industry)

---

# Binary trees, what are they?

> Nov 29, 2021 | A binary entails anything that is related to or involves two parts

_By Usman Ibrahim · 2021-11-29_

![Large tree](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/qt0y2bmbcmkkxunbxnng.jpg)

I can still recall my introduction to the “Binary Tree’’ as a data structure; the peculiarity of its name sprung an immediate interest in me. Nonetheless, I began personal research and was quickly unmotivated due to the density of the material at the time. Thus, I searched for and discovered alternative ways to master content on this subject.

Before I continue a discussion on Binary Tree’s, I’d like to define the key terms necessary for its understanding.

### **Branch**

A part of a tree that grows out from the trunk or another branch.

### **Node**

Put simply, A node is the beginning or the ending of a branch in a tree. I.e a node connects different branches of a tree. Nodes connect branches of a tree meaning they exist at both the end and beginning of a branch; thus, with every node, there is at least one branch.

### **Root Node**

The root of a tree is the foundation of the tree. Understood as the origin or starting point, all other parts of the tree (nodes through branches) emerge from it. Fundamentally, the root node is unique and has no branching leading to it.

### **Child Node**

A child node is a node that descends from another node through a branch. Two nodes that descend from the same node are called sibling nodes.

### **Parent Node**

A parent node is a node that has other nodes on its branches. The root node of a tree, for example, is a parent of the immediate nodes that branch out of it!.

### **Leaf Node**

A leaf node is a terminal node having no further branches or nodes emerging from it. If the root node is the head of a tree, leaf nodes are the tail ends of the tree.

### **Binary**

When we hear the word binary, the number two comes to mind. That is, a binary entails anything that is related to or involves two parts. Simply, a binary entity can assume only either of any two options. Examples of binary options include: True or False, Yes or No, and 0 or 1.

Okay, enough talk about nodes, look at the beautiful tree picture below, can you identify all the terms defined above?. I now want you to make an educated guess on what you think a binary tree is, before reading the next paragraph.

![Skinny tree](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/uonetze6psuwyhutnqxt.jpg)

**Fig 1: Real Binary Tree**

## **Binary Tree**

As you might have guessed, A binary tree is a tree with a maximum of two child nodes for each parent node. A binary tree is also a non-linear data structure where each node represents an element, that encloses some value and references at most two child nodes. We have a tree structure in Fig 2 that depicts our real binary tree when viewed upside down.

![Multiple drawings of a face depicting a binary tree](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/t9a1sbmmmvzs7bb3uioa.jpg)

### **Types of a binary tree**

Having established that any parent node can only have a maximum of two child nodes; there are various types of binary trees. Often distinguished by either the number of child nodes or the arrangement of the nodes in the tree.

#### **Full Binary Tree**

A full binary tree is a type of binary tree in which each node has an even number of nodes. And since a parent node can have at most two child nodes, the number of child nodes of a full binary tree can only be zero or two. A full binary tree is depicted in Fig. 3.

![Multiple drawings of a face depicting a binary tree](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/vu1vyejconmihkqwgeoe.jpg)

#### **Complete Binary Tree**

A complete binary tree is a tree in which each level is filled with nodes while descending the tree except possibly the lowest level. The leaf nodes fill the lowest level from the left. In addition, a leaf node may not always have the right sibling. Fig. 4 shows a complete binary tree example.

![Multiple drawings of a face depicting a binary tree](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/rv8psbz9ofuc5rmjbsrx.jpg)

#### **Perfect Binary Tree**

All nodes in a perfect binary tree have exactly two children and all the leaf nodes in the tree are on the same level. The first **Binary tree Data Structure** image posted above describes a perfect binary tree.

#### **Binary Search Tree**

A binary Search tree is a special type of tree data structure that can come in the form of any of the above binary trees. The binary search tree’s uniqueness is that the nodes on its left have lesser values than the nodes on its right. All three images shown above are examples of binary search trees. This uniqueness makes it one of the most powerful data structures in computer science; thus, the rest of this article will be centered around why the Binary **Search Tree**.

## **Binary Tree Operations**

### **The Insert Operation**

The insert operation is the process of adding new nodes to a binary tree. The algorithm looks for the best available branch in the tree to insert a new node while maintaining the fundamental characteristics of a binary search tree; i.e, the left of the tree containing nodes of lesser value to that of its right.

The time complexity of the insert operation O(h) where h is the height of the tree.

### **Look Up Operation**

The look Up operation as the name implies entails checking if a node exists in a tree.

Remember the binary tree’s fundamental property? Well, the algorithm of a look-up operation can skip all nodes to the left or the right of the tree: this depends on whether the value of the node is greater or less than the value we are looking for. The look-up operation in a binary tree is very efficient in that we won’t have to go through each item in the tree during a look-up operation. The best-case time complexity of a lookup operation is O(log N) where N is the number of nodes in the tree.

### **Delete/Remove Operation**

This is the process of deleting a node from a Binary Search Tree While also ensuring that the binary tree remains balanced.

When A Parent node is deleted from a Binary Search Tree, its child nodes are rearranged and attached to a new parent in such a way that the tree still retains all its unique properties. The best time complexity of a remove/ delete operation is O(log N) where N is the number of nodes in the tree.

### **Breadth-First Search**

This is the process of traversing or iterating through each of the nodes of a Binary Search tree.

It starts at the root of the tree and explores next-level nodes from left to right or right to left. This process continues until the root of the tree is reached and all nodes have been interacted with. The time complexity of a Breadth-first search operation is O(N) where N is the number of nodes in the tree.

### **Dept First Search**

This is the process of traversing a tree to its deepest node. I.e when a node is visited, it is traversed to its leaf node before traversing a sibling node. There are 3 common methods in which this algorithm can be achieved.

### **Dept First Search In Order Traversal**

We will recursively traverse the left subtree for every node (n) starting from the root node, then we process (n) itself after all its left node has been processed before moving to the right nodes then repeat the same process.

In this type of traversal, the leftmost leaf node will be processed first why the rightmost leaf node will be processed last. The time complexity of inorder traversal is O(N) where N is the number of nodes in the tree.

### **Dept First Search Pre Order Traversal**

For every node (n) starting from the root node, we will process (n), then recursively traverse the left subtree of (n), before moving to the right nodes and repeating the same process.

In this type of traversal, the root node will be processed first why the rightmost leaf node will be processed last. The time complexity of preorder traversal is O(N) where (N) is the number of nodes in the tree.

### **Dept First Search Post Order Traversal**

We will recursively traverse the left subtree for every node (n) starting from the root node. Then, we recursively process the right subtree of (n) before processing (n).

In this type of traversal, the leftmost leaf node will be processed first while the root node will be processed last. The time complexity of post-order traversal is O(N) where (N) is the number of nodes in the tree.

## Advantages of Binary Search Tree

1. We can keep the time complexity of insertion, deletion, and lookup operations to O(log N) which can be very efficient for large data volumes.
2. It is good for storing hierarchical data.
3. It can be used to store large data volumes.
4. It helps maintain a sorted data set.
5. It can be used to implement various search algorithms.

## **Disadvantages of Binary Search Tree**

1. The major disadvantage of binary search trees is that we have to maintain the balance of the tree for its accuracy.

#### **Conclusion**

Here we have looked at binary trees in data structures, explored their types, operations, and benefits. Binary Trees are used for both searching and storing data. Thus, they play a key role in the study of Data Science and its applications. We will be discussing the technical implementation of the Binary Search Trees and their operations in my next post.

**Resources**

* The playground to check out the binary tree operations can be found[ here](https://freemile2ru.github.io/data-structures)

---

[View on echobind.com](https://echobind.com/post/binary-trees-what-are-they)

---

# Live-Printing Slappies for an Interactive Mural at RenderATL

> Nov 15, 2021 | RenderATL was our first in-person dev conference since the pandemic, which was initially billed with a focus on React. As React is one of the main tools we use here at Echobind, we joined as cultural sponsors for the conference.

_By Daniel Pomidor · 2021-11-15_

![Echobind RenderATL logo](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/vdupwmh19indezcwldgu.png)

[RenderATL](https://www.renderatl.com/) was our first in-person dev conference since the pandemic, which was initially billed with a focus on React. As React is one of the main tools we use here at Echobind, we joined as cultural sponsors for the conference.

## The Brief

This presented a unique challenge of creating a physical booth at an event that’s largely about coding and black representation. How do we go about representing the culture — both of the conference and of the city itself?

To get started, it was important to really break down a few of the goals of the booth as cultural sponsors:

* Embrace Atlanta culture and black representation in a positive way
* Facilitate interaction with other conference attendees
* Leave a mark — interact with the booth itself

Additionally, we had a few internal goals for the booth — namely:

* Recruit new hires
* Generate new business
* Meet new, like-minded folks

As we talked more about it internally, it was mentioned that Chris Ball, our CTO, had really enjoyed the signing wall at a different conference that he knew the organizers from and so we planned to create a similar experience to that.

## Designing for Space

Initially, Alex Patrón (Echobind’s Creative Director) and I tossed back and forth several ideas for generative art — we weren’t sure how much bandwidth we’d have from the dev team to develop something for the conference, but we were working with what we knew: video art & synthesis, old Processing sketches, Unity 3D, and so on — planning to do projection art.

A screenshot of the inspiration board — including generative art, generative design, the Poooli printer, and video synthesis for Unity 3D and analog video

![A screenshot of the inspiration board — including generative art, generative design, the Poooli printer, and video synthesis for Unity 3D and analog video](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/avto3gfsihvzdddpjndj.png)

As the conference grew closer, we learned that the booth was going to be outside and in a more limited footprint than we’d initially planned. Eventually, we got access to the area the booth was going to be in, and from there we tried to carefully plan something that would be able to withstand any elements.

![Schematic for the small 4' x 3' footprint we’d be occupying with our booth — smaller than the wall we thought we might have](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/yekoa3ieukenwlnodgdm.png)

Schematic for the small 4' x 3' footprint we’d be occupying with our booth — smaller than the wall we thought we might have

We landed on using a standing banner as our interactive piece — on one side, we’d have a mural by a local Atlanta artist ([Faatimah Stevens](https://www.instagram.com/thepainterbae/?hl=en)). For the sake of speed and efficiency, we had them send us a “digital mural” — a piece they created using digital painting and typography — and printed that on the banner.

![Faatimah Stevens’ mural, recommended to us by RenderATL as a local artist.](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/rd2ywt0ieo8rz3bwbmxu.jpg)

Faatimah Stevens’ mural, recommended to us by RenderATL as a local artist that we could work with for the conference.

On the other side of the banner, we really tried to think of a way that attendees would be able to interact with Atlanta culture in a novel way. Initially, the idea was that attendees might sign a landmark, or the mural itself, or something we projected digitally…

## Enter: Sticker Slappies

Anyone walking around Atlanta knows about slappies — every street corner, every light post, every stop sign has a slappy on it. A slappy, in street art terminology, is usually just a sticker — but the kind small enough that the creator can innocuously slap it on nearly any surface without drawing suspicion. Perfect for signs, poles, bathrooms, windows, drive-thrus, public transit — etc.

The branding of RenderATL, as well, is in cooperation with the Trap Music Museum — they provided interior decorating (like the now-famous Money Room), attendees had Cuban-link lanyards, they had trap playlists for every day of the conference, and the branding was bright and colorful.

![RenderATL sign](https://res.cloudinary.com/echobind/image/upload/v1661872447/echobind_blog/tk47ib2hv92ytaqlqsd7.png)

Left: RenderATL’s provided branding and wallpaper. Right: The “Money Room” at RenderATL’s conference space.

Drawing from both of these things, we found a way to incorporate our interactive installation in a unique way that blended in with the spirit of the conference. Using a Poooli thermal printer, we’d take photos of attendees, put them into a cute slappy template, print them onto colorful sticker paper, and then have the attendees sign their names and where they’re from.

![Post-its](https://res.cloudinary.com/echobind/image/upload/v1661872447/echobind_blog/hqtcidi5mufw38k1spli.png)

![Echobind stickers for RenderATL](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/aur6x1hmof4ttlhfxrjk.png)

The final piece of the puzzle was having them slap the sticker “onto” an Atlanta highway bridge overlooking the downtown skyline, amongst a bunch of actual local stickers.

![Random stickers on a pole](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/i3wiq4wfp6snkc7ibb1q.jpg)

![Post-its on a board](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/oc63sla3rmxqftn8slzh.jpg)

## Where the Rubber Hits the Road

Running the booth — that’s a different ballgame. Once we got to Atlanta and started test printing photos on the banner, we realized:

* Stickers were difficult to tear in practice: we equipped ourselves with tweezers to speed things up and make it easier to peel.
* Being outside meant that the wind would sometimes hit the banner and attempt to knock it over: luckily, this didn’t happen often, but it did have to be braced and occasionally picked up.
* Stickers, thanks to humidity and the water-repellent surface of the banner, would slowly peel off: Whoever was watching the booth, would make sure to gently rub the stickers back onto the surface when they started to peel off — luckily we were moved inside the next day, which eased this.

To the right, Echobind’s booth with Faatimah’s artwork clearly visible

![Man walking by Echobind banner at the RenderATL conference.](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/ah8ttefpgb7wwhedeh37.jpg)

At our booth, we had set up:

* Stickers
* Rolls of sticker paper, so people could select their preferred color
* [The Poooli printer](https://www.poooliprint.com/)
* A 360 camera recording both sides of the booth
* An iPad with prompts to sign up for emails from us, to retain info
* Pens for signing the printouts

![Echobind’s booth talel setup with ipad, keyword, and printer.](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/mlzurfkwt4amnddnkjnw.jpg)

The booth table’s setup

Being outside had enormous benefits — as it was, outdoors was the area people could take off their masks and momentarily relax, which eased socializing. We were also set up next to a bunch of the chairs and couches, so what went from being a difficult and cramped space to plan for instead turned into a wide-open and inviting hangout area. The entire Echobind team could sit near the booth!

![Echobind employees hanging out](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/rb13f8mfburamyztmv7q.jpg)

![Echobind employees hanging out](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/zhe7ixhzbnmep0rqr8wy.jpg)

![Echobind employees hanging out](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/rid4sdsrpiatjx4jzq0e.jpg)

The flow went something like this:

* I’m standing near the booth
* Potential contacts would walk up, curious about the banner
* I’d explain the premise to them

![Echobind employee taking photo of a and creating a slappie](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/kwmnjtpjcpcqq92yupxq.jpg)

* We’d take their picture, and then print out two slappies:
1. One is for them to take home as a souvenir
2. The other is for them to put on the mural

![Echobind employees hanging out](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/pi86y3trs9ioec2bhj2f.jpg)

* Taking a photo and then laying their photo into our template, printing it out, and then peeling the sticker off the paper takes a good 3–5 minutes. In that span of time, I can ask them:
1. Where did you come from?
2. Why are you attending Render?
3. Are you looking for work?
4. Are you looking to hire Echobind?
* I could also direct them to take an additional sticker or share their email with us
* In that span of time, I could direct them over to Jenn Robison, our Director of Engineering, or to Alex, our Creative Director. They could also talk to any other available members of the team to rapidly get an idea of what the team’s culture is like.

![Jenn, working the magic with a group of attendees — background, a group of folks interested in slappies](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/ztctgxgzvzmiahc1zbgr.jpg)

Jenn, working the magic with a group of attendees — background, a group of folks interested in slappies

As you can imagine, we very rapidly became a point of contact for a lot of attendees. We also had a hiring poster behind us, so anyone waiting to get their picture taken could quickly snap a picture of our QR code to check out job listings. Several of the folks who came up were speakers themselves — [Justin Samuels](https://twitter.com/ThugDebugger), the organizer of the conference, even came through to get a photo.

![Justin, organizer of RenderATL, posing for his slappy photo](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/lbowoirgvvqskbt8o6ar.jpg)

Justin, organizer of RenderATL, posing for his slappy photo

The other thing about setting up a photo booth this way is — you have material evidence that people took pictures at your booth, which encourages everyone else to take photos too. One of the speakers even explained to us that, as a result of our booth, he would often come up to remind himself of people’s names because he could match their faces to names thanks to the slappies they left.

![Collage of slappies images on Echobind’s banner.](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/ev51tzr3m7jyachajjll.jpg)

At the end of the conference, we were left with a genuinely cool piece of interactive art that captured a lot of what the conference was like: charismatic, upbeat, cutting edge, vibrant, and genuinely fun — in a way that actually reflects the culture of Atlanta.

We thought about what we should do with it for a minute — and then we concluded that the best person to take the finished mural with them was Justin himself, the creator of RenderATL: a memento to an excellent first conference, with pictures of so many of the people who attended.

![Justin with Jenn and the completed mural, at the front of The Gathering Spot, where the conference was held](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/bqhp5bury0f5rj9a1spv.jpg)

Justin with Jenn and the completed mural, at the front of The Gathering Spot, where the conference was held

Not only was the booth a success, but the whole conference was also. Engaging with so many people, we picked up a bunch of new contacts and potential hires, put our names on a lot of people’s radars as a creative and fun agency, and we got to enjoy ourselves. RenderATL is happening again, and beyond that, it’s happening in several new cities across the country — and you can bet we’ll be there again next round.

---

[View on echobind.com](https://echobind.com/post/live-printing-slappies-for-an-interactive-mural-at-renderatl)

---

# Bison Release 1.11.0

> Nov 08, 2021 | We’re excited to ship another version of Bison that not only improves the web apps we build for our clients, but also the developer experience of working on Bison apps and contributing to the Bison template itself.

_By Kishan Gajera · 2021-11-08_

We’re excited to ship another version of [Bison](https://github.com/echobind/bisonapp) that not only improves the web apps we build for our clients, but also the developer experience of working on Bison apps and contributing to the Bison template itself.

Not familiar with Bison? It’s [Echobind’s](https://echobind.com/) starter repository for full-stack [Next.js](https://nextjs.org/) web apps. Check out the links below for more background on Bison and how to use it:

* [Overview of Bison](https://vimeo.com/447643624)
* [Creating Your Own JAMStack Blog in No Time with Next.js and Bison](https://echobind.com/post/creating-your-own-jamstack-blog-in-no-time-with-next-js-and-bison)

## Nexus and Prisma

The previous version of Bison used the [nexus prisma plugin](https://nexusjs.org/docs/plugins/prisma) developed by Nexus which allowed us to easily project fields from our prisma schema into the GraphQL API. However, that plugin will be deprecated in favor of one being [currently developed by the Prisma team](https://github.com/prisma/nexus-prisma/).

The new plugin will use generation to create the GraphQL API similar to how the Prisma Client is generated. The plugin is currently in early preview and we will look to introduce this into Bison when it’s production-ready.

In preparation for this, we’ve taken the steps to [remove the nexus prisma plugin](https://nexusjs.org/docs/plugins/prisma/removing-the-nexus-plugin-prisma) and just use plain Nexus. We’ve added [documentation](https://github.com/echobind/bisonapp/blob/canary/docs/nexus-examples.md) showing examples of how to define just about every type of field and relationship!

## Code Generation

Bison relies heavily on code generation for the GraphQL API on both the front-end and back-end. To improve developer experience, we have removed all generated files from the repository and added them to the .gitignore so they do not cause unnecessary merge conflicts.

These changes do not affect the development process. When running the development server, yarn dev, all generated files will be created and re-generated on file changes. You can also run yarn build:types to generate these files at any time.

## Upgrade to Next.js 11

After attending Next.js conf, our team was very excited about all the new features that were announced and the impact they would have for our developers and clients. Across the board, there are noticeable performance improvements that we are happy to bring into Bison. See their [release blog post](https://nextjs.org/blog/next-11) for more details.

## Upgrade to Jest 27

In upgrading to [Jest 27](https://jestjs.io/blog/2021/05/25/jest-27), it was announced that they’ve changed the default environment in which tests run. The unit tests in Bison test both client and server side code, so our tests will need access to both browser and node APIs. We’ve taken the recommend approach to default to the faster `node` environment and for tests that rely on the browser, configuring that test file specifically to run in the `jsdom` environment by adding the following docblock to the top of the file:

```html
/**
 * @jest-environment jsdom
 */

```

## Node 16

With Node 16 set to be the active LTS version starting October 26th, we’ve officially updated the CI and dev environment configuration to use version 16\. See their [release blog post](https://medium.com/the-node-js-collection/node-js-16-available-now-7f5099a97e70) for all the new features and changes.

## TypeScript

We’ve upgraded Bison to use the latest version of TypeScript, [4.4.3](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-4.html). In addition to that, we’ve also enabled the `noImplicitAny` [compiler option](https://www.typescriptlang.org/tsconfig#noImplicitAny) and refactored the codebase to be strongly typed. This will help to enforce best practices to ensure all variables are typed which results in a more maintainable codebase.

## Contributing to the Bison Template

We have a lot of improvements planned for Bison so we’ve made it much easier to contribute changes to the Bison template. Check out the new [contributing guide](https://github.com/echobind/bisonapp/blob/canary/CONTRIBUTING.md) for more information on how you can help out. Whether it’s reporting bugs, creating pull requests, or participating in discussions, all contributions are welcome!

---

[View on echobind.com](https://echobind.com/post/bison-release-1-11-0)

---

# Developing an Independent Watch App

> Oct 21, 2021 | Lessons learned and overall experience on building a watchOS independent app with SwiftUI for the interface.

_By David Barkman · 2021-10-21_

As an iOS developer, I’ve built or worked on many iOS apps, and even a few Android phone apps 🤫, but have never ventured into the tiny screen world of watch or wearable development. Recently I’ve started exploring and learning SwiftUI, which is quickly gaining traction in the Apple development community, ([read my previous article to help you decide if it’s time to learn](https://echobind.com/post/swiftui-is-it-ready)), and decided I should also add watch/wearable development to my mobile development skills. For my introduction project, I decided to mix both new technologies, SwiftUI and watchOS, because why not 😆, and build a watchOS independent app with SwiftUI for the interface. The following are lessons learned and my overall experience on the project.

## Independence for the apps!

With the release of watchOS 6 in 2019, Apple enabled developers to create independent apps for the Apple Watch. Before watchOS 6, all watch apps were dependent on an iOS companion app, installed on the paired iPhone. A dependent app relies on the iPhone companion app for its data and settings. While a dependent app can and should be able to provide useful information without its companion iPhone app, the watch app is built to rely on the iPhone app in order to be fully useful. [Independent apps](https://developer.apple.com/documentation/watchkit/creating%5Findependent%5Fwatchos%5Fapps), on the other hand, can be installed without a companion iPhone app, from the watch’s App Store app. Independent apps are able to perform tasks like downloading data, [setting up the user’s account](https://developer.apple.com/documentation/watchkit/authenticating%5Fusers%5Fon%5Fapple%5Fwatch) and configuring the app, as well as receiving notifications sent directly to the watch. For this project, I decided to build an independent app, Apple seems to be directing developers in this direction. I also thought it would be less coding, since I wouldn’t need to build a companion app. Remember less coding is fine if you’re delivering value to your client (or employer) sooner.

## 🤔 How cold will it be at 3 am?

The app I built is a simple hourly weather forecast app. The API used is [Weather API](https://www.weatherapi.com/), a robust set of APIs that offers up to 14 days of weather forecasts, weather history back to 2010, real-time weather, weather alerts, astronomy, search and sports. In case you’re as curious as I was, the Sports API allows a user to get a list of all upcoming sporting events for football ⚽️, cricket and golf, for the UK. Maybe this was a 20% project, maybe it’s because the company is based in the UK, but if it updates in near real-time, it could be used in a sports app to check for weather delays or cancelations. The API offers a free tier with up to one million calls per month included and several other affordable tiers with expanded features and more included calls.

The app itself is simply a scrolling list of forecasts, for each hour, for the next three days. If you tap on one of the rows, you’ll navigate to a detail view showing more details for that hour. Most of the data provided by the API come in imperial and metric format, I provide both for every data point available in the detail view and both for temperature in the initial list. This came out of a development decision I made mid-way through. Knowing I had the metric data, I considered creating a setting view for the user to pick metric or imperial, as well as other settings. I decided rather than add more controls to the views, then needing to “teach” the user that settings were available, I would simply show both values. Within [Apple’s Human Interface Guidelines](https://developer.apple.com/documentation/swiftui/asyncimage), they state: “Organize text, images, and controls so people can quickly and easily find the information they need and perform actions. Streamline user interactions by creating focused, space-efficient interfaces.” To go further with simplifying the experience and UI they state: “Prefer a plain black background.” Apple wants you to keep the experience simple and efficient, making sure the data provided is first and foremost for the user. By skipping the settings view, the user will only have to work with two views to get the information they came to the app for and it’s now accessible to all users worldwide, as long as they read English. 🤦‍♂️

![Earth next to an Apple watch](https://res.cloudinary.com/echobind/image/upload/v1661872447/echobind_blog/yirarkz3yavk4hzelejy.png)

## The good…

[Building an app for the watch](https://developer.apple.com/documentation/watchkit/creating%5Findependent%5Fwatchos%5Fapps/setting%5Fup%5Fa%5Fwatchos%5Fproject) wasn’t actually much different from building an iPhone or iPad app. Using SwiftUI really made the layout easier since it’s a declarative UI framework and I just had to tell it what to show, leaving how to show it up to the device. The code I wrote should be 100% portable to an iOS device. I did set some of the text layout to work better on a small screen, so it would look awkward on an iPad, but as far as compiling, I’m confident it would build and load fine on any other iOS device. As part of Swift and SwiftUI’s move to add more concurrency, I was able to use a new struct, new for watchOS 8 and iOS 15, [AsyncImage](https://developer.apple.com/documentation/swiftui/asyncimage), which allowed me to, with very little code, specify a URL for the image I wanted and a placeholder image to use until the requested image was downloaded. In the past, I would have written a service to call that would then utilize network code to fetch and return images.

Here’s the new code:

```html
AsyncImage(url: URL(string: "<https://cdn.weatherapi.com/weather/64x64/day/113.png>")) { image in
    image.resizable()
} placeholder: {
    Image("sunny")
}
.frame(width: 50, height: 50)

```

## And the struggles

The development of this app was not all peaches and cream, I hit a roadblock when trying to change, as the user, my Location sharing preference. The app does need the ability to determine the user’s location, to either get the zip code for US locations or latitude and longitude for locations outside of the US. For watch apps with a companion app, the location sharing preference can be changed in the app’s own settings, within the phone’s Settings app. For an independent app, you still have to use the paired iPhone, but you have to dig a bit more. Open the Settings app, scroll down and tap Privacy, then tap Location Services, then find the watch app in the list of apps, select it and then change the setting. In the Settings app on the watch, you can navigate to the same location, but you can’t change the selected option because all options are grayed out. 🤯

![Circuit board](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/hbiptjuizi0czns6x7gk.jpg)

## Test, test, then test again

When testing the app, running it on an actual Apple Watch was critical. Early in development, I tested with a simulator and expanded the size of it on screen so I could easily see everything. When I ran it on my device for the first time, the font was so small I could barely read it! I had to take some extra time, rework my layout and increase the font size, right up to the standard system font size. Running on a real device will also give you a sense of how long each step takes and what your user’s experience will be like. The API call for the weather API takes usually 1–2 seconds, just long enough that you’re left wondering if the app is still running. An on-screen activity indicator, in such situations, would give the user some confidence that the app hasn’t crashed. Finally when testing on an actual device, you get the true feel of the software. Are your buttons and other touch targets too small, hard to reach, not in a place that makes much sense? Your users will not be using these apps with mice and keyboards, but with their hands and fingers, so use your hands and fingers to test your apps to know if the experience makes sense and is enjoyable to use. ☝️

With this project, I grew my own skills a bit with watchOS, SwiftUI and the Apple Watch itself. I gained more confidence with SwiftUI, learning that I can create a layout for something as small as a watch and it can also build and compile for a device like an iPad Pro. When I build iOS apps in the future, I’ll follow the Apple guidelines and consider not a companion watch app, but an independent watch app that can provide similar features on the watch, exchange data with the phone through iCloud, and give the user the opportunity to choose between installing one or both apps, depending on their own needs. ⌚️

![Three Apple watches side-by-side](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/zz27axqjlpmcgifwwzyf.png)

What has been your experience with watchOS and even SwiftUI development? Let’s continue the conversation below in the comments, I look forward to reading about your experience! 💬

---

[View on echobind.com](https://echobind.com/post/developing-an-independent-watch-app)

---

# GraphQL vs REST: What I’ve learned so far

> Sep 30, 2021 | GraphQL vs REST is like the current options for a grocery shopping experience: ordering online vs physically going to a store.

_By Kim Wilkes · 2021-09-30_

Two years ago, I was a month into my Software Engineering bootcamp learning everything I could about the joys of coding and the inner workings of APIs. I had been taught using RESTful APIs and all seemed straightforward as I created the apps required for my program and a year later was able to get my first internship. Then I got my first job at [Echobind](https://echobind.com/) right after the internship and was introduced to GraphQL as an alternative to REST.

## What is GraphQL?

[GraphQL](https://graphql.org/) is a database query language that allows us to access and manipulate data from one source rather than needing numerous routes and the various CRUD operations. Working with it honestly feels like I’m trying to talk to a ghost who has the shape of the database but definitely is not the actual database itself. Thankfully the ghost will tell you about itself thanks to GraphQL’s self-documentation, assuming the schema has been effectively named.

GraphQL has a schema that helps us know what the data looks like, and what we can expect to receive in our requests to the API. The most important pieces of working with GraphQL that you need to know are types, queries, mutations, and resolvers. Types define the schema as an object, they can be made up of fields of [scalar types](https://graphql.org/graphql-js/basic-types/): ID, String, Int, Float, and Boolean.

```html
ytype Person {
	id: ID!	# the ! means it's a required/non-nullable field
	name: String
	age: Int	
	married: Boolean
	pets: [Animal]
}
type Animal {
	name: String
	species: String
}
```

Fields can also be made of lists, objects, enums, and interfaces. You can also use lists like the \[Animal\] on Pets which will know to expect a nested query, in this case, an array of that defined type.

![GraphQL playground](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/ooe4zzxr5sjvwf03tqwn.jpg)

Queries are pretty straightforward as a means to read the aforementioned data. If you want to change the data in any way you must use a mutation. Mutations can be customized to return data in a specific way using resolvers.

![GraphQL playground](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/bugxthkckqcxzy5mu9jd.jpg)

All of this sounds all well and good, or maybe like gibberish. It matters how we query and manipulate data when most are probably already familiar with RESTful APIs as I highlighted earlier.

## GraphQL vs REST

GraphQL vs REST is like the current options for a grocery shopping experience: ordering online vs physically going to a store.

![Aisle in grocery store](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/xmuowutu7vcu969rd9s7.jpg)

Your query is your shopping cart: you’re hoping to fill it with all of the data pieces that you need to complete your meal planning. Let’s imagine we want to plan out breakfast with something simple with eggs and coffee.

When you go to the REST grocery store, you grab a query cart and head in. Unfortunately, the query cart can really only be used for one of the items on the list at a time unless the grocery store thought to put related things together.

The various aisles in the REST grocery store can be considered routes, each dedicated to a specific resource and may contain a few other resources if someone thought that they are related to a given resource. If we want to get our coffee in an actual grocery store, we will likely find it in a drink aisle that contains everything. Depending on how the aisles are organized, you’ll find a number of other items that may fit into that category but ultimately were not what you were looking for. The drink aisle will include juice, powder, tea, concentrate, flavor mix-ins, and more; when all we were looking for was coffee. Not to mention all of the data about each of these options will also be given to us on the price tag/packaging.

![Matrix gif](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/j1kip0inneb0yo8ucgwd.gif)

What it feels like to query REST apis.

When we query a RESTful API, we will get **all** of the information about that specific resource, even if we didn’t ask for/need it. We may have just needed the name of the item but we will get that as well as the sale price, price per pound, weight, id, and other details that may be useful for something but not what we needed.

Compared to shopping online at the GraphQL mega retailer that offers everything but the moon all from one spot. In one trip to a website, I could request exactly what I wanted without going down multiple aisles and seeing a lot of extraneous details about the objects I’m looking for. Usually just see the name and price until I actually select the specific item.

This analogy kind of falls apart once we get to mutations. If shopping at the grocery store is our query, then mutations would be converting the eggs into an actual meal. Like some futuristic kitchen tool out of a science fiction setting, GraphQL allows us to do almost everything and anything to the eggs in one mutation through a POST request. On the other hand, REST expects us to use each individual route and supply whether it is a POST, PUT, or DELETE. Almost as if we had to use a specialized, As Seen On TV tool for whatever specific egg preparation we wanted.

## What next?

It’s been fascinating to learn about and reflect on the differences between REST and GraphQL. Personally, I still appreciate what REST apis do when I have no idea all of the information that can be included on the first go or potentially just need the kitchen sink of that information. Having multiple routes that are specific to resources is also good for navigating errors in a potentially more straightforward way than what may occur with GraphQL.

GraphQL is great for when I know I need specific pieces of information and want to reduce the unnecessary data being pulled in. The self-documenting aspect of GraphQL makes that effort even easier assuming the schema types have been well named or has descriptions attached. This feature is made even easier to use with tools like [GraphiQL](https://github.com/graphql/graphiql) and [GraphQL Playground](https://github.com/graphql/graphql-playground) (which is included in [Apollo Server](https://www.apollographql.com/docs/apollo-server/v2/testing/graphql-playground/)). GraphQL Playground is really great because it let us explore the schema and understand the necessary parameters before we start querying the data.

![GraphQL playground](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/ooe4zzxr5sjvwf03tqwn.jpg)

I hope my analogies made the abstract a little more concrete and that you get the opportunity to explore these tools for your own curiosity and needs as they arise. May your future queries return your breakfast quickly and to order!

---

[View on echobind.com](https://echobind.com/post/graphql-vs-rest-what-ive-learned-so-far)

---

# The Spaceship of Theseus

> Sep 16, 2021 | As of this or some other moment, you and the rest of your team are probably in the process of needing to replace or enhance…something.

_By Zack Marty · 2021-09-16_

## When building new is better than enhancing the old

As of this or some other moment, you and the rest of your team are probably in the process of needing to replace or enhance…something. You or someone else must decide if the team can bring your current product up to the times or if you all have to decide that your 2001 Ford Escort is not going to make it to 200,000 miles and must be traded in. Mine only made it to 191k. It is rarely an easy decision to make. On a rare occasion, you will happen upon a team (one that you might be part of) that has decided that bringing their current system up to the times is the correct answer. Unfortunately, their current technologies have all the power and prestige of a wooden boat and they want to be flying in a spaceship. The idea we want to explore in this circumstance is that building a new system is often better than spending exponentially more time and money on bringing your current technology to the 21st century.

#### First, [The Ship of Theseus](https://en.wikipedia.org/wiki/Ship%5Fof%5FTheseus)

The Ship of Theseus is an old thought experiment about the nature of identity. If I have an ancient (probably Greek) wooden ship, and I replace every piece of that ship one by one over time, is it still the same ship? At what point during the replacing of parts does the original cease to be if it is not the same ship? None of the parts at the end of the process are their original part, but it still has the same name, maybe the same people are sailing the ship, and by the time you replace the last part, the first part replaced likely looks broken in as if it was never replaced. If someone walked away at the beginning of the process and came back at the end, they might think you gave the ship a good wash.

We could go on and on about the Ship of Theseus and what identity really means or if our incessant personification of objects just reveals our inherent, malignant [anthropocentrism](https://www.britannica.com/topic/anthropocentrism), but that is neither here nor here. It might be there.

## The Spaceship of Theseus

Instead of the end product being an ancient, wooden ship, imagine that your team has decided that they are going to replace each plank, beam, rope, and sail until the end product is a spaceship. Why a spaceship rather than a better wooden ship? Often when a team wants to do something like this, they don’t just want to modernize their product. The modernization of their product is typically accompanied by the need to make their software or product offering exponentially more robust than it is now to stay ahead of the competition. The competition I speak of spent the last few years innovating rather than demanding that their horse run as fast as a Ferrari. When this happens, your client or team will want to go from ship to spaceship, and they want to do it quickly. On top of this, there is an almost 102% chance that this new system needs to look and function significantly different than your exhausted horse/wooden ship.

![Ship with arrow pointing to spaceship](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/tkcdnuqf1eejdvyzxtpe.png)

Sounds difficult, yeah? For the sake of maintaining the metaphor, we can pretend that spaceships are still incomprehensibly complex compared to a wooden ship, but they only have about 50% more parts. The extra parts are due to all of the robustification that needs to accompany the modernization. Your company or client wants to slowly replace pieces of the ship until it becomes a spaceship, but it also needs to continue to act as a boat right up until the moment you can fly it into space. This way, the passengers and pilots/sailors never need to leave the ship, and it becomes better and greater while they continue to do their work that drives the company’s revenue.

![Ship with arrow pointing to a ship with arrow pointing to a spaceship](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/fov4a0kb0emkettktd5y.png)

The other option one might consider (Hint: It’s the option they likely need to do) is to keep sailing, and then get into the spaceship when it is done being built. The users go out in their boat as they always do, do work-related things, find out the spaceship is ready, and then they get into the spaceship for takeoff. The boat still works and maybe needs some basic repairs in the meantime, but your business needs are still being met.

Because we are still in metaphor land, it is hard to conceptualize why someone would ever think something like The Spaceship of Theseus could work. So let’s step away from the metaphor a little bit and ask why a team might think that they can do this or more importantly why they think they must do this.

## Why a client thinks they NEED to do this

### 1\. Data integrity and the continuation of business needs.

There is an overwhelming assumption when people are considering a new build in a theoretical sense, and it is the perspective that can be summarized by the image below.

![Burning ship with people walking towards a spaceship](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/ep74yjs5cgs8jrzm9u3j.png)

A surprisingly common objection to building a new system is that data could be compromised if this new spaceship they are all piling into suffers the same fate as the Challenger. If every client/user piles into this ship that has a catastrophic bug not found during testing, then an entire day’s or week’s worth of work and information could go up in flames. This is typically coupled with the assumption that we plan to set the previous ship on fire as everyone exits the old system. That is a completely reasonable fear if we are committed to the worst transition plan ever devised. To ease the concerns of those who are worried about an imaginary, awful plan, you will need to have a high-level [implementation/transition plan](https://www.entranceconsulting.com/how-to-prepare-your-business-for-a-software-transition/) to go with the conversation about building an entirely new system.

![Ship with gree arrow pointing down next to a spaceship](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/yqvms861snitncprhdtn.png)

The general implementation plan is to have a small set of users be the first to use your production-ready software with the expectation that things WILL go wrong. We would all love to write bugless code with the insane expectation that every developer in your organization already knows exactly how their piece will fit into the overarching puzzle, but that is ridiculous. We just need to prepare for the reality that things will definitely go wrong and be prepared to iron out the kinks before everyone migrates to the new system.

Even when the team is ready to move everyone over to the new system after our first client has helped us iron out issues, new folks will still probably move over in a slow transition. Ensuring that our work has scaled properly before throwing a Molotov cocktail at the legacy system will ease any worries that the rush of users onto a new system will not trigger the apocalypse and bring the four horsemen to your client’s doorstep.

### 2\. Maybe your client or team prefers the illusion of progress over progress.

If you asked your client if they prefer the [illusion of progress](https://deming.org/true-improvement-vs-illusion-of-progress/) over progress, they would think such a question insane, but the slow march of turning an ancient, wooden ship into a spaceship is a commitment. It is a commitment to a significantly longer timeline, a lot more money, and a very risky assumption.

![Two rows of ships next to an arrow pointing to a spaceship](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/whyovotre3c5aqyhx20d.png)

That [risky assumption](https://medium.com/hackernoon/the-mvp-is-dead-long-live-the-rat-233d5d16ab02) is that nobody will beat them to the market with better technology. The illusion of progress is that by X month, you may be slightly closer to the spaceship in your iterative enhancement, but you are significantly further behind than if you started the spaceship from scratch. Your stakeholders may have those tangible results in a production environment that they wanted, but by the time you attach the rocket booster to your wooden ship (as seen above), you could have been halfway done with your entire ship.

So while your client/company is sailing around the Frankenstein ship, someone with a complete spaceship could be going around gobbling up all of your potential and/or current clients. By the time the team has completed the transition it could be too little, too late, and way too expensive. So why would they still be committed to this illusion of progress? Because it is the illusion of a commitment to Agile.

### 2.1 The Illusion of a commitment to Agile

When we talk about [Agile](https://www.wrike.com/project-management-guide/faq/what-is-agile-methodology-in-project-management/) we are typically talking about iterative development. A bunch of executives would want to see iterative progress, and a team might view that requirement as needing to do something like the Spaceship of Theseus where they see the current systems receiving iterative improvements and slowly becoming better. Agile does not mean that we are constantly pushing new features to production for the world to see. When someone starts a major piece of software, they don’t then invite the public to see how someone can choose a username and set a password. There is typically a large build process before anything sees the light of day outside the internal testers and stakeholders. Agile is the way we manage work, but it does not necessitate the pushing of code into production. What it does necessitate is a constant [feedback loop](https://www.mendix.com/blog/agile-process-why-you-need-feedback-loops-both-during-and-after-sprints/). Your team writes code, reviews the end product of that code, and makes course corrections along the way. You may be defining what the end product is ahead of time, but you are also in a constant state of being able to show the results of your work. If you don’t release software to the public, it does not mean you are failing at agile. It just means that what you are building cannot necessarily be released to end-users in bits and pieces, especially if the plan is to replace a behemoth, and super especially if iterative production pushes are going to slow you way down in the long run.

On the other hand, building an entirely new system for people to eventually transition to feels very [waterfall](https://www.guru99.com/waterfall-vs-agile.html). It doesn’t need to be. Just because you are building an entirely new thing before it goes to the end-users does not mean you are committing to a non-agile methodology that ends with you handing someone a CD for installation. It just means your code isn’t immediately available. So how do you show progress on a major project that they won’t be able to use for a long while? Show them what you’ve built so that you can get into that constant feedback loop!

![Yellow truck with part of a spaceship next to a helicopter, two people talking and an unfinished spaceship](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/wlsdabhn3o0nzfqz6jyf.png)

Members of Leadership need to get some “oooohs” and “aahhhs” at a pretty regular interval to be sure that the money they’re throwing at you is actually being spent well. It is difficult to wait N years for new software when they could see a marginal improvement to their current, ancient ship in a few months, but forcing iterative improvement right now is just short-sighted. Making the executives and other stakeholders feel like they are part of the journey is as important as the journey itself to ensure that it does not get canceled from under you leaving you with a half-finished spaceship that you are expected to glue to your ancient, wooden ship.

![Ship with parts of a spaceship](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/rar2cirqumvn8astwxez.png)

### Conclusion

There is a good chance that your client or team will have more objections to a new build that would take them down the route of the Spaceship of Theseus, and your goal will be to cut to the core of the objection to refute what is likely a weak objection. In their efforts to make the Spaceship of Theseus many scrappier folks have eclipsed major companies or made them entirely irrelevant, and you must be their lighthouse in the dark to prevent such an occurrence. Also, the Spaceship of Theseus is not a common occurrence, but you are all but guaranteed to see it more than once in your career. When companies want to update a few modules or make a major update to their infrastructure, it does not necessarily mean that they are creating the Spaceship of Theseus. It may just mean that they are keeping up with the times and taking their Spaceship from 1.0 to 2.0\. The last thing to consider is that not everyone needs a spaceship. Maybe they really just need to go from an ancient, wooden ship to a less ancient, wooden ship. Good luck navigating. Onward and Upward!

![Spaceship](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/qkux8rgcfxji7dirqnel.png)

---

[View on echobind.com](https://echobind.com/post/the-spaceship-of-theseus)

---

# React Hook Form for React Native

> This blog post will help guide you in using React Hook Form to register form inputs on the component level via hooks.

_By Alex Silcox · 2021-09-09_

When looking for a way to integrate forms in one of my more recent React Native projects, I found [React Hook Form](https://react-hook-form.com/) after it being recommended by my colleagues at [Echobind](https://echobind.com/) who used it as a solution for React web. It trades itself as a "Performant, flexible, and extensible \[solution for\] forms with easy-to-use validation". I was excited to find its support for [React Native](https://reactnative.dev/), but as I dove into trying it as a solution, I was quickly confused by its lack of documentation and examples for React Native. 

One of the concepts in React Hook Form is the ability to register your uncontrolled component into the hook. The current example utilizes a Controller pattern, wrapping all components on the same level. While this approach is straightforward for simpler applications, it can be cumbersome/problematic for larger apps because it doesn't enable flexibility for nested component structures. There is a solution to this in the form of hooks, but the documentation is only limited to a React context.

This blog post will help guide utilizing React Hook Form to register form inputs on the component level via hooks, making its value available for form validation and submission for its parent components. When I started using React Hook Form for React Native, I based my learning on this [article](https://medium.com/geekculture/handy-form-validation-in-react-native-with-react-hook-form-usecontroller-3d4c4297e843) by Daniel Koprowski. Since then I've adapted it to using v7 and Typescript, that's what this guide will be based on. So let's get started!

## **Getting started**

Assuming you have your React Native environment setup and dependencies installed, let's start by adding the following code to match React Hook Form's React Native example (<https://react-hook-form.com/get-started/#ReactNative>):

```tsx
// App.tsx
import * as React from 'react';
import { Text, View, StyleSheet, TextInput, Button, Alert } from 'react-native';
import { useForm, Controller } from 'react-hook-form';

export default function App() {
  const { register, setValue, handleSubmit, control, reset, formState: { errors } } = useForm();
  const onSubmit = data => {
    console.log(data);
  };
   
  const onError: SubmitErrorHandler<FormValues> = (errors, e) => {
    return console.log(errors)
  }

  return (
    <View style={styles.container}>
      <Text style={styles.label}>First name</Text>
      <Controller
        control={control}
        render={({field: { onChange, onBlur, value }}) => (
          <TextInput
            style={styles.input}
            onBlur={onBlur}
            onChangeText={value => onChange(value)}
            value={value}
          />
        )}
        name="email"
        rules={{ required: true }}
      />
      <Text style={styles.label}>Last name</Text>
      <Controller
        control={control}
        render={({field: { onChange, onBlur, value }}) => (
          <TextInput
            style={styles.input}
            onBlur={onBlur}
            onChangeText={value => onChange(value)}
            value={value}
          />
        )}
        name="password"
        rules={{ required: true }}
      />

      <View style={styles.button}>
        <Button
          style={styles.buttonInner}
          color
          title="Reset"
          onPress={() => {
            reset({
              email: 'jane@example.com',
              password: '****'
            })
          }}
        />
      </View>

      <View style={styles.button}>
        <Button
          style={styles.buttonInner}
          color
          title="Button"
          onPress={handleSubmit(onSubmit)}
        />
      </View>
    </View>
  );
};

const styles = StyleSheet.create({
  label: {
    color: 'white',
    margin: 20,
    marginLeft: 0,
  },
  button: {
    marginTop: 40,
    color: 'white',
    height: 40,
    backgroundColor: '#ec5990',
    borderRadius: 4,
  },
  container: {
    flex: 1,
    justifyContent: 'center',
    paddingTop: Constants.statusBarHeight,
    padding: 8,
    backgroundColor: '#0e101c',
  },
  input: {
    backgroundColor: 'white',
    borderColor: 'none',
    height: 40,
    padding: 10,
    borderRadius: 4,
  },
});

```

While in smaller apps, this pattern could work out just fine, but for more complex applications with multiple or extensive forms, custom/dynamic inputs, etc, this pattern can be cumbersome if a controller needs to be assigned to every TextInput component. So let's make this more efficient by integrating the controller functionality within a custom TextInput component.

## Setting up the files

### 1\. Create TextInput component

The first thing we will do is create a custom TextInput component. Right now this component will be pretty basic. It will be a wrapper for the React Native Core TextInput component, with some styling (originally defined in `App.tsx`) and props such as `label` and any props inherited from `TextInput` (renamed RNTextInput since we'll have our new TextInput declared) as `inputProps`. You might be wondering why we aren't passing props like `value`, `onBlur`, and`onChangeText`? Don't worry we will get to that part later.

```tsx
// components/TextInput.tsx
import React from 'react';
import { View, TextInput as RNTextInput, Icon, Text, StyleSheet } from 'react-native';

interface TextInputProps extends RNTextInputProps {
  label: string
}

export const TextInput = (props) => {

const {
  label,
  ...inputProps
} = props;

return (

<View style={styles.container}>
  {label && (<Text style={styles.label}>{label}</Text>)}
    <View style={styles.inputContainer}>
    <RNTextInput
      style={styles.input}
      {...inputProps}
    />
  </View>
</View>

);};

const styles = StyleSheet.create({
  label: {
    color: 'white',
    margin: 20,
    marginLeft: 0,
  },
  container: {
    flex: -1,
    justifyContent: 'center',
    padding: 8,
    backgroundColor: '#0e101c',
    borderColor: 'white',
    borderWidth: 1
  },
  input: {
    backgroundColor: 'white',
    borderColor: 'none',
    height: 40,
    padding: 10,
    borderRadius: 4,
  }
});

```

### 2\. Integrating React Hook Form into our TextInput component

This is where the magic begins. There are two main hooks that we will want to import from React Hook Form, `useController`, and `useFormContext`. `useController` hook establishes the instance of our controlled input and stores its value to the form, and the `useFormContext` hook will allow us to access the form's context, its methods, and state.

For `useController` to work, `name` is **required** to be registered to it. Optionally, you can also pass along any validation`rules`, and an inputs `defaultValue`. So let's add those as well to our TextInput props and register them to the controller. Be sure to also extend the TextInput props to inherit the `UseControllerProps`.

```tsx
// components/TextInput.tsx
import React from 'react';
import { 
    View, 
    TextInput as RNTextInput, 
    TextInputProps as RNTextInputProps, 
    Text, 
    StyleSheet } from 'react-native';

/* IMPORT HOOKS AND PROPS TYPES */
import { 
    useController, 
    useFormContext, 
    ControllerProps, 
    UseControllerProps 
} from 'react-hook-form';

/* EXTENDING PROPS TYPES TO INHERIT NAME AND RULES FROM USECONTROLLERPROPS */
interface TextInputProps extends RNTextInputProps, UseControllerProps {
  label: string
  defaultValue?: string //ADD DEFAULT VALUE TO PROPS
}

export const TextInput = (props: TextInputProps) => {

/* GET THE FORMS CONTEXT */
const formContext = useFormContext();

/* DECONSTRUCT PROPS */
const {
  label,
    name,
    rules,
    defaultValue,
  ...inputProps
} = props 

/* 
        REGISTER THE CONTROLLER WITH VALUES 
        RECEIVED THROUGH PROPS
*/
const { field } = useController({ name, rules, defaultValue }); 

```

Again, without a `name`, the app will throw an error. We can safely type our component to require it. Additionally, we could extend this even further by not rendering the input if `name` or `formContext` doesn't exist. I'm generally not a fan of this approach by itself, as it could not render all the inputs in the form and lead to confusing form submission errors if required inputs didn't render. So let's pass a message to the developer to inform when the `formContext` or `name` does not exist.

```tsx
// components/TextInput.tsx
export const TextInput = (props: TextInputProps) => {

const formContext = useFormContext();

const {
  name,
  rules,
  label,
  defaultValue
  ...inputProps
} = props;

const formContext = useFormContext();
const {...methods} = formContext

/* 
        RETURN MESSAGE TO DEVELOPER
        WHEN FORMCONTEXT OR NAME IS MISSING
*/
if (!formContext || !name) {
  const msg = !formContext ? "TextInput must be wrapped by the FormProvider" : "Name must be defined"
    console.error(msg)
  return null
}

const { field } = useController({ name, rules, defaultValue });

```

Now there's one more problem with this code. `useController` is being called conditionally, breaking React's [rule of hooks](https://reactjs.org/docs/hooks-rules.html). So if we were to go with this method, we need to split out the logic to separate components. Let's relocate our `useController` hook and rendered components and their props in a new functional component called`ControlledInput`. 

```tsx
// components/TextInput.tsx > ControlledInput

/* 
      MOVE USECONTROLLER HOOK AND RENDERED CONTENT TO CONTROLLEDINPUT
      WHEN USECONTROLLER IS AVAILABLE
*/
const ControlledInput = (props: TextInputProps) => {
  
  const formContext = useFormContext();
  const { formState } = formContext;

  const {
  name,
  label,
  rules,
  defaultValue,
  ...inputProps
} = props;

  const { field } = useController({ name, rules, defaultValue });

  return (

  <View style={styles.container}>
      {label && (<Text style={styles.label}>{label}</Text>)}
        <View style={styles.inputContainer}>
        <RNTextInput
          style={styles.input}
          {...inputProps}
        />
      </View>
    </View>

  );
}

```

Now, this is accessible to our TextInput component and only returns when`formContext` and `name` exist.

```tsx
// components/ TextInput.tsx > TextInput

/* 
    TEXTINPUT COMPONENT ONLY CALLS THE CONTROLLEDINPUT COMPONENT 
    WHEN FORMCONTEXT AND NAME ARE AVAILABLE
*/
export const TextInput = (props: TextInputProps) => {

const { name } = props;

const formContext = useFormContext();

if (!formContext || !name) {
  const msg = !formContext ? "TextInput must be wrapped by the FormProvider" : "Name must be defined"
    console.error(msg)
  return null
}

return <ControlledInput {...props} />;

};

```

### 3\. Hook up controlled state to our rendered component

The last thing we need to do for our input is connected it to the controller. We're going to destructure the `field` object returned by the `useController`, and assign the root component `value`, `onBlur`, and `onChange` props with these field properties, giving `react-hook-form` full access to our component. 

```tsx
// components/TextInput.tsx > ControlledInput

const ControlledInput = (props: TextInputProps) => {
  
  const formContext = useFormContext();
  const { formState } = formContext;

  const {
  name,
  label,
  rules,
  defaultValue,
  ...inputProps
} = props;

  const { field } = useController({ name, rules, defaultValue });

  return (
/* 
   ASSIGN PROPS ONCHANGETEXT, ONBLUR, AND VALUE TO
     CORRESPONDING FIELDS
*/
  <View style={styles.container}>
      {label && (<Text style={styles.label}>{label}</Text>)}
        <View style={styles.inputContainer}>
        <RNTextInput
          style={styles.input}
                onChangeText={field.onChange}
        onBlur={field.onBlur}
        value={field.value}
          {...inputProps}
        />
      </View>
    </View>

  );
}

```

### 4\. Import the TextInput component into **App.tsx**

Now that our custom TextInput component is controlled by `react-hook-form`, let's go ahead and replace the `Controlled` component with our new controlled `TextInput` component inside `App. tsx`. To work properly, we will need to wrap our TextInputs with the `FormProvider`. We will need to pass all methods into the context by passing the methods from `useForm` to the FormProvider component. Now our TextInputs will be fully registered and controlled by `react-hook-form`. Our submit button will live outside of the FormProvider, but can receive the form data by passing `handleSubmit` with its success and error handlers. 

```tsx
// App.tsx
import React from 'react';
import { TextInput } from './components/TextInput.jsx'
import { Text, View, StyleSheet, Button, Alert, TouchableOpacity } from 'react-native';

/* 
   IMPORT REACT HOOK FORM USEFORM, FORMPROVIDER, AND SUBMIT HANDLERS
*/
import { useForm, FormProvider, SubmitHandler, SubmitErrorHandler } from 'react-hook-form';

type FormValues = {
  email: string;
  password: string;
};

const App () => {

/* 
   GET METHODS FROM USEFORM
*/
 const {...methods} = useForm();

  const onSubmit: SubmitHandler<FormValues> = (data) => console.log({data});
    
    const onError: SubmitErrorHandler<FormValues> = (errors, e) => {
    return console.log(errors)
  };

    /* 
        WRAP TEXTINPUT COMPONENT IN FORM PROVIDER, 
    PASSING CONTEXT METHODS INTO PROVIDER

       FOR THE SUBMIT BUTTON TO RECEIVE FORM DATA
         PASS METHOD HANDLESUBMIT WITH FUNCTION HANDLERS INTO ONPRESS
        
    */

  return (
    <View style={styles.container}>
            <FormProvider {...methods}> // pass all methods into the context
        <TextInput
                    name="email"
          label="Email"
          placeholder="jon.doe@email.com"
          keyboardType="email-address"
                    rules={{ required: 'Email is required!' }}
                />
        <TextInput
          name="password"
          label="Password"
          secureTextEntry
                    rules={{ required: 'Password is required!' }}
        />
            </FormProvider>
     <View style={styles.button}>
        <Button
          title="Login"
          color="white"
          onPress={methods.handleSubmit(onSubmit, onError)}
        />
      </View>
    </View>
  );
};

```

There you have it, we now have an extensible form that can scale and is much cleaner than the original example. This component makes it easy to add extra features like inline validation and error handling. To see a full example of this, you can find it here: [React Hook Form V7 - For React Native - Snack](https://snack.expo.dev/@sparklefaeriecoder/react-hook-form-v7---for-react-native).

***Learn more about our [React Native capabilities](/capabilities/react-native-app-development).***

---

[View on echobind.com](https://echobind.com/post/react-hook-form-for-react-native)

---

# Converting Javascript to TypeScript with React Native

> Sep 02, 2021 | TypeScript can be used anywhere Javascript can be used and it looks very similar to Javascript so it’s easy to learn!

_By Jennifer  Watanabe · 2021-09-02_

If you’re like me, you learned Javascript first and want to start using TypeScript instead. Good news: TypeScript can be used anywhere Javascript can be used and it looks very similar to Javascript so it’s easy to learn!

## Example #1: Interfaces

Interfaces will check the shape of our values. We define them outside the component by using the keyword `interface` and are conventionally Pascal cased.

```javascript

interface DogBreed {
  averageHeight: number
  coatType: string
  countryOfOrigin: string
  isGoodDoggo: boolean
  name: string
}

```

After defining an interface we can use it to define a value’s shape. In this example we’re saying that the value of variable `maltese` and `russellTerrier` will have all the keys and properties of the interface `DogBreed`.

```javascript

const maltese: DogBreed = { // <- Define this value's shape as DogBreed
  averageHeight: 8,
  coatType: 'very long',
  countryOfOrigin: 'Malta? No one knows!',
  isGoodDoggo: true,
  name: 'Maltese',
}

const russellTerrier: DogBreed = { // <- Same thing here
  averageHeight: 11,
  coatType: 'mostly wiry',
  countryOfOrigin: 'England',
  isGoodDoggo: true,
  name: 'Russell Terrier',
}

```

[Doesn’t quite make sense?](https://www.youtube.com/watch?v=P17bFRuefjA)

## Example #2: Unions (“Or”)

Unions are represented by a single pipe (or vertical line) symbol. They describe a value that can be of more than one type. In this example we’re saying that the `countryOfOrigin` can be a string type or undefined type.

```javascript
 interface DogBreed {
  averageHeight: number
  coatType: string
  countryOfOrigin: string | undefined // <- Use the union here
  isGoodDoggo: boolean
  name: string
}
```

Now that we changed the accepted types for `countryOfOrigin`, we can set that value to be undefined and TypeScript will be ok with that. What TypeScript is doing is called type checking and is a large part of what makes TypeScript great.

```javascript
 const maltese: DogBreed = {
  averageHeight: 8,
  coatType: 'very long',
  countryOfOrigin: undefined, // <- Now this can be undefined
  isGoodDoggo: true,
  name: 'Maltese',
}
```

If we tried to assign anything other than a string or undefined to `countryOfOrigin` TypeScript will fail to compile.

```javascript
countryOfOrigin: 'Americas' // ✅ TypeScript accepts a string or undefined and this is a string

countryOfOrigin: undefined // ✅ TypeScript accepts a string or undefined and this is undefined

countryOfOrigin: 10 // ❌ TypeScript accepts a string or undefined and this is a number
```

## Example #3: Enums

Enums are a set of constants that are used to tell other developers exactly what a value should be. They are defined outside the component using the keyword `enum`. Conventionally they are Pascal cased and the properties are written in caps.

```javascript

enum CoatType {
  CURLY = 'curly',
  NO_COAT = 'hairless',
  SILKY = 'silky',
  SMOOTH = 'smooth',
  WIRY = 'wiry',
}
interface DogBreed {
  averageHeight: number
  coatType: CoatType // <- Now coatType can only be what we defined in CoatType
  countryOfOrigin: string | undefined
  isGoodDoggo: boolean
  name: string
} 
```

Now we can change our dog objects to match the new enum. This way we can clearly define what values are acceptable for this property. It’s also easy for another developer to see our intention.

```javascript
 
const maltese: DogBreed = {
  averageHeight: 8,
  coatType: CoatType.SILKY, // <- Now TypeScript will give an error if we type in a wrong value
  countryOfOrigin: undefined,
  isGoodDoggo: true,
  name: 'Maltese',
}
```

[Want more enum examples?](https://www.youtube.com/watch?v=8lIygIB1YTY)

## Example #4: useState

We can check the values passed to the `useState` hook by using angled brackets. (This is also called Generics. Check out the links at the end of this blog for more information!)

```javascript
const [dog, setDog] = useState<DogBreed | null>(null) 
```

Because the default state is null, we have to add null to the angled brackets so that TypeScript knows to accept null. The other type we are accepting is the interface `DogBreed`. Any object that doesn't match the keys and properties of `DogBreed` will not be accepted.

## Example #5: Functions

Function arguments and the function’s return type can be checked with TypeScript.

```javascript
// An onomatopoeia is the formation of a word from a sound like "cuckoo" or "sizzle"
const onPress = (selectedDog: DogBreed, onomatopoeia: string): void => {
  alert(`${selectedDog.name} says: ${onomatopoeia}!`)
}

onPress(maltese, 'bark bark') // ✅ Both arguments match what TypeScript accepts
onPress(russellTerrier, 100) // ❌ The second argument is not a string
onPress(tabbyCat, 'meow') // ❌ The first argument does not match DogBreed
```

`onPress` takes one argument called `selectedDog` which has to match all the keys and properties of `DogBreed`. The second argument must be a string. After all the function arguments are listed, we add the return type of the function. Because `onPress` does not return anything the return type is void.

## Example #6: Arrays

Arrays can be declared in TypeScript using square or angle brackets. If the array accepts more than one type use the angled brackets version.

```javascript
 number[] // Accepts an array of numbers: [1, 2, 3]
Array<number> // Accepts an array of numbers: [1, 2, 3]
Array<number | string> // Accepts an array of numbers or strings: [1, 2, 3, 'hi', 'hello']
number | string[] // Accepts a single number or an array of strings: 1 OR ['hi', 'hello']
```

We can add this to the interface `DogBreed` so TypeScript will only accept numbers for `averageHeight`

```javascript

interface DogBreed {
  averageHeight: number[] // <- Only an array of numbers will be accepted now
  coatType: CoatType
  countryOfOrigin: string | undefined
  isGoodDoggo: boolean
  name: string
}

const maltese: DogBreed = {
  averageHeight: [7, 8, 9], // <- This must match the accepted type of number[] now
  coatType: CoatType.SILKY,
  countryOfOrigin: undefined,
  isGoodDoggo: true,
  name: 'Maltese',
} 
```

[Need to see how this works in action?](https://www.youtube.com/watch?v=157NopQ-chU)

## Example #7: Objects

Objects in TypeScript are written similarly to interfaces. If the object keys aren’t known, we can still define its type.

```javascript
{
  [key: string]: string | number // The object's key will be a string and its value will be a string or a number
}
```

## Example #8: Optionals

Optionals are written using a question mark. When values are optional, they receive the undefined type automatically. Optionals can be added to function arguments too. Optionals are useful when you want TypeScript to check a value only if the value is provided.

```javascript
interface DogBreed {
  averageHeight: number[]
  coatType: CoatType
  countryOfOrigin?: string // <- TypeScript will not complain if this property is not given a value
  isGoodDoggo: boolean
  name: string
}
```

## Example #9: Final Code

```javascript

import React, { useState } from 'react'
import { Text, TouchableOpacity, View } from 'react-native'
import { calculateAverageFromArray } from './utils' // Helper function was imported for brevity

enum CoatType { // Could even be moved to an external file
  CURLY = 'curly',
  NO_COAT = 'hairless',
  SILKY = 'silky',
  SMOOTH = 'smooth',
  WIRY = 'wiry',
}

interface DogBreed { // Could also be moved to an external file if the codebase gets bigger
  averageHeight: number[] // Accepts an array of numbers
  coatType: CoatType // Must match a property of enum CoatType
  countryOfOrigin?: string // Accepts a string or undefined
  isGoodDoggo: boolean // Accepts a boolean
  name: string // Accepts a string
}

const maltese: DogBreed = { // This object will match the interface DogBreed
  averageHeight: [7, 8, 9],
  coatType: CoatType.SILKY, // Uses enum CoatType
  // countryOfOrigin no longer needs to be declared as it is optional
  isGoodDoggo: true,
  name: 'Maltese',
}

const russellTerrier: DogBreed = { // This object will match the interface DogBreed
  averageHeight: [10, 11, 12],
  coatType: CoatType.WIRY, // Uses enum CoatType
  countryOfOrigin: 'England',
  isGoodDoggo: true,
  name: 'Russell Terrier',
}

/**
 * Displays information on certain dog breeds.
 */
export const DogInformation = () => {
  const [dog, setDog] = useState<DogBreed | null>(null) // setDog only accepts objects matching DogBreed or null

  // This function accepts 2 arguments:
  // The first argument must match the interface DogBreed
  // The second argument must be a string
  // Finally, this function does not return anything so its return type is void
  // An onomatopoeia is the formation of a word from a sound like "cuckoo" or "sizzle"
  const onPress = (selectedDog: DogBreed, onomatopoeia: string): void => {
    alert(`${selectedDog.name} says: ${onomatopoeia}!`)
    setDog(selectedDog)
  }

  return (
    <View>
      {dog && (
	      {/* Once a DogBreed is set in state, its information will be displayed here */}
        <Text>
          {`
            You're viewing information on: ${dog.name}
            Country of Origin: ${dog.countryOfOrigin}
            Average Height: ${calculateAverageFromArray(dog.averageHeight)}
            Deserves Treats? ${dog.isGoodDoggo}
          `}
        </Text>
      )}
      {/* These buttons invoke our onPress function and pass it a DogBreed object */}
      <TouchableOpacity onPress={() => onPress(maltese, 'BARK')}>
        <Text>
          Click here to see information on Maltese
        </Text>
      </TouchableOpacity>
      <TouchableOpacity onPress={() => onPress(russellTerrier, 'WOOF')}>
        <Text>
          Click here to see information on Russell Terriers
        </Text>
      </TouchableOpacity>
    </View>
  )
}
```

### Conclusion

Now you’ve learned some common TypeScript and have a good place to start!

> Making TypeScript happy is a full-time job.
> 
> — David K. 🎹 (@DavidKPiano) [August 9, 2021](https://twitter.com/DavidKPiano/status/1424722212800565253?ref%5Fsrc=twsrc%5Etfw)

For more beginning TypeScript resources, check out the following:

* [Learn the Basics with Ben](https://www.youtube.com/watch?v=Z5iWr6Srsj8)
* [Learn the Basics with Fireship](https://youtu.be/ahCwqrYpIuM?t=315)

For more intermediate or advanced TypeScript resources, check out the following:

* [Type Inference](https://www.typescriptlang.org/docs/handbook/type-inference.html)
* [Generics and using <T>](https://www.youtube.com/watch?v=nViEqpgwxHE)
* [More Generics](https://www.typescriptlang.org/docs/handbook/2/generics.html)
* [Interface Inheritance](https://www.youtube.com/watch?v=XPGFqx8Vg-Y)
* [Private and Public](https://www.youtube.com/watch?v=aYmnwDlPB8s)

---

[View on echobind.com](https://echobind.com/post/converting-javascript-to-type-script-with-react-native)

---

# Love ’Em or Lose ’Em: Employee Relationships 102

> How you can use management strategies to become a better employee, and how you can help your own manager become their best?

_By Mariah Grey · 2021-08-26_

Welcome (back) to Employee Relationships, which reviews the management strategies from Love ’Em or Lose ’Em and gives them a twist — how you can use them to become a better employee, and how you can help your own manager become their best.

## **_Information:_** _Share It_

It’s easiest to do your best work when you have all of the information. Imagine trying to decide on vacation plans without the weather forecast — you’d probably decide against going sailing if you knew a storm was rolling in! The same is true in your work. You wouldn’t design a management system for Accounting when HR is actually the one who needs it. Making sure you have all pertinent information is a big part of doing your job to the best of your ability.

Information is power, and you make yourself a better colleague when you share the knowledge you have with others and empower your entire team. Now, keep in mind that this doesn’t mean spilling the beans on every secret you know. Context is important, and sharing information when needed is the key.

At Echobind, management has a clear dedication to sharing information. They hold a monthly meeting where they go over incoming and outgoing clients, margins, percentages, and promotions as a team. The consistent pattern of celebrating and discussing our company progress as a team goes a long way toward making employees feel “in the loop”.

## **_Jerk:_** _Are You One?_

Let’s get down to brass tacks here: We’ve all been a jerk before.

Avoiding this topic would be easier, but it would fail to address a BIG topic in how we can improve as employees and with our managers. Learning to recognize poor behaviors in ourselves leads to becoming better in those aspects of our lives.

Think about how often you do things such as talk condescendingly, show disrespect, start your sentences with “I”, or interrupt. What about failing to listen, lacking patience, or overusing sarcasm? Likely, at least one of these things falls on your shoulders. We all do these things, but acknowledging them and working on _doing them less_ is the takeaway point. We all have bad days or moments, but we can not take those moments out on other people.

The last part is the hardest piece of this section, changing those jerk-like tendencies. If you’ve got colleagues around who have been a target of these behaviors, apologies may be in order. I’m not talking about extravagant and elaborate displays, but about sincere and short acknowledgments. “I’m sorry I spoke to you rudely the other day. I’m working on handling things like this in a better manner.” and then, do the work and make the changes! You become someone others can trust when you are honest about your shortcomings.

## **_Kicks:_** _Are We Having Fun Yet?_

You may be wondering how fun fits into the workplace since you’re there to, well, _work_? While this is true, we tend to overlook the fact that creating and supporting fun at work is one of the best ways to stimulate creativity in people

Two of the biggest myths surrounding this are that Professionalism and fun are incompatible, and that fun at work will compromise the company’s results. To break these down:

_Professionalism and Fun Are Incompatible:_ This is not indicating banana peel slip type of humor, but it could be small things such as having those who don’t have something to contribute to a team meeting tell a joke in its place. We’ve incorporated something similar into our Friday Demo meetings at Echobind, where if you don’t have anything to share, you’re invited to tell us a fact that no one on the team knows about you. Little things like that add some fun to meetings and ensure that people are participating more often.

_Fun Time at Work Will Compromise Results:_ It tends to be the exact opposite! Many managers worry that their employees are wasting time by spending time laughing and joking with their coworkers. Little things like celebrating a colleague's birthday with a half-hour of cake and chatter can boost morale and send people back to their desks feeling refreshed and ready to tackle the rest of their work with renewed vigor. In a remote company, you may not have the physical act of sharing lunch (or cake) but the celebration remains, our team shares photos and video clips of their weekend adventures, such as motorcycle rides, special desserts they’ve made, or their kids.

The biggest factor to having fun AND productive workplaces for yourself and your team is setting clear goals for yourself to accomplish.

## **_Link:_** _Create Connections_

It’s true that it's easy to leave a workplace where you feel no camaraderie, connection, and you lack pride in the company’s purpose or mission. The opposite is also true — it’s hard to leave a workplace where you have “links” or connections to your coworkers, team, and company.

Linking up, or getting to know other departments ([creative](https://echobind.com/services), [strategy](https://echobind.com/services), [engineering](https://echobind.com/services)) and functions within the company allows you to create strong work relationships, which can make or break your workplace experience. As you are a talented, productive employee, your manager should be striving to help create and foster this kind of interaction opportunity for you and with you. Getting plugged into social groups within your workplace can be as simple as eating lunch together, holding weekly watercooler meetings, or celebrating teammates' birthdays with goofy gifs (we do these last two as a fully remote team at Echobind!).

Hopefully, you also feel connected to your company. Ways that this connection can be fostered is through community involvement. If your organization offers things like charity donation matching (Echobind does!) or partners with local or professional communities, this is a good way to connect. Echobind offers something like this to its team — we meet up once a year for an [in-person summit](https://echobind.com/about), several days of getting to know your team who you may have only seen online until then, as well as being involved in tech conferences such as [RenderATL](https://www.renderatl.com/).

## **_Mentor:_** _Find One_

People with mentors are twice as likely to stay and typically produce more, so get you one! Hopefully, your manager is already acting as a mentor for you. It doesn’t have to be a big lavish thing, something as simple as having someone to lean on when you hit a problem within your code or office politics is mentoring.

At Echobind, we have a program in place called our apprenticeship program. This brings on engineers with little “real world” experience and pairs them with an engineer with several years of credibility, with the goal of hiring them into a full-time position at the end of their 3 month learning period. On top of that, every engineer is paired with a senior, and they meet once a week to discuss current projects & investment time use, as well as being a source of help if you’re stuck.

Many good managers mentor naturally. MENTOR stands for the following 4 things: **_M_**odel — Walk the talk. **_E_**ncourage — Find where your mentee needs more support and provide it. **_N_**urture — Show that you care about them and their growth. **_T_**each **_O_**rganizational **_R_**eality — Tell it like it is, and help your mentee avoid those workplace pitfalls not listed in the handbook.

## **_Numbers:_** _Know Your Value_

High turnover rates are a bummer for everyone — companies must spend the money to replace those employees who leave, and employees must fill the gaps left behind in the meantime. 1 in 5 of those leaving are high producers, and both employees and companies feel those losses even more sharply.

What does that mean for you? Knowing your value can make all the difference in your ability to negotiate and find the best fit with (our outside of) your current company to help you reach your full potential. Not being fully present in your position hurts your performance and that of your department or company as a whole.

## **_Opportunities:_** _Find Them — Inside and Out_

Sometimes we are at the top of our performance as employees, and this is where opportunity comes knocking. Keeping an ear to the ground and being in open dialogue with your manager can make a huge difference in the chances you have to move (either parallel or up) within your company.

Seeking these opportunities and being open with your manager about your interest in something new or different can allow you to flourish where you already are. Often, there are things on the horizon that employees may not yet have heard about. They can also give you needed feedback to help make that next jump.

## **_Passion:_** _Find The Work You Love Without Leaving_

Maybe you’re passionate about creating new products, about crunching numbers, about managing others, or being part of a hands-on company that’s doing important work. Whatever lights your fire — find a way to incorporate that into your work. When people do what they love, they’re at their best. When employees work can be connected to their passions, the team and company reap the benefits.

Start out by telling your manager what you’re excited about. They may know of ways to tie your skills into an upcoming project or an internal opportunity. Maybe you had passion when you started your current job, but that fire has gone out. Finding ways to tie into that can rekindle your love of the work you’re doing.

I hope this round of _Love ’Em or Lose_ ’Em has inspired you to bolster your relationship with your manager and advocate for yourself to have the best job experience possible. If you haven’t yet you can read [part 1 ](https://echobind.com/post/love-em-or-lose-em-employee-relationships-101)of the series, or wait for part three to explore topics from Question to the Zenith: going for it.

---

[View on echobind.com](https://echobind.com/post/love-em-or-lose-em-employee-relationships-102)

---

# Using NextAuth.js with Bison

> Aug 19, 2021 | Bison is a starter template for building Next.js web applications that we use for our clients at Echobind...

_By Kishan Gajera · 2021-08-19_

[Bison](https://github.com/echobind/bisonapp) is a starter template for building [Next.js](https://nextjs.org/) web applications that we use for our clients at [Echobind](https://echobind.com/). Out of the box, Bison rolls its own username and password authentication implementation. One of the great things about Bison, is that you can easily swap out any of the default technology choices if you don’t agree with it or if it’s not right for the job. In this post, we will replace the default authentication with [NextAuth.js](https://next-auth.js.org/).

Full source code for this example can be found here: <https://github.com/echobind/bisonapp-nextauth>

## Create a Bison App

Let’s create a new Bison app by running:

```html
npx create-bison-app MyBisonNextAuthApp

```

You should see the following output:

![Bison](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/bsiqv3j7audgvnb2dtvx.png)

Next, we need to run the following commands to initialize the database and start the dev server:

```html
yarn setup:dev
yarn dev

```

In your web browser, we should now see the initial starting point of a Bison app:

![Home page](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/lhm2l1qt2owmosxjpjqm.png)

From the screenshot above, you can see there’s already a “Login” button that will take you through the default authentication flow provided by Bison. We’ll be replacing that functionality so let’s refactor out the default authentication code that will no longer be used. The following files can be deleted:

```html
components/LoginForm.tsx
components/SignupForm.tsx 
context/auth.tsx 
pages/login.tsx 
pages/signup.tsx 
services/auth.ts 
tests/unit/requests/user/login.test.tsx
tests/unit/requests/user/signup.test.tsx
tests/unit/components/LoginForm.test.tsx
tests/unit/components/SignupForm.test.tsx

```

## Integrating NextAuth.js

NextAuth.js supports many different authentication providers such as Google, Facebook, etc. In this example, we will be using the [email provider](https://next-auth.js.org/providers/email) which will send a “magic link” to your email to sign in.

## Install Dependencies

First, let’s install the `next-auth` dependency:

```html
yarn add next-auth

```

While creating the Bison app, you probably noticed it requires a Postgres database and uses [prisma](https://www.prisma.io/) as the ORM. So we need to install the appropriate adapter for NextAuth.js so it knows how to persist data in our database:

```html
yarn add @next-auth/prisma-adapter

```

## Updating the Prisma Schema

NextAuth.js requires the following schema to save users and authentication-related data such as sessions, providers, and verification requests.

```javascript
// prisma/schema.prisma

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

generator prisma_client {
  provider = "prisma-client-js"
}

model Account {
  id                 String    @id @default(cuid())
  userId             String
  providerType       String
  providerId         String
  providerAccountId  String
  refreshToken       String?
  accessToken        String?
  accessTokenExpires DateTime?
  createdAt          DateTime  @default(now())
  updatedAt          DateTime  @updatedAt
  user               User      @relation(fields: [userId], references: [id])

  @@unique([providerId, providerAccountId])
}

model Session {
  id           String   @id @default(cuid())
  userId       String
  expires      DateTime
  sessionToken String   @unique
  accessToken  String   @unique
  createdAt    DateTime @default(now())
  updatedAt    DateTime @updatedAt
  user         User     @relation(fields: [userId], references: [id])
}

model User {
  id            String    @id @default(cuid())
  name          String?
  email         String?   @unique
  emailVerified DateTime?
  image         String?
  createdAt     DateTime  @default(now())
  updatedAt     DateTime  @updatedAt
  accounts      Account[]
  sessions      Session[]
  roles         Role[]
}

model VerificationRequest {
  id         String   @id @default(cuid())
  identifier String
  token      String   @unique
  expires    DateTime
  createdAt  DateTime @default(now())
  updatedAt  DateTime @updatedAt

  @@unique([identifier, token])
}

enum Role {
  USER
  ADMIN
}

```

After you’ve updated the prisma schema, run the following command to generate the prisma client:

```html
yarn build:prisma

```

## Configuring NextAuth.js

We will create a new file, pages/api/auth/\[..nextauth\].ts, to configure the email provider and prisma database adapter.

```html
// pages/api/auth/[...nextauth].ts
import NextAuth from 'next-auth';
import Providers from 'next-auth/providers';
import { PrismaAdapter } from '@next-auth/prisma-adapter';
import { prisma } from '../../../lib/prisma';
export default NextAuth({
  adapter: PrismaAdapter(prisma),
  providers: [
    Providers.Email({
      server: process.env.EMAIL_SERVER,
      from: process.env.EMAIL_FROM,
    }),
  ],
});

```

You’ll notice there are a couple of environment variables for sending emails that need to be added. At Echobind, [SendGrid](https://sendgrid.com/) is our go-to email service. We won’t go in-depth about email services in this post, but after creating a SendGrid account, verifying a domain or specific email address, and creating an API key, you can start sending emails.

```html
// .env
EMAIL_SERVER="smtp://apikey:YOUR_API_KEY@smtp.sendgrid.net:587"
EMAIL_FROM="sender@example.com"

```

## Checking For Authenticated User Client Side

Bison uses a different “layout” component depending on whether a user is logged in or not. This is controlled in pages/\_app.tsx. To determine if a user is logged in, we will use the useSession() react hook provided by NextAuth.js.

```html
// pages/_app.tsx
function AppWithAuth({ children }) {
  const [session] = useSession();
return session ? (
    <LoggedInLayout>{children}</LoggedInLayout>
  ) : (
    <LoggedOutLayout>{children}</LoggedOutLayout>
  );
}

```

We also need to update the click handler for the “Login” and “Logout” buttons to use the new sign-in flow by updating them to call the `signIn()` and `signOut()` methods respectively from NextAuth.js.

In `layouts/LoggedIn.tsx`, we can update the "Login" button to have the following `onClick` handler:

```html
// layouts/LoggedIn.tsx
<Button onClick={() => signIn()}>
  Login
</Button>

```

Now, if we click the login button, it should navigate to the default login form provided by NextAuth.js:

![Login redirecting to homepage gif](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/fggjhecetxzwkxzwu1ct.gif)

When the form is submitted, it will send the following email containing the “magic link” to the email address that was entered:

![Sign in button](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/mzul3lfkj9emcjjfzo5x.png)

In `layouts/LoggedOut.tsx`, we can update the "Logout" button to have the following `onClick` handler: 

```html
// layouts/LoggedOut.tsx
<Button onClick={() => signOut()}>
  Logout
</Button>

```

## Checking For Authenticated User Server Side

Bison uses a GraphQL API. For each request, using the session, we need to query for the user and set it in the context object that will be passed to the GraphQL resolvers.

```html
// graphql/context.ts
export async function createContext(context: ApolloApiContext): Promise<Context> {
  const session = await getSession({ req: context.req });
  let user: User | null = null;
if (session) {
    const sessionWithUser = await prisma.session.findUnique({
      where: { accessToken: session.accessToken as string },
      include: {
        user: true,
      },
    });
user = sessionWithUser?.user;
  }
return {
    db: prisma,
    prisma,
    user,
  };
}

```

## Additional Resources

Want to learn more about NextAuth.js? Check out Mike Cavaliere’s three-part series starting with [NextAuth.js Intro \[1 of 3\]: One-Click Signup](https://echobind.com/post/nextauth-js-intro-1-of-3-one-click-signup).

Do you have opinions for or against using NextAuth.js as the default authentication included in the Bison template? Upvote or leave a comment in our [GitHub discussion](https://github.com/echobind/bisonapp/discussions/152).

---

[View on echobind.com](https://echobind.com/post/using-nextauth-js-with-bison)

---

# Swift Concurrency

> Aug 12, 2021 | Users will want to wait for your app to respond in an environment like a mobile device, threading and concurrency exist in most languages to handle this situation.

_By David Barkman · 2021-08-12_

As a developer, you will eventually write code that makes a call and takes some time to run. Network calls for example typically can take seconds to 10s of seconds to over a minute to run, in some extreme cases. There aren’t many instances when your users will want to wait that long for your app to respond and in an environment like a mobile device, the controlling operating system may think your app has crashed and shut it down. Threading and concurrency exist in most languages to handle this situation.

Concurrency is used to refer to the combination of asynchronous and parallel code. Asynchronous code allows for tasks to be suspended and resumed at a later point. This capability creates a more fluid user experience because it allows apps to complete short-term tasks like updating the UI while working on long-term tasks like retrieving data. Parallel code refers to multiple pieces of code running simultaneously. This gives users the ability to execute multiple tasks at the same time. The combination of asynchronous and parallel code, or concurrency, is essential to the function of modern mobile apps.

![multi-colored yarn through a needle](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/jdejguqmwg1tjfggsblu.jpg)

## WWDC, Upgrades for Swift!

[Announced in June 2021](https://developer.apple.com/news/?id=2o3euotz), at Apple’s annual [WWDC](https://developer.apple.com/videos) conference, Swift 5.5 and iOS 15 include support for async/await concurrency. Swift currently has methods for handling concurrency, the most prominent being closures, delegates and Notification Center with registered observers. Let’s look at each of these for just a moment, all three work fine and fill needed requirements, but sometimes make for a poor substitute for async/await.

### The concurrency you know

[Closures](https://docs.swift.org/swift-book/LanguageGuide/Closures.html), also known as completion handlers, are little functions that are defined within one function and can then be passed to another function to be called sometime later. Crystal clear, right? Not really, especially for newer programmers. In my own apps, I typically use closures for calling external Rest APIs. It allows me to unblock the main thread and make asynchronous calls for data I want to display. My standard app build includes a method with a closure for the data task at the lowest level of the call, a method with a closure for the specific API endpoint I’m calling and a method with a closure in the view controller that needs the data. Following the path between three methods down to the actual network call to the API and then unwinding the call back up through the closures is non-trivial, even after writing it myself. If I go too long without reading the code, I sometimes have to stop for a minute and really think through the steps again.

[Delegation](https://developer.apple.com/documentation/swift/cocoa%5Fdesign%5Fpatterns/using%5Fdelegates%5Fto%5Fcustomize%5Fobject%5Fbehavior) is a design pattern that enables a class or structure to hand off (or [delegate](https://docs.swift.org/swift-book/LanguageGuide/Protocols.html#ID276)) some of its responsibilities to an instance of another type. I typically use delegates for passing data between view controllers. In a split view controller app, where you have at least two view controllers visible on screen at the same time, you will run into scenarios where one controller needs to send data or notifications to the other. Making one a delegate of the other, or both delegates of each other allows this communication.

[Notification Center](https://developer.apple.com/documentation/foundation/notificationcenter), the third type of concurrency commonly used in Swift lets you set up something like a public message board in your app. This works in three steps: first you initialize the board for the specific message, second you add an observer in the controller that will eventually act on the message and third, a separate process will post to the board that an event has occurred. I’ve used this pattern recently when a view controller was depending on an Oauth handshake to first take place before it could fetch data from an API. Once an asynchronous task completed the authorization, it posted to the message board that the session was initiated, then the view controller that had already made itself an observer was notified by Notification Center and was then able to run its fetch method, which then ran through the three layers of closures listed above. 😬

![Visual Studio Code](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/uxknfm9pzmqu5bllk4ix.png)

## So many patterns, so little time

All of these patterns can be used interchangeably, in many situations. Some situations fit one of the patterns better than others, but they work. I could use Notification Center for communicating between two controllers, but it’s cumbersome. Using closures for cross-controller communication would likely not work, so there is some crossover, but not complete. With the new async/await, you will mostly be using it for your calls to internal and external APIs, calls for data that take time to retrieve. Asynchronous functions, such as those using completion handlers, will become more readable and more correct when written in this new pattern with async/await.

Enough theory, let’s look at some example code for fetching and returning thumbnails for a UI.

Here’s the original version:

```javascript
func fetchThumbnail(for id: String, completion: @escaping (UIImage?, Error?) -> Void) {
    let request = thumbnailURLRequest(for: id)
    let task = URLSession.shared.dataTask(with: request) { data, response, error in
        if let error = error {
            completion(nil, error)
        } else if (response as? HTTPURLResponse)?.statusCode != 200 {
            completion(nil, FetchError.badID)
        } else {
            guard let image = UIImage(data: data!) else {
                completion(nil, FetchError.badImage)
                return
            }
            image.preparingThumbnail(of: CGSize(width: 40, height: 40)) { thumbnail in
                guard let thumbnail = thumbnail else {
                    completion(nil, FetchError.badImage)
                    return
                }
                completion(thumbnail, nil)
            }
        }
    }
    task.resume()
}

```

Here’s the new version with async/await applied:

```javascript
func fetchThumbnail(for id: String) async throws -> UIImage {
    let request = thumbnailURLRequest(for: id)
    let (data, response) = try await URLSession.shared.data(for: request)
    guard (response as? HTTPURLResponse)?.statusCode == 200 else { throw FetchError.badID }
    let maybeImage = UIImage(data: data)
    guard let thumbnail = await maybeImage?.thumbnail else { throw FetchError.badImage }
    return thumbnail
}
```

Besides having a single indent level and only six lines of code to read, compared to twenty, the new code only has one exit point, the return of the thumbnail. If an error is encountered, the code will throw a sensical error. In the original version, there are five separate exit points to debug, test and track. Bugs are more easily hidden in complex code and code that’s difficult to read and follow won’t get as thorough of a code review. Code with multiple exit points like the original tend to surface those edge case issues, something the developer didn’t think of in design and is now causing a bug in production.

# Where to go from here?

Completion handlers and closures are still with Swift and still have their place. Hopefully, more as a single-level request and response and not as a series of sequential steps. Async/Await and the other new concurrency tools like [Asynchronous Sequences](https://developer.apple.com/documentation/swift/asyncsequence), [Continuations](https://github.com/apple/swift-evolution/blob/main/proposals/0300-continuation.md) and [Actors ](https://developer.apple.com/videos/play/wwdc2021/10133/)bring a needed upgrade to Swift that will result in more readable, easily testable, less bug-prone code that just does what it says. Learn more by visiting the [Swift Concurrency](https://developer.apple.com/documentation/swift/swift%5Fstandard%5Flibrary/concurrency) page on the Apple Developer portal. [Apple has also published an article and WWDC video, all free for anyone, covering refactoring an app with async/await and other new, concurrency tools on the Apple Developer portal.](https://developer.apple.com/documentation/swift/swift%5Fstandard%5Flibrary/concurrency/updating%5Fan%5Fapp%5Fto%5Fuse%5Fswift%5Fconcurrency)

---

[View on echobind.com](https://echobind.com/post/swift-concurrency)

---

# How to Find the Top Usability Problems on Your App

> Aug 05, 2021 | Find top usability problems on your app or website. Anyone who works with digital products will benefit from the knowledge shared in this guide.

_By Kaila VanSumer · 2021-08-05_

## Before We Get Started, Some Facts

### Fact #1:

Businesses could make more money if they improved their digital products.

### Fact #2:

Digital products can be significantly improved more easily, on a shorter timeline, and on a tighter budget than most people realize.

Bold claims, I know. But give me 5 minutes and I’ll let you in on the secret.

(Hint: you’re about to become a UX Genius for $0 down and less than a day’s work).

## Who This Guide is For

First, let me tell you who it’s **NOT** for:

* People who don’t care about making great products
* People who don’t care about their users
* Usability experts and designers who get paid lots of money to do a more robust version of what I’m about to share with you.

_Note: If you have the time and budget I highly recommend hiring and working with a UX professional. They’ll do a better job than you, have seen many of the same usability problems before, and will be able to suggest possible solutions. Plus, it’s always good to get an objective outside perspective. We do this at_ [_Echobind_](https://www.echobind.com/) _for our clients. Nevertheless, if you don’t have the time and budget read on and I’ll show you how to get started on your own._

Apart from the people on this list, pretty much anyone else who works on building digital products stands to benefit from this knowledge. That means if you’re a product person, this guide is for you, especially if you don’t consider yourself a “UX person” or a “designer”.

## A Brief History of Your Digital Product

So you have an app or website.

You’ve worked hard to get it to where it is today.

Maybe you started with some best-guess wireframes and the company evolved without a dedicated design team. Things have worked out okay so far, but deep down you know that the user experience is less than it could be, and you’re leaving users at the door and money on the table because of it.

Oftentimes design gets cut from the product development process early on because it can be expensive, it feels complicated, and from the outside looks like it produces more problems than it solves. Plus you just need to ship _something._

So the problems pile up, and now you have some weirdo on the internet telling you that you need to get your act together and start looking at those problems with a critical eye (yes, it’s me, I’m the weirdo, and I’m calling you out because I believe in a better internet for all of us).

“But Kaila, we already have a backlog of 107,295 problems,” I hear you say, “Why would we waste our time trying to find more?”

Here’s the deal.

That backlog of 107,295 problems _is_ the problem. Going through it is demoralizing, it’s a huge waste of your team’s time, and more often than not it doesn’t do anything to actually improve the product.

Seriously.

Think about how items get added to your backlog:

* Mr. Idea Man Employee thinks of a super cool feature that would make you a gazillion dollars (it probably won’t)
* The worst 5% of your customers call in on a daily basis and describe a super custom feature they need that your app can’t do (it probably shouldn’t)
* Your QA engineer logs all the inefficiencies in your spaghetti code that disturb his inner peace and keep him awake at night (poor guy)

I have empathy for all of these people, truly, I do. But these are not the problems we should be solving. Or at least, this isn’t how we should go about _deciding_ which problems we should be solving.

Instead, we should be solving, first and foremost, for the end user whenever possible. And it’s almost always possible. We just have to find the problems our users find the most frustrating and systematically work to resolve them.

![People in an office meeting](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/clglsbax7wk9rlkw60hj.jpg)

## Enter Usability Testing

Usability testing doesn’t seek to find solutions for the problems in the backlog. Rather, it helps us decide which of those problems are worth solving by giving us insight into where users are getting stuck while trying to accomplish their goals when using our app.

Okay, but what is usability testing?

For our purposes, usability testing is simply watching people use our apps and websites.

“But Kaila,” I hear you say, “we don’t have the time/resources/money/knowledge/UX unicorn to do usability testing. Who is going to run this usability testing of which you speak?”

(Spoiler alert: it’s you.)

### A Heaping Helping of Enlightenment

Congratulations, you are now your team’s ✨ **Honorary Czar of Usability**✨ !

When you started noticing the usability problems on your website, and then you turned to the internet for answers, you brought upon yourself the ethical responsibility of at least attempting to make things better. But don’t worry, once you’ve finished reading this post you’ll have all the knowledge and resources to complement your fancy new title and you’ll be able to start making your app better immediately.

## Usability Testing 101: A Step-By-Step Guide

### Step 1: Identify Common Goals Users Are Trying to Accomplish on Your Site

This step is simple. Open a google doc and make a list of things your users commonly do on your site or app. If it’s an eCommerce website this might be things like purchasing a particular product, checking out, or finding the latest deals. For a social media app, your list might include publishing a post or messaging a friend. For this first round don’t worry about getting too detailed. You’re going to do lots of usability testing moving forward and you’ll find new things to test as you go.

**_Tip:_** _if you’re having trouble with this step go talk to your customer service representatives and ask them to help you. They’re a treasure trove of information and we ❤️ them._

### Step 2: Write Task Scenarios

After you have a list of ideas of the most common actions users take on your site, choose 3 of them that you would like to test. Once you’ve made your decision, you’re going to write up a task scenario for each. Here’s how Neilson Norman Group defines a task scenario (plus an example):

_A task scenario is the action that you ask the participant to take on the tested interface. For example, a task scenario could be:_

_You’re planning a vacation to New York City, March 3 − March 14\. You need to buy both airfare and hotel. Go to the American Airlines site and jetBlue Airlines site and see who has the best deals._

_From:_ <https://www.nngroup.com/articles/task-scenarios-usability-testing/>

A task scenario gives a user context for the action you want them to take but doesn’t give away too much prescriptive or directive detail. You want to leave your scenarios open-ended enough that users don’t have a play-by-play of the desired action. This will give you a more holistic understanding of how a user might approach a given task and better insight into where the confusion lies.

### Step 3: Find a User

You’ve got your scenarios, now you just need someone to actually perform them on your site (aka a user). While you can recruit pretty much anyone for usability testing there are a few things to keep in mind if you want to maximize the value of your testing sessions:

1. Ideally, it should be someone who hasn’t used the site or app before.
2. It’s best if you can observe them (preferably in person, but if that’s not possible you can check out Shane Doyle’s excellent post on [how to do usability testing over zoom](https://www.shanedoyle.io/post/unmoderated-usability-testing-with-zoom)).

That’s it. For most apps, you don’t need an expert with domain knowledge or someone who perfectly fits your target demographic. The best apps are easy for anyone to use, so there’s no need to be precious about who you recruit. It can be your brother, your mom, an employee at the company next door, whatever. The important thing is that you find _someone_ and actually do some testing.

### Step 4: Watch & Learn (Record It If You Can)

Congratulations, you made it through the hardest parts! Now all that’s left to do is watch your user complete your task scenarios and learn from where they get stuck. Here are a few important points to make sure you get the most out of each test:

1. **Watch and listen.** Don’t nudge your user. Allow them to navigate freely and simply watch what they click on and where they get stuck. This will be the most insightful part of the test.
2. **Ask “what are you thinking?” regularly.** You want your user to give you as much information as possible while they’re actually performing the task. The more you can see and hear their thought process, the better you’ll be able to pinpoint what exactly is causing problems for them in the interface. Be careful not to ask any leading questions — stick to the exact phrase “what are you thinking?” as much as possible.
3. **It’s best to record the session if possible.** This will allow other people on your team to watch the session later if they can’t make it in person, and it will free you up to observe rather than trying to furiously scribble notes. You can use a simple screen recorder and a USB microphone for the best results. You’ll also want to make sure you get consent from anyone being recorded. **_Tip:_** _If you’re not able to record try to find a second person to take notes for you. You’ll get a lot more out of the process if you’re not occupied with note-taking and can stay engaged with your user._

### Bonus: Synthesize Your Insight

You did it. Pat yourself on the back because you’ve just completed your first round of usability testing. While the session is still fresh in your mind, take 5 minutes to create a document of the pain points you saw during the test. Pay special attention to the ones that caused users to be unsuccessful in completing a crucial part of the task or where it took them an unusually long time. Share this document with your team and use it to guide decision-making about the next few tickets your engineers decide to work on. It beats backlog grooming and your users will love you for it.

![Stack of books next to post-its](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/kszlgwyeydjybypctcfv.jpg)

### Closing Thoughts & Further Reading

So that’s how you find UX problems without pulling all your hair out or even looking at the backlog. You can do this all in a 3–4 hour session (sometimes even faster), often costing you nothing more than your time. You can rinse and repeat this process with more users, different scenarios, new features, etc. and it has the potential to save you thousands of dollars and bring you thousands of happy users.

If you want to learn more about DIY Usability Testing I recommend [Rocket Surgery Made Easy](https://www.amazon.com/Rocket-Surgery-Made-Easy-Yourself/dp/0321657292/ref=sr%5F1%5F1?dchild=1&keywords=rocket+surgery+made+easy&qid=1627597298&sr=8-1) by Steve Krug, which is the book from which I stole most of these ideas. Krug’s second book, [Don’t Make Me Think](https://www.amazon.com/Dont-Make-Think-Revisited-Usability/dp/0321965515/ref=sr%5F1%5F3?dchild=1&keywords=rocket+surgery+made+easy&qid=1627597298&sr=8-3), is also quite good if you’re interested in UX more generally.

And if this all sounds too time-consuming and you want a team of expert strategists, designers, and engineers to find and fix your usability problems for you then reach out to [Echobind](https://echobind.com/contact). We’re good at writing blog posts and even better and designing and building apps.

---

[View on echobind.com](https://echobind.com/post/how-to-find-the-top-usability-problems-on-your-app-or-website)

---

# Learnings From Forking an Open Source Project

> Jul 29, 2021 | Lessons from forking an existing open source React Native app, learn from our key takeaways from this recent client project.

_By Dominic Sherman · 2021-07-29_

In a recent project for a client, we were asked to fork an existing open source [React Native](https://reactnative.dev/) app, restyle to match the client’s branding, as well as add some additional features; all this while still maintaining the existing functionality of the app. While this may sound like a simple enough task, it proved to be much more difficult than we could have foreseen due to the way that the existing application was written, making it very difficult for others without tribal knowledge of how the app works to contribute without breaking features. Like we do with all of our projects, we took time to reflect. We wanted to understand specifically what about this code made it so difficult, and what we would do differently. Here are our key takeaways:

## Storing Data in Global State 🚫

A common practice, and one used by this app, is to pull all your data from whatever APIs you need and then put it into global state (like [Redux](https://redux.js.org/)) for easy access within your UI. While this may seem simple on the surface, this type of workflow typically leads to a slew of issues for developers as well as bugs that affect users. There’s a lot more that developers have to think about that could lead to potential issues.

**Loading and error states** — Every time a request for data is made, developers have to keep in mind that their UI has to handle more than just the happy path. This means that when making a request, they have to think about what it looks like to the user while the request is loading and if the request fails. If all their data is being stored in redux, they have to set up a way to manage these loading and error states _for every single request they make_.

**Data being updated from anywhere** — A common issue we have seen is data being changed out from under the user on a screen. For example, the data loads in and the user sees the initial data for a second or two, then another job finishes that changes the data and there’s a flicker to the new data. This is a very poor user experience and usually a very hard bug to fix, since so many different things could potentially be updating the data. You also have to think about race conditions, where you are reliant on one job finishing before another in order to have the proper user experience, but this may not always be the case since server load times can be unreliable.

**Keeping local data in sync with the server** — Whenever data is updated through a user action within the app, that change has to be reflected correctly within your local state. This usually means an API request is made to update the data on the server. While this request is being made a loading UI is displayed to the user. Then on success the redux state is updated, and finally, on error a dropdown is shown and the redux state is not updated.

While all of these things are possible to implement cleanly, it is very difficult for every developer to have all the context necessary to do this correctly every time. These are all things that could be easily mishandled which in turns leads to a very poor user experience, bugs, and crashes if not done correctly. Here at Echobind we prefer to use packages like [Apollo Client](https://www.apollographql.com/docs/react/) or [React Query](https://react-query.tanstack.com/) to manage all of these things for us. These packages serve as your data and caching layer, and provide built in loading and error states, polling, refreshing, and many other features that we utilize on a daily basis. While these features are possible to manage yourself using redux, it can very easily go wrong. Even if done correctly, it is difficult for other developers to also do so correctly. In order to ensure the most optimal success you would have to have clearly documented all of the potential flows and hiccups.

![Sand Timer](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/mpd7q4whrvveaq8di65q.jpg)

## Over-Optimization 👎

It’s no secret that one of the biggest counter-arguments to using React Native is that there can be performance detriments due to the need for the bridge between JavaScript and native code. The most common situation where this arises is when there are large lists of hundreds of items updating and causing unnecessary re-renders. There are ways to circumvent these potential issues, either through performance-focused libraries or writing native code directly and importing into your React Native project. While there are certainly cases where this is necessary, and is something that should be kept top of mind for any React Native dev, it is not _always_ necessary. There were a variety of instances in this app where they seemed to be optimizing the code and adding a large amount of complexity for a screen or component that didn’t need it. For example, the main list screen on the app used a package made for performance that required predefined heights of components within its list. The logic written to make this list work well took several thousand lines, across multiple files that was very difficult to follow and make changes to. Simply changing the order of two sections within the list turned out to be an entire day of work. Rather than continue to work within this overcomplicated list and waste valuable time, we decided to rewrite it using React Native’s default [SectionList](https://reactnative.dev/docs/sectionlist) component, which performed just as well for our needs and slimmed down the thousands of lines into about 150 of more readable code. These types of unnecessary abstractions, by bringing in a package that now requires extra context for devs coming into the app, as well as the amount of code necessary to use it effectively, only makes things harder, buggier, and more time consuming if they aren't necessary. These types of performance enhancements should be used very intentionally for use cases that require it rather than by default.

## Consistency is Key 👌

It is crucial when working on a project with multiple developers to be on the same page in how you write code so that there is consistency across the codebase. The importance of consistent, readable, well-written code cannot be understated when it comes to the quality and stability of an application. Some examples of key points that most applications should consider:

* Separation of concerns (keeping logic separate from UI, for example)
* Consistent data, service, and mapping layers (where does data come from, how do we keep it formatted consistently?)
* Standardized UI library or styling system (what’s the easiest way to keep a consistent theme?)
* Reusing functions and components (how can we isolate necessary changes to be made in a single place for given logic and UI?)
* Scalability (how can we make it easy to add additional X?)

These types of architecture decisions all serve to make the application easier to contribute to and maintain, saving time and money for everyone as well as providing a more robust application. None of them are easy decisions to make, and require architecture planning, internal conversations on code standards, extensive PR conversations, refactoring, and documentation. All of these things are essential to keeping an application running like a well-oiled machine, and without regular and consistent conversation it will quickly become a legacy monolithic application that is painful to make even the simplest changes within.

![iPhone on a table](https://res.cloudinary.com/echobind/image/upload/v1661872447/echobind_blog/cs7dupyk4oanmpqpc88q.jpg)

## Write Once 📱

“Write once, run anywhere”. This is one of the greatest advantages provided by React Native, and allows teams to move much quicker with half the devs by sharing iOS and Android codebases (as well as potentially web, desktop, or even TV). While it is possible to run the exact same React Native code on iOS and Android, it is also possible to separate files out by prefix (i.e. `Foo.ios.js` and `Foo.android.js`) so that they are run only on the respective platform. There are some edge cases where this can be useful, but is generally avoided due to the duplication of code necessary across files to maintain. The preferred path would be to use the `Platform` library within a single file to make selective logical decisions based on the platform, to minimize the surface area of separation between platforms. In this application, we found these separate files used in many cases, as well written in native iOS as well, meaning some components were written 3 different times. From what we found, none of these circumstances required this type of platform specification, and the "performance enhancements" provided by adding the native component as well were unnecessary. All of these changes just added additional logic and complexity that can lead to differences on platforms and additional bugs as any change has to be made in 3 different places.

## Documentation 🙏

As stated above, documentation is a key aspect of a well-written application. It is immensely helpful to have documentation of standards for a project to help ensure all the devs on the project are in agreement on how code should be written, and to quickly onboard new devs to how things work. This is extremely important when writing libraries or packages consumed by an application, especially if it is written and deployed in a different codebase. There were instances where libraries within this React Native app had been forked, modified extensively, and then deployed and consumed by this package without updating any of the documentation. This makes usage of this package very difficult, given the only way to understand how it is used, and even more so, what’s possible, is to review the source code directly; which can be time-consuming and difficult.

No two projects are the same, and at Echobind we are continuously evolving our technologies and standards to improve our applications and developer experience. While the technologies may be changing, there are core development principles that drive our decisions and provide a base to build off of for every engineer. These are the underlying themes across all of our projects that provide us the consistency necessary to be efficient, effective engineers.

---

[View on echobind.com](https://echobind.com/post/learnings-from-forking-an-open-source-project)

---

# Love ’Em or Lose ’Em: Employee Relationships 101

> Jul 22, 2021 | Helpful strategies for being a better employee as well as helping your manager be better at their role.

_By Mariah Grey · 2021-07-22_

‍Maybe you’re coming into this book review thinking “Catchy title, but I’m not managing anybody” and that’s a fair thought! After all, the full-length title is “[Love ’Em or Lose ’Em: Getting good people to stay — 26 engagement strategies for busy managers](https://bevkaye.com/)”, so how can you apply these strategies as an employee? Let me tell you how to use them for yourself, and how you can use them to help your manager be the best they can be for you and your colleagues!

## **_Ask:_** _What Keeps You? What do you really want?_

Consider what your manager can do to keep you (the talented employee) where you are! They should be asking this kind of question often and listening carefully to your answer. They should also be partnering with you to help get more of what you want, where you already are. If no one is asking you these questions, start asking them of yourself and presenting those findings to your manager.

Maybe you’re thinking “A raise would make me want to stay!” and yes, money may help in the short term, but if you really want to work from home two days each week, or you’re itching to learn something another department handles, you may end up looking elsewhere once the glow of that raise wears off.

If your gut response to “What keeps you in your current job?” or “What more do you want from this job?” was “I don’t know” then make this a reoccurring question you ask of yourself until you’re ready to respond with a clear answer. The top 5 reasons people stay, according to Love ’Em or Lose ’Em authors [Beverly Kaye](https://bevkaye.com/about/) and [Sharon Jordan-Evans](http://sharonjordanevans.com/about/), are as follows:

* Meaningful, challenging, and exciting work
* Supportive management/bosses
* Being respected, recognized, and valued
* Career development, growth, and learning
* Flexible work environment

Are you surprised that fair pay isn’t on that list? It’s actually number 6! It is key and plays a factor in what keeps people around, but it won’t do the trick if they’re already unhappy or dissatisfied in the other important areas.

## **_Buck:_** _It Stops here._

Many managers tend to blame upper management or lack of funding completely for their inability to keep good people where they are, but what it really comes down to is _them_. Most of the important factors in employee satisfaction, commitment, and engagement are in their hands! As mentioned under **Ask,** we know that chances to learn and grow, engaging work, recognition, respect, and a good boss fall under the top things that keep us around, and all of those are within your manager’s control. We thrive on relationships, and [research has shown](https://www.inc.com/marcel-schwantes/why-are-your-employees-quitting-a-study-says-it-comes-down-to-any-of-these-6-reasons.html) that 75% of voluntary turnover is influenced by management.

At Echobind, our managers do a great job of building these relationships! During my time here, I have had two managers who were consistent with seeking ways for both myself and themselves to improve as well as by effectively communicating areas where I’m doing well.

Admittedly, managers do not have total control, as they are bound by their own managers, budget constraints, and policies or culture. These things may present more of a challenge, but thinking outside the box, or simply considering the requests instead of a quick “No, we’ve never done that before” will go far in the influence of making employees feel heard within the workplace.

**_Careers:_** _Support Growth. Are they helping your future or standing in your way?_

Career opportunities are one of the top reasons that people stay where they are and produce. Many excuses may be preventing your manager from starting the conversation on this topic, but starting that talk about your abilities, ideas, and choices opens that dialogue. If your manager tends to ask yes or no questions, offer up topics that you can steer into deeper answers, such as:

* This is what makes me unique in our organization
* Here is a list of what I am proud of accomplishing in my time here
* My most important work-related values are… They are/are not met here.

This may be uncomfortable for those of us who are not natural “braggers” but you should be proud of what you bring to the table and voice those things. Seek out development feedback, the kind that is focused on the future and targets areas with a need for improvement. Most people have a desire for constructive criticism when it has the potential to help them grow their careers. Remember, these kinds of meetings are yours to steer — if you want more feedback regarding areas you need improvement in, ask for it! Make sure your career goals are in line with reality (IE: the next step is not a multi-level jump within your organization and matches the growth you are working on).

Also, consider other departments that you may not currently be part of: does the sales team have an opening that matches well with your skills? Sometimes career growth can be a sidestep instead of an upward move, it could be an expansion of responsibilities within your current role, or it could be a relocation. Obviously, that last one is the last resort for when your aspirations cannot be met where you currently are. Making sure you are aware of upcoming opportunities within your organization can allow you opportunities to consider the alternatives to seeking other employment.

Echobind has supported my career growth by maintaining what we call the “career ladder”. This is a chart that outlines clear expectations for each level of software engineer (as well as having separate tracks for our creative and strategy teams) throughout the entire company. This makes it easy to evaluate where you are fitting in and what level you are accomplishing work at.

Making sure you also have a career plan increases your commitment to growth. It allows you to pinpoint any potential roadblocks and plan for responses to them. Your manager should care about you and your career — it benefits them to have you engaged and growing in their team.

## **_Dignity:_** _How do they show respect for you?_

The behavior that most talented people refuse to tolerate is disrespect. If your organization wants to keep you (a talented person), they need to recognize your unique qualities and show respect consistently, in irrefutable ways. Our differences are part of what makes us valuable as employees, part of what we bring to the table. Things like cultural differences, geographical location, learning style, and personality can all bring challenges, but also tremendous benefits if we’re willing to figure out how to utilize each person’s talents. Valuing diversity does not necessarily mean changing your feelings, but it does mean treating everyone with respect and valuing them as a part of your team.

Another part of treating others with respect means managing your moods — yeah, yours! If you are guilty of having rollercoaster emotions (and we all have _those_ days), you need to notice and work on controlling them. We all have big feelings, but handling them so that they do not hurt others is the right way to deal with them. If you have a moment where you slip, then apologizing is the right next step. We all make mistakes, and you show respect for your coworkers when you acknowledge those slip-ups.

The last piece of dignity we’ll cover here is trust. When you treat others as trustworthy, they feel respected. Think back to a time when a boss allowed you to complete a task in a way that wasn’t “by the book”. You probably felt like they respected you and trusted you to get the job done!

Respect goes both ways, and to quote Remember the Titans: Attitude reflects Leadership. Our actions are sure to reflect our attitude, and by that, the chain is formed. If our managers lead with a positive and respectful attitude, their employee’s actions will display that.

## **_Enrich:_** _Energize The Job_

The most valuable employees (ie: YOU!) are the most susceptible to boredom within their day-to-day jobs because they are normally creative, self-propelled, energetic workers. They need challenging work and opportunities for learning. Lack of such opportunities or work may make you consider moving on, or worse — simply make you disengage or provide mediocre effort in your daily tasks. The good news is, this is a preventable or actionable issue! All it takes is a manager willing to allow room for initiative, creativity, or implementation of new ideas. Letting you (that talented employee, once again!) contribute to or set goals within your projects or sculpt the process of how things are done allows you to feel involved and refreshed, which is exciting!

You might be wondering why, if enrichment is so helpful, why it isn’t standard practice? The answer is because what enriches the job is totally dependent on each person’s _feelings_. Some people want to teach and mentor, others seek variety in their daily work. You can start energizing your work by asking for it! If you’re bringing this conversation up, you can also tailor your requests for change in ways that are specific to how YOU want to be doing things.

At Echobind, they’ve set aside roughly 8 hours each week for our team to do just this. We have investment time, where we can dedicate that time toward thingsthat helps us grow as engineers and benefit the company. The opening lines of the employee handbook state: “_While client work is our top priority, Echobind also invests heavily in employee development. One of the biggest ways we do this is through scheduled investment time. It is up to each employee to work with their manager to determine the best approach to leveraging investment time. The goal of investment time is to invest in Echobind, the team, and each individual, so investment time is structured around concrete individual quarterly goals with that in mind._” Ideas that have been suggested are producing blog content (like this post!), contributing to open source projects (like Echobind’s [bisonapp)](https://github.com/echobind/bisonapp), or taking on mentorship opportunities.

By this point, you’ve probably realized that part of helping your manager be their best involves taking an active role in advocating for yourself. It can be challenging but it is also just one more way that you can make your job more rewarding for yourself.

## **_Family:_** _Get Friendly._

Would you leave your organization over work/family conflicts? Yes! Lately, it’s become a hot topic in business magazines to talk about “family-friendly culture”, but break that down into more than buzzwords. People want a workplace that allows them to balance their personal lives and their work lives, instead of expecting them to choose work over family. Employers are beginning to recognize this, and you see it reflected when they offer perks like:

* Flexible work schedules
* Remote work
* Extended maternity and paternity leave programs
* Childcare and Eldercare assistance programs

Giving people flexibility in how, when, and where they work is becoming more and more popular. If your organization already offers these, that’s awesome! If not, you can reach out to your HR department with information and suggestions on what would make you a more dedicated, energized employee. The other option would be to approach your manager about being family-friendly. They are more directly able to approve things like starting meetings only after 9 to ensure that those with kids to get to school don’t miss anything important to their work. Minimal things like that send the message to your team that their work-family balance is important to your manager.

It’s important to note that family doesn’t necessarily mean the stereotypical picture of two parents and little children. It can, but it also means single people (and their pets!), newlyweds, those caring for elderly parents, or members of a large extended family. One strategy will not fit all of these cases, so there should be policies built to work best for each. The more flexibility an organization can offer, the more employees grow committed and loyal to that company.

## **_Goals:_** _Expand Options_

While you probably have many goals for yourself, this is focused only on career-related ones. This boils down to goals for learning, growth, and success at work! this ties back into energizing your work — you need to be growing, stimulated, and offered new experiences. Beyond finding a new job, It could look like this:

* Enrichment: Growing in place
* Lateral moves: Moving across or horizontally
* Realignment: Moving downward to fresh opportunities

You may need to consider a change in department, location, or responsibility. It could even be a physical move, such as to an office within the company but in another city, state, or country!

It doesn’t have to be that dramatic of a change though, it should begin with enrichment. Doing what you can to learn and develop further is the easiest place to start. The biggest question to consider is: What can employees do, or learn to do, that will energize their work and bring them closer to achieving their goals and the goals of the company?

Lateral moves give the opportunity to diversify your skillset. It means applying your current experience in a new job at the same level with different challenges. It also gives talented employees (Yoo-hoo, you!) a chance to help expand and grow in and with the organization.

Realignment is a sticky topic. Most people view it as a demotion, and that’s the opposite of what we want, right? However, a step back can ease job stress or put you back into a role you really enjoyed. Careers shouldn’t be thought of as only moving up. It’s good to try out the next step if you have the opportunity, to see if it’s the right fit, but after giving it some time, if the fit isn’t there, don’t be afraid to take a step back. If you’re part of a supportive company, work with them to see what opportunities are available within any part of the organization. Most companies would rather keep a good employee and find the right fit than lose a good employee altogether.

Sometimes, these aren’t the answer to your goals. That’s what brings us to moving up or moving on. Sometimes, there is a chance to move up within the company, and sometimes you’re in the wrong place at the wrong time or just the wrong fit for the spot. It happens. This is when you usually start looking around for other opportunities that better align with your goals. Make sure you’re not missing something that would make you the right person, at the right time, for the right spot within your own company by talking with your manager.

## **_Hire:_** _Fit Is It_

This chapter is mainly management-directed since as an employee, they’ve already hired you! That doesn’t mean though, that you can’t be paying attention here though. By seeing what your managers are looking for in the people they bring on to your team, you have a great chance to highlight your own strengths and weaknesses to become the best team player, and discover ways to increase your own value to the organization. This may encourage you to level up your technical and communication skills, and leadership abilities.

I hope this taste of _Love ’Em or Lose_ ’Em has inspired you to bolster your relationship with your manager and advocate for yourself to have the best job experience possible. If you’re hooked, read on for topics from Information to the Zenith: going for it.

---

[View on echobind.com](https://echobind.com/post/love-em-or-lose-em-employee-relationships-101)

---

# Alexa Skills

> Jul 16, 2021 | Updated and curated content to get you started in the world of AI with Alexa Skills.

_By Deloris Thompson · 2021-07-16_

‍*This is an updated version of a previous Echobind blog post. This new version still contains valid parts from the original found* [_here_](https://echobind.com/post/how-to-easily-create-custom-skills-for-alexa).

## **Getting Started**

The first step in creating an Alexa Skill is signing up for a [developer account](https://developer.amazon.com/). Once you are signed up/logged in select [Alexa](https://developer.amazon.com/en-US/alexa). This will bring you to the Alexa homepage, click on the **“Create Alexa Skills”** button.

You are now on the Alexa Skills Kit dashboard, click on the “Register Now” button on the right-hand side to navigate to the [Developer Console](https://developer.amazon.com/alexa/console/ask).

_If you are not logged in you will notice the button is “_ **_Console_**_” instead of “_ **_Register_** **_Now_**_”. You can still click “_ **_Console_**_” and this will bring you to the sign-in page (it will also allow you to sign up if you have not done that yet)._

## Creating a new Skill

Creating a new skill requires clicking the “**Create Skill**” button on the right-hand side.

A lot is going on here so let’s break it down.

![Create a skill page](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/dc6zjon2na1egyi9yz0w.jpg)

![Create a skill page](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/mg2p3uek5fiakcxfzkbi.jpg)

A. This is where we set our skill name.

B. **Default Language** — This is our skills default language(English). We can add more later.

C. **Model** — There are a lot of really great pre-built skills. We are going with the Custom model; it allows us to create a custom model with the required skills and a Hello World skill.

D. **Method** — Skills require hosting; you can either have Amazon host them or handle them yourself. Node.js, Python, and `Provision your own` are the methods you can choose from. Select Provision your own since we are connecting our skill to our Rails application.

Click “**Create Skill**”

## Choosing a Template

The templates provided by Amazon give you a great starting point, we are going to leave it on `Start from Scratch` and click "**Choose**"

![Alexa skills page](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/d70bfwu1cmygltsf7evv.jpg)

This will start building your skill with everything we selected. Once finished it will forward you to the `Developer Console`.

![Alexa skills page](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/ochqhlyqaxoj3qcgatkn.jpg)

## Developer Console

The developer console is where the magic happens. It allows us to set everything we need for the skill.

![Alexa skills developer console](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/xvr1lufqiu9wkcs0vcor.jpg)

A. **Invocation** — This is where we set the **Skill** **Invocation Name**. The Skill Invocation Name is what the user says to begin interacting with our skill.

B. **Interaction** **Model** — This is a combination of utterances, intents, and slot values.

C. **Intents** — Represents an action that fulfills a user’s spoken request.

D. **HelloWorldIntent** — This is a really great freebie that we can ignore or even delete.

E. **Built-In Intents** — These are the minimum requirements for all Alexa Skills. They are not to be removed at all.

Now that we have a better understanding of everything the developer console offers, we can set the invocation name. Click “**Invocation**” on the left-hand sidebar and let’s continue with the Pokemon theme and name it `i choose you`.

There are a few requirements for an invocation name:

1. Must be all lowercase why? Well, simply put Alexa is going to take any response and make all the characters lowercase. This is going to be important when we tell Alexa we want to interact with the new skill.
2. Must be at least two words.

![Alexa skills developer console](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/c5frdnf7rjicuofhjg4f.jpg)

Now that we have the name click “**Save Model**” and wait for the confirmation alert on the bottom right-hand side of the site. Once the save is finished click “**Build Model**”. This is required for all new changes to take effect. The bottom right-hand side will display a small alert letting us know if the build was successful or not.

## Intents

Intents are nested under the Interaction Model dropdown. Click "**\+ Add Intent**" to do just that.

![Alexa skills developer console](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/x77c2gucloka5nzle4rq.jpg)

We are going to keep this part simple with only a couple of intents. For more information on intents, see this [section](https://developer.amazon.com/en-US/docs/alexa/custom-skills/create-intents-utterances-and-slots.html) of the Alexa documentation. Intents are always PascalCased. Once you add the name click “**Create custom intent**” to begin adding utterances.

![https://cdn-images-1.medium.com/max/800/1*27bEIZgYr60K2hyfcJ24Tw.png](https://res.cloudinary.com/echobind/image/upload/v1661872449/echobind_blog/nea6yaamglj7nw3fbtd6.png)

## Utterance

An utterance is a user’s spoken request. When adding an utterance think of all the possible questions a user will ask for the intent. One user might say **what is the hottest pokemon?** while another would ask **what’s the hottest pokemon?** or even **who is the hottest pokemon?.** Taking the time to map out these questions will greatly improve your skill and user experience. At this point, our skill doesn’t have an utterance so let’s add some. Hitting “**Enter**” will automatically add the utterance.

![https://cdn-images-1.medium.com/max/800/1*z7jhrhx3FfvfxXLopIsepQ.png](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/jmt0vadfigdoya9qpqjv.png)

**List of Utterances**

![https://cdn-images-1.medium.com/max/800/1*_jkmwhZsWZXLeoj9L3Ctfg.png](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/kt2byprxvbv1mtuovmmm.png)

Let’s pause the skill configuration for a second. Breaks are important so let’s take a small one and pat ourselves on the back.

## Setting up your application to talk with Alexa

Let’s set up our application to handle Alexa’s requests. For this section, we’re going to assume you have a [Rails](https://rubyonrails.org/) API available.

**Create a new controller for requests from Alexa.**

```ruby
rails generate controller api/alexa/handlers create
```

Alexa will hit our server with POST requests. These requests will contain data, like an access token, Intent name, etc. To get these requests, let’s create a new controller. I like to namespace mine, so I opt for `api/alexa/handlers_controller.rb`

In this controller, you’ll note that I return an odd piece of JSON. A lot of this is the boilerplate you need for Amazon. The most important part is the “outputSpeech” section. [Here is the documentation](https://developer.amazon.com/public/solutions/alexa/alexa-skills-kit/docs/alexa-skills-kit-interface-reference#response-examples) to learn more about responses and requests from Amazon. For now, we’ll stub out a simple response “**Hello from Pokemon Hot!**”

```ruby

class Api::Alexa::HandlersController < ActionController::Base
  def create
    message = "hello from Pokemon Hot!"
    session_attributes = {"previous_session": "something"}
    session_end = true
render json: {
      "response": {
        "outputSpeech": {
          "type": "PlainText",
          "text": message,
        },
        "shouldEndSession": session_end
      },
      "sessionAttributes": session_attributes
    }
  end
end
```

and update your routes file

```ruby
#config/routes.rb
  namespace :api do
    namespace :alexa do
      resource :handlers, only: [:create]
    end
  end
```

Once you’re finished make sure to restart your Rails server.

## Install ngrok for SSL locally

[ngrok](https://ngrok.com/) will host a local version of our app, and allow Amazon servers to speak to it. Amazon requires our server to have SSL. We don’t want to host a [Heroku](https://www.heroku.com/) SSL instance simply for testing, so ngrok will work perfectly.

```bash
brew update
brew cask install ngrok
```

After installing ngrok, set it to run on whatever port you’re running your Rails server on. In our case, it’s good ol’ port 3000.

```bash
ngrok http 3000
```

![https://cdn-images-1.medium.com/max/800/1*XNaDFezO0YRCFNAtTAEbdA.png](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/pxoqaygiizt2xiodotmk.png)

There is one final step for ngrok. We need to let our rails application know we want to use it as our host. Open `application.rb` under your config directory and add

```bash
config.hosts << "0135acf2debd.ngrok.io"
```

Do you see that HTTPS link above? That is what we’ll tell Alexa to communicate with.

## Get Alexa to talk to us

Now that we have:

1. ngrok tunneling our application to HTTPS
2. we have our controller and route

Let’s point Alexa at our application. Go to the Alexa skill you created earlier, click on “**Endpoint**” in the left sidebar. The default setting is **AWS Lambda ARN**, let’s change it to **HTTPS** and paste in the HTTPS link from ngrok, including the route we created Ex: 

https://0135acf2debd.ngrok.io/api/alexa/handlers. We also need to let Alexa know we are providing our own certificate. Since we are only testing we can use ngrok to handle our SSL certification. Select `My development endpoint is a sub-domain of a domain that has a wildcard certificate from a certificate authority` and click "Save Endpoints":

![https://cdn-images-1.medium.com/max/800/1*WjhgM_GI-ednNOs_1bLnJw.png](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/ifzcfzkfxjpciuvlx3sg.png)

It’s testing time!!!

Go to the “**Test**” tab in your Alexa skill. Testing is automatically turned off.

![https://cdn-images-1.medium.com/max/800/1*6ulpWdly_XSKj9n19cEiHQ.png](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/taz7vfuucagbjhzthg4k.png)

We can enable `Development` mode from the drop-down.

![https://cdn-images-1.medium.com/max/800/1*FdfrJReVu-fAHqUPJWMrkQ.png](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/vol582a70nr55wgxfgdn.png)

Now we can test our skill!!

![https://cdn-images-1.medium.com/max/800/1*tnRzy0hbc0OwOoyTEgCneA.png](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/rw4px5nexw141ai78o7z.png)

Type in your invocation name. You should see output similar to below:

![https://cdn-images-1.medium.com/max/800/1*8Wk08sxliQRfh4naDafVIA.png](https://res.cloudinary.com/echobind/image/upload/v1661872448/echobind_blog/iwe5tpa4bkp8con0re1a.png)

Great Job! You see we got a response back from our API. This post just skims Alexa skills. There are other features like slot values and more.

[Create Alexa Skills Kit | Amazon Alexa Voice Development](https://developer.amazon.com/en-US/alexa/alexa-skills-kit)

---

[View on echobind.com](https://echobind.com/post/alexa-skills)

---

# My Journey to Engineering

> Jul 08, 2021 | Come along and discover how Paul, our Engineering Manager came to the industry.

_By Paul Buendia · 2021-07-08_

## Finding My Path

I have always found it interesting to learn how people find their careers. One of my favorite things to learn about is how software engineers came to the industry and why. For some, it is a very straight and deliberate path through school, for others it’s more of a round about self evolution via boot camps or classes, and even more interesting can be the stories of those who are almost naturally in the industry over years and years of personal projects. Today I thought that I would take you on my journey that led to finding my path as a [software engineer.](https://en.wikipedia.org/wiki/Software%5Fengineer)

![Empty office space with many chairs and desks](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/ddvckbyfqojkohytncaw.jpg)

## The Foundation: A foot in the door

I started my career in the technology field as a phone support technician. The hours were long and we worked in an office with rows and rows of cubicles. We seldom sat at the same desk for each shift so we had to remember to clear our belongings after each day. This really made work life feel nomadic, but as a recent college graduate I was happy to have a good and stable income!

To be honest, the job wasn’t designed to keep employees for years and years, but it was great for learning and education. Every few weeks new clients were brought on, and I shifted teams as needed. We were trained in different aspects of computer related technologies. At this job I learned about personal computers (PCs), servers, routers, networks etc.

This broad technical training and knowledge acquisition became very useful in my career, but what I consider to be the best knowledge was learning how to describe and lead another person through a complex task using creative descriptions. I remember one of my proudest moments of my career was walking a small business person through installing a motherboard into a computer over the phone. I can still remember how happy he was when we could start up the computer so he could go back to running his small business. It was a long and tedious conversation, but as they say every experience has its rewards and gems of knowledge.

![An iPad, some coffee and paper](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/fuvtgyp5znc6c3py8j9m.jpg)

## The Next Step: Adding people skills

As the months passed at the phone support position and I accrued more knowledge, a recruiter let me know that a local company was hiring. It was a small chain of medical related facilities that needed on-site support technicians. There were only two positions and a lot of applications, but I took the chance, applied, and got the job. This was a huge opportunity for me as there was a chance to get some hands on experience with servers and administering them.

Employment at this company was great for me. My prior training at the phone support job translated directly into building racks of servers, administering and maintaining those servers, and setting up wireless networks in the medical facilities but more importantly I was now working in person with the employees in other departments. It was a fun transition, and I gained an appreciation for how much knowledge could be transferred in an in person environment.

For several years, I learned more and more from on the job training and became a trusted member of the technology department. As the time passed my duties and responsibilities were growing along with the company. They eventually evolved into learning [SQL](https://en.wikipedia.org/wiki/Transact-SQL) and helping with report writing for the company. Along with this new responsibility came the opportunity to work with the management team who were requesting the reports. It was daunting at first to work directly for the C level executives, but it definitely paid off in the end in the form of the coming opportunity.

![A graph of a random stock market](https://res.cloudinary.com/echobind/image/upload/v1661872449/echobind_blog/fgmaw96bvrm3upszozrx.jpg)

## Taking the Opportunity

One day, after several years at the company, I arrived at the office to find a lot of activity and discussion among the managers that I worked for. It had turned out that our only software developer had decided to part ways with the company. This developer had been working on a proprietary invoicing system for use at all the facilities since there was no software available to suit our company’s needs. His leaving left a significant void in a key piece of software for the company. As I recall, we tried several different contractors and other full time developers that either didn’t work out or wanted to rewrite the software from scratch leaving a large question as to when the project would be finished.

Then the opportunity arrived. I was offered the chance to try and fill the last developers shoes. At that point in my life, I hadn’t ever really considered becoming an application developer. It was exciting but at the same time there were so many unknowns to consider. I knew that leaving my position would mean that they would hire someone to fill my current position so there was a fair amount of risk involved. It was a difficult decision, but with the promise of training and an understanding that the management team would work with me, I took the opportunity. I spent the next two months in code bootcamp learning [markup languages](https://www.techopedia.com/definition/2668/markup-language) and how to integrate those with the SQL skills I had obtained over the past couple of years.

I returned from the training with a new excitement for work, and went on to be a major contributor in writing the invoicing application that was used several years after the company was bought out by a larger company (a little piece of information that I still feel some pride in to this day). Needless to say I have been happily in the software development industry ever since.

## Being a Software Engineer

Being a software engineer is an amazing path to choose as a career. I highly recommend it to those who are considering it. There is seldom a boring day in the life of a software developer. Every day there is a new problem to solve and something new to learn. The field is evolving and changing every year so there are endless amounts of lessons to learn and puzzles to solve.

With every project you get the opportunity to work on, you learn a little bit more about the world through its different industries. From my work experiences so far, I have had the opportunity to learn more about industries such as health care, sales, banking, grant writing, and the entertainment industry. Now working with Echobind I look forward to having the opportunity to work with many more companies and adding more value to the world through my work.

## Let’s work together

[Contact Us](https://echobind.com/contact)

---

[View on echobind.com](https://echobind.com/post/my-journey-to-engineering)

---

# Automated React-Native Release Tagging Using GitHub Actions

> Jul 01, 2021 | A recent client project led us to a solution that we’re proud of and wanted to share with others who may be looking for a similar solution.

_By Dominic Sherman · 2021-07-01_

In a recent client project, we set up automated iOS releases using [GitHub actions](https://github.com/features/actions) and [fastlane](https://fastlane.tools/). We had a couple different specifications for it that made it a little more challenging than normal:

* We wanted to be able to kick off the release both manually and on a schedule
* We wanted to have tags created every time a build was created, and wanted this to be automated
* We wanted to be able automate version bumps so that we didn’t have to make local changes to the version in the codebase

This led us to a solution that we’re proud of, and wanted to share with others who may be looking for a similar solution. The basic idea was that we set up a tagging process that was kicked off either through a manual workflow dispatch or a scheduled run. The tag being created triggers the release workflow, which receives the tag information and creates the release off of it.

## Automated Tagging

To set this up, we create a `tag.yml` file which has jobs that are triggered either on manual dispatch or on a schedule. The manual dispatch receives an input for the `versionChangeType`, which can be specified as either `none`, `patch`, `minor`, or `major`. That looks like this:

```javascript
name: Tag
on:
  workflow_dispatch:
    inputs:
      versionChangeType:
        description: 'Type of version bump (major, minor, patch, none)'
        required: true
        default: 'none'
  schedule:
    # Scheduled for 12PM UTC every Tuesday and Friday (8AM EST)
    - cron: 0 12 * * 2,5
```

Now we can configure the `create-new-tag` job to run. In order to do this, we need to first specify the `GITHUB_AUTH_TOKEN` we use to authenticate with GitHub's API for the tag creation, as well as the base branch in the repo. The `GITHUB_AUTH_TOKEN` should be put into the secrets of the repo. For instructions on how to create a personal access token, look[here](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token).

```javascript
jobs:
  create-new-tag:
    name: Create new tag with version bump
    runs-on: macos-latest
    env:
      GITHUB_AUTH_TOKEN: ${{ secrets.CI_GITHUB_PERSONAL_ACCESS_TOKEN }}
      BASE_BRANCH: 'main'
```

The next step is to set up the environment variables we will need to decide what type of version bump (if any) should happen with our tagging. Because this can be triggered either with an input or on a schedule, we can’t just directly use the input value. Instead, we wrote a bash script which checks for the version change type, with `none` as the default, and selectively outputs whether we need a version bump. It also outputs the branch name to tag, since we will be creating a branch and PR with our version change rather than pushing directly to the base branch. The way we set this up looked like this:

```javascript
- name: Set environment variables
  env: 
      DEFAULT_VERSION_CHANGE_TYPE: none
      VERSION_CHANGE_BRANCH_TO_TAG: 'release/${{ github.event.inputs.versionChangeType }}-version-${{ github.run_id }}'
  run: |
      echo "VERSION_CHANGE_TYPE=${{ github.event.inputs.versionChangeType || env.DEFAULT_VERSION_CHANGE_TYPE}}" >> $GITHUB_ENV
      if [$VERSION_CHANGE_TYPE != 'none']
      then
        echo "VERSION_BUMP=true"
        echo "BRANCH_TO_TAG=${{ env.VERSION_CHANGE_BRANCH_TO_TAG }}" >> $GITHUB_ENV
      else
        echo "VERSION_BUMP=false"
        echo "BRANCH_TO_TAG=${{ env.BASE_BRANCH }}" >> $GITHUB_ENV
      fi
```

We can now check out the main branch that we’ll be bumping the version off of:

```javascript
- uses: actions/checkout@v2
  with:
      ref: ${{ env.BASE_BRANCH }}
```

And then run our fastlane command to bump the version, but only if the `VERSION_BUMP` environment variable we set earlier is set to true:

```javascript
- name: Bump iOS version
  if: ${{ env.VERSION_BUMP == 'true'}}
  run: cd ios && bundle install && bundle exec fastlane version_bump
```

Our fastlane command also utilizes the `VERSION_CHANGE_TYPE` environment variable we have set above to know what type of version bump to do:

```javascript
desc "Version bump"
  lane :version_bump do |options|
    if ['major', 'minor', 'patch'].include?(ENV['VERSION_CHANGE_TYPE'])
      increment_version_number_in_xcodeproj(
        bump_type: ENV['VERSION_CHANGE_TYPE'],
        target: 'YOUR_TARGET'
      )
    end
  end
```

Now that our version has been bumped in the native code, we can check out a branch and make a PR for these changes:

```javascript
- name: Create Pull Request
  if: ${{ env.VERSION_BUMP == 'true'}}
  uses: peter-evans/create-pull-request@v3
  with:
    token: ${{ secrets.CI_GITHUB_PERSONAL_ACCESS_TOKEN }}
    branch: '${{ env.BRANCH_TO_TAG }}'
    title: 'release: ${{ github.event.inputs.versionChangeType }} version release'
    commit-message: 'release: ${{ github.event.inputs.versionChangeType }} version release'
    author: ${{ github.actor }} <${{ github.actor }}@users.noreply.github.com>
    labels: |
      release
      automated pr
    delete-branch: true 
```

The last step is to actually create our tag using GitHub’s API. In order to do this, we need to write a script that checks our most recent version and bumps it in the same manner that Fastlane bumped our native code. Another important piece for mobile is to have a distinguishing number differentiating the tags so that we can create a new tag without actually bumping the version. This allows us to have as many tags on a single version as we want, so that we only need to bump the version once the most recent one has been actually sent to users on the app store. The way we did this was appending an incremental number onto each version after a `-` so that we could see how many builds there were for a specific version. For example, if I created a new tag without specifying a version bump, and my most recent tag was `1.2.1-3`, then the new tag would be `1.2.1-4`. The Node script we wrote to do that looks like this:

```javascript
const createTag = async () => {
	// <https://docs.github.com/en/rest/reference/repos#list-repository-tags>
  const response = await fetch(
		// these environment variables are set for us in the github action
    `${process.env.GITHUB_API_URL}/repos/${process.env.GITHUB_REPOSITORY}/tags`,
    {
      headers: {
        Accept: 'application/vnd.github.v3+json',
        Authorization: `Bearer ${process.env.GITHUB_AUTH_TOKEN}`,
      },
    }
  );
  const data = await response.json();
	// most recent tag will be the first element
  const mostRecentTag = data[0].name;
  // split tag on '-' to separate version from specifying number
  const [tagVersion, tagVersionNumber] = mostRecentTag.split('-');
	// remove v from our version so we have 1.1.0 instead of v1.1.0
  const cleanTag = tagVersion.replace('v', '');
	// get the new tag with the version change type
  const newTag = getNewTag(cleanTag);
	// if the tag didn't change, increment our specifying number
	// otherwise restart our specifying numbers
  const updatedTagVersionNumber =
    cleanTag === newTag ? Number(tagVersionNumber) + 1 : 1;
	// put it all back together into our tag name
  const tagName = `v${newTag}-${updatedTagVersionNumber}`;
	// create tag off of the branch that we created with our version change
	// <https://docs.github.com/en/rest/reference/repos#create-a-release>
  await fetch(
    `${process.env.GITHUB_API_URL}/repos/${process.env.GITHUB_REPOSITORY}/releases`,
    {
      body: JSON.stringify({
        owner: 'YOUR_REPO_OWNER',
        repo: 'YOUR_REPO',
        tag_name: tagName,
        target_commitish: process.env.BRANCH_TO_TAG,
        name: `${tagName}`,
        body: `Released at ${new Date(Date.now()).toISOString()}`,
      }),
      method: 'POST',
      headers: {
        Accept: 'application/vnd.github.v3+json',
        Authorization: `Bearer ${process.env.GITHUB_AUTH_TOKEN}`,
      },
    }
  );
};
const getNewTag = tag => {
	// 1.1.0 becomes major=1, minor=1, patch=0
  const [major, minor, patch] = tag.split('.');
  if (process.env.VERSION_CHANGE_TYPE === 'major') {
    return `${Number(major) + 1}.0.0`;
  } else if (process.env.VERSION_CHANGE_TYPE === 'minor') {
    return `${major}.${Number(minor) + 1}.0`;
  } else if (process.env.VERSION_CHANGE_TYPE === 'patch') {
    return `${major}.${minor}.${Number(patch) + 1}`;
  }
	// if we didn't specify a version change type, don't change it
  return tag;
};
```

Now that we have that added, the last step in our action is just to run it:

```javascript
- name: Create tag
  run: cd ci-scripts && yarn && yarn createTag
```

If you want to see all the pieces put together, you can check out [this gist](https://gist.github.com/DominicSherman/aebfc35a6419f8a20a86d828b099f11c).

## Releasing

The releasing process is very specific to each project, and can vary depending on how you want to do certs, what set up steps you have, how you build your app, what fastlane commands you use, etc… Because of this and for simplicity, I’ll just show the basic set up of our release file, and leave the actual building and upload process out.

In order to time our release right to ensure that the scheduled tag workflow is finished before our release workflow runs, it made the most sense to just trigger our release workflow based off when a tag was created. This also made our release process a 1 step process, so that you only had to manually kick off of the tag creation instead of waiting for it to finish and then kicking off the release. We still wanted to allow a manual dispatch with a specified ref in case you wanted to create a release off of a specific branch, tag, or commit. We also wanted to allow the user to specify whether they wanted an `alpha`, `beta`, or `production` release, with `beta` being the default for the automated releases. For production releases, those will have to be done manually. That workflow definition looks like this:

```javascript
name: Release
on:
  workflow_dispatch:
    inputs:
      releaseStage:
        description: 'alpha, beta or production release (alpha does not upload to TestFlight)'
        required: true
        default: 'beta'
      githubRef:
        description: 'Github ref to build and release'
        required: true
        default: 'main'
  release:
    types: [created] 
```

The only other set up step after that is to ensure we checked out the correct ref and set the correct release stage. That looks like this:

```javascript
jobs:
  release-ios:
    name: Release iOS
    runs-on: macos-latest
    steps:
      - name: Set environment variables
        env: 
          DEFAULT_STAGE: beta
          DEFAULT_REF: ${{ github.event.release.tag_name }}
        run: |
          echo "CHECKOUT_REF=${{ github.event.inputs.githubRef || env.DEFAULT_REF }}" >> $GITHUB_ENV
          echo "RELEASE_STAGE=${{ github.event.inputs.releaseStage || env.DEFAULT_STAGE}}" >> $GITHUB_ENV
      - name: Checkout tag
        uses: actions/checkout@v2
        with:
          ref: ${{ env.CHECKOUT_REF }}
... all your app specific build/upload steps
```

Once you get the building/releasing working in CI, you should be all set with an automated workflow of tagging and releasing both beta and production builds, with the click of a button and on a regular cadence of your choosing 🎉

***To learn more about our React Native process at Echobind, visit our [React Native capabilities page](/services/react-native-app-development).***

---

[View on echobind.com](https://echobind.com/post/automated-react-native-release-tagging-using-github-actions)

---

# The Secret about The Secret

> Jun 24, 2021 | What makes a good leader? Find out in this unlikely book.

_By Mariah Grey · 2021-06-24_

‍Let’s kick things off with this very true statement: I don’t read self-help books, because they’re boring. When my sister recommended that I read [The Secret: What Great Leaders Know and Do](https://www.kenblanchard.com/Store/The-Secret), I took the book with the intention of repeatedly shuffling it to the bottom of my ‘to read’ stack until she wanted it back. That is until I heard her say that reading this book was the reason she had quit her job.

If I was asked “what is a leader?” before reading this, my answer would have been something along the lines of this: “A leader is someone who, by roles or responsibilities, is accountable for the success or failure of a team”. While that may be true, there’s so much more to being a leader than holding that responsibility. It’s about what they _DO_. The entire point of this book is summed up in this sentence: **_Great leaders serve_**. That’s it. Three words.

Jumping into it, leadership is like an iceberg: less than 20% of the actual job is visible — it’s more about what you don’t see than what you do. What you see initially in leadership are the skills possessed (what they know how to do), and what you don’t see is the character (Who they are behind the skills and what their motivation is). You need both skills and character to effectively lead, but someone’s skills are easier to develop than their character is. At this point you may be thinking, ‘Sure, sounds great, but I’m not in a leadership position. But you’d be wrong! True leadership has nothing to do with one’s level within an organization, you can provide leadership from wherever you are without holding a title of leadership. This concept was intriguing to me, as a new hire at Echobind, and I was curious as to how I could implement these concepts into my daily routines.

The biggest concept: Regardless of their formal title or position, people who want to be great leaders must embrace an attitude of service to others, or to put it simply, being willing to work for the good of others. You can serve without leading, but you can’t lead well without serving. Skills can be developed, but motivations are much harder to change. This is why becoming the best leader you can be will be a lifelong growth, you don’t master being a leader in a week, a month, or even years. The easiest way to grow as a leader is with the following breakdown of the acronym **SERVE**: **S**ee the future, **E**ngage and develop others, **R**einvent continuously, **V**alue results and relationships, and **E**mbody the values.

**_See the future — What is your vision for your group?_** To create a cohesive team, having a shared goal and plan for what’s next is key. Everyone needs to see who they are, where they are, where they are going, and what will guide their journey. This can be easier said than done — If that goal doesn’t fire you up, your team won’t be passionate about it either. The most challenging portion of this can be where to focus your attention, heads up vs. heads down. Heads up, broken down means you must consistently see and communicate the future, as well as anticipate opportunities and obstacles. Heads down would be implementing that vision, working alongside your people to make the vision reality. To lead, it is your job to keep your team on task and continuously replenish the vision, and involving your people in the heads-up work will gain their commitment to it.

A great way to keep the focus is by displaying the values you are striving toward. This makes them repeatable, recognizable, and rewardable, for positive results — Here at Echobind, our leadership does a great job of this! For example, our values are: [Be a great human, Be veracious, and Be curious](https://echobind.com/culture). All values need to be grounded in truth and reality. Otherwise, you lose credibility by not living them out. Values are a _big deal_. They’re what can make or break your leadership depending on how you embody them personally. Empowering your people can also help with sharing the progress toward goals. You can be asking questions like:

What information do you need to solve this?

What do _you_ think we should do?

By empowering our own teams, we build up their confidence and share the workload.

**_Engage and Develop Others — You must have the right people, in the right roles, fully engaged if you are going to meet the goals you set._** The big ideas here are selecting the right people for the job and building an environment where they can invest in themselves working toward the vision you’ve created together. Recruiting and choosing the right team member can be time-consuming but is less costly in terms of time, energy, opportunities, and morale than retraining or replacing someone who is the wrong fit for your team. Getting the right people in the right jobs is the first part of the term **_engage._** Part two is doing more than enlisting their hands — you want to gain their heads and hearts too. The best way to engage the brains of your team and not just their hands is to involve them in the work and planning. When you get their brain, you often gain their hearts as well.

If you look back on a favorite boss, chances are they made you feel valued and appreciated. When leaders realize that they work for their people, things get done more efficiently and effectively. The best leaders invest in the development of their people. Asking the right questions can help you leverage your strengths and those of your team. Questions such as ‘What are your strengths and Do they match the role you’re in?’ or ‘Are you in the right role? If so, were you trained properly? Do you clearly understand your responsibilities?’ can help lead you down the right path for finding the right fit for each role.

**_Reinvent Continuously — The very best leaders are learners, with a healthy disrespect for the status quo._** The R has three branches — implementing as a leader, as a team, and as an organization:

_As a leader: How am I learning and growing as a leader? What am I doing to encourage others on my team to constantly learn and reinvent themselves?_

_As a team: How are we doing the work? Do it better? What changes could enhance our ability to serve our customers and one another?_

_As an organization: What structural changes do we need to make to be more efficient & effective?_

These questions can help us keep up with the competition and rate of change in the world. If you stop learning, you stop leading. We can’t expect our team to be investing in themselves if we are not leading by example. How can we do the work better? How can we do it with fewer errors? How can we do it faster? For less? The team leader may champion the cause, but the people make it happen — or not. Work purposefully to engage the hearts and heads of your people.

**_Value Results and Relationships — Great leaders do BOTH._** When we value our _relationships_ we get better _results._ An easy way to maximize your results as a leader is to have high expectations for both results and relationships. You need to get to know people beyond who they are at work and what they do there. \*\*You might be thinking “But I don’t want to get overly involved in my coworker’s personal lives” and that’s a fair concern! We’re obviously not talking about prying here. But you _should_ be interested in listening to them when they are sharing their own concerns and issues that are impacting their work. \*\* People don’t care how much you know until they know how much you care. It’s not a one-way street, you need both the results and relationships. One simple way to do this is by finding ways to help them meet their goals. Goals tend to fall into the four categories of Be, Do, Have, or Help. Maybe one of your people wants to _be_ a better golfer — you could suggest a book you’ve read on the topic! If someone wants to _have_ a better work-life balance, you can sit down together to try and figure out how to make that happen. These are not _BIG_ or _DIFFICULT_ things to do, but they show your team that you care and are listening.

**_Embody the Values — Walk the Talk, Don’t Stumble the Mumble._** This is fundamental and ongoing. If you lose your credibility as a leader by not being a person of integrity, your leadership potential is greatly limited. If you live out the values you set, and you create an opportunity to shape the culture of the organization and give people faith in your leadership. Being someone your team trusts to do the right thing and what you say will play a huge factor in creating trust between you and your team.

There you have it — the secret sauce from The Secret — how to lead effectively and in a way that empowers your team toward success.

---

[View on echobind.com](https://echobind.com/post/the-secret-about-the-secret)

---

# An Intro to Web3 Development

> Jun 17, 2021 | Let's take a deeper look into the specifics of Web3 development using Node scripts and web3.js.

_By Dominic Sherman · 2021-06-17_

In my [previous post](https://echobind.com/post/an-introduction-to-ethereum), I talked about the basics of Ethereum at a higher level as an introduction to people just coming into the field of crypto. In this post (and future posts), I’ll be taking it deeper into the specifics of Web3 development using Node scripts and web3.js. For the full code example, check out the [GitHub repo](https://github.com/DominicSherman/web3-blogpost-example).

## Set Up Test Wallet

The first step to developing on the blockchain is getting a test wallet set up. There are many ways to do this, but we’ll do it through [metamask](https://metamask.io/). If you already have a test wallet with a public address, you can skip this step.

First, install the [metamask chrome plugin](https://chrome.google.com/webstore/detail/metamask/nkbihfbeogaeaoehlefnkodbefgpgknn?hl=en) and then create a wallet. The main information you need now is the public address listed under the account name.

![Metamask homescreen](https://res.cloudinary.com/echobind/image/upload/v1661872448/echobind_blog/w1or0m0wiob5zlobvuly.jpg)

## Add KETH To Wallet

Now we need to actually get some test tokens added to our wallet. You can use any testnet to do this, but for this article we’ll be using Kovan. Testnets are replicas of the mainnet blockchain that allow you to do interactions for free, and a faucet is a way to request tokens for use on these testnets. In order to get ETH in Kovan (KETH), you need to go to the [Kovan faucet](https://faucet.kovan.network/), login with GitHub, and put your public address for your test wallet in.

![Metamask wallet](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/qydxhr2n7irb0rbhxdum.jpg)

Hit `Send me KETH!`, then you should see it show up in your metamask wallet in a couple seconds. The default amount sent from the faucet is 2 ETH, which should be plenty for what we need.

![Metamask user screen](https://res.cloudinary.com/echobind/image/upload/v1661872448/echobind_blog/qejivlclklgkmgapgbxd.jpg)

## Add Kovan DAI To Wallet

Since KETH is the native token on the Kovan network, it is a much simpler process to get and view those tokens in your wallet. If we wanted to add another test token to our wallet, like Kovan DAI, that gets a little more complicated.

The faucet for Kovan DAI isn't as simple as KETH. Luckily, someone deployed a smart contract that does this for us, so all we need to do is send some of our ETH to the smart contract, and it will send Kovan DAI to our wallet. Hit the send button in metamask, and put the following address: `0x786e3c83cd270414649079A758Ad92f961EDdA0A`. This address is the location of the deployed contract, so you want to use this exact string. You can send any amount, as long as you have it in your wallet, and then set the gas limit to 3000000\. The gas limit refers to the maximum amount of gas you are willing to spend for a transaction, so setting it to a high value doesn't mean that's how much you will use, but this limit is the minimum that the faucet requires.

![Metamask modal](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/rbn8ivhdpxvnxdawpqjf.jpg)

Once that's done, hit `Next` and `Confirm`.

You can check your activity to monitor the transaction, and it may take a little bit for it to be mined. Once the transaction has gone through, you’ll see that you have less ETH (since you sent it away), but you won’t see your DAI token yet. This is because metamask only supports the native token for the given network out of the box, and we have to set up viewing another token.

To do this, go to your `Assets` tab and press `Add Token`. The deployed contract address for Kovan DAI is `0x4F96Fe3b7A6Cf9725f59d353F723c1bDb64CA6Aa`, so set that as the token contract address. The other two fields should autopopulate, and then you can hit `Next`. You should see the balance of DAI you have in your wallet, and then hit confirm to finish adding the token. Now if you go back to your account, you should see both ETH and DAI listed as assets.

![Metamask user screen](https://res.cloudinary.com/echobind/image/upload/v1661872448/echobind_blog/fvauxcqic5qkncefbft5.jpg)

## Set up Infura Account

The next step is to set up an account with Infura so that we can get a free project ID to use for their API. Infura is one of many APIs that allow us to interact with the blockchain. Go to [https://infura.io](https://infura.io/) and sign up, create a project, then grab your project ID. We’ll be using Infura’s API in conjunction with web3 to programmatically check our wallet balances on the blockchain.

## View Native Token Balance

Now that we have our test wallet and infura project ID, we can actually start programming, using [web3.js](https://web3js.readthedocs.io/).

> _The web3.js library is a collection of modules that contain functionality for the ethereum ecosystem._

First step is to add it to our project.

```bash
yarn add web3

```

In order to actually use web3 to interact with the blockchain, we have to set up a web3 instance with a provider. Our provider will be an `HttpProvider` which comes with web3, and we'll use the Infura API with our projectId as the Ethereum node. This will look something like this:

```bash
const provider = new Web3.providers.HttpProvider(`https://kovan.infura.io/v3/${YOUR_PROJECT_ID}`);

const web3 = new Web3(provider);

```

Now that we have it set up, getting the native token balance of our wallet is super simple.

```bash
const balance = await web3.eth.getBalance(YOUR_WALLET_ADDRESS);

```

If you log what is returned here, you’ll notice that the number returned is waaaaay larger than the number you see in metamask as your ETH balance. This is because by default, Ethereum returns wei, which is approximately 10¹⁸ ether.

![Metamask code](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/qjycaphco6glcgbclcpa.jpg)

Web3 surfaces a set of utils that allows us to convert this easily, so we can call `web3.utils.fromWei` to get our balance in ethers.

```bash
const balance = web3.utils.fromWei(await web3.eth.getBalance(YOUR_WALLET_ADDRESS));

```

Now it should match the balance you are seeing in metamask:

![Metamask code](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/v2uai2xbs6fzxvt2o1ks.jpg)

## View Kovan DAI Token Balance

Just like with getting and viewing Kovan DAI in our wallet, getting your balance using web3 isn’t quite as simple as it is with the native token. In order to do that, we first have to set up a web3 Contract instance using the ERC20 token standard ABI and the Kovan DAI token address.

ERC20 is a type of token contract that lives in Ethereum, and the ABI (Application Binary Interface) is the specification for the contract. These ABIs are public, and you can find the ERC20 ABI in a lot of different places. I have it listed in the the GitHub repo for this post [here](https://github.com/DominicSherman/web3-blogpost-example/blob/master/erc-20-abi.ts). You’ll need to copy that whole file and add it to your project, and then use it as part of the definition of the Contract instance.

The Kovan DAI token address is just the address of the token smart contract that is deployed on Kovan. It's the same address we used above to add Kovan DAI to our metamask wallet for viewing: `0x4F96Fe3b7A6Cf9725f59d353F723c1bDb64CA6Aa`.

Now that we have these two values, we can create a token contract instance, which looks like this:

```bash
const tokenContract = new web3.eth.Contract(ERC20ABI, DAI_TOKEN_ADDRESS); 

```

We can now use this token contract to invoke functions on the token. The one we will be using is `balanceOf`, but if you look at the DAI token on [Etherscan](https://kovan.etherscan.io/address/0x4F96Fe3b7A6Cf9725f59d353F723c1bDb64CA6Aa), go to the `Contract` tab and look at the `Read Contract` and `Write Contract` sections, you can see all the possible functions and even test them out. Invoking this function using web3 looks like this:

```bash
const balance = await tokenContract.methods.balanceOf(WALLET_ADDRESS).call(); 

```

As we saw with the native token, we will get the balance back in wei, so we need to do the conversion using the `fromWei` util again. After that, we should see the same Kovan DAI balance that we are seeing in metamask.

---

[View on echobind.com](https://echobind.com/post/an-intro-to-web3-development)

---

# SwiftUI, is it ready?

> Jun 10, 2021 | A lot of developers new to native iOS and even those with years of native development experience as themselves, is it time to learn SwiftUI?

_By Echobind Team · 2021-06-10_

Maybe you’re brand new to iOS development or you’ve got some experience building cross-platform apps for iOS and you’re ready to dive into the native ecosystem, but between Swift, SwiftUI and UIKit you’re not sure where to start. If you Google “iOS Development Tutorials,” at least half of the results will be titled something like “Learn iOS Development with SwiftUI,” or at least include SwiftUI as an important module. This is the decision point for a lot of developers new to native iOS and even those with years of native development experience, is it time to learn SwiftUI?

[What is SwiftUI](https://developer.apple.com/documentation/swiftui/)? SwiftUI is not a new language for iOS development, it is a declarative UI framework or, a set of programming tools, used for building user interfaces, allowing me to tell the device what to do instead of how to do it. In Apple’s words: “SwiftUI helps you build great-looking apps across all Apple platforms with the power of Swift — and as little code as possible.”

Three years ago, at WWDC19, Apple introduced SwiftUI as an alternative to [UIKit, the original UI framework](https://developer.apple.com/documentation/uikit/), which has been part of the Developer SDK since it released in 2008\. Will SwiftUI eventually replace UIKit? I think so, if I read into this statement by Apple: “With SwiftUI, you can bring even better experiences to all users, on any Apple device, using just one set of tools and APIs.” The “even better experiences” is key to why I think Apple has a long-term roadmap for moving away from UIKit as the dominant framework. UIKit will always be part of the native ecosystem backing up SwiftUI, in the same way Objective-C still supports Swift in some aspects.

[Swift](https://developer.apple.com/documentation/swift/) itself is the programming language for native, iOS development, it was first released in 2014 and even with Apple’s statement of, “a majority of the top 1,000 apps are built with Swift” almost all iOS developers are using it exclusively to build their apps. The rest of the top 1,000 apps have either been around forever (before 2014), or are built with a cross-platform framework like React Native or Flutter.

## Time to decide

If you review the top tutorials, I’ll add a few of my favorites below, you’ll think SwiftUI is the most important part of learning native development, but if you browse job boards, almost no employers include SwiftUI in their job listings. Most listings include Swift, a few may include UIKit and only one or two will mention SwiftUI. In preparing for this article, I worked the salt mines of Google, looking for any stats of how many apps in the App Store are built solely with SwiftUI and found nothing official. Trolling through Reddit, I did find anecdotal evidence that a few developers have built and published apps with SwiftUI, but nothing that would create a blip on a bar chart.

With SwiftUI Release 2, announced at WWDC20 and publicly available with iOS 14, you could build a complete app, albeit with some limitations, using SwiftUI as the only UI framework. [With the release of SwiftUI 3.0](https://developer.apple.com/xcode/swiftui/), announced this week and available publicly with iOS 15 this fall, Apple is “focused on supporting even deeper adoption of SwiftUI in apps with a great set of rich new features.” Many developers, this one included, will be spending our summer unpacking this and determining just how far we can now go with SwiftUI. All that said, with SwiftUI now in its third year, as of this week, this developer says yes, it’s time to learn SwiftUI.

## SwiftUI saves buttons! 🎉

One important announcement on just day two of WWDC is that SwiftUI will bring borders back to buttons with this third release! If you’ve followed iOS over the years, you’ll remember the old days of interfaces looking like real world items, torn paper, green felt, etc. Apple did this to help us understand how to use the interfaces and once they decided we had figured things out, everything went flat and borders were removed, hurray, a blue word is now a button! This has worked fine over the years and if you really miss your buttons, you could turn them back on with Accessibility, but I’m very happy to see bordered buttons returning with SwiftUI.

![Collage of buttons](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/krcewaoxucgqzaudzhlj.png)

## Where to start

So it’s time to learn Swift and SwiftUI, how about some direction on how to get started and where to go for quality, free tutorials.

1. You need a Mac, anything able to run MacOS 11 (Big Sur) and probably from 2015 or newer. I’m running just fine on a mid-2015 MacBook Pro with the latest version of MacOS and Xcode, so don’t feel like you need to break the bank for something brand new, find something used and see if you like iOS programming first. Not ready to buy? You can even rent a Mac for as little as $25 a month from some providers, [check here for a full guide.](https://codewithchris.com/xcode-for-windows/)
2. Install Xcode. Whether you’re on a new or used machine, you’ll need to first fully update to Big Sur then install the latest version of Xcode from the Mac App Store. It’s completely free and has everything you need to build and test an app.
3. Pick a tutorial, start learning and start building!

If you want to eventually publish your blockbuster app, you will need a paid developer account, $99 USD per year, but you won’t need to pay to test your app on a simulator or your own device, so hold off on the paid account, until you’re ready to publish.

## Great tutorial providers

As promised, here are a few of the people I consider my own mentors who have helped me in my own native iOS learning journey:

[raywenderlich.com](http://raywenderlich.com/) — probably one of the oldest iOS tutorial providers on the Internet. Ray started posting iPhone development how-to’s in 2010\. A lot of their content is paid, but more than enough is free to help you get started. The paid content is very much worth it when you’re ready to dive deeper.

[hackingwithswift.com](http://hackingwithswift.com/) — Paul Hudson started HackingWithSwift shortly after Swift released in 2015 and is probably one of the nicest guys on the Internet. He posts frequently on YouTube and has several great, free courses online, including 100 Days of Swift and 100 Days of SwiftUI, both recommended!

[codewithchris.com](http://codewithchris.com/) — another long-term blogger and iOS teacher, since at least 2012\. Chris posts quality tutorials on YouTube, at least weekly, and has several high-quality paid courses when you’re ready to move up to the next level.

## What do you think?

Where are you in your native development journey? Let me know in the comments below. Are you a diehard SwiftUI fan, have you been building with SwiftUI since 2019? Are you a brand new developer just trying to find your way? Or, are you somewhere in between, eyeing SwiftUI, trying to decide when to dive in. Please let me know your thoughts and let’s have a conversation.

Good luck on your journey and let us know what you think about SwiftUI and any of the other great announcements from this week at WWDC.

---

[View on echobind.com](https://echobind.com/post/swiftui-is-it-ready)

---

# Imposter Syndrome

> Have you ever felt like a phony at work? These feelings are nothing new and you are not the only one going through them.

_By Deloris Thompson · 2021-06-03_

_Have you ever felt like a phony at work? Like your co-workers are going to find out you are a fraud? Hours spent studying and the grades proving you understand feel like simply luck?_

These feelings are nothing new and you are not the only one going through them. Doctors, engineers, actors, even presidents have felt the same. An article printed in The Journal of Behavioral Science explains that 70% of the population has dealt with it. Since boot camps started a lot more people have migrated to developing. It is a great starter that can open a lot of doors. Ruby on Rails, React Native, C++ is just a few that make it possible to find that new career. One door that even seasoned veterans find a hard time closing is imposter syndrome.

## **What is Imposter Syndrome?**

_The idea that you’ve only succeeded due to luck, and not because of your talent or qualifications. —_ [_Time Magazine_](https://time.com/5312483/how-to-deal-with-impostor-syndrome/)

The term was developed by psychologists Pauline Rose Clance and Suzanne Imes in 1978 originally as an imposter phenomenon. They focused on self-starting, successful women. Women that others look at and assume they have it all; from confidence to financial success and independence. What they found was shocking; no matter how powerful or confident, imposter syndrome was always there waiting to pounce. But why? Did Former President Barack Obama feel it? Has Steve Wozniak ever walked into a boardroom unsure his tech was up to par? Is it just women? Simply put no.

_Despite outstanding academic and professional accomplishments, women who experience the imposter phenomenon persist in believing that they are really not bright and have fooled anyone who thinks otherwise. — Harvard Business Review_

As research increases, we are finding that everyone experiences it at some point in their life. A moment when you are not “able to internalize and own your own successes.” — Dr. Audrey Ervin. My very first experience with it was when I made the Dean's list. I spent hours studying, making sure my work was perfect and handed in extra credit, yet I still felt like I did not deserve it. All of my hard work felt like just luck. I was lucky the textbooks were not overly complicated or that my teachers were amazing. I couldn’t own my own success.

## **How do you break the imposter syndrome spell?**

> **_Each time I write a book, every time I face that yellow pad, the challenge is so great. I have written eleven books, but each time I think, ‘Uh oh, they’re going to find out now. I’ve run a game on everybody and they’re going to find me out. — Maya Angelou_**

Taking control of my thoughts was the first step. Everyone has good and bad thoughts but realizing which ones are actually helpful is important. When we realize which thoughts are just hindering our success we are one step closer to beating imposter syndrome. Accepting constructive criticism is also important. Without it, we will never truly know where to improve. The most important step in breaking the spell is knowing when to ask for help and being comfortable with it. At Echobind we have a fifteen-minute rule. _If you are stuck on a problem for fifteen minutes reach out for help_. Imposter syndrome can make asking difficult. Thoughts like “what if they find out I am a fraud?” can slow you and your team down. When we ask for help, we accept that we do not know everything, but we are also breaking down the “fraud” barrier.

Everyone has positive and negative thoughts. Not allowing the negative ones to control our actions is important. Remember you deserve the success and worked hard for it. Celebrate every small win; even if it is a single commit PR or an A on a report. Every little win you embrace brings you one step closer to accepting your hard work.

---

[View on echobind.com](https://echobind.com/post/imposter-syndrome)

---

# The Plan

> May 27, 2021 | Mariah's journey started with the plan, which has evolved to bring her to where she is now, in the software development field.

_By Mariah Grey · 2021-05-27_

My journey into software development has definitely not been a ‘point A to B’ path. It all started with _the plan,_ which has evolved to bring me to where I am now, in the software development field. Travel this tumultuous road with me.

> _“It takes as much energy to wish as it does to plan.” — Eleanor Roosevelt_

My career path began with a focus on getting my degree to teach. During high school, I had volunteered in a kindergarten classroom for several terms, helping grade papers, and setting up lesson plans, which I genuinely enjoyed. This was what kick-started _the plan. The plan_ was to get my bachelor’s degree, then my master’s in education — to teach either kindergarten through second grade or high school English and History while working part-time as a PreK teacher to support myself through college. I acquired my Associate’s degree with a focus in Early Childhood Education and transferred from a community college to a state school to pursue my Bachelor of Science degree in Education. This is where _the plan_ hit its first bump.

![Restaurant with bar stools](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/xjmu5ijnabodxvw33azi.jpg)

Shortly after I began my second phase of college, I got married and found out we’d be moving. Not simply across the state, but to Japan. This put a major wrench in _the plan_ since student teaching would be extremely challenging to complete overseas through my current college. Instead of transferring schools for a third time, I decided to take a break from college as I followed my husband across an ocean. Once we settled into life overseas, I started teaching English to Japanese kids and jumped back into teaching PreK through a daycare on the military base where we lived. I loved the structure and working with children. Three years of this flew by, and we had a little girl and prepared to move back to the States, where _the plan_ was to continue working as a preschool teacher and get back on track pursuing my Education degree.

![Moving boxes stack on top of each other in a room](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/jght2zrosgjdnxd8pkqn.jpg)

Once we landed in Texas, _the plan_ hit another snag. Childcare in the oil fields of Texas was astronomically expensive and my salary as a PreK teacher was barely enough to cover the price and make it worth spending 8 hours each day away from my kids, especially as we added another baby girl to our family. After a year and a half of searching for a job that was worth my time, I was feeling a bit of despair towards _the plan_. Finding something that would allow me to set flexible hours and work from home seemed completely out of reach. A family member suggested I check out [Free Code Camp](https://www.freecodecamp.org/), and I was intrigued enough to dig in.

After working through the Front End development section of Free Code Camp, I began to feel like this could be the next phase of _the plan_. I took a leap of faith and signed up for a Bootcamp focused on Full Stack JavaScript. It was challenging and stretched me far outside my comfort zone, which forced me to admit that, once again, _the plan_ wasn’t going the direction I had imagined. But also, that it was okay to veer off course from _the plan_. Once I accepted that fact and dove headfirst into dedicated growth in the software development field, I was able to find a remote position with a small software company based in Idaho. I was working closely with my boss and learning so much each day. The position focused heavily on Classic ASP and the HTML, CSS, and JavaScript basics. With that, I was able to learn steadily and grow as a remote developer.

![A desk at home set up for remote work](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/vt9sxzcpivlompkpaz8w.jpg)

As I settled into my job title of ‘Software Developer’, I started to fight through my imposter syndrome. I did this by reminding myself that I had earned my spot within the company with the level of knowledge that I already had! I then solidified this thought by getting into as many learning opportunities as I could whenever I had free time within my workday to grow the knowledge I already possessed. Both of those things calmed down my ‘what the heck am I even doing here’ thoughts. Once I had that under control, I began to look for opportunities to transition into a more React and React Native focused position. I was leaning farther into mobile-first engineering and saw significant room for growth, both personally and as part of the software development field overall. I applied for many spots, one of which was an apprenticeship with Echobind, and took a break from Development as COVID really took hold of the economy. In August I was accepted to and began my apprenticeship with Echobind, which led to a full-time job opening in November.

After starting as a Software Engineer here at Echobind, I gained exposure to many different channels of tech and have met many people who have taken the non-traditional path to where they are now. It’s such a supportive environment and I look forward to being part of the continued growth here. I guess _the plan_ doesn’t always take us where we anticipate going, but it always brings us to where we’re supposed to be. Here’s to flexibility and growth as _the plan_ changes!

---

[View on echobind.com](https://echobind.com/post/the-plan)

---

# NextAuth.js Intro [3 of 3]: Adding Access Control

> May 20, 2021 | In this series, we’re exploring different patterns for using next-auth with Next.js for easy and powerful login and sign up for your app. In this next installment, we’ll talk about requiring the user to be logged in to see parts of your app.

_By Mike Cavaliere · 2021-05-20_

In this series we’re exploring different patterns for using next-auth with Next.js for easy and powerful login and sign up for your app. In this next installment we’ll talk about requiring the user to be logged in to see parts of your app.

**Links:**

* [GitHub Repo](https://github.com/echobind/next-auth-example/tree/with-access-control)
* [Interactive demo](https://next-auth-example-access-control.vercel.app/) on Vercel

**Other articles in this series:**

* [NextAuth.js: One-Click Signup \[Part 1 of 3\]](https://echobind.com/post/nextauth-js-intro-1-of-3-one-click-signup)
* [NextAuth.js: Magic Link Email Authentication \[Part 2 of 3\]](https://echobind.com/post/nextauth-js-intro-2-of-3-magic-link-email-authentication)

In most apps, there are features and screens for which we want to require the users to be logged in. For our example app, we’ll assume the user needs some kind of personal dashboard they’ll see only when logged in (since, we can’t know _whose_ data to put on the dashboard unless we know that (1) they’re logged in and (2) who they are),

## Create a restricted page

First we’ll create a dashboard page for our app with some content in it. We’ll require that a user log in to see this page.

In `/pages/dashboard.js` we'll add some fake-but-neat-looking sample content using Chakra-UI. This can be any sample content, you don’t have to use Chakra-UI. (But if you do, make sure to install it first naturally.)

```javascript
export default function Dashboard() {
  return (
    <Flex
      direction='column'
      align='center'
      justifyContent='center'
      minHeight='80vh'
    >
      <Heading mb={3}>My Dashboard</Heading>
      <Stack>
        <Badge mb={2}>Things</Badge>
        <Badge mb={2} colorScheme='green'>
          Stuff
        </Badge>
        <Badge mb={2} colorScheme='red'>
          Foo
        </Badge>
        <Badge mb={2} colorScheme='purple'>
          Bar
        </Badge>
        <Badge mb={2} colorScheme='blue'>
          Baz
        </Badge>
      </Stack>
    </Flex>
  );
}
```

![Sample app homepage](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/ukj3fg7sh4fmfmmfdt8v.png)

Looking good! Chakra-UI is pretty great.

Now let’s do a check to make sure the user is logged in, and redirect otherwise. We’ll do this with 2 great helpers: the `getSession()` function from `next-auth`, and Next.js's `getServerSideProps` function.

```javascript
export async function getServerSideProps({ req, res }) {
  const session = await getSession({ req });
  if (!session) {
    return {
      redirect: {
        destination: '/',
        permanent: false,
      },
    }
  }
  return {
    props: {},
  };
}
```

Next.js’s `getServerSideProps` function is executed on every page load, before rendering the page. As a convention, it will allow you to return a redirect object to tell the browser to `redirect` to another page. Here we call getSession to check that a user's logged in, and return the redirect object if not. If they are logged in, we return an empty props object which will pass through to the page renderer seamlessly.

## Restricting a page by hiding it

The above works well if the user knows the address of the page, and is trying to see it without being logged in. This is an effective measure, since there’s no way they can get in.

But why show them a link to it in the first place? We should only show links to restricted pages when the user is logged in.

Let’s start by adding a `Navbar` component to `/components/Navbar/index.jsx`:

```javascript
export const Navbar = ({ children }) => (
  <Flex
    w='100%'
    bg='green.800'
    px={5}
    py={4}
    color='white'
    justifyContent='space-between'
    alignItems='center'
  >
    <Flex flexDirection='row' justifyContent='center' alignItems='center'>
      <Link href='/'>Next.js Auth & Access Control Demo</Link>
    </Flex>
    <Box>{children}</Box>
  </Flex>
);
```

It’s just some styling, and has the ability to pass in children which is important since that makes it fairly composable. That is, we can pass it any children we want and it’ll still work, which also means we can wrap it easily with other components that pass specific children to it.

Now we’ll want a logged in and logged out version of it:

```javascript
export const LoggedOutNavbar = () => <Navbar />;
export const LoggedInNavbar = () => (
  <Navbar>
    <Link href='/dashboard' mr={4}>
      My Dashboard
    </Link>
    <Link onClick={signOut}>Log out</Link>
  </Navbar>
);
```

The logged in links to the dashboard we created, and also shows a Log out link (which we shouldn’t show when someone is logged in either).

Now how do we get them to show conditionally? Easy. We export another component that takes in the session as a prop. If it exists, we show the logged-in version of the Navbar. Otherwise we show the logged-out version.

```javascript
export const NavbarWithLoginState = ({ session }) =>
  session ? <LoggedInNavbar /> : <LoggedOutNavbar />; 
```

Then inside our DefaultLayout component we add the `NavbarWithLoginState`, and grab the session from the `useSession` hook:

```javascript
import { Box } from '@chakra-ui/react';
import { NavbarWithLoginState } from '../../components/Navbar';
import { useSession } from 'next-auth/client';
export const DefaultLayout = ({ children }) => {
  const [session] = useSession();
  return (
    <Box>
      <NavbarWithLoginState session={session} />
      {children}
    </Box>
  );
};
export default DefaultLayout; 
```

Boom. Only logged in users will see the dashboard link, so there’s a second layer of protection on the private page.

![Logged-out homepage](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/ikflt4gwihm7l9gzjrti.png)

Logged-out homepage

![Logged-in homepage](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/gzunrjwrcrpfiqnxkzsy.png)

Logged-in homepage

## Adding private data and restricting the API route

So we’re redirecting anyone that views the dashboard in the browser who isn’t logged in. But the dashboard will inevitably need some data, which we’ll have to create an API route for. What if someone were to request that API route directly, without being logged in?

We don’t want people fiddling with that endpoint without having at least logged in first. So our API route will need to check that the user is logged in as well. In general the back-end is even more important to restrict, since that’s where all valuable data will come from. So for security reasons and other reasons, let’s put a redirect there as well.

Let’s add an API route to send us some data:

```javascript
// pages/api/dashboard.js
const data = [
  {value: 'Stuff', colorScheme: 'green'},
  {value: 'Foo', colorScheme: 'red'},
  {value: 'Bar', colorScheme: 'purple'},
  {value: 'Baz', colorScheme: 'blue'},
];
export default (req, res) => {
  res.statusCode = 200
  res.json(data)
}
```

If we hit this endpoint in Postman, we’ll see the data sent back in JSON:

![Postman displaying JSON data](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/z0ckpgwephfk7il3ces2.png)

Then we can have the dashboard page use this data with a simple React fetch/setState pattern. The dashboard will look exactly the same, but it will now render the data dynamically.

```javascript
import React, { useState, useEffect } from 'react'
import { Badge, Flex, Heading, Stack } from '@chakra-ui/react';
import { getSession } from 'next-auth/client';
const fetchThings = async () => {
  const response = await fetch('/api/dashboard', {
    headers: {
      'Content-Type': 'application/json',
      'Accept': 'application/json',
    }
  });
  const json = await response.json();
  if (!response.ok) {
    throw json
  }
  return json;
}
export default function Dashboard() {
  const [things, setThings] = useState([]);
  useEffect(() => {
    fetchThings().then(things => {
      setThings(things)
    });
  }, [])
  return (
    <Flex
      direction='column'
      align='center'
      justifyContent='center'
      minHeight='80vh'
    >
      <Heading mb={3}>My Dashboard</Heading>
      <Stack>
        {things.map((thing) => {
          return (
            <Badge mb={2} colorScheme={thing.colorScheme} key={thing.value}>
              {thing.value}
            </Badge>
          )
        })}
      </Stack>
    </Flex>
  );
}
export async function getServerSideProps({ req, res }) {
  const session = await getSession({ req });
  if (!session) {
    return {
      redirect: {
        destination: '/',
        permanent: false,
      },
    }
  }
  return {
    props: {},
  };
}
```

Now let’s require a session in the API route. `next-auth` makes that easy from an API route as well. We just pull in the `getSession` helper from `next-auth/client` and pass it our request:

```javascript
import { getSession } from 'next-auth/client'
const data = [
  {value: 'Stuff', colorScheme: 'green'},
  {value: 'Foo', colorScheme: 'red'},
  {value: 'Bar', colorScheme: 'purple'},
  {value: 'Baz', colorScheme: 'blue'},
];
export default async (req, res) => {
  const session = await getSession({req});
  if (!session) {
    res.redirect(307, '/')
    return
  }
  res.status(200).json(data)
}
```

Now you’ll see below that the postman request will return a 307 for temporary redirects.

NOTE: When testing in Postman, make sure you have automatic redirects turned off in the settings, or you’ll see a bunch of HTML as your response.

![Postman settings](https://res.cloudinary.com/echobind/image/upload/v1661872447/echobind_blog/ar4cbgzbgtf7bwgjxjru.png)

![Postman displaying JSON data](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/vhkbtjcrk8n5mnfndnti.png)

Great. Now we’ve locked down the dashboard from both the front-end and the back-end. Go celebrate with your beverage of choice 🎉

---

[View on echobind.com](https://echobind.com/post/nextauth-js-intro-3-of-3-adding-access-control)

---

# An Introduction to Ethereum

> Helpful initial learnings broke down for others so that this crypto world isn’t as far out of reach as it initially seems.

_By Dominic Sherman · 2021-05-13_

If you’re working in the tech or finance world at the moment, or even just reading the news, you probably have heard a lot about cryptocurrency. It’s taken the world by storm, starting with Bitcoin and now with a multitude of other currencies. At Echobind, we’ve been building a mobile app for a client to confront some technical challenges on the Ethereum blockchain, which has led us to jump into the cryptocurrency world headfirst. In this blog, I’ll share some of my most helpful initial learnings, and break them down for others so that this crypto world isn’t as far out of reach as it initially seems.

## What is a blockchain?

A blockchain is a network of computers that store the state of the system. In order for any changes to be made to the system, each node (computer) in the system must agree on this change. The way that a specific blockchain agrees on changes and the current state of the system is called its [consensus mechanism](https://ethereum.org/en/developers/docs/consensus-mechanisms/). These mechanisms allow the networks of computers to work together while also staying secure from bad actors.

## How do consensus mechanisms work?

Ethereum currently uses a mechanism called proof-of-work (PoW), which means that any node that wants to make a change to the blockchain must first solve a challenging puzzle. These puzzles require _a lot_ of computational power, so solving the puzzle shows that you have spent the resources necessary to make the change. This deters bad nodes from trying to submit fraudulent blocks since so many resources are spent trying to produce the block.

## What is gas?

Gas fees are another aspect of the Ethereum network that allow it to remain secure from actors spamming the network. They are simply a fee paid for the computational resources spent for every transaction. These fees are paid in ETH (Ethereum’s native currency) and denoted in Gwei, which is a denomination of ETH. One Gwei is equal to 0.000000001 ETH (10^-9 ETH).

## What is decentralization?

One of the core concepts of the Ethereum network is decentralization, which refers to the fact that no single entity owns the system. In order to get started buying and selling ETH, you need only an internet connection. You never need to enter any personal details about yourself, and all transactions are based on your wallet’s address (a random string generated when you created your wallet). This makes it impossible for the system to ever discriminate or choose who can open an account or send transactions. Also, Ethereum itself and its apps are open source, meaning the code running the system is visible for anyone to see.

## What is a dApp?

A dApp (decentralized application) is an application that is built on a decentralized peer-to-peer network. This means that the network it runs on is independent, and not controlled by any single entity, compared to an application like Facebook or Instagram where they control the backend of their applications.

## What is a smart contract?

_A “smart contract” is simply a program that runs on the Ethereum blockchain. It’s a collection of code (its functions) and data (its state) that resides at a specific address on the Ethereum blockchain._

Smart contracts themselves are a type of of Ethereum account, except they are not controlled by a user. A user can interact with a deployed smart contract by sending transactions to the blockchain with instructions to execute one of the functions the smart contract has defined.

For more in-depth details on smart contracts, check out Ethereum’s [developer docs](https://ethereum.org/en/developers/docs/smart-contracts/).

## What is Web3?

[Web3](https://echobind.com/post/an-intro-to-web3-development) refers the system of dApps that run on Ethereum’s blockchains, which allow anyone to participate without requiring the use of their personal data. Web2, to contrast, is our existing system of applications that monetize your data in exchange for the use of their service.

For more in-depth details on Web3, check out Ethereum’s [developer docs.](https://ethereum.org/en/developers/docs/web2-vs-web3/)

## What is an Ethereum wallet?

The terminology here is slightly confusing, because your Ethereum wallet can refer to both your account as well as to the apps that allow you to view and manage your account. Your account (wallet) consists of three major pieces: a public address, private key, and generally a mnemonic.

The **public address** is a string of the form `0x000...000` that is used to publicly identify your wallet. This can be shared with other individuals, which allows them to send you assets, as well as used to view your wallet balance somewhere like [Etherscan](https://etherscan.io/).

The **private key** is a random string of 64 hex characters which serves as a way to identify yourself as the owner of a wallet, and it can be used to import your wallet into an Ethereum wallet app and start using it. Some apps allow you to import a wallet using only the public address, but this only gives you viewing access to the wallet. You would not be able to make any transactions on the wallet’s behalf without the private key.

For most wallets, a **mnemonic** (or seed phrase) can also be used to identify yourself as the owner of a wallet. For example:

```javascript
jealous expect hundred young unlock disagree major siren surge acoustic machine catalog
```

This is simply a phrase of 12 or 24 readable words that can be used by Ethereum wallet apps to derive your private key. It can be thought of as the password to your account, and if you are creating and funding an Ethereum wallet, _you do not want to lose this phrase._

It is easy to get started investing in cryptocurrency using a broker like Coinbase, but something to be aware of is that you don’t actually own the Ethereum you are invested in since your wallet is managed by the broker. The upside to using a broker is that since they manage an account and ETH for you, you aren’t subject to the same risk of losing your wallet’s private key or mnemonic, and thus losing access to your wallet forever. Coinbase allows you to transfer any purchased ETH to an Ethereum wallet address, but until you do that you are still reliant on Coinbase to keep your personal information and ETH safe for you. For true decentralization and complete security, you must use an actual Ethereum wallet with private key/mnemonic, and interact with it using an Ethereum wallet app. To learn more about Ethereum and get started using it, go to the official site and check out the [learning pages](https://ethereum.org/en/what-is-ethereum/)!

---

[View on echobind.com](https://echobind.com/post/an-introduction-to-ethereum)

---

# Learning Rails after Bison’s JAMstack

> May 06, 2021 | Is Rails old news? Kim highlights some of it's features after learning Bison.

_By Kim Wilkes · 2021-05-06_

I’m a Software Engineer at [Echobind](https://echobind.com/) learning and developing skills across various tech stacks. To help with that, we get something special called [Investment Time](https://echobind.com/post/the-roi-of-self-directed-investment-time-for-software-engineers), 8 hours a week, to dedicate towards learning some skill that would be beneficial to both ourselves and the company. Now, I recently had the wonderful opportunity to work on a greenfield project, from start to finish, that would use our company’s JAMstack generator, [Bison](https://github.com/echobind/bisonapp). Its tech stack includes: Next.js, TypeScript, GraphQL, Prisma, Chakra UI, and React Hook Form.

I have always enjoyed working with React and the front end but being a full-stack developer, I should also maintain some expertise with the backend. Knowing that some future projects may require knowledge of Rails, I set that as my goal and used my investment time towards recreating some of the functionality of that Bison project but using Rails. My only other experience with Rails before this learning adventure was during my [General Assembly](https://generalassemb.ly/?&topic=&mkt%5Faccount%5Fid=1056949875&mkt%5Fcampaign%5Fid=1629435768&mkt%5Fad%5Fgroup%5Fid=62410829179&mkt%5Fdevice%5Ftype=c&mkt%5Fkeyword=general%20assembly&mkt%5Fmatchtype=e&mkt%5Fplacement=&mkt%5Fad%5Fid=425102003416&mkt%5Fnetwork=g&mkt%5Ftarget%5Fid=kwd-300765785657&mkt%5Ffeed%5Fitem%5Fid=&utm%5Fsource=google&utm%5Fmedium=paid-search-bra&utm%5Fcampaign=TS:TX:BRA:REM:BR:GeneralAssembly&utm%5Fcontent=campus-lead-lander-remote&utm%5Fterm=general%20assembly&gclid=Cj0KCQjwp86EBhD7ARIsAFkgakijVrAwiZVkX3g49CQsSoDFpMLmtuXlWaOyyb7jiLJ732bg2yI5pqoaAvlCEALw%5FwcB) bootcamp for one project’s backend. I had appreciated the simplicity of quick setup using the scaffold command generator but that was about as far as that understanding went.

I wanted to share my findings from this effort because I came across the opinion that Rails is old news while going through tutorials and researching aspects of it. I want to highlight features instead of insisting on the relevance of one thing over another given my limited experience.

**Similarities**

* Fast and easy to spin up a new app.
* Schema file that shows the structure of your database models.
* Create DB migrations based on the aforementioned schema.
* Static and Dynamic routing
* Make “components” that get pulled into pages/views: Rails allows partial html to be rendered in other pages would be pulled into as similar to making a React component that could be used throughout the app.
* Pre-configured generators (Bison App lists commands in package.json): for example, .
* Html with code mixed in: and . For example, you can run for loops to build out the data for a table or list.

**Differences**

* The Schema file in Rails is sacred and not to be touched whereas Prisma’s Schema file is where the modeling magic happens, which Bison would auto-update the and .
* Rails’ MVC is fully separated and does not typically get pieces mixed in. React “views” can have the “controllers” included in the file.
* Pending migration in Rails stops you from continuing to see the page view and must finish migrating before continuing.
* RESTful vs GraphQL: can set up Rails with GraphQL but not right out of the given Rails box.
* Routing seems simpler in Bison: Bison → immediately can open that page with a pre-generated component with the page's name to help visually confirm its creation. Rails → add to the file → have a controller related to that route → all of which requires a model related to all of it.
* Rails came with a lot of directories that I did not end up using and have no idea what to use them for, but may be relevant for more complicated projects.

![Cartoon of man on ladder touching large computer](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/ejrgejd7tfjrnkvxyxyc.jpg)

**In the Future**

Now that I have more familiarity with the error page, I’m not as immediately terrified of seeing the bright red header (which provides a helpful tip on where to start your debugging efforts) as I used to be. I learned to have a bit more patience while parsing those error messages and appreciated that Rails made a full stop on whatever I was trying to do before potentially starting a never-ending loop.

I loved the challenge of trying to replicate the functionality of an app through Rails because I had a reference point to chase and could see the appeal of one tool over another for various goals. I was pleasantly surprised that I could spin up a full app using just Rails and a few helpful gems. I also appreciated the already included Rails features like [Action Mailer](https://guides.rubyonrails.org/action%5Fmailer%5Fbasics.html) to be able to send emails within the app and [Active Storage](https://guides.rubyonrails.org/active%5Fstorage%5Foverview.html), which included explanations of how to add various cloud storage options for one-to-one and one-to-many files for a record. Between the generators and these extra features already built into the base template, it’s hard not to describe Rails as “magic.”

If you were to ask me which tool would I use going forward, then I’d have to say that I don’t have a good answer for that yet. I’m sure this will change as I get involved in more projects and get a better feel for what tools make the most sense to me and for the needs of a project. I’m still in the “sponge” stage of my engineering career; I want to learn everything and anything I can soak up, though I know there’s a limitation to how much knowledge will really get pulled in. I feel more of a pull towards Bison’s JAMstack just because I’m so curious about using GraphQL in comparison to REST. I’ll certainly be using my next quarter’s investment time towards GraphQL to have a deeper understanding and look forward to reporting what I learn then.

---

[View on echobind.com](https://echobind.com/post/learning-rails-after-bisons-jamstack)

---

# Why Should I Write Clean Code?

> Apr 29, 2021 | Writing clean code is important because it allows you to clearly communicate with the next person who works with what you've written.

_By Mariah Grey · 2021-04-29_

Writing clean code is important because it allows you to clearly communicate with the next person who works with what you've written. Being able to return to previously written code and understand what it does is key, especially in the software development world. The more declarative code is the better it communicates, and the easier it is to fix problems when they arise. By writing clean code, you will make yourself a better teammate, employee, and developer.

When I became a software developer, I knew that my code should be “clean”,but what does that actually look like?

## **WHAT IS CLEAN CODE?**

**_‍_**In a nutshell, clean code means that your code is easy to read, easy to understand, and easy to change. It’s as simple as having descriptively named variables, functions, and classes so that as you read, you know what each contains or does without guesswork. Remember these key principles: **KISS**, which stands for **K**eep **I**t **S**imple, **S**tupid, and **DRY**, **D**on’t **R**epeat **Y**ourself. Ask yourself if there is a better solution for solving problems or complexity within your code. Start building habits that are conducive to clean code, such as:

* Checking your naming conventions. Keep them clear and concise.
* Be consistent. Use the same names in similar functions (Get vs Fetch, Set vs Update, Add vs Append).
* If you copy-paste code multiple times, consider better ways to make your code more efficient.
* For database requests, keep it as simple and productive as possible.
* Listen to your gut. If you feel that a piece of code is too complex or not the best way to do it, then stop! Give yourself a few moments to rethink the process and see if you can come up with a better way.
* Review with colleagues. Compare their code with yours, and be open to suggestions.

## **WHY IS IT IMPORTANT?**

**_‍_**Most code isn’t written and forgotten about, it is written and then modified over time to keep it current and efficient as it pertains to the project. Most likely, you aren’t the only person who will need to understand what your code does, which is why what it does will need to be obvious.

Yes, you can use comments_,_ but if that’s your only form of communication within your code then you’re writing dirty code. Making certain that your code can speak for itself will also help you to develop your technical vocabulary. This benefits you by elevating your code quality — when you can discuss your code clearly, you can more effectively ask for help and suggestions on how to improve what you write. Clean code won’t write itself, it takes dedicated focus on putting forward what you mean to convey. Strive to write self-documenting code, clean and structured code that doesn’t need comments all over to explain what it’s doing.

![Hand cleaning a computer screen with code](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/gdnzmdxgdbyedz3v8f2k.png)

## **BUT WHY SHOULD YOU CARE?**

[**Teamwork!**](https://echobind.com/culture) You won’t be in the software development field for long before joining a project that is either a real-time collaboration or contains legacy code. Working with code that others have or will work on makes it evident that clean code is important_._ Jumping into code that doesn’t have a clear direction is time-consuming for all parties involved because when it isn’t apparent what code does or why it does it, you waste resources trying to discover its purpose.

**It’s Reusable.** The cleaner your code is, the more likely it is that you can reuse it!Writing clean code makes you a more efficient programmer because you are writing code that does one clear thing, which doesn’t take any extra time to write. Clean code also makes maintenance easier and quicker.

**You’ll feel better about your code.** Asking for help from a colleague and then having to wade through poorly written code to find the issue is never a boost for your confidence. Writing clean code will allow you to produce quality code that you’re proud to share with your team, knowing they'll have an easier time working on it too.

**You’ll see growth.** You won’t always write clean code! And that’s okay, we’re always learning and growing as developers. When you know better, you can do better. If you take the time to write clean code now, you will reap the benefits of readability and easier debugging down the road.

If you think you spend most of your time writing code, you’re wrong. You spend more time reading code, figuring out bugs, finding problems, and figuring out how to solve them. Clean code makes all of those things easier. If there’s one thing all programmers can agree on, it’s that clean code is better.

> _Clean code always looks like it was written by someone who cares. There is nothing obvious you can do to make it better. -Michael Feathers_

---

[View on echobind.com](https://echobind.com/post/why-should-i-write-clean-code)

---

# Variety Is the Spice of (Agency) Life

> Apr 22, 2021 | Working at an agency is an experience like none other, and while we absolutely love it, we recognize that it’s unique and not everyone is cut out for it.

_By Jenn Robison · 2021-04-22_

Working at an agency is an experience like none other, and while we absolutely love it, we recognize that it’s unique and not everyone is cut out for it. And not every agency is the same! But when people ask me what I love about working at an agency, there are a few things that immediately come to mind, but chief among them is **Variety**.

Clients engage us for a variety of different reasons such as code audits, mentoring and coaching, greenfield projects, and team augmentation, to name a few. We also get to work on a wide variety of projects and technologies, which keeps things interesting for each of us. We are never bored, and we learn and grow a lot. We share our expertise, we hone our skills with the technologies we already know, and we learn technologies we’re less familiar with. The projects are each so different, so we’re learning new businesses and with each, we see how what we’re doing drives value for our client. As I said, we’re never bored.

The flip side to all this variety is that things are dynamic, and we don’t always set the cadence or schedule for projects. Clients’ needs or budgets can shift, which quickly impacts what we’re working on. That can be jarring for some, which is one of the reasons agency life isn’t for everyone. But that’s also why we get hired — we’re brought in on an as-needed basis and when those needs change, we adjust accordingly. Coming from a corporate experience it can be a little jarring but likely it’s hitting on one of the reasons you have flirted with the idea of agency life. In corporate life, you are often moving at a much slower and controlled cadence in a project and may find a lot of bureaucracy along the way. While you are in the corporate world, we often get frustrated with this, but when you leave that environment and join the agency world, it may feel like you don’t have the same guardrails in place, making things feel a bit disorganized for those not used to this. It can take time to adjust and it is not for everyone, but for me personally I have found this to be very refreshing once I gave it some time. This means, like business problems we are trying to solve, we must approach the change with an open mind. Depending on how long you have worked in the corporate environment it may take longer to adjust, and as I said, it is not for everyone; this is something that only you will know.

I now look forward to the excitement of “What will today bring?" I never know what cool new business problems I will get the opportunity to solve. One day it may be healthcare technology, the next online greeting cards; whereas when I worked in corporate, every single day was about manufacturing and not nearly as interesting.

Would you enjoy the variety of agency life?

---

[View on echobind.com](https://echobind.com/post/variety-is-the-spice-of-agency-life)

---

# Docker Compose DB

> Apr 15, 2021 | The same reason you use docker for anything, projects differ, and while version managers work well for programming languages, they are nightmarish for databases.

_By Matt Thompson · 2021-04-15_

## The Problem…

Developer environments can be a tedious process, even more so at an agency. You spend 2 days getting Client A’s secret sauce of a config rolling, only to need Client B’s config later in the week. While you are typically at the liberty of their setup, a few things can still be in your control. e.g. Tooling.

Over the past couple of months, I’ve had clients needing versions of databases across the board. Typically, we don’t think of it. Install this version, switch to that, run for a while…. rinse, and repeat. But what happens when you need to adapt quickly? What happens when Mac updates are pushed and brew installs break? **_Big Sur_** anyone? \*\*The issue, as much as we try to stay consistent in our setup, it’s almost impossible when we continue to patch and reconfigure. We’ve come a long way in terms of language versioning, but not much has been said in terms of databases.

It seems like something was made just for this… hmm… what was it.

**_\*a wild dockerfile appears!_**

![Pokemon game with Ash catching a docker](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/h3iotptg44qiijwcnchn.png)

_Credit: Kim Wilkes via_ <http://www.pokemonbattlecreator.com/>

Below is an exported README from a [current docker setup](https://github.com/mthomps4/docker-compose-db) for database versioning.

Feel free to clone and follow along in exploring this _probably over-engineered_ setup.

> _Automation is good! More must be better!_

**Source Repo:**

<https://github.com/mthomps4/docker-compose-db>

## Why Docker DB

The same reason you use docker for anything, projects differ, and while version managers work well for programming languages, they are nightmarish for databases. Have you ever tried to manage 3 versions of MySQL on a mac? While you can brew link all day… they still share common MySQL setup files and config files via brew… and as you could imagine, MySQL@5.6 and MySQL8 do not play nice together.

**Why can’t we just host these in the cloud somewhere?!** Absolutely, this is not to discourage other alternatives. Slap that MySQL instance up there and drop some ENVs. At some point, however, you’ll want more direct access to logging, and those _free_ services and hosts stop being free. And what if you need to modify some my.cnf files? While services have options, and there are definitely pro’s and con’s to both, having more direct control over what is going in our dev setup can be ideal when onboarding and debugging various applications.

**_insert docker_**

## The Goal

The main focus here is to give each DB instance a home, MySQL 5.6 shouldn’t care about MySQL8, etc. Each instance is self contained to it’s container with a persisted volume and config files are set for each as needed. This also lends itself to expansion with other DB tooling, postgres, redis, and memcache for example. If we need to tweak a config, it’s as easy as stopping the running container, editing/creating a file and restarting.

## Setup

Note: If you are familiar with docker and want a single instance of a DB feel free to take a quick peek at the docker-compose.yml and copy over what you need. This setup will enable you to set up and run, MySQL 5.6, 5.7, 8, and Postgres either as a suite or as individual services (recommended).

We are leveraging [Docker/MySQL](https://hub.docker.com/%5F/mysql) and [Docker/Postgres](https://hub.docker.com/%5F/postgres) docs here.

* Create a `.env` from `.env.example` and set your DB ENVs accordingly.
* run `source .env`
* run `docker-compose` config to ensure your ENVs are pulling through
* You may need to ensure `setup.sh` has executable permissions by running chmod `+x ./setup.sh`
* Run `./setup.sh`

`./setup.sh` gives the folder `./initializers` permissions and runs each DB initializer file respectfully to scaffold out or `db` folder.

**Let’s take a look at what happened:** You should now see a `db` folder. The initializers have created a folder PER DB inside, each with a `data` folder, `init` folder, and for MySQL a `my.conf` file. If you take a peek at the db/mysql8/init you’ll notice the initializer also added a `01.sql` file. This file will then be used by docker in pair with `docker-entrypoint-initdb.d` to run extra commands on setup. In our case, we’ve taken the liberty to use our ENVs to ensure a superuser was created with all permissions and a respected DB. While the ENVs provided to Docker/MySQL already do this, I’ve kept this file as an example for any other seeds and SQL you may need to run.

Note: For MySQL 5.6, I’ve set an example setup of Root with NO password. If you need something different be sure to tweak the initializer, ENVs, and compose, respectfully.

## Ways to run this thing

To pull, build, and link all the things with docker lets run from our project directory.

```javascript
docker-compose up --no-start
```

This will pull the DB images from DockerHub, create the default network drivers, and build the containers to run. Now we are ready to run all or some of our services.

```javascript
docker-compose start mysql8
```

You should see `Starting mysql8 ... done`

Let’s see what’s going on with

```javascript
docker-compose logs -f
```

You should see something similar to:

```javascript
 MySQL8      | 2021-01-08T17:37:28.188065Z 0 [System] [MY-010931] [Server] /usr/sbin/mysqld: ready for connections. Version: '8.0.22'  socket: '/var/run/mysqld/mysqld.sock'  port: 3308  MySQL Community Server - GPL.
MySQL56 exited with code 0
postgres exited with code 0
MySQL57 exited with code 0
```

You’ll notice here — our other DBs have “exited” with a code of 0 — ie. They were never started. MySQL 8 is _ready for connections_ on _port: 3308_

_Side Note: Currently each DB port is hardcoded in the docker-compose file. If another port is needed, swap these out in the command: and ports: section, I’ll look to make a quick follow with ENVs for these as well._

## Connecting via DB Viewer

This is no different than running a DB locally. Your config will still look similar to the below image with localhost (or 127.0.0.1), port, username, and password.

**Config:**

![MySQL config modal](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/fbgqjl6kfl3cjmojz2gu.png)

**Connected View:**

![Connected view](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/enbkvgolztw8vhp75ukj.png)

## Next Steps

**Do I really need to `cd` into another project for all of this?!**

Nope!

Thanks to docker we can build some nice alias commands with the `-f` command.

```javascript
Base Command:docker-compose -f <path_to_file> <command> <service_name>
```

```javascript
# .bash_aliases
alias db:mysql8:start='docker-compose -f ~/Databases/docker-compose.yml start mysql8'
alias db:mysql8:stop='docker-compose -f ~/Databases/docker-compose.yml stop mysql8'
```

---

[View on echobind.com](https://echobind.com/post/docker-compose-db)

---

# Revelio: Defer and Lazy-Load with the Intersection Observer API

> Apr 08, 2021 | Deferring and lazy-loading are just a few techniques at our disposal for improving the load speed of a website.

_By Deloris Thompson · 2021-04-08_

Deferring and lazy-loading are just a few techniques at our disposal for improving the load speed of a website. One that I am a huge fan of is the Intersection Observer API; we are going to use it to lazy-load a video.

In 2016, Google conducted a research study and found that 53% of mobile users will leave a page that takes longer than 3 seconds to load. Just 3 seconds and your companies competitor could possibly gain a new user.

> _Intersection Observer API provides a way to asynchronously observe changes in the intersection of a target element with an ancestor element or with a top-level document’s viewport. — Mozilla_

## Creating an Intersection Observer

The first step is setting the target. This is the child element that is being observed when it interacts with the root (parent).

Next is creating a function; it is called once the page load is finished. The method contains an observer object, options hash, and a call to the observe function provided by the API.

```javascript
let target = "";

let createObserver = () => {
    let options = {
        root: null,
        rootMargin: '0px',
        threshold: 0
	    };
    let observer = new IntersectionObserver(callback, options);
    observer.observe(target);
};
```

**Observer:** An object set it to a new instance of the **Intersection Observer** constructor. We pass a reference/pointer to the callback function and the options hash.

**Observe:** Function provided by the API. Pass the target element you wish to observe here.

**Callback Function:** Triggered every time a change is observed. Accepts two arguments: the target(s) and the observer.

**Options:** Optional key/value pairs, defines the behavior. Consists of a **root, rootMargin**, **threshold**

**Root** — This is the parent element or document object. The value must be an element within the DOM tree. The default value is the viewport of the browser.

**RootMargin** — Margins around the root element that will grow and shrink the container. We set it similar to the CSS margin property. “5px 4px 12px 20px”.

**Threshold** — The percentage when the object we are observing is intersecting with the container. This will let the observer know when to react. It can be a single value or an array of values

## Callback Function

```javascript
let callback = (entries, observer) => {
    
    entries.forEach(entry => {  
        if (entry.isIntersecting) {
            target.insertAdjacentHTML("beforeend", 
																			'<p class="lead"><iframe width="704" height="396" src="<https://www.youtube.com/embed/_JkwZok_GHw>" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe></p>')
            observer.disconnect();
        }
    });
}; 
```

**isIntersecting:** Method provided by the API. True if the target element is intersecting with the root/viewport

**insertAdjacentHTML:** Attaches the image/video to the target (This is 100% optional, Mozilla and W3 Schools have a lot of methods you can choose from)

**disconnect():** Method from the API. Stops watching the target element(s). Use `unobserve(entry)` if you want to stop observing a single element

### Example:

#### HTML

```javascript

<div>
  <div>
    <h2>Intersection Observer</h2>
  </div>
  <div id="intersectionObserverVideo"></div>
</div>
```

#### JavaScript

```javascript
let target = "";

window.addEventListener(
  "load",
  (event) => {
    target = document.getElementById("interSectionObserverVideo");
    createObserver();
  },
  false
);

let callback = (entries, observer) => {
  const video =
    '<p class="lead"><iframe width="100%" src="https://www.yourSource.com/embed/_JkwZok_GHw"></iframe></p>';
  entries.forEach((entry) => {
    if (entry.isIntersecting) {
      target.insertAdjacentHTML("beforeend", video);
      observer.disconnect();
    }
  });
};

createObserver = () => {
  let options = {
    root: null,
    rootMargin: "0px",
    threshold: 0,
  };

  let observer = new IntersectionObserver(callback, options);

  observer.observe(target);
};
```

---

[View on echobind.com](https://echobind.com/post/revelio-defer-and-lazy-load-with-the-intersection-observer-api)

---

# React Native 0.64

> Apr 01, 2021 | The Facebook team recently announced their newest React Native version, which comes with some huge improvements.

_By Dominic Sherman · 2021-04-01_

The Facebook team recently announced their [newest React Native version](https://reactnative.dev/blog/2021/03/12/version-0.64), which comes with some huge improvements. While some of these changes are focused on the developer experience, the main ones will benefit all users of these apps.

## Hermes for iOS

[Hermes](https://hermesengine.dev/) is a JavaScript engine specifically built for React Native, which provides faster launch times, decreased memory usage, and smaller app sizes. These benefits together provide the user with a faster, easier experience to get started using your app, especially those on older devices who might not have as much memory or storage space available. Hermes as an engine has been around since its debut at [Chain React 2019](https://www.youtube.com/watch?v=zEjqDWqeDdg), but previously it was only available for use on Android. Now, with version 0.64, Hermes can be enabled on iOS devices.

In a direct comparison done by the engineering team at Facebook of a React Native app leveraging Hermes versus another without the Hermes engine, we identified 3 key improvements we see having an immediate impact on app performance:

* The time to interaction was over 2 seconds faster
* The memory utilization was almost 50MB less
* The application was almost 20MB smaller

![Hermes logo](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/kj28xxqnquqjzkiihozw.png)

## Hermes Proxy Support

With all of the improvements mentioned above for apps running Hermes, some apps were unable to use Hermes due to compatibility issues with popular libraries (for example react-native-firebase and mobx). Proxy support has now been added to Hermes in this version to allow those apps to enable Hermes and get all of the performance benefits that come with it.

## Performance tracing with Hermes

Previously, being able to do an in-depth analysis of the performance of your application took additional plugins or libraries. Now, developers running React Native using Hermes can easily check these details in the Performance tab of Chrome DevTools to ensure the app is always running at the high speeds we expect. This also allows developers to more easily debug any performance issues and isolate areas of the app that might need some more optimization.

![Screenshot of code](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/sa2isnlrzkoo8lexqtua.jpg)

## Inline Requires enabled by default

According to the React Native release blog:

_Inline Requires is a Metro configuration option that improves startup time by delaying execution of JavaScript modules until they are used, instead of at startup._

While this feature has been available for use for a couple years, it is now enabled by default.

Ready to see the benefits of React Native 0.64 in your app? At Echobind, we are here to support you at any point in the development life cycle, [contact us](https://echobind.com/contact) for help upgrading your [React Native](/capabilities/react-native-app-development) app.

---

[View on echobind.com](https://echobind.com/post/react-native-0-64)

---

# NextAuth.js Intro [2 of 3]: Magic Link Email Authentication

> Mar 25, 2021 | Another way many apps like to allow people to sign in easily is via use of a “magic link.”

_By Mike Cavaliere · 2021-03-25_

(This is the second article in a series on next-auth. Check out the first article for background: [One-Click Signup in Next.js With next-auth](https://echobind.com/post/nextauth-js-intro-1-of-3-one-click-signup))

From our previous article in this series, we know that one-click signup / sign in with next-auth using Google, GitHub, Facebook, or any other provider is pretty easy. Another way many apps like to allow people to sign in easily is via use of a “magic link.” The user will enter their email address and receive an email with a link they can click to login to the app.

As you may have guessed, that’s pretty easy with `next-auth` too 😉 Here’s how to do it.

Source can be found [in this branch at GitHub](https://github.com/echobind/next-auth-example/tree/with-email-auth).

## Create and structure a database

Database integration is required for email auth in next-auth currently, so we need to get this running first.

First we need a database. PostgresSQL is our default relational DB choice at Echobind, so that’s what we’ll use for this example. I use [Postgres.app](https://postgresapp.com/) for Postgres on localhost, and often start with a Heroku Postgres DB on the Hobby plan for the deployed version of small projects like this.

Connect to your database using `psql` or a client like Postico.

First create a database:

```javascript
CREATE DATABASE "next-auth-example"
```

The database needs some structure to hold user information in it, which next-auth [provides on their website](https://next-auth.js.org/adapters/overview). Run these `CREATE TABLE` statements and that'll do the trick.

```javascript
CREATE TABLE accounts
  (
    id                   SERIAL,
    compound_id          VARCHAR(255) NOT NULL,
    user_id              INTEGER NOT NULL,
    provider_type        VARCHAR(255) NOT NULL,
    provider_id          VARCHAR(255) NOT NULL,
    provider_account_id  VARCHAR(255) NOT NULL,
    refresh_token        TEXT,
    access_token         TEXT,
    access_token_expires TIMESTAMPTZ,
    created_at           TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updated_at           TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY (id)
  );
CREATE TABLE sessions
  (
    id            SERIAL,
    user_id       INTEGER NOT NULL,
    expires       TIMESTAMPTZ NOT NULL,
    session_token VARCHAR(255) NOT NULL,
    access_token  VARCHAR(255) NOT NULL,
    created_at    TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updated_at    TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY (id)
  );
CREATE TABLE users
  (
    id             SERIAL,
    name           VARCHAR(255),
    email          VARCHAR(255),
    email_verified TIMESTAMPTZ,
    image          TEXT,
    created_at     TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updated_at     TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY (id)
  );
CREATE TABLE verification_requests
  (
    id         SERIAL,
    identifier VARCHAR(255) NOT NULL,
    token      VARCHAR(255) NOT NULL,
    expires    TIMESTAMPTZ NOT NULL,
    created_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY (id)
  );
CREATE UNIQUE INDEX compound_id
  ON accounts(compound_id);
CREATE INDEX provider_account_id
  ON accounts(provider_account_id);
CREATE INDEX provider_id
  ON accounts(provider_id);
CREATE INDEX user_id
  ON accounts(user_id);
CREATE UNIQUE INDEX session_token
  ON sessions(session_token);
CREATE UNIQUE INDEX access_token
  ON sessions(access_token);
CREATE UNIQUE INDEX email
  ON users(email);
CREATE UNIQUE INDEX token
  ON verification_requests(token);
```

## Connect database and enable email provider in next-auth

Next we need to add the database adapter to our repo.

```javascript
yarn add pg
```

or `npm install --save pg`

Add the connection string to your `.env` file, so `next-auth` knows where to look for it.

```javascript
DATABASE_URL="postgres://my-root-user:my-root-pass@localhost:5432/next-auth-example?schema=public" 
```

Then uncomment this line in `pages/api/auth/[...nextauth].js` so that `next-auth?` knows where the database is:

```javascript
database: process.env.DATABASE_URL, 
```

Now we tell `next-auth` that we want to use email for authentication in that same file. In the array of providers, add:

```javascript
Providers.Email({
      server: process.env.EMAIL_SERVER,
      from: process.env.EMAIL_FROM,
    }),
```

## Set default theme

In next-auth 3.2, you’re able to set your sign in pages to use a light or dark theme, or to use the system theme (which is the default). The only quirk with this is that if your system is set to a dark theme, the background of the sign in page will be dark but so will the text, rendering it invisible!

As an easy remedy, I set the theme to `light` . in `pages/api/auth/[...nextauth].js` :

```javascript
const options = {
  theme: 'light',
  // ... other options
};
```

## Connect an email provider

Create an account with an email service so that your app can send emails out transactionally. My default is usually [SendGrid](https://sendgrid.com/), but there are tons of others. With any provider you’ll have to create an account, verify an email address to send from, and get the SMTP credentials from your account.

Once you have those credentials, you can add them to your .env file. My SendGrid configuration looks like this:

```javascript
EMAIL_SERVER=smtp://apikey:BIG-LONG_CRYPTIC_STRING:587
EMAIL_FROM=your-verified-sending-email@yourdomain.com
```

There are different ways you can specify this configuration as well, see the [docs](https://next-auth.js.org/providers/email#configuration).

## Restart and test

Restart your local server for the settings to take effect, visit your sign in screen and log in with an email address. You should receive an email containing a sign-in link.

Clicking that link will take you to the landing page. You are now signed in. 🎉

One thing to note is that when logging in with email, we don’t have any other information about the user automatically, so their name in the screenshot above is blank since it doesn’t exist. A small conditional will change that.

In `pages/index.js` we just update our conditional:

```javascript
{session && session.user && session.user.name && (
  <h3>Logged in as {session.user.name}</h3>
)} 
```

And now the text makes a lot more sense.

So far we’ve got two methods for logging in fast, and easily in Next.js using `next-auth`. Later in this series we'll explore what you can do with user information now that the user is logged in.

---

[View on echobind.com](https://echobind.com/post/nextauth-js-intro-2-of-3-magic-link-email-authentication)

---

# Measure Twice Code Once

> Mar 17, 2021 | At Echobind, we spend a significant amount of time planning before a single line of code is written.

_By Isaac Myman · 2021-03-17_

## Measure Twice Code Once

I often tell people I work in software development and get the response “So, you code?”. It seems the outside world doesn’t realize that much like a carpenter, the planning and measurement is just as (if not more important) than the cut.

![What people think I do poster](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/mfec150ld8ni1rucdl3t.png)

At Echobind, we spend a significant amount of time planning before a single line of code is written. We have made it part of our [playbook](https://echobind.com/playbook). We utilize various processes and tools to understand what the business goal is, how we will measure success, and what the features will actually look like. Then we take all of this and wrap it together to create a comprehensive document that describes the project in perfect detail.

![ER diagram](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/m9fwroem5dzgew6i30sm.png)

We start with our discovery session. We use a client questionnaire and a kickoff meeting to start gathering the “why” of the project. We use this as a fact-finding mission asking questions that from our experience steer the conversation toward the true business goals. We then gather up every possible feature imaginable. Once we have our feature list and business goals we go to work. Matching every feature to a business goal we move them to must-have, nice to have, and phase 2\. Once we have this we get moving on a user flow. A schematic of the application showing every which way we could go once we open it up. At the end of this, we have the makings of a true MVP.

After discovery, we move to wireframes. We go through the process of designs and revisions, discussion and iteration. We refine what is needed and set the rest to the side. Once this is done we have a clickable prototype of exactly what we plan to build.

![Stick figure](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/rmt5pvczyyfi14muapdk.png)

Now that we have everything this project is going to be we piece it all together. This is our business requirements document. It takes all the knowledge that has been gathered since the first engagement to the final wireframe and puts it together into a single comprehensive document. This will have everything from business goals and key performance indicators to risks and technical needs. We use annotated wireframes to describe exactly what each feature does and the actions that can be taken.

The apex of our planning comes in the form of this document. We use this to estimate the cost of the application. We are able to go feature by feature and understand what is needed at a granular level. This also provides an opportunity to work with our clients to cut scope when needed. The idea is that I can take the business requirements document and hand it to anyone and they will be able to read it and know exactly what we are building. In the end, we have a full plan on what to build and how to do it that could be given to any agency with faith they should be able to build it including ours.

Our strategy team has found planning in this much detail and working this much upfront saves buckets of money. Changes during engineering are the most expensive and with this document, they become nearly negligible. Business and engineering can all agree on what we are building from a single document. No translation needed. This is why we measure as many times as it takes before we make that first cut.

---

[View on echobind.com](https://echobind.com/post/measure-twice-code-once)

---

# NextAuth.js Intro [1 of 3]: One-Click Signup

> Mar 11, 2021 | Integrating one-click signup with Next.js can take a fair bit of work, but the fantastic next-auth package makes it incredibly easy and flexible.

_By Mike Cavaliere · 2021-03-11_

One-click signup using Google, Facebook, or any other existing provider is a desirable feature for most web applications, since it makes it faster and easier for people to create accounts. Integrating one-click signup with [Next.js](https://nextjs.org/) or any other isomorphic web framework can take a fair bit of work, but the fantastic `[next-auth](https://next-auth.js.org/)` package makes it incredibly easy and flexible.

In this article, I’ll show you how to set up one-click signup in a Next.js application via Google and GitHub, and how to easily force users to be logged in to see your content.

Full code is available here on [GitHub](https://github.com/echobind/next-auth-example), and an interactive demo is [here on Vercel](https://next-auth-example-1.vercel.app/).

**Part 2 of this series is here:** [Magic Link Email Authentication in Next.js with next-auth and PostgreSQL](https://echobind.com/post/nextauth-js-intro-2-of-3-magic-link-email-authentication).

## Scaffold app and add dependencies

Let's generate our app as we normally would, then add `next-auth`.

```jsx
yarn create next-app next-auth-example
yarn add next-auth

```

Now we have our app scaffold; nothing surprising here if you’ve ever done this before.

## Create Provider Credentials

Create an account for every provider you want users to be able to log in to your site with. I'm using Google and GitHub in this example, but `next-auth` supports [a ton](https://next-auth.js.org/configuration/providers) so go crazy.

From each provider, you’ll need to get an access **key** and **secret**. Those will go in your local .env file as follows:

```jsx
GOOGLE_CLIENT_ID=123123123
GOOGLE_CLIENT_SECRET=abcabcabc
GITHUB_CLIENT_ID=123123
GITHUB_CLIENT_SECRET=abcabc

```

Later when deploying to Vercel, these will go into Vercel environment variables as well.

## Configure next-auth

Ok let’s get to the code! 🎉

Following <https://next-auth.js.org/getting-started/example>, first add their route file which makes their magic integration happen. Then add any providers you want. Below I’ve added Google and GitHub.

```jsx
import NextAuth from 'next-auth';
import Providers from 'next-auth/providers';

const options = {
  // Configure one or more authentication providers
  providers: [
    Providers.GitHub({
      clientId: process.env.GITHUB_CLIENT_ID,
      clientSecret: process.env.GITHUB_CLIENT_SECRET,
    }),
    Providers.Google({
      clientId: process.env.GOOGLE_CLIENT_ID,
      clientSecret: process.env.GOOGLE_CLIENT_SECRET,
    }),
  ],

  pages: {
    signIn: '/auth/signIn',
  },

  // A database is optional, but required to persist accounts in a database
  // database: process.env.DATABASE_URL,
};

export default (req, res) => NextAuth(req, res, options);

```

## Add session and theme to application state

Now we'll add the next-auth session state to our \_app.js so that it's available everywhere via the `useSession` hook. We'll also add Chakra's theme information to the application in the same manner, so we can style everything pretty easily.

```jsx
import { Provider } from 'next-auth/client';

function MyApp({ Component, pageProps }) {
  return (
    <Provider session={pageProps.session}>
      <Component {...pageProps} />
    </Provider>
  );
}

export default MyApp;

```

## One last .env variable

next-auth also requires the `NEXTAUTH_URL` environment variable for some functionality, so your .env file should now look something like this.

```jsx
GOOGLE_CLIENT_ID=123123123
GOOGLE_CLIENT_SECRET=abcabcabc
GITHUB_CLIENT_ID=123123
GITHUB_CLIENT_SECRET=abcabc
NEXTAUTH_URL=http://localhost:3000

```

## Add authentication!

Now that the setup is complete, let’s give people the ability to sign in and sign out.

Our index.js will now look like this:

```jsx
import styles from '../styles/Home.module.css';
import { useSession, signIn, signOut } from 'next-auth/client';

export default function Home() {
  const [session] = useSession();

  return (
    <div className={styles.container}>
      <main className={styles.main}>
        <h1 className={styles.title}>This is the welcome page.</h1>

        <h2>You're currently {session ? 'logged in.' : 'logged out.'}</h2>

        {session ? (
          <button onClick={signOut}>Log out.</button>
        ) : (
          <button onClick={signIn}>Log in.</button>
        )}
      </main>
    </div>
  );
}

```

Here are the notable pieces:

First we call the `useSession` hook to determine login status.

The next-auth `useSession` hook is multi-purpose. By returning an object in the `session` variable (and not a falsy value), it tells us whether the person is logged in or logged out respectively. It can also return a second `loading` boolean to tell us whether it's currently checking session status; we're not doing it in this example, but that's useful if you want to show a loading spinner while it's checking.

Then we add the Log in and Log out links that trigger the default `signIn` and `signOut` functions provided by next-auth. Now we've got basic one-click login functionality already. 🎉

![White screen with GitHub and Google sin up butons](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/dnz9f2lpwkxzs34humje.png)

![Welcome screen with log out button](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/n98ki3x3yikdibw02elb.png)

The other purpose of `useSession` is getting information about the logged-in user. If `session` exists, it'll have user information inside of it. So if we add this line to the index.js page:

```jsx
{session && session.user && <h3>Logged in as {session.user.name}</h3>}

```

We’ll now be able to display the user’s name when they’re logged in:

![Welcome screen with log out button and login name](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/bjxtare8gor5z137df89.png)

That’s it. In a matter of minutes you were able to allow a user to create an account on your site with a few clicks.

Here’s some even better news: next-auth can do a _lot_ more. In subsequent articles we’ll talk about how to control access to private information, allow signing up via email with a magic link, mashup Google profile info with your app’s custom data, and more.

**Now, check out Part 2:** [Magic Link Email Authentication in Next.js with next-auth and PostgreSQL](https://blog.echobind.com/magic-link-email-authentication-in-next-js-with-next-auth-and-postgresql-bf12b4fa908a).

---

[View on echobind.com](https://echobind.com/post/nextauth-js-intro-1-of-3-one-click-signup)

---

# From Teaching to Tech

> Mar 04, 2021 | Kim made the terrifying career leap into something different and thankfully is no worse for wear.

_By Kim Wilkes · 2021-03-04_

I did it. In a year, I made the terrifying career leap into something different, and am, thankfully, no worse for wear. In fact, I’m thriving and I’m so happy I can’t really quite commit to words the feelings I have now about accomplishing the hardest part of a career change — getting a job in the tech field at a place where I am frequently learning, supported, and happy. I know everyone struggles to consider or even make that leap and those who do try, don’t always end up where they hoped to land. I still believe it’s worthwhile and hopefully my experiences can provide others that push as well.

## **The Start**

I graduated college with a degree in Psychology and Black studies and moved to Boston alongside many friends with different majors. Despite this, somehow during that transition into adulthood, the majority of them ended up in or transitioning to software engineering. I became a teacher through Boston Teacher Residency because of my passion for helping others, and fears that I didn’t have the grades to continue pursuing Psychology beyond undergrad. It was a great 6 years working with a range of grades, students, and schools. I worked in second grade up to middle school teaching English Language Arts to Math, Science, and Social Studies. I eventually picked up a special education certification and was charged with creating fully inclusive learning experiences that would almost always benefit all of my students. It changed the way I thought about my students and pushed me to develop a broader understanding of how people interact with the world around them.

![Computer cart full of chromebooks](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/eikdqitb4nzrvtgg0sdx.jpg)

Throughout that time, I was considered the tech guru and coworkers would always come to me for help. Whether it was setting up speakers or computers to navigating surprisingly complicated websites, I learned that a lot of teachers had a very frustrating fear and wariness of technology. A fear that was coming up with far more frequency as standardized testing has made its own push into the tech world, requiring students to take tests on computers and type up 3–5 paragraph essays. Students were doomed to fail if they had no previous experience using a computer and teachers panic at the prospect of having a third grader try to use a touchpad to find their way to a web browser to access the testing sites. I had always appreciated tech and was never that afraid to just go in and break things because I figured there was always a way to recover or get help.

I didn’t think anything of it beyond looking into online courses to try to learn python or just get better at Microsoft suite of apps. I had tried to do the Harvard CS50 class and couldn’t commit the time and energy after a day of teaching. It wasn’t until one of my rare, non-engineering friends needed to make a tough decision to change career paths, that I really reflected on my own career choice. Due to (my lack of) seniority, and staffing needs, I had to either find a new school or move on to something else entirely. It was because of this sudden opportunity, and my friend’s own career shift, that I realized it was possible to make the switch and to begin looking into my options to really commit. Thanks to the academic calendar and what remained of my teacher salary to be paid out, I could leap into a bootcamp with minimal financial fears.

![Work vs GA note](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/tmme3j9fxmwtznxpnjcd.png)

## **The Bootcamp**

The [General Assembly](https://generalassemb.ly/) Full-time Software Engineering Immersive bootcamp was exactly the kick I needed to really buckle down and learn software engineering. Nothing like spending a pretty big amount of money and committing full time to make you significantly more invested in something. General Assembly offered loans, payment plans, or an income share agreement where they take a percentage out of the paycheck once you get a job. Once that was decided, four projects were all that stood between me and starting the path into software engineering! The first one was the hardest, and much like teaching, the first year is always the most difficult, but it only goes up from there. I think this can be true of trying anything unfamiliar for the first time, especially having built up a particular mental image of success, based on unrealistically high standards simply due to lack of knowledge.

Through this bootcamp I (re)discovered my love of working on UX/UI. Rediscovered because I had played around with website layout generators for social media and my experiences helping others navigate apps made me think about potential users so much more. If it weren’t for my engineering friends, I would have taken the UX/UI course. But they believed it would be better to have coding skills to back up my understanding of UX/UI rather than trying to learn to code later.

## **The Year of Waiting**

![board with post-its](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/ghxcwdwzrkud7kqcmzjc.png)

From my October bootcamp graduation, I was now on the terrifying path of actually applying for jobs with just my bootcamp certificate and my own scrappy attitude in hand. I applied to hundreds of postings with minimal response. I counted myself lucky to even get a rejection email. Before my bootcamp, I had also decided to get an Associate’s in Computer Science at Bunker Hill Community College to make up for my lack of STEM from my undergrad/master’s. This helped occupy my time as I developed other coding languages and deeper understanding that I wasn’t able to get during the bootcamp in what was the fastest 12 weeks of my life.

I felt like I could make space for my old cosplay and video game hobbies for the first time in years. I attended meetups and would reach out to people on LinkedIn or through the meetup slack channels to get some insight into the industry and any advice they could offer. I confided my fears to my friends and family and had many ups and downs in my confidence about this choice. And while I was able to benefit from unemployment, I had learned, perhaps too late, that some applicant tracking systems won’t read a .pdf or .doc of the original file used tables or columns. A revelation that wouldn’t fully click in until my participation in [Hack.Diversity](https://www.hackdiversity.com/).

## **The First Internship**

Hack.Diversity is a career leadership and workforce development program that provides mentoring and support for under-represented populations in the tech industry. We were introduced to their partner companies and had the opportunity to interview with them. After getting my applications in, I had to reapply because my resume had turned up blank for them. They provided many incredible resources and workshops to help level up hard and soft skills and match us with amazing mentors, who are passionate and knowledgeable about the industry. I couldn’t have been paired with a better mentor. We practiced elevator introduction pitches, checked zoom/video quality and lighting, and always established next steps for my goals.

Through Hack.Diversity I was able to land my first internship/job with [athenaHealth](https://www.athenahealth.com/). It was a great learning experience as it offered a small taste of what devOps looked like. A field I had never really been exposed to up to that point and had really no idea about. I always try to keep an open mind about the world, so I welcomed the opportunity to grow. I learned a lot and the experience affirmed my love of all things on the front-end side of software engineering .It also provided me with some greater clarity on where I can see myself going on this career adventure. From there I was able to network with my Hack.Diversity mentor to bring me to [Echobind](https://echobind.com/).

## **The First Job**

Echobind has provided a wonderful space to grow and hit the ground running. I’m encouraged to ask questions, share my thoughts, and just be myself. With Echobind being remote first, the most important lesson I’ve gotten is to ask questions, whenever you can. I feel lucky to have great coworkers and a variety of projects to work on, and I never get the feeling of being stuck in one place. In addition, I get regular feedback and opportunities to be heard. It’s been an amazing experience to be able to pair with senior engineers and check myself whenever I think, “Oh god, I’m making all these silly mistakes,” and see senior engineers also struggle. They’re just much faster at figuring out the issue and have even more experience of tools to help them navigate issues. Not to mention some keyboard or command line shortcuts that have become muscle memory for them. Everyone is willing to help in whatever way they can and share their learnings, a culture that I dearly appreciate. If I hadn’t found people to talk through those fears, then I might not have found enough self-motivation to keep going. The future is certainly looking brighter after a year of uncertainty and fear.

![Board with multiple pictures](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/mplmqwqcxgzd270cjzcw.jpg)

---

[View on echobind.com](https://echobind.com/post/from-teaching-to-tech)

---

# A JAMStack Blog in No Time with Next.js & Bison

> Next.js is a fantastic framework for building fast and powerful JAMStack web applications — that’s one reason among many that it’s our go-to JavaScript framework at Echobind.

_By Mike Cavaliere · 2020-10-19_

Next.js is a fantastic framework for building fast and powerful JAMStack web applications — that’s one reason among many that it’s our go-to JavaScript framework at Echobind. We’ve wrapped Next.js with a set of tools we regularly use into a JAMStack generator called Bison, which makes Next.js even more powerful. In this article, I’ll show you the steps to building a custom blog with Bison and Next.js.

If you want to jump right to the code, [here’s the repo on GitHub](https://github.com/mcavaliere/bison-blog).

## Run the Bison Generator

```javascript
yarn create bison-app bison-blog 
```

![](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/kjlpqoqcaiajeponxjb6.png)

This will generate your app skeleton, run `yarn install` and create a Git repo automatically.

![](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/hpmwc6m4z2k7tjjrollf.png)

## Set up your database

You’ll want to [check the latest README](https://github.com/echobind/bisonapp#getting-started) for full steps, but it’s as simple as making sure PostgresSQL is running (I highly recommend [Postgres.app](https://postgresapp.com/)) and running `yarn db:setup`

.

You’ll be asked a few questions during setup, and it’ll do the rest of the work for you.

![](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/xt2tgcjrlns7qpiwll6u.png)

![](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/uwhifiy4knjqf0b07bbh.png)

## Start the app

Run `yarn dev` from the directory you just created, and visit <http://localhost:3000>. Your app is running, and you should see a screen like the one below. We’re in business.

![](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/uugoz1ylaaiw5tozbpz3.png)

## Create a user account

Bison comes pre-packaged with a simple user authentication mechanism, so signing in or signing up is a cinch.

First, tap **Login** to get to the login screen, then click **Sign Up**.

![](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/lfcdzuxghxgpaubhlwsg.png)

![](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/sy8onuh4xa3yywce1u7w.png)

Fill out the form and submit, and you’ll be logged in and redirected to the home page.

![](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/ntau4uguqbgrfpclzqo1.png)

## Add some database tables

We’ll need a `Posts` table and model to create and list posts. Edit `schema.prisma` which is the source of truth for the data model. Adding a `Post` model is pretty easy.

![](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/jovodrtcqkw5hvqrtcub.png)

Then run `yarn prisma migrate save --experimental`, to generate a database migration for it.

![](https://res.cloudinary.com/echobind/image/upload/v1661872447/echobind_blog/zkw8acodrynsin5eptaq.png)

![](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/ybqkf0oqggjgxqlfsc8i.png)

Now run the migration using `yarn db:migrate`.

![](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/zu8wnfqdgqkxosx9rgbh.png)

If you look at your database using Postico or `psql`, you’ll see the resulting table and columns.

![](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/dlfyyftjtzaxkdv9t0gy.png)

## Generate a page for creating posts

Use Bison’s page generator to stub the `/posts/new` page:

```javascript
yarn g:page posts/new
```

![](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/vdyancyqdjmi2cidvoje.png)

## Generate components

We’ll need 2 React components for creating and showing posts `PostList` and `PostForm`, so we’ll generate them with Bison’s CLI commands. These wrap 👍 some pre-packaged [Hygen](https://www.hygen.io/) generators that Bison comes with.

```javascript
yarn g:component PostList
yarn g:component PostForm
```

![](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/niy4nrdg7z44nsxr1pgn.png)

![](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/tvihurjuvccmrdw2yvsi.png)

Now you’ll see these 4 new files in your folder tree:

![](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/ughpjgglbn2gvrtxjebe.png)

![](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/t7ih0wdrhod7gisa2vnr.png)

All rightie! Let’s add some code.

## Create the “New Post” form

The page container for `/posts/new.tsx` is quite simple; aside from styling, we add the  component which we’ll build immediately after.

```javascript
 import React from 'react';
import Head from 'next/head';
import { Heading, Flex } from '@chakra-ui/core';

import { PostForm } from '../../components/PostForm';

function PostsNewPage() {
  return (
    <>
      <Head>
        <title>PostsNewPage</title>
      </Head>

      <Flex direction="column" justify="center">
        <Heading size="lg">New Post</Heading>

        <PostForm />
      </Flex>
    </>
  );
}

export default PostsNewPage;
```

## Create the <PostItem /> component

Full code is [here](https://github.com/mcavaliere/bison-blog/blob/master/components/PostForm.tsx). Here are some highlights.

Bison comes packaged with [react-hook-form](https://react-hook-form.com/), so we build the form out like this:

```javascript
<form onSubmit={handleSubmit(onSubmit)}>
      <FormControl isInvalid={errors.title}>
        <FormLabel htmlFor="title">Post Title</FormLabel>
        <Input type="text" name="title" id="title" ref={register({ required: true })} />
        <FormErrorMessage>{errors.title && <span>This field is required</span>}</FormErrorMessage>
      </FormControl>
      <FormControl isInvalid={errors.body}>
        <FormLabel htmlFor="body">Post Body</FormLabel>
        <Textarea name="body" id="body" ref={register({ required: true })} />
        <FormErrorMessage>{errors.body && <span>This field is required</span>}</FormErrorMessage>
      </FormControl>
      <Button type="submit">Submit</Button>
    </form>
```

Because Bison also sets up [nexus-plugin-prisma](https://github.com/graphql-nexus/nexus-plugin-prisma) for us, We add a mutation to create a post like so:

```javascript
export const CREATE_POST_MUTATION = gql`
  mutation CreatePost($data: PostCreateInput!) {
    createOnePost(data: $data) {
      id
      title
      body
    }
  }
`;
```

In turn, Bison’s `graphql-codegen` configuration sees the above and generates a nice React hook for us to plug into 🎉:

```javascript
import { useCreatePostMutation } from '../types';
```

We use this and a few other hooks to get our data into the form component:

```javascript
export function PostForm() {
  const { register, handleSubmit, errors } = useForm();
  const [createPost] = useCreatePostMutation();
  const router = useRouter();

  const { user: { id: userId } = {} } = useAuth();
  // ...
}
```

And here’s the `onSubmit` handler which triggers the createPost mutation and redirects back to the homepage upon success:

```javascript
const onSubmit = async (data) => {
    // Create the post
    await createPost({
      variables: {
        data: {
          ...data,
          author: {
            connect: {
              id: userId,
            },
          },
        },
      },
    });

    // Redirect to homepage
    await router.replace('/');
  };
```

Now we’ve got a form that saves a post to the database. Voila. 🚀

![](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/jqevabe9bw85taozajgj.png)

## Create the <PostList /> component

Now that we’ve got data, let’s display it.

If you remember, we already ran the generator for the `` component. So we start by importing the `` into the homepage and displaying it like so:

![](https://res.cloudinary.com/echobind/image/upload/v1661872447/echobind_blog/poziqwvzgkrrfxnala52.png)

Now we’ll need to fetch and display the posts. When fetching data with Bison, we recommend something called a “cell.” A cell is a concept [borrowed from Redwood.js](https://redwoodjs.com/docs/cells). It’s a declarative way of wrapping the GraphQL query together with loading, success, and error states.

`yarn g:cell FetchPosts` will create `/cells/FetchPosts.tsx` as below.

![](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/evvnrij5tojurxbh2a4u.png)

Now we’ll fill the cell out with the correct query and some formatting for the rendered posts.

Full code [here](https://github.com/mcavaliere/bison-blog/blob/master/cells/FetchPosts.tsx). Important snips:

```javascript
export const POSTS_QUERY = gql`
  query posts {
    posts {
      id
      title
      body
    }
  }
`;
export const Success = ({ posts }: PostsQuery) => {
  return (
    <Stack>
      {posts.map((p) => (
        <Box p={5} shadow="md" key={p.id}>
          <Heading>{p.title}</Heading>
          {p.body}
        </Box>
      ))}
    </Stack>
  );
};
```

Don’t forget to include the cell in the  component:

`export function PostList() { return ; }`

And we’re done. You now have a (very simple and basic but functioning) blog built in Next.js. Add some data and start having fun.

![](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/shh5iub6nlglid8y9u8d.png)

## Conclusion

[Bison](https://github.com/echobind/bisonapp) is in its early stages, but is already a useful tool for kickstarting your Next.js project quickly with great stuff like Prisma, Nexus, and Hygen built-in.

If you try out this tutorial, please drop me a line with any feedback or questions. Or comment right here.

---

[View on echobind.com](https://echobind.com/post/creating-your-own-jamstack-blog-in-no-time-with-next-js-and-bison)

---

# Choosing Your Path

> Sep 18, 2020 | Jenn, our Dir. Engineering explores how she landed in this industry and lessons learned along the way.

_By Jenn Robison · 2020-09-18_

We all know the saying “Hindsight is 20/20”, which is the ability to evaluate past choices more clearly than at the time of the choice we made. After many years in tech, I find myself evaluating how I landed where I am today and wanting to share some of the things I’ve learned along this path. It’s a bit like[ Choose Your Own Adventure](https://www.cyoa.com/); for those not catching the reference, this was an amazing book series in my childhood. In these books, you would read a few pages and have to make a critical decision about where to go next. There were many decision points throughout the book and you might even go back a few times to change the outcome. You might even try and peak at your choices and see where that path will lead, but that isn’t something we really get the option to do in our real lives. So for better or worse, here is the adventure I have been on thus far.

As of late, it is far more common to not have a computer science degree, but that wasn’t the case when I started in tech. I love seeing the articles shared on[ No CS Degree](http://nocsdegree.com/), normalizing self-taught, and bootcamp developers. Growing up I saw my mom go to trade school at night and become a COBOL programmer. After my parents divorced, my mom went to school at night and began her journey — which eventually led her to being a project manager for a large health insurance company during the Y2K craze. I was inspired, I dabbled with our [Tandy computer ](https://www.old-computers.com/museum/computer.asp?st=1&c=109)early on, making it sing and change colors on our TV.

After high school I found myself choosing a harder path than I had originally planned. I entered the workforce doing data entry, and then got hired by a large tech company as an administrative assistant. In those early days, I knew this was a stepping stone, as it was supposed to be a short term stop while I went to school to be in the medical field. Not long after I started at this tech company I began taking on tasks like managing our internal department websites; this was in the days of FrontPage and DreamWeaver. We wanted to add features like employee look-ups, so I started to learn some very basic JavaScript. During this time I was working on my Associates Degree and taking courses for my EMT (Emergency Medical Technician). I started to see opportunities as a developer and with that I chose a few courses for my associates that included learning data structures and some Visual Basic. The team I was working with had a large eBusiness initiative and I immersed myself in this project and began working as a business analyst; although I was still an Admin. This went on for some time. I was nearly complete with my Associates Degree and I began to advocate for being recognized for the work I was doing. It was honestly frustrating, I was being asked to keep doing the additional responsibilities without the commiserate compensation. My manager at the time gave me three options:

1\. Get promoted now  
2\. Get promoted in 9 months when my associates program was completed  
3\. Get promoted in approximately 6 months at the normal review cycle

I remember looking at him and saying something like “obviously now!”. Thank goodness I spoke up and advocated for myself. I had been doing that job for about 18 months before getting the promotion. I wish I could say that my experiences changed through the years, but I found I had to always advocate for myself and be the squeaky wheel to be recognized for the work I was doing.

I look back on those days and I wish I would have spoken up sooner, but I learned so much from those experiences. Recently, I was asked what advice I could share with another woman in tech, and what I wish I knew before. I was very candid with her, I shared my experience and that I can’t stress the importance of working with a team where you feel heard and valued. If you are not heard and valued, speak up, and do NOT let leadership brush you off.

My career continued. I had to learn to find balance as a developer and also feel like I belonged on teams that were primarily all CS majors. As I had children I knew I didn’t want to be working more than 40 hours so I had to find ways to ensure my balance. Looking back I probably stayed at my original tech company for many more years than I should have but I learned so much. I grew through all of those experiences and I took that all with me later. One constant was the need to advocate for myself, find new opportunities, and not allow my voice to be quieted.

When I got to a point where I no longer felt challenged, and the open opportunities didn’t seem to offer anything exciting, I knew it was time to move on. This was a very scary prospect and actually took me several years to take action. My years had been spent as an internal application developer and not experiencing products outside those four walls. I was waiting for a great opportunity that made sense; I felt comfortable where I was and worried I wouldn’t have the same success elsewhere. In reality, I was conditioned by those around me to think that the success I had was due to the environment I was in and I wouldn’t experience that elsewhere.

Fast forward to 2018, I experienced workplace sexual harassment. Harassment that was reported and invalidated. This experience made me sick! I no longer came to the office, I refused to be around the offender and ultimately this was the straw that broke the camel’s back. I’m proud of myself for not backing down at this point, for not allowing this experience to prevent me from moving forward. If anything, it lit a fire within me.

An opportunity presented itself to move to another company and build upon the skills I had built over the years and jump over to mobile development using React Native. This frightened me, I talked to so many peers and mentors that I trusted and ultimately made the leap of faith to leave the company that started my adult life and brought me to this point. This decision allowed me to feel like I held my values and integrity and fought for what I believed in.

That mobile development role allowed me to spread my wings, see that I could be wildly successful in another environment. Through these experiences, I’ve learned that being opinionated is ok and that your success is a culmination of the effort you put in and the people you surround yourself with as mentors and advisors.

In my current role I have felt a tremendous amount of growth in a short period of time. A good part of this is culture — finding a team that values individuals for the experiences they have and listens with an open mind. Believe me, I know this can be hard to find, but treasure it when you do! Make it known what they are doing well, give feedback to those around you that help you feel included!

Never settle, don’t stop learning, keep pushing forward for the right change! We don’t get to peek and see what is ahead, we have to use the information and experiences from our past to make the best decisions when we are at the fork in the road.  
I am very proud of where I am today. In all honesty, sometimes I want to pinch myself. It’s hard to believe that I’ve been able to share my learnings and experiences on stage and to virtual audiences. Your path might not be traditional and it will likely look different than everyone else’s around you; keep moving forward towards your goals!

---

[View on echobind.com](https://echobind.com/post/choosing-your-path)

---

# A Guide for RESTful APIs with Node, Sequelize & Postgres

> Sep 01, 2020 | This guide will assist you with setting up a Node.js project, and installing Sequelize to allow for object relational database mapping between a Postgres database.

_By Mickey Martinez · 2020-09-01_

If you’ve landed here, hopefully you’re looking for help getting data flowing from a [**Node.js**](https://nodejs.dev/learn)and[**Express**](http://expressjs.com/) web application, to a [**PostgreSQL**](https://www.postgresql.org/about/) **database** with [**Sequelize**](https://sequelize.org/master/manual/getting-started.html) **as the O.R.M.** This guide will assist you with **setting up a Node.js project**, and **installing Sequelize** to allow for object relational database mapping between a Postgres database.

The simplest way to think of **O**bject **R**elational **M**apping is as a process for _accessing a relational database_ — Postgres in our instance — _from an object-oriented language_ like JavaScript. Sequelize allows us to interact with a Postgres database using JavaScript instead of SQL.

> _“Sequelize is a promise-based Node.js ORM for Postgres, MySQL, MariaDB, SQLite and Microsoft SQL Server.” —_ [_sequelize.org_](https://sequelize.org/)

Before we get moving, let me lay out the tools we’ll be using. This way you have a high-level sense of what tools you should be knowledgeable of, and what you can expect to extract from this guide.

* [Node.js](https://nodejs.org/en/download/) 🎛
* [Sequelize](https://sequelize.org/master/manual/getting-started.html) 📝
* [Postgres](https://www.postgresql.org/download/) 🗄 (I’m using [Postgres.app](https://postgresapp.com/) for mac)
* [Postico](https://eggerapps.at/postico/) 🔍 (or any DB viewer for Postgres)
* [VS Code](https://code.visualstudio.com/) 💻
* [yarn](https://yarnpkg.com/getting-started) 🧶

Project Dependencies

* express 👂🏼
* dotenv 🔐
* nodemon 🔁
* sequelize-cli 🗺

## Prerequisites

To have the most success using this guide you should have a general**_command of JavaScript_**. You also **_need to have_**[**_Node.js_**](https://nodejs.org/en/download/) _and_ [**_PostgreSQL_**](https://www.postgresql.org/download/) **_installed_** on your machine.

_💡 Postgres and PostgreSQL are the same thing. This confused me at first, but it’s just industry semantics — although PostgreSQL is the official name._

While my goal is to help you **configure Sequelize with Postgres**, in the process we will be **building a RESTful API**. Once we have data flowing properly, you can expand on this app’s build however you’d like — adding more routes or developing the front-end.

### Why Postgres?

Those of us who have only dabbled with the back-end, may have done a few tutorials using a non-relational database like [MongoDB](https://www.mongodb.com/). And I can attest I’ve learned a ton by using MongoDB with Node.js — seeing data flowing and testing endpoints with Insomnia.

I quickly realized when landing my first engineering gig that it’s imperative to command knowledge of relational DBs (databases). Postgres itself is an _“object-relational database system that uses and extends the SQL language,”_ according to the [official website](https://www.postgresql.org/about/). Its language is designed to perform CRUD (Create, Read, Update, Delete) operations on a database, it scales vertically and can perform complex queries across multiple tables of data.

### Sequelize what?

Without Sequelize, we’d have to execute SQL statements in order for us to interact with Postgres and perform CRUD on our databases. Sequelize handles this translation for us, allowing us to interact with a Postgres database using JavaScript instead of SQL.

## Setting up a new Sequelize project

Now that we have some context established, let’s get to the code!

For this guide, I’ll be using yarn 🧶. _The_ [_official Sequelize documentation_](https://sequelize.org/master/manual/migrations.html) _uses_ npx_._ We'll create yarn scripts along the way for future developers to join the project. For a full working example, click here (Link to spike with yarn scripts).

### Create new directory

Let’s start by creating a new directory for our project, and setting it as our working directory.

**Open your terminal**, and **enter** `mkdir` to create a new directory (empty folder) on your desktop for this project. **Change directories** `cd` into the folder that you just created.

```bash
mkdir sequelize-app
cd sequelize-app
# Our project's directory name will be sequelize-app
```

### Configure project

Next, we **initialize Node.js** and **create a new** `package.json` file in the root directory of our app by **running the command** `yarn init`.

Press `enter/RETURN` to accept the default set up, although we do want to name our main file `app.js` instead of `index.js`.

```javascript
entry point (index.js): app.js
# You can choose to name this server.js or index.js
# I'll be using app.js
```

**Install the dependencies** for this project by running the commands:

```bash
yarn add express
yarn add dotenv
yarn add nodemon -D// -D for devDependency
```

From the terminal, now **open your project in VS Code**.

```bash
code .
```

**With VS Code open**, select your `package.json` file. **Add in** a `"scripts"` **object**, and then **add the script below to start our server with nodemon.**

```json
"dev": "nodemon -r dotenv/config app.js"
```

💡 We’ve also added `-r dotenv/config` to the script so that dotenv is required and pre-loaded. Meaning, we won’t need to require and load dotenv in our application’s code — more on that [here](https://www.npmjs.com/package/dotenv).

![Package.json file](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872445/echobind_blog/f1wmdjbtxwxmzj51dnki.png)

package.json file with initial dependencies and nodemon script

Now we’re set up to **run our application by simply using the** `yarn dev` **command**. Nodemon will enable _"hot-reloading"_, allowing our server to continue running while monitoring for changes in our files — auto-restarting the server after saved changes.

**Create a** `.env` **file** in your root directory — a hidden file to pass environment variables and protect secure information like port numbers, passwords, database URIs.

**Add in known environment variables** to the `.env` file:

* `PORT=3000`
* `DB_HOST='127.0.0.1'`
* `DB_USERNAME='postgres'` // default username for Postgres
* `DB_PASSWORD='postgres'` // default password for Postgres

💡 _Sequelize can use a full DB\_URL string, other config options can be found_ [_here_](https://sequelize.org/docs/v6/getting-started/)_._

![.env file](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872445/echobind_blog/xx28mimkwjsvdrqtvjhs.png)
*.env config*

🧰 **Optional step if pushing to GitHub** 🧰

**Run** `git init` // Creates an empty Git repository

```javascript
git init
# Initialized empty Git repository in /Users/mickey/projects/sequelize-app/.git/
```

Next, **create a** `.gitignore` **file** and **add** `.env` & `/node_modules` as assets that **GitHub will ignore** when updating your repo. By doing this step, `.gitignore` prevents you from accidentally uploading your hidden `.env` file to your repo .

![.gitignore file](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872446/echobind_blog/ywqqebfyl1exbjds2rjh.png)
_.gitignore file for protecting your assets_

### Express Server

**Create** an `app.js` file in the root directory, and `set up the Express server:`

* Require Express
* Create our `app` server
* Grab the secure `PORT`from `process.env`
* Set up `app.get` for our root URL ('/')
* Set up `app.listen`
* Start our server that’ll be listening on `port 3000` for connections

💡 This set up below mimics what Express refers to as the “simplest app you can create.” Read more [here](http://expressjs.com/en/starter/hello-world.html).

![app.js file](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872444/echobind_blog/ybktrxnh8huamrpkobm8.png)

Express server configuration

**Save** the `app.js` file. Now let’s **fire up our server and test our connection!**

**Run** `yarn dev` in the terminal.

💡 If you’re using VS Code, you can type **control + \`** on your keyboard to open the terminal and run the command from there.

![app.js file with terminal running code](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872446/echobind_blog/nzhxiyrunabw4uyiracs.png)

Node server running / listening from within the VS Code terminal

Mission control, **we have liftoff** 🚀 — everything is working as expected! Our app is listening 👂🏼 for connections at [http://localhost:3000](http://localhost:3000/). If you follow that link and open a new webpage, you should see the _‘_**Hello World!**’ message.

![Hello World on browser](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872444/echobind_blog/l42zoaylo3cx8ycrd7a1.png)

### Install Remaining Dependencies

Let’s **install our remaining project dependencies** and transition to Sequelize and Postgres.

💡 To kill your server’s connection and input commands again, open the terminal the server is running on and press **control + c** on your keyboard.

**Install Postgres** — our database of choice — and **Sequelize**

`yarn add pg pg-hstore --save` // Installs Postgres`yarn add sequelize --save` // Installs Sequelize

**Install Sequelize CLI** for command-line interface migrations and project bootstrapping.

```javascript
yarn add sequelize-cli -D
```

🥳 **_Celebrate, you’re halfway there_!** Here’s how your dependencies should look at this step:

```javascript
"dependencies": {
    "dotenv": "^8.2.0",
    "express": "^4.17.1",
    "pg": "^8.3.2",
    "pg-hstore": "^2.3.3",
    "sequelize": "^6.3.4"
  },
  "devDependencies": {
    "nodemon": "^2.0.4",
    "sequelize-cli": "^6.2.0"
  }
```

## Sequelize Project bootstrapping:

With our app configured, and the necessary dependencies installed, we can **create an empty Sequelize project**. To do so, execute the `init` command:

```javascript
yarn sequelize-cli init
```

This will automatically create the following folders within your root directory:

* **config** — contains config file, which tells CLI how to connect with database
* **migrations** — contains all migration files
* **models** — contains all models for your project
* **seeders** — contains all seed files

![List of files](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872447/echobind_blog/bqzz2ag1ga660vm3wkrs.png)

Now that we have a new Sequelize project created, let’s get it configured correctly.

## Sequelize Configuration:

We need to **_tell Sequelize CLI how to connect to the database_**. To make that happen, open the default config file `config/config.json`.**Rename the file** to `config.js` **Add the** `dotenv` **requirement** to the top of the file, and **destructure** your `.env--` _variable names_ from `process.env`:

```javascript
// config.js
require('dotenv').config();
const { DB_HOST, DB_USERNAME, DB_PASSWORD } = process.env;
```

![config.js file](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872445/echobind_blog/omoo38zfydvo5m3evuah.png)

**Replace** the `username`, `password`, and `host` values for each testing environment — **development, test, and production** — _using the variable names_ you destructured from `process.env`. Also, be sure to **update the** `dialect` from `mysql` to `postgres`.

```javascript
{
development: {
	username: DB_USERNAME,
	password: DB_PASSWORD,
	database: "database_development",
	host: DB_HOST,
	dialect: "postgres",
}
// Update all 3 testing environments, not just development
```

🤹🏻‍♂ _Optional step_ — It’s good practice to **rename the databases**, replacing the default names with unique enough titles that will avoid future confusion between your databases. I’ll be using:

* Development: `"sequelize_database_dev"`
* Test: `"sequelize_database_test"`
* Production: `"sequelize_database_prod"`

**Lastly**, set module.exports to equal the object in config.js

💡 _For a production configuration you may need to update with SSL and other config options found_ [_here_](https://sequelize.org/master/class/lib/sequelize.js~Sequelize.html#instance-constructor-constructor)_._

## Create a new database in Postgres

We’ve done all the hard work to properly configure our database, so let’s **give Sequelize the O.K. to create it**.

💡 Sequelize will use the default connection port for Postgres — port 5432\. To specify a different port, add the `"port"` field to `config.js`. Read more [here](https://sequelize.org/master/manual/migrations.html).**First, update package.json** and add in a `db:create` script:`"db:create": "sequelize-cli db:create"`Now we can **run** `yarn db:create` to **create our new database**. OR `npx sequelize-cli db:create` **Success!** We’ve **created a development database** with the name `sequelize_database_dev`.

![bash terminal](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872445/echobind_blog/f2ssevhbgbrspds3b4qs.png)

## Creating the first Model & Migration

To actually get **data into our database**, let’s **create a model** (table) for our database named `User`, and provide a few **attributes** (columns) — `firstName`, `lastName`, `email`.

In your terminal, run the following command:

```bash
yarn sequelize-cli model:generate --name User --attributes firstName:string,lastName:string,email:string
```

Or:

```bash
npx sequelize-cli model:generate --name User --attributes firstName:string,lastName:string,email:string
```

![bash terminal](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872445/echobind_blog/hzvunsoffdo2kexv3u1m.png)

Confirmation that a new model and migration were created

The `model:generate` command will _automatically create_:

1\. A `user.js` model file in the models folder.

💡 Models = Sequelize (App specific). Treat models as the representation of the table you want to create or update.

2\. A _migration file_ with name like `XXXXXXXXXXXXXX-create-user.js` in the migrations folder.

💡 Migrations = Postgres (Database specific). Treat migrations like a log of changes in the database.

## Running (data) Migrations

Up until this point, we actually haven’t inserted any data into the database 😳. We’ve only created the _required model_ and _migration files_ for our `User` model (table). To actually create the `User` table in your database you need to run `db:migrate`.

First, let’s update `package.json` and add in a `db:migrate` & `-->db:g:migration-->` script:

`"db:migrate": "sequelize-cli db:migrate"`,

`"db:g:migration": "sequelize-cli migration:generate --name"`

Now we can run `yarn db:migrate` and send over our `Users` model to Postgres. (Or `npx sequelize-cli db:migrate`)

![bash terminal](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872444/echobind_blog/gkbqlnjbc7kz20bdmyn2.png)

If everything went smooth, we can finally view our empty Sequelize model (`Users` table) within the Postgres database. I’m using [Postico](https://eggerapps.at/postico/) below to view the `Users` table.

![Postico displaying database tables](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872445/echobind_blog/olxpne19ozkuk8pykbgt.png)

![Users table](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872446/echobind_blog/ayywlvifhyaaegfykmu9.png)

Viewing empty Users table using Postico

## Creating Seeds

Let’s insert some mock data into our `Users` table by _creating a few sample users_.

💡 Seed files are used to populate database tables with sample data, so let’s create a seed file that will allow us to add a few sample users to the `Users` table.

Again, update `package.json` and add in the `db:g:seed` & `db:seeds` scripts:

`"db:g:seed": "sequelize-cli seed:generate --name"`

`"db:seeds": "sequelize-cli db:seed:all"`

Next, run the `yarn db:g:seed` command, adding in the desired name of the seed file:

`yarn db:g:seed sample-users`

Or `npx sequelize-cli seed:generate --name sample-users`

This command will create a seed file in the seeders folder. It's file name will look something like `XXXXXXXXXXXXXX-sample-users.js`.

Now we have to edit the `XXXXXXXXXXXXXX-sample-users.js` seed file so that it has a few sample users to insert into the table. Reference the image below to see how to format the up and down functions.

💡 The `up()` and `down()` functions are included in every migration file, allowing us to define our desired database changes. The `up()` function defines the new change, and the `down()` function defines how to undo the change — if needed.

![User seed file](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872446/echobind_blog/su2l73gbstdqeikn6rvw.png)

## Running Seeds

In the previous step _you’ve only created a seed file_, we still need to transfer the users to the database. To do that run the command `yarn db:seeds` (Or `npx sequelize-cli db:seed:all`)

**Boooom** 💣💥 ….. **We’ve got some legendary users in our database!!**

![Postico displaying user data](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872444/echobind_blog/uofv5wyxo0cq0q8wcfgi.png)

Viewing seed users with Postico

## Updating your original model

After all this work, you might realize you need to update your original database structure — let’s say you need to add a new column for `password` on the `Users` table.

To accomplish this, you’ll need to create a new migration file using the CLI by running:

```bash
yarn db:g:migration addPassword
```

Or:

```bash
npx sequelize-cli migration:generate --name addPassword
```

Now that you have a new migration file `XXXXXXXXXXXXXX-addPassword.js` — located inside the migrations folder — you’ll need to update it to define how you want the database to change.

The same `up()` and `down()` functions we used to seed are included in this migration file. Remember, the `up()` function defines the new change, and the `down()` function defines how to undo the change.

```javascript
 module.exports = {
	up: async (queryInterface, Sequelize) => {
	await queryInterface.addColumn(
	"Users",
	"password",
	{
	  type: Sequelize.DataTypes.STRING
	}
     );
	},

	down: async (queryInterface, Sequelize) => {
	await queryInterface.removeColumn("Users", "password");
	}
}; 
```

Once you’re finished updating your migration file, you should **migrate the database again**.

Run `yarn db:migrate`

You’ll also need to update your `user.js` file in the models folder, adding in the new column name `password` and it’s corresponding data type to the `User.init` object (see below).

![User.js file](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872445/echobind_blog/peunzlvu2lsivnj1r5ao.png)

Adding the password column to user.js

## Cheers 🍻

If you rode the wave 🌊🏄🏻‍♂️ to this point, then you’ve certainly expanded your developer toolkit! Take a moment and **_let all this settle in_**, we’ve covered a lot of information.

You’ve created a functional RESTful API using Node.js and Express, which can transmit data to a Postgres database by utilizing Sequelize to translate JavaScript into equatable SQL commands.

From here, maybe you create more tables to really see how relational DB’s work, or build out pages that have forms gathering or verifying data. Imagine a form for creating a new account and another for logging in, that way you’ll be able to test the two-way process of storing and accessing data.

I wrote this guide to be verbose, because I struggled to locate documentation that put all the pieces together in a way I understood. My hope is that this guide benefits both newcomers and Sr. engineers. We all learn and grow uniquely from the wisdom our teachers & mentors provide. What’s important is that we continue ‘forever learning’.

---

[View on echobind.com](https://echobind.com/post/a-guide-for-restful-apis-with-node-sequelize-postgres)

---

# Destructuring: Arrays & Objects

> Destructuring assignment, introduced in ES6 JavaScript, is used to more easily assign values taken directly from an object or an array.

_By Mickey Martinez · 2020-07-28_

A special JavaScript syntax introduced in ES6 is the **Destructuring assignment**, which gives us the ability to DO MORE by doing less. Destructuring is used to more easily assign values taken directly from an object or an array.

Let’s start by taking a look at an example of an object and the process required to extract its values prior to ES6:

```javascript
var obj = {first: ‘Rick’, last: ‘Sanchez’, age: 70};
var first = obj.first;
var last = obj.last;
```

Destructuring saves us from repeating ourselves like above — eliminating the need to create two separate variables to extract the `first` and `last` values from the object using dot notation.

By using ES6 destructuring syntax we can create an equivalent assignment statement:

```javascript
const { first, last } = obj;
// first = 'Rick', last = ‘Sanchez’
```

Above, the `first` and `last` variables will be created on the left hand side, and then assigned to the corresponding values from the `obj` object.

This is where destructuring has really provided significant impact — It lets you extract multiple properties from an object, which wasn’t possible to do all at once prior to ES6. In practice, destructuring will also help significantly reduce the amount of code you write.

So you might be thinking, “that all seems pretty easy.” While true, the challenge with destructuring is that there’s so many different ways of going about doing it, and so many combinations of the syntax.

To dive a bit deeper — snorkeling depth — we can look through some key examples of destructuring both arrays and objects. This will help establish a solid foundation for eventually leveraging destructuring to perform list transformations, assigning default values, swapping, ignoring values, nested arrays, and more.

***Destructuring Arrays***

Variable declarations when destructuring:

```javascript
const [first, second] = [true, false];first = true
second = false
```

Assignment:

```javascript
[first, second] = [true, false];
```

With **array destructuring**, you can create new variables using an item in the array as a value. Let’s look at an example of an array with the various parts of a date:

```javascript
const date = ['11', '02', '1982']
// values represent month, day, year
```

Arrays in JavaScript will *always maintain their order*, so in our example above the first index will always be a month, the second will be the day, and third the year. With this in mind, you could create variables from the items in the array using bracket notation:

```javascript
// Process before destructuring was introduced
const month = date[0]
const day = date[1]
const year = date[2]
```

Continuing to manually do this will bloat your code. Cue **array destructing** — where instead we can assign the values from the array in order, all on one line, and immediately assign them to their own variables:

```javascript
// Destructure array values into variables
const [month, day, year] = dateconsole.log(month) // 11
console.log(day) // 02
console.log(year) // 1982
```

You can even *skip/omit values* in the array by using a comma and leaving the syntax blank:

```javascript
// Skips the second item in the array
const [month, , year] = dateconsole.log(month) // 11
console.log(year) // 1982
```

Below is a helpful visual example of what we just covered above. I’ve also included an example of destructuring with the spread operator, and swapping variables without needing to use temp variables — these begin to show how you can really leverage destructuring.

![](https://cms.echobind.com/assets/7f51753b-ce87-4162-84e0-5f8083bc06be)

***Destructuring Objects***

As we first touched on at the start of this post, destructuring is equally as valuable on objects.

You can extract as many or as few values from an object as you need. As a refresher, let’s first look at how we declare variables on the left hand side, and match them to the *properties of the object* on the right hand side.

Variable declarations:

```javascript
// create new variables using an object property as the value
const {first, second} = {first: 0, second: 1};
first = 0
second = 1
```

Assignment:

```javascript
{first, second} = first: 0, second: 1};
```

Now, with a solid understanding of variable assignment, let’s take a look at the first two examples in the image below. These highlight how destructuring allows you to **assign a new variable name** when extracting values, by putting the new name of the variable after a colon `{user: x}`.

In the second example we see a common mistake, where the property name doesn’t match the original on the right, so when we log out the newly declared variable `x`, a value of `undefined` is returned. This issue is resolved in the last example, which illustrates how to properly reassign values when destructuring.

![](https://cms.echobind.com/assets/a4f0c189-d966-41c9-b1db-36743172af06)

***Destructuring Objects & Arrays***

Now let’s observe how we can combine ***both object and array destructuring*** into a single destructuring assignment. *First let’s look an an object* that also has an array of data. We start by declaring the `blog` object.

```javascript
// Declare the blog object
const blog = {
  title: 'My First Space Travel Blog',
  author: {
    firstName: 'Rick',
    lastName: 'Sanchez',
  },
  tags: ['ideas', 'notes', 'inter dimensional travel'],
}
```

Then we destructure as needed:

```javascript
const {
  title,
  author: { firstName, lastName },
  tags: [ideasTag, notesTag, travelTag],
} = blog;console.log(title) // My First Space Travel Blog
```

Now let’s take those same principals, and look at another nested data structure that’s an array of objects. The goal is to destructure this nested data structure into two variables, one variable should have the string `'blue'` and the other `'yellow'`.

```javascript
var friends = [
    {
        name: 'Rick',
        color: 'blue'
    },
    {
        name: "Morty",
        color: 'yellow'
    }
];
```

Remember, without destructuring we’d need to separately assign the values to two variables:

```javascript
// Without destructuring
const firstColor = friends[0].color;
const secondColor = friends[1].color;
```

With destructuring, we can do the same variable assignment two different ways:

```javascript
let [ color1, color2 ] = [friends[0].color, friends[1].color];
 // OR
let [{ color: firstColor }, { color: secondColor }] = friends;
// Assigning blue to firstColor and yellow to secondColor.
```

***Use Destructuring to Pass an Object as a Function’s Parameters***

What happens when we have a data structure and leverage destructuring to pass an object as the parameters of a function? At times you can destructure the object in a function argument itself:

```javascript
const profileData = {
 name: 'Morty',
 age: 14,
 nationality: 'American',
 location: 'Dimension C-137',
 email: 'hello@morty.com',
 'last login': 'Tuesday'
};const profileUpdate = (profileData) => {
const { name, age, nationality, location } = profileData;
// do something with the variables 
}
```

This effectively destructures the object sent into the function. This can also be done **in-place**:

```javascript
const profileUpdate = ({ name, age, nationality, location }) => {
// do something with the variables 
}
```

*Destructuring in-place* removes extra lines and further cleans up our code. Additionally, we avoid having to manipulate an entire object inside a function, and can select just the fields that are needed to be copied inside the function.

Hopefully by now you’ve begun to understand how the ES6 destructuring assignment adds desired functionality to JavaScript and produces more succinct code. In practice you’ll gain an appreciation for destructuring, especially when dealing with complex objects or arrays, and you’re able to manipulate their data quickly.

---

[View on echobind.com](https://echobind.com/post/destructuring-arrays-and-objects)

---

# 5 Tips to Zoom Like a Pro

> May 23, 2020 | Lots of folks are using Zoom for the first time. So, we've put together five tips to help you use Zoom like a pro.

_By Josh Buchea · 2020-05-23_

With the current global coronavirus pandemic, companies around the world are shifting to remote work. As a result, lots of folks are using Zoom for the first time. So, I put together five tips to help you use Zoom like a pro.

## 1\. Leave Meetings with a Single Action

I like to remove the confirmation dialog before leaving a meeting, so I can exit a meeting with a single action. Plus, attendees don’t see me look lost as I try to locate and press the “Leave meeting” button in the confirmation dialog. ✌️

**Settings > General > Prompt a confirmation before leaving a meeting**

## 2\. Enhance Your Appearance

The “Touch up my appearance” feature in Zoom is really good. I use it to “soften” my video and help hide skin blemishes.😍

**Settings > Video > My Video > Touch up my appearance**

## 3\. Join Meetings with Video Disabled

Some meetings don’t require video and sometimes I’m scrambling to prepare, so I like to join meetings with my video disabled and manually turn it on after I’ve joined and I know I’m prepared. 👨‍💻

**Settings > Video > Meetings > Turn off my video when joining a meeting**

## 4\. Join Meetings with Audio Disabled

For most meetings, I try to stay muted when I’m not actively speaking. This helps reduce unnecessary distractions and interruptions during the call. No one wants to listen to your typing, heavy breathing, children screaming, or that leaf blower outside. 🙉

For all of the reasons I just listed, I like to join meetings with my microphone muted.

**Settings > Audio > Mute microphone when joining a meeting**

## 5\. Virtual Backgrounds

If you have a computer with enough horsepower, you can use the Virtual Background feature in Zoom. Virtual backgrounds are great at hiding a messy workspace. They’re also a great way to have some fun! 🤪

**Settings > Virtual Background > Choose a virtual background**

![Me, with the living room from The Simpsons as a backdrop](https://res.cloudinary.com/echobind/image/upload/v1661872447/echobind_blog/ziwdkbrnfbcchdurjrjp.png)

Me, with the living room from The Simpsons as a backdrop

Here are a few ideas for virtual backgrounds:

* Points of Interest
* Beautiful Scenery
* Backdrops from Shows & Movies
* Nicer Office Spaces
* Solid Colors

I hope these tips help you be more professional on Zoom. Leave a comment if you found them helpful, I’d love to hear from you!

---

[View on echobind.com](https://echobind.com/post/5-tips-to-zoom-like-a-pro)

---

# Next-Level Mobile App Debugging with a Network Proxy

> May 21, 2020 | Working as a mobile app developer comes with a host of unique challenges, one of which is how to debug problems with production app builds.

_By Ryan Atkinson · 2020-05-21_

Working as a mobile app developer comes with a host of unique challenges, one of which is how to debug problems with production app builds. As hard as we work to prevent production-level problems, things will invariably go wrong at some point, and it’s important to have a plan of attack when they do. Today I want to share with you one of the most indispensable tools in my toolbox of mobile development: viewing mobile app network requests via a web proxy.

The gist is that by tethering our mobile device to a local computer, that from this computer we will be able to intercept and view all network requests made by the mobile application. This will help us cover some of the first bases of a production-level app bug: is the app making requests to the correct API environment, and is the API returning the expected payload? Some of the most common issues I see in this type of situation are that either the mobile app was built with the wrong ENV variables, or the target API environment hasn’t been updated with the latest changes from development.

There are two main tools I would recommend for this, [Charles](https://www.charlesproxy.com/) and [Fiddler](https://www.telerik.com/fiddler). I personally use Charles as it is the best option I know of for mac users, and my windows-based colleagues tend to use Fiddler. For this post, I am going to use Charles to show a complete setup; however, the principles will be the same if you wind up using Fiddler.

Here are the general steps to follow to get everything set up:

* Install Charles and open the application.
* Add target API URL to Charles SSL proxy settings.
* Connect the device with mobile app via USB.
* Install and trust Charles root certificate on mobile device.
* Configure manual wi-fi proxy settings on mobile device.
* Accept proxy request in Charles.
* Make request from mobile device and view logs in Charles!

**Install Charles and Open Application.**

This should be as straightforward as downloading the application from the [Charles homepage](https://www.charlesproxy.com/documentation/welcome/)

**Add Target API URL to Charles SSL Proxy Settings.**

By default, you won’t be able to view the details of the requests being intercepted by Charles. We will need to add each specific domain we are interested in inspecting in the SSL Proxy Settings.

Charles > Proxy > SSL Proxying Settings…

![Charles SSL application](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/mplkymzkj1wu4ye43dgj.png)

From this window, add `*.your-domain.com` as the Host, and `443` as the Port. Here I do this for google.com below. The wildcard prefix lets me listen to any env-specific variants that may be using this particular domain.

![Charles SSL application](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/ffinl1fmnjsctcibzuys.png)

Ok! Charles is configured to allow us to view any traffic hitting google.com. (From our computer itself or from a tethered mobile device, i.e. this was not a mobile-specific step.)

**Connect Device with Mobile App via USB.**

Go ahead and plug your mobile phone into your computer via USB. This will work whether you have an iOS or Android device.

**Install and Trust Charles Root Certificate on Mobile Device.**

This is a step you perform once and never have to do again, but the first time you intend to use Charles to proxy mobile network requests you need to first install and “trust” the Charles root certificate.

Navigate to this link and follow the instructions specified for the platform of your mobile device: <https://www.charlesproxy.com/documentation/using-charles/ssl-certificates/>.

**Configure Manual Wi-Fi Proxy Settings on Mobile Device.**

With the Root certificate trusted, we will now configure our mobile proxy.

Get the IP address of your machine. (You can do this on Mac by holding down “option” and clicking the wi-fi connection icon in the system tray.)

![Apple MacBook Pro](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/qrardm7dolavcrxtmges.png)

Now go to the “Wi-Fi Settings” of your mobile device, and select the wireless network that both your mobile device and computer are connected to.

![Apple MacBook Pro Wi-Fi settings](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/ib0i7f8a3trimx4abxfs.png)

On iOS, select “Configure Proxy” under the HTTP PROXY header at the bottom of the screen.

![Apple MacBook Pro Wi-Fi settings](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/ln2jrt4ckwdxmfmikwfn.png)

Choose “Manual” and enter the IP address of your computer that we got earlier, along with 8888 for the Port, and leave the Authentication toggle off. Press Save to exit and apply these settings.

![Apple MacBook Pro Wi-Fi settings](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/h7uz7epjm0v2wbklguj7.png)

**Accept Proxy Request in Charles.**

After adding the manual proxy settings, you will be prompted to allow the connection to the device from within Charles; choose Accept.

**Make Requests from Your Mobile Device and View the Logs in Charles!**

Now any network traffic coming from the apps on your mobile device will be logged in Charles, and you will be able to inspect the requests of any domains you have added to the SSL Proxy settings.

![Charles SSL application](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/feqn9zgppfg6nrhgaiqn.png)

Showing the Twitter API calls while viewing Twitter in my mobile browser.

Boom! Now we can reliably access network request logs from any mobile app we are running. If you aren’t sure of what domains to inspect, just proxy without any domains configured in the SSL Proxy settings, grab the domains that look relevant from Charles, and then add them and restart the app.

With our proxy in place, we are able to quickly verify that our production app builds are making the requests to the correct environments and that API payloads and user credentials, etc. are all functioning as expected.

Some extra notes:

* Although I used an iPhone, you can do the same thing with an Android device. You can access the proxy settings for a particular wi-fi connection on an Android device by “long-pressing” the connection in the wi-fi settings. Adding the IP address as the server and using port 8888 will work the same.
* Using port 443 for the SSL Proxy and 888 on the device proxy are defaults that should work without any additional configuration. If you have custom settings on your machine or network, you may need to modify these accordingly.
* Please use this tool responsibly and never for any malicious purposes!
* **Don’t forget to turn the proxy back OFF in your mobile phone settings after you’re done, otherwise, you aren’t going to be able to connect to wi-fi!**

Let us know if you want to [chat about how Echobind can help](https://echobind.com/contact) with your mobile development or [react native development](https://echobind.com/capabilities/react-native-app-development).

---

[View on echobind.com](https://echobind.com/post/next-level-mobile-app-debugging-with-a-network-proxy)

---

# Leveling Up

> May 19, 2020 | Digging deeper is the concept of being comfortable understanding what you use and how you use it. Let’s get to it.

_By Alvin Crespo · 2020-05-19_

## Leveling Up

There are a lot of good articles out there on how to level up your software engineering career. I’m going to focus on one: digging deeper. Digging deeper is the concept of being comfortable understanding what you use and how you use it. Let’s get to it.

### 1 Player Game

When I first started, I had no clue what I was doing. My method of doing anything, especially in the early days of web development, was to just piece things together. Some HTML here, add a little bit of CSS ([Blueprint](http://blueprintcss.org/) anyone?) to make it look good and a sprinkle of [jQuery](https://jquery.com/). I’d download assets, add it to the project and then FTP it — done!

I didn’t dig into any of those libraries. This was my method:

* Read some blog post
* Integrate recommendations
* Ship the project
* Make cash 💰💰💰

This wasn’t sustainable.

### 2 Player Game

I feel sorry for the people who had to maintain code from my early days. Who knows, perhaps they still are. It’s a spaghetti mess. I eventually learned to clean up my act and my code! Once I got out of freelancing and had opportunities to join formal engineering teams — I understood that it was necessary to think through solutions.
‍
I thought about maintenance, scaling, and code styling. This was my method:

* Read some blog post
* Discuss solutions with the team
* Integrate recommendations
* Ship the project
* Make 💰💰💰

That’s where I plateaued.

### Grand Prix

When I was working in [Ember](https://emberjs.com/) and working closely with folks on the core team, I was introduced to a novel concept: debugging internals. We would put a debugger and just step through the whole stack. I had never done this before! I thought it was crazy! I also thought it was the coolest thing in the world!

During that time — I found that the tools I was using were developed by other humans! Humans who had an idea and just wrote the code for it. Some of it was great, some of it was terrible.

Over the course of a year or so — I had developed some core knowledge about Ember that helped me:

1. Develop features faster
2. Communicate more effectively with teammates
3. Contribute to OSS (to overcome roadblocks)

This was my method:

* Read some blog post
* Discuss solutions with the team
* Integrate recommendations
* Learn about my tools
* Knowledge share
* Ship the project
* Make 💰💰💰 (this increased significantly)

How do **you** get here?

## Let’s-a Go!

Don’t wait to get to this step! Start today!

I’m going to showcase an example. For this example, I’m going to dive into Apollo’s `useQuery` hook. I haven't used Apollo for almost six to seven months now, and I haven't dug into `apollo-client` before, so this is my first time.

Alright, let’s start here:

```javascript
const { loading, error, data } = useQuery(GET_DOGS);
```

Let’s say that for whatever reason my loading state isn’t working. I don’t know why my query works and the graphql playground is working as expected. I’ve looked at the docs several times and I’m stumped. What can I do? I can add a debugger at this line and step into what’s happening — that’s a great option.

I could also dive into the source code. This is what I’m going to do because I need to know whats going on to figure out what’s up. Keep in mind, I’ve never done this before this article.

Here’s what I do:

Let’s start by going to the repo:

![GitHub repository](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/vlnuimsctthpls68o9y8.png)

I’m going to search for `useQuery`, and luckily my second result is the test for this hook. I can look at the test, but I'm going to dive deeper.

![GitHub repository](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/hxxdrj3bdqmt6uopfmri.png)

The test tells me where `useQuery` exists, so I'm going to go up one directory and check it out.

![GitHub repository](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/dzi3eixshkmhszabxsfy.png)

Ok cool, there it is — let’s click into `useQuery.ts`

![GitHub repository](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/otcbnxp8sccdbtehsi7u.png)

Alright! We’re looking at source code…but… there’s nothing here — what do I do?

![Code on a GitHub repository](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/fdyh38jhyce5muqgbcny.png)

It looks like it’s using something called `useBaseQuery`, the import above shows it's in a utils directory - let's go to it.

![Code on a GitHub repository](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/d1doshujvrebl00gpqwh.png)

Ok, we’ve found the file — let’s open it.

![GitHub repository](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/ekv3xclllkqd4j8shl5x.png)

Ok. I’m digging through the file and I see something called `queryResult.loading`. I don't know what `queryResult` is so, let's see what it is...

![Code on a GitHub repository](https://res.cloudinary.com/echobind/image/upload/v1661872447/echobind_blog/tavdtslmlbh0fyxdw78d.png)

Ok, looks like it depends on if `lazy` is true or false. Since we didn't specify anything `lazy` about our hook as an option, I'm assuming it is the second one where we typecast it as `QueryResult`.

![Code on a GitHub repository](https://res.cloudinary.com/echobind/image/upload/v1661872447/echobind_blog/vtaexedqlkrkcehtvbll.png)

This is the line, I’m assuming we hit:

![Code on a GitHub repository](https://res.cloudinary.com/echobind/image/upload/v1661872447/echobind_blog/age8gfwiujdq0mjf6iga.png)

Regardless, whats `result`? Ah, ok it's above.

![Code on a GitHub repository](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/rnzzbioyttofgewas7nt.png)

Ok so within this other hook is a call to `executeLazy` or just `execute`.

![Code on a GitHub repository](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/wuzhwvlaqtubcakdxzoo.png)

I’m going to assume where calling `queryData.execute` because I didn't specify `lazy`. But, what's `queryData`?

![Code on a GitHub repository](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/qmivar6gv6rhjqcpvxy7.png)

Looking further above, it looks like it gets set to some current thing or a new thing. The new thing is an instance of `QueryData`. So, knowing what we know so far `execute` is a method on an instance of `QueryData`.

Nothing significant about `loading` here - it looks to be contained within this `QueryData` type. So let's dig deeper.

![Code on a GitHub repository](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/phzegjoyfqfjsqcqxrtx.png)

Looks like `QueryData` is being imported by two levels above. Let's go to it.

![Code on a GitHub repository](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/frqdl0n3pqq7kigzclyo.png)

Found it! Let’s go into the data directory:

![A GitHub repository](https://res.cloudinary.com/echobind/image/upload/v1661872447/echobind_blog/jc3n3hfrwimuhmogvovv.png)

Once here, we’ve found `QueryData.ts` \- let's click it.

![A GitHub repository](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/ys8cvvxnoetrhtinvfyz.png)

Alright, we’ve found the `QueryData` class! Let's investigate for `execute`

![Code on a GitHub repository](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/bpxt7gtfq6rwtuqnmzhw.png)

Found it! Let’s see what it does:

![Code on a GitHub repository](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/gfqci1ammvls45jgbjk1.png)

Ok, it seems to make a call to `getExecuteSsrResult` or `getExecuteResult`. Since we're not doing anything SSR related, I'm going to expect `getExecuteResult` is what gets called. Let's see what that does.

![Code on a GitHub repository](https://res.cloudinary.com/echobind/image/upload/v1661872447/echobind_blog/gtzef8fowxgveocfgimc.png)

There it is!

![Code on a GitHub repository](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/ttjtnglnwefbnsh68mxr.png)

This function seems to call `getQueryResult` \- ok, that definitely seems relevant! Let's see what it does.

![Code on a GitHub repository](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/ijvktsjmkirzllsl9cfx.png)

And boom! We’ve found where all the magic happens. This is the function that returns the result we’ve been looking for. Here, we’ll find `loading`, `error`, and `data`.

![Code on a GitHub repository](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/ihklyzhxqmpgbj7zmdn9.png)

### Fín

A very important step in your career is the ability to dive into the tools you use. Doing this is a crucial step in giving you the freedom you need to build software the way you want. With this in mind, go on and triumph!

---

[View on echobind.com](https://echobind.com/post/leveling-up)

---

# COVID-Q: Technology Overview

> May 12, 2020 | A secure, easy-to-manage queue system for drive-up COVID-19 testing.

_By Chris Ball · 2020-05-12_

## A Secure, Easy-to-manage Queue System for Drive-up COVID-19 Testing

This is part two of our COVID-Q overview. COVID-Q is an app we built to help manage a queue system for drive-up testing for COVID-19\. If you’re interested in why we built the solution, see [part 1](https://medium.com/@cball/covid-q-an-app-to-help-manage-drive-up-testing-queues-5c7381022fd2).

## The Technology

As an agency, we often spike out technical solutions with internal projects to prove them out before recommending on client projects. This project was an opportunity to put a few things through the paces and evaluate them for future use with our clients.

For this project, we used some of our favorites along with some new tools.  
Some of our favorites include:

* [**Next.js**](https://nextjs.org/) for the landing page and the application. The landing page is fully static and leverages Next.js [API Routes](https://nextjs.org/docs/api-routes/introduction) to process the contact form. The app is a mix of static and dynamic content.
* [**Chakra UI**](https://chakra-ui.com/)for styling and base components. We’ve leveraged Chakra on quite a few projects now, and it has increased our speed and productivity developing responsive UI components and pages.
* Hosting on [**Zeit Now**](https://zeit.co/). Now comes with numerous benefits out of the box including deploy URLs for Pull Requests, a global CDN, and a Serverless architecture.

**Tools we are Evaluating**

[**Sanity.io**](https://www.sanity.io/)

A CMS and basic admin area provided by [**Sanity.io**](https://www.sanity.io/). The site re-deploys to Now via a webhook when editors publish content. We also like [**DatoCMS**](https://www.datocms.com/) but Sanity is a bit more configurable and flexible. Sanity can also be self-hosted, and this was a good opportunity to put it through the paces.

[**Prisma 2**](https://www.prisma.io/)

We were less than impressed with Prisma 1\. In fact, it caused a lot of issues on the project we used it on. That said, Prisma 2 is much more focused and has proven really promising. We encountered a few small issues with migrations, but the overall setup works well. We will continue to evaluate Prisma 2.

[**Urql**](https://formidable.com/open-source/urql/)

We use [Apollo Server ](https://www.apollographql.com/docs/apollo-server/)on most client applications. We tested out Urql on this project but did not find any benefits over Apollo. We likely won’t use it in the future. For simple GraphQL calls in scripts or times where a full-fledged client provides little benefit, we prefer [graphql-request](https://github.com/prisma-labs/graphql-request).

[**Now deploy buttons**](https://zeit.co/docs/v2/more/deploy-button)

Now deploy buttons allow for a one-click clone from GitHub and instant deployment. We are using this to help spin up new COVID-Q sites for interested companies quickly.

## Technical Questions and Answers

**Why use both a CMS and a database on this project? Couldn’t you just store all of the content in the CMS?**

We absolutely could. We chose not to do this for two reasons. First, using a separate database helps us with better HIPAA compliance should we need it. Storing patient data within a CMS like Sanity is less secure since we don’t have control over how the data is accessed. We’re not actually storing any Patient Health Information (PHI) in this app, but we wanted the flexibility should we need to start doing so in the future.

To keep the admin section of the site easy to use, we call our main API to fetch data for things like appointments and tokens.

**Isn’t GraphQL overkill for this type of project?**

GraphQL is definitely not necessary for the size of the API we’re working with. We decided to keep everything in GraphQL for a few reasons:

* It allowed us to test out [GraphQL Nexus](https://github.com/graphql-nexus/schema), which we’ve been meaning to evaluate.
* The CMS API and Prisma API were already GraphQL, so we wanted to avoid introducing another way of fetching data to the application.

**Why use a Serverless infrastructure?**

First, it keeps costs low. Second, the infrastructure will automatically scale to meet demand should it need to. Because we were providing a service to others, we wanted it to be maintenance-free.

The most important part of this app is certainly not the technology behind it. That said, we hope to help other development teams by sharing our insights as we’re evaluating new technologies for internal projects and client apps.

---

[View on echobind.com](https://echobind.com/post/covid-q-technology-overview)

---

# Not Just a Code Monkey

> May 11, 2020 | Do not underestimate how valuable your experiences as a developer are, and how you can use them to influence the solutions you deliver.

_By Jenn Robison · 2020-05-11_

As a developer there are many roles we can take on through a project and through our careers. First and foremost it would appear that our job is to write code and do as we are asked to deliver a product, or solve a problem. Do not underestimate how valuable your experiences as a developer are, and how you can use them to influence the solutions you deliver. Don’t settle into that comfort zone, find how to add even more value.

Recently in a retrospective with a client, our project stakeholder made a statement to his peer that they needed to be more mindful when working with project teams to ensure that they weren’t working with teams that were just doing as they were asked. He then went on to elaborate that Echobind was providing value by “challenging client requests”, and it was greatly appreciated. In our Sprint Planning and Grooming meetings, we are often asking questions to understand what problem we are trying to solve as well as talk through the potential pitfalls or options we have to solve the problem based on our experiences. When we do this, we are ensuring that our client is getting our best, and the end-user will have the best user experience possible.

Sometimes this can feel like we are walking a fine line, especially as an agency. You obviously do not want to offend your client and personalities can be challenging. Finding what works for each project takes some time. You do not come HOT right out of the gate, you build rapport and mutual respect; with this, they will value your questions and understand that your questions or comments come from a place of good intention.

When you think of your role as more than _just_ a “coder” you not only help bring the most value to the project but you help your future self too. If we blindly do exactly what we are being asked, knowing it isn’t the best solution or that it will have a domino effect of other issues; then we will end up having to fix those later. It may seem counterintuitive that as an agency we would not want to let the client create “more work”. However, you win more business by doing your best work, and not by creating extra work that could have been avoided.

I’ll share with you a story of the value you can bring when you ask the right questions, and keep asking until you get the answers. Several years ago now, I was working on a very complex project that had very complex statistical algorithms as well as data from several sources. One of my business partners asked for a “data dump” to Excel. My first question was “Why?”. When I wasn’t getting a clear answer I then asked, “When you get this data in Excel what will you do with it? There are hundreds of thousands of lines of information here, that seems like a lot to wade through.”. The response I received was that they had a plan to write advanced formulas and some macros that would scan the data and let them know when certain criteria were met that meant a transaction should be investigated further. This would have been a very manual process and would take this person quite a bit of time to set up initially and then complete on a regular cadence. I then learned that others would need to have similar processes which meant there was room for discrepancies in how each person might be calculating these flagged transactions. After this discussion, I suggested that we allow the computer to process all these transactions each time we loaded the data, use the business rules defined to flag the appropriate items, and then alert the owner that there were a select number of items that needed their attention. This allowed them to have a repeatable process and only look at the items that required attention instead of thousands and thousands of items that did not require attention. In the end, we saved them several hours of work each week.

One last comment, just for a reality check. Just because we have these conversations doesn’t mean we always go down the suggested path either. There are of course tradeoffs. It may be necessary to make the choice to do the unfavorable task now in order to get past a hurdle or deadline, but by having the conversation all parties are aware of the risks involved or the tradeoffs being made and plans can be put in place to mitigate or address them when the time is available.

Now I challenge all of my fellow devs to raise your hand, ask the questions, provide feedback to your stakeholders. In addition, I challenge all the stakeholders out there to look for those that don’t just do what you ask but have a constructive conversation about the problem you are trying to solve so that they can deliver the best possible solution.

Cheers to being more than a code monkey! 🐵

---

[View on echobind.com](https://echobind.com/post/not-just-a-code-monkey)

---

# Clubhouse: Tips and Tricks

> Apr 30, 2020 | Here at Echobind, we use Clubhouse for our ticket tracking software. Learn the finer points of project management using Clubhouse.

_By Isaac Myman · 2020-04-30_

Here at Echobind, we use [Clubhouse](https://clubhouse.io/) for our ticket tracking software. Having come from either a Jira or VSTS environment Clubhouse was a whole new world for me. Instead of the normal questions of “_why won’t this ticket show up for this person?_” or “_what permission do they need to have again_?” I am saying things like “_wow this is simple_.” and “_I can have that report ready in five minutes_”.

Even though Clubhouse was so much easier than other things I have used before, it still had a learning curve. Through poking around I have learned a few things about how to really get the most out of Clubhouse. Here are six tips to really use the tool to its max.

## 1\. One Workspace — Many Projects

Something I love about clubhouse is being able to see all the work for multiple projects in the same place. With Clubhouse, projects within the same workspace are shown together allowing me to get an overall picture of the status of all work, rather than just a single project.

As an Account Strategist, it is helpful to see the big picture of the projects in progress. This provides me the opportunity to adjust which projects people are allocated to and ensure we are staying on top of what we are doing.

## 2\. Using Spaces for Organization

![Clubhouse spaces section](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/iovel1wxbwysrmnhkeur.png)

Since every project is in the same place, the board can become very messy and overwhelming. This is where spaces come into play. Clubhouse offers a feature that allows users to create “_spaces_” which have saved filters to see a specific set of stories from all projects. I can save these spaces as private or share them with the team. I use these to create views of the work that make more sense for each of the team members. A developer on project A probably doesn’t want to see the stories that are still in the backlog for that project let alone all of the stories from all the other projects.

Using spaces allows me to slim down a board and make it specific to the task at hand. Being able to save them allows me to quickly see the progress of a project at a more specific level and for a specific phase.

## 3\. Projects, Milestones, Epics, Iterations, Stories

Clubhouse has a lot of ways to breakdown work into smaller chunks and exactly how to use these groupings should come down to the current process the team is working on. I will use the way Echobind uses these features to give a good example of one way these can be used.

![Clubhouse side bar with icons](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/fvmou3vr5xy9xcsvttln.png)

We start with Projects and Milestones. We create the project we need, for example, Product MVP. Another way to use projects is by functional team, for example, backend, frontend, design, etc.. Then we add all of the milestones for that workspace. These milestones can be used for many different projects or just one. For example, we will use them in the use case where they are for just one project. This could be Beta 1, Beta 2, Release Candidate, Final Submission.

Then we add epics. The epics will be a specific set of stories that encompass some part of the application which will be completed in a specific Milestone. Epics can span across different projects which is nice if you are using projects to describe functional teams specific to one project. Once the Epics are created you add them to milestones. For example, for the Beta 1 milestone, I might add the Epic for login/account creation, adding to cart, and checkout. By setting it up this way I will finish these epics within this milestone which has a finite date to be completed. Next, I will add stories to those epics breaking them down further into the smallest testable functional requirements I can.

And finally, I create Iterations. These will be 1–4-week sprints which I can use to map out how much work we need to commit to for each of those cycles to complete everything by the end of the milestone.

## 4\. Reporting

![Clubhouse reporting graph](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/tvkfggctaaecx7jujn5y.png)

Source: Clubhouse

All of these levels of groupings of work are only great if they have a point. That point comes in the form of easy to use reports that can be seen at each of the different levels. If you have been estimating your user stories — as you should be — then you are able to see a burndown chart, velocity chart, and lead time all from the milestone dashboard. These reports are incredibly valuable for understanding the overall progress of the project and what can realistically be done. I will use these reports to make further estimates to clients and to make decisions on cutting scope should a decision need to be made.

For anyone hoping to stay within the budget and also make the deadline, the reporting tools in Clubhouse are powerful resources for hitting those goals.

## 5\. Searching and Filtering

The search tool in Clubhouse is powerful for finding stories that meet specific criteria. It uses a syntax that allows the user to say something like “_is:unestimated_” and displays all the unestimated stories so I know what needs to be completed to get a final report of the progress we are making.

## 6\. Story Templates

Something we love to use at Echobind is the story templates. These are super simple to set up. You just begin creating a story as you normally would with all the parameters you want and then you click the dropdown arrow on C_reate Story_ and select create template instead.

![Clubhouse story template](https://res.cloudinary.com/echobind/image/upload/v1661872447/echobind_blog/hco1brzke6cup6nh0md9.gif)

Source: Clubhouse

Story templates have proven to be invaluable to us. We frequently have clients or other members of the team entering feature requests and bugs that without the template could end up in an unusable format. The templates help us keep everyone writing useful requirements and bug tickets and saves a lot of clean up time later.

Overall, Clubhouse is a powerful tool for managing projects. While it is simpler than many other applications in the same category it still will require a slight learning curve. Once the lessons have been learned and the full experience is unlocked Clubhouse becomes a delightful tool to use.

---

[View on echobind.com](https://echobind.com/post/clubhouse-tips-and-tricks)

---

# Hyper Focused → Hyper Productive

> Apr 28, 2020 | We are slowly recognizing that passion can only carry you so far and what we all thought was important, just isn’t these days.

_By Matt Thompson · 2020-04-28_

Over the past couple of weeks, I’ve been ramping up on Rails and read multiple articles pertaining to Elixir, Phoenix 1.5, and LiveView. I was excited, passionate, renewed even. Ready to dive into a new build and write a series of content. Except for some reason I couldn’t do it. While I tried, I found myself in a new state of burnout. The passion I had for the topic just could not overturn the fact that I was exhausted and tired of staring at a screen. While I will eventually \*\*dive into Phoenix 1.5 and write a short series, today I wanted to address the other.

It may be the ADHD brain stuck in quarantine, but lately, I’ve noticed I can adventure from _SUPER EXCITED_ about a topic to this rare new form of burnout. I’ve been working remotely for years now and this is the first time I am truly struggling. It’s more than exhaustion this time, my passion for the subject suddenly dies, and I’m not alone. Managers, Co-workers, and colleagues are all finding themselves in a funk. We are all on edge, trying to be our best in an environment that is less than ideal. We are slowly recognizing that passion can only carry you so far and what we all thought was important, just isn’t these days.

> _Let’s be clear, the ability to hyper-focus on a task is NOT a bad thing. The issue here is that ALL tasks are hit with this same intensity._

Work is one part of my day, in some manner, I control. I used to start my day knowing the only distraction was going to be my stomach telling me it was time for lunch. I was focused, but not in the same way I am now. Now, I’m not sure what or when the next distraction will be. Tasks are all started with this hyper-focused intensity. _Let’s be clear, the ability to hyper-focus on a task is_ **_NOT_** _a bad thing. The issue here is that_ **_ALL_** _tasks are hit with this same intensity._ I may not be able to find toilet paper… but that question on slack, that Twitter thread, that PR, it was responded to, promptly. Even better, those 15-minute meetings, they now last at least an hour because we all are missing some form of human interaction.

We are all overcompensating in this new quarantine state and it’s exhausting. We try to take control of something, anything to feel human. Our routines were disrupted, and we are on a mission to regain control. At war, with this “new normal” trying to feel some sense of peace. For a lot of us, this is amplified by financial stress. You’ve either lost your job, know someone, or are in fear of the unknown. Tack on the new distractions as your partner, kids, pets are just always… there. It’s a disaster. A quote from my introvert wife sums it up: “Do you mind, I can hear you breathing!”

![Character from The Office show rolling his eyes gif](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/whnrg0rsa1cztd3dtoro.gif)

> _The beauty of remote work is that it can be, and should be asynchronous._

The beauty of remote work is that it can be, and should be asynchronous. \*\*\*\*_Do I need to respond to that message?_ **Yes**. \*Do I need to finish that task? \* **Yes**. _Can I realize I’ve been sitting in this same spot in my house for days and should take a walk first?_ **YES!** For some unknown reason, it’s like all the common sense habits of remote life were lost on me the second a global pandemic happened. If you are like me and just forgot how to function, here are some tips and reminders:

* Give yourself multiple tasks for the day.  
This will encourage you and your brain to shift gears.
* Write your tasks down and check them off.  
This will make you feel like you accomplished something by the end of the day.
* Set some timers!  
If you are stubborn like me, set some reminders to switch gears, eat, and MOVE!  
/remind me everyday at 10am to walk  
/remind me everyday at 10:10 am -- No really get off your...
* GO OUTSIDE!
* Distractions. Embrace them!  
Play with the kid, have a hobby, watch that 20-minute episode, collect those turnips… Just make sure to remain disciplined and get the job done. Your brain actually enjoys the chaos and breaks.
* Asynchronous communication!  
While distractions are great you don’t need to stare at Slack, Gmail, and your phone for 10 hours a day… you just don’t.

## Conclusion

To my knowledge, the singularity has yet to be perfected. None of us are fully functional robots… yet. Humans are not meant to stay hyper-focused on a task 24/7\. We are meant to adapt and survive. Keep the hyper-focused moments contained in the small bursts of energy they were intended for. It’s a tool in the belt, not a lifestyle. To truly be productive, introduce change, take a deep breath, and embrace chaos.

> _Don’t get set into one form, adapt it and build your own, and let it grow, be like water. Empty your mind, be formless, shapeless — like water. Now you put water in a cup, it becomes the cup; You put water into a bottle it becomes the bottle; You put it in a teapot it becomes the teapot. Now water can flow or it can crash. Be water, my friend.” \~_ [_Bruce Lee: A Warrior’s Journey_](https://en.wikipedia.org/wiki/Bruce%5FLee:%5FA%5FWarrior%27s%5FJourney)

---

[View on echobind.com](https://echobind.com/post/hyper-focused-hyper-productive)

---

# GraphQL and Typescript: Revisiting an Echobind Case Study

> Reflecting on the synergy between GraphQL and Typescript, and how it’s helped us to write better code here at Echobind.

_By Ryan Atkinson · 2020-04-27_

![TypeScript logo](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/yklt45lzlvbbvgqom9yt.png)

Today I’m reflecting on the synergy between GraphQL and Typescript, and how it’s helped us to write better code here at [Echobind](https://echobind.com/). I recently wrote a case study for a client of ours and detailed how valuable these two pieces of technology were for our success. Below, I summarize the essential nature of the client’s challenges, and how GraphQL and Typescript set us up for success.

One of the core challenges of this project was the necessity for two separate applications, geared to serve two separate user demographics. Statistical data showed that one user group was typically a younger demographic in their 20s and 30s, and due to their comfort with technology and the mobile nature of their job, they would heavily favor a native mobile application. The other group tended to be a bit older and expressed a strong preference for a web application that would typically be accessed on a desktop computer in their home. The interactions between the native mobile app and the desktop web app would be numerous, as the app ecosystem needed to facilitate a number of features requiring input from both user roles such as messaging and interviewing. The challenge was how to ensure that the two applications communicated flawlessly from a technical standpoint while allowing developers to contribute to both platforms easily with minimal context shifting.

The solution came in the decision to use a GraphQL API for the backend architecture and to leverage a superset of Javascript known as Typescript for the frontend apps. One of the major reasons people use GraphQL over REST is when there are a number of preexisting REST APIs that are desired to be woven together. In this case, GraphQL is serving as more of a “middle layer” than a true backend. But is there ever a reason to use GraphQL as a true backend that accesses the underlying databases itself? We think so. The creation of a GraphQL API implicitly necessitates creating an organized “schema” of all of the data elements the backend provides and their hierarchical relations. This effectively serves as a “data contract” between the frontend and backend. This was useful on this project as it allowed developers to work on any portion of either frontend application, and to already be familiar with the underlying data structures since their implementation was uniform throughout. In short, GraphQL helped keep both frontend apps synced, and helped to keep developers sane as they contributed to both platforms.

While GraphQL ensured both applications were externally synced on the same relations with the backend, Typescript ensured that both applications were internally synced. Using Typescript and some additional tools (namely graphql-codegen), we took the GraphQL schema and converted it into a set of data “types” that were stored in the frontend codebases. By keeping the types in the frontend applications up to date, we ensured developers always had the latest data and documentation at their fingertips (by means of their editors TS plugins), and that many potential bugs would be caught before the code ever even compiled.

## TL;DR:

* GraphQL’s typed schema helps keep multiple frontend applications synced with minimal context shifting for developers.
* Using TypeScript on the frontend helped expose the GraphQL schema to developers as it was updated, keeping the code safe, and developers up to date on the latest data models.

The outcome was a robust and scalable application ecosystem that provided seamless interaction between the various user roles on their separate application platforms. The usage of Typescript ensured bugs were minimal in quantity and significance in both the web and mobile applications, and the GraphQL backend provided a solid foundation for not only the first iteration of the ecosystem but many future iterations to come. Scalability, clear documentation, and strong typing are some of the things Echobind loves about GraphQL and TS and keeps us coming back to them again and again for our best work.

---

[View on echobind.com](https://echobind.com/post/graphql-and-typescript-revisiting-an-echobind-case-study)

---

# 3 Attributes of Good Embedded Software Consultants

> Apr 23, 2020 | When working in new environments, our engineers need to be particularly strong in certain qualities in order to be the most effective as a part of our client’s team. Here are three of them that stand out.

_By Mike Cavaliere · 2020-04-23_

Team augmentation (aka, “software engineer rental”) is something a lot of software consultancies do as a service; if you’ve got good engineers, it’s valuable to let other companies borrow them for a fee. Sometimes those other companies have their own tech teams and don’t need to hire a whole team to get the job done — they might need one or two with specialized expertise as extra sets of hands to get a project over the finish line.

When working in new environments, our engineers need to be particularly strong in certain qualities in order to be the most effective as a part of our client’s team. Here are three of them that stand out.

## Asking Lots of Questions

If a new engineer to any project just listens and nods her head a lot, it could be a good thing — they could be absorbing everything perfectly, then once they hit the GO button on her keyboard they’re going to crush some code exactly how you need it. More often that’s not the case, and if someone isn’t asking the right questions, they’re missing something. They might be too eager to code something without knowing that the approach they’re taking is the right one.

Asking questions — a fair amount of detailed ones — is valuable since it shows the engineer wants to consider all angles before diving in. She doesn’t want to just start writing code, she wants to think of the challenges ahead of her holistically so that she’s going to execute efficiently.

## Looking at the Whole Stack

Things in software development aren’t always what they seem. This is especially true when diagnosing things like performance issues, for example, where a slowly-responding button could be the result of a front-end bottleneck, a back-end bottleneck, a third-party API call, or an engrained architectural decision.

Good software consulting — like good software engineering in general — is facilitated by assuming any problem you encounter might be the tip of the iceberg, with more parts of the problem hidden beneath the surface. Practices like the [Five Whys](https://en.wikipedia.org/wiki/Five%5Fwhys) and [root-cause analysis](https://en.wikipedia.org/wiki/Root%5Fcause%5Fanalysis) come in incredibly handy, even on a small scale.

## Pragmatism Over Perfectionism

Every software engineer wants to write good code, and do things “the right way.” But trying to focus on perfection at the expense of time, budget, practicality, and so on can lead us down costly rabbit holes or create unnecessary complexity that can turn into technical debt.

When working off of someone else’s dime, it’s particularly important to keep these things in mind. Being too perfectionistic with the solutions we build means missing deadlines, launching too slowly, and sometimes over-engineering solutions that might change before they’re worthwhile. So it’s important to have a razor-sharp focus on the immediate goals while keeping the long-term goals in mind, and building the happy medium solution that will best cover both bases without taking too much time to see the light of day.

---

[View on echobind.com](https://echobind.com/post/3-attributes-of-good-embedded-software-consultants)

---

# How to Avoid Response Bias in Surveys

> Apr 20, 2020 | In this post, four types of response bias will be discussed along with some tips on how to structure surveys to avoid them.

_By Anne Tolmie · 2020-04-20_

## **What is Response Bias?**

[Response bias](https://en.wikipedia.org/wiki/Response%5Fbias) is the tendency for participants to respond inaccurately to questions. This occurs often when people are asked to self-report, for example in a survey, and is often an unconscious behavior.

### **Why This Matters**

Surveys can be an invaluable method to get information from users or customers. In fact, a lot of software companies leverage user testing before building their app. However, many companies unintentionally use _biased_ surveys to inform their business decisions, which can have an effect on the validity of the research and lead companies astray. It is encouraged for any company to acknowledge response bias in surveys and take measures to inhibit it. In this post, four types of response bias will be discussed along with some tips on how to structure surveys to avoid them.

## **1\. Acquiescence Bias**

Acquiescence bias occurs when the respondent tends to agree with all of the questions in the survey, also known as “yea-saying”. There are many reasons hypothesized as to why people do this. Some people believe that it is due to the respondents’ desire to please researchers, and others think it’s caused by the respondents’ attempt to relate their experience to the question. Regardless of why this occurs, just know this bias occurs often, and there are ways to avoid it.

### **Pro-Tip**

Avoid asking questions that require the respondent to agree. This can also be known as a leading question. Instead, give them the option to agree or disagree. Take note of the following two examples. Which one avoids bias?

**Example A**

![Survey Question](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/kflb4wcxdohzc59eujdg.png)

**Example B**

![Survey question](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/f6fkev9mm6ykzueke6at.png)

Example B is the answer. Example B is considered best practice, as it gives the respondent the option to either agree or disagree rather than leading them to agree.

## 2\. Demand Characteristics Bias

Demand characteristics bias is where a respondent changes their behavior because they are participating in a survey. There are many ways this can occur, but here are a few examples:

* Participants try to figure out the purpose of the survey and change their behavior to align with that purpose.
* Through email surveys, if the respondent receives a friendly greeting, their responses can be influenced.
* The respondent having knowledge of the survey content before taking the survey may cause them to research before taking the survey.
* Anonymous vs. non-anonymous surveys may yield a different answer from the respondent.

### Pro-Tip

This is a tough one to avoid, however, you can soften the bias by using a neutral tone in an email survey greeting, avoid giving your participants prior knowledge regarding the purpose or content of the survey, and consider how anonymity would affect the respondents' answers. Additionally, you can _try_ to make the survey fun or engaging for your participants so they do not overthink it.

## 3\. Social Desirability Bias

Social desirability bias is the tendency for the respondent to choose the more socially acceptable response rather than answering truthfully. People tend to want to present their best selves, even if they do not know or have any face to face contact with the researcher.

### Pro-Tip

Consider anonymity. If you are going to use Example A, make your survey anonymous to receive more truthful responses. Otherwise, Example B is the best way to increase truthful responding.

**Example A**

![Survey question](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/ej6mn1vt7cf4ucxgm9uf.png)

**Example B**

![Survey question](https://res.cloudinary.com/echobind/image/upload/v1661872447/echobind_blog/rmusizmqtrtcdrl9t7ba.png)

## 4\. Extreme Responding Bias

Extreme responding bias occurs when participants are likely to choose the most extreme responses. This often occurs when the respondents are given a Likert scale. A Likert scale is a question that uses either five or seven points. This bias also commonly occurs when the respondent has a strong opinion or an emotional reaction to the question.

### Pro-Tip

Avoid asking sensitive questions using emotionally charged words or loaded language. Choose your words carefully and consider how they could make the respondent feel.

**Example A**

![Survey question](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/stbyqcknsmxygiaebjvw.png)

**Example B**

![Survey Question](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/lnvwhitkddlu9a5jifp9.png)

In these two examples, the only difference is one word. In Example A the word _eliminated_ is used whereas in Example B _removed_ is used. The word eliminated has a much more negative connotation than removed and may cause a more extreme response from a participant.

Voila. Four common types of response bias to watch out for when designing surveys. This was by no means an exhaustive list, but feel free to leave a comment if anything additional would be helpful.

---

[View on echobind.com](https://echobind.com/post/how-to-avoid-response-bias-in-surveys)

---

# How Illustrations & Imagery Compliment UI in Mobile Design

> Apr 17, 2020 | Ever wonder how a mobile user interface shines and gives you such a delightful feeling? A reason for that can be illustrations whether in 2-D, 3-D or photographic images.

_By Michael Dang · 2020-04-17_

‍Ever wonder how a mobile user interface shines and gives you such a delightful feeling? A reason for that can be illustrations whether in 2-D, 3-D or photographic images. These design choices are super important when trying to balance out a UI with just enough graphical elements to set the tone for a great user experience.

Here you can see how simple the UI is with just a mere couple elements in the burger menu, main navigation, content cards, etc. This allows the 2-D illustrations to take center stage and sets the tone of what the app is all about. We can see from all of the talking bubbles and people that it has something to do with communicating and messaging. The overall balance of this simple, intuitive design paired with an equally simple illustration works well in harmony.

![Apple App Store](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/n6kjh0bgkcf2f99nx5hj.png)

For this example, the 3-D illustrations are so powerful that you do not notice the UI as much as you notice the layout -and it still works because of its simplicity. From the vibrant colors to the polished characters, the illustrations here did most of the legwork in terms of the overall design.

![Netflix on an iPhone](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/kpdnnlszxrsl9hmeivqk.png)

In this UI, movie images are clearly leading the way and give you an immersive feeling that you’re in a library of movies. This is done quite well with clean spacing/formatting, clear titles/categories and of course amazing images. Finding the balance of UI elements, intuitive layouts and imagery is the key here and I feel like this designer did a great job encompassing all of that.

I hope these examples give you an idea of how to utilize different illustrations and images so that your UI design skills will further enhance and in turn give your users an overall better experience when using your app.

---

[View on echobind.com](https://echobind.com/post/how-illustrations-and-imagery-compliment-the-ui-in-mobile-design)

---

# Listen for the Call

> Apr 02, 2020 | In times like these, we see the helpers emerge. People are looking for the good and how they can help.

_By Jenn Robison · 2020-04-02_

We all are in unprecedented times right now. COVID-19 has people in situations that they have never found themselves before. Workers that never imagined they would be working from home, are working from home while trying to navigate a whole new world.  
  
In times like these, we see the helpers emerge. Whether that is the healthcare workers that are going to extreme measures for their patients or the car manufacturers that are shifting their facilities to make masks or ventilators, or the [individuals in places like my very own home town that are serving lunches to children that are out of school](https://pamplinmedia.com/fgnt/36-news/457247-372863-forest-grove-sandwich-shop-owner-gives-free-meals-to-kids-in-need?fbclid=IwAR2CPyPXaw8Pfv%5FeHyxtLVRh1P%5Fuh3mPjDR63ZBDFn8HjZOhWeS9jxEs3tY). People are looking for the good and how they can help.  
  
I connect deeply with these feelings, especially in times like these. My full-time day to day job is a software engineer, however, I am also an EMT and spent over 6 years as a volunteer firefighter. When times like these occur, I feel the call. A deep sense of wanting to connect and give.  
  
One of the ways I look to connect and help is by using my skills in technology and software development to solve the problems we are currently experiencing. I reached out in my local rural community and connected with a couple of other developers to see how we could help small businesses as well as individuals in need. Reaching out with simple acts of kindness go a long way.  
  
A friend that is on the opposite coast like me, is connecting with the at-risk youth in her area. Those she fears will lose their reading and math skills and do not necessarily have a strong technology presence in their homes. She put out a call for anyone to help her with a tutorial about how to download and install [Zoom](http://zoom.us/) on an iPhone or Android, so she could ensure these kids have what they need to engage with her. I didn’t think twice, we use Zoom on a daily basis. This video tutorial is not polished, but it was a ten-minute investment that allows an exponential impact.  
  
Through my years as a provider in emergency services I have an understanding of what those on the front line are going through, I also bring a different perspective when we work on an application for one of our [healthcare clients](https://echobind.com/work). I am actively looking for ways to bring my experiences in healthcare and my years as a software engineer to solve problems. If we can put ourselves in the shoes of those we are helping, we provide better user experiences and designs. When we can combine our passions and past experiences to bring new solutions, it is magical!

***Learn more about Echobind's [Healthcare capabilities](https://echobind.com/industries/healthcare).***

---

[View on echobind.com](https://echobind.com/post/listen-for-the-call)

---

# 3 Tips for Designing in the Healthcare Industry

> Mar 27, 2020 | One of Echobind’s strong suits is designing and developing applications for the healthcare industry. Hopefully, these three tips will help if you are ever challenged with the task of healthcare design.

_By Michael Dang · 2020-03-27_

One of Echobind’s strong suits is designing and developing applications for the healthcare industry. As a designer at Echobind, I have learned that there are special considerations when designing for the healthcare industry.

Hopefully, these three tips will help if you are ever challenged with the task of healthcare design.

**1\. Keep it Clean and Simple**

User experience is the utmost importance in my opinion when it comes to healthcare. The designer in me wants to try new things and see how I can up my design skills even more but then I have to keep in mind that the users of this app will most likely be focused on getting a task done or consuming information.

Below is an example of great formatting and spacing. I really appreciate the simple colors with good contrast and clear actions.

![Multiple health applications](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/ikornmjmg91qltp3bvwl.jpg)

**2\. Imagery**

Have uplifting images in place as opposed to a gory scene from E.R. will surely create a more upbeat feeling. Picking the right pictures will set the tone for your design. Even though it can be difficult at times to find these types of images, it is definitely worth doing so.

Here’s an example of a patient smiling while getting some work done. Notice how his facial expression lights up the mood in this photo. This creates a happy tone and adds to the overall look and feel of the design.

![Man at a doctors visit](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/h52bdb1askwi1lvkxeew.jpg)

**3\. Color Palette**

This may seem obvious but to keep with the happy/uplifting vibe, the color choices should also reflect that to help carry the mood across the entire app. Choosing bright colors with soft shadows and rounded corners is a great baseline. As you can see in this example picture below, the soft white is a staple for hospitals.

Also, note that the black color is more of an off-black mixed with a lighter purplish hue. That helps with keeping it light and is not as bold as pure black. If you mix in light pastel colors for contrast like the peachy orange, turquoise, and lavender you have yourself a great color palette that conveys a happy mood.

![Multiple health applications](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/rbdme64vycuqt3ubqbmr.png)

These tips that I’ve learned over time have really helped me with designing for the healthcare industry. Hopefully, I can inspire a few other designers and make their decision and thinking process a little bit easier. Happy designing!

***Learn more about Echobind's [Healthcare capabilities](https://echobind.com/industries/healthcare).***

---

[View on echobind.com](https://echobind.com/post/3-tips-for-designing-in-the-healthcare-industry)

---

# Feature Flipping with Rails and Rollout

> Mar 24, 2020 | With the Rollout Gem, switching a feature on or off is extremely easy and straight forward to set up in a Rails application.

_By Gabriel Martin · 2020-03-24_

Sometimes you want the ability to flip a feature on or off, or only give certain users access to new features in your application. Maybe you want to get user feedback before the final release? Maybe you want the ability to revert to the previous functionality with a single command.

With the [Rollout Gem](https://github.com/fetlife/rollout), this type of functionality is extremely easy and straight forward to set up in a Rails application.

Rollout allows you to enable or disable features without having to revert changes in the repository or promote different branches to production.

It does this by saving a “feature flag” in [Redis](https://redis.io/) which is either on or off. You can enable this feature flag globally, on a per-user basis or toggle the feature on and off for specific groups of users.

In order for Rollout to work, we need to have a Redis client set up in our application. I’ll walk through how I set up Redis for the demo app I created for this write-up. But first, let me show you what the app is.

The demo app is a very simple to-do app. A user can create and delete todos, and mark them as complete.

![TODO app with text box and button](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/e3mweobb75riqvanlrmx.gif)

## Setting up Redis

As mentioned above, Rollout uses Redis to store the state of feature flag. So let’s set that up.

Add the `redis-rails` and `dotenv` gems to you `Gemfile`.

```javascript
gem 'redis', '~> 4.1', '>= 4.1.3'
gem 'dotenv-rails', '~> 2.7', '>= 2.7.5', groups: [:development]
```

Make sure to install these new gems with `bundle install`.

Create an env file and add the key for the Redis URL. Here’s what I did for local development.

Create the file.

```javascript
touch .env.development
```

Add this to the `.env.development` file we just made.

```javascript
 REDIS_URL=redis://localhost:6379
```

Next, I added an initialization file for Redis

```javascript
touch config/initializers/redis.rb 
```

and add this to that file.

```javascript
require "redis"
Redis.current = Redis.new(url: ENV['REDIS_URL'])
```

You can check that this is working by opening up the Rails console and typing `Redis.current`. You should see something like this in the console.

```javascript
 => #<Redis client v4.1.3 for redis://localhost:6379/0>
```

Right on. Now that Redis is set up, let’s see how you can implement and use Rollout.

### Adding Rollout

I’m going to add a feature that allows a user to mark a todo as _important_. The only thing here is that I’m going to “wrap” this feature markup in Rollout so I can turn it on or off extremely. Let’s set up Rollout first.

Add the rollout gem to your `Gemfile`

```javascript
gem 'rollout', '~> 2.4', '>= 2.4.5'
```

and install with `bundle install`.

Now we need to update `config/initializers/redis.rb` to get rollout working.

```javascript
 require "redis"
Redis.current = Redis.new(url: ENV['REDIS_URL'])
# add this line
$rollout = Rollout.new(Redis.current) 
```

Make sure you restart your rails server. You can check if this worked by starting up the rails console and running `$rollout`.

You should get something back like this.

pre>

Rollout is now ready to use!

### Wrapping Features

I’ve added the column `important` to the `todos` table and updated the view and controller. Here is what the view file looks like.

```javascript
<% @todos.each do |todo| %>
  <div class="todo <%= 'important' if $rollout.active?(:important_todos) && todo.important? %> <%= 'complete' if todo.complete? %>">
    <div class="todo-text"><%= todo.text %></div>

    <div class="todo-actions">
      <% if $rollout.active? :important_todos %>
        <span><%= link_to todo.important? ? '!Important' : 'Important', todo_toggle_important_path(todo), method: :put, remote: true, class: 'important' %></span>
      <% end %>
  
      <span><%= link_to todo.complete? ? 'Incomplete' : 'Complete', todo_toggle_complete_url(todo), method: :put, remote: true %></span>
      <span><%= link_to 'Remove', todo, method: :delete, class: 'remove' %></span>
    </div>
  </div>
<% end %>
```

You can see that I’ve wrapped the toggle important link in an if statement.

```javascript
if $rollout.active? :important_todos
```

The `active?` method checks Redis to see if the \`important\_todos\` feature is…active. If it’s not, this will return false and nothing will be rendered.

Without this feature enabled, the app looks and performs the same as before the new code was added.

![TODO app with text box and button](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/lmo7j26ba6agkozocm5q.gif)

If we want to activate this feature, all we have to do is open up the rails console and run

```javascript
$rollout.activate :important_todos 
```

This will save the `important_todos` feature in Redis and set it to active. The next time a user visits the todos page, they will see the link to toggle important todos.

The great thing about this is that everything happens in a live environment. We don’t need to push a different branch if, for whatever reason, this new feature needs to be disabled, or restart any dynos to see the changes take effect.

All we have to do is start up the rails console and run `$rollout.deactivate :important_todos` and boom! No more important todos feature.

Here is a short clip of all this in action.

![TODO app with text box and button](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/cqmcl3fztfqn3pt7zd8l.gif)

There’s more to Rollout than just flipping a single feature on or off. Like I said before, you can enable features for specific users or place a bunch of users into groups (user testing) and enable features for the whole group. Be sure to check out the [Rollout Docs](https://github.com/fetlife/rollout) to see how this additional functionality works.

---

[View on echobind.com](https://echobind.com/post/feature-flipping-with-rails-and-rollout)

---

# Remote Workers: Help Your Neighbor

> Mar 17, 2020 | If you have been privileged with the ability to work from home prior to this craziness listen up.

_By Matt Thompson · 2020-03-17_

![Co-workers around laptop](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/pyms9wk5esgvq9ahkyys.jpg)

While I hoped to write a technical article today my mental state could not avoid the fog surrounding the current pandemic. So instead, I’m taking my own advice and focus on what I can do. What we can do.

## For Remote Workers

If you have been privileged with the ability to work from home prior to this craziness listen up. There are some simple things you can do to help those in need before you dive into that box of Samoas you’ve been hoarding by your desk (calling myself out here…) Friends and organizations are being forced into work environments with little to no warning, using tools and resources we take for granted on a daily. While there may be a dedicated IT guy on staff most places do not have that person. Those who do suddenly got overwhelmed with the scale of requests. “Hey, I need 20 laptops by tomorrow…”. Below is a quick example of how we can take our day-to-day knowledge and reach out to those in need.

## For Folks Forced Into Remote Life

If you are a small organization, non-profit, team, individual trying to figure this all out. Stay tuned. We are here to help. Hopefully, this will shed some light on resources you can use or at least get conversations started with those who may be able to help.

### The Example:

Most city/town organizations are comprised of small teams and offices 15 people or less. There’s not a dedicated IT guy. Instead, there’s a donated work station acting as a server in a closet, everyone just has their files saved locally on their desktop, with all the normal Office tools installed. While it’s not perfect… it works.

If you are in IT, you are probably thinking of 100 different ways this could have been solved for, the cost savings, the concerns of old hardware. You also know this is normal. It’s 2020 and some folks are still out their rocking XP, not caring about the issue until it was an issue… and until last week that was fine.

Today, meetings are being held with stressed organizers and managers trying to figure out how to continue forward while doing what they know is best — Sending people home. While there have always been glaring holes in the IT world, it is the scale that is crippling here. Folks assumed they’d need to replace a couple of machines at some point, but now they are needing to pull the trigger on a whole new infrastructure for their team. Today. These decisions normally take a year or more, budgets planned, business practices and protocols thought through.

## So What Can We Do

As remote workers, engineers, and consultants, we already have this knowledge and the resources on lockdown. We have best practices in place, the do’s and don’ts, and why it matters. The _ONE THING_ we can do today is to share this knowledge and some time. This isn’t the time to make a quick buck… This is helping your mom set up her printer territory. Do you know of a company using Office 365 — Help them integrate with Teams and OneDrive. No? Gmail users? Setup G-Drive and Slack. Introduce them to Zoom. Help them work out a meeting schedule. Those daily programs pinned to your taskbar — most folks are not aware. SHARE.

This week alone, I was contacted by a handful of organizations stressed just needing advice on how to function, how WE function. In most cases, this doesn’t even require a face to face meeting, simply a call of confirmation as you walk them through the best tools for the job.

As a Software consultant, this is in my blood. **_Use the right tool for the job, and empower others along the way_**_._ If you work remotely I challenge you in the days and weeks ahead to reach out to your neighbors and help guide the way. A simple 15-minute call could save a team **months** of stress and anxiety.

![Two men drinking coffee](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/zpjq9o5ihaki7vkq9isj.jpg)

[](https://unsplash.com/?utm%5Fsource=medium&utm%5Fmedium=referral)

## I’m Trying to Figure This Out

If you are among the masses now trying to figure out how you and your organization can continue forward. I urge you to reach out. We are here to help however possible. These are abnormal times, while we all hope for the best, we all need to be prepared. If you have questions about finding the right tool for the job or are in need of sound-boarding a solution to a problem, we are available and willing to help.

### Tools and Resources to Start

For most organizations, a few things kick in when needed to work remotely.

* All my files are at work!
* I’m used to chatting w/ John all day about this stuff…
* We still have to get everyone together at some point, how are we going to stay on the same page.

I hinted at a few of these above, but here’s a quick breakdown.

**All my files are at work!**

* [Office365 OneDrive (Included w/ subscription)](https://products.office.com/en-us/onedrive/online-cloud-storage)
* [Google Drive (Free space per Account)](https://www.google.com/drive/)
* [DropBox](https://www.dropbox.com/?landing=dbv2)
* [Box](https://www.box.com/home)

**I’m used to chatting w/ John all day on this…**

* [Office 365 Teams (Included w/ subscription)](https://www.microsoft.com/en-us/microsoft-teams/group-chat-software)
* [Slack](https://slack.com/)

**We still have to meet at some point**

* [Zoom](https://zoom.us/)
* [Whereby](https://whereby.com/user) (Room up to 4 free)
* [Google Calendar](https://calendar.google.com/) (Schedule those Zoom Meetings!)

While these aren’t the ONLY tools in the shed, they are a good start when making a quick transition. In short, if you already have a 365 subscription, start leveraging it more. If not I’d recommend uploading your files to Google Drive and create an organization on Slack. Zoom is your friend.

The number one piece of advice, Don’t let pride get in your way.  
We are in the information age with the ability to ask the world for help on a whim. Don’t be afraid to do so. Chat soon!

---

[View on echobind.com](https://echobind.com/post/remote-workers-help-your-neighbor)

---

# 10 Tips to Ease Working From Home

> Mar 13, 2020 | As a team, we have put together a few tips that we hope will help you if you are struggling to work from home.

_By Anne Tolmie · 2020-03-13_

With coronavirus, many companies are encouraging their employees to work from home, if they can. For some, working from home is a challenge. Some may find it takes a toll on their productivity and some may be feeling downright lonely.

At Echobind, we work remotely the majority of the year — apart from kickoff meetings and our annual summit. We know what it is like to make that adjustment from working in the office to working from home. As a team, we have put together a few tips that we hope will help you if you are struggling right now.

## 1\. Have a Routine

Don’t work from your PJs. Eat breakfast, shower, get dressed as if you were going to work.

## 2\. Start Moving Early

Go for a walk after breakfast. Don’t go straight to the computer.

## 3\. Be Social

Find a way to socialize here and there, even if it’s on a phone or video call. Otherwise, you’ll go stir crazy faster.

## 4\. Get Sunshine

Get sunlight into your home as much as you can. Try to set up your workspace near it. Also, take outside breaks if possible.

## 5\. Move

Don’t sit all day. Try to take movement breaks. Shoot for one per hour. You will feel so much better, and less sluggish.

## 6\. Have a Stop Time

Just because you’re working from home doesn’t mean there’s no end to your workday.

## 7\. Separate Your Space

Try to separate your workspace from your personal space. This will help enforce your stop time, and allow you to get out of work mode faster.

## 8\. Buddy Up

Reach out to someone you feel comfortable with (hello work bestie) if you feel isolated. Try to check in with that person daily or at a minimum weekly. You never know when they could need you too.

## 9\. Over Communicate

Communicate more than you think you have to. This entails giving frequent updates to your team when you are blocked, complete a task, or even if you are going to lunch. At Echobind we use Slack. This makes status updates easy peasy!

## **10\. Identify Your Tools and Stick to Them**

We use Slack to stay in touch and Zoom calls for meetings. At Echobind, it’s best practice to always have the camera on so we actually get to see each other.

We hope you enjoyed these 10 tips to ease working from home. Leave us a comment if you found them helpful, we would love to hear from you!

---

[View on echobind.com](https://echobind.com/post/10-tips-to-ease-working-from-home)

---

# Product Design ft. Hello, Startup — the MVP

> Mar 05, 2020 | Let's focus on bringing what we learned about user-centered and visual design into a minimally viable product.

_By Ashley Nelms · 2020-03-05_

In the previous part of this series, we dove into the beginning stages of product design with [Hello Startup](https://www.hello-startup.net/): visual design. In this installment of the series, we’ll go through the next stage which focuses on bringing what we learned about user-centered and visual design into an MVP.

## Minimum Viable Product

Also known as MVP, which is defined excellently in Erick Ries’ book The Lean Startup as “a version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”

> _… “Minimum” is often misread as “ship something — anything — as soon as humanly possible,”… “Viable” is often incorrectly understood as “enough features for the product to function,”… “product incorrectly suggests that the MVP must be a product… —_ **_Yevgeniy Brikman | Hello, Startup_**

Hello, Startup puts it well. **Minimum** means eliminating that which doesn't help with validation, **viable** means having everything needed for customers to accept it and **product** could be a working prototype or something simpler, including just a landing page.

Creating the initial version of the MVP is the first challenge in designing the product. It can be tough to resist the temptation to try and maintain perfection to build an unrivaled product. Doing that would, in my opinion, drive anyone mad!

![Henrik Kniberg drawing](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/hdvt3as7cbmo1qtv8c3z.png)

[Source](https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp?ref=https://product-frameworks.com)

Product design and building the MVP is an iterative process. With each iteration, you encounter new problems, new solutions, and new ideas. Through trial and error, you continue to refine your product design before the MVP is finalized.

## Types of MVPs

The MVP doesn’t have to be a tangible product but just something to assist with validation when used. I’ll touch on the three most common forms of MVPs but Hello Startup goes into a few more that are worth checking out!

### Landing Page

Perhaps the most common, a landing page is a cheap and effective MVP since it requires minimal expense to set up and quick to update when needed. It’s a web page that consists of your product description and can gauge user interest through some type of commitment, usually an email address to receive more information. If you’re struggling to get user commitment then reconsider what can be done differently; if it’s getting a lot of attention then you can be more confident that you have something good going.

![No Code landing page](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/atewooqx5fshbx1xfolo.png)

[Source](https://medium.com/lean-startup-circle/time-to-create-a-landing-page-and-test-your-mvp-acc028c0f8fe)

### Explainer Video

_Show don’t tell_ is a phrase that holds true when trying to grab the attention of potential users. The greatest example of this is Dropbox. Instead of creating a full-fledged product that would have required a data storing service, Drew Houston created a [four-minute video explaining](https://www.youtube.com/watch?v=iAnJjXriIcw&feature=emb%5Flogo) what DropBox was about and even had a basic prototype for users to try out on their machines.

### Crowdfunding

Most people are familiar with Kickstarter, a place filled with creative ideas that people can pledge funds to. This is my personal favorite form of MVP since it’s engaging, transparent and overall more fun than other options. People are willing to pay money before the product is even built and to me, that is crystal clear validation that you have a good idea that people want to see come to life.

![A guide what is JS crowdfunding](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/elf8gq9srgtib0rjrajg.png)

[Source](https://www.thebalancesmb.com/a-guide-what-is-crowdfunding-985100)

## The Differentiators

Also referred to as the “competitive advantage”, differentiators of a product are the features that separate it from similar products. When trying to outshine your competition you don’t go for “just enough”. You want to do something significantly better so that users **want** to use your product over competitors’. Remember, show, don’t tell — you really want to present how you’re better than the alternatives!

A product can’t do everything so it’s essential that you focus on the small number of features that you want it to excel at. Identify these and build your MVP around them. If you’re building an app that allows users to sign up for workouts with a trainer or in a class, trying to focus on in-depth user profiles for the MVP won’t benefit you, scheduling and signups will. Invest your energy, time and budget wisely!

![Donuts](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/au2n2hkiclthwrl8gyns.png)

[Source](https://www.jeremyjarrell.com/mvp-validates-need/)

## Conclusion

To some degree, everyone is a designer and understanding the basics of design is a core skill to have for anyone working in software. Always keep in mind that the process of product design is iterative and adjustments will be made through trial and error, from user-centered design to visual design and finally the MVP.

Remember, this is only a fraction of the valuable information that can be found in this book. I highly recommend picking up your own copy for more in-depth explanations and examples.

![Matt Leblanc quote](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/kxbvjcvn5ifayfootrrp.png)

[Source](https://www.springboard.com/blog/shareable-ux-design-quotes/)

Stay tuned for the next part of the series where we’ll go through Hello Startup’s section on growing the MVP using data and distribution.

Until next time!

---

[View on echobind.com](https://echobind.com/post/product-design-ft-hello-startup-the-mvp)

---

# Getting to Yes Faster

> Mar 03, 2020 | The sooner you can get to yes, the sooner the work can begin and your project can stay on schedule. Here are three tips on how to get your client to say yes faster.

_By Anne Tolmie · 2020-03-03_

Part of my job as an account manager at [Echobind](https://echobind.com/) is client communication. My point of contact on a project can vary between a project manager to a CEO. When my point of contact is a CEO, time is of the essence. Generally, they are busy and their time is limited.

What I have learned is that, usually, it is just a matter of getting the client to agree so we are all on the same page. We are a consultancy. Our clients come to us because we have the experience and the knowledge to get the job done. My team already knows the strategy we want to take, it is just a matter of getting the client on board.

The sooner you can get to yes, the sooner the work can begin and your project can stay on schedule. Here are three tips on how to get your client to say yes faster.

## 1\. Keep it Short and Sweet

When emailing the client, keep it as brief as possible, especially if you want a quick response. I don’t know about you, but if I see a long email and I am in a rush, I will schedule time later in the day to go over it. If I have a few minutes and I see a short email, I am more likely to respond.

## 2\. Ask a Multiple Choice Question

Instead of asking the client an open-ended question and expecting them to answer, provide them with options. Design a multiple-choice question. Ask your question and provide three viable choices. This will lighten their mental load by being able to choose from options A, B, or C.

## 3\. Don’t Be Afraid to Ask for it

A simple but effective way to get to yes faster is to be direct and ask for it. You could simply say, “John, I’m only looking for a yes or no here, but do you want …”. This is clear and concise. It takes the pressure off the client to respond with a paragraph. They know they can simply say yes, or no to what you are asking.

There you have it, three simple ways to get to yes faster. Drop me a comment and let me know if you found this helpful. I would love to hear from you.

---

[View on echobind.com](https://echobind.com/post/getting-to-yes-faster)

---

# How to Prepare for Hiring and Recruitment

> Feb 25, 2020 | Hopefully, these tips and learnings will help fast track anyone that is going through the hiring and recruiting process. Let’s jump right in.

_By Elrick Ryan · 2020-02-25_

Hiring and recruitment is a challenge. There are things that you need to do in order to be prepared before you start. It turned out to be more involved than I initially expected, but it is not until you do something that you are able to fully understand it, learn and get better.

Hopefully, my tips and learnings will help fast track anyone that is going through the hiring and recruiting process. Let’s jump right in.

## Figure Out Why You Are Hiring

The first thing to do is to analyze what the needs of the company and the team are. Look at the current makeup of the company and team. Note the strengths and weaknesses. Then think about where you want to go and the types of projects you want to do. Once you have those written down, you are moving in the right direction.

With this in mind, you can develop a profile of the candidate that you need to hire. Write down things like what skills they need, what tools or languages should they know, what experience, etc. This information will be helpful in the next step.

## Write a Job Description

When writing your job description, you want to be honest, open, and genuine. A job description is your opportunity to make a good impression on candidates and highlight the culture, tone, and values of the company. Remember, you are presenting both the job and the company. A good job description will impact which candidates apply to your job so spend some time and make it great.

You can organize your job description in any number of ways, but here are some things you should include when writing yours.

* Short description of the company
* What you do/offer
* What makes your company different from everyone else
* Company values
* Something thought-provoking
* Why are you hiring
* Why is this an interesting and great opportunity
* What impact will the person have in the is position
* What responsibilities will the person have in this position
* What are the required skills and experience needed
* Benefits
* Perks

Remember to be honest and realistic with yourself and the potential candidates. Speak primarily about what the person needs to have in order to be successful in the position. By the end of the job description, someone should be able to answer do I qualify, do I want to work here, do our values match, do I like the culture, what kind of impact will I have, and does it sound like a good opportunity.

![Picture with text that says this must be the place](https://res.cloudinary.com/echobind/image/upload/v1661872447/echobind_blog/qmohi6bf3nspxojtrngp.jpg)

## Use an Applicant Tracking System

Setting up an applicant tracking system will allow you to keep track of the stage that an applicant is at within your overall process. I first started using Airtable, which worked great on a small scale. But I quickly outgrew that solution as the number of applicants increased, and I ended up using Workable. You can choose any applicant system you like, but here are a few features that were very useful.

* The system allows you to add customize stages, statuses, and tags as applicants go through through the process. Each applicant tracking system treats these things differently, but overall you just want to know where someone is, their status, and how long have they had been there. Some examples would be, applied, DNQ, Send DNQ letter, DNQ Letter Sent, phone screen, Send Thank you, Thank you Sent, interview, hire.
* Applications and submitted documents from an applicant go right into the system.
* Ability to add any external documents, and links per each applicant.
* Integration with email, calendar, and scheduling tool.
* Able to add comments and assessments.

The applicant tracking system keeps you updated with what is happening with an applicant and allows you to stay on top of communication as well.

## Setup a Scheduling Tool

It’s challenging enough to have several asynchronous dialogues with applicants. Going back and forth in email and scheduling times for things such as phone screens, interviews, follow-ups are almost impossible and time-consuming. How do I know? I made this exact mistake.

I made a flow chart to identify where I could optimize. In the best-case scenario, it would take three emails. One, sending available times. Two, a response with a selection of a time slot. And three, an email to confirm the time. In addition, to adding the confirmation to my calendar. However, a high percentage would take more than three emails, trying to shuffle time slots and for multiple applicants.

At that point, I realized there were too many steps associated with scheduling availability. What we were trying to do with the emails is to find a match that works for both parties. If I allowed the applicant to pick without the need for follow up emails, we could reduce this to one email. This is what a scheduling tool allows you to do.

In the scheduling tool, you need to set up and block-out your available times beforehand. Then, send a link to all candidates and they will choose the best time that works for them from that list. You will then be alerted as to who picked what time. Also, if your scheduling tool supports it, each accepted time will be automatically added to your calendar. And the list will be automatically updated to show the remaining times to all the applicants.

I used Calendly but I am sure there are more out there.

Up to this point, we know why we are hiring, who we are looking for, we have a job description, an applicant tracking system, and a scheduling tool. We are almost ready to post the job but we have a few more things to make sure we have in place first.

## Compile Rubrics

Before you start talking with candidates and reviewing any information they submitted you need to compile some rubrics and a list of baseline questions that you are going to use during your screening, reviews, and interviews, etc. for each position you intend on posting.

A rubric is a set of criteria that you are going to use when you evaluating candidates. Here is an example:

* Does the person have the years of experience we are looking for?\[yes\]\[no\]
* Do they have work examples, portfolio, etc. \[yes\]\[no\]
* Do the candidates’ work examples show proficiency in Javascript, Ruby, Node, Typography, Composition, User-centric Design, etc. \[yes\]\[no\]
* Do the candidate responses show a clear understanding

Rubrics will enable you to keep detailed information about each applicant. Hopefully, they will eliminate any bias and introduce some transparency. They will allow any person involved in the process to use the same criteria. It enables open and consistent communication during and after the process when speaking about a candidate.

## Get Your Interview Questions in Order

This is a tricky topic and lengthy, but I will try to distill it down to the essentials. When you get to point when you are speaking with candidates you will have a mix of static and dynamic questions comprised of behavioral, general, and technical questions. Static questions come from baseline, general, and the notes you gather while reviewing things like resumes and portfolios. Dynamic questions happen on the fly during the conversation.

What is very important is your questions need to be scoped around the applicant’s function and ability to do the job. And they should not be discriminatory in any way. You may have the best intentions at heart but could ask questions in a very ill-advised way. In addition, there are questions that are completely illegal to ask so make sure you don’t ask those.

Here are some examples of illegal questions you cannot ask:

* Do you have a disability?
* How old are you?
* Are you a citizen?
* Have you been arrested before?
* How much money do you make now?

However, if you reframe and ask the question in a manner that is based on the applicant’s ability to do the job, and job requirements that is ok. This, as I mentioned, is trying to eliminate any discriminatory practices.

* “This job requires or involves you to do \[XYZ\], do you think you will be able to perform \[XYZ\] effectively?”
* “Are you legally able to work in the United States. Do you now, or will you in the future, require sponsorship for employment visa status (e.g., H-1B visa status, etc.) to work legally for our Company in the United States?”
* “All applicants have to submit their information for a background clearance check and pass that before we can grant employment, are you able to do that?”
* “Is there a particular pay range you are hoping to be within for this position?”

Consult with your human resource director as they should be very aware of this and should be able to train you if needed. I took both the Human Resources and Business classes that covered this topic in detail. But since I am not an active HR professional, I made sure to consult with two Human Resource Directors from two big companies before proceeding to be aware of any changes.

The gist of it is don’t’ ask illegal questions, frame your questions around the applicant and job function and don’t carry bias into these situations.

## Organize and Document Your Overall Process

We have mentioned things like the hiring process, stages, rubrics, and questions. This is where you document these in order for you to be organized and the candidates to know the process. You can create whatever process you think will result in your finding the best candidate. Just make sure to document and follow it for every candidate in the cycle of that job posting.

Here is an example of a high-level overall process.

* Applied
* Initial Screening/Review of the applicant’s submitted documents
* Phone screen
* First-round interview
* Onsite interview — Technical, Collaboration
* Take-home project or pairing session
* Collect, assess all evaluations from the interview, onsite, take home, etc
* Check background and references
* Hire

These are the high-level points in the process. Between each point, you have scheduling, evaluations, and sending out emails. This is also where your applicant tracking system is important because you will set up all the intermediary stages and status in there. For example, after someone applies, you screen/review and then what happens? Do they move on or not? Can you send the email now or do you need to do it later? Any number of conditional branching can happen in your process but have them in your system and document them.

One thing to note is that your process, rubrics, and questions should be fundamentally the same for every candidate. If you deviate from any of these in the process make sure to document exactly why. For example, if you normally give test A, and then decide you don’t have to, make sure to document exactly why you made that decision. Your documentation and supporting evidence need to be rock solid. If not, you can end up in a world of trouble. My humble opinion would be to give test A to everyone.

At this point, you should be prepared and ready to post your job.

## Post Your Job

Where you post your job really depends on the position you are trying to fill. You have several options when you are listing your jobs and there are no hard fast rules as to which one is going to yield the best candidates. The goal is to get your job posting out and in front of a diverse set of people.

Here are some examples of options and places you post your job.

* General job boards like LinkedIn, Indeed, or CareerBuilder.
* Alumni board from a specific program.
* Specialized Job board like Dribbble, EpicCo, or Remoteok.
* The framework or library you use might also have a job board on their site. ie. React, Vue, Ember, Node, Ruby, Elixir, etc.
* Tweet it on Twitter.
* Slack groups catering to the job posting.
* Mention it in a podcast.
* Get recommendations from your network. The people that you know and trust.
* Use an agency like g2i.
* Post it on your website.

Using a combination of these resources will have applications coming in for your job posting.

![MacBook Pro next to a plant and cellphone](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/s7nzylqz0wlryk5mtavl.jpg)

## Be Actively Recruiting

Posting your job does not necessarily mean that people are going to apply. I learned that hard lesson when I posted a job and for weeks, even months, and no one had applied. This had me questioning a number of things, including the job description, the company’s website, and the posting location. I realized that getting awesome people to apply to your job is a combination of all that and then some. Recruitment is not just posting a job, or sending out cold emails and DM’s on LinkedIn. You have to be doing passive and active recruitment.

For a company trying to recruit great people they need to:

* Network — talk with people that you would want to work with before you want to work with them and build a relationship.
* Be active and give back in the community — do workshops, sponsors programs and conferences.
* Have a great culture — you need to show, that you are serious about fostering and keeping a diverse, open, and collaborative environment.
* Make a good first impression. Your website, copy, culture videos, emails, recruitment packages, etc. need to speak positively to people.
* Present your best work — If you are doing interesting work you need to show it and speak about it.

Hopefully, these methods will help you attract those great people into your company.

## Talking With People

Once you have done the prep work it will make speaking with people and the process much smoother. Here are a few more things to remember when you at this stage.

### Give yourself time before and be prepared

You need to have time before you speak with someone to prepare. Make sure you have read, re-read, reviewed, and re-reviewed all the information the candidate has submitted and it’s fresh in your mind. Do not wait until you are actually speaking with someone to read or review their application. This is highly ineffective and it shows a lack of professionalism. We expect candidates to be prepared, prompt and professional. You as a hiring manager and a representative of the company should do the same.

### Have all your prep work open and ready

Don’t wait until the call to start looking for the questions you need to ask or the rubrics you want to use. Have those open and ready before the call.

### Give yourself time after

It best to compile your thoughts immediately after speaking with someone. So, whatever notes, questions, rubric you have to be sure to address them right away because waiting until two days later will not work. You can use anything, your applicant tracking system or just a simple file. But be sure it’s easily retrievable.

## A Few More Things

Before I close out, I want to mention a few more things to keep in mind.

* Be respectful of the candidates’ time.
* Do not be in a rush to hire but keep a good pace.
* If you do not find the right fit, start the hiring process over.
* If you are certain you found the right person, don’t wait too long to send an offer.

## Best of Luck

This is an ongoing learning process. But hopefully, this post pointed you in the right direction. If you only remember one thing from this post, remember to **be prepared, honest, and open.**

---

[View on echobind.com](https://echobind.com/post/how-to-prepare-for-hiring-and-recruitment)

---

# Love Your Customers by Investing in Your Employees

> Feb 20, 2020 | Happy employees create a ripple effect — the happiness is infectious among other employees and customers can feel it, too.

_By Sarah Case · 2020-02-20_

Last week I got to kick off Valentine’s Day weekend at the [Customer Love Summit](https://www.customerloveseries.com/summit/) in Boston and I got to see some of my favorite people along the way ([Trish Fontanilla](https://medium.com/u/9eb379b58681?source=post%5Fpage-----9b8e4cc195d1-----------------------------------), [Felicia Jadczak](https://medium.com/u/f3fd89adce29?source=post%5Fpage-----9b8e4cc195d1-----------------------------------), and [zarla ludin](https://medium.com/u/2d0d5591baed?source=post%5Fpage-----9b8e4cc195d1-----------------------------------), to name a few).

To start, the Customer Love Series is focused on two types of customers: your employee and the person consuming your product/service. Happy employees create a ripple effect — the happiness is infectious among other employees and customers can feel it, too. As Director of Operations at Echobind, our employees are my customers, which means I’m constantly trying to support them, make sure they’re happy and that they have everything they need to be successful. In short, one of my primary focus areas is the Echobind employee experience.

_Employee Experience_ is something companies invest in (whether they do so strategically or not), and there’s [data](https://www.visioncritical.com/blog/employee-engagement-benefits) to back up the value of creating an excellent employee experience. Employee performance is better, customer experience is better, and profit and Revenue feel the love, too.

When we talk about _Employee Experience_, many people think about ping pong tables and bean bags in the office, free lunch Fridays, etc. These are perks, and while they might contribute to employee experience, they don’t alone define it. So what does? The short answer, a lot of things. But they can be generally broken up into three buckets:

**Benefits and perks that drive _real value._**

Sure a foosball table in the office is fun, but what value is it driving for your employees? If you have to pick between parking or public transportation subsidies to help your employees get to and from work or endless snacks, ask yourself which is really going to move the needle for your employees?

The same question applies to remote companies, only we’re working in a different framework. To make sure we’re truly driving value, we survey our team at least once a year. We give them $100 to allocate across a dozen or so benefits and perks to get a pulse on what our team wants to see and what they really value. It’s amazing to see the results that come back. Then we share a summarized view of those results and apply what we’ve learned in tweaks to the upcoming year’s benefits and perks offerings.

**Activities that create satisfied and engaged employees.**

This is an interesting bucket, especially for remote teams. How do you make sure people are satisfied and engaged? How do you track that over time and triage if you see a dip? We invest (dollars and time) into tools and platforms to help people collaborate, to set and track their professional goals, and to keep open communication. We also use Zoom meetings with a camera on policy to see each other on a regular basis (even if just virtually). For 2020, we’ve also rolled out a strategy for conferences to send more people when we’re sponsoring or someone is speaking. We recognize that our team doesn’t get to meet up in person often, so we’re thinking creatively to solve for that beyond our annual team summit.

Another way to keep employees satisfied and engaged is to recognize their hard work. This can be through an employee of the month announcement, a kudos channel in Slack, or any other medium that makes sense for your team. We’re all out here hustling, and it takes two seconds to share that you appreciate when someone has gone an extra mile for you, for the team, or for the customer.

Bottom line is, do what works for your employees and for your company — there’s room to get creative. Ask for feedback from your team and pivot if you’re not seeing the results you expect to see.

**A productive work environment with a complete toolset.**

This is critical and can be successfully achieved in a bunch of ways. One of the speakers showed a picture she’d snapped of a new hire’s desk before they arrived. It was decked out with a bunch of things like a new laptop and monitors, some company swag (a T-shirt, a water bottle), and a fresh notebook. And [Trish Fontanilla](https://medium.com/u/9eb379b58681?source=post%5Fpage-----9b8e4cc195d1-----------------------------------)

 made the comment that when she was setting up for a new hire, she always liked to order a small run of business cards to show that person how excited you are they’re on the team. But apart from the swag, making sure a person has everything they need to effectively do their job is key to employee experience, especially on that first day when you want to start off on the right foot.

All in all, there’s so much that goes into _Employee Experience_, there is no right way to do it, and there is definitely no plug-and-play formula.

Also, a little love for the organizers. They assembled an incredibly diverse speaker set. There were men, women, people of color, and disabilities represented on the stage. Industries included arts, consumer tech, non-profit, and consulting. The customer love theme seamlessly tied everyone together and provided the audience with a wide variety of stories, perspectives, and insights. If you’ve ever organized an event, a panel, or conference, you can appreciate how difficult it is, and the Customer Love Series team pulled it off.

---

[View on echobind.com](https://echobind.com/post/love-your-customers-by-investing-in-your-employees)

---

# Use These 3 Things to Add Value to Your App in 5 Minutes or Less

> Feb 18, 2020 | For those in-between task times when you feel like going above and beyond.

_By Echobind Team · 2020-02-18_

For those in-between task times when you feel like going above and beyond.

## **1\. Cool Micro-interactions**

![Hover animations on the Echobind website](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/bos3iygy73saajdjgj4l.gif)

Hover animations on the [Echobind website](https://echobind.com/services).

Last week, we added a slick little transition to a few card components on the Echobind website. When hovered, the card appears to slide toward the user. The slight translation on the y-axis, combined with the wider-spread box-shadow, gives a visual indicator that this element is clickable, and focused. The growing gradient underlining the card title was just added for fun.

## 2\. Loading Spinners or Progress Bars

This one will make your users immediately happy. We recommend [nprogress](https://ricostacruz.com/nprogress/). It’s a lightweight JavaScript library that takes 5 minutes to implement, and it’s framework agnostic. Add in a few extra minutes if you want to customize the appearance of the loader. Here’s a gif of what the default configuration looks like:

![Default loading spinner for Nprogress, a lightweight library for loading spinners and progress bars.](https://res.cloudinary.com/echobind/image/upload/v1661872447/echobind_blog/fwmjddgqdu4r30601b2t.gif)

Default loading spinner for [Nprogress](https://ricostacruz.com/nprogress/), a lightweight library for loading spinners and progress bars.

Depriving your users of a loading/progress indicator is not an option. Take a few minutes and show them that something is loading.

## 3\. Tests!

Add some tests! Adding end-to-end testing (preferably, automated) immediately returns on its investment. We ask our engineers to use [Cypress.io](http://cypress.io/) for integration and E2E testing on _all_ of our projects because of its simplicity, features, and power. All of our engineers have reported 100% satisfaction because writing tests helped them fix bugs that weren’t immediately present, detect and fix bugs before the inflicting code is deployed, and use the tests as a form of documentation to set a feature’s acceptance criteria. Clients love it because they are seeing less time spent bug hunting and fixing, and more time writing features. [Michael Yagudaev wrote an excellent article on testing with Cypress](https://medium.com/free-code-camp/how-to-test-your-frontend-with-the-cypress-io-framework-f048070f4330), and we recommend taking a gander and trying it out.

![Cypress running automated end-to-end tests on a small to-do app](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/th3ysitbimd4jsybxuun.gif)

Cypress running automated end-to-end tests on a small to-do app.

What are some other quick things can add value to web apps? Let us know in the comments!

---

[View on echobind.com](https://echobind.com/post/use-these-3-things-to-add-value-to-your-app-in-5-minutes-or-less)

---

# React Native Fix: Jumping Screens in the React-Navigation TabNavigator

> Feb 17, 2020 | Let's head down the rabbit hole of trying to fix an issue I was having with a seemingly simple react-navigation implementation of a TabNavigator.

_By Ryan Atkinson · 2020-02-17_

I recently went down the rabbit hole trying to fix an issue I was having with a seemingly simple react-navigation implementation of a TabNavigator. I followed the docs exactly and didn’t have anything out of the ordinary in my code (or so I thought). The issue was that every time I selected a new tab of the tab navigator, the screen would “jump” as it was rendering.

It looked like this:

![iPhone app with three tabs on the bottom](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/eunow96wjcmaawijsk99.gif)

Why is the screen jumping 😢

It would happen so fast that it didn’t seem like a big deal at first, but as the issue persisted it became an increasing frustration. I couldn’t find or think of anything that would cause this problem, and the GitHub issues page for react-navigation gave me no help either. Part of the issue was also that people would probably use a lot of different nomenclatures to describe the issue, whether it be “jank”, or “jumping” or “stuttering”. But the biggest issue was that I really didn’t understand the problem well enough to even compose a proper search for the solution…

After taking a QuickTime video of the screen jumping, and playing it in slow motion to see what exactly was happening, I noticed that the additional padding above the StatusBar was briefly disappearing during the jump. Interesting. This got me thinking about the usage of React Native’s SafeAreaView since that is what provides the additional padding on the top.

I looked at the official documentation, <https://facebook.github.io/react-native/docs/safeareaview> but there wasn’t anything interesting there. Searching the react-navigation documentation for “SafeAreaView” yielded this: <https://reactnavigation.org/docs/1.x/handling-iphonex/>.

_👀 This section jumped out at me:_

![React Navigation screenshot of forceInset](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/dzcuj3jzlfpaosmsuxfm.png)

That sounded like exactly what I needed! `forceInset="top"` But it also raised some additional questions… why is `forceInset` recommended by react-navigation, but not in the official docs? Why was it jumping at all if I’m only trying to leverage the insets that should be the default for a SafeAreaView? 🤔

Boom! I stumbled on to the **react-native-community** page for SafeAreaView, which differs from the primary documentation: <https://github.com/react-native-community/react-native-safe-area-view>. The react-native-community SafeAreaView _does_ expose the forceInset prop, and documents it as follows:

![React Navigation screenshot of forceInset](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/wh0irr85hnyqbsho1s89.png)

> _Sometimes you will observe unexpected behavior and jank because SafeAreaView uses onLayout…_

YES. This is exactly what I was missing. The screen jumping was the “onLayout” call happening under the hood. The solution (as suggested by react-navigation) was to use `forceInset="top"` to preload the top inset prior to the onLayout call. The other issue is that `forceInset` is not available on the SafeAreaView exported directly from react-native, but only on the one in the react-native-community package.🕵

With these changes in place our app looks like it should:

![iPhone app with three tabs on the bottom](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/fmghtl9jmpqeodz2k9qo.gif)

No jumping!

In summary, when using SafeAreaView with the react-navigation TabNavigator, be sure to add the react-native-community SafeAreaView, and specify `forceInsert="top"` on all of your tab screens.

I hope this helps some of my fellow react native developers!

***Learn more about our [React Native capabilities](/capabilities/react-native-app-development).***

---

[View on echobind.com](https://echobind.com/post/react-native-fix-jumping-screens-in-the-react-navigation-tabnavigator)

---

# A Typeface or a Font — which is right?

> Feb 13, 2020 | The origin of Typography has deep roots but many of the terms used today can be traced back to print before even 1880.

_By Elrick Ryan · 2020-02-13_

The origin of Typography has deep roots but many of the terms used today can be traced back to print before even 1880\. The use of Typography has evolved and grown over time. It is now used in many different industries and disciplines including graphic, motion, and product design (UI/UX). This widespread use across disciplines leads to some of the terms being used interchangeably.

Four common terms used interchangeably across design are type, typeface, font, and font-family. Depending on what industry you are in and who you are speaking with, they may use one or the other. Which are very similar but have subtle differences.

When you look at different pieces of Typography any party will generally agree that it has an identity, a style, a weight, and a size.

## Typeface

The identity is associated with the typeface. A typeface is a particular design of Type that has the same visual consistency and characteristics across all characters.

There are hundreds of typefaces but here are a few examples:

* [Roboto](https://fonts.google.com/specimen/Roboto)
* [San Francisco](https://developer.apple.com/fonts/)
* EB Garamond
* Helvetica Neue
* Times New Roman
* or Brush Script

![letters in EB Garamond typeface](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/vxpp3nolnlcosowl5hzg.png)

![letters in Roboto typeface](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/cvvnf8d5xdvg83g2kv1b.png)

## Type

Type refers to an individual or collection of characters of a typeface. It comes from the time when letters (a character) were printed onto a single block of metal and used in a printing press. Also, think about a typewriter — there is a reason it was so purposefully named. It has individual characters printed onto metal rods that when pressed will stamp that character onto a piece of paper.

## Weight

Weight is the increase or decrease of the stroke on a type that results in it visually appearing heavier or lighter.

![Image of the word “type” with the contour of letter T traced to represent what stroke means in Typography](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/xtcas3olwtptrdhv5gfm.png)

Stroke of Type

## Style

Style can be considered things like italic, regular versions of a type. It is also acceptable to consider the various weights of a Type to make a new style.

## Font

A font is a particular variation of a typeface’s weight and style.

Another thing to note, since the invention of desktop publishing is font also refers to the actual font files on the computer. So working within digital design people would see the word font and not typeface. In addition, many programs from that time until now use the word font. They combined the picking of a typeface and font into one action.

These are examples of fonts from a typeface like Roboto:

* Roboto Thin
* Roboto Light
* Roboto Regular
* Roboto Bold
* Roboto Black

![Fonts available in google fonts for Roboto](https://res.cloudinary.com/echobind/image/upload/v1661872444/echobind_blog/sae6qvkgsbwvcd7tryp3.png)

Fonts available in google fonts for Roboto

## Font-Family

Font-family is the collection of Fonts.

The font-family of Roboto would be the collection of fonts like Roboto Thin, Light, Regular, Italic and Bold. There are more fonts in Roboto that we did not mention. And not all Typefaces have all these fonts in the font-family. But the main takeaway here is that Typeface is what we see its how we identify Type and Font is the variation of Type that we use.

What I have come to notice is people who have a background in graphic design, print, and sending designs to print may hear or use the word typeface. As opposed to those who mainly work in like software, web, or product design (UI/UX) may use the font. The division is not so clear cut, as camp A and camp B and I am surely not trying to promote that. Because I have heard graphic designers use, font and mean typeface. Product designers use, typeface and mean font. And developers use font-family and mean typeface. Hey, everyone does it.

Using the terms interchangeably is ok for the most part outside of print and type design. However, it’s good to know the difference so you can understand or use the correct terminology within the appropriate context. This will help you effectively communicate with people from all backgrounds and design disciplines. And if you need clarification or you think there is some miscommunication, just politely ask the person and talk it out.

I think this covers the design to design communication. But there is another channel of communication in product design where things can get murky and that is between designer and developer.

## Tip for working with developers

A designer may say “that font is supposed to be bold” and a developer may ask “what font-weight number is that”. The reason being as a designer you will see the Font listed by the description in your design tool.

![Font description listed in design tool showing all available font types in a font-family](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/mnviutgsgxli301wbwyc.png)

However, when a developer goes to use that Font in a project it may be referred to by number and not description.

So for example:

* Roboto Regular equals font-weight 400
* Roboto Light equals 300
* Roboto Bold equals 700

And there are numbers associated with the other fonts in the font-family as well from 100–900\. So if the developer asked that question and the designer does not know just ask them to see how that number corresponds to the font description.

Here is an example from Google Fonts.

![Google font download screen that shows font and their corresponding weight](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/eyarxculf8a1ylfdtzqy.png)

This is a question that sometimes comes up when designing for the web and even mobile. If you hear that question you will be prepared.

One thing that helps with the communication of typeface and fonts is a type specification. A Type specification can be provided to the developer within your Style Guides or Design System.

Here is an example of how to write a type specification:

* Typeface — Roboto
* Font-Family- Roboto Bold, Roboto Regular
* Heading: Roboto Bold — 40 / 44 ( 40 being font-size (aka type-size), 44 being line-height (aka leading) )
* Paragraph: Roboto Regular — 20 / 30

![Type specification listing the typeface, font family, size, weight, and leading needed.](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/crjjyol8lqcw8ujo2psu.png)

Sample image of type specification

The type spec will communicate information like the typeface, fonts (weights), and size. Along with other information like line-height (leading) and letter-spacing (tracking). Helping to smooth out the designer to developer communication.

## Wrapping up

So all in all, knowing the difference between type, typeface, font, and font-family will empower you to speak, a unifying design language.

Just remember:

* A typeface is how we visually identify a Type.
* A Font is a variation of Typeface’s style, and weight.
* And those Font variations are what we use and make up a font-family.

Will people still use them interchangeably between disciplines, industries, and languages? Probably. But will you still design awesome things at the end of the day? Yes. The main goal is not to bicker over terminology but to work as a team and design things that communicate.

There are hundreds of great typefaces to choose from and if someone says font it is ok. Regardless of the typeface or font you decide just remember the main function of Typography is the readability, legibility, and the hierarchy of information in Design.

Just pick a typeface, write good copy, and structure it well in your design and you will be on your way. Continue to be creative and enjoy what you do.

Keep Creating. Keep Innovating. Keep Designing.

---

[View on echobind.com](https://echobind.com/post/a-typeface-or-a-font-which-is-right)

---

# Reasons for Lo/Hi-Fidelity Mockups

> Feb 13, 2020 | When starting a project, visualizing what the design will become is just one piece of the puzzle.

_By Michael Dang · 2020-02-13_

When starting a project, visualizing what the design will become is just one piece of the puzzle. To help us get to that point, we rely on fast drafts of a wireframe to give us an idea of the layout.

This is usually done with either the old-school method of a pen and paper or a more modernized way with software like Adobe XD, Sketch, etc. Either choice will work just fine but I typically like to draw it up in an XD so that transitioning to the design phase is a lot quicker.

Speaking of the design phase, the high-fi mocks typically takes shape once the lo-fi mocks are signed off by the client. Here is where the creative juices are flowing and your design takes shape of the intended look and feel from the client’s vision. Again, software like Adobe XD, Sketch or even Photoshop will be perfectly adequate to get the job done.

### **Low-Fidelity Mock-ups**

Below is an example of a good old pen and paper low-fi. If I’m out in a client meeting and need to draw out the layout so we can get on the same page, I will use this method because it clears up a lot of questions when you have visuals.

As you can see, the vision of the layout gains clarity which is paramount because this is the foundation of how your app or website will eventually look and function.

![Layout Sketch](https://res.cloudinary.com/echobind/image/upload/v1661872447/echobind_blog/wem1l5rsyuu3kei8r9d7.png)

### **High-Fidelity Mock-ups**

This is the fun part. Designing the look and feel of what you and your client’s vision will ultimately become. The focus here will be purely aesthetic but never lose sight of the user’s journey and purpose throughout a project. Here you can see the rich colors, shapes and design elements of this app but if you look closely at the different elements and spacing, you can imagine how the lo-fi mocks were previously set.

![Wallet](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/fqlzblopdnz3yia1edng.png)

### **Take it up a notch**

If there is time in your project and the scope allows it, try to take your designs up a notch by animating some screens to really bring the app to life. Not only does this enhance the experience of the presentation but it gives the client an idea of how the app interacts whether it be with micro-transitions or animated icons, etc.

### **In Summary**

Having lo-fidelity mocks is crucial to setting the foundation of what the final project will eventually become. This gives clients an idea of the structure and flow while also setting yourself up nicely to fully focus on the high-fidelity design and enhancing the look and feel of the project.

---

[View on echobind.com](https://echobind.com/post/reasons-for-lo-hi-fidelity-mockups)

---

# How to Run React Native Apps on a Specific Device in the iOS Simulator

> It can be frustrating when the officially recommended method for doing a thing doesn’t work. Here are some steps and commands to help you get your React Native app running on your preferred device in the iOS Simulator.

_By Josh Buchea · 2020-02-10_

It can be frustrating when the officially recommended method for doing a thing doesn’t work. Here are some steps and commands to help you get your React Native app running on your preferred device in the iOS Simulator:

The [React Native Docs](https://reactnative.dev/docs/running-on-simulator-ios#specifying-a-device) recommend using the `--simulator` flag with `react-native run-ios`:

```javascript
react-native run-ios --simulator=”iPhone 11 Pro Max”
```

If you run into (like I did):

```javascript
command not found: react-native
```

Try running the script for iOS in your app’s `package.json` (often it’s `ios`):

```javascript
yarn ios --simulator=”iPhone 11 Pro Max”
```

In theory `npm` should work also, but I didn’t have any luck. Your mileage may vary:

```javascript
npm run ios --simulator=”iPhone 11 Pro Max”
```

## List Available Devices

List available iOS devices:

```javascript
xcrun simctl list devices
```

Available devices for iOS `13.3` on my machine:

```javascript
iPhone 8 (2FE6CAE2–4908–4464–884A-5DED11505CE4) (Shutdown)
iPhone 8 Plus (F2A473F7–1F48–48DB-A6A6–584253814AA6) (Shutdown)
iPhone X (8FC4167D-AC9C-4F90–825C-9FB7004D03BA) (Booted)
iPhone 11 (E7885A5A-0306–4243-A852–8E71A7B0A5CB) (Shutdown)
iPhone 11 Pro (13B1AF48-BDD5–4AD7–8D7C-F31F3CF97FF5) (Shutdown)
iPhone 11 Pro Max (9C3B2313–258B-4E79–86A3–275D6BB3D078) (Shutdown)
iPad Pro (9.7-inch) (1A094DA7-A246–47B7–9716–5D8A9190C563) (Shutdown)
iPad (7th generation) (E0E0E252–5B96–4D2B-BD98–7D9ED79756AD) (Shutdown)
iPad Pro (11-inch) (143BB411-E726–4048–98E5-F87F04DEDCC2) (Shutdown)
iPad Pro (12.9-inch) (3rd generation) (14EFAE0F-C4D2–49E3-B501–633CB3E7DD00) (Shutdown)
iPad Air (3rd generation) (2797C8B5-E8FC-428A-AA4A-81F500153DDA) (Shutdown)
```

## Add Devices

To add additional devices:

1. Launch Xcode

![Xcode dock icon](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872447/echobind_blog/th9cdhqw8cxogin8ajbu.png)

2\. Open Devices and Simulators (⇧⌘2)

![Screenshot of the Window menu in Xcode with Devices and Simulators selected](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872445/echobind_blog/eghphrxy0mwnbjfqgchr.png)

3\. Press Simulators Tab

![Screenshot of Devices and Simulators window in Xcode](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872446/echobind_blog/loigs0cspdgrab8cb5gb.png)

4\. Press plus “+” button in the bottom left corner  
5\. Choose a Simulator Name, Device Type, and OS Version  
6\. Press blue button labeled “Create”

![Screenshot of the “Create a new simulator” dialog in Xcode](https://res.cloudinary.com/echobind/image/upload/f_auto,dpr_auto/v1661872447/echobind_blog/mvlfqk5cs5dm1gaeg0at.png)

## Commands for Your Convenience

Here are some commands with yarn that are ready-to-use for your convenience:

```javascript
yarn ios --simulator=”iPhone 8"
yarn ios --simulator=”iPhone 8 Plus”
yarn ios --simulator=”iPhone X”
yarn ios --simulator=”iPhone 11"
yarn ios --simulator=”iPhone 11 Pro”
yarn ios --simulator=”iPhone 11 Pro Max”
yarn ios --simulator=”iPad Pro (9.7-inch)”
yarn ios --simulator=”iPad (7th generation)”
yarn ios --simulator=”iPad Pro (11-inch)”
yarn ios --simulator=”iPad Pro (12.9-inch)”
yarn ios --simulator=”iPad Air (3rd generation)”
```

## Note

There is currently no way to set a default device for the Simulator.

## Thanks for reading!

***To learn more about our React Native process at Echobind, visit our [React Native capabilities page](/services/react-native-app-development).***

---

[View on echobind.com](https://echobind.com/post/how-to-run-react-native-apps-on-a-specific-device-in-the-ios-simulator)

---

# Why Top-Notch Soft Skills Are Vital for Software Consultants

> Feb 07, 2020 | Here are a few ways soft skills manifest in a better reputation for our company.

_By Mike Cavaliere · 2020-02-07_

We routinely get comments from our clients like this one (actual quote):

_“I was just telling someone yesterday how much I’ve enjoyed working with Mike and Isaiah, and so has our developer, \[name omitted\]. They are doing good work, they communicate well, and they are personable. What more can you ask for, right? I’d love to chat with you about how you kick off projects internally though — I think we could learn from Echobind on that end, given how quickly the guys hit the ground running.”_

_\- One of our many, beloved Echobind clients_

This result is no accident. We look for excellent communication skills when hiring engineers, and we nurture it as a part of our company culture. It’s not enough to be a good coder at Echobind; you need to be a good communicator. You need to be empathetic to your clients. You need to keep their business goals in mind and adapt to their personalities.

Here are a few ways soft skills manifest in a better reputation for our company:

## Clients don’t worry that they’re wasting their money.

Our people proactively communicate and don’t sit on their hands. If they’re blocked on a task, they escalate it; if no one can unblock them, they get moving on another. We’re not getting paid to sit around, nor are we the type of people that like to sit around. We’re builders, strategists, and product-focused technicians.

Our clients realize this soon after starting to work with us. Pretty quickly, they inevitably trust us in the same way they would a salaried member of their team. After all, they’re not paying us so that they can waste their time keeping tabs on us; they’re paying us _to save them time and money_ by doing the engineering work they either don’t have the time, expertise or bandwidth for.

## Clients thank you for preventing problems.

We’re always proactively thinking about their businesses and alerting them about the potential risks we see.

Sometimes we’re able to do this because we’ve got more knowledge in our respective domains (people often hire us because of our React and React Native experience, for example), so we notice problems that aren’t obvious to those with less expertise in said domains.

At other times, this is possible simply because we’re acting as another set of eyes that isn’t part of the same team day in day out. Regardless of why we proactively alert clients to potential future problems.

Maybe their software’s dependencies are out of date, which increases their tech debt and will haunt them in the future; perhaps it’s a foreboding security vulnerability or performance challenge that will come as they grow their codebase.

Whatever the case, our people don’t resist the urge to speak up and alert everyone about these challenges. Saving the client pain (either near or far) down the road is good karma all around.

## Clients aren’t afraid to confide in you.

Clients and human beings in general, are more inclined to tell you things of a sensitive nature when they’re comfortable with you. Building a deep sense of trust with your client gives them the confidence to let you know what might be going on internally at their company, which can affect how you do your work. There might be an upcoming change of management, a pivot in technical direction, or anything that could affect the trajectory of your project.

Or maybe there are members of their team who are struggling silently, knowing this could help you as the consultant give that team member a bit of extra support. Good software consultants aren’t code monkeys; they’re outside engineers who become deeply embedded members of your team, even if just for a short time.

In summary, if you’re a software consultant or individual freelance engineer, make sure you’re thinking of the client, and getting them to enjoy working with you and talking to you. The benefits for both you and them are huge.

---

[View on echobind.com](https://echobind.com/post/why-top-notch-soft-skills-are-vital-for-software-consultants)

---

# 3 Shortcuts We Use to Make Decisions — Part I

> Feb 07, 2020 | Humans and animals use shortcuts constantly to make decisions. These shortcuts often are made with the unconscious or irrational part of our brain — this is known as our inner elephant.

_By Anne Tolmie · 2020-02-07_

Throughout time, people have warned against using shortcuts.

Like this…

> There are no shortcuts to knowledge, especially knowledge gained from personal experience. Following conventional wisdom and relying on shortcuts can be worse than knowing nothing at all. — **Ben Horowitz**

And perhaps for good reason…

Humans and animals use shortcuts constantly to make decisions. These shortcuts often are made with the unconscious or irrational part of our brain — this is known as our _inner elephant_. Behavioral economists refer to these shortcuts as _heuristics_.

_Heuristics_ are mental shortcuts to aid in decision making and problem-solving. Think of them as a rule-of-thumb to make life easier for us (Thaler & Sunstein, 2009).

But — Heuristics also have a dark side. They can lead to systematic biases (Thaler & Sunstein, 2009).

To address any problem, you must first become aware of it. The unconscious must be brought to the conscious.

Today I am going to go through _one_ of three heuristics — the problems it can cause and what you can do to train your inner elephant.

## Anchoring and Adjustment

The [_anchoring and adjustment_](https://en.wikipedia.org/wiki/Anchoring) _heuristic_ is where people start with a suggested reference point and make adjustments.Let’s learn more through four examples…

### 1\. Guess Again

Let’s say I asked you to guess Shakira’s age. You would likely begin by using your age as an _anchor_ and _adjust_ her age based on whether she was older or younger than you. This is fine because you know your age (hopefully).

But, let’s say I told you, Jennifer Lopez’s age is 43 _and then_ asked you to guess Shakira’s age. You would most likely use J.Lo’s age as an anchor and guess that Shakira was younger than 43\. (For the record — both these women were amazing and after the Super Bowl halftime show, I googled that J.Lo is 50 and Shakira is 43 — beautiful).

Hopefully, this little example showcased the problem with anchoring and adjusting. If the anchor is initially wrong, the adjustment is likely incorrect.

#### How to Train

If you are going to continue to blindly guess, be okay with being wrong. Otherwise, fact-check your anchor/starting point. Don’t assume the anchor is true.

### 2\. Question Questions

Anchoring also influences answering questions. If two questions are asked, the order in which they are asked influences the response.

This was tested on college students. They were asked the following two questions:

1. _How happy are you?_
2. _How often are you dating?_

When the order was reversed, the students used how much they were dating — the anchor, as a way to measure their happiness — the adjustment (Thaler & Sunstein, 2009).

This makes you second guess every satisfaction survey you have ever taken, huh?

#### How to Train

Consider the order of the questions. If you have a hunch that some nudges are going on, try reordering the questions and see if you would answer differently.

### 3\. Here’s a Tip

Anchors are also seen at your local coffee shop. Upon payment, a series of suggested tip amounts are shown. _This is not an accident._ This is a nudge to leave a default tip. Now, if the person is providing excellent service, _yes_, this is great. But — what about the burnt-out barista that can’t be bothered to smile and gets your order wrong?

![FastCompany screenshot](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/ffz9dcx6cgeuguwhfl8q.jpg)

[source](https://www.fastcompany.com/3022182/how-square-registers-ui-guilts-you-into-leaving-tips)

#### How to Train

Use the C_ustom Tip Amount_. Decide for yourself what is affordable, what is reasonable, and what the person earned, but keep in mind that working in the service industry is hard.

### **4\. Ungroup**

At Echobind, we are well aware of the anchoring and adjustment heuristic. Poor estimating can be catastrophic to a project. People have a tendency to be overly optimistic about what they can achieve and tend to underestimate how long a task will take. This is especially true when estimations are provided in group discussions. Person one will give their estimate, and then person two will use person one’s estimate and a point of reference and adjust their estimate.

#### **How to Train**

Avoid group discussions when estimating. When we estimate projects at Echobind, we have our team provide their estimates individually and separately. That way no one is influenced. We unanchor the anchor. By doing so, we find our estimates are more accurate, resulting in smooth sailing for our projects.

That concludes Part I. I encourage you to look for the _anchoring and adjustment heuristic_ in your own life. Join me for Part II, where we will go through the second heuristic.

**Sources**

[Thaler, R. H., & Sunstein, C. R. (2009). _Nudge: improving decisions about health, wealth, and happiness._ Rev. and expanded ed. New York: Penguin Books.](https://www.goodreads.com/book/show/3450744-nudge)

---

[View on echobind.com](https://echobind.com/post/3-shortcuts-we-use-to-make-decisions-part-i)

---

# React Native iOS Splash Screen with Storyboard

> Feb 05, 2020 | In June 2019, at WWDC 19, Apple announced that as of April 2020 it would be a requirement to use Xcode’s storyboard to create your splash screen.

_By Jenn Robison · 2020-02-05_

In June 2019, at WWDC 19, Apple announced that as of April 2020 it would be a requirement to use Xcode’s storyboard to create your splash screen. This was a surprise to me when I saw a [tweet](https://twitter.com/cball%5F/status/1218894883492069376?s=20) from our very own [Chris Ball](https://echobind.com/team/chris-ball), this past month. As a React Native developer, I have been using [react-native-splash-screen](https://github.com/crazycodeboy/react-native-splash-screen) for the past couple of years; which relies on `.xib files`.

At first, I was a little concerned, just one more thing to add to my to-do list, yet a very important one that could keep us from launching our React Native application to the App Store. After my initial reaction, I realized we had a couple of months to figure this out.

When I decided to spend a little time to see how difficult this might be I did not find a lot of documentation for a non-native developer. One of the allures with React Native is that you don’t have to know the nitty-gritty for both iOS and Android, but it can also mean we aren’t as comfortable with some of the tasks that require us to dig into the native side. Spoiler alert, it wasn’t as difficult as I expected, once I figured out the secret. Here is what I learned!

![Existing project with a .xib Launch Screen](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/uoxe6j4jr9h6omscxi1g.png)

I started with a React Native project in which I already had a Splash Screen that was a `.xib` file. I opened up my project workspace in Xcode and started to Google for how to use Storyboard. Honestly, I was NOT finding anything that was helping me. I found articles on the developer site that told me about [Launch Screens](https://developer.apple.com/design/human-interface-guidelines/ios/visual-design/launch-screen/) and the Human Interface Guidelines, but not how to create it. A little further down in my search results I found a [Stack Overflow](https://stackoverflow.com/questions/37951817/launch-screen-storyboard-with-centered-image-ios) article which I thought had promise.

![Adding the Storyboard File in Xcode](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/apldmqlnuhkcdtkhians.png)

Great! I created my Storyboard file! By default, it set me up with the name of my Application and the Copyright footer. Here is what I had as a starting point with my storyboard. But what next? How do I add my image?

![Storyboard default](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/kz4ih75xlracl7aphto2.png)

That initial Stack Overflow article I found confused me, it was outdate for an older version of Xcode and I was not finding the options right off hand. I took to my usual style of learning which is to just explore and figure it out. I ended up discovering the `+` icon in the upper right menu bar and BINGO I was moving forward again.

![Adding image to my Storyboard](https://res.cloudinary.com/echobind/image/upload/v1661872447/echobind_blog/cdlj5l3ddosoi4jwycp7.png)

![Echobind logo on iPhone](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/bh5v1rxwbyjanp0lnbe8.png)

To add the image to your storyboard you drag the item from the left on to your canvas. Once it is there you can start to manipulate it. For demonstration purposes, I have a drastic difference here with the background white and a large image. You can see it here on the iPhone 11.

![Echobind logo with SpalshScreen next to it](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/kypamzzre1jrytm6e0gr.png)

But if I were to change my display, to say an iPad, things start to look really off! The image we imported is now in the upper left of the iPad display, I see the text I was not seeing before and obviously this is not a consistent user experience based on different devices. Let’s look at how we can make our Splash Screen a consistent experience across devices!

To ensure we have a consistent look we will want to add constraints. Many properties can be used to fine-tune your storyboard, but we will keep it simple.

In the bottom right of the storyboard window, you will find a few icons which I didn’t immediately see in dark mode. The simplest constraints we can add are for horizontal and vertical alignment.

![Adding constraints for alignment](https://res.cloudinary.com/echobind/image/upload/v1661872447/echobind_blog/ovywkdmlf0prfjwevpz5.png)

Once I have applied these constraints you can see that I now have the cross hatches displayed on my storyboard to show the view is locked into these constraints. You can also see that when I changed my view back to the iPhone 11 that my image stays where I expected.

![Constraints applied and visible on iPad and iPhone](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/h0rgjjbqaozxhprajyyl.png)

These are just the basics of using storyboard! You can get much more detailed with your text and images while creating a consistent user experience across devices.

The final step to replace your previous Launch Screen is to ensure that your new file is set as the Launch Screen File in the general settings of your project. In my case the previous file was `LaunchScreen.xib` and for the new file I used the default name which set it to `Launch Screen.storyboard`. This wasn’t super clear in making the update, as you can see it does not display the file extension. Once you select the new file make sure you reset your bundler cache and clean your build or you may go crazy thinking that your changes aren’t working.

![Select your new file as your Launch Screen in the project settings](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/g44cip5qlfjvpuxslj6v.png)

After I went through this the first time I decided to take what I learned and apply it to another project. Great news, I was able to accomplish this within a matter of minutes! My hope is that with this knowledge, you will be able to accomplish this task just as quickly.

***Learn more about our [React Native capabilities](/capabilities/react-native-app-development).***

---

[View on echobind.com](https://echobind.com/post/react-native-ios-splash-screen-with-storyboard)

---

# Trust me…

> Feb 04, 2020 | “Trust me…” It may come to you as a surprise but these words can have a very negative connotation in the workplace.

_By Matt Thompson · 2020-02-04_

## Trust me…

**_Trust:_** _a firm belief in the reliability, truth, ability, or strength of someone or something._

**“Trust me…”** It may come to you as a surprise but these words can have a very negative connotation in the workplace. It sparks a very different emotion from person to person and should be used with caution. Some people have trust issues. Some people have been burnt.

You can help negate this by:

* Actively listening
* Being open to opinions
* Being honest in your response
* Being reassuring
* Building confidence

### Backstory

I was recently having lunch with an old colleague celebrating a new job when this topic came up. Asking what he enjoyed the most about the transition and his new job, a one-word response was given, _“Trust”_. The discussion continued as we both re-lived old wounds from previous employers that ended with what seemed to be a silver lining. We both agreed it was nice to work in a place knowing the co-workers and company have your back. It’s that continued **_reassurance_** that brings a sense of peace. This trust plays into our entire mental psyche, our motivations, actions, and willingness to be. Its human nature really, why would I help support something that continues to weigh me down. It can give us all a pessimistic side that continues to ask _“Why should I trust you?”_

### “Why should I trust you?”

This leads to one of our core guiding principles here at Echobind. **_Transparency_**

Trust is built around being **_open_** with one another. An understanding of both parties and the expectations within. I can trust you because you are **_actively listening_** to my concerns. I can trust you because you are being **_honest_** with your response. I can trust you because I know my voice matters.

Here at Echobind if something doesn’t feel right in our day-to-day, it gets called out. It’s a work family, and as with any company/family, we have our differences. **_Trust doesn’t always mean you agree_**. It means you understand one another, I know where my colleagues are coming from. I understand the support they need to succeed. Trust is knowing we are all doing our part to do just that, **succeed**. When this plays out, we are each **_confident_** in our own abilities to reach down and help another. This builds synergy and momentum and is extended beyond our company. Impacting families, communities, and other organizations as our team adventures life.

As an agency, it’s our job to place this same trust and confidence within our clients. _Why should you trust us?_ It’s simple, As a developer, you can trust me knowing I have the support of my team. When working with one of us, you are working with all of us. We aim to carry the aforementioned core values over to you and your team. Actively listening to your problems, while providing honest feedback. Our goal is to remain open and reassure you each step along the way. We take all the positive energy from our team and pass to you the same confidence instilled in us. It is our job to make sure that with each decision you make, you continue to feel inspired and supported. While we have our differences, we each aim to succeed. You trust us because you realize you are not alone.

---

[View on echobind.com](https://echobind.com/post/trust-me)

---

# Reasons to Use Animations in Mobile App Designs

> Feb 02, 2020 | Mobile app animations are what give life to the overall design. It creates a unique sense that a static design surely cannot.

_By Michael Dang · 2020-02-02_

Mobile app animations are what give life to the overall design. It creates a unique sense that a static design surely cannot. For example, a smooth parallax transition going from one screen to another or a simple micro-transition of a burger menu turning into an “x” creates a truly interactive user experience.

Not only does this enhance the aesthetics of the design but there are lots of functional usages that can be created from these animations. Below is a list of examples that showcase this.

## Transitions

Transitional animations like this onboarding app for the UMA’s adds a simple, refined feel. Notice how each swipe introduces a new screen with multiple micro-transitions. The header text flows in from the right, which simultaneously moves with your finger while you’re swiping that direction. The data/secondary elements come in with its own set of progressing animations and the subtle background has a growing parallax effect that ties up everything nicely.

Doing all of this correctly with the right blend of animations will yield positive experiences for the user.

![Cellphone displaying Universal Music Artists app](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/fw4phsfrvypkfg1fde3v.gif)

## Pull-to-Refresh

A common yet great way to show off refreshing a screen to load in new data is the pull-down interaction. [This example](https://dribbble.com/shots/5952059-Preloader-to-refresh-animation) shows how intuitive it is to just swipe down, hold for a second and release. A set of squares animates and shows progression while the cards below have a general wireframe that depicts the upcoming content that is being loaded in.

## Notifications

This is a tricky one. The idea is to have a great looking design and animation that is not obtrusive. Usually, we’re prone to seeing modals that overlay the entire screen or a banner graphic that is taking up half the real estate. Both instances give the user a negative experience.

We can fix that by doing something like the example below. Notice how soft and light the notification comes in. It has a graceful animation that gives off a non-obtrusive feel. The design itself further helps that with a subtle drop shadow.

![Tim Cook calling gif](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/vj7ixqwvq1glwrgjhccd.gif)

## All Out Eye Candy

This is the ultimate goal and to flex on how your app is better than most. Combining intuitive functionality with beautiful designs and sick animations while having all phases work in unison is the holy grail. Below you’ll see how bringing these elements together truly creates a wonderful experience that will surely keep the users engaged throughout the app.

![Tesla Model3 app](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/ywno29z6bngdiefrpbvu.gif)

These are just one of many ways you can incorporate animations into mobile design. Always ask yourself why you’re adding interactions and if it’s creating a positive or negative experience. A few advantages of adding animations are to increase usability, provide feedback to the user, save screen space, create an immersive atmosphere, and ultimately bring your designs to life.

---

[View on echobind.com](https://echobind.com/post/reasons-to-use-animations-in-mobile-app-designs)

---

# Yes, Your Team Needs Pull Request Templates

> Jan 29, 2020 | Pull Request Templates will nudge your engineers to fill out some information before submitting a Pull Request.

_By Echobind Team · 2020-01-29_

Imagine, you’ve recently hired a new engineer to join your team. During their first weeks, they are pouring over your projects’ repositories and trying to make sense of the codebase when they consistently stumble onto this message:

![Pull Request with the description: No description provided](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/eidr4x9zsvdiog2ya6mp.png)

Pull Request with the description: “No description provided.”

That’s not very indicative of what changes were made, or what the code does. Let’s go ahead and fix that by adding a Pull Request Template that will nudge your engineers to fill out some information before submitting a Pull Request.

## What is a Pull Request template?

_A pull request template is a file containing markdown text that is added to your pull request description when the pull request is created._

Essentially, the template is a bunch of text that developers don’t want to write each time they submit code. Having these templates reduces their cognitive load, thus speeding up the entire process.

## How to create a Pull Request template

1. Go to the root of your project directory and create a .github folder.
2. Create a file and name it PULL\_REQUEST\_TEMPLATE.md (case doesn't matter, but the file needs to be named this exactly for GitHub to process it)
3. Copy & paste this into PULL\_REQUEST\_TEMPLATE.md (this is one of Echobind's default [templates](https://github.com/echobind/pr-templates))

Description of PR that completes the issue here...## Changes<name\_of\_repository>: - Description of changes## Screenshots (prefer animated gif)## Checklist- \[ \] Requires migrations?- \[ \] Requires dependency update?- \[ \] Automated tests- \[ \] Looks good on large screens- \[ \] Looks good on mobileFixes #

4\. Save the file, commit, and merge it

The next time a Pull Request is created a template will appear. ✨

## Conclusion

Imagine that same new developer cruising through your project’s code, having enough context to gain a better understanding of your codebase, all because of a template.

Feel free to browse our current Pull Request templates that we use on our projects!

<https://github.com/echobind/pr-templates>

---

[View on echobind.com](https://echobind.com/post/yes-your-team-needs-pull-request-templates)

---

# (Some of) The Magic of Having a Distributed Team

> Jan 24, 2020 | A few years ago people viewed remote working as a trend, but we’re seeing more and more companies welcoming remote workers or opting to have fully distributed teams — so it seems this trend is actually here to say.

_By Sarah Case · 2020-01-24_

A few years ago people viewed remote working as a trend, but we’re seeing more and more companies welcoming remote workers or opting to have fully distributed teams — so it seems [this _trend_ is actually here to say.](https://buffer.com/state-of-remote-work-2019)

Remote work isn’t for everyone, nor is it for every company. That being said, Echobind is a 100% distributed team, and here are a few reasons why we love it:

* We get to recruit from a wider **_talent pool._** We can hire the best and brightest designers, developers, project managers, and operators because we aren’t limited by geography. All we require is a reliable, fast-speed internet connection in the US.
* We appreciate the wide variety of backgrounds and experiences our team brings, which in turn leads to **_diversity of ideas and perspectives_**.
* **_Nobody is commuting_**! We aren’t spending hours sitting in cars or trains just to get to and from work each day. That’s precious time we get back for so many things — more family time, more sleep, more exercise. Before I joined the Echobind team, I was commuting over 3 hours a day, which is 15 hours a week = 750 hours a year = 31 days per year. Getting that time back is gold.
* Working from home (or the occasional co-working space or coffee shop) means that each of us gets to work in an **_environment where we feel most comfortable and productive_**. Each of us gets to customize our workspace to suit our needs and preferences.

As I already mentioned, working remotely isn’t for everyone and it certainly presents unique challenges. Thankfully, we’re able to solve for many of them with the right tools (a few of which you can find in this blog post about [onboarding](https://echobind.com/post/onboarding-is-like-hosting-a-party)).

P.S. You’ll note I said we’re a _distributed team_ instead of a _remote team_ because while we don’t work side by side in an office, we don’t feel remote because we’re constantly collaborating. We might be physically far apart, but we’re still very much connected.

![Screenshot of a remote definition from a dictionary](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/nnpisbdx9mvru8rvm8c4.png)

---

[View on echobind.com](https://echobind.com/post/some-of-the-magic-of-having-a-distributed-team)

---

# 3 Tips to Keep You Motivated in 2020

> Jan 23, 2020 | The first month of 2020 is nearly over. How are you doing on your New Year’s Resolutions?

_By Anne Tolmie · 2020-01-23_

The first month of 2020 is nearly over. How are you doing on your New Year’s Resolutions?

Personally, I am not one for New Year's resolutions. It is too much pressure and the hype usually begins to wear off about now. Today I am going to share with you three tips to keep you motivated all year long.

## 1\. Renew your goals on a cadence that works for you.

Set it and forget it? No way. Goals require a commitment and if you want to be successful, you should build check-ins — you’ll track progress and adjust as needed. Personally, I renew my goals on a monthly cadence with each new moon. Need more accountability? Do it weekly. Less? Try quarterly. Do what works for you.

## 2\. Break your goals down to fun-size.

A behavioral principle I tend to follow is _less effort, more behavior._ I am more likely to achieve something if the goal is attainable. Achieving can be fun when you are meeting your goals. For example, let’s say you want to work out 5 days per week in 2020\. If your baseline for weekly workouts is currently 0 workouts/week, I would suggest the following plan of action:

_January-March: 2 workouts/week_

_April-June: 3 workouts/week_

_July-September: 4 workouts/week_

_October-December 5 workouts/week_

At first glance, this does not look scary or daunting — it looks doable! By breaking your goals down — they become doable. You do the desired behavior over and over while slowly increasing the effort. This creates a habit and a lasting behavior change. Simple, but effective.

## 3\. Set up nudges to help you win.

What’s a Nudge? To put simply …

A nudge is an easy intervention that alters people's behavior in a predictable way without making something off-limits _(_[_Nudge: Improving Decisions About Health, Wealth, and Happiness_](https://en.wikipedia.org/wiki/Nudge%5F%28book%29)_)._

Think of it as a gentle reminder to help you succeed. It could be something as simple as putting your healthy snacks in the front of the pantry so you see those first, or keeping a checklist on your phone or in your planner (like me). Ultimately, it should be designed to help keep your goals top of mind.

And don’t be shy of using technology — we’re seeing nudges in all types of apps these days. An awesome example is [Noom](https://www.noom.com/#/) — I’m using it as part of my 2020 goal to make better food choices and move more.

![Person making a checklist](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/c7dnctmmvbblxkdr6ekp.jpg)

As a behavioral science subject matter expert, I want to double click into nudges and geek out over [Noom](https://www.noom.com/#/). They are excelling on the nudge front. Let me show you how they are nudging me towards my best self.

## **A Quick Review of Noom**

### Better Food Choices

![Noom](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/fjrnzc5c8i6dxict5v8s.jpg)

Noom makes eating healthy easier through awareness by categorizing your foods into three colors — green, yellow, and red.

Green — They gently nudge you toward the green foods by giving you socially mediated positive reinforcement — (Great choice!-Enjoy) and not setting any limits.

Yellow — They recommend moderate portions of yellow foods but also understand that most of your foods will be yellow because “_we are not rabbits_” (Noom).

Red — They don’t say red foods are off-limits. They suggest to limit them while providing a recommendation based on your goals, body, etc. This is pretty smart on their part— deprivation actually temporarily increases motivation for the item you are depriving yourself of, and that is why so many diets fail.

And if you do go “over budget” — nothing happens other than they are glad you logged your food. They show you a streak of how many meals you have logged to keep you motivated. The idea is to become more self-aware of your eating habits, not shame you.

### Move More

![Screen with total steps](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/e4lm3ghhqqliiqzopstf.jpg)

Noom motivates me to move by encouraging me to get my steps in (I’m horrible at stepping away from my screen, although it is recommended that you get up and move every hour).

They start by making the goal easy to achieve (less effort — more behavior). I started at 2,000 steps. The next day, my goal increased by 150 steps. The idea is that my step goal will slowly increase until I reach 10,000 steps, which is the recommended step count to be considered active and healthy.

There are many behavioral science studies that support this. Fun fact — I replicated a study during my graduate work. In fact — just giving someone a pedometer will increase daily steps (Noom).

This stuff (behavioral science) works. Sometimes you just need a gentle nudge to help you win. Thanks, Noom.

Keep in mind there are many ways to leverage nudges to help you. Noom is just one means to an end. A nudge could be as simple (and free) as a calendar reminder to drink water. In addition to setting up nudges, don’t forget to renew your goals on a cadence that works for you and break your goals down to fun-size. I hope these tips are helpful. Feel free to leave me a comment.

---

[View on echobind.com](https://echobind.com/post/3-tips-to-keep-you-motivated-in-2020)

---

# Optimizing your Android Build for React Native

> Jan 21, 2020 | Are you familiar with the Hermes Engine for Android that came out with the release of React Native 0.61? Here are some tips on how to get both of these things working in your React Native project to help optimize your Android builds.

_By Jenn Robison · 2020-01-21_

Have you seen the call to action in the Google Play Console? The one that lets you know that you should be using the bundle (.aab) format, instead of the APK. Are you familiar with the Hermes Engine for Android that came out with the release of React Native 0.61? I will share some tips on how to get both of these things working in your React Native project to help optimize your Android builds.

Recently I got this message with a note stating I could reduce the file size by an estimated 60.1% and I decided I should dig back into the Android bundle after the missteps I previously had with them and React Native.

![Call to Action from Play Store Console](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/igldnzxcxspbbsicxqbb.png)

So what were those missteps I experienced previously? After attending [Chain React](https://cr.infinite.red/) in July of 2019, I was stoked at the announcement of the Hermes engine to be released with React Native 0.61\. [Facebook](https://facebook.github.io/react-native/) followed up with a[ blog post](https://facebook.github.io/react-native/blog/2019/07/17/hermes) about this announcement and how you could take advantage; I was sold and decided I was ready to dig in. While we were at it, I decided we should work on figuring out those Android Bundles. At the time, the project I was working on was about a 50MB APK.

After enabling Hermes and creating my first bundle everything seemed to be working great locally! We uploaded successfully to the Play Console with much anticipation with our significantly reduced file size, sent to our users in our Alpha test group and experienced our first letdown: the app would NOT load. The users were able to successfully download the app from the PlayStore but it would never get beyond a white splash screen, just hanging out there with no feedback. Such a disappointment. We weren’t sure if this was to do with the bundle or Hermes at the moment.

Of course, we were mid-release cycle without a lot of time to explore what was going on. I attempted to figure out the bundle but struggled at the time with how to test that `.aab` file without uploading to the Play Console to discover it to still not be working.

Fast forward about 6 months, seeing that Call To Action I had a conversation with my manager and decided it was time to figure out this bundling. I was not going to let it hold me back again. It’s amazing how you can come back to a problem with a fresh set of eyes, and of course months of additional experience under my belt, to knock it out of the park.

Here is what I learned and how you can take advantage of the Hermes engine, Android bundle, and test and verify that bundle locally!

The first step is to enable Hermes. This is a pretty simple change, toggle the boolean configuration in the app/build.gradle; however, you MUST clean and rebuild the app or it won’t take effect due to caching. This can be accomplished with the gradlew clean command. I have created a convenience script in my package.json in order to help facilitate this.

Here is my build.gradle file along with the package.json snippet.

![Hermes enabled in app/build.gradle](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/dhatwuo1p6qo8l8ob4qu.png)

![package.json scripts](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/vl2j10lzo0n4kk5lamvy.png)

After you run the clean you can run a build that has now enabled Hermes!

Next up is the Android bundle. Again, this is a pretty simple change in how you create that Release variant for your React Native builds. In the past, we have used `gradlew assembleRelease` which generated our APK file that we uploaded to the Play Console. In order to bundle you simply change that command to be `gradlew bundleRelease` this will then generate that bundle .aab file. Where it fell apart for me in the past was then deconstructing that bundle back to an APK that I could install to a [bundletool](https://developer.android.com/studio/command-line/bundletool) from Android, although I felt like the documentation was a bit lacking in its actual usage. This time I was prepared to settle in for the long haul and figure it out. Previously I had followed the [tip](https://developer.android.com/studio/command-line/bundletool#download) to download the bundletool which sent me to the GitHub repo and a list of jar files. Of course, I downloaded the file and then I will admit, I got a bit lost in how to use it.

This attempt I figured there had to be a way to install bundletool in which I could call it locally with a PATH variable defined. A quick Google search led me down the path of a [Homebrew](https://brew.sh/) package for bundletool. A simple `brew install bundletool` and I was on my way!

Well, then what? Again not great documentation that I could find on how to take my bundle and create the APK I could install locally. Eventually, I settled on a couple of commands I could use to do just this. I have my bundle command, generate APK command which takes the bundle and creates that associated APK, followed by install APK which will install to a connected device or emulator. Here is what has worked for me:

```javascript
 "scripts": {
"android:bundle": "cd android && ./gradlew app:bundleRelease && cd ..","android:gen-apks": "bundletool build-apks --bundle=./android/app/build/outputs/bundle/release/app.aab --output=./bundle/myapp.apks --ks=./android/app/android.keystore --ks-key-alias=homehero-release","android:install-apks": "bundletool install-apks --apks=./bundle/myapp.apks",
}
```

Perfect, I was now able to verify my bundle locally. I discovered I still had the same issue of a white splash screen being present. This was 6+ months later and a completely different project. Again, it was time to take to the power of a search and figure out what was going on. After a little time, I discovered this was a known problem with [Hermes enabled](https://github.com/facebook/react-native/issues/26400#issuecomment-539395814) and if I set my `resolutionStrategy` for SoLoader then it would hopefully resolve. Thank you to GitHub issues and [Alaa-Ben](https://github.com/Alaa-Ben) for a well-documented issue! I updated my `app/build.gradle` file once again to include this and took to testing and validating locally with great success. Finally, I had confidence in uploading a bundle to the Play Console for consumption by my users. I have noted that the SoLoader version bump will be included in the [React Native 0.62 release](https://github.com/facebook/react-native/blob/0.62-stable/ReactAndroid/gradle.properties), I have seen it in the Release Candidate. In the meantime, this little fix will help move you forward with optimization.

The final test was to upload to the Play Console to determine just how much my file size was reduced with this bundling. This is just a small example of the improvement you could see, this does not include any performance benchmarking with the implementation of the Hermes engine. With our new bundle created and uploaded for this project, we went from a 21+MB APK to a \~7MB download size with the bundle. That is a \~69% reduction in file size!

I hope that my fellow React Native developers can benefit from my learnings and start to realize the benefits of these optimizations, as we have.

***Learn more about our [React Native capabilities](/capabilities/react-native-app-development).***

---

[View on echobind.com](https://echobind.com/post/optimizing-your-android-build-for-react-native)

---

# Product Design ft. Hello, Startup — the Visuals

> Jan 20, 2020 | In this installment of the Hello Startup series, we’ll go through the next stage which focuses on the visuals and how we present to the user.

_By Ashley Nelms · 2020-01-20_

## Product Design ft. Hello, Startup — the Visuals

[In the previous part of this series](https://echobind.com/post/product-design-ft-hello-startup-the-user), we dove into the beginning stages of product design with [Hello Startup](https://www.hello-startup.net/): user-centered design. In this installment of the series, we’ll go through the next stage which focuses on the visuals and how we present to the user.

### Visual Design

![15th century German coats-of-arms](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/a7cbbnzltotwsuxf3zio.jpg)

_15th-century German coats-of-arms. Via_ [_Wikipedia_](https://en.wikipedia.org/wiki/Coat%5Fof%5Farms)

People have been doing visual design for some time now, or should I say a long time. Have you ever thought of a coat of arms as being visual design? It was developed in northern Europe in the mid-12th century for the purpose of identification. It evolved into representing family descent, alliance, profession and more.

The coat of arms became a symbol of recognition that was memorable and could leave such an impression that it could instill fear on the battlefield.

In this part of the chapter, Hello Startup introduces us to the techniques that will help us get started in creating designs that will be memorable and leave an impression on those who see it.

Before diving into anything complex its essential that one becomes familiar with basic visual design skills.

### 1\. Copywriting

Since most people think of design as colors, animations and pictures it comes as a surprise to novices that copywriting is a part of it.

_… the real core of almost all software design is is actually text. In fact, you could remove the colors, borders, pictures, and just about everything else from most applications, and as long as you left the text, it would probably still be minimally usable._ 
**_— Yevgeniy Brikman | Hello, Startup_**

It’s not that the other elements don’t matter, but users get most of their information in the titles, menus and so on. This is why Hello Startup suggests that when doing visual design, copywriting should be the first priority. Take the time to think about what you’re going to say to the user and how — remember our discussion on emotional design from the last part of the series?

It’s common practice to design with the usual filler text “lorem ipsum”. Because of this, we end up focusing on the text that will fit the mold we’ve shaped instead of focusing on _“writing a message that resonates with your audience.”_

### 2\. Design Reuse

![Screens from successful mobile apps](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/yzuekvrihozeo6sy5v2b.png)

Screens from successful mobile apps. Via [Adobe](https://xd.adobe.com/ideas/principles/app-design/11-screens-youll-find-many-successful-mobile-apps/)

When it comes to design, especially if you’re new, don’t try to reinvent the wheel. If you were to observe various applications and websites you’ll begin to notice common design patterns. When you know something works take advantage of that.

That’s not to say your whole project should be a copy and paste of someone else’s work, but by mimicking others and eventually reusing your own designs you not only learn but also save time. This might sound familiar if you’ve read the [first part of the series](https://echobind.com/post/building-products-ft-hello-startup) for product design. _“Copy, transform, and combine are the basis of all creative work.”_ Do a bit of searching on [Dribbble](https://dribbble.com/) and you’ll notice some similarities while the designs still maintain their own sense of identity.

### 3\. Layout

A good layout arranges what’s on the screen in a way that conveys useful information to your audience. We’ve become so accustomed to it that it’s not something we think about anymore until we have to build it ourselves that is. Let’s use LinkedIn as a reference for the next two points.

One of the aspects of design is _proximity_ which _“indicates if elements are logically related or not.”_ This means unrelated elements should be further apart. The other aspect is _alignment_ which _“allows you to communicate that there is a relationship between elements.”_

Below is a comparison of what LinkedIn looked like in 2010 and what it looks like now. Just at a glance, there is a significant improvement — the call to action is more prominent, the information is condensed and the summary (about) is closer to the top. The human mind can only process so much information at once. With the old version, a lot of information had to be consumed before you could get what you want or even see the user’s experience history.

![Screenshot of a LinkedIn profile](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/aqdvlvnriuy4bstig2nf.jpg)
_[Source](http://web.archive.org/web/20100403055925/www.linkedin.com/in/davidssmith)_

### 4\. Typography

Hello, Startup describes typography as the art and science of arranging text so that it is arrangeable and beautiful. As with layout, typography has its own essential aspects.

**Measure** refers to the length of each line. It’s not about the abundance of information but how it’s presented to the user. Margin, alignment, and characters per line all play a part.

![Web typography](https://res.cloudinary.com/echobind/image/upload/v1661872447/echobind_blog/f3mbvx7th9ouhprz0mer.png)
_[Source](https://internetingishard.com/html-and-css/web-typography/)_

**Leading** refers to the vertical-spacing between each line. Too little or too much and the user will have a hard time reading the displayed information.

![Web typography](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/sozg1kruice2ddemkzvh.png)
_[Source](https://internetingishard.com/html-and-css/web-typography/)_

**A typeface** is the design of the letters. Although every operating system comes with some built-in, Hello Startup points out that one of the simplest ways to dramatically improve your designs is to steer clear of these. Many better-looking alternatives can be obtained for free and this [resource here](https://internetingishard.com/html-and-css/web-typography/#where-to-find-web-fonts) goes further in-depth.

**Style** refers to the way you can alter the look of a typeface including text size, thickness, letter spacing or capitalization. A certain combination of typeface and style is a font, although the terms are incorrectly used interchangeably.

![Digital Synopsis graphic design typography color art terms explained](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/uolb7gv7duplfpzfasq0.png)
_[Source](https://digitalsynopsis.com/design/graphic-design-typography-color-art-terms-explained/)_

### 5\. Contrast and Repetition

Contrast helps to build consistency as well as directing attention to more important parts of the design. In the LinkedIn image above, you can see the fonts are consistent for headers, sub-headers and so on and have emphasis where needed. At Echobind, we enforce this design technique through the use of template styling. This ensures all related elements follow the same rules and bring cohesion throughout the app.

### 6\. Colors

Colors not only make something look pleasing to the eye but it can help direct users without the need for words. Take this screenshot from [Jobsite](https://www.jobsite.co.uk/about/about-us) below. Using contrast effectively they’ve made the call to action stand out to the user. At a glance, before even reading the button’s text the user will know the purpose and what they should do after filling out the form.

![Jobsite about us page](https://res.cloudinary.com/echobind/image/upload/v1661872447/echobind_blog/x92twnbggc3ris4eanrx.png)
_[Source](https://www.jobsite.co.uk/about/about-us)_

### Up Next

In the next part of the series, we’ll continue through Hello Startup’s chapter on product design, this time focusing on building the MVP with what we’ve learned about user-centered and visual design. Remember, this is only a fraction of the valuable information that can be found in this book and I highly recommend picking up your own copy for more in-depth explanations and examples.

Until next time!

---

[View on echobind.com](https://echobind.com/post/product-design-ft-hello-startup-the-visuals)

---

# Look Deeper into the Look and Feel

> Jan 16, 2020 | Design is comprised of many things but fundamentally it is about problem-solving and communication. It is a non-linear, iterative, analytical, creative and critical thinking process.

_By Elrick Ryan · 2020-01-16_

## A Brief History of Design

### The Composition of Design

Design is comprised of many things but fundamentally it is about problem-solving and communication. It is a non-linear, iterative, analytical, creative and critical thinking process. A process used to craft solutions to problems and communicate them in ways people can comprehend, use and enjoy. To get the most out of design you have to look deeper into the aesthetics or the ‘look and feel’. Because the resulting aesthetic is based on a trail of logical and intentional decision making, not whimsical expression. It’s used to reinforce, inform and support how the design is supposed to work. And what it’s trying to communicate. It is a piece of design, not design in and of itself.

Steve Jobs, co-founder of Apple is recognized as one of the greatest minds, entrepreneurs, and innovators in the 20th and 21st century and had much to say on the topic of design. He was noted saying that:

_‘Design is not just what it looks like and feels like. Design is how it works’. — Steve Jobs_

And Even though this is not a complete definition, if such a thing even exists, it illustrates that Jobs understood there was much more to design and leveraged that deeper understanding to his advantage. But what does design mean? If you ask 10 people, you will get 10 slightly different but equally valid definitions and here is why.

Design is a word whose roots go back thousands of years. It spans and has influence from several industries. And it has different meanings and describes a discipline, a process, and a thing. People use it to mean a drawing, sketch, object, blueprint, plan, goal, objective, purpose and intention. This adds to the confusion of the meaning of the true meaning of design. But an interesting grouping has emerged from all these synonyms.

Looking at these words, we can group them into three categories. **Objects, intentions, and plans**. So, if we combine this with our earlier statement about design, we could say that —

‘Design results in some object with intent or intentions that we plan, which is then communicated to users in a way they can comprehend, use and enjoy’.

This is yet another definition of what design means. But I will try to explain why I think this is a valid description. But first, let's walk through a brief history of design. It's important to understand how we got to where we are today. I wish I could go into extreme detail but that is a book within itself. So, I will skim the history and pull out some details.

### **Brief History of Design**

The roots of Design span over 40,000 years. As long as humans have been in existence we have been solving problems and creating solutions. We started with Petroglyphs, then Hieroglyphs and Cuneiform, using symbols, elements, and objects to communicate intent and meaning.

Those were the early forms of communications that over time evolved from pictures and symbols to markings and were combined with Latin and Greek into the alphabet we know today. But at the time these were carved into stone and clay. Fast forward through many years of innovation we went from stone to clay, then papyrus, parchment, paper and digital. Let’s pause on the revolution of paper.

### Paper

Paper is credited to be have been invented in China around 200CE by Cai Lun. Another sizeable invention in China at the time was ‘woodblock’ printing. Which allowed impressions to be printed into the paper. Prior to this everything was done by hand. Fast forward through years of innovation, we ushered in woodblock printing, moveable type, metal-based printing, manual printing machines, steam-powered printing, rotary, inkjet, offset printing, screen printing, 3D printing and digital to name a few.

### Printing

Printing was the gateway to the first information superhighway pre-internet which were books, magazines, and newspapers. Printing allowed for information to be mass-produced at high speeds and then distributed. Even though printing was influential, the result was repeatable, static, and uniform content. But there was a group creating, expressive, dynamic content, what people would call the artist.

### The Renaissance

Artists continued to evolve the symbol, pictures and illustrative side of our over 40,000-year-old communication roots. Artists were doing things like Calligraphy and experimenting with and creating typefaces the precursor to Typography. Creating decorative letters. And studying, documenting, and illustrating the physical form and world. A notable point to mention here is the Renaissance. The Renaissance not only produced some of the most famous artists but inventors as well. After the Renaissance, we went through a few more periods, several movements, and the world wars.

### The Industrial Revolution

One major period was the Industrial Revolution and so much happened during this time span. The word Graphic Design was coined. Posters started to be printed and combined with color and illustrative work and used for things from promoting goods to propaganda. All that the precursor to marketing and advertisement. The first assembly line was created by Ford. More expansive factories started to emerge, employing people to work with machines. Products and luxury goods were starting to be mass-produced going from hand-made items to machine-made items.

People started to study these factories and their interaction with the workers. And systems started to be created like Fredrick Taylor’s “The principles of Scientific Management” and Toyota’s Production System. Two different ideas in systems but many believe them to be early forms of human-computer interaction studies.

### Pictures

The first portable camera was created by Kodak. The first GUI and personal computers were created. The radio and television were invented. So many things were created during this period. Industrial design was born as people studied the design material object for users. Henry Dreyfuss wrote ‘Designing for People’. The title says it all.

### Movements

While industrial things were happening, so were the movements we mentioned. Movements such as Arts and crafts, Art Nevue, Constructivism, Dada, Surrealism, Modernism, Futurism, and De Stijl. All of which changed and influenced the Design of things from industrial, architecture to printed things. A major influence to note here before we move on is the Bauhaus School of Design in Germany. They took all of what these movements presented and turned them into many of the modern design principles still used to this day.

So much of the design influence at this time can still be felt and seen today in everything from furniture, architecture, products, graphic design, user interface, typography, and illustration. But the bigger influences and changes are on the way.

### Into the 20th Century

As the 20th Century rolled so began the digital revolution, the change from analog to digital electronics and more modern computers. Steve Jobs lead Macintosh to created the first computer to have multiple fonts that were evenly spaced. Don Norman, electrical engineer, and cognitive scientist, the first-ever User Experience Architect joins Apple to design the new human-centered products. More advanced computers and software were built and that started digital design. Design now moved from much of the manual process and setup into digital desktop publishing.

The internet was created. A new medium and platform at the time. Whos underlining design model takes heavy influence from Graphic Design. We went through several years of innovation on the web from linked docs to webpages, HTML, CSS, Javascript, and Flash ubiquitous with interactive websites and animations on the web at the time. And a lot of great things happened but the platform was so still going through some growing pains and figuring out what it could be.

Then Steve Jobs and Apple hits us with another invention that would change. The iPhone. The iPhone was the start of ‘smart devices’. Even though it was not the first phone with internet access or even the first to be able to render a webpage. What it did was changed the way users would interact with the web and its content. It changed expectations. That was 2007\. Fast forward through several years we have smart everything and everything has internet access and the user can access any content. Phones, Watches, Television, Regriators, Game Consoles are all things we have to design for in 2020\. We have come a long way from Clay.

We only scratched the surface of our history up until now. Hopefully, you were able to see that our history of design, innovation, and communication is not a sequential pattern of things that overwrite one another but more of a global interconnected, overlapping, cross-pollinated history. Influence from all aspects of things over time from Egyptians, Scribes, Monks, Artists, Posters, Wars, Movements, Books, Phliopshers, Engineers, Business, Technology, Scientist, Products and everything in between. All with the same mission to Design, solve problems, build objects, and communicate things.

### Design in 2020

Design in 2020 is a combination of everything that we have learned over our 40,000-year history of design, products, business, and users. No longer are we just designing a Watch. It's a Smart Watch, with a heart sensor, GPS, and many other features. A Radio is now connected to the internet, it has voice controls, and knows the weather. A car is now an Electric car, that updates over the internet, with auto-drive, a 17-inch dashboard, and a mobile app. Users have access to all the mass-produced smart devices. Businesses are now global entities catering to diverse markets. And the distribution of content and products can happen in minutes to thousands if not millions of users. You get the idea.

Designing today has a lot of concerns and variables

Such as:

* Marketing / Marketing Strategy
* Information Architecture
* Branding / Brand Identity
* Copywriting
* Illustration
* Typography
* Color Theory
* Psychology
* Ergonomics
* Experience
* Business
* User needs
* Interface Design
* Visual Design
* Composition
* Photography
* Prototyping
* Strategy
* Research
* Testing
* Animation / Interaction Design
* Accessibility
* And Development

Luckily we can look back at our history and what was learned over time to pull influence from it and use it as a springboard for innovation.

This may look like a daunting list but there are organizational approaches or mental models such as the one in from the book [Elements of User Experience by Jessie James Garret](https://www.amazon.com/Elements-User-Experience-User-Centered-Design/dp/0321683684) that can be used to help you tame that list.

![https://cdn-images-1.medium.com/max/1600/1*nIEV4Eu-odryfKz5frz0cQ.png](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/haypzhiuqc8qrvssfkvv.png)

![https://cdn-images-1.medium.com/max/1600/1*X4ycAz3rRE_nXVCvF1CE7w.png](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/esbvfcyc1f3zaiz4vipp.png)

I hope this post was able to provoke some thought and get you thinking about what is behind the look and feel. The same way we started with simple shapes and elements so long ago we can use the same concept when breaking down even the biggest Design task in 2020\. We just have to dig deeper.

---

[View on echobind.com](https://echobind.com/post/look-deeper-into-the-look-and-feel)

---

# The Importance of Negative Space

> Jan 15, 2020 | Having an understanding of negative space can help you become a better designer.

_By Michael Dang · 2020-01-15_

Something that I learned back in my Graphic Design days was the importance of utilizing negative space in a design. Often designers (including myself) try to fill in as many design elements inside of a set real estate not knowing that it ultimately convolutes the overall message of the design. It took me some time to understand how negative space can help create groupings, add emphasis and improve legibility. Having an understanding of these concepts has made me a better designer today.

### **What is Negative Space?**

Negative space is the area around a design that is not taken up by things like text, graphical elements, images, etc. For example, look at this Nike image below. Notice how there’s the big bold text bottom left and a whole lot of negative space on top of it. This is a perfect use of negative space that works in unison with the background image. It helps create an emphasis on the overall message while also giving the background image it’s space to shine. Very clear and concise.

![Nike ad with a guy working out](https://res.cloudinary.com/echobind/image/upload/v1661872445/echobind_blog/fpi4rhh8ro0pi5pv8kds.png)

Another great example is Apple. They are the masters at this. They seem to always know what the message is and put the utmost importance on their product. Here you can see how straight forward they are with this graphic. You have your text describing what it is, how you can customize it and a super vibrant image of the product. Notice the negative space on the left and right sides. Negative space is underrated because a lot of companies would try and fill in that space with more marketing text/design. But not Apple. Apple lets its product do all the talking.

![Apple watch ad](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/lefptrywehigcqqonxrw.png)

### **Clarity in Negative Space**

Avoiding needless clutter is a skill that is very important. It’s easy to over-design something when your creative juices are flowing. But, you should always take a step back and ask yourself — is this really necessary? In this instance below with the Coca-Cola advert, less is more and simplicity is key to help give clarity to this design. It truly looks refreshing.

![CocaCola billboard](https://res.cloudinary.com/echobind/image/upload/v1661872446/echobind_blog/pwfcgcmuhzz1vig0bn2w.jpg)

### **How to design with negative space**

As you can see from the examples above, there’s a clear pattern. It takes the right amount of padding to create the necessary space around either text, image or product. This allows the overall design/message to become the main focal point. To help with negative space, keeping the background simplistic is key and also gives you room to move your design elements around freely.

### **Conclusion**

Understanding spacing and having breathing room around the design elements will help in almost every facet. From print, web to now UI, it has helped me in my career and is a great skill that every designer should have.

---

[View on echobind.com](https://echobind.com/post/the-importance-of-negative-space)

---

# Building a Social Media Image Generator

> Jan 14, 2020 | What if all we needed to do was provide a title and tagline, and then we could generate the image and use it on social media? Let's find out.

_By Joe Previte · 2020-01-14_

The other day, a friend named [Jason Lengstorf](http://twitter.com/jlengstorf/) shared a blog post called [“Automatically Generate Social Images for Blog Posts.”](https://www.learnwithjason.dev/blog/auto-generate-social-image/) I saw it and thought the idea was super cool.

Then, a light bulb went on.

_What if we could use this to help with our social media?_

Rewind to a week ago. I was chatting with Anne about the blog. Our conversation went something like this:

“I love that we’re pushing out more blog posts but it’s taking up a ton of time. And it’s taking away from my other responsibilities.”

“What takes the most time outside of editing?”

“Creating images to be shared along with our blog posts on Twitter. I’m spending sometimes 20+ minutes in Canva, even with the template from the design team.”

I thought to myself, “Why not use Jason’s tutorial plus the template from the design team and build something to generate the image in seconds?”

So that’s what I did!

## Building the Generator

Jason’s blog post laid the groundwork for how the image would be generated. All we needed to do was provide a title and tagline, and then we could generate the image and use it on social media. Perfect!

Using [chakra-ui](https://chakra-ui.com/), [Next.js](https://github.com/vercel/next.js#api-routes) and a [Next API route](https://github.com/vercel/next.js#api-routes) — all hosted by [ZEIT](https://vercel.com/) — we made it happen.

We built a simple form that asks for a title and a tagline. You then click “generate”, which sends a request to the `/api` route and responds with a URL to the template image with text overlaid on top (thanks to [Cloudinary](https://cloudinary.com/)).

Taking the URL, we draw it on an HTML5 `Canvas` element and then provide a convenient “download” button. Here’s what it looks like in action:

![Our blog image generator in action.](https://res.cloudinary.com/echobind/image/upload/v1661872450/echobind_blog/h15gixdh756asmohk10e.gif)

## Team Work

We couldn’t have built a solution this quick without help from the following people and organizations:

* Jason Lengstorf
* `chakra-ui`
* ZEIT
* Cloudinary

If you’re interested in setting something up yourself, you can [view the source code](https://github.com/echobind/blog-image-generator) and [sign up for Cloudinary here](https://cloudinary.com/invites/lpov9zyyucivvxsnalc5/ixsyxixtotweej6u9bzv)!

Thanks for reading!

---

[View on echobind.com](https://echobind.com/post/building-a-social-media-image-generator)

---

# Ruby on Rails — Importing Data from an Excel File

> Jan 13, 2020 | Importing data into Ruby on Rails from an Excel spreadsheet doesn’t need to be difficult. Let's create a rake task and use the roo gem.

_By Gabriel Martin · 2020-01-13_

Importing data from an Excel spreadsheet doesn’t need to be difficult. While Rails doesn’t include a native utility to handle these file types, there are several gems that make it quite easy to read/write Excel spreadsheets.

In this post, we will create a rake task and use the roogem to read from an Excel file and import data into the database.

## Setup

We’ll start by adding the roo gem to our project. If you’re using Bundler 1.15 or higher, you can use the `bundle add` command.

```javascript
 bundle add roo 
```

This will add roo to the `Gemfile` and install it. Alternatively, you can update the `Gemfile` and install it manually.

Add this line to your `Gemfile`.

```javascript
 gem 'roo', '~> 2.8' 
```

And install.

```javascript
 bundle install 
```

## Creating the Rake Task

Now that we’ve added roo, we can start working on the actual feature.

Generate the rake task.

```bash
rails g task import data
```

This will generate the file `import.rake` in `lib/tasks` where “import" is the namespace and “data" is the task name.

Now that our task is created, let’s update the description. We’ll also add a simple puts command and ensure that it runs.

```javascript
namespace :import do
  desc "Import data from spreadsheet" # update this line
  task data: :environment do
    puts 'Importing Data' # add this line
  end
end 
```

Run this command in your console.

```bash
 bundle exec rails import:data
```

## Importing the Data

To keep it simple, I have a very basic user schema. Where a user has two fields, name and email. I’ve added the spreadsheet file at lib/data.xlsx which contains several rows, each representing a new user to be created.

![CSV sheet with name and email columns](https://res.cloudinary.com/echobind/image/upload/v1661872889/echobind_blog/pmuqchkb8e1yn2wmt9mr.jpg)

As you can see, the first row of the spreadsheet represents the headers. Everything else is the actual data that we need. Let’s start implementing roo so we can map over this data and create the users.

First, we will require roo and open the spreadsheet within the task.

```javascript
 require 'roo'
namespace :import do
  desc "Import data from spreadsheet"
  task data: :environment do
    puts 'Importing Data' # add this line
    data = Roo::Spreadsheet.open('lib/data.xlsx') # open spreadsheet
  end
end
```

Next, lets grab the first row of the spreadsheet since we know this is the header row. We’ll use this later to create a hash when mapping over the rows with the data we need.

```javascript
data = Roo::Spreadsheet.open('lib/data.xlsx') # open spreadsheet
headers = data.row(1) # get header row
```

Now we can map over the spreadsheet rows and extract the user data. Here is what the code looks like.

```javascript
 data = Roo::Spreadsheet.open('lib/data.xlsx') # open spreadsheet
headers = data.row(1) # get header row
data.each_with_index do |row, idx|
  next if idx == 0 # skip header
  # create hash from headers and cells
  user_data = Hash[[headers, row].transpose]
  if User.exists?(email: user_data['email'])
    puts "User with email '#{user_data['email']}' already exists"
    next
  end
  
  user = User.new(user_data)
  puts "Saving User with email #{user.email}"
  user.save!
end 
```

Let’ walk through this.

We map over each row in the spreadsheet using `data.each_with_index-->.`

If we’re on the first row (`idx == 0`), we want to continue to the next iteration because this is the header row. 

Next, we create a new hash that contains the data from the current row. We build this hash using the `headers` array that we grabbed earlier and the current `row` that we are on in the loop. So, what is this line doing?

Let’s start with Array#transpose. I’m not going to dive into the transpose method but it essentially turns columns into rows when you have a multi-dimensional array. Here’s a quick visual.

This is what the array looks like before calling `transpose`. 

```markup
 [
  ['name', 'email'],
  ['john', 'john@test.com']
] 
```

And this is what is returned when calling `transpose`. 

```markup
[
  ['name', 'john'],
  ['email', 'john@test.com']
]
```



When passing the above array to `Hash[]`, we get a back a new hash where the `key` is the first item in each nested array and its value is the second. In our case, the hash matches the user fields we need to create a new database entry. ``

```markup
user_data = Hash[[["name", "John"], ["email", "john@test.com"]]]
p user_data # {"name"=>"John", "email"=>"john@test.com"} 
```

Then we check to see if a user already exists with the current email address. If it does, we print some text to the console and move on to the next iteration without saving.

```markup
# next if user exists
if User.exists?(email: user_data['email'])
  puts "User with email #{user_data['email']} already exists"
  next
end
```

And finally, if the user doesn’t already exist, we can create a new user instance with the fields generated from the current row and save the new user in the database.

```markup
user = User.new(user_data)
puts "Saving User with email '#{user.email}'"
user.save! 
```

The complete code should look something like this.

```markup
require 'roo'
namespace :import do
  desc "Import data from spreadsheet"
  task data: :environment do
    puts 'Importing Data'
    data = Roo::Spreadsheet.open('lib/data.xlsx') # open spreadsheet
    headers = data.row(1) # get header row
    data.each_with_index do |row, idx|
      next if idx == 0 # skip header row
      # create hash from headers and cells
      user_data = Hash[[headers, row].transpose]
      # next if user exists
      if User.exists?(email: user_data['email'])
        puts "User with email #{user_data['email']} already exists"
        next
      end
      
      user = User.new(user_data)
      puts "Saving User with email '#{user.email}'"
      user.save!
    end
  end
end
```

That’s it! Now you can run this task and import users from the spreadsheet.

While this approach uses a very simple data structure, it’s a good starting point even for more complex situations.

---

[View on echobind.com](https://echobind.com/post/ruby-on-rails-importing-data-from-an-excel-file)

---

# What to Ask When Hiring a React Native Consultancy

> Be informed before putting down a bunch of money to get your app built. React Native developers aren't all the same.

_By Mike Cavaliere · 2020-01-10_

If you don’t have your own tech team and need an app built, sometimes hiring an agency to design and build it for you is a valid option. Like with any other significant purchase, you should be informed before putting down a bunch of money to get your app built.

Far too often, companies and individuals who do not have a technical background have no way to gauge whom they’re hiring, or what to expect in an engagement. This list covers some important questions that will at least make you think about the types of things to look for in a software consultancy. **A handful of them are React Native-specific; most can be applied to any technical engagement of any kind.**

(Note that I use the words _agency_ and _consultancy_ interchangeably.)

## Project Scope

**“What’s your process for gathering requirements?”**

Discovery (or requirements-gathering) is included as an initial phase by many agencies; it’s the process whereby any unknowns become known: time risks, difficult technological challenges, complex business processes and a number of other possibilities.

The agency should be able to give you a sense of whether discovery is needed for your project, how long it should last, and what the discovery process will entail.

**“How long does it take / how much does it cost to build a React Native app?”**

To most pros this is a silly question since it’s like asking how long it takes (or how much it costs) to build a house; the answer is there’s a big range that depends heavily on what the house has in it. The number of rooms; the type of rooms; not to mention the conditions of the land the house will be built upon.

That said, a good agency will handle a question like this gracefully by explaining the above to you.

### **About the Technology**

**“Why React Native?”**

React Native may be a hot technology buzzword, but that should never be the only reason a team uses it. Whereas many teams will focus on one framework rather than another, they should be able to justify their decision to focus on React Native vs Flutter or Titanium for example. And with multiple branches of reasoning.

**“What can’t React Native do? Or what doesn’t it do well?”**

No one framework is suited to every task, project or situation. Anyone who is experienced with React Native (or any other framework) should be able to tell you situations where it’s not the best solution. If they can’t, it may be a sign that they’re way too attached to their tool of choice (and a bit dogmatic with their approach to technology), or not experienced enough to know its limitations.

### Development Process

**“Do you develop on simulators or actual devices?”**

Development teams will often rely on software that simulates mobile phones and tablets since it’s impossible to own every device out there, even for a very large team. The simulators allow an unlimited assortment of device models and versions.

There are certain things that are only accurately testable on real devices though; things like in-app purchases, or camera usage for example. Mobile engineering teams — especially remote ones — should have at least a device or two on hand for testing things of this nature.

**“What’s your Quality Assurance (QA) process?”**

QA is the process whereby the software is tested (manually, and in an automated manner as well). A good consultancy should have a process by which the software is ensured to be working as intended, a way of tracking issues, and time allocated to a project’s budget to ensure any critical bugs are found and eliminated.

**“What does the end-to-end (E2E) process look like?”**

Automated software testing is crucial when building complex applications. End-to-end testing, in particular, is testing that runs the app and simulates the use of the app as if a real person was using it; clicking, tapping and typing relevant information into it.

E2E testing runs more slowly but tests that the critical things are working at all times. So an engineering team needs a strategy for when to apply this type of testing, and a process for how to go implement it (and how to run the E2E tests regularly, such as with a Continuous Integration process).

**“Will our developers, or other contract workers, be able to maintain a React Native codebase after the contract ends?”**

This is crucial. Sloppy engineering teams build things that aren’t easy for anyone else to follow; code is written with poor naming conventions; documentation doesn’t exist; things are cryptic for no reason; files in the codebase are large and messy.

Better teams have well-commented, self-documenting code that is unambiguous along with release notes, wikis, and other things that make it easy for anyone with decent skills to pick up and work with.

### **Getting the App Out There**

**“How do we release a React Native app?”**

A novice RN engineer might be able to cobble an app together and have it work in the simulator; getting it live in the Apple App Store and the Google Play Store successfully (and repeatedly so) takes a bit of experience. Experienced RN teams will be able to tell you what types of materials you’ll need upfront (marketing, legal, and so on), in addition to walking you through the many ways the stores (in particular, the App Store) can notoriously reject your app, forcing you to go back to the drawing board and spend more time and money.

### Customer Service

**“How do you educate your clients?”**

Consultants are meant to be experts in their industry. The more established ones teach, publish, speak at conferences. And even the ones that don’t should at least know a lot more than you about the subject matter; that’s what you’re hiring them for.

As such, they shouldn’t just take your money and make things; they should be able to give you some understanding of why a feature should work a certain way, why some tasks will take longer than others, and the implications of taking one approach over another. They should be adept at (and comfortable with) explaining complex concepts to people outside their realm.

**“How do you ensure timely delivery while staying on target with a budget?”**

Time and money are things that anyone who’s ever hired an agency cares about. Normally, you’re hiring an agency to build something that’ll help you make more money or save more time, so you don’t want to burn too much of either one during the process.

Asking this question will give the agency a chance to describe the processes, habits, tools and everything else they use to keep timelines and budgets from missing their mark. And depending on how they explain this, it’ll cue you in to just how important they treat their clients’ time and money.

**“How frequently will I be updated about my project?”**

Some consultancies (or freelancers) will take a project spec and disappear without a trace for days, weeks on end. That’s all fine if that’s what you agreed to, and you’re comfortable with it — most people are not.

Any consultancy you hire should have a typical pattern of communication with their clients, be it biweekly, weekly or daily. This will differ by the type of project the consultancy focuses on, industry, team preference, and project. But they should be able to verbalize why they approach their communication the way they do and make you feel comfortable that you’ll hear from them when they say you will.

### About the Agency

**“Have you worked with enterprise (or SMB, or fill in your industry) clients before?”**

Enterprise technology projects have different needs, restrictions and processes than those for small startups, small- and medium-sized businesses. So the agency’s approach needs to fit within those needs.

Similarly, each industry has its own subject matter and specifics. Health tech (which we happen to do a lot of) has specific rules around HIPAA data privacy and patient information. So whereas a good technology consultancy can work in a great many industries, it doesn’t hurt for them have had a little experience in your industry, particularly if it’s one with a lot of specific industry knowledge like health tech or FinTech.

**“Where are your engineers/designers/QA testers located?”**

I believe that consultancies should be very upfront about this, but I’ve seen many advertise themselves as being based in the USA when only one or two employees are based there (usually sales reps), and their engineers are completely offshore in another country. This feels like a bait-and-switch to me.

Engineers located anywhere can be effective, but it’s important that you know what you’re getting. And if it’s important to you that you’re working with domestic engineers, or engineers in a closer time zone, that information should be front and center.

**“How can a remote team be as effective compared to a shop that is all onsite?”**

The world is still divided in their perception of remote work; many companies still cling to the notion that all people regardless of role need to be in a cubicle working to get anything done. Quite the reverse is true and it’s gradually becoming more understood publicly, however; and as remote agencies, we should be able to verbalize why. I for example often cite [stats about the effectiveness of remote workers](https://www.owllabs.com/blog/remote-work-statistics) and the book [_Remote_](https://basecamp.com/books/remote), both of which solidify the tangible benefits of remote work.

**“What process is in place for when an employee is sick?”**

When you’re hiring an agency, you’re looking for a solid team of people—_people_, not _a person—_to build something great for you_._ By definition, you’re hiring a group of people, not an indestructible lone wolf hero. With that should come a realization that all people (even our lone wolf hero of legend) are human, and run into problems at times.

Sickness, injury, jury duty; all these things affect even the most lone-wolfiest of us. A good agency has safeguards for handling them all without any disruption of your project’s progress.

**“Will the same engineers be working on the project for the full duration of the project? How often do engineers transition out?”**

For longer projects, in particular, it’s not always ideal—for either the agency or the client—to have the same engineers on the project for too long. A certain amount of time is important for understanding the domain, setting up the project on their computer and so on. Too long, and it’s easy for people to have less impact at what they do, and stop learning drastically different things.

This is one of the benefits of hiring consultancies; their engineers see so many diverse projects, that their knowledge is extremely robust. So some consultancies switch them out after a period of time to keep them improving and bring new eyes to your project that will see things the veterans won’t. But this duration should fit well with your project’s timing, so it’s good to have a sense of this upfront.

**“Can I talk to any of your previous clients?”**

This last one is a question that few people think of but is incredibly important. Recommendations and social proof of some sort can make you feel a lot more certain that you’re hiring a group of professionals that have helped another professional like yourself get things done—well, professionally. You’d ask for references for someone who was babysitting your child; for some, their company is like their second baby. A good agency will treat your project like an infant—with the care and respect it needs. And they’ll be glad to ask their other clients to tell you just how well they’ve taken care of them in the past.

---

[View on echobind.com](https://echobind.com/post/what-to-ask-when-hiring-a-react-native-consultancy)

---

# Up and Running — Next.js and TypeORM

> Jan 09, 2020 | Today we take an app a bit further and show how to integrate Next.js serverless API functions with TypeORM and Postgres.

_By Matt Thompson · 2020-01-09_

## Welcome to Up and Running — Part II

In my [previous article](https://echobind.com/post/up-and-running-zeit-now-environments), I talked about how to get [Now](http://zeit.co/) up and running with multiple environments. We used a boilerplate [Next.js](https://nextjs.org/) app and added a single environment variable to show our intended deployment on the landing page. Today, I’d like to take that app a bit further and show how to integrate Next.js serverless API functions with TypeORM and Postgres. While this still won’t cover everything, by the end we will be able to:

* Add a User model
* Make a migration
* Create a User Factory
* Seed our database
* Add a getUser call to the API
* Use the said call to display data

**What this won’t cover:**

* Database Pooling
* Hosting the DB
* Unit testing
* End to End testing
* CI Testing

I’ll be continuing the series hoping to address the above as this tech stack progresses. For now, let’s get this app running with some data.

_Note: As stated in the previous article, ZEIT is still a moving target. I’ve been keeping watch over threads. While this is an example of a current setup, I am aware they are still actively adding features and sifting through requests. Should this setup change I’ll create a follow-up post. This is not the single and only way to do things._

### [TypeORM](https://typeorm.io/)

If you’ve worked with an ORM you should be good here. The main benefit of using this one was out of the box TypeScript support. I’m not going to dive into the specifics of TypeORM but we will be covering the config setup and I’ll have a few examples along the way. I am going to go ahead and define some terms here as I’ll be using them throughout this post.

**Entity:** (Model) A class that maps to a database table. This also provides typescript annotations to our app.

**Entity Manager / Repository:** TypeORM has a couple of ways to interact with your model based on your needs. For this example, we will be using the `getRepository` helper which allows us to call utils such as `.create`, `.save`, `.find`, etc. The repository is how our app will interact with our database.

**Migrations**: TypeORM will compare your Entities to Postgres and auto-create a migration file. Running the generate command will create a timestamped file with the needed up and down SQL. 90% of the time this will be all you need. However, I will note I’ve seen some edge cases when trying to update fields to something new, say an enum type, where this SQL may be off. Regardless, these files are generated but not set in stone. You can edit at will if something needs to be added. It’s always good to double-check.

### Dependencies

You can follow along in my [example repo here](https://github.com/mthomps4/next-now-test/tree/next-typeorm-example) on the `next-typeorm-example` branch or if you would like you may add these dependencies into your Next.js app and give these snippets a go.

**Dependencies:**
* **dotenv:** used in our yarn scripts to point to the needed `.env.environment` file
* **reflect-metadata:** used for Typescript/TypeORM to reflect our Entities
* **typeorm**

**Dev dependencies:**
* chance
* ts-node
* typescript

### Setting up the DB

TypeORM has a lot of built-in helpers for generating the core entities and migration files. You can install this dependency globally, but we would like to use these commands in our yarn scripts in pair with dotenv and keep our package versions under control.

To start we are going to look at a couple of setup scripts that will leave us with a base User model.

```javascript
"db:setup": "yarn db:create:dev && yarn db:create:test",
"db:create:dev": "createdb --owner=postgres next_now_dev",
"db:create:test": "createdb --owner=postgres next_now_test",
"g:migration": "yarn typeorm:local migration:generate -n",
"g:entity": "yarn typeorm:local entity:create -n",
"typeorm:local": "yarn local ./node_modules/typeorm/cli.js",
"local": "DOTENV_CONFIG_PATH=./.env ts-node -P ./tsconfig.yarn.json -r dotenv/config",
```

The first block of lines here is fairly straight forward. We want to create a quick `db:setup` script that will create our Postgres tables. This just helps on-board others and helps yourself remember when the project has set on a shelf for a month or two. Things I never do.

The next block starts to hone in on our actual TypeORM calls we want to leverage. Specifically these two scripts `typeorm entity:create -n` `typeorm migration:generate -n.` Remember we want to use typeorm from our node\_modules and not the global install, so we've added another script to help locate that file with `typeorm:local`. We've also conveniently named this with `:local` for semantic purposes to know which environment we aim to leverage. With one last helper that utilizing dotenv for the environment variables needed. (You'll note there's a tsconfig in here as well, but more on that later).

### Environment Variables and TypeORM config

So we have a script that creates our databases and scripts to create an entity and create a new migration file. However, if you run any of the generate commands now, things will begin to break. TypeORM isn’t aware of your database just yet.

If you are following along in the repo take a peek at `.env.example` quite a few variables have been added in for TypeORM.

![.env file](https://res.cloudinary.com/echobind/image/upload/v1661874502/echobind_blog/a2w6f0ndir2fwm0lhm3s.png)

You have the normal DB setup here with connection type, host, db, port, etc. but we also have some ENV’s set for Entities Migrations and their respective directories. TypeORM will look to these files when making a comparison for migrations and use the directories when we generate new content. If you look into the root of our project you’ll see a folder set for both.

Adding these to our .env file we can now try out our first command. `yarn g:entity User`. You should see a new User.ts file appear within your entities folder. As _exciting_ as it looks this will be our base for adding the User model and table to Postgres.

![User typescript file](https://res.cloudinary.com/echobind/image/upload/v1661874071/echobind_blog/h63weftjij6sbdxtmlab.png)

### Adding the user table

Let’s start building this User Entity out. I’m going to be covering a handful of example types here just to show how TypeORM migrations shine. TypeORM uses its helpers to define columns for the database tables. We also include our public and private typings here on the Entity for TypeScript. For starters, let’s add name and email columns by importing the `Column` helper from `typeorm`. We will also go ahead and import `Index` to make our email filed unique.

![Typescript code](https://res.cloudinary.com/echobind/image/upload/v1661874078/echobind_blog/spjupu5vtuxyys8cvamn.png)

Taking a closer look you’ll notice that Column takes an object of keys that are database specific. Underneath each of these, you’ll also see the field is defined as a public field for typescript. A quick note, you can define different field names within Column if you would like to map to something different. eg. first\_name maps to firstName. We’ll see how this all plays out in a second but for now, let’s keep going.

Enums. At some point, you’ll want to add a field that has limited values. For this example, we are going to add a role to the user. Similar to the other fields we will still use Column, but expand on the type options for Postgres. We’ve also defined this as a constant type to use within our application code.

![Typescript code](https://res.cloudinary.com/echobind/image/upload/v1661874085/echobind_blog/otf2cbjodxg2by0wxhuv.png)

Finally, you’ll notice I’ve used TypeORM’s utils for timestamps and primary keys. I’ve also brought in a before insert helper to set the primary id to a UUID rather than the Postgres default of 1, 2, 3\. I know this is a lot but you altogether you should be looking at something like this.

![Typescript code](https://res.cloudinary.com/echobind/image/upload/v1661874092/echobind_blog/tanncl98ncayadh4svyz.png)

### Migrations

Great, we have a User Entity but what does all this code buy us? Let’s get back on track and run the other yarn script we created earlier `yarn g:migration AddUserEntity`. If everything ran successfully you'll see a new file under the root migrations folder that should look similar to below. There is one thing to note however, remember when I mentioned these migration files weren't always 100% perfect. Well, here is a perfect example. The Postgres extension for our UUID may not be installed but TypeORM has no way to know this when auto-generating this file. It simply compares the model we created to that in the database. To combat this we've added one more line to the `up` method await `queryRunner.query(CREATE EXTENSION IF NOT EXISTS "uuid-ossp");`. This will ensure when the migrations run we Postgres will install the needed extension.

![Typescript code](https://res.cloudinary.com/echobind/image/upload/v1661874358/echobind_blog/dsql1tfnfqfz2tvsh1lx.png)

Everything looks good. Let’s run one more command. `yarn db:migrate:local` under the hood, this uses our custom `typeorm:local` setup and runs the typeorm command `migrations:run`. You should see an output similar to below and check Postgres to see that the user table was created.

![Terminal running yarn migration](https://res.cloudinary.com/echobind/image/upload/v1661874906/echobind_blog/zsbmungypa09evxma2gi.png)

### Making Some Users

Alright, so far we’ve made our Entity, created and ran our Migrations, let’s get some Users into the database. While you could do this manually, we want to make this dynamic enough that others can get up and running as well. We’ll create a Factory and create a user seed file to create some users. Eventually, this Factory can also be used to test our users. Inside of our example codebase, you’ll see a folder for `factories` with the following code inside the UserFactory.

![Typescript code](https://res.cloudinary.com/echobind/image/upload/v1661873206/echobind_blog/guovwthwwqplfo0cqave.png)

The big thing to note here is our build and create methods. With TypeORM you have the ability to `create` the record and validate it before we `save` it to the database. We know what record this will be by accessing the `getReposiotry` method and passing in our `Entity`. It's also worth noting TypeORM will add any of the default and null values missing from `userAttrs`. In this case, the only key required is email, we've used the chance library here to ensure one is always created but we can also pass other fields in to add to or overwrite our factory defaults. Now we can import this in a seed file and run our create method.

Example: `UserFactory.create({firstName: 'Bob', email: 'bob@test.com'})`

Adding more of these lines we can attempt to run this seed file within our yarn scripts and add some users. Feel free to be creative.

`"db:seed:users": "yarn local seeds/userSeeds.ts"`

Again, this will use our custom `local` config that points to the correct ENV credentials for TypeORM and runs our seed file. If everything ran successfully you should see some users in the Database!

![Postman application showing user data](https://res.cloudinary.com/echobind/image/upload/v1661873840/echobind_blog/qjhm67udeypqnbab8bx3.png)

### Show Me Some Users!

Nice, we’ve set up a lot of useful tools and got some users in the database, but data means nothing if we can’t view it. We are going to expand on Next.js REST API to get our Users. With Next.js, inside of the pages folder, their lies an `api` folder. This folder is used by Next.js to create endpoints dynamically based on the file names. In this example, we've made a `getUsers` file with the following. In the example here we are simply returning all users, importing our User Entity and the `getRepository` again we have access to the `.find()` method. We connect to our database, ensure we can find the entity and find the users returning them as a JSON Blob for our app. In the real world, you'll want to expand this for error handling but this works fine for now.

![JavaScript code](https://res.cloudinary.com/echobind/image/upload/v1661873494/echobind_blog/xysx6z662opvbk4b7lvg.png)

I’m sure you were wondering if we would ever get to this point, but let’s start up our app by running either `now dev` or `yarn now:dev`. Running our Next.js app with Now ensures our ENV's are compiled in properly. Once the app has started, navigate to `localhost:3000/api/getUsers`. You should have some data!

![JSON data](https://res.cloudinary.com/echobind/image/upload/v1661872933/echobind_blog/bgbsicsqpyyvpvycgpk3.png)

Fantastic! Let’s wrap this up and add some data to our home page. To do this we’ll use Reacts `useState` and `useEffect` hook to hit our API. Within our index page, we will add these lines.

![useEffect method](https://res.cloudinary.com/echobind/image/upload/v1661872940/echobind_blog/x9uimjyvhnerjvvkejzx.png)

You should be able to map users and style however you’d like. With the app still running, navigate `localhost:3000` and check out your results.

![Homepage of new application](https://res.cloudinary.com/echobind/image/upload/v1661874603/echobind_blog/af0j68xzpks6je0l96y9.png)

### Wrapping up

A bit tedious but there you have it, a Next.js app up and running with TypeORM. The fun part, this is ready to go with our staging and production environments as well. Our different `now.json` files mentioned in the previous post will contain the ENV's needed to connect to the appropriate database for each. For seed files, you'll just need to `dotenv` in your yarn scripts to point to a proper env file. If you take a peek at the package.json file you'll see some examples where we've followed the same `command:local` pattern with `:staging` and `:prod`.

This setup is not contained to Next.js serverless REST pattern. There are various ways to set up a Next.js app. The good news, the TypeORM setup should remain the same. The Entities, Migrations, and Factory we created will not change. How you interact with them might. You may be looking to use Apollo and GraphQL. If so, you will look to call your `getRepository` and `find()` calls from within your resolvers.

I also mentioned at the beginning of this post it does not cover testing. There are still a few topics I’d like to cover regarding Next.js and Now. Namely testing your API with end-to-end tests, expanding on CI/CD, and Database pooling. Stay tuned, hopefully as I learn, so will you.

---

[View on echobind.com](https://echobind.com/post/up-and-running-next-js-and-typeorm)

---

# Convert a React Component to TypeScript

> Jan 07, 2020 | Converting a React component to TypeScript can be broken down in a few steps. Let’s walk through it together!

_By Joe Previte · 2020-01-07_

Converting a React component to TypeScript can be broken down in a few steps. Let’s walk through it together! Here’s the file we’ll use for our example:

```javascript
import React from 'react'

export const Header = ({text, color}) => {
  return <h1 style={{ color }}>{text}</h1>
}

Header.defaultProps = {
  color: 'red',
  text: 'Hello world!'
} 
```

1\. Rename your file from `.js` or `.jsx` to `.tsx`

This tells React and TypeScript that this is a TypeScript/JSX file.

`Header.jsx` \-> `Header.tsx`

2\. Add a return type annotation and a type for your props

```javascript
import React from 'react'

type Props = {
  text: string;
  color: string;
}

export const Header: React.FC<Props> = ({text, color}) => {
  return <h1 style={{ color }}>{text}</h1>
}

Header.defaultProps = {
  color: 'red',
  text: 'Hello world!'
}  
```

`React.FC` stands for “Functional Component”. The `<>` is called a “generic” and it takes the interface/type for our component props. We define our props using a`type`.

3\. Refactor your `defaultProps` to use ES6 default values

```javascript
import React from 'react'

type Props = {
  text: string;
  color: string;
}

export const Header: React.FC<Props> = ({text = 'Hello world!', color = 'red'}) => {
  return <h1 style={{ color }}>{text}</h1>
}
```

Boom! You’re all done. Give yourself a pat on the back and dance. 🎉

---

[View on echobind.com](https://echobind.com/post/convert-a-react-component-to-typescript)

---

# How to Integrate Ruby on Rails with Box.com in 2020 (Part 1)

> Jan 03, 2020 | So you want to integrate your Box folders and files with your Ruby on Rails applications. There are a ton of reasons you might want to do this, but I am pretty sure if you landed here you might have an idea about why you are.

_By Kory Tegman · 2020-01-03_

So you want to integrate your Box folders and files with your Ruby on Rails applications. There are a ton of reasons you might want to do this, but I am pretty sure if you landed here you might have an idea about why you are.

The [Box.com API](https://developer.box.com/en/reference/) is fairly large and has a lot of amazing docs, but it can be difficult to figure out where to start or how you might use it to do things like, create folders from your Rails app or display files from a folder in your App’s UI.

### _Let’s make this easy._

In this post we will cover:

1. Setting up your Box account to use the API.
2. Using application-level authentication via JWT tokens.
3. Setting up server-side tasks like creating folders, uploading files and such.

In Part 2 we will cover:

1. Setting up our front end to use the Box UI Elements with React. This will allow us to access our box files and folders from our App’s UI.
2. Setting up OAuth 2.0 authentication. This hands over the permissions to Box, so folders and files will only be accessible if the user has the permission on their Box account.

### Setting up our Box account application.

Your first requirement is to either create a new account or have an admin level permission on a Box account.

After we have our account setup we need to create a new _application_ on our Box account. We will use it to integrate with our Rails application. This is a common way APIs are set up these days. The _application_ is essentially a place where you store all the settings and credentials you will use for you communicating with the Box API.

Next, we are going to go to the dev console via the left menu bar:

![Box.com API](https://res.cloudinary.com/echobind/image/upload/v1661873221/echobind_blog/cgdzzqvvs0rtzbrdcwiu.png)

From the dev console, we will need to create a new app.

![Box.com Create New App button](https://res.cloudinary.com/echobind/image/upload/v1661873156/echobind_blog/qtyv0cynpz7fs8e71zwd.png)

We are given a choice of _types_ of applications to create. We will be creating a “Custom App” as it will best support us for doing async tasks from the server.

![Box.com New App setup](https://res.cloudinary.com/echobind/image/upload/v1661873163/echobind_blog/e9cpqbzankpkvjdnvq72.png)

Our Authentication Type will need to be “OAuth 2.0 with JWT” (server-side auth). Let’s give our app a name and move on to “view our app”.

Awesome! We set up our box integration app. We still have two more things to do in Box in order to be prepared for our Ruby on Rails App.

First, we need to generate a public and private key-pair for our app to use. This will prompt our 2-factor auth code.

![Adding public keys to Box.com](https://res.cloudinary.com/echobind/image/upload/v1661873242/echobind_blog/o9wjn8pakpgtkevtsiik.png)

This should have downloaded a JSON file with all the keys and such we need to integrate with our Rails app. Hold onto this file, keep is safe we will use it soon. If anyone were to get access to these keys they would be able to access your entire box account.

Next, we need to authorize this app to make API calls. Seems obvious I know, but this is so developers like us can build apps and the system admin can decide whether or not to approve it.

We will need to go back to our main Box account home page and click on the admin console and then the app tab.  
Scroll down to the custom applications section and click on Authorize New App.

![Activate new App button on Box.com](https://res.cloudinary.com/echobind/image/upload/v1661874913/echobind_blog/pkbpk5u8ptq1gyyctpuc.png)

The modal will ask us for our “API Key”, this really means our `client_id`. Fill in your client id and submit (We can find our `client_id` in the JSON file we downloaded when we created our public and private key-pair.) This should ask us to authorize the app, let’s do it!

Boom! We are all set up on Box.

### Ruby on Rails

In this example, we will have a Rails application that has a `Project` model. We want to store all the files for any given project in a box folder. We can do this by creating a Box folder every time we create a new `Project` and saving a reference to that folder on our new project.

Let’s dive in:

We are going to use a nice gem called [Boxr](https://github.com/cburnette/boxr) that wraps the Box API so we can make things a little easier on ourselves. Run `bundle add boxr` from our application root and we are good to go.

Next, let's throw all our credentials from the JSON file we downloaded earlier in our environment using [dotenv](https://github.com/bkeepers/dotenv). Again, let's run `bundle add dotenv` to add the gem to our bundle.

We will create a new environment file called `.env.development` and it should look something like this, where the values in the curlies (`{}` ) will be where we find the values in our JSON file.

```javascript
# .env.development
# Box.com
  JWT_PRIVATE_KEY={appAuth.privateKey}
  JWT_PRIVATE_KEY_PASSWORD={appAuth.passphrase}
  JWT_PUBLIC_KEY_ID={appAuth.publicKeyID}
  BOX_ENTERPRISE_ID={enterpriseID}
  BOX_CLIENT_ID={clientID}
  BOX_CLIENT_SECRET={clientSecret}
```

Next, let's make a `BoxApi` Class that will implement a `get_token` method and `create_folder` method.

It will look something like this:

![Ruby code](https://res.cloudinary.com/echobind/image/upload/v1661874920/echobind_blog/ysinndnqxqqluvusumex.png)

`get_token` is going to use all of our environment variables to fetch an access token for us to use to communicate with the Box API. `create_folder` will use `get_token` and then create a folder in our box account.

Let’s add the `box_folder_id` to our `Project` model by generating a migration:

run: `rails g migration add_box_folder_id_to_projects box_folder_id:string `.

Our migration should look like this:

![Ruby migration](https://res.cloudinary.com/echobind/image/upload/v1661874927/echobind_blog/jwhgqtmhnln3mmqvlrd5.png)

Run your migration with `rails db:migrate`.

Next, let’s use the `BoxApi`'s `create_folder` method on our `Project` model to create a new folder every time we create a new project.

It will look like this:

![Ruby create_box_folder method](https://res.cloudinary.com/echobind/image/upload/v1661874934/echobind_blog/gole3wzjdbulcxtracrg.png)

We are using the `before_validation` callback and adding the restraint of `on: :create` this will call the `create_box_folder` method before creating a new record, before the validation phase of the saving process.

When we create a new folder on Box we get the `box_folder_id` from the response and add the `box_folder_id `to the project so it will save.

NOTE: I added a parent folder ID that the folder will be created in. This helps contain all these project folders in one place for me, but you can leave it as the root folder if you would like.

Great, we did it! We now have Box integrated with our backend application to create and reference a new folder for all of our projects on our app!

---

[View on echobind.com](https://echobind.com/post/how-to-integrate-ruby-on-rails-with-box-com-in-2020-part-1)

---

# Finding Joy In Automated Tests

> Jan 02, 2020 | Obviously, we can’t remove all things in our code that do not bring us joy, but what about putting things in, that do bring joy?

_By Jenn Robison · 2020-01-02_

I recently wrote a blog, [Clear the Clutter with Fragments](https://echobind.com/post/clear-the-clutter-with-fragments), with that my co-worker Anne had a clever idea to find ways to [Marie Kondo](https://konmari.com/) your code! For those not familiar with this concept, it’s about removing what does not spark joy in your life. From [KonMari.com](https://konmari.com/):

_Our goal is to help more people live a life that sparks joy, and we are committed to offering the simplest, most effective tools and services to help you get there._

Obviously we can’t remove all things in our code that does not bring us joy, but what about putting things in, that do bring joy? This might be a controversial statement but automated tests do bring me joy, and confidence in my code.

![Wall with yellow post-its](https://res.cloudinary.com/echobind/image/upload/v1661872990/echobind_blog/xw8pwkjsfhnvuljmc1h0.jpg)

As developers, we all hear about automated testing, and yet it seems to rarely be a priority. From my experience, it’s often undervalued by the business owners and thus takes a back seat to continuing to deliver new features, and thus one of the first things to be removed from the planning board.

But what happens when we keep delivering new features only to find we have a regression on something else within the application? This could be a super basic feature like logging in, or perhaps something more complex like navigating three levels deep with certain elements expected to be visible. Either way, some simple End to End (E2E) Integration tests could help relieve that worry.

With React Native you have a few options for E2E testing, however most common is the use of [Detox](https://github.com/wix/detox). This third party library integrates with your project for both iOS and Android, and thus allows you to write one set of tests for both platforms. After following a short setup guide you are on your way to testing visibility, taps, scrolls, and whatever interaction you would like.

On a recent project, where we have no control of the backend API, we were suddenly unable to login to the application during development. This brought the perfect opportunity to share with their team, the value of automated tests. I made a screen recording of the application and shared with them how this will be running, and automated through Continuous Integration as we check-in feature branches. This provides confidence in Continuous Delivery and helps to ensure we are not regressing as we continue to develop or iterate on features.

[In this video](https://vimeo.com/382279556), you can see with a simple command it builds, loads, and validates some basic functionality. Ensuring a username and password field exist. If I input incorrect values I get an error message, as expected, and if I submit correct credentials I navigate to the home screen. After this, we also then ensure on our main/home screen that a few key elements are visible. Our client was very impressed to see this and it will help continue the conversation with them as we estimate work moving forward, to include those tests.

We’ve all been there. Worrying about a code change having a bigger impact than we expect. It’s that time of year where we reflect on the past year, decisions we’ve made, accomplishments, and goals we want to achieve in the new year. Consider a focus on adding value-add E2E tests to your projects, and thus bring joy to your life with higher code confidence!

---

[View on echobind.com](https://echobind.com/post/finding-joy-in-automated-tests)

---

# Static Sites without the Static

> Dec 31, 2019 | A technique to get peak performance without waiting for rebuilds and preview URLs

_By Chris Ball · 2019-12-31_

#### A technique to get peak performance without waiting for rebuilds and preview URLs

Static sites, produced with tools like [Gatsby](https://www.gatsbyjs.org/), [Hugo](https://gohugo.io/), and others, are popular for a reason. They deploy almost anywhere, are extremely fast, and don’t compromise on the developer experience. When paired with a CMS though, new sites must be built each time an editor makes an update in the UI.

This isn’t always a problem since static site rebuilds are fast, but it does mean that that tooling needs to be inserted after changes are published to perform the rebuild. Most CMS providers offer webhooks to power this functionality.

![Example webhooks from Contentful](https://res.cloudinary.com/echobind/image/upload/v1661873826/echobind_blog/pdxofqmxanizoavy2jrl.png)

Example webhooks from Contentful

Recently, a number of [services](https://www.gatsbyjs.com/preview/) that have sprung up recently to offer “preview’ or staging versions of a site, and some that [attempt to keep the entire preview client-side](https://tinacms.org/) as part of the editor. But as good as these are, it does mean that an editor (who is often a non-technical user) needs to sit through a rebuild process to see changes they have made.

Recently, I set out to explore a technique to allow instant updates from a CMS-backed site on staging sites, while keeping the production version static. Let’s dive in and see how that technique works.

## A look at the tools we’ll use

### Next.js

* Supports Server Side Rendering out of the box
* Has simple “API” support via an `/api` folder. While we won't leverage it for this article, most CMS-backed sites will need to process simple forms and this is a big selling point.
* Can optionally export a fully static site. More on this at the end of the article.

```javascript
graphql-request
```

* A simple wrapper for fetch to make GraphQL queries

### Now (optional)

* Provides multi-cloud redundancy out of the box
* Supports a CDN caching layer, which we can intelligently set via Server Side Rendering

## Start with the dynamic, Server Side Rendered page

First, you’ll need to setup a Next.js site. If you’re starting from scratch, I’d recommend using `create-next-app`.

Then, set up a GraphQL client using `graphql-request`:

```javascript
import { GraphQLClient } from 'graphql-request';
const endpoint = process.env.API_URL;
const token = process.env.API_TOKEN;

export const graphQLClient = new GraphQLClient(endpoint, {
  cache: 'no-cache',
  credentials: 'include',
  mode: 'cors',
  headers: {
    authorization: `Bearer ${token}`,
  },
});
```

After that, set up a Next.js page that fetches data from the CMS using GraphQL.

```javascript
import React from "react";
import Head from "next/head";
import { NextPageContext } from "next";
import { graphQLClient } from "../../config/graphql";
import { SeoMetaTags } from "../../graphql/fragments/SeoMetaTags";

const PAGE_DATA_QUERY = `
  query ServicesQuery {
    servicesPage {
      ${SeoMetaTags}
      name
    }
  }
`;

interface Props extends NextPageContext {
  data: Record<string, any>;
}

/**
 * A page that lists all services we offer
 */
const Services = ({ data }: Props) => {
  const tags = data._seoMetaTags;
  const pageData = data.servicesPage;

  return (
    <>
      <Head>
        <SeoMetaTags tags={tags} />
      </Head>

      {pageData.services.map(s => (
        <h3>{s.name}</h3>
      ))}
    </>
  );
};

Services.getInitialProps = async ({ res }) => {
  const data = await graphQLClient.request(PAGE_DATA_QUERY);

  return { data };
};
```

In a staging environment, we need to point `graphql-request` to our CMS's "draft" endpoint (most CMS's support this workflow). Whenever an editor saves a change to the CMS, they can reload the page to see the changes.

## Remove the need to reload

Reloading the page to see updates works well, but gets tedious for the user that is previewing the changes. What if we could build in a “live reload” feature, that automatically refreshes the staging site after changes are saved? To accomplish a live reload feature, we can:

* leverage a SSR response header to determine if page data has changed
* add a focus hook that will asynchronously fetch the page in the background and compare the new version header

### Set the version header

To set the version header, we will create a hash of the data after it is fetched during Server Side Rendering. We’ll create a utility to keep things clean.

```javascript
// utils/setVersionHeader.ts

import { ServerResponse } from 'http'

/**
 * Sets an `X-version` header that is used to determine when CMS data has changed.
 * @param data The page data
 * @param res The response from the SSR server
 */
export function setVersionHeader(data: Record<string, any>, res: ServerResponse): string {
  // calculate a hash based on the passed data
  const pageDataHash = require('crypto')
    .createHash('md5')
    .update(JSON.stringify(data))
    .digest('hex');

  if (res) {
    res.setHeader('X-version', pageDataHash);
  }

  return pageDataHash;
} 
```

### Add hooks that implement focus and reload behavior

The first hook we will add will simplify the handling of browser focus events.

```javascript
// hooks/useFocus.ts

import { useState, useEffect } from 'react';

/**
 * Hook that returns true if the window is focused and
 * false if not.
 */
export function useFocus() {
  const [state, setState] = useState(null);

  const onFocusEvent = () => setState(true);
  const onBlurEvent = () => setState(false);

  useEffect(() => {
    window.addEventListener('focus', onFocusEvent);
    window.addEventListener('blur', onBlurEvent);

    return () => {
      window.removeEventListener('focus', onFocusEvent);
      window.removeEventListener('blur', onBlurEvent);
    };
  });

  return state;
} 
```

And a hook that wraps `useFocus` that checks the version header and reloads the page if necessary:

```javascript
// hooks/useFocusReload.ts

import { useEffect } from 'react';
import { useFocus } from './useFocus';

/**
 * This works with the useFocus hook to reload the page if data has changed.
 * It works by fetching the current page async, and comparing the X-Version
 * header to the current one (passed in as pageDataHash)
 */
export function useFocusReload(pageDataHash: string) {
  const focused = useFocus();

  useEffect(() => {
    async function handleFocus() {
      if (focused) {
        const res = await fetch(window.location.href, {
          headers: {
            pragma: 'no-cache',
          },
        });

        if (res.ok && res.headers.get('X-version') !== pageDataHash) {
          window.location.reload();
        }
      }
    }

    handleFocus();
  }, [focused]);
}
```

Here’s how to use the hooks we just put in place:

```javascript
// pages/services.tsx

import React from "react";
import Head from "next/head";
import { NextPageContext } from "next";
import { graphQLClient } from "../../config/graphql";
import { SeoMetaTags } from "../../graphql/fragments/SeoMetaTags";
import { useFocusReload } from "../../hooks/useFocusReload";
import { setVersionHeader } from "../../utils/setVersionHeader";

const PAGE_DATA_QUERY = `
  query ServicesQuery {
    servicesPage {
      ${SeoMetaTags}
      name
    }
  }
`;

interface Props extends NextPageContext {
  data: Record<string, any>;
}

/**
 * A page that lists all services we offer
 */
const Services = ({ data, pageDataHash }: Props) => {
  useFocusReload(pageDataHash);

  const tags = data._seoMetaTags;
  const pageData = data.servicesPage;

  return (
    <>
      <Head>
        <SeoMetaTags tags={tags} />
      </Head>

      {pageData.services.map(s => (
        <h3>{s.name}</h3>
      ))}
    </>
  );
};

Services.getInitialProps = async ({ res }) => {
  const data = await graphQLClient.request(PAGE_DATA_QUERY);
  const pageDataHash = setVersionHeader(data, res);

  return { data, pageDataHash };
};

export default Services;
```

To recap what is going on:

1\. An `x-version` header will be set during Server Side Render, based on the CMS API response data. 2\. When the browser receives a focus event, the current page is fetched again in the background 3\. If the header has changed, we reload the page. If not, we do nothing.

**Note:** 
This same technique can be leveraged on _any Single Page App_ to notify users that a new version has been released, and that they should reload the page. In that case, you would typically add a confirmation prompt before reloading on their behalf.

After deploying, you should be able to verify the `x-version` header was set in the browser.

![an example of the x-version header](https://res.cloudinary.com/echobind/image/upload/v1661873451/echobind_blog/mkpzdim3jvvezn1lby7u.png)

(an example of the x-version header)

### Moving to production on Now

Up to this point, we’ve created a Server Rendered Next.js app that will automatically reload on focus if the page data has been updated in our CMS. The final step is to bring the high performance of a static site to our page.

To do that, we will leverage a built in feature built into the Now platform called [Serverless Pre-Rendering](https://zeit.co/blog/serverless-pre-rendering). Similar to the header approach above, we’re going to set a special cache header to cache our pages at the CDN layer. In practical terms, that means our page will be as fast as a static site for the duration that it is cached.

Now’s CDN will send a cached version of the page to the user. If the cache time has expired, it will asynchronously fetch and re-cache the page using a Serverless lambda in the background. This is awesome, because it avoids the “slow for 1 user every x seconds” problem you encounter with many caching strategies.

Let’s add a util to set the proper cache header during Server Side Rendering.

```javascript
// utils/cachePageFor.ts
import { ServerResponse } from "http";

/**
 * This sets a cache header for the specified amount of time. Time is in seconds.
 */
export function cachePageFor(cacheTime: number = 60, res: ServerResponse) {
  if (cacheTime && res) {
    res.setHeader(
      "Cache-Control",
      `s-maxage=${cacheTime}, stale-while-revalidate`
    );
  }
}
```

The important bits here are `s-maxage` and `stale-while-revalidate`. we set `s-maxage` to the number of seconds we'd like the CDN to serve a cached page, and `stale-while-revalidate` powers the async cache update strategy mentioned above.

To use the util, we set a cache time on a per-page basis. For example, we might want our homepage to only be cached for a max of one minute before refetching, but our contact page could be cached significantly longer.

```javascript
Services.getInitialProps = async ({ res }) => {
  const data = await graphQLClient.request(PAGE_DATA_QUERY);
  const pageDataHash = setVersionHeader(data, res);
  cachePageFor(1200) // 20 minutes

  return { data, pageDataHash };
};
```

Once you deploy this code to staging, you should be able to verify that a cached response was returned:

![an example of the x-version header](https://res.cloudinary.com/echobind/image/upload/v1661873458/echobind_blog/hhtbcmwn5mi2pvn2opad.png)

### What happens if you deploy a code update during this time?

Now will intelligently clear caches for you every time you deploy! See <https://zeit.co/docs/v2/network/caching/#cache-invalidation> for more detail.

### Alternate approach: use Next.js’s static export

What if you can’t or don’t want to host on Now? As I mentioned earlier, Next.js also supports exporting a static site. Using this, we can change our build pipeline to export a static version for production.

Unfortunately, this requires adding some configuration to your app, especially if you have dynamic pages. Here’s an example config that filters out dynamic pages and populates sub-pages based on the results of a GraphQL query:

```javascript
// next.config.js

const GraphQLClient = require('graphql-request').GraphQLClient;
const endpoint = process.env.API_URL;
const token = process.env.API_TOKEN;

const graphQLClient = new GraphQLClient(endpoint, {
  headers: {
    authorization: `Bearer ${token}`,
  },
});

const DYNAMIC_PAGES_QUERY = `
  query services {
    allServices {
      detailPage {
        slug
      }
    }
  }
`;

module.exports = {
  exportPathMap: async function(defaultPathMap, { dev, dir, outDir, distDir, buildId }) {
    // filter out all dynamic pages (ex: services/[slug].tsx)
    const filteredKeys = Object.keys(defaultPathMap).filter(key => !/\[/.test(key));
    let filteredPathMap = {};
    filteredKeys.forEach(key => (filteredPathMap[key] = defaultPathMap[key]));

    // Fetch data for dynamic pages
    const pages = await graphQLClient.request(DYNAMIC_PAGES_QUERY);

    // dynamically add services pages that have a detail page
    const servicesPages = pages.allServices.reduce((obj, service) => {
      const slug = service.detailPage ? service.detailPage.slug : null;

      if (slug) {
        obj[`/services/${slug}`] = { page: '/services/[slug]', query: { slug } };
      }

      return obj;
    }, {});

    return {
      ...filteredPathMap,
      ...servicesPages,
    };
  },
}; 
```

You’ll also want to add a hook from your CMS that triggers an export and deployment. Generally, it’s best to leverage a script in `package.json` to keep things clean.

![example of setting up a hook to build the production site statically](https://res.cloudinary.com/echobind/image/upload/v1661873847/echobind_blog/ronqxyf5xhncejzomr6y.png)

(example of setting up a hook to build the production site statically)

You could also leverage the custom webhook to run a workflow on GitHub Actions that accomplishes the same thing.

### Enjoy your non-static static site!

We now have what seems to be the best of both worlds. Our staging site acts like a traditional server that reflects changes as soon as they are saved in the CMS. Due to the CDN caching, our production site is just as fast as a static site, with the added bonus of never being out of date for longer than our cache time. We never need to wait on a site rebuild.

We’re currently rebuilding the Echobind site, which leverages this technique. Look for it to be released soon!

### Thanks to ZEIT

Massive props to the team at ZEIT for not only adding this feature to the Now platform, but also for writing a blog post on [Serverless Pre-Rendering](https://zeit.co/blog/serverless-pre-rendering) that demonstrated the focus reload technique.

---

[View on echobind.com](https://echobind.com/post/static-sites-without-the-static)

---

# Product Design ft. Hello, Startup — the User

> Dec 23, 2019 | Let's discuss user-centered design, which will help us to design our product with a great user experience from the start.

_By Ashley Nelms · 2019-12-23_

## Product Design ft. Hello, Startup — the User

[In the first part of the series](https://echobind.com/post/building-products-ft-hello-startup) I talked through [Hello Startup’s](https://www.hello-startup.net/) process to coming up with a solid idea and validating it before you even begin the building process. In this installment of the series, we’ll discuss user-centered design, which will help us to design our product with a great user experience from the start.

### Designing for Users

When it comes to software the user only understands what they are directly seeing. For someone who needs a ride, a ride sharing app is a button on their phone that orders a car. For someone using a smartphone, it consists of the parts they can see, hear and touch. Users don’t see what’s hidden beneath the surface of it such as the the operating system or hardware. This is what many of us know as the [iceberg secret](https://www.joelonsoftware.com/2002/02/13/the-iceberg-secret-revealed/).

![iceberg](https://res.cloudinary.com/echobind/image/upload/v1661873566/echobind_blog/hy175geqtyrijzfidhqc.jpg)

_You know how an iceberg is 90% underwater? Well, most software is like that too — there’s a pretty user interface that takes about 10% of the work, and then 90% of the programming work is under the covers. And if you take into account the fact that about half of your time is spent fixing bugs, the UI only takes 5% of the work. And if you limit yourself to the visual part of the UI, the pixels, what you would see in PowerPoint, now we’re talking less than 1%._

> _That’s not the secret. The secret is that_ **_People Who Aren’t Programmers Do Not Understand This_**_._ 
> **_—_** [**_Joel Spolsky_**](https://www.joelonsoftware.com/) **_in_** [**_The Iceberg Secret, Revealed_**](https://www.joelonsoftware.com/2002/02/13/the-iceberg-secret-revealed/)

If you were to show someone a user interface that doesn't look good then they are going to assume the whole app is bad. While the saying goes to never judge a book by its cover that is exactly what’s going to happen with poor presentation. Hello Startup sums it up well in saying that “_design is fundamentally about how to present information so other people can understand it and use it_”.

“Designer” may not be part of everyone’s official title but everyone is certainly a designer to a degree. Over time and through experience with many projects, you begin to recognize what does and doesn’t work and how a specific audience may react to the design. This is why design isn't about just making it look good, it’s also about helping users achieve their goals. This starts with an understanding of the user.

### User-Centered Design

![Three men discussing user design](https://res.cloudinary.com/echobind/image/upload/v1661873574/echobind_blog/sawivmrxbxudehbrmadr.jpg)

If software causes someone to feel dumb because they can’t understand it, then the software has failed. If a user is struggling more to accomplish their goals than they were prior to using the software, then its design should have a second look. It’s not about the beautiful buttons or number of features but how easy it can help a user accomplish their goals.

When building any software it’s essential that you have an understanding of the users. Yes, a feature may be cool but if its not something a user actually needs then its implementation should be reconsidered. From day one design should be incorporated into the development process using the five principles of user-centered design.

#### 1\. User Stories

_User stories_ are short descriptions of what is being built from the perspective of the user. They should tell you who the user is, what they are trying to accomplish and why they need it. The stories help overcome the [curse of knowledge](https://en.wikipedia.org/wiki/Curse%5Fof%5Fknowledge) by making you more empathetic to the user and considering their perspective. At Echobind, our user story template is as follows.

_As a \_\_\_\_\_, I want to \_\_\_\_\_ so that \_\_\_\_\_._

The user stories will serve as the “source of truth” for development and what the final product should accomplish.

#### 2\. Personas

The users for a software’s audience will vary and trying to please everyone only spells trouble. Instead, design should be done for _personas_. These are fictional characters that represent a real user of the software who has specific goals, traits and desires. Having personas handy forces you to think about real people and consider various aspects about them such as their personalities. To gain the most benefit from personas Hello Startup suggests they should include:

* Name
* Age
* Short bio
* Work history
* Skills
* Goals

#### 3\. Emotional Design

Have you ever yelled at your printer for breaking down for the hundredth time or love an app so much that you swear by it? Whether we realize it or not software invokes emotional reactions similar to how we’d interact with other humans. This is why more and more apps are starting to have a touch of humanity to them, my personal favorite being Twitter’s fail whale.

![Twitter error screen](https://res.cloudinary.com/echobind/image/upload/v1661874941/echobind_blog/r1zaoylsmqwvnkxq464p.png)

Imagine how you’d feel if you go to a site experiencing issues and all you’re met with is a generic error page. Or how about no error at all? While it still invokes an emotional response it will be that of frustration compared to seeing a page with a more friendly, human touch.

#### 4\. Simplicity

You don’t _create_ simplicity, you reduce unessentials until what’s left is simple and essential. No project starts with a blank slate. There’s knowledge, ideas and so many other things to consider. Think of it as the first draft of an essay. It’s always a mess and you reduce, cut out and refine it until you’re left with its core purpose.

> _“The sculpture is already complete within the marble block, before I start my work. It is already there, I just have to chisel away the superfluous material.”_ 
> _—_ [**_Michelangelo_**](https://www.goodreads.com/quotes/1191114-the-sculpture-is-already-complete-within-the-marble-block-before)

![Michelangelos David](https://res.cloudinary.com/echobind/image/upload/v1661874949/echobind_blog/ekv1c9svnhxs3x4tj60i.jpg)

[The same is done with software and how we achieve MVP](https://echobind.com/post/product-design-ft-hello-startup-the-mvp). When building new software, there are tons of ideas, concepts and feature requests. Like with the essay, you cut down and remove things until you are left with the very core of the software’s design. Instead of thinking about what your app should do, think more of what it shouldn’t do to help you reduce and cut out the unnecessary.

Make no mistake, however. Software can be incredibly complex but using it should be simple. The next principle of user-centered design helps us see if we’ve accomplished this.

#### 5\. Usability Testing

No matter how much validation you do or how much more you think you know than users, you will still be wrong. The ultimate test to seeing if all the work so far will work out is by putting the design in front of real users. The goal here is to see how people will use the software to accomplish specific tasks.

In order for the usability testing to be valid there is to be no interference. Even if the users make mistakes and start to become frustrated it will bring to light issues that can be resolved and prevent in the future.

### Up Next

In the next part of the series, we’ll continue through Hello Startup’s chapter on product design, this time focusing on the more visual aspects of design. Remember, this is only a fraction of the valuable information that can be found in this book and I highly recommend picking up your own copy for more in-depth explanations and examples.

Until next time!

---

[View on echobind.com](https://echobind.com/post/product-design-ft-hello-startup-the-user)

---

# Onboarding is Like Hosting a Party

> Dec 18, 2019 | We’ve worked hard to hone our onboarding process to set our new hires and team up for success.

_By Sarah Case · 2019-12-18_

![Three women drinking wine around a dinner table](https://res.cloudinary.com/echobind/image/upload/v1661873127/echobind_blog/zkbjecny9diq4otp8ivs.jpg)

Updated On: April 5, 2022

There are two types of party hosts. There’s the host who yells that the door is open and waves toward the makeshift bar when you walk in. You look nervously at the random assortment of beverages and mixers trying to figure out where to begin, but figure it’s a safe spot to linger while you scan the room in search of a familiar face (at least you’ll look busy). On the other end of the spectrum, you have the host who greets you at the door, grabs your coat, helps get you settled with a drink and facilitates an introduction or two so you immediately feel part of the fun.

If you’ve run with this crowd for years, the first type of host works — you’re already part of the group, know what beverage you want to whip up (because you make it every time) and who you want to chat with first! However, if you’re new to the neighborhood (or a new hire), you’ll likely feel significantly more comfortable and welcome with the second type of hostess.

![Multi-colored welcome sign](https://res.cloudinary.com/echobind/image/upload/v1661873134/echobind_blog/ihozg59ru4fczzxqco02.jpg)

It probably comes as no surprise that a great onboarding process aligns more with the latter — the gracious _hostess with the mostest_ who immediately makes you as the guest (or new hire) feel welcome and part of the team. As the Vice President of Operations at Echobind, where we’ve done a fair amount of hiring over the last 12 months, we’ve worked hard to hone our onboarding process to set our new hires and team up for success. To be the _hostess with the mostest,_ here are five areas we’ve focused on:

1. **_Start onboarding early and be consistent_.** We’ve made each step in the process feel genuinely like Echobind — our new Team page highlights our team, values and ethos, which is then reflected in our job descriptions, how we structure interviews, etc. Onboarding actually starts before your new hire’s first day, so you shouldn’t wait until their first day to start showcasing your company culture, values and team.
2. **_Give them everything they need to hit the ground running_.** Much like making sure your new hire’s workspace is set up, we do the same as a remote team. We make sure they have their laptop, account logins and company policies in hand so they can get started. But we don’t just hand them a ton of info and leave them to their devices — their manager, me and others jump in to show them the ropes.
3. **_Set up shadowing to get started_.** Before a new hire starts on client work solo, we have them shadow a few team members so they can see how we use our systems, communicate with each other and our clients, etc. This way they can learn by watching and doing side-by-side, and then feel that much more confident diving in.
4. **_Meeting the team is critical, and a step we value particularly as a remote team._**We schedule short and sweet intro calls so that our new team member gets a chance to chat with everyone off the bat.
5. **_Track progress early to ensure things are moving in the right direction_.** We have a 30-, 60-, 90-day check ins for each new hire, which might sound like a lot but have been tremendously valuable. Our goals are twofold: first, make sure we’re on the same page and that the new hire’s experience is matching the expectations we set (we always ask if anything has been surprising). Second, identify/validate strengths and growth opportunities, which can then be incorporated in that person’s goals, can inform what projects that person gets put on, etc.

It goes without saying, that technology helps power our onboarding process (and everything else we do, for that matter). Some of the tools we use are:

* 15Five: We’ve found this platform to be great for 1:1s, goal tracking, performance reviews.
* Notion: Document everything. Notion is where our processes, handbooks/playbooks, notes, etc. all live. We love Notion.
* Discord: Like so many teams (remote or otherwise), we use Discord to stay in touch. It’s quick and convenient and helps facilitate collaboration internally and with our clients all in the same place.

---

[View on echobind.com](https://echobind.com/post/onboarding-is-like-hosting-a-party)

---

# 4 Ways to Optimize an Agile Environment with Nudge Management

> Dec 17, 2019 | What if I told you, we could subtly tap into the unconscious mind to improve working conditions and productivity? Well, we can with something called nudge management.

_By Anne Tolmie · 2019-12-17_

From a Behavioral Economic Lens

What if I told you, we could subtly tap into the unconscious mind to improve working conditions and productivity? Well, we can with something called _nudge management._ Today, we are going to cover what nudge management is, and four ways you can apply it in an agile environment to make for a happy team.

## Nudge Management — What is it and Where did it come from?

First, let’s start with a solid definition.

> _Nudge management is a management approach that applies insights from behavioral science to design organizational contexts so to optimize fast thinking and unconscious behavior of employees in line with the objectives of the organization. -Erbert and Freibichler 2017_

Unconscious behavior? Let’s break this down. Nudge management was inspired by thinking of the mind as two very different processes. Psychology knows this as the [_dual-process theory_](https://en.wikipedia.org/wiki/Dual%5Fprocess%5Ftheory). The first process is the unconscious process. The second process is the conscious process. The unconscious process is our emotional/intuitive side, while the conscious process is our logical/reflective side.

I look to metaphors to better understand concepts. [The elephant and the rider metaphor](http://sourcesofinsight.com/the-elephant-and-the-rider/) refers to our emotional side as the elephant and our logical side as the rider. Often we go through life as the rider, believing we are in control as we rely on reason to guide us. At times, the elephant overpowers the rider, and our emotions take over. Our emotions may even cause turbulence. We react in ways we do not understand. We may behave irrationally. For many of us, our emotions remain unconscious unless a person works hard to bring the unconscious to the surface.

![Man washing an elephant](https://res.cloudinary.com/echobind/image/upload/v1661873782/echobind_blog/gxdxt6l2jpojplnbknzp.jpg)

# What are Knowledge Workers?

Another term to understand is [_knowledge workers_](https://en.wikipedia.org/wiki/Knowledge%5Fworker)_._ Knowledge workersare people whose job requires them to _think for a living_. At Echobind, our team is paid to think and solve problems. As an account manager here, I often consider how I can improve the working conditions for my team so they can solve problems faster and make our clients happy. When I came across an [article](https://jorgdesign.springeropen.com/articles/10.1186/s41469-017-0014-1#citeas) on how to increase knowledge worker productivity, I was pleased to discover that we are already implementing 3.5/4 of the suggestions.

![Painting for a downward spiral](https://res.cloudinary.com/echobind/image/upload/v1661874661/echobind_blog/lbonr5ybvxk1fekvrx2o.jpg)

## 4 ways to Optimize an Agile Environment

Now, let’s dive into the four ways you can optimize an agile work environment to tap into the unconscious behavior of your team.

### **1\. Improve Meeting Productivity**

Is it me, or do people dislike meetings? It is no wonder that they do when approximately 50% of knowledge workers’ time is spent in meetings (Erbert and Freibichler 2017). On one hand, it makes sense that a knowledge worker such as a developer needs to be in meetings. They need to give their daily reports and any blockers they are facing. They need to share knowledge with other team members on the project. Software is not created in a vacuum, so a developer cannot work solo all the time. But, the code must be written. This cannot happen if a developer’s time is consumed by meetings. So what can be done to improve meeting productivity?

![Person sitting with laptop in the middle of a clock painting](https://res.cloudinary.com/echobind/image/upload/v1661873257/echobind_blog/czd9zrvdvseyosdsdkrq.jpg)

Meetings — We do them well. We do not have meetings to have meetings. As an account manager, it’s my job to have an agenda for every meeting to keep everyone on track. If I cannot write an agenda, it is a good indicator we do not need to have a meeting. We do not schedule follow up meetings. Instead, I spend some time after a meeting creating action items. This is a win for everyone because I love making checklists and my team can get back to work. The best part — they do not have to worry about attending a followup meeting to talk about what was discussed at the meeting prior.

Standups — an agile necessity. Something I like to do is have my team post a written status in [Slack](https://slack.com/) instead of video conferencing (yes, we are remote). This allows them to post their updates when it’s convenient for them and is less note-taking for me. Another win-win. A tool I recently starting using is called [Status Hero](https://statushero.com/). I highly recommend it. My favorite feature — it prompts your team to include an emoji about how they are feeling. You can bet I am interested in the feelings of my team. 😉

![Board meeting](https://res.cloudinary.com/echobind/image/upload/v1661873710/echobind_blog/f1ruqamhsokw5zvjt7oq.jpg)

The [article](https://jorgdesign.springeropen.com/articles/10.1186/s41469-017-0014-1#citeas) suggests a different approach to improving meeting productivity. They suggest changing the social constructs around the default of meeting times. The norm or default duration of a typical meeting is 60-minutes. They say to change the default duration to 30-minute meetings. At Echobind, we schedule the appropriate amount of time for the task at hand. This goes back to what I said about not having meetings just to have meetings. Don’t schedule a meeting for 60 minutes when all you need is 30 minutes. However, what the article is saying is, by changing the expectations of what is considered a typical meeting length, more people will comply with this organizational construct because they will not want to stand out as _the one scheduling long meetings._ If you build the construct, professional people generally try to follow it.

### 2\. **Improving Planning**

Being that one of our core values at Echobind is transparency, I’ll be honest — planning is an area I would like to help my developers improve in. No, I am not saying that developers are poor planners. Many developers are [INTJs](https://www.16personalities.com/intj-careers) — the J standing for judging, which makes them exceptional planners according to the [Myers-Briggs Type Indicator](https://en.wikipedia.org/wiki/Myers%E2%80%93Briggs%5FType%5FIndicator). Let me tell you specifically what I mean. In my experience, developers are too optimistic about what they can get done. This makes trying to plan a sprint a nightmare for me. It is not their fault though. Many people do this, and it has nothing to do with being a developer. It is known in psychology as the [planning fallacy](https://en.wikipedia.org/wiki/Planning%5Ffallacy). It is the occurrence of people underestimating the amount of time a task will take due to being overly optimistic.

![Whiteboard with yellow post-its](https://res.cloudinary.com/echobind/image/upload/v1661874157/echobind_blog/imajusqtph9qzmq2dci6.jpg)

The article suggests using _implementation intentions_ as a remedy. The [article](https://jorgdesign.springeropen.com/articles/10.1186/s41469-017-0014-1#citeas) states that

_…the idea is that employees plan and openly communicate their key objectives, thereby committing themselves to these plans in front of their peers._

In my opinion, a sprint planning session does just that. The developers break down the task, assign it a point based on the complexity (we use the [Fibonacci scale](https://en.wikipedia.org/wiki/Fibonacci%5Fscale%5F%28agile%29)), and then someone takes ownership of the ticket in front of their peers. So, why does this not work? It all goes back to the planning fallacy. So here we find ourselves in a [loop](https://www.thoughtco.com/definition-of-loop-958105). And not to knock the authors’ suggestion, but I may have an alternative solution. I propose that developers should be empowered to self manage their expectations through reflection.

![Folder with empower on it next to a pen and phone](https://res.cloudinary.com/echobind/image/upload/v1661874272/echobind_blog/zja2c57yp4iei4sf2epr.jpg)

#### How to Empower Self Management

To self manage, they need to evaluate their estimations with the goal of becoming more aware of their accuracy. They will need candor and a way to track time. When a developer picks up a ticket, they should start time tracking, **account for breaks**, and once the ticket is complete, they should reflect upon the accuracy of the estimation by leaving a note on the ticket. They could simply indicate: accurate or inaccurate. Developers should be familiar with this, it is just like a boolean, either true or false. Let’s follow that up with an [if statement](https://www.computerhope.com/jargon/i/ifstatme.htm). If false (inaccurate), indicate what it should have been. You may have noticed that I bolded **account for breaks.** Yes, developers need breaks and they should include them in the time tracking. Usually the more complex the ticket, the more breaks they need. I have heard developers say a countless number of times:

_It was when I walked away that I solved the problem._

### **3\. Improving Task Productivity**

I mentioned earlier, a productive developer is a happy developer. Many of the developers I have worked with and know in my personal life enjoy productivity for the pure sake of being productive. Not only that, but they also need to be to get their work done. According to the [article](https://jorgdesign.springeropen.com/articles/10.1186/s41469-017-0014-1#citeas),

_Unplanned interruptions are among the most effective productivity killers for knowledge workers._

Unfortunately, there are many workplace interruptions in an agile environment with one of the main ones being [Slack](https://slack.com/). Don’t get me wrong. Slack is great. But with all the notifications sounding off, it sure can stomp on productivity.

So, how is a developer to achieve a sense of [deep work](https://www.calnewport.com/books/deep-work/)? At Echobind we have Slack etiquette that helps eliminate unnecessary messages. This ultimately leads to higher productivity for our team.

1. We encourage the team to set their status during our core working hours instead of messaging a specific channel or person(i.e. _relocating, taking the dog out_).
2. We ban using @here or @channel unless it is urgent.
3. We encourage thread-use to avoid clogging up channels with conversations. That way people are not reading things that do not pertain to them.
4. We have a #life channel. It’s optional to join. If you want to see pictures of your co-workers’ dogs or kids — great! If you don’t — great. We leave it up to each individual to decide.
5. We encourage people to close Slack or use the “Heads down” if they don’t want to be interrupted.

![Man on cellphone walking by Productivity board](https://res.cloudinary.com/echobind/image/upload/v1661873876/echobind_blog/s9amgiadgpbc1pakva2s.jpg)

### 4\. Knowledge Sharing

We love sharing at Echobind. Especially, knowledge. I have found that many of my co-workers have diverse backgrounds. The more I get to know my team, I am blown away to discover all the hidden gems. Just recently I discovered that one of my co-workers, [Joe](https://twitter.com/jsjoeio), has a background in marketing and almost pursued a master’s degree in Italian linguistics. You can bet I run to him when I need to come up with something catchy for Twitter!  
The point being, we all have knowledge and experiences that make us experts in certain areas and we do our best to capitalize on this.

Some ways we do this are:

1. We have a _Today I Learned_ or #TIL channel in Slack. (We also have a monthly [This Month We Learned Blog](https://echobind.com/post/this-month-we-learned-august-2019) post where we share some of these learnings with you!)
2. We have lunch and learns.
3. We encourage our team to make write-ups/case studies if we learned something new on a project.
4. We have something called investment time. Read more about it [here](https://echobind.com/post/the-roi-of-self-directed-investment-time-for-software-engineers).
5. We have a 15-minute rule. If someone is stuck on something for more than 15 minutes, they must seek help.

Knowledge is wealth. I am glad to work somewhere that nudges us to share the wealth.

![person holding gold-colored coins](https://res.cloudinary.com/echobind/image/upload/v1661873797/echobind_blog/da3gwylyrzdzh1r1xwyl.jpg)

I hope you enjoyed looking at Echobind from a behavior economic lens. I encourage you to look at your workplace and see if any of these nudge management tips can be generalized to your work environment. If you end up implementing anything, leave me a comment and let me know how it went. I would love to hear from you! Remember the subtle effects of nudge management may be hard to detect at first but it’s worth the thought.

#### **Resources**

Ebert, P., Freibichler, W. Nudge management: applying behavioural science to increase knowledge worker productivity. _J Org Design_ **6,** 4 (2017) doi:10.1186/s41469–017–0014–1

---

[View on echobind.com](https://echobind.com/post/4-ways-to-optimize-an-agile-environment-with-nudge-management)

---

# TypeScript: Function Declarations vs. Function Expressions

> When using React with Typescript, let's look at using components as function declarations vs. function expressions.

_By Joe Previte · 2019-12-13_

When I first started learning TypeScript and using it with React, I followed patterns. A friend showed me how to type a component. I used that as an example whenever I created a new component. This example looked something like this:

```javascript
const MyComponent: React.FC = () => <h1>Hello, world!</h1>
```

Experimenting with this pattern, I thought to myself, “If I want to declare a component using the function keyword, then I bet I can do the same thing.”

```javascript
function MyComponent(): React.FC { 
  return <h1>Hello, world!</h1>
}
```

Sadly, this is not valid. Instead of investigating deeper, I decided to stick with what worked (using function expressions like the first example). Eight months later, after diving deeper into TypeScript, I’ve finally learned the difference and understand why my first attempt didn’t work.

## Typing a React Component as a Function Expression

When we type a React component as a function expression (i.e. const MyComponent: React.FC), we have to ask ourselves, “what are we annotating and what type of value does this variable `MyComponent` hold?”

We’re annotating the _function type_ because this variable holds a _function._ React.FC indicates a “React Function Component”. So that’s why we type it this way.

## Typing a React Component as a Function Declaration

In the other instance, when we type a React component as a function declaration (i.e. `function MyComponent`), we ask the same thing.

This time, we’re annotating the _function return type_. This explains why we can’t use the same type! We instead need to tell TypeScript, “Hey! This function here is going to return a React component.” So what does that look like? Like this:

```javascript
function MyComponent(): React.ReactNode {
  return <h1>Hello, world!</h1>
}
```

Now, TypeScript knows that this function will return some type of `ReactNode`. If you haven’t seen `ReactNode` before, you’ll notice from the `@types/react` declaration file that it is a union type that looks like this:

```javascript
type ReactNode = ReactChild | ReactFragment | ReactPortal | boolean | null | undefined;
```

These are all the valid things that can be returned by a component. Feel free to take a look at the [source code here](https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/react/index.d.ts#L201).

And now you know how to properly type a React component as both function expressions and function declarations! Check out the [react-typescript-cheatsheet](https://github.com/typescript-cheatsheets/react) to learn more.

## Typing Props with a Function Expression

When your components accept props, it’s important to know where those get added in as well. Here’s an example:

```javascript
type Props = {
  name: string;
}
const MyComponent: React.FC<Props> = ({ name}) => <h1>Hello, {name}!</h1>
```

In addition, we can use a handy type called `PropsWithChildren` which will automatically include the `children` prop for us:

```javascript
type Props = {
  name: string;
}
const MyComponent: React.FC<PropsWithChildren<Props>> = ({ name, children }) => <h1>{children}, {name}!</h1>
```

## Typing Props with a Function Declaration

We can do the same thing with a function declaration:

```javascript
type Props = {
  name: string;
}
function MyComponent({ name }: Props): React.ReactNode {
  return <h1>Hello, {name}!</h1>
}

```

And the same for using `PropsWithChildren` :

```javascript
type Props = {
  name: string;
}
function MyComponent({ name }: PropsWithChildren<Props>): React.ReactNode {
  return <h1>{children}, {name}!</h1>
}
```

Pretty neat, huh?

Credit to [ Chau Tran](https://medium.com/u/e9317aaf0ad5?source=post%5Fpage-----e433ac8d6938-----------------------------------) for teaching me about this on [Twitter](https://twitter.com/Nartc1410/status/1206697327970455553?s=20)!

**LAST UPDATED:** _December 17, 2019_

---

[View on echobind.com](https://echobind.com/post/react-with-typescript-components-as-function-declarations-vs-function-expressions)

---

# Zero to Dark Mode in React Native

> Dec 13, 2019 | With the releases of Android 10 and iOS 13, mobile users and developers of these platforms gained a new system-wide feature: dark mode.

_By Josh Buchea · 2019-12-13_

With the releases of Android 10 and iOS 13, mobile users and developers of these platforms gained a new system-wide feature: **dark mode**. I prefer dark UIs so I was stoked for this feature! Echobind designer Michael Dang recently outlined some of the [advantages of dark theme user interfaces](https://echobind.com/post/advantages-of-dark-theme-user-interfaces).

For now, the user’s preference for dark mode isn’t available in React Native out-of-the-box ☹️ Although, it appears a new `Appearance API` providing access to the user’s preference for dark mode should be available in React Native sometime in the future since [iOS support has already landed on](https://github.com/react-native-community/discussions-and-proposals/issues/126) `master`.

Fortunately, there are several packages available on [npm](https://www.npmjs.com/) that provide this functionality 😊 . Two popular packages are [react-native-appearance](https://www.npmjs.com/package/react-native-appearance) and [react-native-dark-mode](https://www.npmjs.com/package/react-native-dark-mode). I prefer [react-native-appearance](https://www.npmjs.com/package/react-native-appearance) because I like that it’s maintained by the [Expo organization](https://github.com/expo) and is officially supported in managed Expo projects.

To detect the user’s preference for dark mode on supported platforms (Android 10+, iOS 13+) just add [react-native-appearance](https://www.npmjs.com/package/react-native-appearance) to your React Native project, import the `useColorScheme` hook, and you’re off to the races! 🏇

Let’s look at a minimal example:

```javascript
import * as React from 'react';
import { Text, View } from 'react-native';
import { useColorScheme } from 'react-native-appearance';

const colorSchemes = {
  light: {
    background: '#fff',
    text: '#333',
  },
  dark: {
    background: '#333',
    text: '#fff',
  },
};

const DarkModeExample = () => {
  const colorScheme = useColorScheme();
  const colors = colorSchemes[colorScheme] || colorSchemes.light;

  return (
    <View
      style={{
        alignItems: 'center',
        backgroundColor: colors.background,
        flex: 1,
        justifyContent: 'center',
      }}
    >
      <Text style={{ color: colors.text, fontSize: 24 }}>
        zero to dark mode
      </Text>
      <Text style={{ color: colors.text }}>
        color scheme: {colorScheme}
      </Text>
    </View>
  );
}

export default DarkModeExample;

```

The example provided is intentionally minimal. It’s just enough to determine if dark mode is enabled and modify styles accordingly. You may choose to pull the **userColorScheme** hook into individual components as we’ve shown in the example, or you may wish to take things a step further and integrate dark mode into your app-wide theme. The power is yours, but it’s up to you how you use it. Now go forth and **dark mode all the things**! 😎

## See also:

* [Appearance — Expo Documentation](https://docs.expo.dev/bare/unimodules-full-list/)
* [Dark Mode — Visual Design — iOS — Human Interface Guidelines](https://developer.apple.com/design/human-interface-guidelines/ios/visual-design/dark-mode/)

***Learn more about our [React Native capabilities](/capabilities/react-native-app-development).***

---

[View on echobind.com](https://echobind.com/post/zero-to-dark-mode-in-react-native)

---

# Clear the Clutter with Fragments

> Dec 12, 2019 | This is a game-changer for working in React Native! Fragment support reduces the complexity and increases the readability of your code.

_By Jenn Robison · 2019-12-12_

I have been developing React Native applications for about two years, and until just recently I had no knowledge of fragments. I found myself doing a peer review with some empty element tags and I thought it might be a mistake. I took to Google and quickly found an article from [reactjs.org](https://reactjs.org/blog/2017/11/28/react-v16.2.0-fragment-support.html) announcing fragment support in v16.2.0\. I was so excited! In my early days of React Native development, I found myself frustrated that I would have to wrap sets of elements in a <View> just to satisfy the JSX expression.

This is a game-changer for me! It reduces the complexity and increases the readability of your code. There is no uncertainty if that View is necessary and how it might be affecting the rendering of your screen or component.

Take this as an example. I have a screen that I may or may not render a couple of lines of styled text within another View that is already styled. I create a conditional and tell it to render to more Text elements, but it is not happy with me. My editor is letting me know that the JSX element is expecting all items to be within one containing parent.

![React code in Visual Studio Code](https://res.cloudinary.com/echobind/image/upload/v1661873358/echobind_blog/krnzc8qkmttwydjgubmo.png)

Two elements with no parent, and unhappy linter

![Parsing error in Visual Studio Code](https://res.cloudinary.com/echobind/image/upload/v1661873365/echobind_blog/ay0trl6wm1q4s0v92hba.png)

JSX Parsing error

I can resolve this error by wrapping the two text components inside a container:

![React code in Visual Studio Code](https://res.cloudinary.com/echobind/image/upload/v1661872717/echobind_blog/uwjlit9d0lkgvkpvenll.png)

JSX contained within a parent element

But why add that extra node in the DOM, along with the baggage it might be brining. In this case, our container is a view, which has style props, etc.

A much cleaner approach is the use of a fragment, which looks like this:

![React code in Visual Studio Code](https://res.cloudinary.com/echobind/image/upload/v1661873372/echobind_blog/xhtsfhdlephzincznatm.png)

Usage of a fragment

As a developer, I now can see that this is just a way to group these children. I don’t need to dig into that container in order to determine why my text elements are not properly laid out. I’ve also reduced the extra noise in the DOM.

You can also utilize <React.Fragment></React.Fragment>. Personally I think it looks cleaner without. In fact, if you utilize eslint it will actually tell you it prefers the usage of the shorthand <></>.

I’m always up for shortcuts, that save me keystrokes and make for more readable projects!

---

[View on echobind.com](https://echobind.com/post/clear-the-clutter-with-fragments)

---

# Styling with :focus-within

> Dec 09, 2019 | We’d like to share how one CSS pseudo-class can change the way you style forms. That pseudo-class is :focus-within.

_By Echobind Team · 2019-12-09_

We’d like to share how one CSS pseudo-class can change the way you style forms. That pseudo-class is `:focus-within`.

## What is `:focus-within`?

> _The :focus-within CSS pseudo-class represents an element that has received focus or contains an element that has received focus. In other words, it represents an element that is itself matched by the :focus pseudo-class or has a descendant that is matched by :focus. (This includes descendants in shadow trees.) —_ [_MDN Docs_](https://developer.mozilla.org/en-US/docs/Web/CSS/:focus-within)

Or, succinctly:

> _It selects an element if that element contains any children that have :focus. —_ [_Chris Coyier_](https://css-tricks.com/almanac/selectors/f/focus-within/)

## How can I use it?

There are many creative use-cases for this pseudo-class; a common use-case is applying focus styles to the parent of a focusable element. Here are a couple of examples:

1. **Input field with icon and button**

In this example, the container element uses a class `.input-wrapper` to identify itself as the parent of focusable content.

```javascript
<div className="input-wrapper">
   <i className="fas fa-search" />
    <input
      id="input"
      placeholder="What are you looking for?"
      autoComplete="off"
    />
    <button>Search</button>
</div>
```

With that class handy, we can target the parent to display styles whenever one of its children is focused.

```javascript
.input-wrapper:focus-within {
  /** Add desired outline, focus styles here */
  box-shadow: 0px 0px 10px 0px var(--primary-color);
  transition: box-shadow 250ms ease-in;
}
```

[Click to see the full source code here.](https://codesandbox.io/s/focus-within-example-1-vlnxv)

When either the input or button is focused, the parent “container” element displays an animated box-shadow to give visual focus.

**2\. List of items with focusable content**

Here’s an example to demonstrate the usefulness of this particular pseudo-class. A list of forms is displayed, and when an input field or button is focused, the individual list item is highlighted with a different-colored background to indicate focus.

_Providing location context to your users is considerate, pragmatic and delightful._

This is how it’s achieved in the code:

```javascript
// index.html
<ul>
  <li>
    <h2>Item 1</h2>
    <form>
      <label for="field-1">Field 1:</label>
      <input placeholder="focus me for styles" name="field-1" />
      <button>button</button>
    </form>
  </li>
</ul>
// styles.css
li:focus-within {
  background: #f7dce9;
}
```

[Click to see the full source code here.](https://codesandbox.io/s/focus-within-example-2-lfbbj)

By attaching the `:focus-within` pseudo-class to list items, the list items are listening for any descendants who are focused, and then applies its styles. In this instance, the background color of the list item updates to be light pink.

For effect, we can take it a step further. When any element within the form is focused, the button color also changes. This is done by targeting the button when the list item detects any focused children.

```javascript
li:focus-within button {
  background: #9dddca;
}
```

## Conclusion

There are so many creative possibilities out there using `:focus-within`. We encourage you to see how you can improve your styles and explore your creativity with this handy trick!

**Note**: There is no support for IE or Edge.

![Browser Compatibility screenshot](https://res.cloudinary.com/echobind/image/upload/v1661873869/echobind_blog/ejjekdjn77ejaidywanp.png)

---

[View on echobind.com](https://echobind.com/post/styling-with-focus-within)

---

# Reducing Costly Renders During Gesture Animations in React Native

> Dec 09, 2019 | Let’s jump into how we can reduce costly re-renders for gesture animations.

_By Isaiah Grey · 2019-12-09_

Building highly performant animations in React Native can be tricky, particularly when dealing with gestures. Gesture animations are tricky due to the frequency the events from the gesture handler are fired, sometimes only 30–40 milliseconds apart or less.

Let’s jump into how we can reduce costly re-renders for gesture animations.

Typically, when we want to track a value in a React component, in this case, **offsetY** in the example below, the default strategy is to use **setState** when the value changes. This isn’t optimal since a small interaction will potentially trigger 20–30 events, resulting in 20–30 re-renders. This would cause many UI frames to be dropped, causing elements to jump across the screen unexpectedly, instead of a transitioning across in a fluid motion.

To avoid this, first, we are going to track the animated style value coming from our gesture event as an **Animated.Value**.

Next, when the **onGestureEvent** callback is fired, we use the **setValue** method from the **Animate.Value** instance to modify the native node directly.

```javascript
 import React, { Component } from 'react';
  import { Animated, View } from 'react-native';
  import { PanGestureHandler } from 'react-native-gesture-handler';
  
  class GestureComponentExample extends Component {
    offsetY = new Animated.Value(0);

    onGestureEvent = (gestureEvent) => {
      const { nativeEvent } = gestureEvent;
      const { absoluteY: offsetY } = nativeEvent;
  
      this.offsetY.setValue(offsetY);
    }

    render() {
      const animatedStyle = { transform: [{ translateY: this.offsetY }] };

      return (
        <View style={styles.container}>
          <PanGestureHandler onGestureEvent={this.onGestureEvent}>
            <Animated.View style={[animatedStyle, styles.box]} />
          </PanGestureHandler>
        </View>
      )
    }
  }

  const styles = {
    container: {
      flex: 1
    },
    box: {
      height: 100,
      width: '100%',
      backgroundColor: 'black'
    }
  }

  export default GestureComponentExample; 
```

This allows the box to be dragged up and down along the y-axis fluidly without dropping any frames. All without re-rendering the component.

---

[View on echobind.com](https://echobind.com/post/reducing-costly-renders-during-gesture-animations-in-react-native)

---

# Bonus Yourself with Preparation

> Dec 05, 2019 | When you don’t prepare, it’s obvious to those who have. You end up looking foolish. Successful people prepare for the possibility of surprises and don’t wait for them.

_By Michael Yared · 2019-12-05_

Bonus time.

I tend to find myself working at companies where tracking time is part of the role. And when you’ve had to account for time as long as I have, a decent benefit is learning how you can be more efficient. The retrospective view of your time after you already know the result of your actions gives you clarity on how to handle future situations. You know what time was spent well and what steps can be skipped.

Because of this, I try to impart the benefits of preparation with everyone that I get a chance to work with. I see preparation as a defensive opportunity that shields you from having to spend time on unproductive tasks.

## A Tale of Ignorance

I once worked alongside a junior project manager who was struggling with his sole project. He seemed to be spinning his wheels, dejected, and burnt out. When asked how I could help, the coworker suggested shadowing me to see if I interacted with clients differently. Before we could schedule a time, the coworker openly admitted to having worked hundreds of hours more than what was being logged. It was shocking.

From the company’s perspective, the employee worked the expected [40 hours each week](https://echobind.com/post/40-hours-are-optimal). But in reality, he was starting his day three hours before anyone showed up and ended well after most folks finished dinner. This happened for months. When asked why he said this schedule was the only way to ensure that the project was successful. Despite the best intentions and all the time thrown at the project, it wasn’t a success until the rest of the team came together to save it.

**_“No matter how far you’ve gone down the wrong road, turn back.”_** _— A Turkish proverb from The Pragmatic Programmer that_ [_Mike Cavaliere_](https://echobind.com/post/spotlight-series-mike-cavaliere) _shared with our team today._

## Plan Your Day

When you don’t prepare, it’s obvious to those who have. You end up looking foolish. Successful people prepare for the possibility of surprises and don’t wait for them.

![Planner with notes](https://res.cloudinary.com/echobind/image/upload/v1661874560/echobind_blog/hzqnasnouwrbzuhp7xb1.jpg)

Somewhere, someone is planning to plan.

Consider how you start your week. Do you get to work Monday morning and start banging away at a keyboard? Are you nervous about what awaits you in your email? Do you wait for the ten-minute reminder from your calendar to prepare for the following hour?

A simple glance of your calendar the night before ensures you know how your day may unfold. You can handle conflicting appointments immediately. You can plan to take advantage of open time. You can think through what you may need so that you aren’t embarrassed by showing up empty-handed. You can even proactively cancel meetings that don’t require your attendance.

That smallest bit of effort will let you know how much preparation is required of you. Spending 10 minutes researching a new topic will lead to one of two outcomes. You either walk away confident that you already know enough about the subject, or you realize you need to plan to spend additional time to understand it.

## Anticipate Change

Let’s say you’ve got a good plan for your day. You’ve mapped out what you need to do. If you do it all, you’ll feel extremely accomplished. Maybe you’ve even bought a calendar that helps you detail how you spend every hour.

![Man sitting on brown couch](https://res.cloudinary.com/echobind/image/upload/v1661874034/echobind_blog/i45i92y11ejiqbtkmzmu.jpg)

When Bob calls.

What happens when Bob from accounting calls and has an urgent request that requires you to drop your plans for at least half a day? And now your day’s ruined all because of a surprise request. Well, the thing about surprises is, you don’t know when they’re going to happen.

My advice? Plan on taking small breaks throughout the day, schedule dedicated time for yourself, and don’t let others steal your time.

1. **Don’t work the full hour.** Work 50 minutes, and then take a 10-minute break. Walk around, disconnect, or grab a snack. Do anything except switch to another work task. If you can accomplish that, it’s usually a positive indication that you’ll come back refreshed and ready to work again.
2. **Don’t schedule your entire day.** What happens when you get a new business call out of the blue? Are you going to skip it? Probably not. Take the call and use some of that buffer time you’ve built into your day to handle the task you were currently working on.
3. **Don’t let people control your day.** Once you have a plan, keep to it. Nothing’s worse than having an unprepared person come to take away time from you. This is a massive reason why pushbacks on meetings are not only allowed, but advised at Echobind. [Meetings can be toxic](https://m.signalvnoise.com/meetings-are-toxic/), so avoid them at all costs unless there’s a clear purpose.
4. **Don’t let Slack control your day.** Slack is the worst. It’s a todo list of todo lists. Unfortunately, it’s become a vital part of many businesses and a preferred way to communicate. Slack works well if you can treat it with an async mindest, but it becomes a time suck as soon as you treat it like an always-on megaphone that you can just shout into at any time.

## Breathe Easy

![Group yoga session](https://res.cloudinary.com/echobind/image/upload/v1661872738/echobind_blog/z4rrkmmt94nsfrgapor4.jpg)

Meditation is basically preparation.

When you prepare, you feel confident. You know what you’re getting into, and you don’t have to worry about surprises. You look like the smart one on the call, especially if others simply checked the attendance box and didn’t come with an agenda.

**_“There are no secrets to success. It is the result of preparation, hard work, and learning from failure.”_** _— Baby Yoda (actually, Colin Powell)_

Being prepared also means working less. By taking the time to prepare, you’ve already taken something off of your to-do list. Odds are, because of that preparation, you better prioritize your workload and won’t lose time fixing mistakes.

Prepping for daily actions, weekly meetings, [quarterly goals](https://echobind.com/post/becoming-more-proficient-on-the-back-end-part-1), or yearly reviews can pay off massively. Being prepared is another way to be proactive, so start investing in yourself by preparing more.

---

[View on echobind.com](https://echobind.com/post/bonus-yourself-with-preparation)

---

# Tides of the Tailwind

> Dec 05, 2019 | Let’s step through some common hurdles in CSS and how modern CSS frameworks, like Tailwind.css, can help solve them.

_By Kory Tegman · 2019-12-05_

CSS, the web’s UI styling language, has come a long way since the days of GeoCities. Our lives are better (and sometimes worse), thanks to new language features, tooling, and design patterns. Let’s step through some common hurdles in CSS and how modern CSS frameworks, like Tailwind.css, can help solve them.

## CSS History

### Language Improvements

CSS has made a lot of progress over the years. For instance, it is now possible to vertically and horizontally center a div, and it is pretty easy! With the introduction of [flex-box](https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS%5Flayout/Flexbox), CSS grid, transitions, and countless other things can now be styled that was previously a black box. CSS has become pretty awesome and powerful.

### Tooling & Patterns

Aside from new language features, new tooling and design patterns have emerged.

Adding a precompile step to our CSS has given us tools like SASS, LESS and POST CSS. With more control, we started to DRY up our code, add functions and variables, and get rid of scope leaks.

Patterns emerged as we settled into these new technologies. [BEM](http://getbem.com/) solved a lot of problems organizing CSS, and even if you didn’t follow the rules strictly, BEM gave a good base to frame our thinking around.

### BUT (there is always a but)

BEM was not the most approachable for newcomers, and we still ended up with giant CSS files that are woven together just so. Any change at all to this delicate balance would lead to divs shooting off the screen left and right!

The friction of maintaining class names and delicate import/file structures all over your project didn’t go away either.

### **CSS in JS**

JS libraries like React and Vue started solving this problem by moving CSS into components. This got rid of cascading bugs and class name management since the scope is handled at compile time. Styled-components get us closer to the goal of staying focused and productive by keeping everything in one file.

This is a great solution and has solved a lot of problems.

## In Comes Tailwind

So what if you can’t use CSS in JS or StyledComponents? To start, Tailwind is a great option for styling an app with regular HTML. It is also easy to add to a legacy project and sprinkle where you need to make quick adjustments.

So what is Tailwind, and why do we need it? Tailwind is, as the [homepage](https://tailwindcss.com/) tells us:

> _A utility-first CSS framework for rapidly building custom designs._

But what does that mean?

It is basically a large set of utility classes that allow you to quickly style your application.

What are the benefits, and how do I use it?

### Smaller Cognitive Load

Tailwind is set up as a bunch of utility classes that are all named pretty intuitively. At first, you may need to visit the docs, but development is extremely fast once you have the class names memorized. You no longer need to switch files or context when you are writing components.

It feels so much better to stay in flow when building. You just add classes to your markup as you are going, rather than:

1. Stop your flow
2. Think of a new class name, and file name
3. And where do I put code again this?
4. And then create the file
5. Actually write the CSS (is it justify-content: right; or align-items right;?)
6. And back to the component file.
7. And add the new class in the markup.

I know you are already thinking that you don’t want all your markup polluted with thousands of class names everywhere. Well, Tailwind thought of that. There are a few solutions.

### The @apply directive.

After building out your super cool button, you might have something like this:

![HTML button](https://res.cloudinary.com/echobind/image/upload/v1661872486/echobind_blog/qrckbb3my5c9hd1qoctn.png)

Yikes! But by using the `apply` directive you can start extracting all this into reusable classes like so:

![CSS code with HTML button](https://res.cloudinary.com/echobind/image/upload/v1661872493/echobind_blog/u5xy5zgnrjxi8i4o9ohv.png)

### Styled Components

So what if you want the best of both worlds? Does tailwind support styled-components? As it turns out, it does. Since Tailwind is written in Post CSS, you can write plugins/macros.

So what does this look like?!?! how can I achieve this workflow bliss with Tailwind and use my awesome new StyledComponents?

[Christoph Benjamin Web does a great job of covering how to set this all up](https://wetainment.com/articles/tailwind-css-in-js/),

But here is the code you end up with looks like this:

![React code](https://res.cloudinary.com/echobind/image/upload/v1661872501/echobind_blog/naeozhtzqmlqh0xtcjyh.png)

Notice how you can use them inline or as styled-components? This gives us a lot of flexibility to make things modular as our app grows.

**So what did we learn about Tailwind?**

1. It is a time saver.
2. It helps us maintain focus.
3. It allows you to type less code.
4. It can use with styled-components to keep things terse.
5. The macro/plugin system means things will only get better.

I hope that you found this interesting and gives you a good idea of why you should give Tailwind a shot. Maybe on your next project, or who knows maybe you should start replacing legacy CSS with Tailwind now!

---

[View on echobind.com](https://echobind.com/post/tides-of-the-tailwind)

---

# Advantages Of Dark Theme User Interfaces

> Dec 04, 2019 | Here are some advantages of dark theme user interface (UI) since including saving eyes from unnecessary strain.

_By Michael Dang · 2019-12-04_

I truly appreciate the dark theme user interface (UI) since it saves my eyes from unnecessary strain. In fact, my eyes are straining as I write this very post. It looks like I will have to enable Dark Theme for Medium by getting [this extension.](https://chrome.google.com/webstore/detail/medium-dark-mode/kofkfocgjmlajkbkecljhbalihcpliih?hl=en) Dark themes make reading and browsing content at night enjoyable. Usually, when I’m texting or using apps, I have the brightness all the way down due to the constant glare of the white background. It fatigues my eyes rather quickly. With sites and apps adopting the usefulness of dark themes, I reap the benefits.

## **How Dark Theme Translates to Design**

Dark theme UI has made me reconsider how I think about design. For example, having high contrasted headlines grabs the attention of the user. As a designer, this is a great tool to use because it gives me a bit of leverage to guide the user to read or see what I deem the most important. Also, the use of highlighting rows/columns and graphical elements can set a [visual hierarchy](https://www.interaction-design.org/literature/topics/visual-hierarchy) that further routes the user into seeing what you envision from the start. It also accentuates certain parts of the UI while masking others.

![phone screens](https://res.cloudinary.com/echobind/image/upload/v1661873761/echobind_blog/twgnw0vjhxkdybhqlaec.jpg)

## **Adding a Sense of Drama and Emotions**

Dark theme UI evokes drama and emotions. For example, having a dark background with grungy textures overlaying with bold type treatment and an intimidating image can evoke a sense of anxiety and hopelessness about a certain design. On the other hand, you can have a dark background but with a bright, colorful image like Apple’s iPhone which then gives off this luxurious and bold feeling. One consideration for designing dark themes is that colors don’t translate the same way as they do in light theme. [UX Planet](https://uxplanet.org/8-tips-for-dark-theme-design-8dfc2f8f7ab6) says that

> _colors are actually perceived differently depending on their background._

They suggest using lighter tones (colors ranging from 200–50).

![Back of cellphone with water splashing](https://res.cloudinary.com/echobind/image/upload/v1661874985/echobind_blog/dxn8jt9djipewnuj6c9z.png)

### **Having a Connected Experience Between Real Life and Digital life.**

Dark theme UIs can have a subconscious ability to connect a user from their real-life to digital life. For instance, apps that have a day and night mode, like Google maps. When using this during morning times, the UI simply shows everything in a light manner with bright colors. It doesn’t really affect our eyes since there is an abundance of natural light surrounding us. When the sun sets in real life, the UI darkens and signals that we are transitioning into the evening. Not that we need to be told it is night, but this detail gives off an immersive experience that could potentially make a user feel more connected with the app.

![navigation system](https://res.cloudinary.com/echobind/image/upload/v1661874877/echobind_blog/b897kpmvptkh64pfbibr.jpg)

Personally, dark theme mode gives me a sense of calmness. When I use an app like Robinhood (a trading app that has a well built UI/UX) in the morning, with it’s bright and rich colors, it creates the hustle and bustle of the market like I’m on Wall Street. When the sun goes down, the app darkens in a more subdued state and, I feel it giving me a sense of relaxation while I browse for companies that I’m interested in.

![stocks mobile application](https://res.cloudinary.com/echobind/image/upload/v1661873012/echobind_blog/euwnq8axvqhn6aztylqq.jpg)

### **The Force is with You**

Understanding these UI tactics has opened up my eyes to how I should design user interfaces in the future. It is all about creating a great experience for the user, and I think the dark theme UI creates the best experience. It’s not just aesthetically pleasing, but it helps connect our lives to the digital world that many of us are already engulfed in. Personally, I have already gone to the dark side, and if given the choice, I would auto-enable this feature for all my applications. However, [UX Planet](https://uxplanet.org/8-tips-for-dark-theme-design-8dfc2f8f7ab6) says that for the best UX, you should allow your users to choose when they can enable a dark theme.

If you are a dark theme lover like me, I welcome you to the dark side!

---

[View on echobind.com](https://echobind.com/post/advantages-of-dark-theme-user-interfaces)

---

# Up and Running: ZEIT Now Environments

> Dec 01, 2019 | If you’re a JavaScript developer you’ve probably heard mention of zeit.co/Now and all their plans to have a zero-config setup for app deployments.

_By Matt Thompson · 2019-12-01_

If you’re a JavaScript developer you’ve probably heard mention of zeit.co / Now and all their plans to have a zero-config setup for app deployments. One of their main goals is to provide a seamless solution to deploy your JavaScript apps such as a Next.js app without all the DevOps hassles and shell scripts. While that’s not all they do, it’s what I’ll be expanding on here. Short, simply install Now and run the command `now` from the root of your project and this will push and deploy a version of your app to Zeit's hosting site. Integrating further with GitHub, and Now will also deploy a live branch of your site based on commits and PRs of your feature branch for review.

Out of the box, I'll have to say this was nice. For quick apps and sites, this is pretty neat and works well. My issue presented itself when I wanted to scale this into multiple environments for team collaboration. How do I set up different environments? How do I manage the environment variables? While the live test branches are great, they still pointed to production. That was a no go for me. There had to be a way to leverage Now's tools to set up a proper development, staging, and production environment. After some digging around and various threads through Spectrum, I found a few solutions to try out.

> _Note: I’ve been keeping watch over these threads in ZEIT’s Spectrum chat. While this is an example of my current setup, I am aware they are still actively adding features and sifting through requests. Should this setup change I’ll create a follow-up post._

**Solution 1.** Create separate instances within the ZEIT dashboard and use the CLI tools to deploy to the correct instance.

**Solution 2**. Use the same instance in ZEIT and have specific `now.json` files that would alias a specific domain URL when deploying manually through CLI or automagically through CI/CD.

While learning, I had a repo ever so cleverly named `next-now-test` that I'll be referencing throughout the rest of this article. (I was tired, names are hard) This is a bare-bones NextJS app that uses Next's serverless API. If you haven't used NextJs before no worries you want to need to worry about that for this setup, but if you are interested you can dive into their [learning section](https://nextjs.org/learn/basics/create-nextjs-app) here or stay tuned for my next entry "Up and Running: NextJS and TypeORM"

## The Code

At first, looking at the two solutions, Solution 2 seemed like a better option. Maybe it was the 4-month-old sleep I was getting… Either solution seems viable at this point as you would manage multiple instances inside of Heroku or other providers as well. Regardless, at the time I didn’t want to manage multiple instances inside of Zeit. My primary goal was to set this up to automagically-deploy through CI/CD and have aliased URLs.

For solution 2 to work at the root of my project I would need three now.json files to support Development, Staging, and Production. I would also need to set some ENV’s with Now’s CLI tool.

* now.json (the default JSON file used for branch deploys — Development)
* staging.now.json (Staging ENV’s)
* prod.now.json (Prod ENV’s)

To keep thing’s simple I created one `APP_ENV` to display the environment name on the main landing page. Below is an example of each JSON that includes the alias URL as well (more on that in a sec).

```javascript
now.json (Branch deploys no alias needed)
{
  "name": "next-now-test",
  "version": 2,
  "env": {
    "APP_ENV": "@dev_app_env", // set with now secrets see below 
  }
}
staging.now.json
{
  "name": "next-now-test",
  "version": 2,
  "alias": ["staging-next-now-test.now.sh"],
  "env": {
    "APP_ENV": "@staging_app_env",
  }
}
prod.now.json 
{
  "name": "next-now-test",
  "version": 2,
  "alias": ["production-next-now-test.now.sh"],
  "env": {
    "APP_ENV": "@prod_app_env",
  }
}
```

`Now` manages their environment variables through their CLI tooling. These are provided out of the box when you install Now to your machine. If you've interacted with Heroku or Aptible's CLI this is very similar. Now CLI gives you the CRUD commands needed to review, add, remove 'secrets'. As you would expect these are per project instance. For this app, I added three ENV's with `now secrets add...:`

* dev\_app\_env = “DEVELOPMENT”
* staging\_app\_env = “STAGING”
* prod\_app\_env = “PRODUCTION”

You’ll note in the now.json examples above we are able to reference these with the `@` symbol. `"APP_ENV": "@staging_app_env"` If the @ symbol wasn't present `Now` would just assume this is a string value and move on. We also are making these semantic with `dev_` `staging_` `prod_`. If we were to need real ENVs, say a database\_url we would want to do the same.

## CI / CD

Alright, that’s a lot of words for nothing so far but we are almost there. Let’s get this wired up.

A recap of our solution goals here, when I create a PR from any branch Now will create a named branch deploy using our Development ENV’s. If that PR is merged into a branch called `staging` we would like Now to deploy and alias `[staging-now-next-test.now.sh](<http://staging-now-next-test.now.sh>)` using our staging ENV's and likewise with anything going into master for production.

Feature Branch (development) → PR into Staging (staging) → PR into master (production)

I decided to use GitLab here but you can use any CI/CD tool you’d like as we will just be running a few commands based on branch names. If you recall integrating Now with GitHub already deploys a named branch when a PR is made. When deploying Now will look for the root `now.json` file. We've left our `now.json` file setup for Development so our setup here is already complete! You should see a note from Now inside the PR as well as inside [Zeit.co](https://vercel.com/) under the project itself. Below is an example of both the PR named branch and a commit specific branch deployed by Now. During development, I was using a branch called `testing`.

All we need is to trigger specific deploys for our staging and production environments. If you see below in our config we have two commands setup if something is merged into staging or master, `yarn ci:deploy:staging` and `:master` respectively.

_.gitlab-ci.yml_

```javascript
... 
deploy-staging:
  stage: deploy
  script:
    - yarn ci:deploy:staging
  only:
    - staging
    - merge_requests
deploy-production:
  stage: deploy
  script:
    - yarn ci:deploy:prod
  only:
    - master
    - merge_requests
```

_package.json scripts_

```javascript
... 
"ci:deploy:staging": "now -A staging.now.json --target=staging --token=$NOW_TOKEN --scope=mthomps4  && now alias -A staging.now.json  --token=$NOW_TOKEN",
"ci:deploy:prod": "now -A prod.now.json --target=production --token=$NOW_TOKEN --scope=mthomps4 && now alias -A prod.now.json  --token=$NOW_TOKEN"
```

Let’s look at one of these in detail, ignoring NOW\_TOKEN all of these commands can be run using the CLI.

> _now -A staging.now.json — target=staging — scope=mthomps4 — token=$NOW\_TOKEN_

&& now alias -A staging.now.json — token=$NOW\_TOKEN”

* `now -A staging.now.json` \- now means 'hey deploy this' the -A command is saying 'hey deploy this and use this now.json file'.
* `—target=staging` Honestly, I'm not sure this is needed anymore. This is the counter to `now —prod`. All we are doing here is telling Zeit/Now to not deploy this to their given production URL and our aliased production URL.
* `—scope=mthomps4` Think organizations here. If you are using Now personally and are not roped into any other company/organization accounts you can skip this line. When you are a part of another Zeit organization/team you would navigate these in the CLI using `now switch` before running any other now commands. This tells `Now` to do the same and ensure you're under the right profile before it deployed.
* `&& now alias -A staging.now.json` Using the file provided with -A please alias all of our domains provided to THIS deploy. `now alias` will look into the now.json file provided for an alias array and map those domains to the recent deploy. `"alias": ["staging-next-now-test.now.sh"]`,
* `—token=$NOW_TOKEN` $NOW\_TOKEN is an auth token provided by Zeit found under <https://zeit.co/account/tokens> You'll need to create a token, and then save this as an ENV for GitLab or other CI to use.

**That’s it!**

With these two yarn commands, GitLab CI/CD will deploy and alias our domains as expected. Merging a branch into staging will update `[staging-next-now-test.now.sh](<http://staging-next-now-test.now.sh>)` and merging to master will update `production-next-now-test.now.sh`.

![Multiple welcome screens](https://res.cloudinary.com/echobind/image/upload/v1661872537/echobind_blog/w1hjw3ssgcmswz7bwok6.png)

---

[View on echobind.com](https://echobind.com/post/up-and-running-zeit-now-environments)

---

# Customizing Notion for Productivity

> Nov 29, 2019 | Here at Echobind, we use a lovely little tool called Notion. At a glance, it looks like just another note-taking app, but it’s THE note-taking app everyone needs.

_By Ashley Nelms · 2019-11-29_

Here at Echobind, we use a lovely little tool called [Notion](https://www.notion.so/). At a glance, it looks like just another note-taking app, but it’s THE note-taking app everyone needs. With Notion, you can manage your notes, projects, goals and more. It serves as a wiki tailored to our company where everyone can collaborate to build it up.

I could go on for hours about how we use Notion as a company, but today I’d like to show how I’ve personally used it to manage my productivity.

## Command Center

For a good while, I didn’t use Notion to it’s fullest potential. In my private section in Notion, I’d create a new page for notes as needed. There was no real organization to it, and it took ages to find reference back to notes that I needed. Deep down, I knew I could likely be using this tool more efficiently.

I researched Notion setups for some inspiration and noticed a common theme: they had dashboards! I decided to adopt this idea and build my own “command center.” With this, I was able to consolidate many apps and Chrome tabs into one centralized location as shown below.

![A Notion page showing the layout of the dashboard.](https://res.cloudinary.com/echobind/image/upload/v1661874416/echobind_blog/qd1zox2c7twginklh8yv.png)

At the top, I have the three most common pages I expect to use often.

## Priorities

Each week, there are some high priority tasks that absolutely must be completed. To ensure they aren’t forgotten, I use this page to schedule my week’s priorities and attach [notification reminders](https://www.notion.so/Reminder-notifications-b4325370e2744d999c021900e76c9abb).

![A Notion page showing the priorities section of the dashboard.](https://res.cloudinary.com/echobind/image/upload/v1661873718/echobind_blog/wtmvz8lij9cpswmpkoul.png)

## Goals

Each quarter, everyone at Echobind has goals that we work on accomplishing using our [investment time](https://echobind.com/post/the-roi-of-self-directed-investment-time-for-software-engineers). While we use [Lattice](https://lattice.com/) to track goal progress, I chose to use my command center in Notion to schedule and set reminders for my goals. In my “Completed Goals” column, I have a link to Lattice to remind myself to mark a goal as complete.

![A Notion page showing the goals page of the dashboard.](https://res.cloudinary.com/echobind/image/upload/v1661873725/echobind_blog/wgzcebwtpy2blvegdvdy.png)

## Inbox

Often times throughout the week, I come across an interesting article that I always tell myself “I’ll read later”. By the time I have a chrome window filled with tabs of “to read” articles, I’m feeling mentally cluttered. I occasionally find myself ripping off the band-aid and killing all browser windows to start fresh into another vicious cycle of dozens of tabs. With an inbox, [I save all of these articles](https://www.notion.so/Embeds-6b7133323590447b9d8e963c136ebce5) in one central location to come back to later and don’t lose them in a mess of various other tabs.

![A Notion page showing an inbox section of the dashboard.](https://res.cloudinary.com/echobind/image/upload/v1661873732/echobind_blog/cdrldz8xw7cb5vp1kbql.png)

## Routine

In the next part of my command center, I have a routine section. At Echobind, we place great value on [checklists](https://www.notion.so/Personal-To-do-s-39a65118f94541559065828134130c57). I have a checklist of each type (daily, weekly, etc) to be sure I’m not missing any essential tasks. For every checklist, I make use of [Notion’s template feature](https://www.notion.so/Create-your-own-templates-5c033c12ac3b4c1fb4703491be74550d). This allows me to generate a fresh checklist once I’ve completed the current routine’s checklist. See what I mean about Notion being more than being just another note-taking app?

![A Notion page showing the Monday checklist of the routines page of the dashboard.](https://res.cloudinary.com/echobind/image/upload/v1661874963/echobind_blog/ovin2o4szzxw8tsgunma.png)

## Client Projects

As an account manager, I normally work with more than one client project at a time. And as a company, we manage information about the client in their own Notion pages. This includes what Echobind is doing for them, who key stakeholders are and so on. With this page, everyone on the project’s team can collaborate with ease.

![A Notion page showing the client page of the dashboard.](https://res.cloudinary.com/echobind/image/upload/v1661873790/echobind_blog/atgwq99zij2ygwcyec8d.png)

## Investment Projects

For my investment projects, they fall more in line with personal goals but still provide benefits to Echobind as a whole. What differentiates it from my goals list we talked about earlier is that these are not part of my quarterly goals. Instead, these are projects that I tend to focus on when I find myself with extra time. They are open-ended and don’t have a specified deadline. These pages are very similar to the client project page above.

![A picture of the investment projects section on the dashboard.](https://res.cloudinary.com/echobind/image/upload/v1661873199/echobind_blog/mqrxap8ffufzjcmxsmmh.png)

## Reminders

A lot of times I need a quick reminder for a task after coming out of a meeting. Prior to using my command center, I was using Slack but they were easy to overlook. Again I make use of Notion’s template feature to quickly add a new to-do item under my reminders and attach a time to it. When you add a timestamp to Notion, you’ll get a reminder within Notion itself and, depending on your settings, a text and email as well. This has more coverage and visibility than when I was using Slack or even Google reminders.

![A picture of the reminders section of the dashboard.](https://res.cloudinary.com/echobind/image/upload/v1661872515/echobind_blog/fhgv13dryyzkzkdjpz0f.png)

## Library

Here, I have my “books” for learnings as well as [snippets](https://www.notion.so/Code-blocks-69df2788f65345bbbe18596cfa1750fe) I find myself using often. Doing database management for some clients, I’m often reusing some of the same commands regularly. With my snippets notebook, I have them all in one spot and find that I can take care of management tasks faster. Below is an example section from my snippets notebook.

![A picture showing some example snippets of the snippet book on the dashboard.](https://res.cloudinary.com/echobind/image/upload/v1661872522/echobind_blog/kpkrfvivuatieie3g3rv.png)

## Summary

After using this system for a few weeks, I feel more organized and definitely more productive. Hopefully, this provides some inspiration for your own command center — space theme optional of course!

---

[View on echobind.com](https://echobind.com/post/customizing-notion-for-productivity)

---

# The ROI of Self-Directed Investment Time for Software Engineers

> Nov 27, 2019 | Investment time is good for business, we can offer up to one full day of investment time to our people every week, it increases our bottom line.

_By Mike Cavaliere · 2019-11-27_

For those unfamiliar with the term, “investment time” refers to free time employees are given on a regular basis, in which they can experiment, learn, and create without any employer-enforced agenda. Google, for example, has been known to allow their employees to use 20% of their time working on self-directed projects they’re passionate about. At Echobind, we do it too. But the reason behind it may surprise you.

Conceptually, the notion of giving people a chunk of “do whatever you want” time seems like a pie-in-the-sky idea that only happens at places like Google, where chairs are made of air, robots give you massages at your desk, and lunch is catered every day. At best, it sounds like a luxury, and at worst, a fantasy.

The truth is, investment time is good for business. This is why we are proud that we can offer up to one full day of investment time to our people every week; it’s selfishly motivated since it increases our bottom line.

To understand how investment time makes us more profitable, let’s take a look at the different things that software engineers, designers, project managers, and strategists can produce in their time to roam free.

## Learning

Taking the opportunity to learn a new topic of their choosing is an endeavor that motivates itself. It’s a welcome departure from the tasks you’re required to do for your job, even if you happen to love doing them. It’s a mental shift from a “doing” mode into a “playing” or “absorbing” mode.

Indulging in fun, inquisitive endeavors begets more motivation for the required work tasks. It refreshes people (albeit, on a smaller scale) in the same way that a vacation can.

Outside of just motivation, learning new things means a better quality of work. New tools and technologies mean more (and sometimes better) methods for getting things done that the team may not have had exposure to before. Or for a consultancy like ours, it may mean a completely new service we can offer to clients.

And even if it doesn’t turn into a new service, it often helps our clients out directly. Quite often, the things our employees learn in their investment time turn into actionable skills that get used the very next week in the course of client work.

## Motivation == Happier Engineers == Less Employee Turnover

That motivation I mentioned above compounds over time. It’s a lot easier to get through a tough week of client work when you know there’s some self-directed innovation time at the end of it. But just by virtue of having investment time at all — the _gesture_ of it — means that the company is investing in you as an employee; that alone makes many people want to work harder at their jobs.

And that’s also true of applicants as well; many of the people who we’ve hired said that the investment time was a major selling point for wanting to work with us, along with the fully remote work and this overall vibe of investing in our employees. The more happy people are, the better their work is and the longer they’ll stick around.

## New Developer Tools

Every good dev knows the DRY principle: Don’t Repeat Yourself. This extends to, “Don’t do the same laborious task twice.” Sometimes we use investment time to make our non-investment time a lot easier by writing code (or creating design templates, process-simplifying tools, etc) that will simplify other tasks.

These can be command-line tools, [templated code generation](https://echobind.com/post/improve-developer-productivity-with-generators-and-team-conventions) (which we love), web-based tools, [open-source packages](https://github.com/echobind), and so on. Each complex task you pop into a module means a lot less typing, and time to worry about other, more complex tasks.

The open-source packages also contribute to the community, which is good for geek cred and fosters collaboration with other engineers. It’s even helped with hiring since it connects our engineers with other talented people out there in the world.

All of this also means better, faster, more significant output for our daily work lives. Which, in turn, affects everyone’s bottom line, regardless of the business type.

## Content Creation

Another thing our team members spend time on is writing up their investment learnings. Sometimes this turns into lunch-and-learn sessions that teach others, which raises the team’s shared knowledge levels. Sometimes these lunch-and-learn sessions, like one I did on Chatbots, help inspire and motivate others to take further action on the same topic. In fact, one of our engineers, Deen, started building her own chatbot with her investment time. (For those interested, it’s called `Sparklebot`. It gives sparkles to people that deserve them ✨✨)

Often these learnings turn into part of our shared knowledge base in our company wiki so that others working on the same topic can get a quick start off of work that was already done, and avoid problems that have already been solved. At other times, this content turns into blog posts, which demonstrate our experience to potential clients and help build our search rankings and online credibility. It’s a win-win-win situation.

## Products

Lastly, one hope for the use of investment time is that some of these tools prove so useful that they ultimately turn into public-facing or B2B SaaS products. Naturally, there’s a bit more that goes into things like this before they’re successful, but plenty of products have been started this way. Gmail and Basecamp may be the classic examples, but there are lots of others — take a read through [indiehackers.com](http://indiehackers.com/), and you’ll find a bunch.

The bottom line is that investment time for software engineers isn’t just a luxury; it’s something smart companies should invest in since it will create concrete returns on their investment. At a minimum, it’ll help keep their employees from getting bored, unhappy, or stale in their technical skills. At best, it could lead to new revenue streams, or potentially change the future direction of your company. Don’t miss out on the opportunity.

---

[View on echobind.com](https://echobind.com/post/the-roi-of-self-directed-investment-time-for-software-engineers)

---

# The Business Value of (& Precautions for) React Native

> Nov 26, 2019 | React Native’s popularity has been growing year after year, with no hints of slowing down yet. Startups and anyone who wants to build a cross-platform app quickly keep gravitating to it.

_By Mike Cavaliere · 2019-11-26_

React Native’s popularity has been growing year after year, with no hints of slowing down yet. Startups and anyone who wants to build a cross-platform app quickly keep gravitating to it. Companies are hiring more dedicated React Native engineers. And I think that’s because at least part of the business value is clear: you can build a cross-platform app faster by writing it only once for two platforms.

There are other business benefits to using React Native (RN) as well, which may not be common knowledge. Below I’ll get into a number of them, in addition to some potential challenges you should be aware of before having your team adopt RN or hiring a team to build your mobile app with it.

![Google trends graph](https://res.cloudinary.com/echobind/image/upload/v1661873300/echobind_blog/nkf12ftfmduz7yihqjrv.png)

[Google Trends graph indicating React Native’s growing popularity](https://trends.google.com/trends/explore?date=today)

## Time savings

This one everyone knows; write the app once in JavaScript, and you end up with an Android app and an iOS app (it’s not _quite_ that simple — I’ll provide more details below — but know that this is a fact). But there’s more detail to the types of time savings you’ll get by using RN.

Engineers save valuable development time (and therefore, their employers save money) since most features get written once rather than twice. That’s not the only place time gets saved. Time is also saved _in the learning process_ for those engineers since the libraries they use only have to be learned once — the paradigms for both platforms for most use cases (navigation, styling, etc) are centralized into one shared way of doing things. Learn once, implement once, deploy twice.

This applies to more than just common React Native libraries as you’ll see in the next section.

## Knowledge portability

If your team members already know React or any of its associated tools (GraphQL, Redux, and so on), they’ll be able to apply that knowledge directly to React Native development without having to do much differently. This means that the inevitable paradigm shift from building web apps to building mobile apps, which is pretty challenging on its own, becomes much smoother.

But outside of React, their JavaScript knowledge now goes a long way. Using the same language you’re already accustomed to is a considerable time and learning savings (especially when going from something like JavaScript to Java; similar names, _massive_ paradigm shift). Also, very notably, engineers can reuse many of the same utility libraries between web and React Native: [Lodash](https://lodash.com/)/[Underscore](https://underscorejs.org/), [Moment](https://momentjs.com/), [RxJS](https://www.learnrxjs.io/), [Ramda](https://ramdajs.com/).

The same goes for many things you’d use in Node. Less new learning translates to more money in the company’s pocket.

## Maintainability

Having one codebase instead of two means a lot less code to maintain, and far less room for human error. And it has exponential benefits as you scale. One suite for test coverage is easier to maintain than two completely different ones. The same goes for one CI setup. E2E testing on a service like Browserstack can be set up once and just have different device configurations plugged into it.

This goes for production monitoring, error tracking and debugging as well. Since tools like Microsoft [AppCenter](https://appcenter.ms/), [Sentry](https://sentry.io/) and [Fastlane](https://fastlane.tools/) treat React Native as a first-class citizen, you install them once and are able to know what issues crop up on the exact devices they affect. And you can make hotfixes without always having to go through the app release process for many cases. One debugging process, two platforms.

## Must-know before adopting React Native

Above are some of the great benefits of using React Native — and they are indeed great. Here are some of the gotchas that can set a tech team back if they don’t know them beforehand. None of them are detractors from using React Native at all, they’re arguably challenges that could exist when moving from any programming paradigm to another. But knowing them ahead of time will save your team lots of time and energy.

## App Performance

If your app needs to be truly, truly multi-thread, you’re SOL. JavaScript (and therefore React Native, and any other JS-based platform) is single-threaded, and therefore, only one line of code can run at a time.

Chances are, that doesn’t matter one bit for your app. And if it does, it still may not be a problem.

React and React Native are heavily optimized frameworks; they’re built for fast, efficient rendering. As long as you’re not committing any React performance sins, your app will run extremely well for most cases. The few types of apps where true multithreading might even be a valid consideration include processor-intensive apps like 3D games and augmented reality apps. And [even](https://www.youtube.com/watch?v=oHBGhHlVOI0) [those](https://www.youtube.com/watch?v=WYCZgWEnHkg) have been done rather well with React Native already. So chances are RN can still do what you want it to.

## React Native Isn’t React

As I mentioned above, React engineers can transfer a lot of their React (and JavaScript) web development knowledge to React Native easily. Lots of things are going to need to be done differently codewise though, that will require different habits and tools.

Notable concepts that will require new learning and different libraries:

* **Navigation.** [React Router](https://reacttraining.com/react-router/), for example, is arguably the most common navigation library for React on the web; [React Navigation](https://reactnavigation.org/) is the de-facto standard on React Native. Navigation on mobile is an entirely different paradigm as well; instead of linking to pages (random access), often mobile screens “stack” — they’re laid one on top of another, so that the only way out of them is to hit the back arrow (and take a screen off the stack and throw it away).
* **Visual styling and layout.** React Native uses Flexbox almost exclusively. Web styling has other methods (CSS grid, floating, and so on) that do not exist on RN. Furthermore, styles in RN are written directly in JavaScript — quite different than writing CSS itself (though this can be worked around with a library like [styled-components](https://www.styled-components.com/)).

These are concepts that exist for web apps but will require a transition to doing them the RN way. Then there are the concepts that don’t exist on the web at all.

## Web Apps Are Not Mobile Apps

There are concepts in the mobile development world that either don’t exist at all or exist in very different forms in the front-end web world. To be effective, web teams will have to absorb a few crucial areas of knowledge to be minimally effective with React Native.

A few crucial areas that come to mind:

* **Device differences.** Mobile devices have hardware capabilities that most web apps never concern themselves with. Location, device orientation, haptics, push notifications, just to name a few. Each will require some conceptual understanding and usually an RN library for the related device functionality.
* **Testing is harder.** You can’t just send people a URL of your staging server to take a look; you need a way of building real apps and a way of distributing them to people’s devices. And you guessed it, the means to do which is different between iOS and Android.
* **App store process.** Like distributing for testing, shipping a live app is a complex process. It’s different between app stores, and in the case of Apple’s App Store, it’s possible to get rejected and have to go back to the drawing board, even if you’re experienced in the matter and know what to expect.
* **Production debugging.** Because the release processes on the app stores are not as quick as a web app deployment (and updates require approval), production issues and API versioning conflicts can be catastrophic. Over-the-air updates with something like Microsoft App Center and backward-compatible API versioning (especially with something like [GraphQL and Apollo](https://echobind.com/post/8-business-reasons-to-adopt-graphql-and-apollo-server)) help mitigate these risks very well.

These are challenges that you (or whomever you hire) should know about before kicking off a React Native project, or they could easily throw a big monkey wrench into your development plans.

The above should serve as a good summary of how valuable React Native is and most of the things you should know before adopting it. It’s a fantastic framework for rapid cross-platform mobile app development, [which is why we do so much of our client work with it](https://echobind.com/). Before you have your team (or a hired team) build your app in it, reference this article, and your results will be fantastic.

---

[View on echobind.com](https://echobind.com/post/the-business-value-of-precautions-for-react-native)

---

# Three Methods for Styling Components in React Native

> Whether you are just starting out with React Native and trying to learn how styling works in a new ecosystem, or you’re just trying to catch up on all the latest CSS-in-JS buzz, you’ve come to the right place.

_By Ryan Atkinson · 2019-11-19_

Whether you are just starting out with React Native and trying to learn how styling works in a new ecosystem, or you’re just trying to catch up on all the latest CSS_\-in-JS_ buzz, you’ve come to the right place. I have worked on a number of React Native apps, and have used all of the most prevalent styling tools out there.

I’m going to share with you my own perspectives on each, and what I consider to be its pros and cons. Hopefully, by the end, you will have a better picture of the options available and can make your next styling tool choice from an informed perspective.

### **_Stylesheets and the Style Prop_**

The place to start is going to be the “out-of-the-box” solution for styling components in React Native, the style prop. There are no .css files or classNames in React Native, but instead “style objects” are passed directly into the style prop of the components provided by React Native:

![React component code](https://res.cloudinary.com/echobind/image/upload/v1661872601/echobind_blog/r7ermasgxrnfg5dge8wc.png)

Styling a component via the style prop

Just from the trivial example shown, it’s clear that a major drawback of this approach is its verbosity, and how much physical space our style definitions can take up in our JSX. Also, there’s no strategy for code re-usability inherent in this approach.

React Native has a special tool, StyleSheet for defining styles outside of the JSX, and then using them by referencing the keys of the styles object that `StyleSheet` provides:

![React component code with styles props](https://res.cloudinary.com/echobind/image/upload/v1661872609/echobind_blog/bdpzwonfopdjzxlajnwi.png)

Moving styles into a Stylesheet

The keys of the StyleSheet are very similar to `classNames` in a traditional web context, which reduces the code profile in our JSX, as well as facilitates re-use of styles. Also shown in the example above is a pattern for updating styles based on props, which is an invaluable pattern in component development.

While stylesheets let us clean up our JSX and are generally a better practice, they still don’t solve code repetition between files unless you move your styles into centralized, external locations in your codebase. This then brings up another pain point of mentally remembering the styles contained in your stylesheet as you’re working in your JSX. While you can still have high-quality apps and clean codebases using these out-of-the-box tools, it is a somewhat mentally fatiguing process for writing and maintaining styles.

### **_Styled-Components_**

Styled-components is the premier library for using CSS-in-JS. With styled-components, there are no stylesheets and no style props. We use template-literal strings to define CSS blocks within component definitions. The names of the components with the styles applied then lead to highly semantic JSX in our render method, aiding in the readability of our code:

![React component code](https://res.cloudinary.com/echobind/image/upload/v1661872616/echobind_blog/pffcrjplh3irzf29iypy.png)

Styling components with styled-components.

Note that we are no longer importing React Native component primitives, but instead accessing them from the `styled` object. Notice how we are now computing styles based on props. I find this pattern very useful for common UI states which follow an either/or pattern. We can also use the `styled` object as a function, to add new styles to an existing component:

![React component code](https://res.cloudinary.com/echobind/image/upload/v1661872623/echobind_blog/nn8dnqalwwrgaa4siob9.png)

Adding new styles to Container with ModifiedContainer

Styled-components isn’t the only library for providing this powerful CSS-in-JS utility; Emotion is also very popular. Styled-components make code easier to read, and easier to work with (in my opinion). The only real criticisms I have of styled-components are the lack of style re-usability and the corresponding bloating of our files with lots of verbose style definitions. Also, a cognitive bridge is still required in the developer’s mind between the name of the “styled” component and the styles themselves when working in the final JSX output.

### **_Styled-System_**

So far neither of our styling options has provided us with a clear solution to an inevitable problem of a scaling codebase: style consistency. It is very common to define a central “theme” file with style values defined for different layout scenarios, but this is a lot of extra work for the developer to maintain and to enforce consistent usage. This is one of the issues styled-system solves.

The other issue styled-system solves is the one intrinsic in both the “stylesheet” and “styled-components” style methodologies: when working on styles, a cognitive map needs to be held between the style objects and the JSX. Ironically, styled-system can almost be viewed as a step _backward,_ to having the styles defined directly within the style prop object of our primitive React Native component JSX.

Styled-system is, in essence, a toolkit that allows you to overload components with extra props that represent subsets of available CSS styles, and to parse those values from a centralized provider. This allows you to apply styles directly as props in your JSX, as well as use special shorthands that compute to values in your theme definition.

Styled-system requires a bit of setup and actually requires that you add a CSS-in-JS library as well (such as styled-components or emotion). It would be more accurate to think of styled-system as a super-layer on top of styled-components, or whatever CSS-in-JS library you prefer. The first thing you would do is to define a new styled-system component, which overloads an existing component with new style props:

![React CSS code](https://res.cloudinary.com/echobind/image/upload/v1661874445/echobind_blog/oixgx9lp3mrsbovi3orz.png)

Creating a new styled-system View component

![React CSS Code](https://res.cloudinary.com/echobind/image/upload/v1661874452/echobind_blog/ugewlx8soygusmywovmo.png)

Creating a new styled-system Text component

And then back in our component, we can import the new `Container`, as well as the similarly overloaded `Text` component, and start using the style props provided by styled-system:

![React code](https://res.cloudinary.com/echobind/image/upload/v1661874459/echobind_blog/xtkmzj51ouuo9bxlet4f.png)

Adding styles directly as component props

I can understand if this method of styling is off-putting to those who are attached to the lean and concise JSX provided by styled-components, however, in my experience this method allows for much faster development speeds than either of the previous methods. The syntax is easier to write than the inherent style-objects of React Native and keeps our styles in the JSX itself, so less “mental-bridging” is required.

Notice the `bg` prop on the `Container`. This is shorthand for `backgroundColor`, and just one of many shorthands provided by styled-system. In practice, I typically only define a few “primitive” components which receive my styled-system props and build all other components from these few. A potential criticism is the mixture of style and data props. In actual usage, however, I find it is actually quite clear which props represent styles and which represent actual component data. “Primitive” components will be loaded with style props, while my more complex components will primarily be receiving data props.

Another amazing feature of styled-system is the combination of theming with the custom style props. Utilizing the `ThemeProvider` from styled-components (or emotion), we can predefine scaling values and then access them with shorthand syntax provided by styled-system.

![React main App component code](https://res.cloudinary.com/echobind/image/upload/v1661873394/echobind_blog/mobmjpukupovvdz9ldlu.png)

Wrapping our component tree in a ThemeProvider

Notice in our theme we define a `space` array, which contains a set of integers. These will be the values that the `${space}` props from styled-system pull from. These will translate to the padding and margin values on our styled-system component:

![React code](https://res.cloudinary.com/echobind/image/upload/v1661873401/echobind_blog/y7tuchwvjmgjqh8lrnve.png)

Accessing the “space” values of our theme in the padding and margin shorthand props

Note the `p` and `m` props on the inner `Container`. These are shorthands for padding and margin (similar to `bg`). When we give them a value less than the length of the space array in the theme, it will pull the value at that index from the theme; otherwise, it will use whatever you pass in.

i.e. `p={4}` will compute to `theme.space[4]`, while `p={30}` will just be `30`.

Styled-system makes component development _fast_ while making theming _easy_. Styled-system is also very flexible. You can use it without a theme, and you can opt-out of using the shorthand style props in favor of the more conventional style names. Any way you use it though, once you get past the small initial learning curve, I find that this facilitates very rapid UI development.

### **_Bonus: Boolean Style Props_**

Disclaimer: This technique is my own creation and not at all endorsed by any of the aforementioned libraries ⚠️.

Boolean style props are a styled-system meta-pattern that resulted from looking at my code and seeing the same groups of styles applied over and over. You can think of them as being similar to “global CSS classes”. For instance in React Native, where everything is a flexbox, I found that the vast majority of all of my layout components received the same set of props:

```javascript
flex={1}
width="100%"
justifyContent="center"
alignItems="center"
```

Since one downside of styled-system is the same downside of the inherent React Native style props, JSX bloating, I decided to make these applicable via some extra shorthand props on my `Container` component:

![React CSS Code](https://res.cloudinary.com/echobind/image/upload/v1661874315/echobind_blog/sd4tmwk5i3n6urchiwae.png)

Adding boolean style props for globally-accessible, predefined style chunks

![React code](https://res.cloudinary.com/echobind/image/upload/v1661872897/echobind_blog/hw4qio8ocajefnpij3fj.png)

Using our new boolean style props for clean code

I find that with this custom pattern in place for any heavily repeated styles, the resulting JSX becomes nearly as clean as that provided by a pure styled-components implementation. If you really liked this pattern you could add as many custom styles as you wanted to, but personally I strive to add as few as possible. Also, I keep them completely devoid of app context and make sure they stand in abstraction. For example, I would make a `blueBackgroundprop`, but not a `homepageBackgroundprop`. This ensures styles remain robust and reusable.

### **_Closing Notes_**

Arguments can be made for all of the component styling methods that have been discussed, but at the end of the day, I would recommend just trying them all and seeing what works best for you. Each will come with its own tradeoffs, and it’s up to you to decide which you’re ok with. Maybe you just want to leverage as few external libraries as possible and the out-of-the-box utilities are good enough for you. Or you want the benefits of styled-components, but styled-system is more structure than you need. I know when I went to go setup styled-system the first time I was deeply irritated at having yet _another_ js library that I had to figure out, but once I started building things with it I couldn’t imagine ever going back.

**_Documentation links for setting up and using the referenced libraries:_**

_Stylesheet (facebook):_  
<https://facebook.github.io/react-native/docs/stylesheet>

_Styled-components:_  
<https://www.styled-components.com/>

_Styled-components for react-native:_  
<https://www.styled-components.com/docs/basics#react-native>

_Emotion:_  
<https://emotion.sh/docs/introduction>

_Emotion for react-native:_  
<https://emotion.sh/docs/@emotion/native>

_Styled-system:_  
<https://styled-system.com/>

***Learn more about our [React Native capabilities](/capabilities/react-native-app-development).***

---

[View on echobind.com](https://echobind.com/post/a-comparison-of-three-methods-for-styling-components-in-react-native)

---

# AllThingsOpen 2019 Recap

> Nov 12, 2019 | If you haven’t heard, All Things Open is an annual conference on open source software (OSS) that happens in Raleigh, North Carolina. It’s been going on for the last seven years and continues to grow each year.

_By Joe Previte · 2019-11-12_

If you haven’t heard, [All Things Open](https://allthingsopen.org/) is an annual conference on open source software (OSS) that happens in Raleigh, North Carolina. It’s been going on for the last seven years and continues to grow each year. It offers a mix of keynote speakers along with smaller sessions and workshops on a variety of topics related to OSS.

One of the perks here at [Echobind](https://echobind.com/) is being able to attend conferences. I chose All things Open due to the speaker lineup and my growing involvement with OSS.

## Highlights

Overall, the conference was nothing but amazing in the quality of content and the opportunities to interact with other attendees.

The keynotes featured speakers including [Ashley McNamara](https://twitter.com/ashleymcnamara), [Kent C. Dodds](https://twitter.com/kentcdodds/), [Ben Ilegbodu](https://twitter.com/benmvp), [Chris Coyier](https://twitter.com/chriscoyier), [Tracy Lee](https://twitter.com/ladyleet), and [Emma Wedekind](https://twitter.com/EmmaWedekind).

![Keynote speaker on stage at All Thing Open 2019](https://res.cloudinary.com/echobind/image/upload/v1661873991/echobind_blog/jsob4pcx9k1crwdfpi3k.jpg)

Besides the keynotes, the smaller sessions and workshops were a great opportunity to learn from other speakers on various topics such as front-end engineering, back-end engineering and devops.

![Group learning about Developer Advocate](https://res.cloudinary.com/echobind/image/upload/v1661874265/echobind_blog/xyrs4eqcy6fyidf1ggay.jpg)

Learning about being a Developer Advocate at Facebook from [Cami Wiliams](https://twitter.com/cwillycs)

I really enjoyed the conversations I had with people over meals or in-between sessions. Raleigh has numerous appetizing restaurants so it was easy to find a place to share good food and conversation.

![Club sandwich and tater tots on a plate](https://res.cloudinary.com/echobind/image/upload/v1661874733/echobind_blog/zx9lsxbptqz5kjubtf8w.jpg)

A delicious club sandwich and tater tots I had for lunch one day

## Recommended Talks

Luckily, ATO recorded the keynotes and a select few of the smaller sessions. Of those, here are the ones I recommend watching:

You can find other recordings from ATO 2019 on their [YouTube channel](https://www.youtube.com/channel/UCBhXFK70DbOU15N2BhDQVTg/videos).

Not included: two talks I wish I could include here, but I couldn’t find the recordings for were **“Does Tech Really Have a Pipeline Problem? Exploring Diversity & Inclusion”** by Tracy Lee and **“Building High Performance Teams Across Cultures”** by Emma Wedekind.

That’s all! If you’re not convinced by now, all I can say is buy a ticket to All Things Open 2020\. You will not regret it!

---

[View on echobind.com](https://echobind.com/post/allthingsopen-2019-recap)

---

# Reinvesting in Echobind

> Oct 22, 2019 | Here's what it looks like to reinvest in Echobind.

_By Michael Yared · 2019-10-22_

Laptops are for laps.

In September of last year, we wrote a post titled [Investing in Echobind](https://echobind.com/post/investing-in-echobind) that touched on all the rad ways our agency was expanding. Even then, we didn’t anticipate the rapid growth and exciting opportunities that were on our horizon. In a year, our team more than doubled in size. We’ve made a number of new engineering hires, continued to build our creative offering, and adopted new tech to better assist our clients.

## New Hires

We’re thrilled to have added eleven amazing people to our team since the start of the year. The positions include engineers, designers, strategists, and operations (our first internal hire!)

* **Anne Tolmie**, Account Manager
* **Deen Denno**, Software Engineer
* **Gabriel Martin**, Associate Engineer
* **Glenn Hayes**, Senior Account Manager
* **Jenn Robison**, Senior Software Engineer
* **Joe Previte**, Software Engineer
* **Josh Buchea**, Software Engineer
* **Kory Tegman**, Senior Software Engineer
* **Michael Dang**, Designer
* **Mike Cavaliere**, Senior Software Engineer
* **Sarah Case**, Director of Operations

## Creative Expansion

Much of our growth has been fueled by our clients’ need for more sophisticated mobile applications. These apps that fit in your hand extend what our team has been doing with web apps and APIs since our inception.

Folks building their first mobile app don’t often realize that mobile apps almost always need a supporting web app. These supporting web apps may be for administrators to surface and manage user data or serve as a means for mobile subscriptions that don’t incur app store costs.

Because of this, our mobile work led us down the path of bringing more of our creative offerings in house. Today, we’re happy to say that in addition to crafting beautiful and functional designs, we’re spending almost as much time planning our applications as we are engineering them.

This work has lead us to solve problems earlier in the development cycle and reduces the complexity of our projects so that they ship sooner and with fewer bugs. (We’ve even helped some clients realize that they should go back to the drawing board before continuing a project since we didn’t see a clear to an ROI!)

We’ve been fortunate to work with clients in the following areas:

* Application Audits
* Product Discovery
* Design Sprints
* User Experience Interviews and Mapping
* Continuous Digital Strategy

Our investment in our creative work is ongoing. We’re exploring new partnerships and opening several full-time positions in the coming year. Stay tuned!

## Hello, Chatbots

We give our team the ability to spend time each week investing in their personal goals that align with our goals as a company. With this investment time, our team gains relevant skills that help current and future client requests. We experiment with unvetted technologies by learning the ins and outs before we sell it as a service.

A byproduct of this investment time is our ability to strategize and develop functional chatbots. Over the last year, we’ve worked closely with two of our healthcare clients to round out our skills and build company processes and checklists to accelerate future development.

We despise buzzwords, so to be clear, we consider chatbots to be software that listens to your users and responds reliably. Mike Cavaliere has lead our company’s internal research over the last year, and we’ve had the opportunity to develop and work with our clients on the following:

* Deterministic conversational interfaces that are web, mobile, and API-driven
* Content management systems that allow for our clients to update their messaging
* Visualization tools to view and triage specific conversation branches

We’ll continue working with clients on chatbots this year regardless of whether the chatbot is a single feature or the app’s core feature.

## Summit 2019

![Echobind 2019 summit logo](https://res.cloudinary.com/echobind/image/upload/v1661873646/echobind_blog/tci1gllqtakmqoq5lrb2.png)

It’s time for our annual company summit. We’re happy to announce we are headed to sunny San Diego to spend five days leveling up our strategic skills and collaborating to build several products that we hope will make our team more efficient.

Summit is a time to remove ourselves from the day-to-day, come together as a team, and challenge ourselves to sharpen the saw. It’s also the start of how we set the tone for the new year, both in terms of how we want to grow the company and recommitting to what we want our company culture to be. We look forward to sharing what we’ve learned (and likely some epic surf pics) when we return!

---

[View on echobind.com](https://echobind.com/post/reinvesting-in-echobind)

---

# Rolling Your Team RPG Style

> Oct 21, 2019 | As hard as it is for some people to believe, developers are not robots, we are human beings. Even harder to believe, we each have unique personalities. Some days it feels like we are in a bad enterprise commercial.

_By Matt Thompson · 2019-10-21_

As hard as it is for some people to believe, developers are not robots, we are human beings. Even harder to believe, we each have unique personalities. Some days it feels like we are in a bad enterprise commercial. We each speak to our own “sport”, explaining that we actually did(do) something else with our lives besides stare at code all day and manage expectations. I don’t know about you, but it’s weird. While we are aware of this, we rarely seem to leverage our personalities when forming teams and taking on a project. We should be more self-aware and pay attention to the types of people we interact with mixing our personalities to shape how we operate in our day-to-day.

There are many ways to get a glimpse into your friends and co-workers' personalities, Myers-Briggs, Enneagram, Karaoke, etc. Keeping the geeky stereotype alive I wanted to compare some of these personality traits to that of an RPG (role-playing game) character. People spend countless hours in what is called “rolling a character” or creating the perfect combination of skills to mix with their playing style. They spend even more time pairing a character with others to ensure a successful mission in the game. The goal is to understand your character’s strengths and weaknesses in hopes to find a balance with your teammates. So why don’t we take the time to do this in real life?

If you’ve never played a role-playing type game before, don’t worry the breakdown is fairly simple to pick up. I’ll be alluding to these types of characters:

* The Scout (Planner, lookout)
* The Tank (Shield, Protector)
* The Melee Attacker (up close, swords, axes, hammers)
* The Ranged Attacker (Archer, Mage)
* The Rogue (Sneaky Specialist)
* The Healer (Support)
* The Dungeon Master (Narrator/Organizer)

_For the avid gamer’s out there — These roles are being defined generally for the purpose of this article… Don’t overthink it._ **_Pew Pew_**

**The Scout**

The primary job of the scout is to move ahead of the team and alert back with any potential traps, enemies, or danger that fall ahead. Once the team has caught up, the scout either continues ahead or assumes a _lookout_ type of position calling out more potential threats. They feel validated when the team is informed and prepared for what comes next.

**The Tank**

The tank’s job is not to finish the mission but to hold the attention of the boss while the rest of the team takes care of business. The tank is a guardian and protector. Covered in armor and carrying a shield they are there to serve as a barrier. The tank will also guide the team, calling out what to focus on next during battle. They feel validated when the team is unharmed and able to press forward.

**The Melee Attacker**

Typically right behind the tank is another armor-clad warrior carrying a large ax. Normally with a bit of a chip on their shoulder, these folks just want to, what the gaming community refers to as, ‘_smash and bash’._ The melee attackers prime goal, a headcount. With large sweeping motions the melee attacker will jump headfirst into a mob of enemies attempting to clear the field. They feel the most validated when they see the carnage left behind them knowing every enemy has been slain.

**The Ranged Attacker**

Similar to the melee attacker, the goal here is to clear the field. However, the ranged attacker always seems to be a bit more _specialized_ in their area and able to focus on objectives and typically single targets. Surprisingly enough the melee attacker cannot just charge through and expect to make it out alive. They get cocky… the ranged attacker knows this and has their back. As the melee starts clearing the field and moving forward, ranged support picks off targets missed by or flanking the warrior. However helpful, this is not their sole job. Ranged support can also pair with the scouts and start carving the battlefield to move the team forward. A _friendly_ competition normally occurs between the melee and ranged folks about which approach is better, but you need both to succeed. They also feel validated when the field is clear and the job is done.

![That still only counts as one gif](https://res.cloudinary.com/echobind/image/upload/v1661873689/echobind_blog/gid06klzunubpx9ioctd.png)

**The Healer**

The healer’s job may be obvious but painfully underappreciated. Their goal is to renew the team, keep morale, and keep everyone alive. The healer can support in a variety of ways, healing obviously, but if planning has gone according to plan at this point the healer may join the battlefield in their own way supporting and picking off enemies. Typically though they keeping everyone else on the battlefield. It always came as a shock to me in games that Healers often had an ability to support their teammates for a short time after death. It’s like the game knew they were set up to die… They are validated when everyone survives **and** remains in good health. The battle is not over for them until everyone makes it home.

**The Rogue**

The team is in the middle of battle, plans are going according to plan, enter the unknown… There’s a new threat on the horizon but the team is too preoccupied. Shifting away from their own duties would surely mean death. Enter the specialist. A rogue has been hiding in the shadows this whole time observing the battle, without anyone knowing. Their ability to enter and exit the battlefield gives them the prime opportunity to pick off this new threat before the team is overwhelmed. Their strength, however, is also a weakness, once spotted, they are in the battle for the long haul. Generally specialized, the rogue has been waiting for the best moment to strike, making the best use of their abilities for the team before entering the fight. They are validated when they can remain unseen and continue to strike from the shadows.

**The Dungeon Master**

Who signed us up for this war anyway? All a sudden I’m with these other people and we are just supposed to make it work. Why was I chosen? Enter the DM (PM). The DM got word of a looming threat via messenger. With little information to go off of, the DM sought you and your teammates out to fulfill the need. While the mission may not be exciting, the pay is good. The DM is validated when missions are successful and the team returns victoriously excited for their next adventure.

## Rolling your Character and Team

So which are you? Naturally, our personalities will lean toward one or the other. Do you prefer to just smash through work with brute force, or do you care more about keeping your team alive and well? For a developer team, these roles can even be mapped out by company roles. There’s normally a Project Manager informing the team of its next client (mission) while distracting the client and boss as the team presses on. A Lead Developer may take the scout position, spiking out solutions ahead of time observing possible pitfalls and scope creep. A few more developers start clearing the field (tickets) before inevitably unknown scope does creep in. Enter the senior dev, you normally don’t see this person but today they were by your side, able to unblock you and your team to keep momentum on the project. You go to thank them… but they’re already gone, \*\* **poof**.

In truth, especially in consulting work, you’ll be called to fill all of these roles at some point, depending on the size of the team you may be fulfilling multiple roles. The trick, find the balance between the team. Know your own strengths and weaknesses and create momentum. What happens if you are thrown into a role you aren’t comfortable with? Make it known, for starters. Maybe there’s someone else better suited for the role. It’s not a bad thing. As humans, we are too fearful to miss out on opportunities and too proud to admit otherwise that we set ourselves and our team up for failure. We are taught that “No” is negative when in fact it’s just being transparent. Think about it, no one would argue with this phrase in a game _“I’m an Ironclad warrior with a battle-ax, I probably shouldn’t be healing”._ Know your strengths and weaknesses keep a balance.

![There’s plenty for the both of us, may the best dwarf win gif](https://res.cloudinary.com/echobind/image/upload/v1661873696/echobind_blog/orrjanldjpoa9shfqquo.png)

What happens when no one else is available? Hopefully, there are people to reach out to… but that’s not always the case. Going with the same analogy above — You’re carrying a battle-ax and you see a teammate getting overwhelmed. You can’t heal them, so what do you do? You can’t just let them die — can you? At our core, regardless of personality and skill, we have the choice and ability to be a good human. Doing the right thing is not always easy, in this scenario, the goal is to survive and there is strength in numbers. You let your teammate know they’re not alone, you pick up your ax, and you get to work. Noting is ideal, but the worlds not perfect. You fight on, reassuring your teammate that someone has their back.

In the end, whether real-world projects or fantasy middle earth battles, remember to:

* Keep a balanced team
* Don’t kill your support
* Be self-aware, know your strengths and weaknesses.
* Don’t let pride overtake you
* Don’t let your friends fight alone
* Keep your tools sharp — there’s always another day

**Until next time …**

![Certainly of death, small chance of success… What are you waiting for gif](https://res.cloudinary.com/echobind/image/upload/v1661872998/echobind_blog/or6e29wqfh0n5czzycl6.png)

---

[View on echobind.com](https://echobind.com/post/rolling-your-team-rpg-style)

---

# This Month We Learned - September 2019

> Oct 19, 2019 | September Edition‍: At Echobind, we strive to create a culture that fosters growth, full of people who want to grow. Our aim is to constantly learn new things and share them with one another. Our "This Month We Learned" series is a monthly piece about some of the things we’ve learned as a team over the previous month. The spirit of Fall is in full blow at Echobind. The following are some acorns of wisdom we harvested in the month of September.

_By Anne Tolmie · 2019-10-19_

### _September Edition_

At Echobind, we strive to create a culture that fosters _growth_, full of people who want to _grow_**.** Our aim is to constantly learn new things and share them with one another.

Our _This Month We Learned_ series is a monthly piece about some of the things we’ve learned as a team over the previous month.

The spirit of Fall is in full blow at Echobind. The following are some acorns of wisdom we harvested in the month of September.

### 1\. Kory showed us an awesome resource to find useful tips about Ruby on Rails.

It includes a comprehensive list of best practices along with random gotchas. You can find the link Kory is referring to [here](https://rails-bestpractices.com/).

![Tweet about Ruby on Rails](https://res.cloudinary.com/echobind/image/upload/v1661874099/echobind_blog/g5tu1ja0heghrnlv9cv4.png)

### 2\. Our CTO, Chris, showed us a flag you can pass to ts-node to improve performance.

By default, ts-node will check all types in your project on execution. However, when running commands that migrate the database or start a server, this is probably not necessary. By using \`TS\_NODE\_TRANSPILE\_ONLY\`, ts-node will convert TypeScript to JavaScript, but skip the type-checking. This will be significantly faster.

![Today I learned tweet by CTO Chris Ball](https://res.cloudinary.com/echobind/image/upload/v1661874013/echobind_blog/qzxeqdoabw12evcrvsz5.png)

### 3\. We learned from Isaiah how cool it is to use this package!

[Here](https://www.npmjs.com/package/start-android-emulator) is the link to the package. Stay cool, like Isaiah!

![Today I learned tweet by Isaiah Grey](https://res.cloudinary.com/echobind/image/upload/v1661872803/echobind_blog/rper2ygeufimjjecehie.png)

### 4\. Ryan taught us about the performance utility built into Javascript.

The benefit? It can help you measure loading and execution speeds with a greater degree of accuracy than comparing _Date_ objects.

![Today I learned tweet about JavaScript](https://res.cloudinary.com/echobind/image/upload/v1661872810/echobind_blog/pbeehkgceyhyb6exqfn8.png)

### 5\. Joe, currently known as TypeScript Joe, taught us about renaming a GraphQL filed in your query with an alias.

In GraphQL, when you ask for data, you have to ask for things based on their actual names. Sometimes, you want to change the name when you get that data back, so you can do that with an alias.

In the GraphQL schema, the data he wanted was called _timeRecord_. He wanted it to be called _updateTimeRecord_ so he used an alias to achieve this.

![Today I learned tweet about GraphQL](https://res.cloudinary.com/echobind/image/upload/v1661872818/echobind_blog/cbsrvtqc7kclibyg9jvj.png)

Thanks for learning with us!Feel free to reach out to us through our [contact page](https://echobind.com/contact) with any thoughts or questions. Until _next_ month!

---

[View on echobind.com](https://echobind.com/post/this-month-we-learned-september-2019)

---

# How to Mock Using Jest.spyOn (Part 2)

> Oct 16, 2019 | Mocking is an important concept in testing where a subject that is dependent on data has said data replaced so that it can be controlled and measured.

_By Jeffrey Zhen · 2019-10-16_

_This is part 2 of my JavaScript testing series. You can check out_ [**_How to Write Functional Tests in React (Part 1)_** _here_](https://echobind.com/post/how-to-write-functional-tests-in-react-part-1)_!_

Mocking is an important concept in testing where a subject that is dependent on data has said data replaced so that it can be controlled and measured.

There are a handful of ways you can mock in [Jest](https://jestjs.io/docs/mock-functions). You can mock a function with `jest.fn` or mock a module with `jest.mock`, but my preferred method of mocking is by using `jest.spyOn`.

## Tracking Calls

`jest.spyOn` allows you to mock either the whole module or the individual functions of the module. At its most general usage, it can be used to track calls on a method:

```javascript
const video = {
  play() {
    return true;
  },
};

export default video;
```

```javascript
import video from './video';

test('plays video', () => {
  const spy = jest.spyOn(video, 'play');
  video.play();

  expect(spy).toHaveBeenCalledTimes(1);
});
view raw
```

Any call to `video.play`, either in this test file or (if the function is being called as a side-effect) in some other file, will be tracked within this `test('plays video', () =>{}`) function.

## Overwriting/Mocking A Function

If you want to mock out an implementation and overwrite the original function, you can chain `.mockImplementation` to the end of `jest.spyOn`:

```javascript
test('creates Contract on correct date', () => {
  const NOW = '2019-05-03T08:00:00.000Z';
  const mockDateNow = jest
    .spyOn(global.Date, 'now')
    .mockImplementation(() => new Date(NOW).getTime());

  const mutation = `
    mutation createContract {
      createContract {
        startedOn
      }
    }
  `;

  const response = await graphQLRequestAsUser(mutation);
  const { data } = response.body;

  expect(data.startedOn).toEqual(NOW);

  mockDateNow.mockRestore();
}); 
```

In this test, we are mocking the implementation of JavaScript’s global `Date.now()` function. We set it to return a static value of `2019-05-03T08:00:00.000Z` (converted to milliseconds).

On the backend, where `createContract` is implemented, we use `Date.now()` to define the `startedOn` field of a `Contract`. When `graphQLRequestAsUser` is called, `createContract` will be run on the backend and will use the mocked `Date.now()` to return the date we set (instead of the actual `Date.now()`).

By mocking `Date.now()`, we can ensure that:

1. createContract is creating Contract records with a startedOn field in the correct format
2. our tests will pass consistently because Date.now() is returning a value that we can confirm every time

## BONUS: before/after Hooks

We can use jest’s `beforeEach` and `afterEach` hooks so that we keep our tests DRY when they have similar environments to setup:

```javascript
const now = '2019-05-03T08:00:00.000Z';
let mockDateNow;

beforeEach(() => {
  mockDateNow = jest.spyOn(global.Date, 'now').mockImplementation(() => new Date(now).getTime());
});

afterEach(() => {
  mockDateNow.mockRestore();
});

test('some test name', () => {
  //...do some test stuff here
})

test('another test name', () => {
  //...do some more test stuff here
})
```

Before every `test` function is run in the file, jest will mock `Date.now()`, and after every `test`, jest will restore the function to its original implementation. Using the `beforeEach/afterEach` hooks for setup ensures that every test is fresh and independent of each other.

_Note: we could probably use `beforeAll/afterAll` instead of the tests aren’t mutating the date._

I hope this article helped you understand the usage of mocks a litter better. Please don’t hesitate to reach out if you have any questions. You can drop us a line through [**Echobind’s contact page**](https://echobind.com/contact) or just leave a comment here. I wish you the best of luck to you on your next npm run jest!

---

[View on echobind.com](https://echobind.com/post/how-to-mock-using-jest-spyon-part-2-3)

---

# 8 Business Reasons to Adopt GraphQL and Apollo Server

> Oct 15, 2019 | If you’re wondering why (or whether) you should adopt GraphQL in your organization (or whether you should), this article is for you.

_By Mike Cavaliere · 2019-10-15_

GraphQL, other than being one of the hot, relatively new buzzwords in web development, is a technology that has a lot of practical business applications. But it’s a lot easier for software engineers to understand it than business stakeholders.

Technical people have been adopting it for a number of reasons; but what about the non-technical business folks? If you’re wondering why (or whether) you should adopt GraphQL in your organization (or whether you should), this article is for you.

## What is GraphQL?

If you already know what GraphQL is, skip to the next section. For those that need a primer, GraphQL is a methodology for interacting with databases. The “QL” stands for “Query Language, ” which is accurate; GraphQL is a language for querying backend systems from an application that is more robust and lean than conventional APIs, but much simpler and safer than directly interacting with the database via SQL.

In some ways, GraphQL is thought of as an evolution upon other ways of constructing APIs for web applications for communicating with their backends. We’ll go into some of these reasons in the next section.

## Some challenges of REST

REST APIs are great and have become the standard for over a decade. REST was a natural evolution past its predecessor, SOAP, and solved a lot of challenges that were commonly present in SOAP APIs. REST is very commonplace and quite mature now, and while it’s very strong at doing some things, naturally it has its own limitations as well. GraphQL’s strength — among others — is addressing a number of these weaknesses.

## Excess data == slower performance

Sometimes you want your app to retrieve a list of products with all their details (different photos, technical specs, and dimensions); sometimes you want only basic info like the product name and thumbnail image.

With REST, this means doing things that can get messy; creating random parameters to your /products API call that tells it which data to bring back, or creating ad hoc API endpoints like /products/basic and /products/detailed. This bloats your codebase and can get messy as it scales.

Then let’s say you want to get a list of product collections with all the products associated with each. Either you’d do something like the solution above (make /collections return all product details along with the list of collections), or if you’re trying to keep your “resources” separate, you’d make one API call to /collections and another to /products, then mash the data together in the app. In either case, you’re slowing things down (the second case more so, since two API requests will be slower than a single, fatter API request). Both situations work, but neither is ideal.

## Versioning

With REST APIs, to update a single endpoint you have to duplicate the API structure, add a v2 (or v3, v4, etc) prefix to the URL path and reproduce each endpoint. Using the example above, this means creating /v2/products, /v2/collections and so on. Then the apps themselves need to be upgraded to point to these new URLs.

## Enter GraphQL

One of the benefits of GraphQL over traditional REST is that it helps you retrieve exactly the data you want; nothing more, nothing less.

Using the example above, your collections page in the app could be retrieved by a single GraphQL query that says, “Give me only the product collections I want, only the products I care about in those collections, and only the product information I want.” And if you have different places in the app that require different details for products or collections, I can define another query that also gives me exactly the data I need for each particular screen.

### GraphQL Business Benefit #1: Efficient data == Speed == engagement

Based on the above, you can hopefully understand that building an API using GraphQL is very efficient; efficiency lends itself well to speed, which means your customers are waiting around collectively less. Speed is highly correlated with better software engagement since customers aren’t waiting around for requests to complete. For websites and apps, it’s also a major factor in SEO. And both SEO and customer engagement contribute directly to revenue and company perception. Faster apps mean better business.

### GraphQL Business Benefit #2: Quicker Feature Turnaround

There are a lot of cases in which, after some initial setup, developers can engineer features in GraphQL quicker than they would against traditional REST APIs. Once a REST API is established and there are app features making requests against its endpoints, those existing endpoints can’t be refactored easily without the risk of breaking the existing features or having to add new API endpoints ad nauseam.

Alternatively, a REST API can be versioned; that is, if the app is working against version 1.0 of the API, a version 2.0 can be built and the app can gradually be adjusted to work against it. However, that can be a slow process, and if rushed it could mean the app gets messy since it might be using both versions of the API at once.

With GraphQL, you can add new features as quickly or slowly as you need to, without worrying about backward compatibility. Since GraphQL’s query resolvers aren’t dependent on each other, you can add new ones without breaking anything. So say goodbye to the notion of having to version an entire API just to make improvements to existing features.

### GraphQL Business Benefit #3: Type System == Less Bugs

In software development, strong typing (a feature of some programming languages) is a way of enforcing that a piece of changeable data will always be of a certain type. If I define a bucket that only numbers can go into (as opposed to text, or true/false values), then that bucket will contain only numbers; I’ll never expect a number and get something else. This essentially eliminates the possibility of an array of software bugs that result from expecting one type of information and getting another.

Similarly (though not quite the same as strong typing), GraphQL provides typed API data. When you define your GraphQL schema, you can declare that a User query will return a User that has an id, first name, last name, and email. That same User definition can potentially be used in your mobile or web app’s codebase, which means that when your app pulls data from GraphQL, it’s going to get what it expects (e.g., a number for id, and text for first/last name) — this is especially transparent if you’re using a type system like TypeScript in your app. The more you can control typing in your application and API, the more stable your software will be in general.

### GraphQL Business Benefit #4: Developer & DevOps Tools == Happier Developers

Because of the popularity of GraphQL, a rich array of developer tools have gained adoption which makes GraphQL not only easier to work with, scale and maintain, but more enjoyable to work with as well.[ GraphiQL](https://github.com/graphql/graphiql) and [GraphQL Playground](https://www.apollographql.com/docs/apollo-server/testing/graphql-playground/) let developers work easily with their data and see the structure of their APIs at a glance;[ Prisma](https://www.prisma.io/with-graphql/) makes creating a GraphQL API even easier and very performant;[ GraphQL-tools](https://github.com/apollographql/graphql-tools) helps developers generate and test their schemas appropriately; Apollo Server is phenomenal, and there are plenty more. @matt has a great post talking about the technical details of a number of great tools out there. And in general, more tools like this for each developer task means easier, faster, and more enjoyable development.

### GraphQL Business Benefit #5: Faster Developer Output

Because GraphQL allows developers to pull complex combinations of data, implementation can be faster than with REST or other API architectures; rather than pulling your data from two or more places and joining it together, you pull it from one place.

Adding to that, the self-documenting nature of GraphQL means less time spent writing and adjusting documentation; the docs are already done the minute you write the code. And while using GraphiQL or GraphQL Playground developers can read the docs easily alongside their query code as they’re writing it.

The combination of small things like these adds up to one thing: more developer time getting freed up to allocate toward growing and improving your application.

### GraphQL Business Benefit #6: Easier Versioning

Versioning in GraphQL is by default backward compatible, with fewer updates required. For example, to allow apps to pull an \`avatar\_image\` field from the \`/products\` endpoint, no duplication of the API structure is needed, and no version number needs to be added to the path. You simply enable the new field to the \`products\` portion of the schema, and apps can retrieve it at will. It’s automatically backward compatible, and you can remove any old fields at your leisure.

This not only reduces development work even more since less API work is required to add features, but it reduces redundant functionality (since there’s a need to duplicate a whole API structure). It also means your API requests stay lean; since the GraphQL endpoint doesn’t automatically send back any old data for backward compatibility, new versions of the app are still only getting exactly the data they need and nothing more.

## Business Benefits of Apollo Server

All of the above are perks of using GraphQL itself as a way of querying your data over HTTP. By using Apollo Server, you get a number of other benefits that fit into a wide array of development projects and existing architectures.

### Apollo Server Business Benefit #1: Universal Compatibility & Incremental Adoption

Adopting new web services can sometimes mean rewriting old client and server code, and introducing the risk of breaking things. Apollo lets you run GraphQL on top of your existing APIs, whether they be REST, SOAP or anything else. In addition, it doesn’t matter what web server (or serverless) setup you’re using either; Apollo has integrations for Express, Restify, Microsoft Azure, AWS Lambda, and just about every setup you can think of. It also can be run by itself if you choose to go that route.

What this means: not only is it going to work well with what you’ve already got, but you can adopt it incrementally and gradually. Once you setup Apollo Server and add Apollo Client to your app, you can choose to have one feature use it, two features, or a dozen. Only use it for new features, or gradually port old ones to it. Leave the old ones running against the existing APIs for as long as it makes sense for your team and your business. You have full control.

### Apollo Server Business Benefit #2: Fine-Grained Caching == More Speed == More Engagement

With Apollo Server, you can now cache your API queries on a far more granular level than with typical REST or any other API format. Instead of either caching or not caching users and blog posts, you can decide to cache users and blog posts selectively based on criteria like how often their content is viewed.

This means a large speed boost right out of the box if you don’t have caching already; if you do, it means caching anything that doesn’t need to change as often and making the specific data that changes often refresh at will. Just like the way GraphQL allows you to query your data, Apollo allows you to cache it in a way that is much more exact than before possible. The net result: speed, and a great handle on it.

Hopefully, this article gives a robust introduction to the business value GraphQL brings to the table. It’s worth noting that adopting new technology like this doesn’t necessarily come with some upfront time and learning investment since it’s a new paradigm and toolset for many. And the setup of Apollo Server and Apollo Client takes a non-trivial amount of work. But that upfront investment is worth it for a great many use cases and extremely minimal for experienced engineers. I highly recommend looking into how GraphQL and Apollo Server might be a fit for your team’s technical goals.

---

[View on echobind.com](https://echobind.com/post/8-business-reasons-to-adopt-graphql-and-apollo-server)

---

# California Consumer Privacy Act — 79 Days Until the CCPA Goes into Effect

> Oct 14, 2019 | We thought it would be beneficial to put together a short Frequently Asked Questions (FAQ) document about the CCPA.

_By Echobind Team · 2019-10-14_

The CCPA goes into effect in 79 days! For some of you, this day will come all too soon, and it is a lot to think about. We are thinking about it too. In fact, many of our clients have been asking how this will impact them.

They asked — we listened.

We thought it would be beneficial to put together a short Frequently Asked Questions (FAQ) document about the CCPA. This is by no means an exhaustive list, but it will ready your team to review your own applications. We anticipate more information and clarity as we approach January 1st. I encourage you to do your own research if you are a business operating in California, or are conducting business with clients living in California. Below you will find more information specific to who this will impact, but in my opinion, it will be affecting everyone — Nationwide — and soon.

## What is the CCPA?

The CCPA stands for [California Consumer Privacy Act](http://leginfo.legislature.ca.gov/faces/codes%5FdisplayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5). It is a bill that is intended to increase privacy rights and consumer protection for residents of California, USA. Amendments to the CCPA were passed on September 13, 2018.

## When does the CCPA go into effect?

The CCPA becomes effective on January 1, 2020.

## Will there be any changes before it goes into effect?

Potentially, yes. There is currently a document of [Proposed Regulations](https://www.oag.ca.gov/sites/all/files/agweb/pdfs/privacy/ccpa-proposed-regs.pdf). The [Attorney General](https://www.oag.ca.gov/privacy/ccpa) is accepting written comments until December 6th, 2019.

## Who must comply with the CCPA?

**Any**businesses operating in California that collect personal information about its consumers that meets any of the three statements:

* Has annual gross revenues in excess of $25 million;
* Possesses the personal information of 50,000 or more consumers, households, or devices; or
* Earns more than half of its annual revenue from selling consumers’ personal information.

## Can this affect me if my business is not physically present in California?

**Yes** The CCPA does not require you to be present in California. It will affect you if you are conducting business with California residents and have the following:

* Annual gross revenues in excess of $25 million;
* Possesses the personal information of 50,000 or more consumers, households, or devices; or
* Earns more than half of its annual revenue from selling consumers’ personal information.

## What if my business does not comply?

Failure to comply will result in the maximum civil penalty of $7,500 per violation, per individual if the business intentionally violates it. Otherwise, the max penalty is $2,500 per violation, per individual.

## What is on the horizon for other states in the USA?

Roughly about 10 other states are purposing a similar law to the CCPA. Hawaii, Maryland, New York, and Washington, to name a few, with Maine recently passing. This means you will need to comply in each jurisdiction if this happens.

## How can my company comply?

1. **Notify consumers about data collection**. Businesses must inform individuals what information is being collected about them. You need to do this before or at the time of collection.
2. **Prepare for access requests**. Consumers may request a record of what collected information, where it came from, how it was used. Consumers can also ask which third parties received a copy of the data. According to the [Proposed Regulations](https://www.oag.ca.gov/sites/all/files/agweb/pdfs/privacy/ccpa-proposed-regs.pdf), businesses must provide two or more designated methods for submitting a request.
3. **Allow consumers to opt-out.** Under this new law, consumers may opt-out of sharing personal information. A business cannot ask a consumer to change their choice for a period of 12 months.
4. **Consider Minors.** Minors under 13 years old require their parents’ consent for their data to be sold. Minors 13 to 16 can opt-in themselves.

[For more details, see the Proposed Regulations](https://www.oag.ca.gov/sites/all/files/agweb/pdfs/privacy/ccpa-proposed-regs.pdf), but remember these may be subject to change.

We hope this has been helpful. We try to look out for our clients on matters that will be impacting them. Do not hesitate to [reach out if you have any further comments or questions](https://www.echobind.com/contact).

---

[View on echobind.com](https://echobind.com/post/california-consumer-privacy-act-79-days-until-the-ccpa-goes-into-effect)

---

# A Reflection: Building a GraphQL API with Nest.js

> Oct 08, 2019 | Nest.js as a framework for Node/TypeScript development compared to our traditional stack, with a build as proof of concept (POC).

_By Joe Previte · 2019-10-08_

The GraphQL Playground endpoint for my Nest.js/GraphQL API

During my investment time, I explored Nest.js as a framework for Node/TypeScript development. In order to compare it to our traditional stack, I decided to build a proof of concept (POC). I wrote this piece in order to reflect on what I built, and share my thoughts with the community.

## What I built

I built a GraphQL API using [Nest.js](https://nestjs.com/), which connects to a Postgres database with [TypeORM](https://github.com/typeorm/typeorm). I also added authentication using [OneGraph](https://www.onegraph.com/).

## How it works

It works by serving a GraphQL API (Apollo Sever under the hood), which talks to a Postgres database. GraphiQL is served via a static HTML page to the client on the `/playground` route. Mutations are protected by GitHub authentication using OneGraph. In order to execute any mutations, you must login with GitHub. Queries are all unprotected. On top of that, only members of the `echobind` organization on GitHub are authorized to execute any mutations.

Live demo: <https://jsjoeio-nest-graphql.herokuapp.com/playground>

_Note: the app is running on Heroku so it may take 2 mins to start up_

## How this compares to our recent client project

Our most recent client project used the following tech stack:

* Apollo Server
* GraphQL
* Node.js
* TypeScript
* TypeORM
* Postgres

And this is how data flowed:

![Data flow diagram](https://res.cloudinary.com/echobind/image/upload/v1661874042/echobind_blog/ututghmu85qbflrvtiqr.png)

Data flow in our regular GraphQL setup

Alternatively in the POC, I used this stack:

* Nest.js (uses Apollo Server)
* GraphQL
* TypeScript
* TypeORM
* Postgres
* OneGraph

In the POC, here’s how data flowed:

![Data flow diagram](https://res.cloudinary.com/echobind/image/upload/v1661874488/echobind_blog/qvhup7srg7qqyrght8ex.png)

Data flow in the GraphQL with Nest.js setup

These look almost identical and that’s because they are, with the exception of the “Service” piece in the Nest implementation.

The main difference actually lies in the code structure and organization of files. In our client project, we used categories to organize things.

Whereas in the POC, things were organized by module. The module being the actual thing itself, this might be something like ‘user’ or ‘job’ in the client project.

I don’t believe this type of folder structure is required for Nest, but it’s definitely encouraged via their CLI file generator. You can see another example of this in their [sample/graphql-apollo repo](https://github.com/nestjs/nest/tree/master/sample/12-graphql-apollo/src/cats).

One thing I liked about this approach was that it felt more structured. I knew exactly what files I needed when I set up my module. Every file related to that module was prefixed with the module’s name, which in this case was “employee”.

Overall, I enjoyed the patterns, structure and organization encouraged by Nest. Even if you don’t use it, it may provide a new perspective on file structure that’s worth exploring.

## Pros & Cons

Looking at both approaches, I made a quick list of pros and cons of using Nest.js compared to our other approach.

### Pros

* `nest-cli` gives you generators out of the box (similar to hygen)
* Supports TypeScript out of the box
* Solid documentation
* Framework encourages specific patterns
* Helpful testing utils
* Active development (4 patch releases in last month)
* Feels stable, sturdy → think it would scale well
* Allows single API to support both GraphQL & REST endpoints

### Cons

* Heavy use of decorators makes some things feel like “magic”
* Feels similar to Redux development
* To do one thing, you need an action, reducer, and an action creator
* With nest, similar type of thing (module, service, potentially more)

## Conclusion

Nest.js is an exciting new framework for back-end development. It supports TypeScript out of the box and can provide a quick way to develop a GraphQL API. The opinionated file/folder structure is excellent because it’s one less thing to think about from a developer’s perspective. I plan to explore Nest.js further in the future and keep it in my toolbox for future client projects.

---

[View on echobind.com](https://echobind.com/post/a-reflection-building-a-graphql-api-with-nest-js)

---

# Building Products ft. Hello, Startup

> Oct 07, 2019 | Hello Startup contains valuable knowledge that is beneficial even to startups, larger companies or even a solo developer working on a project.

_By Ashley Nelms · 2019-10-07_

## Building Products ft. Hello, Startup

A book commonly recommended to me lately has been [_Hello Startup_](https://www.hello-startup.net/) and is considered the “Hello, World” tutorial for building products, technologies, and teams in a startup environment. After much urging from friends and colleagues, I decided it was finally time to pick it up.

Contrary to the title, this read doesn’t just apply for startups and contains valuable knowledge that is beneficial even to larger companies or even a solo developer working on a project.

With topics on coding, design, and more, there are many learnings — both technical and non-technical — to take away whether you’re brand new, seasoned, or even a manager.

I find the best way to retain new information is to put them to use — practice makes perfect! During this blog series, I’ll go over some practices and ideas we already have at Echobind, what we could start trying and demonstrate application on a real-world project.

### The Project

I recently met [Eric Harrison](https://twitter.com/Blenderer%5Fcodes), a developer I encountered in a shared online community. After talking nearly every day, it didn’t take long for us to realize we both worked in the tech industry. In addition, we both work from home, so we had a good chat about life in the home office, school, and our experiences so far into our careers.

We discovered we each had a problem when it came to side projects, but for different reasons that complimented each other. He had ideas with low motivation, whereas I had motivation but very few ideas.

This lead us to talking about a project he’s had in development, which is a chatbot for [Twitch](https://www.twitch.tv/) called _gaccha-bot_. This works in a manner similar to opening [loot boxes](https://en.wikipedia.org/wiki/Loot%5Fbox) or trading card packs and receiving items at random. With this bot, stream viewers can “open” packs in chat, trade items, and even have a collection to show off to other viewers.

![iPhone with Twitch app loading screen](https://res.cloudinary.com/echobind/image/upload/v1661874827/echobind_blog/wczseojxx2dbfbxdkm5z.jpg)

After an introduction to the project and the code, it seemed this would be the perfect project to work on while working through _Hello Startup_. There was no hesitation for me to jump at the opportunity to pair up with him and expand my knowledge.

### IDEAS

Many people get discouraged when their first idea for something doesn't work out and I myself have experienced it.

> _“Ideas don’t just magically appear. They grow and evolve… Every single new, creative thing you’ve ever seen is just a mashup of ideas created before it.”_ 
> **_— Yevgeniy Brikman | Hello, Startup_**

While what he says seems obvious, I, like others before me, let myself get so distracted by trying to create a brand new idea that’s never been done before that I become a blocker for myself.

In reality, all new ideas are just, as Yevgeniy would say, mashups of ideas that came before it. Google definitely wasn’t the first search engine and was a transformation of its predecessors. Although chatbots already exist, we are transforming _gaccha-bot_ into something new through a combination of prior ideas and applying what we know about this type of service.

### Limitations and Restrictions

![Speed limit 55 sign on a highway](https://res.cloudinary.com/echobind/image/upload/v1661874567/echobind_blog/rjdslagwbymjvdrlq9n4.jpg)

When thinking of new ideas, it’s hard to keep yourself from thinking of all the possibilities and how it may evolve over time. It’s definitely exciting to think about! However, this can quickly get out of control and soon enough you lose sight of the original idea.

> _“A system with no constraints is like trying to keep 100 balls in the air: you can’t keep track of them all.”_ 
> **_— Yevgeniy Brikman | Hello, Startup_**

Not only do constraints help you keep the original idea in focus, but it can also help if you're struggling to come up with any ideas at all.

One of the best ways to add constraints is to look ahead to where you want the idea to be regardless of how you get there and then work backward. By knowing what you’d like to accomplish — your constraint — you can then work in reverse to layout the steps necessary to reach the end.

If the end vision is hard to picture, there is another and possibly easier way to add constraints: Look for something that is painful that can be made better. This brings us to the next _point_:

### Pain Points

![Man pouring coffee into white mug with UGH written on it](https://res.cloudinary.com/echobind/image/upload/v1661874855/echobind_blog/yt4p2nybtxoeget80b1k.jpg)

When you can find an issue or pain point that could use a solution, you begin to have a clearer idea of what you’re trying to accomplish. This can greatly help narrow down your ideas.

If something irks you or you see someone having a problem, Yevgeniy encourages you to write it down! Even if you don’t know how to solve the problem yet, you may come across this same issue over and over, each time adding new thoughts to the problem.

Learning to identify and fix problems is a valuable skill to have. We are surrounded by tasks that are tedious or problems many are not willing to solve, and so it’s frequently met with a blind eye. However, if you’re the one willing to solve an issue for everyone else, this can result in having a valuable product or service on your hands.

A common pain point for many Twitch streamers is viewer retention. How do you get viewers to stay and watch the stream? Sure, the streamer is providing content with whatever they are streaming, but most times that isn’t enough, especially for the smaller channels.

Many viewers want an engaging experience with their streamer. If a steamer is brand new, they usually have more trouble retaining viewers. In the stream chat, _gaccha-bot_ aims to get viewers engaged from the moment they tune in. After the viewer “opens” a pack they see a message announcing their new item — in some streams this could be Pokémon.

Like opening up a pack of trading cards, this is a fun experience and it’s exciting to see what you’ll get next! Viewers can trade and show off their collection which makes for an active chat, viewers getting excited, and the streamer sharing in the fun with them. A stream that a viewer may have quickly stopped watching may have now stuck around long enough to decide it’s a channel worth following.

### Validating An Idea

![Black journal with Write Ideas logo and pencil on desk](https://res.cloudinary.com/echobind/image/upload/v1661873062/echobind_blog/dsfpmessphxxqetqi85k.jpg)

Often times we think we have the next big idea that will wow everyone. In fact, the idea may already be in use today but you’re adding a slight twist to it. However, that slight twist may not be enough to generate interest or it may be entirely unpopular. The point is it’s essential to validate an idea to see how potential users may respond to it. As amazing as an idea may sound you can’t guarantee it will be a success.

> _“All of these folks are trying to do the same thing: validate their ideas in the market… That is, they are trying to test that their idea works, that they’ve identified a real problem, and that they can build a valuable business on top of it.”_ 
> **_— Yevgeniy Brikman | Hello, Startup_**

To give the chatbot a test run, Eric had a select few streamers add it to their stream chat. From there he could see how people were using it, what they were saying, and so on all in real-time. With a timed message in the stream chat, viewers didn't take long to engage with the bot. There are now over 100 viewers interacting with the bot regularly across just a small handful of streams. This was a good indicator of how the bot was received by users and that it could be expanded into something more.

### Talk To Real Users

When you talk to the users of your idea or product you tend to learn a lot about them and can determine if they are truly having a real problem, what the possible solutions are, and how much they'd be willing to pay for a solution. When it comes to pinpointing this information, it’s best not to be direct. People can be unsure of what they want or say they want something when they really want something else. I myself have been in this same situation. The best way to get to the underlying problem is through listening and observing. Let the user do the talking and narrow it down to what the primary issue is.

Many people have probably heard of the [**“5 Whys”**](https://en.wikipedia.org/wiki/Five%5FWhys). If you haven't heard of it, it’s a way of getting to the root of the problem instead of jumping straight to a solution. The best way to explain this is by using an example.

![Five why’s](https://res.cloudinary.com/echobind/image/upload/v1661874164/echobind_blog/jcz1pffjtu6llqbh7oat.png)

By asking why on each step, you continue to narrow down to the root of the problem and figure out what the real issue is. It may not always be “**5 Whys”**, but at the very least asking one time can be essential in discovering the problem.

## Conclusion

In the next part of the series, we’ll talk about designing a product around ideas. Remember, this is only a fraction of the valuable information that can be found in this book and I highly recommend picking up your own copy for more in-depth explanations and examples.

Until next time!

---

[View on echobind.com](https://echobind.com/post/building-products-ft-hello-startup)

---

# GraphQL — the Dev Edition

> Sep 26, 2019 | In this post, we want to shed some light on the pros and cons, breakdown some of the packages used and leave you and your team with enough insight to make an informed decision on GraphQL.

_By Matt Thompson · 2019-09-26_

## Intro

It’s difficult to be a developer and not experience the hype around GraphQL. I’ve spent the last three years implementing GraphQL APIs in Elixir and Node, watching the tooling and community grow along the way. In this post, I want to shed some light on the pros and cons, breakdown some of the packages used and leave you and your team with enough insight to make an informed decision on GraphQL.

_Note: Your GraphQL server does not have to be implemented with Node. However, I will be detailing a bit of GraphQL history with JavaScript in mind as most will be interacting with these tools at some point via the client. You can see a full list of supported server languages at_ [_graphql.org/code_](http://graphql.org/code)_._

If you would like to skip the history and packages and read the pro and con section scroll down to _GraphQL the good and bad._ Sadly, I could not get anchor tags to work today in Medium. ¯\\\_(ツ)\_/¯

## What’s the Hype all about?

> _GraphQL is an open-source data query and manipulation language for APIs, and a runtime for fulfilling queries with existing data._

As is with any new shiny web tool we’ll start with the docs.

The documentation found at [graphql.org](http://graphql.org/) does a good job at defining what GraphQL is and isn’t, so I’m not going to veer too far from that here. Navigating to [graphql.org](http://graphql.org/) you’ll arrive at a landing page that gives a quick three bullet response to the most common pros.

* Describe your data
* Ask for what you want
* Get predictable results

We will talk about these points more in a moment, but for a lot of lead developers, we have the responsibility to research these tools to ensure their merit. The last thing you want is to see your team ramp up on a new open-sourced tool only to have it crumble from underneath us a few months later. With the open-sourced community being well, open-sourced, it is easy to have a pessimistic approach to development and the tools we use, or at least I do. My internal conversations start with something like, “That all sounds great, but everyone hypes up their work. How do I know I can trust this one?”

### **History of GraphQL**  

Let’s take a quick dive into how it all started and where a few packages are now.

Through Google searching around you’ll find that GraphQL started by Facebook as an internal tool back in 2012\. Facebook had an issue of building a solid API for their mobile apps that could consistently describe their data as they scaled. You can read more of their release details [here](https://engineering.fb.com/core-data/graphql-a-data-query-language/). As you can imagine, this took a while to refine. By 2015, Facebook had released this tool into the wild to help drive the process, similar to how React grew into what we know today. Fast forward a few more years, and GraphQL was moved from Facebook to the newly established [GraphQL Foundation](https://foundation.graphql.org/members/), hosted by [Linux Foundation](https://www.linuxfoundation.org/). Now you have a tool created by a tech giant, refined by the community, and supported by one of the largest open-source investors today. [Other companies](https://foundation.graphql.org/members/) have joined the GraphQL Foundation in support AWS, IBM, and Twitter being a few. If that’s not enough, a quick look into the JavaScript community shows the [graphql npm package](https://www.npmjs.com/package/graphql) alone was downloaded by over 2 million users last week. This is just one package within a single community. But again, GraphQL is not tied to JavaScript ([graphql.org/code](http://graphql.org/code)).

**History of GraphQL tools**

Great! GraphQL seems legit enough to look into further, but now I notice there’s a ton of tooling and ways to implement it.

Agreeably, the noise is hard to sort through. You search GraphQL and a ton of articles (like this one), packages, and tools all appear. There are even articles like this one [“13 GraphQL Tools and Libraries You Should Know in 2019”](https://blog.bitsrc.io/13-graphql-tools-and-libraries-you-should-know-in-2019-e4b9005f6fc2) that try to set expectations for what developers should know.

I’m going to highlight a few of them as a quick overview of where we are:

* Express GraphQL
* GraphQL Yoga
* Prisma (1 and 2)
* Apollo Server
* AWS Amplify

**NOTE:** I’d like to mention that ALL of these packages have merit. There is no one-size-fits-all GraphQL package. I suggest you explore the community, look around and find what best suits your needs. This is not meant to weigh one over the other but hopefully can help get you started.

### **Express GraphQL**

This is probably the quickest way to demo and experiment with GraphQL in my opinion. This setup uses the ‘express-graphql’ and ‘graphql’ packages. This used to be the example given within the graphql docs itself. Ignoring some details below, you can see that Express sets up a route at `/graphql`. This exposes an endpoint pointing to our full `graphql` setup. From here, it's all back to the GraphQL docs to learn how to build out a new Schema, Queries, Resolvers, etc. There’s no doubt these two packages make up the foundation of some of the following tools. This setup will allow you to get your feet wet, spending more time in the GraphQL docs and less time questioning how to set it up.

```javascript
var express = require('express');
var graphqlHTTP = require('express-graphql');
var {
    buildSchema
} = require('graphql');
var schema = buildSchema(`  type Query {    hello: String  }`);
var root = {
    hello: () => 'Hello world!'
};
var app = express();
app.use('/graphql', graphqlHTTP({
    schema: schema,
    rootValue: root,
    graphiql: true,
}));
app.listen(4000, () => console.log('Now browse to localhost:4000/graphql'));
```

As the community took off with GraphQL, you could imagine it became sort of a leg race to be _THE_ GraphQL solve all. If you ask me — that marathon is continuing today. The remaining list below has grown and evolved since their first iterations. As a brief of each, I may have left something out, but again they each have merit, so if something strikes your interest, **_dive in_**!

### [**GraphQL Yoga**](https://github.com/prisma/graphql-yoga)

One of the first tools I remember seeing on the scene — GraphQL Yoga. A look into GraphQL Yoga and you’ll see that it is a collection of packages and tools brought together to make remembering all the boilerplate setup you may need easier. When it started, it used the express-graphql package above, but you’ll notice now that it uses one of the other tools mentioned here: Apollo Server. So, why not just use Apollo Server instead? Some may opt for just that. GraphQL Yoga becomes an abstraction with pros and cons. How much code do you wish to maintain vs having a tool do it for you? Will you run into a wall at some point? In my experience, using any magical create-thing-package will at some point lead to issues. However, for most common apps, you may be just fine. Use your judgment.

GraphQL Yoga’s Pitch:

> _Using these packages individually incurs overhead in the setup process and requires you to write a lot of boilerplate. graphql-yoga abstracts away the initial complexity and required boilerplate and lets you get started quickly with a set of sensible defaults for your server configuration._

> _graphql-yoga is like create-react-app for building GraphQL servers._

### [**Prisma**](https://www.prisma.io/)

Prisma came on the scenes trying to solve the boilerplate issue. I already have my database, I already have my models, can’t we just wrap this in some way? Focusing more on Deployment options and wrappers, Prisma started creating the idea of GraphQL as a service tooling. This came with pre-built filters from your models ditching all custom boilerplate you may have needed otherwise. Below you’ll see their example of posts, \`prisma.posts\` already has a `where` and `orderBy` clause defined, but look further, `where` also has helpers for things like `_contains`, `_ends_with`, etc.

```javascript
const posts: Post[] = await prisma.posts({
  where: {
    published: true,
    title_contains: "GraphQL"
    author: {
      email_ends_with: "@prisma.io"
    }
  },
  orderBy: "createdAt_ASC"
})
```

Prisma is now working on 2.0 which is to include its own type of ORM tooling expanding the above into a more chain-able dot syntax and expanding it’s database migration tools.

```javascript
const postsByUser: Post[] = await photon
  .users
  .findOne({ where: { email: 'ada@prisma.io' }})
  .posts()
```

At this point, GraphQL as a service seems to be a big push. I’ll be interested to see how some of these tools shake out over time. Prisma learned a lot through its first iteration, and while the initial 1.0 setup felt a bit off, 2.0 seems to be making leaps based off community feedback. This is worth keeping an eye on.

### [**AWS Amplify**](https://aws-amplify.github.io/)

Do you run all your services in the cloud already? Are you considering it? Do you want to jump on the Serverless train? AWS, like other tooling, brings their services together to provide what seems to be as close to GraphQL as a service as you can be. I believe as these tools continue to mature, we will see more of a “point this tool at your database…” type of setup. You can set up your DB of choice, add your Schema, Resolver logic, and let AWS manage the rest. Using AWS, which has its own learning curve, removes a lot of the overhead and boilerplate. You’ll be up and running quickly and back to focusing on solving your project’s problems, instead of configuring all the things. This also gives you the freedom to quickly tie into other AWS resources such as S3\. Do you need to have an endpoint to upload files? Chances are you were probably going to use S3 anyway. Do you have IAM roles set? Use them with GraphQL for your authorization and between Amplify and AppSync you’ll be set in no time.

Do you want to stay up to date with AWS Amplify? I’d recommend giving [Nader Dabit](https://twitter.com/dabit3) a follow.

### **Apollo Server**

I know I said there was no one-size-fits-all GraphQL package, I kind of lied. It’s hard to search GraphQL and _NOT_ see Apollo mentioned at this point in the game and for a good reason. While AWS and others are pushing forward with serverless tech, Apollo, at least for now, has kind of set the standard for server/client setups. Regardless of which server-side setup you choose, you’ll be reaching for Apollo at some point for the client-side. Apollo client has been the most supported, and community-driven. It has also improved upon its cache store, subscriptions, and stayed up to date with ESX features and state management features like React Hooks. At this point, Apollo has enough tooling and configuration options to merit its own blog post. It’s safe to say if you aren’t sure which option is best for your team, Apollo is a safe bet.

## GraphQL the good and bad

### Benefits

* **One API Endpoint** — This is normally the first thing you hear about. Simplify all those REST routes for your user into one simple route. Example: api/graphql route. Granted you will be managing Queries and Mutations as “routes” but now the end-user can infer these from automated schema docs, GraphQL playground, etc.
* **Data Normalization** — Sometimes your API may manage calls and data that aren’t it’s own. This is always awkward for the consuming user. What if it errors? The user also has to parse this JSON blob and hope what they need is there. You can help the user by turning those third party calls into defined graphQL calls and normalize the return. This can be as simple as {success: true, data: "JSON"} or take this further, and define Types for that JSON blob. Now not only can the user quickly parse a successful call, but they can ask specifically for the information needed.

```javascript
getBlogPost {
   success
   data { id title body }
   errors
 }
```

* ‍**Multiple Languages** — If you haven’t caught on by now the community is huge. GraphQL has been around longer than most think and is more than just a fancy new way to build a web app. You can use GraphQL in just about any tech stack. [_graphql.org/code_](http://graphql.org/code)
* **Ease in** — Outside of a bit of boilerplate, you do not have to support your entire API all at once out of the gate. You can initialize your GraphQL server and migrate one call at a time, as needed. Supporting both your REST API and GraphQL API can be done simply by relaying calls between the two. There are also community works to wrap a REST API auto-magically with GraphQL. You don’t have to rush it. Take time to define your types and in the long run, it will be worth it.
* **Clean Data** — We’ve hinted at this already, but your data now becomes typed and defined. As long as you’ve got some error handling in play, you can normalize all your results into something human-readable and reliable. Adding things like custom Scalars enhances your data, and ensures it is serialized or parsed before ever reaching your DB/User.
* **Dynamic Use** — Once you get a few endpoints up and running, you’ll realize a lot of the functionality can be broken down into similar patterns. These patterns include filters, order, pagination, etc., as well as relational lookups via Resolvers. Not only will these patterns simplify maintenance for your devs, but now it’s on the end-user to ask for what they need. Instead of supporting 10 different routes for ‘users’, we simply have a query endpoint for users with all the required patterns in play. It's now on the end-user to decide what they need. Maintenance becomes adding new where filters with the appropriate joins as you scale, and the end-user is good to go. Your Front-End devs can also get used to this pattern. I need 'X' users with 'Y' posts. No more long conversations about which route does what, and worrying about if all the data returns. Ask and shall receive.

```javascript
users(where: {...}, orderBy: {...}, pagination: {...}) {
   id
   firstName
   posts (where: {...}, orderBy: {...}) {
     id
     title
     body
    }
 }
```

**Documentation** — Real talk: keeping documentation up to date is a pain. Tech moves fast. With tooling to auto-export Schema, GraphiQL, and [graphQL playground](https://www.prisma.io/blog/introducing-graphql-playground-f1e0a018f05d) at your fingertips, documentation is no longer an issue. Staying diligent to add a quick description line here and there and you are good to go. GraphiQl and Playground will pick up on these lines to give a description to the call, but because everything is now typed, they also show the defined input and output of said call. You may even opt to create a GraphQL playground for your external users/clients. Keep a live server up to date with your GraphQL schema that returns dummy data. Users/clients can use this playground to get a feel for your API and learn how to integrate on their own. With its schema documented, most questions can be answered without the back and forth phone calls.

**Subscriptions** — Need real-time data? GraphQL supports subscriptions out of the box. Create your Subscriptions and have your FE peeps tie in.

**Onboarding** — While I agree there is a lot of boilerplate to set up with GraphQL, once you are up and running, the patterns become super simple to replicate. Need a new Query endpoint? Anyone can look at previous examples and follow along. You may even use template utils to make this process even simpler. New team member? Have them interact with the GraphQL playground for a day. This will introduce business terminology, relations, and current use cases. With GraphQL your goal should be to follow consistent patterns for your end-users to take hold. Once you understand THE pattern, you’re good to go on creating new types and maintaining older DB relations.

**Customization** — It is worth noting again, use GraphQL for what you need, how you need, with the tools you need.

### Counter Weights (Cons)

* **Boilerplate** — I agree that there is some overhead to get up and running with GraphQL. You’ll want to choose what seems to work best for your team and press forward. While you can slowly build up your API, remember there is a Front-End overhead here as well. Your team will probably want/need to set up some sort of cache/store with Apollo to make these calls easier moving forward. When adding new endpoints, it’s all about the pattern. It does become rinse and repeat, but there is still a chunk to replicate.
* **Learning Curve** — There is a bit of a learning curve to GraphQL. What’s a Mutation? What is a Resolver? How do I set up this the pattern I keep hearing about? Above, I mentioned that onboarding becomes easier to follow due to patterns in play. While that is true, your team will still need to learn, communicate, and establish this pattern. That takes some time.
* **Momentum** — Continuing on the note above, establishing the patterns and benefits take time. The time benefits from GraphQL become visible later in the game. Your team is in the thick of your production app and new features and maintenance are occurring. In my opinion, GraphQL is a long term investment. Over time you will refine this build, adding helpful utils, solidifying filters, and relational lookups. As you scale, your team will become more efficient in building with GraphQL and begin to enjoy the benefits as logic changes are needed. As an agency, sometimes this one can be frustrating. We build for our clients with the future in mind. Their team will benefit from the patterns and momentum that we created. We consider it our job to get the stone rolling.

### Don’t recreate the wheel.

While this may be obvious, it’s worth noting. GraphQL has the support of a rallying community. Don’t recreate the wheel before checking out the open-sourced world for solutions. You’ll spend a lot of time building out GraphQL boilerplate that could have been a simple import. Below are some packages that come to mind:

**Date Scalars**

* Node:
<https://www.npmjs.com/package/graphql-scalars>
<https://www.npmjs.com/package/graphql-iso-date>
* Elixir:
<https://github.com/absinthe-graphql/absinthe/wiki/Scalar-Recipe>
<https://github.com/absinthe-graphql/absinthe/blob/master/lib/absinthe/type/custom.ex>

**Dataloader:**
* Node: <https://www.npmjs.com/package/dataloader>
* Elixir: <https://github.com/absinthe-graphql/dataloader>
* Python: <https://github.com/graphql-python/graphene>

[**Code Generating Typescript Types**](https://github.com/dotansimha/graphql-code-generator)

## Is GraphQL a good fit?!

I usually go by a quick smoke test to determine if GraphQL is worth it.

**NO**

* I need to create a small website for my friend Joe.
* We don’t see ourselves needing a lot of endpoints (simple web app)  
_Take the now vs later approach here. Get the simple site up — wrap in GraphQL when/if you start to grow_

**YES**

* Are you supporting multiple Apps (Web/Admin/Mobile)
* Mobile API? (maybe look at Amplify)
* Is this a long term project that will continue to grow and scale?

As to what tools, packages, etc., that is up to you. Use GraphQL for what you need, how you need it, with the tools you need.

## Conclusion

This should serve as a good primer for choosing or not choosing GraphQL on your projects. I plan to follow up on this overview with some code. _“GraphQL — Talk is cheap, show me the Code!”_

I’ll be diving into some of the patterns mentioned here, and showcasing some of our own “gotchas” we’ve solved for along the way. Stay tuned!

---

[View on echobind.com](https://echobind.com/post/graphql-the-dev-edition)

---

# Using Your Values to Manage People

> Sep 16, 2019 | The following are some takeaways from the amazing course Conversations that Drive Performance.

_By Anne Tolmie · 2019-09-16_

‍From a Behavioral Science Lens

The following are some takeaways from the amazing course [_Conversations that Drive Performance_](https://bsci21.org/shop/ceus/on-demand/conversations-that-drive-performance-empowering-employees-with-behavior-science-1-ceu/). Through this course, I was able to understand what is _really_ driving most performance management conversations, how to improve these conversations, and how to ultimately solve the problem. For a more in-depth explanation, take the course.

![Woman holding white mug with Like a Boss on it](https://res.cloudinary.com/echobind/image/upload/v1661873530/echobind_blog/qdoibjfsogcecp9tnd7y.jpg)

If you have ever managed people, you have had to shape behavior. According to Behavior Science, this is done through reinforcement and punishment.

> _Reinforcement is any stimulus that will increase the likelihood of a behavior occurring in the future._

> _Punishment is any stimulus that will decrease the likelihood of a behavior happening in the future._

These contingencies are at play in our every day lives. However, there is a little more to it. There can be positive reinforcement and negative reinforcement. Likewise, there can be positive punishment and negative punishment. I know what you are thinking. Positive punishment? No, this is not a mistake and I am not being ironic. To put it simply, _positive_ means you are _adding_ something to the environment and _negative_ means you are _removing_ something from the environment. See, not so bad.

As a manager, you have probably had to call a meeting to deliver feedback to an employee that was negative(bad). Perhaps they were performing below standards. Is this punishment? From the lens of Behavior Science, no it is not. More than likely, for both the manager and the employee, _the reinforcer is the meeting coming to an end_**.** This is otherwise known as _negative reinforcement_.

Performance management meetings can be stressful for both the manager and the employee. These meetings are often avoided or escaped by either party. In this context, _avoid_ meaning the meeting never happens, maybe the manager reschedules it, and _escapes_ meaning that the meeting happens, but perhaps the employee or the manager says whatever they have to in order to reach the conclusion of the meeting. These escape and avoidant behaviors fail to produce a meaningful conversation. In turn, this will not lead to the desired behavior change and will likely result in more uncomfortable conversations in the future.

![Coffee cup with What Good Shall I do this day? written on it](https://res.cloudinary.com/echobind/image/upload/v1661873538/echobind_blog/gx7fwlyonwyisi6iivmo.jpg)

## How Your Values Can Help

One solution is to utilize the Acceptance and Commitment Therapy (ACT). According to [Association for Contextual Behavior Science](https://contextualscience.org/act) ACT is

> _a unique empirically based psychological intervention that uses acceptance and mindfulness strategies, together with commitment and behavior change strategies, to increase psychological flexibility. Psychological flexibility means contacting the present moment fully as a conscious human being, and based on what the situation affords, changing or persisting in behavior in the service of chosen values._

It is suggested that you, the manager, should set aside some time before your dreaded meeting to consider your values. This may seem trivial, but according to past[ research](https://www.ncbi.nlm.nih.gov/pubmed/16262767), reflecting on values can significantly reduce your stress levels.

In fact, [another study](https://contextualscience.org/p%5Fezblarrina%5Fet%5Fal%5F2008) found that focusing on values resulted in a higher tolerance to discomfort, in which the participants received an electric shock.

With that said, at the very least, reflecting on your values can help you tolerate an uncomfortable conversation with your employees, as well as reduce your levels of stress before the meeting. I would say it is well worth your time.

You might be wondering, how do I reflect on my values? It is recommended that you answer the following four questions. The only requirement is that you answer from your heart.

1. What impact does the work we are doing have?
2. What impact will this conversation make for the organization?
3. What impact will this conversation have on your employee?
4. What impact will this conversation have on you?

![Two women meeting in an office](https://res.cloudinary.com/echobind/image/upload/v1661873545/echobind_blog/oh64klzlh44a3qi3q6pa.jpg)

## The Meeting

Now it is time for you to meet with your employee. Here are your next steps._‍_

_1\. Communicate what the problem is by referring solely to the facts._

2\. _Tell them what you envision them moving towards by referring back to your values._

_Try to go toward something positive instead of trying to go away from something negative._

3\. _Have them repeat what they heard back to you._ Try something like: “I just talked at you a lot. I truly want to make sure you understand. What did you get from our conversation so far?”

4\. _Thank them for sticking it out with you._ Step 3 can be awkward or annoying for the employee, but it is essential to make sure they heard what they needed to hear and are not adding unnecessary relations to your statements. As relational beings, we tend to do this. That being said, do step 3 and 4 despite it being awkward.

5\. _Get to the root of the problem. Ask them what they think their performance problem is._ Now is your turn to listen. Listen for solutions, actions, or skills they can improve upon. If something cannot be changed, ask questions about how or why and see if you can enable the employee to direct it to something that can be changed. For example, let’s say the employee says “ I have too much work to do”. You would want to ask questions about how they are doing their work and help them find more efficient ways to get their work done.

6\. _Solving the problem._ Summarize the problem by repeating what you heard back to them. This could lead to them elaborating on the problem, which is good. You want them to dig deep. After the problem has been stated clearly, ask what actions they can take or not take to solve the problem. Ask how they can change their environment to be more successful. Your goal is to lead them to the solution to their own problem and empower them to self manage. This is also the time to offer solutions or guidance if they are having difficulty coming up with solutions.

7\. _Thank them for their willingness and participation._ After a viable solution has been determined, tell them how much you appreciate them coming to the meeting and their willingness to grow. Reinforce the behavior you want to see!

One last thing to mention, these steps are by no means a rigid set of orders. They are meant to be fluid and provide guidance, but ultimately you must do what is best for you, your employee, and the organization. I hope you will consider leading with your values to help manage behaviors going forward. I know I will.

A special thanks to [Behavior Science in the 21st Century](https://bsci21.org/) for providing us with the content for this blog post.

---

[View on echobind.com](https://echobind.com/post/using-your-values-to-manage-people)

---

# This Month We Learned - August 2019

> Sep 06, 2019 | At Echobind, we strive to create a culture that fosters growth, full of people who want to grow.

_By Anne Tolmie · 2019-09-06_

### August Edition

At Echobind, we strive to create a culture that fosters growth, full of people who want to grow**.** Our aim is to constantly learn new things and share them with one another.

Our _This Month We Learned_ series is a monthly piece about some of the things we’ve learned as a team over the previous month.

The following are tidbits from the month of August that we learned and shared.

1. **We learned that you can _Accept All_ merge conflicts when doing a rebase in VS Code**

Ah, the infamous merge conflict. You cannot have a team of software engineers without a way to manage merge conflicts effectively.

A team member was working on a feature (we’ll call it `user-routes`) which was was branched off of another branch (`user-models`) that was still being worked on by someone else. When it came time to merge, he had to rebase his branch on top of that person’s branch (`user-models`) because they had made updates and finished that feature. That rebase lead to merge conflicts. Then, in order to merge his branch (`user-routes`) into the `master` branch, he had to do another rebase, but this time, on top of `master`. That ended up showing the same merge conflicts that he had just resolved previously. Using the `Accept All` commands for merge conflicts was the solution!

![Accepting both merge conflicts](https://res.cloudinary.com/echobind/image/upload/v1661874438/echobind_blog/go6s8krcq8hjssmmr6eo.png)

**2\. We learned about Language Server Protocols**

Language Server Protocols (LSP) is meant to set the tone for how servers and development tools communicate. The purpose is for reusability across multiple dev tools and languages. Some examples include features such as _auto-complete_, _find all_, and _go to definition_.

![Tweet about Language Server Protocols](https://res.cloudinary.com/echobind/image/upload/v1661873019/echobind_blog/pxazefxkej0q8vtcmyrh.png)

> _For more information on LSP:_

> <https://microsoft.github.io/language-server-protocol/>

> <https://github.com/neoclide/coc.nvim>

**3\. We learned a faster way to to re-install an iOS build**

Building a decently-sized iOS project to run on Simulator can take several minutes _on a good machine_. Having the ability to install the app from a previous local build when trying to debug issues around user settings, which get cleared when the device/app is uninstalled is tedious if you have to re-build just to re-install the same app again.

By having a command that allows for installation from that cached build, it saves an immense amount of time when this needs to be done 10–12 times to debug situations where the issue is only encountered after/near a fresh app install with all permissions yet to be prompted.

![Tweet about installing iOS](https://res.cloudinary.com/echobind/image/upload/v1661873005/echobind_blog/osz2so7uuvk5mmg3ezon.png)

**4\. We learned how to add proxy requests in Create React App**

Sometimes developers use the same port and host on both the front-end and the back-end during development. We learned you can set up a proxy server. Why would you want to do this? The benefit of using this method is when you make an API request during development, the server will know it is not a static asset and go to the proxy server as a backup.

```javascript
"proxy": "http://localhost:<PORT-GOES-HERE>"
```

![Tweet about React](https://res.cloudinary.com/echobind/image/upload/v1661874330/echobind_blog/ikqmiyz6opewzffw3n0v.png)

> _For more information on Proxy Requests:_

> <https://microsoft.github.io/language-server-protocol/>

---

[View on echobind.com](https://echobind.com/post/this-month-we-learned-august-2019)

---

# Spotlight Series : Mike Cavaliere

> Aug 27, 2019 | Go behind the scenes with Mike Cavaliere, one of our sublime team members through our Spotlight Series.

_By Echobind Team · 2019-08-27_

#### Go behind the scenes with our sublime team members through our _Spotlight Series._

## Mike Cavaliere

Mike Cavaliere is a Senior Engineering Strategist at Echobind. He’s been in the tech industry for as long as anyone can remember. He lives in Brooklyn, NY, travels here and there, and is a brain hacker on the side (he writes about it periodically at [ADHDTechies.com](https://adhdtechies.com/)).

### How did you get into coding?

I’ve been curious about technology since I received my first computer — a Commodore Vic20 — that was given to me as a gift when I was a kid. I fiddled with software as much as I could until I got to college and majored in Computer Science. At that time the major was theory-heavy, so I spent my own time picking up practical web development skills and using it them get freelance work (HTML was all the rage back then!). The rest is history.

### What do you love about what you do?

I love being able to build something that alleviates pain or frustration or saves time for people. I also enjoy using technology to connect people over long distances and solve a similar problem for them no matter where they’re located.

### What is your go-to resource when you are stuck on a problem or need guidance?

Google solves all!

### Who in the industry do you admire?

Software bootstrappers ([Rob Wailing](https://robwalling.com/), [Dane Maxwell](https://thefoundation.com/), [Amy Hoy](https://stackingthebricks.com/), others) are among my favorite people to learn from.

### What is your favorite podcast?

For software: [Indie Hackers](https://www.indiehackers.com/podcast).

### Are there any technologies or frameworks coming out that you are excited to use?

Next.js is great. I’m also excited to see Typescript becoming more widely supported, and I think that more innovations like TypeORM are going to evolve out of it as a result.

### What have you built that you are most proud of?

It’s hard to pick one thing!

I’m proud of lots of recent Node and React Native work I’ve done with [Echobind](https://echobind.com/), since it’s fairly cutting-edge and enjoyable to take part in.

I’m proud of the work I did at [Brainscape](https://www.brainscape.com/) back in the day since it was software that helped people learn, and since scaling a startup has its own set of interesting technical challenges.

I’m proud of the writing I’ve done on [ADHDTechies](https://adhdtechies.com/) since it’s given support and relief to people who have been frustrated with cognitive differences.

I’m proud of the mentorship I get to do at Echobind, since a little advice from someone more experienced like myself can go a long way in helping an engineer past their personal roadblocks.

### What advice do you have for someone who wants to get into coding?

Connect to what aspects of this industry you seem to enjoy for no reason. Try to build your career around them.

Learn your own strengths and weaknesses well; build the career around your strengths.

Learn, learn, learn.

### What do you enjoy doing that is not work related?

All things related to brain improvement, activity, nature, and enjoying time with my wife and adorable son.

### What is your morning routine like?

Shower, and get moving! Movement is the best thing for your brain. Also: coffee ☕️

---

[View on echobind.com](https://echobind.com/post/spotlight-series-mike-cavaliere)

---

# Becoming More Proficient on the Back-End (Part 4)

> Aug 23, 2019 | Becoming more proficient at any task takes work. Here is one team member's journey to become more proficient at back-end development.

_By Joe Previte · 2019-08-23_

In case you missed it, check out [Part 1](https://echobind.com/post/becoming-more-proficient-on-the-back-end-part-1), [Part 2](https://echobind.com/post/becoming-more-proficient-on-the-back-end-part-2), and [Part 3](https://echobind.com/post/becoming-more-proficient-on-the-back-end-part-3) where I talk about my Q3 goals and explain how this series works.

Now, here’s Part 4!

## Progress Update

Between Aug 12 and Aug 22, my goal was to complete the following:

**Week of Aug 12**
* Modern TS Course
* Logging — 15 mins
* Pro-production Configuration — 15 mins
* Front-End Application — 10 mins
* Deployment to AWS — 30 mins

**Week of Aug 22**
* Modern TS Course
* Testing a NestJS Application
* Plan out NestJS GraphQL app

❌ **Completed Weekly Goal(s)**

I did not complete my planned tasks for the Week of Aug 22\. However, I purposefully made the workload lighter for the week of Aug 26th to allow me to catch up.

I’m crossing my fingers no unexpected events occur next week and I’m able to get back on track.

🤔 **What did I do?**

The material from this update touched on things like:
* logging (NestJS has a built-in logger)
* lenvironment configuration (using a package called `config`)
* lconnecting the API to a Front-End application
* ldeployment to AWS

I had prior experience with most of these areas but it was still helpful to review them.

✅ **Milestone Achieved**

If you remember from [Part 1](https://echobind.com/post/becoming-more-proficient-on-the-back-end-part-1), my original Result Goal for the quarter was

> _Become more proficient in Back-End Development, measured by: shipping 3 features on the API/Back-End side_

After completing the first feature in the Part 3 update, I’m happy to share I’ve now completed this goal! 🎉

During this progress period, I spent a lot of time working on the back-end. This included the following features:
* 2 new entities
* 2 new mutations

![GitHub commit](https://res.cloudinary.com/echobind/image/upload/v1661873214/echobind_blog/kzm25p9d097ktprirzew.png)

The first entity I created

![GitHub commit](https://res.cloudinary.com/echobind/image/upload/v1661874250/echobind_blog/gac7j6scj7ir7uxbvclh.png)

The second entity I created

![GitHub commit](https://res.cloudinary.com/echobind/image/upload/v1661874617/echobind_blog/sme4snhcgupit3igqhxc.png)

The first mutation I created

![GitHub commit](https://res.cloudinary.com/echobind/image/upload/v1661874344/echobind_blog/eu9uzxcfvrnqe1kmyras.png)

The second mutation I created

It feels exciting for me because I achieved what I set out to achieve!

Although this NestJS course focused on a different framework than what we are using, I was able to apply a lot of the same concepts to client projects. I’m also thrilled on the opportunities I’ve had to do back-end work here at [Echobind](https://twitter.com/echobind/status/1162381617169608704?s=20).

I am slowly starting to feel more comfortable picking up back-end work without asking for help. I will continue to use what I’ve learned to ship more back-end features moving forward 😄

## 💡 Key Learnings

Some of these things were new and others were review but here’s what stuck out:

* _log levels_

I heard about this at my last job but never fully learned what they were because I never had to implement them into an app. Since NestJS comes with a [logger](https://docs.nestjs.com/techniques/logger), the logger has methods for each log level. For instance, you have the following levels and what they’re used for:

* log — general purpose logging of important information
* warning — unhandled issue that is NOT fatal or destructive
* error — unhandled issue that is fatal or destructive
* debug — useful information that can help debug the logic
* verbose — information providing insights. usually for operations
* `config` package

With config, you essentially do the same thing essentially, but with `yaml` files. An example might be like this

```javascript
development.yaml
```

```javascript
server:
	port: 3000
```

Then when you want to use that value, you import the package and get the port with `const PORT = config.get('server.port')`

And it knows what `yaml` file to use based on the environment set for `NODE_ENV`. Pretty cool, right?

## ⁉️ Challenges

The biggest challenge of these two weeks was deploying my app to AWS. The back-end side wasn’t too challenging but setting up SSL for the front-end was troublesome. I’m used to services like [ZEIT](https://zeit.co/) and [Netlify](https://www.netlify.com/), which handle all that for you. Either way, it put me outside my comfort zone and reminded me how thankful I am for services that handle SSL for me. Besides that, everything seemed to make sense.

That’s all for my update! Thanks for reading and catch ya next week! 👋

---

[View on echobind.com](https://echobind.com/post/becoming-more-proficient-on-the-back-end-part-4)

---

# Becoming More Proficient on the Back-End (Part 3)

> Aug 16, 2019 | Let's explore how one team member improved back-end development during their investment time.

_By Joe Previte · 2019-08-16_

In case you missed it, check out [Part 1](https://echobind.com/post/becoming-more-proficient-on-the-back-end-part-1) and [Part 2](https://echobind.com/post/becoming-more-proficient-on-the-back-end-part-2) where I talk about my Q3 goals and explain how this series works.

Now, here’s Part 3!

## Progress Update

During the week of July 29th, my goal was to complete the following:

* Modern TS Course
* Authentication — Setting up JWT/Passport — 1.5 hours
* Authorization — Task Ownership — 30 mins

❌ **Completed Weekly Goal**

Unfortunately, I did not put in the time to complete these sections in my course. I failed to hit my target because I only dedicated three hours that week towards these goals due to other obligations.

I was also on PTO the week of August 5th meaning I did not have time to make up for it.

Thus, I should be able to finish these sections this week. This means I will be a week behind on my schedule, but I plan to put in extra hours this weekend to make up for it.

🤔 **What did I do?**

The material I completed touches the surface on Authentication. We set up a module to handle signing up and logging in.

✅ **Milestone Achieved**

If you remember from [Part 1](https://echobind.com/post/becoming-more-proficient-on-the-back-end-part-1), my original Result Goal for the quarter was

> _Become more proficient in Back-End Development, measured by:: shipping 3 features on the API/Back-End side_

In this update, I made progress towards that by **shipping a feature on the API/Back-End.**

This means I’ve completed 1/3 — woohoo!🥳.

Fortunately, the current project has back-end work where I can practice what I’m learning. My teammates Matt and Jeff have provided guidance along the way. After multiple rounds of helpful PR feedback, my PR with a new Entity, new GraphQL types and resolvers, tests, and a Factory for creating the Entity in testing was merged in.

I’m celebrating this milestone because:

1. It’s progress towards my original Result Goal for Q3
2. It’s the first time I’ve shipped code to production related to API/back-end work

## 💡 Key Learnings

Some of these things were new and others were review but here’s what stuck out:

* _hashing passwords_

Hashing a password is when you encrypt a password using an algorithm. For example, let’s say my password is `superSecure1234`. We can take this password and pass it to a sha256 algorithm to encrypt it. In return, we receive the encrypted value.

```javascript
 Sha256(superSecure1234) = dbc78b60341efd7484630bdaa9cde2fc9ae5d782ee59b550e98b19f11aeafd86
 
```

As you can imagine, storing a user’s password as a hash is more secure than storing the original plaintext value.

* _salting passwords_

Salting is a password means you prefix the password with a hash value. Usually this is done after you hash the password. By doing this, we make the stored hash less vulnerable to attacks because it’s no longer only the hashed password.

An example might look like this:

```javascript
// Our password for logging in
const password = "superSecure1234"
// The hashedPassword after we use an algorithm like sha256
const hashedPassword = "dbc78b60341efd7484630bdaa9cde2fc9ae5d782ee59b550e98b19f11aeafd86"
// The salt we use to prefix the password before storing in the database
const salt = "$2b$57$//DXiKSFJG9p7G5k/3Jlx/t"
// What we store in the database
// storedPassword = salt + hashedPassword
const storedPassword = "$2b$57$//DXiKSFJG9p7G5k/3Jlx/tdbc78b60341efd7484630bdaa9cde2fc9ae5d782ee59b550e98b19f11aeafd86" 
```

Now there are two ways you can salt passwords.

1. Fixed salt
2. Dynamic salt

A **fixed salt** is one you generate and then use with _every password_. If a hacker were to look at your database, they would be able to guess the salt because it would be in every row. This is less secure.

A **dynamic salt** is one you generate _with each new user_. Every time a user/password is created, you generate a new salt. This way, each salt is unique and your database is more secure. And every time the user changes their password, you generate a new salt.

Using a dynamic salt is also more secure because in the event that a hacker did figure out the salt and had access to the database, they would only be able to decrypt that single user’s password. Fortunately, since every salt is dynamic, they wouldn’t be able to decrypt any other passwords.

# ⁉️ Challenges

Since I haven’t dived too deep into these lessons, there weren’t many challenges. I assume there may be as I progress through the Authentication and Authorization sections as those topics can get complicated.

That’s all for my update! Thanks for reading and catch ya next week! 👋

---

[View on echobind.com](https://echobind.com/post/becoming-more-proficient-on-the-back-end-part-3)

---

# Becoming More Proficient on the Back-End (Part 2)

> Aug 15, 2019 | Let's explore how to be more proficient at back-end development during investment time.

_By Joe Previte · 2019-08-15_

In case you missed it, check out [Part 1](https://echobind.com/post/becoming-more-proficient-on-the-back-end-part-1) where I talk about my Q3 goals and explain how this series works.

Now, here’s Part 2!

## Progress Update

During the week of July 21st, my goal was to complete the following:

* Modern TS Course
* Validation and Error Handling — 30 mins
* Data Persistence — PostgresSQL & TypeORM — 1 hour

✅ **Completed Goal**

I put in extra hours this weekend to get back on track for my plan so I completed both of the course sections.

🤔 **What did I do?**

I learned about validation, error handling and data persistence. I also integrated TypeORM and a PostgresSQL database.

## 💡 Key Learnings

Again, I have experience in these areas but here are some things that stuck out this time around:

* _data transfer objects (DTOs)_

A data transfer object is essentially the definition of a piece of data, which may be used across multiple layers of your application.

For instance, in the Nest.js application I’m building, there is a /tasks controller. On the controller, we have a POST endpoint on the root where you can create a task. The controller utilizes the service (where the logic actually lives). Since these both accept the same parameter when creating a task, this is perfect use case for a DTO. We create a create-task.dto.ts which looks like this:

```javascript
export class CreateTaskDto {
  title: string;
  description: string;
}
```

Then, import it wherever we need it within the application. Viola!

One comment the instructor made was to define it using ES6 Classes instead of a TypeScript interface, so the shape would be preserved after the TS complication to JS. This also makes code easier to maintain in the future.

* _Nest.js pipes_

In terms of validation, Nest.js provides classes called `ValidationPipes` and `ParseIntPipe`. I like to think of these pipes as **paths we send data on.** When we use this on handlers or methods within our controllers, Nest.js will "**pipe the data**" into these validation pipes and check them against the DTOs we provided. In this course, we use them in tandem with a package called `class-validator` which provides decorators for you're classes. Here's our updated `create-task.dto.ts` with the validators.

```javascript
import { IsNotEmpty } from 'class-validator';
export class CreateTaskDto {
  @IsNotEmpty()
  title: string;
  @IsNotEmpty()
  description: string;
}
```

As you can see we added the `IsNotEmpty` decorators to make sure `title` and `description` are never empty strings.

Then in our controller, we can tell Nest.js to use a Validation Pipe like so:

```javascript
 @Post()
  @UsePipes(ValidationPipe)
  createTask(@Body() createTaskDto: CreateTaskDto): Promise<Task> {
    return this.tasksService.createTask(createTaskDto);
  } 
```

We’re basically saying, “Hey Nest! on this `POST` handler, I want you to use the `ValidationPipe` and validate the `Body` of the request again the `CreateTaskDto`. Sound good? Thanks!"

The `ParseIntPipe` is used to convert a `string` to a `number` so pipes can also be used for data transformation.

## ⁉️ Challenges

Below are some things that were difficult for me and that I’m still wrapping my head around.

* _repositories_

After adding TypeORM and PostgresSQL, we added a “repository” layer. The documentation states:

> _Repository is supposed to work with your entity objects. Find entities, insert, update, delete, etc._

As outline in the docs, the next step is to create a `Task` entity (which essentially is a table in the database for `tasks`) and then create a `task.repository.ts` file. In this file, two methods were added: `getTasks` and `createTask`. I believe the reason behind this is because the methods involved more complex logic related to using the `queryBuilder` provided by TypeORM and the purpose was to separate logic.

That’s all for my update! Thanks for reading and catch ya next week! 👋

---

[View on echobind.com](https://echobind.com/post/becoming-more-proficient-on-the-back-end-part-2)

---

# Becoming More Proficient on the Back-End (Part 1)

> Jul 29, 2019 | Here at Echobind, one of the awesome benefits every employee has is 8 hours per week of “Investment Time.”

_By Joe Previte · 2019-07-29_

Here at Echobind, one of the awesome benefits every employee has is 8 hours per week of “Investment Time.” As you can guess, this time allocated to invest in yourself however you see fit. We try our best to use them to level up our skills or work on side projects that may benefit you or the company in some way.

## Q3 — Result Goal

For this quarter, I set the following goal:

> _Become more proficient in Back-End Development, measured by : shipping 3 features on the API/Back-End side_

At my previous job, I spent all my time working on the front-end. However here at Echobind, we have the opportunity to work the full-stack so it’s given me the ability to use Node, TypeScript, GraphQL, Postgres and TypeORM as part of the back-end stack.

My intention behind setting this goal is to fully invest into that side of the stack and level up as a developer.

## Q3 — Progress Goals

We take our “Result Goal” and break it down into smaller, measurable goals. For mine, that looks like the following:

* Integrate Node/TS into Investment Time
* [Complete Modern TypeScript Back-End Development Course](https://www.udemy.com/nestjs-zero-to-hero/)
* [Complete SQL Fundamentals](https://egghead.io/courses/sql-fundamentals)
* Document my learnings

A few friends recommended the TypeScript back-end course on Udemy. I chose it because the stack is very similar to the current stack we’re working with (Node, TypeScript, TypeORM, Postgres). Although it uses Nest.js and we’re using Apollo Server/GraphQL, I plan to try building a GraphQL API with Nest after completion of my courses.

The SQL Fundamentals course is meant to help me with Postgres and to give me a solid SQL foundation.

The last is to document my learnings, which I intend on doing once a week in this series of blog posts here on the Echobind blog.

Each post will have the following format:

* Progress Update — what have I accomplished?
* Key Learnings — quick recap of major concepts and terms I’ve learned during that week
* Challenges — things that were difficult or that I had to spend more time learning

And with that, I’ll transition to my first update!

## Progress Update

During the week of July 15th, my goal was to complete the following:

* Modern TS Course — REST API — Task Management Application (CRUD) — 2 hours

❌ **Completed Goal**

Due to the nature of our current project, I did not have as much time as I had anticipated to dedicate to investment time. I had some features I wanted to finish up so I spent less investment time taking the course.

🤔 **What did I do?**

Even though I didn’t finish that section of the course, I finished 10/21 modules so almost 50%. My plan is to finish up the rest this week and continue moving along.

## 💡 Key Learnings

Even though I’ve built REST APIs before, Nest.js introduced a lot of new concepts to me, including the following:

* _controllers_

To help myself understand this, I thought of the following example: let’s say you have a team of people in an office. Imagine one person is the Security Guard and the other person is the Office Manager. The Security Guard chooses who comes in and goes out of the office. If you don’t have the proper credentials, you are not allowed in. This person’s main responsibility is “authorization” (i.e. an AuthController). The Office Manager is in charge of tasks. So if it’s related to creating, reading, updating or deleting tasks, s/he is in control.

* _services_

Admittedly, I am still a bit confused on this one, but from my understanding, the service actually does the thing. So thinking back to our example, maybe the Office Manager utilizes a service (let’s say TaskRabbit) that goes and gets the tasks for them when they want to read all the tasks. It’s important to remember the Controller is leveraging the Service in order to accomplish this. The Service is where the logic is done, but the Controller has access to that Service, meaning it can utilize it. I hope that makes sense.

* _dependency injection_

This is another concept I am still exploring, but from what I learned, it’s injecting dependencies into something else. Let’s say I have a class/module that relies on X dependency. I can use _dependency injection_ to provide that class/module with the necessary dependencies.For now this is the extent of my knowledge, but I hope to provide further examples down the road.

## ❗️ Challenges

Some things that were difficult for me and that I’m still wrapping my head around.

* _providers_

After going 50% through the REST API section, I still don’t quite understand what provider is in the terms of Nest.js. One of my awesome coworkers, Mike, explained that in general, providers are used for dependency injection so hopefully once I read more, I’ll be able to see how the two work without someone else explaining it to me.

* _decorators_

Honestly, I don’t think I knew these existed in JavaScript. Actually, at the time of this writing, they are at [Stage 2](https://github.com/tc39/proposals#stage-2) in the ECMAScript Proposals. Technically, I guess they’re can only be used if you have a transpiler like Babel or if you’re using TypeScript. Either way, I am still learning.

From the [basic research](https://robdodson.me/javascript-design-patterns-decorator/) I did, it’s described as “a design pattern when you want to dynamically add properties to an object/class”.

That’s all for my update! Thanks for reading and catch ya next week! 👋

---

[View on echobind.com](https://echobind.com/post/becoming-more-proficient-on-the-back-end-part-1)

---

# Supporting the next generation of developers through volunteering

> May 16, 2019 | Support the next generation of developers through volunteering.

_By JC Hiatt · 2019-05-16_

Mississippi Coding Academies is a non-profit that operates tuition-free, 11-month courses on full-stack web development to recent high school graduates. Yesterday, it just concluded its second cohort!

I’ve been volunteering there — helping out with student evaluations and offering positioning/growth advice for the past couple of years. In the time I’ve spent there, I’ve come to see just how important it is that we support the next generation of developers. Most of the students I meet there have no technical background, but they are very eager to learn. The academy has done a good job creating a culture where learning new things and being open to changing your ideas is standard.

Mentorship has hands-down been my #1 mechanism of growth as an engineer, and I never want to forget how impactful it can be to offer up my time to help the next wave of developers.

At Echobind, we strongly value mentorship. We believe constantly learning from others and paying it forward by teaching others is the best way to both grow as an engineer and help shape the tech community in a positive way.

It’s an expected part of your role as an engineer here, and it must be something you regularly practice in order to level up in the company. But we also value mentorship externally, through volunteering at places like Mississippi Coding Academies.

## A Challenge

We have a challenge for you. If you’re an individual, find one person who wants to know about something you know about. Offer to teach them for free.

If you’re a company, find ways to create a culture of mentorship and volunteering in your organization. This can be in the form of pair programming, mock interviews, volunteering at bootcamps — there’s many ways to give back to the community!

We’re all standing on the shoulders of giants — don’t pretend for one second that everything you’ve learned and built has just been because of your work alone.

Thanks again to my team for sponsoring my time yesterday! I love getting to serve these students in my community.

---

[View on echobind.com](https://echobind.com/post/supporting-the-next-generation-of-developers-through-volunteering)

---

# Defining Scope and Determining Necessary Features

> Apr 16, 2019 | As a project manager, you have to determine essential features while still making the client happy, staying within budget, and meeting deadlines. Here's how to determine scope and necessary features.

_By Ashley Nelms · 2019-04-16_

When I first joined Echobind, I was introduced to a greenfield project which meant we were building an application from the ground up. This provided a lot of freedom such as choosing the most optimal technology and designing how the app will look.

Building this from the ground up meant there was an abundance of creative ideas being thrown around each of which was deemed as essential for launch. These ideas were going beyond the basic function of the product. With the deadline on my calendar, I knew all the items on this long list of requests wasn’t going to make it in.

As the project manager how was I to determine essential features while still making the client happy, staying within budget, and meeting deadlines?

## Trimming the Fat

In software, there is something referred to as **Minimum Viable Product** (MVP). This is the first working version of a product and should have a sufficient amount of core features to validate an idea but no more. This was the key to building something that would still make the client happy and not go over budget.

Part of my job was to determine what would be part of the MVP. This meant collaborating with all stakeholders to ensure that we were building features that were relevant to validating the product.

The definition of an MVP is fairly easy to understand theoretically, but much more difficult to practice. Our CEO, Michael Yared gave me excellent advice when determining critical features for product validation:

* Is it absolutely critical? Yes or No?
* Can we simplify it? Yes or No?

Using those questions as a base I built a decision tree to help me answer my question around new features:

**Is this feature necessary for this phase of work?**

![ER diagram](https://res.cloudinary.com/echobind/image/upload/v1661874308/echobind_blog/pxfmwnro0icyc7rgx6c9.png)

Referring to this tree has been helpful in determining whether a feature can be revisited in the future or if we have to absolutely build it now. If we’re building an app whose primary feature is to allow users to chat with each other then a feature for user profiles showing birthdays can be determined as a “nice to have” for the future.

If a feature is determined to be necessary and is large enough to begin affecting the budget and meeting the deadline I’ll reanalyze other requested features using this tree. We want to be **ruthless** and trim down to the core necessities for MVP.

## Wait, Technical Debt?!

In the tree, I mention technical debt which is a concept that Robert Beene ensures we keep in mind for every project whether that be greenfield or not.

Before saying that a feature can be simplified it’s important to consider the ramifications of making that decision. Will simplifying it now cause us to work harder later? With three primary factors to consider for projects (budget, quality, and time) we may be saving on time now but pay in budget later to fix this technical debt.

## Not Mushroom For Technical Debt

![Mushrooms](https://res.cloudinary.com/echobind/image/upload/v1661872954/echobind_blog/yvappamy4ak53brlsyrg.jpg)

I want to talk about technical debt using a real-world scenario I encountered recently.

I’ve gotten into the hobby of growing gourmet mushrooms. As a side project, I wanted to build an app that would allow me to easily search all types of mushrooms and view certain information about them such as health benefits or if it’s even safe to eat.

I knew for my MVP build I wanted to have the mushroom name and its potential health benefits. Mushrooms can have more than one health benefit so my initial thought was to have an array to hold these. It’s simple to do and doesn’t take much time. Great! When I search for a mushroom I’ll be able to see its health benefits.

Well now I have a cold and I’ve decided to make a soup containing mushrooms. I know reishi mushrooms have immune-boosting benefits but unfortunately, I’m not growing those right now and the store is all out! To see what other mushrooms have the same benefit I want to filter for the mushrooms with that specific benefit. Given that I used an array to store all the benefits for the mushrooms each one has to be touched to see if their array contains the immune-boosting benefit.

If there’s only a handful of mushrooms in the database this may not seem like an issue. But what about if there are hundreds? If I’m trying to search for those with immune-boosting benefits, I now have to touch hundreds of individual mushrooms and check their arrays. This is a significant problem when it comes to efficiency, only I realized the issue too late after hundreds of mushrooms have been added to the database.

Now I have technical debt. I have to go back and implement a more efficient solution which costs extra time and runs the risk of losing data which would be even more time lost.

To improve this let’s look at what I know:

* A mushroom can have many types of health benefits
* A health benefit can belong to more than one type of mushroom

Have you guessed where this is going yet? That’s right, a many-to-many relationship! Using this relationship to our advantage we’ll now have a mushroom table, a health benefit table, and a join table. This join table will hold the association between the mushrooms and the health benefits.

With this new structure, I can ask the join table to show me all the mushrooms where the health benefit is that of immune-boosting without having to touch every single mushroom in the database. This makes the processing time for filtering those results much more efficient.

Using an array simplified the work and saved time at that moment but I didn’t consider the technical debt that it was causing.

## Be Fearless

I said it before and I’ll say it again: **be ruthless**! As the project manager, it’s our job to guide the client to success which can require tough calls that you can’t be afraid to make.

You can narrow down the product to its core MVP features and still end up in a situation where the deadline doesn’t allow for the given work. It could be a dilemma of deciding between two features and the client is torn on which way to go.

Help guide them to the final choice using the decision tree. They may decide to cut a feature entirely or decide on trying to implement a simpler version.

Just remember, before you simplify a feature consider the technical debt! If it can’t be simplified, assure the client that waiting to implement it in the future may very well be the best decision they can make. They may even appreciate this attention to detail and feel you have their best interest at heart.

Sometimes all that the client needs is the reassurance that a successful product can be still be made even if we have to make some cuts here and there.

Until next time!

---

[View on echobind.com](https://echobind.com/post/defining-scope-and-determining-necessary-features)

---

# How to Write Functional Tests in React (Part 1)

> Apr 12, 2019 | This is the first in a series of articles that will help you build a solid foundation for testing React components.

_By Jeffrey Zhen · 2019-04-12_

This is the first in a series of articles that will help you build a solid foundation for testing React components.

At the beginning of the year, I set a goal to improve my code quality by focusing more on testing. I tried a handful of libraries and methods like [Enzyme](https://github.com/airbnb/enzyme), [react-test-render](https://github.com/facebook/react/tree/master/packages/react-test-renderer), and [snapshot testing](https://jestjs.io/docs/en/snapshot-testing). I eventually landed on [react-testing-library](https://github.com/kentcdodds/react-testing-library).

## What is react-testing-library?

[**react-testing-library**](https://github.com/kentcdodds/react-testing-library) (RTL) is a testing framework created by [Kent C. Dodds](https://kentcdodds.com/) with the guiding principle of

> The more your tests resemble the way your software is used, the more confidence they can give you.

## How is RTL different than other frameworks like Enzyme?

RTL structures your test in a way that doesn’t include the implementation details of your components. As such, when your components are refactored in the future (to change implementation but not functionality), your tests do not break and your time isn’t spent fixing it.

Unlike Enzyme, RTL will test DOM nodes instead of component instances if said component is related to rendering. If you’d like an in-depth analysis, Kent C. Dodds has a [comprehensive article](https://kentcdodds.com/blog/why-i-never-use-shallow-rendering) about his dislikes with shallow rendering in Enzyme.

The TL;DR is that RTL does not include a lot of the utilities that Enzyme has (such as `shallow` and `instance`) because they

> are things which users of your component cannot do, so your tests shouldn’t do them either.

## How can I use RTL effectively?

We’ll create some basic tests for asserting form inputs. Here’s what our component will look like:

## Our Component

![React code](https://res.cloudinary.com/echobind/image/upload/v1661874106/echobind_blog/jfroegteahcxcr5mhg1m.jpg)

MyInput.js (but it’s actually a form 🤫)

* On the initial creation of this functional component, we assign `inputIsPristine = true` and `number = 0` with the `useState` hook
* When the user types in the input we fire the `handleChange` function and set `inputIsPristine = false` and `number` to the user’s input
* The `error-msg` is shown with `inputHasError` when the input is no longer pristine (user types something) nor valid (less than 1)
* The `submit-btn` is disabled when the input is not valid (less than 1)
* `data-testid` is an attribute used by RTL to find elements

_**Note:** I call the component MyInput and I realize it isn’t technically an input since it’s wrapped in a form, but I did it so I could have an easy way to use the submit button with the input._

## Our Test File

Assuming you already have [**jest**](https://github.com/facebook/jest) installed in your app, we will also be installing a few other libraries. Here’s what the top of your test file will look like:

![React import code](https://res.cloudinary.com/echobind/image/upload/v1661873926/echobind_blog/zzmbvurvam6rbjn2rbvz.jpg)

MyInput.test.js

* We will be getting a few extra and helpful assertions from `jest-dom/extend-expect`
* Because `react-testing-library` mounts our components to `document.body`, we will be using its `lceanup-after-each` which will unmount and clean up our DOM after each `est`
* I will go into detail about `react-testing-library`'s `render` and `fireEvent` functions later on

## Our Test Utilities

### render

The `render` method is the bread and butter of RTL. In this following example, I’m showing what RTL’s `render` method is doing under the hood. My next example (getByLabelText) will demonstrate how to use `render` in our tests.

![JavaScript function](https://res.cloudinary.com/echobind/image/upload/v1661873934/echobind_blog/cqc2qcqfiankyrigl56a.jpg)

What RTL’s render method sort of looks like

* The component `(ui)` that’s passed to it gets rendered on a `container`
* RTL’s utility methods (ie. `getByLabelText`, etc) are all extracted and assigned to `queries`
* These methods are then spread on the object that is returned so that we can destructure out the utilities that we need

### getByLabelText

The `getByLabelText` utility works well for getting an `input` element and its associated `label`.

![RTL test code example](https://res.cloudinary.com/echobind/image/upload/v1661873941/echobind_blog/keru2cu6p7xhvs2jxgzy.png)

* `react-testing-library`'s `render` function mounts our component to the DOM and exposes a handful of utility methods (`getByLabelText` in this case)
* We pass the text of the label `'Number:’` to `getByLabelText` and it returns the `input` that was associated with the `label`
* We then make an assertion on the `input` that it has an attribute `type='number'`

_**Note:** `getByLabelText` works here because of the relationship we created between the `label` and `input` in `MyInput.js`. **The `htmlFor` in the `label` element matches the `id` in the `input` element.**_

If we didn’t create the association between `label` and `input` or made a typo in the `htmlFor` like calling it `inpoot-number`, RTL would throw us an error:

![HTML code](https://res.cloudinary.com/echobind/image/upload/v1661873948/echobind_blog/hx30motlrxj2dyiw1oti.png)

RTL’s enforcement of this relationship is great for catching typos and keeping accessibility high!

### getByTestId

This is a method I really like about RTL. Remember that `data-testid` attribute we added to `button`? The `getByTestId` utility is what we’ll use to target it.

![RTL test method](https://res.cloudinary.com/echobind/image/upload/v1661873581/echobind_blog/brboh4xvkcorpumexbla.png)

* We use RTL’s `getByTestId` method to find an element with a `data-testid="submit-btn"`
* Because of `defaultProps` where we set `-->min = 1-->`, and our initial state where we set `number = 0` — we expect our button to be disabled since our input is not valid

Typically, you’ll want to use `getByTestId` when targeting a specific element — it’s great for looking up inconspicuous `divs` or other elements in weird places.

### getByText

This is a pretty general method that looks for any matching text that’s passed as an argument.

![RTL test method](https://res.cloudinary.com/echobind/image/upload/v1661873588/echobind_blog/zsyribcqq77h1bulwx6l.png)

This is the same test we did with `getByTestId` except here we use `getByText` and pass it the button text “Submit!”

I tend to prefer using `getByTestId` & `data-testid` attributes over `getByText`, as the former method reduces the scope and allows me to pinpoint the exact element I’m asserting.

### fireEvent

The `fireEvent` method is used to manipulate the DOM based on some sort of event. The list of events spans from `change` to `wheel`(the full list can be viewed [here](https://github.com/testing-library/dom-testing-library/blob/main/src/events.js)).

![RTL test method](https://res.cloudinary.com/echobind/image/upload/v1661872767/echobind_blog/gaepe1txbhd7ti0rqjcw.png)

* First, we assign `input` and `button` variables to the elements that we found using the methods we used earlier
* Next, we call `fireEvent.change` and pass it an object that is similar to the one we used in our `handleChange` function in `MyInput.js`

![React handleChange function](https://res.cloudinary.com/echobind/image/upload/v1661872774/echobind_blog/jfkhoo8spsmtayba4ajh.png)

handleChange in MyInput.js

* In our `handleChange` function we set the number state with `event.target.value`, so in the same fashion with our test we pass it the object `{ target: { value: 5 } }`
* Finally, we expect that the button is enabled because any number greater than or equal to our `min` (which is set as 1 from our `defaultProps`) should be a valid input, thus enabling the button

### rerender & queryByTestId

_This is a two-parter to show how you can test for something to_ **_NOT_** _be in the DOM._

For `rerender`, I typically use it to assert the outcome of a component after updating its props.

`queryByTestId` is very similar to `getByTestId`. The difference between the two is that `getByTestId` will throw an error when it can’t find the element and `queryByTestId` will return `null`. All the other `getBy`.. methods have similar `queryBy`.. methods.

![RTL test code](https://res.cloudinary.com/echobind/image/upload/v1661873883/echobind_blog/nlngmelbcj8psxkw8szw.png)

* Just like before, we assign the variable `input` to the element associated with the label text “Number:”
* We call `fireEvent.change` and change the input to `-5`
* The input’s value is now less than our `min (1)` which is defined in our `defaultProps`, so we expect the `error-msg` to be present
* Now we call `rerender` on our `MyInput` component and update the `min` prop to `-10`
* Now that our input’s value `-5`, is greater than our updated `min` `-10`, we expect the `error-msg` to not exist (`toBeNull`)

### Bonus: debug

RTL’s `debug` method will log out the current structure of the DOM where ever you place it. Very useful for peeking at the state of your DOM during different parts of your tests.

![RTL test code using debug method](https://res.cloudinary.com/echobind/image/upload/v1661873465/echobind_blog/hw9m4uo52otqjmitgfwa.png)

* Deconstruct `debug` out of the `render` method
* Here we place it before and after we call `fireEvent.change`
* Run our test and we’ll see this in our console:

![HTML code](https://res.cloudinary.com/echobind/image/upload/v1661873120/echobind_blog/ssbc4xlk6jlef4pg384p.png)

Two debugs, two outputs!

* In the first output, before we call `fireEvent.change` we see our input’s `value = "0"`
* In the second output, after we call `fireEvent.change` we see that our input’s `value = "-5"` and there’s also the inclusion of an `error-msg div` now

## Conclusion

Hopefully, this walkthrough gave you a good idea on how you can implement RTL in your next (or even current) project. It’s a great way to test your components in a way that mimics your users’ interactions.

All of the examples can be found on [**github**](https://github.com/jeffreyzhen/rtl-blog-1-demo)**,** or you can try it out instantly on [**repl.it**](https://repl.it/repls/DramaticFoolishNumerators?language=reactjs&folderId=)**.**

If you have any other testing tips, don’t be afraid to send them my way! I just started my testing journey and would love to learn more about how to make my application more bulletproof. Also, be sure to stay tuned for the next part of this series where I will dive even deeper into testing! 🐐

---

[View on echobind.com](https://echobind.com/post/how-to-write-functional-tests-in-react-part-1)

---

# Software Development: A Woodworkers Perspective (Final)

> Apr 01, 2019 | You finished a project — congrats!What’s next?Do it all again!Only this time, you carry every experience from this project with you.

_By Matt Thompson · 2019-04-01_

## “Make it a habit!”

* [Intro](https://echobind.com/post/software-development-a-woodworkers-perspective)
* [Plan and Prep](https://echobind.com/post/software-development-a-woodworkers-perspective-part-1)
* [Use your resources](https://echobind.com/post/software-development-a-woodworkers-perspective-part-2)
* [Learn from every experience good and bad](https://echobind.com/post/software-development-a-woodworkers-perspective-part-3)
* [Don’t be a hero](https://echobind.com/post/software-development-a-woodworkers-perspective-part-4)
* Finally, make it all a habit.

## Make it a Habit

You finished a project — congrats!

What’s next?

Do it all again!  
Only this time, you carry every experience from this project with you.

I know I need to plan better…  
— _Is there a whiteboard around here?_

I know I may need to find better tools and resources…  
— _I’ll make the list._

I know mistakes are going to happen…  
— _But I can react differently this time_ 
_— I can continue to grow and learn._

I know I can’t always do it all…  
_— I’ll learn my limits_ 
_— I’ll ask for help_

I know if I keep building on my mistakes…  
— _I’ll continue to grow._  
_— I’ll be able to help others grow_

Regardless of your profession. Woodworking, Development, or other, as we continue to push forward, to make mistakes and learn, I hope we can do so together.

Do Good. Then do good work.

Until next time,  
Cheers!

![](https://res.cloudinary.com/echobind/image/upload/v1661873293/echobind_blog/zxxtqxxr1g0m2ngja14d.png)

---

[View on echobind.com](https://echobind.com/post/software-development-a-woodworkers-perspective-final)

---

# Software Development: A Woodworkers Perspective (Part 4)

> Mar 15, 2019 | Don’t get so caught up in your work that you lose a piece of yourself… literally

_By Matt Thompson · 2019-03-15_

## “Don’t Be A Hero”

* [Part 3: Every Cut Counts](https://echobind.com/post/software-development-a-woodworkers-perspective-part-3)

In other words — Don’t be such a stubborn, arrogant fool that you lose a piece of yourself in the process. Over the years my pride has definitely pushed me to some extremes I’m not proud to admit. As a craftsman, you know better. Wear the gloves, the eye protection, don’t have your hand so close to the blade… Safety first.

However, there are times you just need to “Make something work”. I don’t always have the tools I need… but “Hey! If I rig this tool, maybe I can…” Innovation is a great tool, one that needs to be utilized but your pride and ego can easily push it over the edge sending you to the nearest urgent care or worse. So far I’ve been lucky… but I have witnessed others. Now they set a constant reminder.

“Don’t get so caught up in your work that you lose a piece of yourself… literally”

## The Crossover

Sure, you probably won’t physically lose a piece of yourself typing away at a keyboard, but there’s a lot to learn here. The mental games can be a harder battle than physically getting hurt. The frustrations, stress, anger, depression, anxiety… they are real. It’s easy to say _“I’m going to make this work”_ but how many hours do you spend trying to force it to your will? How long do you wait before asking for help? Do you? Deadlines are near, your team members have their own issues to deal with. It’s my responsibility, not theirs. What do you do?

Every personality is different, but the message is the same.

**Don’t lose yourself in the process.**

My personality is a “power through — all or nothing” type. A couple of years ago, the number of projects, goals, and family responsibilities kept stacking. I felt like I had something to prove and even more to prove to myself. In my mind — it was part of the job. For work it was fourth quarter, late in the year, if I could just make it to the holidays I’ll be able to breathe and feel incredibly accomplished for it. So I let the chip on my shoulder hold all the stress and anxiety from the year and kept pushing forward day and night. Honestly, I knew I wasn’t myself but I was meeting my goals and that’s what mattered. I lost track of family, I lost track of what day of the week it was, I became my work. Then one night I woke up to my wife shaking me, when I came to I realized I was on the floor in the hallway. She had a bloody rag and I can still remember the look of concern on her face. I remember feeling something funny, a missing tooth. I blacked out. I have no memory of those few hours. After a night in the ER and a few stitches later… I had to take a look in the mirror. The black eye, the bruises, all of those things eventually heal. What hurt the most, was having to admit that I did it all to myself.

I pushed too hard. I let my pride get in the way. There are limits.

You can’t invest 110% in all areas of your life.  
At least not at the same time. It’s a balance.

> **Don’t be a hero — It hurts.**

---

[View on echobind.com](https://echobind.com/post/software-development-a-woodworkers-perspective-part-4)

---

# Software Development: A Woodworkers Perspective (Part 3)

> Mar 01, 2019 | Every cut counts in both woodworking and software engineering. Time to square up those corners.

_By Matt Thompson · 2019-03-01_

## “Every Cut Counts”

* [Part 2: Use Your Resources](https://echobind.com/post/software-development-a-woodworkers-perspective-part-2)

## Square Up

You’ve mapped out the project. Gotten all the boards roughed to shape. A few cuts here and there, a little glue, and we can call this project complete…

Don’t get ahead of yourself.

Wood moves. Here in Kentucky, the humidity and temperature dramatically change… daily. Even after surfacing the lumber it’s always a good idea to double check with a square. Unless that is, you are after a wobbly, half-jointed, paperweight. Square those pieces up. You may have spent time with each section. You may have paid extra attention to how every corner of each piece looks — But put them next to one another and suddenly what looked dead square is now nothing but a rhombus-shaped coaster. There’s no unseeing it. If you had kept building the finished piece would have been twisted, leaning, and barely functional. When working with each piece keep the others in mind. Remember how they interact and don’t lose sight of the end goal.

![](https://res.cloudinary.com/echobind/image/upload/v1661874625/echobind_blog/z1ehaaf0i2ncojjeqrss.jpg)

![](https://res.cloudinary.com/echobind/image/upload/v1661874632/echobind_blog/tgjxhuujhm2dwm5uzhfh.jpg)

![](https://res.cloudinary.com/echobind/image/upload/v1661874006/echobind_blog/ngzyytgldblxknyqkmzx.jpg)

Square Up!

## Every Cut Counts

With every cut for this box, sawdust was made. Every cut I swept the sawdust into a container and left it sitting at the end of my workbench for one reason — mistakes happen.

Along the way, mistakes _will_ happen. Don’t ignore them… Learn from them. In the photos below you’ll see a few examples. I didn’t quite saw to my line. When marking a line with my square… it moved. Even when cutting “exactly” to the line there were a few gaps when piecing the boards together. It’s rough, you spend a lot of time trying to be accurate, planning to make the perfect piece, but you’re human. At this point don’t freak out. Examine what went wrong for next time. How can you improve? This is the teaching stage. It’s also the stage where most give up. Keep your chin up, keep pushing forward. As a woodworker, that collection of sawdust at the end of the bench — experience. Mistakes will always happen. Patch it the best you can, and move on. In the end.. they’ll never notice. Every cut counts, good and bad, You will learn from both.

![](https://res.cloudinary.com/echobind/image/upload/v1661873271/echobind_blog/bcwgygfvta1b7desa1nn.jpg)

![](https://res.cloudinary.com/echobind/image/upload/v1661873487/echobind_blog/bpfydpti2b991hheqamt.jpg)

![](https://res.cloudinary.com/echobind/image/upload/v1661874754/echobind_blog/lk0pk6agmfav9gg6mdl2.jpg)

Mistakes Happen…

## The Crossover

As a developer, don’t get ahead of yourself. In the same way wood moves, Code can grow and change over time. That feature you built locally, that’s perfect, now has to be merged in with the rest of the beast. Remember not to lose sight of the end goal. At some point, you’ve probably heard the expression _“can’t see the forest for the trees”_. Don’t build rhombus-shaped code. If it looks twisted and forced it probably is. Find way’s to keep yourself and code in line with those around you. The thought should not be “This is how my feature works” but “This is how my feature can be used by others”. For the solo developers out there your future self thanks you.

…and remember mistakes happen… Learn from them.

Every keystroke, every thought, every countless frustrating hour you spent trying to make something work. It matters. **You matter.** Keep your head up. Keep engaged. Use your resources and ask for help if you need, but don’t get lost in the void. Don’t become so focused on the one line of code that you forget the big picture. Mistakes will always happen, bugs will always appear, patch them the best you can and learn from the experience. Keep yourself motivated. Five years from now, that bug won’t matter, but how you learn to react to them will.

---

[View on echobind.com](https://echobind.com/post/software-development-a-woodworkers-perspective-part-3)

---

# Software Development: A Woodworkers Perspective (Part 2)

> Feb 15, 2019 | There are over 1000 different ways to make the same box. Use your resources, do your best, the rest will come with time.

_By Matt Thompson · 2019-02-15_

## “Use Your Resources”

* [Part 1: Planning and Preparation](https://echobind.com/post/software-development-a-woodworkers-perspective-part-1)

## Use your resources

There are over 1000 different ways to make the same box. How you approach the work depends on a lot of variables but the two most noticeable — your skill set and your tools. You may own the finest chisels, but if you lack the knowledge on how to sharpen them it means nothing. Likewise, you may have the knowledge of an old foreman, but if all you own is a hammer… you’re buying some nails. It’s best to understand where you are, and what you’re capable of. Take the challenge and push yourself, keep learning, but don’t reach for something unobtainable. Use your resources, do your best, the rest will come with time.

When building this box I needed to have a slot for the back and front panels to slide into. There are multiple ways to do this. Adjust the blade of the table saw, use an electric router, a router plane, and if nothing else slowly chisel a line until it works. Obviously, the first two options are typically preferred, set the blade and rip the board — It takes almost no time. The same goes for the box joints. A little setup with a router and **\*boom\*** done.

So, what happens when these resources aren’t available? You can’t just call it quits. There’s work to be done and again we aim to always push forward. So you have two options, work with what you have… or track down the resources. When funding is low, you work with what ya got. In my case, it was a router plane and coping saw. It took some time, but in the end, I had what I needed. Using different methods caused me to slow down and focus which was not a bad thing. After a while, there seemed to be a soothing repetitiveness to the work. Make a few cuts, lower the blade, repeat. It gave me time to think, time to actually enjoy what I was doing. When using alternative methods don’t get frustrated. Learn from them. Efficiency doesn’t come from a resource. It comes from practice. A faster tool doesn’t necessarily mean a faster build.

![](https://res.cloudinary.com/echobind/image/upload/v1661873516/echobind_blog/hfkizaclplog899bdsnc.jpg)

![](https://res.cloudinary.com/echobind/image/upload/v1661873350/echobind_blog/tv7cmcgz5pgncpjwcnh8.jpg)

![](https://res.cloudinary.com/echobind/image/upload/v1661873444/echobind_blog/gl8sxjg4iejw2cviy9c3.jpg)

## The Crossover

When working on a project it’s best to understand where you are, and what you’re capable of. When starting out, know your limits.

* What tools and skill sets do you have readily available?
* How skilled are you with these tools?
* How long will it take to learn a new skill?
* How many questions can you ask before driving co-workers crazy?

Understand what you’re working with and be honest. You may not have the most efficient methods, you may not have access to all the tools, but if you’ve made it this far, you CAN get the job done. In time you’ll end up with the same results. Don’t get frustrated. Efficiency doesn’t come from a fancy resource. It comes from practice.

---

[View on echobind.com](https://echobind.com/post/software-development-a-woodworkers-perspective-part-2)

---

# A Common Conditional Rendering Bug in React Native

> Jan 22, 2019 | Along the way we've encountered numerous little quirks to the development process that you get used to. These include some best practices, as well as “no better option” practices, but there’s one matter we consistently find ourselves commenting on in pull requests that we’d like to share with you.

_By Ryan Atkinson · 2019-01-22_

I’ve been developing with react native for a couple of years now. Along the way I’ve encountered numerous little quirks to the development process that you get used to. These include some best practices, as well as “no better option” practices, but there’s one matter I consistently find myself commenting on in pull requests that I’d like to share with you.

![React code in Visual Studio Code](https://res.cloudinary.com/echobind/image/upload/v1661874589/echobind_blog/hauxh8pjs9arfrv8t1z5.png)

BAD: Conditionally rendering text with the && operator.

In the snippet above, we have a  component conditionally rendering based on the “truthiness” of its string value contents, `potentialTextValue`. This is a common React pattern and is perfectly fine. The problem however, is that in React Native, rendering a string, even an empty one, outside of a component is bad news. If you’re familiar with the `&&` operator, then you know when `potentialTextValue === ''`, the expression in the snippet will evaluate to `''`. Boom, we just crashed our app 💥.

![Red code error screen](https://res.cloudinary.com/echobind/image/upload/v1661874596/echobind_blog/d4k1i4erncjzjiesmajf.png)

Crash city.

Ok, this all makes sense, “so what is the big deal?”, you ask me. If our logic was going to lead to an app crash, then surely we’d see this in development. _Well, maybe._ The problem is that depending on your react native package version, this may not actually crash iOS. If you have someone primarily developing on iOS, they could easily write this code and everything would seem fine, only to fire up the Android build and see it crash.

(NOTE: as of the writing of this `react-native: "0.57.8"` will correctly crash when evaluating an empty string outside of a `Text` component on iOS. This issue primarily affects users still on react native `0.56` and below.)

If you want to be safe, make these two small tweaks to protect your conditional renders:

![](https://res.cloudinary.com/echobind/image/upload/v1661872926/echobind_blog/w8u6odrdf9q2ifbomoyy.png)

You can easily use type coercion or a ternary to be more explicit about the fallback return value, circumventing the issue entirely. This is the small suggestion I find myself making in pull requests. As I mentioned, if you’re on react-native `57` or greater, you will likely catch this before it becomes an issue, but for everyone on an older RN version, I find this is surprisingly common in pull requests.

[This is the original conversation if you’re curious.](https://github.com/facebook/react-native/issues/20764)

---

[View on echobind.com](https://echobind.com/post/a-common-conditional-rendering-bug-in-react-native)

---

# Lazy Loading Components in React

> Jan 22, 2019 | Here's how to improve website performance without sacrificing or removing all of the necessary input fields on the page.

_By Jeffrey Zhen · 2019-01-22_

Recently, I came across a problem in a project where the loading of a page was throttled by the number of large components being initialized. The page hosted a large form which included many custom input fields, dropdowns, radio buttons, and checkboxes.

```javascript
Finish times for page load:
 1st: 6.77s
 2nd: 5.82s
 3rd: 5.62s
 4th: 5.71s
 5th: 5.56s
Average: 5.90s 
```

A [**study by Google**](https://www.thinkwithgoogle.com/marketing-resources/data-measurement/mobile-page-speed-new-industry-benchmarks/) states that:

53% of mobile site visits leave a page that takes longer than three seconds to load.

Clearly, an average time of 6 seconds for a page to load is incredibly poor user experience. I needed to increase the performance without sacrificing or removing all of the necessary input fields on the page.

![think with Google](https://res.cloudinary.com/echobind/image/upload/v1661874884/echobind_blog/rmkpe6hjf3gvgjbykh6d.jpg)

A 6s page load has bounce increase of 106%! 😰

## Introducing react-infinite-scroller

[**react-infinite-scroller**](https://github.com/CassetteRocks/react-infinite-scroller) is a package that is usually used to implement infinite scroll pagination, with images being the most common use case. When you get to a certain threshold on the bottom of the page, it will make a request to fetch more images.

For my use case, I implemented it by using it to stagger the loading of components.

![React code in Visual Studio Code](https://res.cloudinary.com/echobind/image/upload/v1661874682/echobind_blog/odywtvz4i5ajafscuvok.png)

The full FormPage Component

**InfiniteScroller** takes 3 arguments:

* pageStart: integer telling what page it will begin load at
* hasMore: boolean telling it if it should continue loading
* loadMore: function that is called when `hasMore === true` and user reaches the loading threshold (bottom of page)

When the user reaches the bottom of page 0, `this.loadItems` is called and depending on what page the user is on, we push an arbitrary value and update the `formPage` array in `state:`

![React code in Visual Studio Code](https://res.cloudinary.com/echobind/image/upload/v1661873321/echobind_blog/vqgcu4tivj3m32a1o1j7.png)

**Note:** When we reach the last page, we flip **hasMoreItems to false** so it doesn’t continue 

In the `render()` method, we check the length of `formPage` and render each section of the form accordingly.

![React code in Visual Studio Code](https://res.cloudinary.com/echobind/image/upload/v1661873329/echobind_blog/diav8t76y7sjvdiqicsh.png)

**Note:** The **key** prop allows InfiniteScroller to index what section to load

With this implementation, our load times for the page reduces drastically:

```javascript
Finish times with infinite-react-scroller:
 1st: 1.41s
 2nd: 1.70s
 3rd: 1.32s
 4th: 1.55s
 5th: 2.33s
Average: 1.66s
```

With an average time of **1.66 seconds** versus the previous **5.90 seconds**, that’s a **72% increase** in speed!

The retention rate of new users is highly correlated to the loading speed of your webpage (especially on mobile devices). When you realize that [53% of visitors abandon a webpage if it takes over 3 seconds to load](https://www.thinkwithgoogle.com/marketing-resources/data-measurement/mobile-page-speed-new-industry-benchmarks/), performance becomes a top priority.

Lazy loading can be beneficial to your application if you have a large number of assets. If you are seeing poor performance on your application, consider staggering the loading of your assets or components as a possible solution.

---

[View on echobind.com](https://echobind.com/post/lazy-loading-components-in-react)

---

# Software Development: A Woodworkers Perspective (Part 1)

> Jan 14, 2019 | Along the way, Matt has found multiple cross-overs between what he aims to accomplish as a woodworker and in his day-to-day as a software engineer.

_By Matt Thompson · 2019-01-14_

## Planning and Preparation

If you read [my intro article](https://echobind.com/post/software-development-a-woodworkers-perspective), you’ll know I’ve been reading a lot of [books](https://echobind.com/post/software-development-a-woodworkers-perspective) about “Mastering your craft”. Along the way, I’ve found multiple cross-overs between what I aim to accomplish as a hobbyist and in my day-to-day as a software engineer. I decided to share these points as advice we hear over and over, this time as a woodworker rehashing the process it took to make a small box. If anything, maybe I’ll finally learn to apply these same principles I keep reading about. Maybe…

Take the time, you’ll thank yourself later.

## Planning and Preparation

It goes without saying, the best thing you can do before starting any project is to _think it through_. Take the request and whiteboard, napkin sketch, whatever it takes to think about the end goal. It doesn’t have to be pretty, just make the effort. Walk away, come back later, and do it all again. You’ll see something new every time, typically with the inner voice of “What was I thinking?” It’s easy to fall into the traps built by your own ego and confidence. Something along the lines of “This shouldn’t be that hard…” or “I can figure this part out as I go…” If you find yourself making these comments, do yourself a favor and stop. While you may be okay, it’s only a matter of time before errors occur. This is a game of “when will I screw up” not “will I”. Make a mental note and grab some coffee. Take the time, you’ll thank yourself later.

![Sharpening handplane blade ](https://res.cloudinary.com/echobind/image/upload/v1661874222/echobind_blog/txoytlumpubxid9waxpn.jpg)

Preparation doesn’t have to be pretty…

You’ve thought about the project and made as many mental notes as your brain will allow. You’re ready to get started. Only now you realize your tools are dull, beaten, and I swear that ruler was just laying here… Take the time to find and organize what you’ll need. You may find you don’t have the tools necessary to complete the job. At this point, you’ll either make a new plan or find the resources. Finally, make sure your tools are sharp, tuned, and ready. “Take care of your tools and they’ll take care of you.”

### The warm-up

To stay productive, you need to stay organized… or so I’m told. You try to keep the shop clean knowing if everything is in arms reach work can be done. Knowing you’ve done all you can, you approach the workbench with an attitude of _just_ _getting stuff done_. It’s about this time my brain starts to think about anything and everything else. My mind is **loud**. Regardless of what I do. It takes a fair amount of time to focus and for that reason, it’s always best to take a minute and settle into the task at hand. A warm up. Start with something small. Layout the tools you’ll need, review your notes, get re-acquainted with the work. It’s not going anywhere. Getting prepared for a project has nothing to do with it. Sometimes, you may need to step away and take care of the distractions and other to-do items that keep popping into play. If all else fails, find a place to escape.

Keep your ego in check. If possible start with something unrelated to the project. Make a few test cuts, and get in the mindset. Make sure you’re focused.

It all seems simple enough, but after your first couple of projects you’ll hit a point where you say to yourself “I’ve done this before”. I’ve made this same cut 1000 times over. Why is this one any different? Reaching for the saw, you start cutting into what will be the finished piece, without thought. You feel good about yourself. Accomplished even. Progress is being made and you are proud of it. Then it hits you… something’s wrong. When cutting joinery, it’s typically something stupidly preventable like cutting on the wrong side of a line or just cutting the side altogether. At this point, words are said and you’re back to square one. Literally — You’re back in the car, driving to the store to pick up new material and eating the cost. The whole time knowing it was preventable if you had just taken a second to layout the project. Keep your ego in check. If possible start with something unrelated to the project. Make a few test cuts, and get in the mindset. Make sure you’re focused.

![Cutting to the line](https://res.cloudinary.com/echobind/image/upload/v1661873811/echobind_blog/aiqpzqd46wnqzhiuefkb.jpg)

![Marking waste with a square](https://res.cloudinary.com/echobind/image/upload/v1661873818/echobind_blog/n93m4qjppb40i5enqpbe.jpg)

![Board with line cut on the end](https://res.cloudinary.com/echobind/image/upload/v1661873380/echobind_blog/h07pvlrfjpk7oyb6rqu8.jpg)

Left: Start with something unrelated Middle: Mark it out. What stays? What goes? Right: Mistakes happen

### Layout

If you’re like me and have already screwed up just getting to this point, it’s okay. Remember all the previous mistakes, don’t repeat them. Instead take the notes, the material, a pencil, and get everything marked out. Identify the major pieces of the puzzle, how they interact, and plan ahead. Instead of cutting blindly, take a minute to mark the cuts, what should stay, and what get’s removed. This is the point where the napkin sketch starts to take shape and any unknown obstacles can be spotted before you’re in over your head… or back at the store. You know the end goal. Make sure it’s possible. Mistakes can still be made at this stage, but they can be saved or brought back to planning. You should end with a solid idea of how everything will interact and work.

With all of this you’re ready for step two — Use your resources and start building.

* [**Part 2 — Use Your Resources and Start Building** ](https://echobind.com/post/software-development-a-woodworkers-perspective-part-2)

## The Crossover

As a Developer, you need to take the time to plan a project and to prepare for the task at hand. I _try_ to start all my projects the same.

* Think it through (describe the end goal)
* Warm up (review the project)
* Simplify your environment (remove distractions)
* Work on the broad strokes (mock, pseudo code)

Your mind needs to be ready and engaged. Warm up, review the project, _maybe remember how to open and close vim_. Tackle those side tasks that may annoy you later and get rid of any small task that may distract you along the way. Have a feel for all the major pieces of the project, where they belong, and how they interact. Take the time to understand how it all fits together. Project requests will change over time, but the knowledge gained here will provide you with all you will need to adapt. Be kind to your future self.

> “Do good work... ” — Rogowski

---

[View on echobind.com](https://echobind.com/post/software-development-a-woodworkers-perspective-part-1)

---

# Software Development: A Woodworkers Perspective

> Jan 01, 2019 | How does woodworking and software development relate? Matt takes us on a journey detailing his career path to software engineer.

_By Matt Thompson · 2019-01-01_

## About Me…

If you want to start reading [A Woodworker’s Perspective Part 1](https://echobind.com/post/software-development-a-woodworkers-perspective-part-1) instead of reading this article detailing my career path to Software Developer by day and Woodworker by night, you won’t hurt my feelings.

## A bit about me…

I’ve always been curious about how we interact with the world. How objects, both man-made and natural, were created. As a kid, I would crack open toys to see how they were built and how the pieces interacted, sometimes destroying it in the process. I was excited to see all the pieces in a pile of rubble, what was normally hidden became a pile of new building blocks. I would attempt to learn and then use the parts in a completely new way. The way LEGOs used to be…

In truth, I didn’t understand a lot as a kid, but I wanted to. I studied and dabbled a lot in college. First, it chose Mechanical Engineering, then Graphic Design, then Biology, then Sculpture, then Computer Science, then Architecture, then Business, and back to an interest in Furniture Making. Needless to say, I pulled the all famous 5th-year and ended up with what I call a well rounded liberal arts degree. I used those years to find what I enjoyed, but even then, I was still naive and unsure of what to do.

## _Fast-forward 13 years…_

Not a lot has changed. I still describe myself as a “builder”, and I still have an interest in _all the things_ with a hundred ideas, hoping one day to merge them into something bigger than myself_._ For now, it’s a dream. Honestly, like many others, my work has always been with an attitude, a chip on my shoulder. What’s needed to survive and to provide? What does it take to keep moving forward? For any Luke Cage fans out there, the quote _“Never backward, always forward. Always.”_ comes to mind_._

It’s about the process... create ways to step away.

I’ve worked many odd jobs in my short career span. At some point in all of them, I hit a point knowing deep down it was never about that job or the type of work. Some of them were just means to an end, but you keep pushing forward. The motivating factor for me has always been the process. How can I get to a point where the results of what I create makes a difference? If I keep doing ‘X’ and ‘Y’ where will I be in five years? Again, similar to other stories out there, I kept finding the same notes, advice, and habits each time I made a change. I soon came to the realization that it’s not about the job — it’s about the process.

Currently, I’m a software engineer by day and a traditional woodworker wannabe by night. Both take time, patience, and a willingness to learn. _One does not simply…_ pick up a chisel or start typing on a keyboard. Both are what I consider to be a craft. Although through different mediums, the approach is surprisingly the same. The practice and discipline from one reinforce the other. When speaking to new developers, the main advice I give is “Don’t try to learn everything at once.” Find a hobby, create ways to step away, and most importantly find something that forces you to learn and engage that’s not “work”. It should occupy your mind enough to forget about the other. When mastering a craft, it’s about the process, not the outcome. Don’t burn out.

Admittedly, that’s the hard part. You want to be the best. You want to succeed. People are depending on you. You’re running that race, but somehow always feel behind. Suddenly, you’re in your own head. When living that _always forward_ lifestyle, people seem to forget the obvious. It’s exhausting. It’s a marathon, not a sprint, and the finish line moves. It doesn’t stop moving and neither will you if you choose. One day I’m unloading trucks, the next its building an app, and tomorrow… maybe I’ll finally start building that kitchen table I sketched three years ago. Life changes. Enjoy the process, and learn from it.

![](https://res.cloudinary.com/echobind/image/upload/v1661873235/echobind_blog/nz8rcovhd5f6ptutdgy2.jpg)

In my studies as a woodworker, I’ve encountered multiple books that take on the same two questions every beginner has. “How long did it take to master your craft?” and “How do I do the same?”

I’ll be referencing a few books throughout as they’ve helped reinforced my own thoughts, and more importantly, pointed out that my crazy habits are not all that crazy. Although related to woodworking and trade, they are still relevant to any problem solver and a good weekend read. I’ve linked them below.

I plan to document and highlight some of these preferred habits and relate them to my day-to-day as a software developer. To start… Let’s make a box!

* [Software Development: A Woodworkers Perspective (Part 1) — Planning and Preparation](https://echobind.com/post/software-development-a-woodworkers-perspective-part-1)

**Books:**

* [Handmade — Gary Rogowski](#)
* [The How and Why of Woodworking — Michael Pekovich](https://www.amazon.com/Why-How-Woodworking-Approach-Meaningful/dp/1631869272/ref=sr%5F1%5F1?s=books&ie=UTF8&qid=1546869385&sr=1-1&keywords=how+and+why+of+woodworking)
* [Shop Class as Soulcraft — Matthew Crawford](https://www.amazon.com/Shop-Class-Soulcraft-Inquiry-Value/dp/0143117467)

---

[View on echobind.com](https://echobind.com/post/software-development-a-woodworkers-perspective)

---

# What is this type?!

> Oct 25, 2018 | If you’re new to TypeScript and you’re using a library like react-emotion, you might be wondering how to type your styled components. Here’s what I do.

_By Alvin Crespo · 2018-10-25_

If you’re new to [TypeScript](https://www.typescriptlang.org/) and you’re using a library like [react-emotion](https://github.com/emotion-js/emotion/tree/master/packages/react-emotion), you might be wondering how to type your styled components. Here’s what I do.

Let’s say you have the following styled component:

![React code](https://res.cloudinary.com/echobind/image/upload/v1661873977/echobind_blog/b82nllducss1hvhd1hrv.jpg)

What is the type for `AStyledComponent`?

I don’t know, but [VSCode](https://code.visualstudio.com/) is here to save the day:

![React code](https://res.cloudinary.com/echobind/image/upload/v1661873141/echobind_blog/rewpughcdivrtm6raqhv.png)

The above image shows me hovering over `AStyledComponent` and VSCode showing me what type it is. We can then use this type:

![React code](https://res.cloudinary.com/echobind/image/upload/v1661873149/echobind_blog/ailifwgtjbyttnvsrcn5.png)

But…what are all these type definitions? And, where do they come from?

Well, after some digging around in react-emotion, [create-emotion-styled](https://emotion.sh/docs/styled) and react itself — I found these awesome imports:

![React code](https://res.cloudinary.com/echobind/image/upload/v1661873595/echobind_blog/eog9yxvjvu5vpaa9xda2.jpg)

Note: When I say “digging” I meant going into node\_modules/react-emotion, node\_modules/create-emotion-styled and looking in their type definitions file (`index.d.ts` ).

As for the parameters for `StyledOtherComponent<A, B, C>` :

* `A`, denoted as `any` in the images above, is for the properties used within the style definition.
`B`, denoted as DetailedHTMLProps<HTMLAttributes, HTMLDivElement> is for the component you are wrapping. 
* `C`, denoted as `any`, is for a theme.

Alright! That’s all I have for you folks today. Let me know if you have any questions or feedback — I’d love to hear it.

Also, did you know the team at Echobind is [hiring](https://echobind.workable.com/)?! That’s right, we’re looking for some awesome people to help us build some cool products. For more info, check us out [here](https://echobind.com/about).

---

[View on echobind.com](https://echobind.com/post/what-is-this-type)

---

# Investing in Echobind

> Sep 14, 2018 | After a great first half of 2018, we’ve made some exciting investments in Q3 that we would like to share.

_By Michael Yared · 2018-09-14_

After a great first half of the year, we’ve made some exciting investments in Q3 that we would like to share.

Our agency is growing, and we’ve added three full time employees to our team. We picked up **Ashley Nelms**, a developer from Seattle, who is our first Delivery Lead. Ashley is a problem solver and brings exceptional communication skills to Echobind. Ashley is also at the beginning stages of her development career. We look forward to helping her develop both of these complementary skills.

In August, **Matt Thompson** accepted our offer to join the team as a full stack Software Developer. Matt made the call easy for us. He brings experience in React and Elixir, tech we use every day. When Matt’s not at work, he spends time woodworking and helping co-manage local meetups in Louisville.

We had to announce that **Jeff Zhen** will be ending his internship sooner than expected. But we’re not sad at all as Jeff will be joining our Boston team as a full time developer. Jeff’s a reformed scientist with a BS in Biochemistry and Molecular Biology. He’s proven that he can take any project that we throw at him.

And with one internship ending, another begins. **Chelsea** **Galvez**, a senior at University of Washington, has joined us for the fall. Chelsea won us over with her [approach to problem solving](https://chelseagalvez.com/paymate). We’re excited to add her voice during our planning sessions and to see how her skills enhance several of our internal and client projects.

![Chelsea Galvez sitting on oversized teddy bear](https://res.cloudinary.com/echobind/image/upload/v1661873077/echobind_blog/q1cmq0plbtxdybsp5rkq.jpg)

![Jeff Zhen](https://res.cloudinary.com/echobind/image/upload/v1661873084/echobind_blog/hndtvnjgsmmeiuwo3fef.jpg)

![Matt Thompson woodworking](https://res.cloudinary.com/echobind/image/upload/v1661873091/echobind_blog/acbqik0v1wn2wdjlhoon.jpg)

![Ashley Nelms](https://res.cloudinary.com/echobind/image/upload/v1661873098/echobind_blog/ytgyrbqzzmtbcpjvgnz4.jpg)

Chelsea, Jeff, Matt & Ashley

## Adding Creatives

Speaking of design… We’re going to continue investing in creative resources. For years, we’ve worked with trusted subcontractors or partnered with other agencies to add creative work to our applications. But now we’re ready to take the next step and invest in a Design Lead.

Our team has a diverse background working at larger agencies, product companies and startups. We know what we like and don’t like, but we’re also not afraid to say there’s a lot we don’t know. That’s why for us, it’s critical that this first hire has passion for design, can communicate their ideas clearly, and can lead integration efforts_._ Look for us to roll out additional design services in 2019!

## Our Summit

![Echobind 2019 summit logo](https://res.cloudinary.com/echobind/image/upload/v1661873105/echobind_blog/o88xgwzelzi5npuriugt.png)

Echobind is taking the week September 17th off from client work to invest in ourselves. We’re flying the entire team to beautiful Scottsdale, Arizona for a week in a desert mansion. Every morning we will be sharpening our strategic thinking and problem solving skills while the afternoons will be spent collaborating on a company project.

Our takeaways include new skills for our consulting work and the launch of an internal product. As a remote agency, it’s a unique opportunity for us to be in the same city, so we’re thrilled for the opportunity to work together on a shared vision with a common goal. It’s a chance to recharge and level up as a team, and we can’t wait to see what we accomplish in Q4.

P.S. — We’re hiring [React and React Native developers](https://echobind.workable.com/)!

---

[View on echobind.com](https://echobind.com/post/investing-in-echobind)

---

# Automating CodePush deploys with Fastlane

> Aug 27, 2018 | CodePush is a great service that allows you to update your React Native apps over the air without waiting on the user to update their app through the App Store or Google Play.

_By Chris Ball · 2018-08-27_

[CodePush](https://microsoft.github.io/code-push/) is a great service that allows you to update your React Native apps over the air without waiting on the user to update their app through the App Store or Google Play. CodePush is extremely configurable, and includes a CLI to configure and initialize deploys. Despite a simple `release-react` command and some good defaults, there are lots of questions and parameters to remember, such as:

* What track should I use (dev, staging, or production)?
* What version of the app should this deploytarget (what could break by releasing this)?
* Do I want to force-apply this update immediately and not wait until the next time the app resumes?

## Why Automate?

A common thread exists between every software developer, regardless of experience. We’re all human, and humans make mistakes.

The best way to reduce the likelihood of a mistake is to automate as much as possible in your workflows and processes. In the React Native world, the best deploy-related tool we’ve found to do that is [fastlane](https://fastlane.tools/).

NOTE: If your impatient, and just want to see the full script we’re using, skip to the bottom of the page. For more detail on each piece, read on.

## Create Codepush Lanes

We’ll start by creating our fastlane entry points, a lane called `codepush_ios` and a lane called `codepush_android`.

The only job of those lanes is to pass an app name param to a [private lane](https://docs.fastlane.tools/advanced/lanes/#private-lanes) (think of these as private methods).

```javascript
desc "Codepush release to iOS"
lane :codepush_ios do |options|
  CODEPUSH_APP = "MyOrg/MyApp-ios"
  do_codepush(app_name: CODEPUSH_APP, manditory: options[:manditory])
end

desc "Codepush release to Android"
lane :codepush_android do |options|
  CODEPUSH_APP = "MyOrg/MyApp-android"
  do_codepush(app_name: CODEPUSH_APP, manditory: options[:manditory])
end
```

### The Main Script

The main part of our script first checks to make sure there are no local git modifications, and wraps the built-in `release-react` command with a nice confirmation message. This gives a user a chance to make sure everything is correct before continuing.

To keep things clean, we handle getting the correct CodePush environment and app version from other private lanes.

```javascript
private_lane :do_codepush do |options|
  ensure_git_status_clean
  environment = select_codepush_environment(options[:app_name])
  version = select_app_version(project_name: project_name)
  manditory = !!options[:manditory]
  manditory_string = manditory ? " -m" : ""

  if UI.confirm("About to CODEPUSH your local branch *#{git_branch}* to the *#{options[:environment]}* environment for users running version #{options[:version]}. Proceed?")
    Dir.chdir("..") do
      sh "appcenter codepush release-react -a #{options[:app_name]} -d #{options[:environment]} -t #{options[:version]}#{manditory_string}" do |status, result, command|
        unless status.success?
          UI.error "Command #{command} failed with status #{status.exitstatus}"
        end

        UI.success "🚀 All done! Check out the rollout & install stats in the Codepush section of the dashboard on App Center."
      end
    end
  else
    UI.error "😅 that was close!"
  end
end
```

### Select a Proper Codepush Environment

These private lanes handle fetching the available CodePush environments and prompting the user to select one. By default AppCenter will create a Staging and Production environment, but you can create as many as you’d like.

```javascript
private_lane :select_codepush_environment do |options|
  available_environments = fetch_codepush_environments(app_name: options[:app_name])
  environment_labels = available_environments.map{|e| e.first}
  UI.select("What environment do you want to target?", environment_labels)
end

# fetch codepush environments. assumes the user has logged in to appcenter cli
# via `appcenter login`
private_lane :fetch_codepush_environments do |options|
  FETCH_ENV_COMMAND = "appcenter codepush deployment list -a APPNAME --output json"
  UI.message "Fetching Codepush environments for #{options[:app_name]}"

  sh FETCH_ENV_COMMAND.sub(/APPNAME/, options[:app_name]) do |status, result, command|
    unless status.success?
      UI.error "Command #{command} failed with status #{status.exitstatus}. Are you logged in via `appcenter login`?"
    end

    JSON.parse(result)
  end
end
```

### Select a Target App Version

This private lane will parse the current app version (it currently assumes iOS and Android are versioned in lockstep), and prompt the user for a target version.

Assuming the current app is version 1.3.0, selecting “All users” will apply the codepush update to every version. Selecting “most recent major” and “most recent minor” will target `1.x.x` and `1.3.x` respectively, and “Current” will target `1.3.0` only. To make sure this is clear to the user, we show the version target in the select prompt.

```javascript
private_lane :select_app_version do |options|
  # Assumes symver (x.x.x) or 💥
  current_version = get_version_number(xcodeproj: "./ios/#{project_name}.xcodeproj", target: options[:project_name])
  current_major = [current_version.split('.').first, 'x', 'x'].join('.')
  current_minor = current_version.split('.').slice(0, 2).push('x').join('.')

  target_version_label = UI.select("What version do you want to target?", [
    "All users",
    "Most recent major (#{current_major})",
    "Most recent minor (#{current_minor})",
    "Current (#{current_version})",
  ])

  next "\"*\"" if target_version_label.match?(/All/)
  next current_major if target_version_label.match?(/major/)
  next current_minor if target_version_label.match?(/minor/)

  current_version
end
```

## That’s all folks!

Putting this all together, you now just have to run `fastlane codepush_ios` and `fastlane codepush_android`, answer a few questions, and watch it 🚀!

![Code running in terminal](https://res.cloudinary.com/echobind/image/upload/v1661873747/echobind_blog/joht2icho8nw2d58uw89.png)

Our script in action - Part 1

![Code running in terminal](https://res.cloudinary.com/echobind/image/upload/v1661874236/echobind_blog/fyfkkxfa6lcmc2eyolge.png)

Our script in action — Part 2

Here’s the full script:

```javascript
project_name = 'MyApp'

# To release a new version of the app via CodePush, run `bundle exec fastlane codepush_ios`
# or `bundle exec fastlane codepush_android` from the proper branch. For example:
# If you want to CodePush to the production (release) version, make sure and run this from the release branch.
# If you want to CodePush to the beta version, make sure to run this from the beta branch.
#
# Generally speaking, you should use the Staging track to validate a production Codepush before it is released / promoted.
#
# To mark an update as manditory, which will immediately download, apply the update, and restart the users app,
# pass manditory:true. `bundle exec fastlane codepush_ios manditory:true`
desc "Codepush release to iOS"
lane :codepush_ios do |options|
  CODEPUSH_APP = "MyOrg/MyApp-ios"
  do_codepush(app_name: CODEPUSH_APP, manditory: options[:manditory])
end

desc "Codepush release to Android"
lane :codepush_android do |options|
  CODEPUSH_APP = "MyOrg/MyApp-android"
  do_codepush(app_name: CODEPUSH_APP, manditory: options[:manditory])
end

private_lane :select_codepush_environment do |options|
  available_environments = fetch_codepush_environments(app_name: options[:app_name])
  environment_labels = available_environments.map{|e| e.first}
  UI.select("What environment do you want to target?", environment_labels)
end

# fetch codepush environments. assumes the user has logged in to appcenter cli
# via `appcenter login`
private_lane :fetch_codepush_environments do |options|
  FETCH_ENV_COMMAND = "appcenter codepush deployment list -a APPNAME --output json"
  UI.message "Fetching Codepush environments for #{options[:app_name]}"

  sh FETCH_ENV_COMMAND.sub(/APPNAME/, options[:app_name]) do |status, result, command|
    unless status.success?
      UI.error "Command #{command} failed with status #{status.exitstatus}. Are you logged in via `appcenter login`?"
    end

    JSON.parse(result)
  end
end

private_lane :select_app_version do |options|
  # Assumes symver (x.x.x) or 💥
  current_version = get_version_number(xcodeproj: "./ios/#{project_name}.xcodeproj", target: options[:project_name])
  current_major = [current_version.split('.').first, 'x', 'x'].join('.')
  current_minor = current_version.split('.').slice(0, 2).push('x').join('.')

  target_version_label = UI.select("What version do you want to target?", [
    "All users",
    "Most recent major (#{current_major})",
    "Most recent minor (#{current_minor})",
    "Current (#{current_version})",
  ])

  next "\"*\"" if target_version_label.match?(/All/)
  next current_major if target_version_label.match?(/major/)
  next current_minor if target_version_label.match?(/minor/)

  current_version
end

private_lane :do_codepush do |options|
  ensure_git_status_clean
  environment = select_codepush_environment(options[:app_name])
  version = select_app_version(project_name: project_name)
  manditory = !!options[:manditory]
  manditory_string = manditory ? " -m" : ""

  if UI.confirm("About to CODEPUSH your local branch *#{git_branch}* to the *#{options[:environment]}* environment for users running version #{options[:version]}. Proceed?")
    Dir.chdir("..") do
      sh "appcenter codepush release-react -a #{options[:app_name]} -d #{options[:environment]} -t #{options[:version]}#{manditory_string}" do |status, result, command|
        unless status.success?
          UI.error "Command #{command} failed with status #{status.exitstatus}"
        end

        UI.success "🚀 All done! Check out the rollout & install stats in the Codepush section of the dashboard on App Center."
      end
    end
  else
    UI.error "😅 that was close!"
  end
end
```

***To learn more about our mobile development process at Echobind, visit our [React Native capabilities page](/services/react-native-app-development).***

---

[View on echobind.com](https://echobind.com/post/automating-codepush-deploys-with-fastlane)

---

# A 12-Factor Approach to Environment-Specific Builds in React Native

> Aug 07, 2018 | Having separate builds for dev, beta, and production environments is critical for most apps.

_By Chris Ball · 2018-08-07_

Having separate builds for dev, beta, and production environments is critical for most apps.

These environment specific builds give us a way to:

* Change the values of variables at build time
* Change app/bundle ids to allow the installation of any environment variant on the same device at the same time
* Change the icon for each build variant
* Change the display name of the app

Let’s look at how to do that in React Native!

There are two main ways to configure environment-specific builds in your app, and neither of them are the following approach:

```javascript
// development
const API = 'http://localhost:4000';
// staging
// const API = 'https://my-staging-server.com';
// production
// const API = 'https://my-prod-server.com';
```

![Cat hugging another cat with Don't do it Carl! You're on your 9th life quote](https://res.cloudinary.com/echobind/image/upload/v1661872559/echobind_blog/ajfwpwnhefh9i5y8vgcx.jpg)

### The traditional (manual) approach

The first way to set up environment-specific builds involves using `schemes` and `build configurations` in Xcode, and `buildTypes` or `productFlavors` for Android. You then have to set up user-defined variables in Xcode and create separate `.properties` files for Android. But guess what? You now have to manage the values in both places.

It would be nice to have a single place to do this, and ideally a way to do so without touching native code.

### The 12-factor approach

At Echobind, we follow the 12-factor approach for all of our web and mobile apps. Using this approach, you create a single version of your app configured differently via environment variables. We see multiple wins by taking this approach in React Native:

* It’s harder to accidentally build and submit a release of the wrong type and for example, submit a beta build to the App Store.
* There aren’t multiple configurations to manage differently (one for iOS and one for Android)
* If you `.gitignore` your `.env` files, developers don’t have access to staging or production configurations by default, which increases security.

In React Native, we can gain access to ENV variables by using [react-native-config](https://github.com/luggit/react-native-config). [babel-transform-inline-environment-variables](https://github.com/babel/minify/tree/master/packages/babel-plugin-transform-inline-environment-variables) is an alternative option, but it doesn’t currently work in the App Center environment. We use App Center on a lot of client projects (expect an App Center specific post from us soon!), so we stick with `react-native-config`. It requires a bit more setup, but you also get the added benefit of having access to environment variables in native code, and configuration files if you need them (such as `Info.plist` on iOS and `strings.xml` on Android).

`react-native-config` expects an `.env` file which defines all the environment variables used in your app. We strongly believe that `.env` files should not be checked into source control, so we needed a way to provide one to our CI server.

## .env on CI

Most CI’s [support](https://docs.microsoft.com/en-us/appcenter/build/custom/scripts/) [build](https://circleci.com/docs/2.0/using-shell-scripts/) [scripts](https://docs.travis-ci.com/user/customizing-the-build/#implementing-complex-build-steps) to run custom commands at various points in the build pipeline. We can leverage these scripts to create a `.env` file for us. Here’s what an example `appcenter-pre-build.sh` script looks like, which creates an `.env` dynamically:

```javascript
#!/usr/bin/env bash
# Creates an .env from ENV variables for use with react-native-config
ENV_WHITELIST=${ENV_WHITELIST:-"^RN"}
printf "Creating an .env file with the following whitelist:\n"
printf "%s\n\n" $ENV_WHITELIST
set | egrep -e $ENV_WHITELIST | egrep -v "^_" | egrep -v "WHITELIST" > .env
printf "\n.env created with contents:\n"
cat .env
```

This script takes a configurable whitelist of ENV variables (defaulting to anything with an `RN` prefix), and uses `set` and `-->egrep-->` to filter available ENV variables down to only the variables that match that whitelist regex. The output is saved to an `.env` file which react-native-config reads before building our app.

## Changing variables at build time

With `react-native-config` setup, changing your API server or any other variable is now just a matter of:

* Using `Config.ENV_NAME` in place of a hardcoded value in your app code.
* Updating your local `.env` file to have a sensible default.
* Adding an ENV variable to your CI server with the `beta` or `production` value.
* Informing your team members. We like to keep an `.env.example` in the project root that contains all the variables (without real values) that need to be set.

## Change the bundle / app id for each environment

Each app has an id assigned to it (typically `com.yourcompany.AppName`). This is called a bundle identifier on iOS and an app id on Android. If the beta build of your app and release build of your app share an id, you can’t install both at the same time on the same device. To get around this, we dynamically assign a different id at build time.

We need a way to add a suffix to the id for each release type:

```javascript
com.yourcompany.AppName
```

```javascript
com.yourcompany.AppName.alpha
```

```javascript
com.yourcompany.AppName.beta
```

Tools like [PlistBuddy](https://willowtreeapps.com/ideas/using-plistbuddy-to-inject-app-secrets-and-keys-at-build-time) and Gradle scripts can help with this, but we’re trying to do things cross-platform in a unified way. Enter [fastlane](https://fastlane.tools/). To setup fastlane, follow the [Getting Started](https://docs.fastlane.tools/getting-started/ios/setup/) section in the guides.

To start, we’ll create a basic lane that will be used to update the bundle / app id. Create a `fastlane` folder with the following 2 files in the root of your project:

![Fastlane folder with two files nested under it](https://res.cloudinary.com/echobind/image/upload/v1661872565/echobind_blog/mo2tqiv6113rhnjnvify.png)

\`fastlane init\` will complain about finding an ios project in a subfolder, so just create these manually.

Update `Appfile` with the app\_identifier and package\_name that your app uses. This will avoid prompts from fastlane to request these values.

```javascript
# iOS Settings
app_identifier("com.yourcompany.YourApp")

# Android Settings
package_name("com.yourcompany.YourApp") 
```

Next, add the magic. fastlane comes bundled with an ios plugin called `update_info_plist` that we will use to update the app\_id. On Android, we’ll leverage a built-in concept called `applicationIdSuffix` and install a plugin that does the same thing. Add the following a line to `android/app/build.gradle`, and set it to an empty string by default.

![CSS Code](https://res.cloudinary.com/echobind/image/upload/v1661873739/echobind_blog/fio1wlf2zxdkiym6rfd9.png)

After setting up react-native-config, this is the only “native” change you’ll have to make

Next, install the `set_value_in_build` plugin:

![Terminal with install data](https://res.cloudinary.com/echobind/image/upload/v1661873919/echobind_blog/fhc2khms9n57tbqvvsbx.png)

As of August, 1, 2018, this plugin doesn’t properly update values that contain empty strings (I have an [open PR](https://github.com/otkmnb2783/fastlane-plugin-android%5Fversioning/pull/7) that fixes it). In the meantime, if you want to follow the same process here, you’ll need to point to a fork.

Update the `fastlane/Pluginfile` that was created when you installed the plugin to point to the fork:

```javascript
# Autogenerated by fastlane
#
# Ensure this file is checked in to source control!
gem 'fastlane-plugin-android_versioning', github: "cball/fastlane-plugin-android_versioning", ref: "support-blank-id-suffix"
```

Run `bundle install` to install the updated gem.

To use these plugins, update your `Fastfile` to the following:

```javascript
# this should be the folder name under `ios` for your project
project_name = 'MyProject'

# NOTE: This is meant to be run on CI where it changes everything before building the app.
# Usage:
#   `RN_RELEASE_TYPE=beta fastlane prep_release_type` (on CI these ENV variables should be set via the UI)
desc "Updates the app identifier, display name and icon for alpha, beta, and production releases"
lane :prep_release_type do
  # alpha, beta, production
  type = ENV['RN_RELEASE_TYPE'] || 'production'
  next if type == 'production'
  
  suffix = ENV['RN_BUNDLE_SUFFIX'] || type
  # assumes identifier is defined in Appfile
  app_id = CredentialsManager::AppfileConfig.try_fetch_value(:app_identifier)
  new_app_id = "#{app_id}.#{suffix}"
  
  # update the app identifier and bundle
  UI.message "\n\nSetting app identifier to: #{new_app_id}"

  # update ios indentifier
  update_info_plist(
    plist_path: "#{project_name}/Info.plist",
    xcodeproj: "./ios/#{project_name}.xcodeproj",
    app_identifier: new_app_id
  )

  # update android suffix
  set_value_in_build(
    app_project_dir: "./android/app",
    key: "applicationIdSuffix",
    value: ".#{suffix}"
  )
end
```

In this lane, we provide a configurable release type. We typically use `alpha`, `beta`, and `production`, but additional types can be added by changing the environment variable.

We then set a customizable suffix, which defaults to the release type.

Time to test it out! Run the following command from your project root. The use of `bundle exec` is important to ensure we execute the command in the context of our project `Gemfile`.

```javascript
RN_RELEASE_TYPE=beta bundle exec fastlane prep_release_type
```

You should see the following updates:

![GitHub code changes](https://res.cloudinary.com/echobind/image/upload/v1661873609/echobind_blog/baw9yt0ljvktp7bzitpr.png)

ios changes

![GitHub code changes](https://res.cloudinary.com/echobind/image/upload/v1661872947/echobind_blog/goqkczsnw1iagp0ttene.png)

android changes

Remember, this is designed to be run on CI and discarded after build, so it’s fine that these values get overwritten.

## Change the Icon for Each Environment

Now that we’re able to install the different builds side-by-side we need to make the app icon visually distinctive so we know which one we’re opening.

To do this, we’ll make use of a great plugin for [fastlane](https://fastlane.tools/) called [badge](https://docs.fastlane.tools/actions/badge/).

If you don’t already have Imagemagick installed, do that first (`brew install imagemagick` on a mac).

Next install the badge plugin:  

```javascript
fastlane add_plugin badge
```

Insert an `add_badge` command to the existing lane for each platform. If you have a typical icon setup, the following should just work for you. Otherwise, you may have to adjust the `glob` line for each platform.

```javascript
lane :prep_release_type do
  # ...
  
  # Add badge to app icon
  # want to add the app version to the icon? try this:
  #  current_version = get_version_number(xcodeproj: "./ios/#{project_name}.xcodeproj", target: project_name) 
  #  add_badge(
  #    shield: "Version-#{current_version}-blue"
  #    shield_scale: 0.75
  #  ) 
  # 
  # See all available options at: https://github.com/HazAT/badge
  UI.message "\n\nUpdating app icon with #{type} badge"

  # ios badge
  add_badge(
    glob: "/ios/**/*.appiconset/*.{png,PNG}", # note no dot in path
    alpha: type == 'alpha',
    grayscale: type == 'alpha'
  )

  # android badge
  add_badge(
    glob: "/android/app/src/main/res/**/*.{png,PNG}", # note no dot in path
    alpha: type == 'alpha',
    grayscale: type == 'alpha'
  )
end
```

Now, we can re-run our previous command to produce some slick looking badges!

```javascript
RN_RELEASE_TYPE=beta bundle exec fastlane prep_release_type
```

```javascript
RN_RELEASE_TYPE=alpha bundle exec fastlane prep_release_type
```

![Left image is fastlane logo in color and right image is fastlane logo with Beta in bottom right](https://res.cloudinary.com/echobind/image/upload/v1661873430/echobind_blog/rjgknmug57cqkaonycht.png)

Example of our beta icon

![Left image is black and white fastlane logo and right image is fastlane logo with Beta in bottom right](https://res.cloudinary.com/echobind/image/upload/v1661873437/echobind_blog/ln1e4q0yoxqgrmqbonty.png)

Example of our alpha icon

Note: Like the app id changes, it will modify the icon in place. If you’re testing this out locally, just discard the changes.

## Changing the display name

For iOS, we just have a minor update, but to handle Android we need to install another plugin to update our `strings.xml` file:

```javascript
fastlane add_plugin update_android_strings
```

Now we can update our lane to change the display name on both platforms:

```javascript
lane :prep_release_type do
  # ...
  
  display_name = ENV['RN_DISPLAY_NAME'] || type.capitalize
  UI.message "\n\nSetting Display Name to: #{display_name}"
  
  # update ios indentifier and display name
  update_info_plist(
    plist_path: "#{project_name}/Info.plist",
    xcodeproj: "./ios/#{project_name}.xcodeproj",
    display_name: display_name,  # <------------------ add this line to our existing update_info_plist call
    app_identifier: new_app_id
  )
  
  # update android display name
  update_android_strings(
    block: lambda { |strings|
      strings['app_name'] = display_name
    }
  )
  
  # ...
end
```

## Environment-specific builds for the win

Welcome to a scalable, secure way to set up variables, icons, display names, and bundle suffixes for different environments your app needs. You should be able to set up any CI to run your Fastlane lane, overriding the defaults via ENV variables as needed.

Here’s our final `Fastfile` for reference:

```javascript
# this should be the folder name under `ios` for your project
project_name = 'MyProject'

# NOTE: This is meant to be run on CI where it changes everything before building the app.
# Usage:
#   `RN_RELEASE_TYPE=beta fastlane prep_release_type` (on CI these ENV variables should be set via the UI)
#   Available release types: alpha, beta, production (default)
# 
# If you're trying this script out locally, make sure you have ImageMagick installed, and discard the changes via git when you're done.
desc "Updates the app identifier, display name and icon for alpha, beta, and production releases"
lane :prep_release_type do
  # alpha, beta, production
  type = ENV['RN_RELEASE_TYPE'] || 'production'
  next if type == 'production'

  suffix = ENV['RN_BUNDLE_SUFFIX'] || type
  # assumes identifier is defined in Appfile
  app_id = CredentialsManager::AppfileConfig.try_fetch_value(:app_identifier)
  new_app_id = "#{app_id}.#{suffix}"
  display_name = ENV['RN_DISPLAY_NAME'] || type.capitalize

  UI.message "\n\nSetting app identifier to: #{new_app_id}"
  UI.message "\n\nSetting Display Name to: #{display_name}"

  # update ios indentifier and display name
  update_info_plist(
    plist_path: "#{project_name}/Info.plist",
    xcodeproj: "./ios/#{project_name}.xcodeproj",
    display_name: display_name,
    app_identifier: new_app_id
  )
  
  # update android display name
  update_android_strings(
    block: lambda { |strings|
      strings['app_name'] = display_name
    }
  )
  
  # update android suffix
  set_value_in_build(
    app_project_dir: "./android/app",
    key: "applicationIdSuffix",
    value: ".#{suffix}"
  )

  # Add badge to app icon
  # want to add the app version to the icon? try this:
  #  current_version = get_version_number(xcodeproj: "./ios/#{project_name}.xcodeproj", target: project_name) 
  #  add_badge(
  #    shield: "Version-#{current_version}-blue"
  #    shield_scale: 0.75
  #  ) 
  # 
  # See all available options at: https://github.com/HazAT/badge
  UI.message "\n\nUpdating app icon with #{type} badge"

  # ios badge
  add_badge(
    # use dark if your icon is light in color
    # dark: true,
    glob: "/ios/**/*.appiconset/*.{png,PNG}", # note no dot in path
    alpha: type == 'alpha',
    grayscale: type == 'alpha'
  )

  # android badge
  add_badge(
    # use dark if your icon is light in color
    # dark: true,
    glob: "/android/app/src/main/res/**/*.{png,PNG}", # note no dot in path
    alpha: type == 'alpha',
    grayscale: type == 'alpha'
  )
end
```

**_Need help with your React Native app?_** 
[Say hello!](https://echobind.com/contact) We’d love to chat.

---

[View on echobind.com](https://echobind.com/post/a-12-factor-approach-to-environment-specific-builds-in-react-native)

---

# Integrating Prettier + ESLint + Airbnb Style Guide in VSCode

> I have found two well-known VSCode extensions that can scan your JavaScript / TypeScript code and reformat it to a very legible and attractive style.

_By Jeffrey Zhen · 2018-06-20_

> _The ratio of time spent reading (code) versus writing is well over 10 to 1 … (therefore) making it easy to read makes it easier to write. -Bob Martin, Clean Code_

Formatting code and adhering to style guides can be a time-consuming and meticulous task. I remember when I first started programming, I would count the number of times I pressed the space bar when I wanted to indent on a new line. And at the end of every line, I would check for semi-colons and trailing commas. Thankfully, those days are over. I have found two well-known extensions that can scan your code and reformat it to a very legible and attractive style.

**11/11/2018 UPDATE**: 

[Paulo Ramos](https://medium.com/u/e1c465f43a0a?source=post%5Fpage-----47f07b5d7d6a-----------------------------------) created an awesome shell script for this: <https://github.com/paulolramos/eslint-prettier-airbnb-react>

## Prettier

![Prettier icon](https://res.cloudinary.com/echobind/image/upload/v1661872652/echobind_blog/p4x70wy84zggzjxct1nm.png)

[**Prettier**](https://prettier.io/) is an opinionated code formatter. It supports many languages and integrates with most code editors. You can also set your preferences in the options. Some of the options include tab width, trailing commas, bracket spacing, etc.

I don’t write the best-looking code, but with Prettier I no longer have to worry about that. After a long session of furiously hacking away on my keyboard, I can save my file and then **\*poof\*** — it auto-magically formats my code!

![React code](https://res.cloudinary.com/echobind/image/upload/v1661872659/echobind_blog/puautmhlraywepwacdlh.gif)

Prettier doing work! 💁

## ESLint

![ESLint icon](https://res.cloudinary.com/echobind/image/upload/v1661872666/echobind_blog/aa2vhjdc8a9obpsaiqvy.png)

[**ESLint**](https://eslint.org/), is program that runs through your code and analyzes it for potential errors. The extension is highly configurable, with an assortment of built-in options for matching your company’s style guide. It can highlight errors while you type in your editor, as well as display an itemized list of errors in your console.

![code running in console](https://res.cloudinary.com/echobind/image/upload/v1661873055/echobind_blog/iqx1k8rmggcsfndfsgzf.jpg)

Itemized ESLint errors in the console

## Combining Prettier with ESLint + Airbnb Style Guide

We will set this up so that Prettier will be our main extension for code formatting (based on the ESLint rules we define). **Our goal will be to disable all formatting rules inside ESLint so that we will only use it for errors, and have Prettier format all our code instead.**

> _I would also like to preface that at the time of this writing (June 2018), this will not work if you install the libraries globally. In order for this to work, you will have to install ESLint and the other dependencies locally to your project (preferably under devDependencies)._

Before we begin, you will have to install [**npm**](https://github.com/npm/npm) and then [**npx**](https://github.com/zkat/npx).

1. Download the [ESLint](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint) and [Prettier](https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode) extensions for VSCode.
2. Install the ESLint and Prettier libraries into our project. In your project’s root directory, you will want to run: npm install -D eslint prettier
3. Install the [Airbnb config.](https://github.com/airbnb/javascript/tree/master/packages/eslint-config-airbnb) If you’re using npm 5+, you can run this shortcut to install the config and all of its dependencies: `npx install-peerdeps --dev eslint-config-airbnb`
4. Install [eslint-config-prettier](https://github.com/prettier/eslint-config-prettier) (disables formatting for ESLint) and [eslint-plugin-prettier](https://github.com/prettier/eslint-plugin-prettier) (allows ESLint to show formatting errors as we type) npm `install -D eslint-config-prettier eslint-plugin-prettier`
5. Create `.eslintrc.json` file in your project’s root directory:  
```javascript  
{  
  "extends": ["airbnb", "prettier"],  
  "plugins": ["prettier"],  
  "rules": {  
    "prettier/prettier": ["error"]  
  },  
}  
```
6. Create `.prettierrc` file in your project’s root directory. This will be where you configure your formatting settings. I have added a few of my own preferences below, but I urge you to read more about the [Prettier config file](https://github.com/prettier/prettier#configuration-file)  
```javascript  
{  
  "printWidth": 100,  
  "singleQuote": true  
}  
```
7. The last step is to make sure Prettier formats on save. Insert `"editor.formatOnSave": true` into your User Settings in VSCode.

### ‍**Congratulations, you did it**!

You were able to mediate the conflicting differences between the two, and now they are the best of friends! Our linter will allow us to detect bugs early, and our formatter will help us maintain consistency throughout our codebase. With both these extensions working side-by-side, we should be able to build clean and maintainable code. Your boss will thank you, your peers will thank you, and low-key — [Microsoft](https://news.microsoft.com/2018/06/04/microsoft-to-acquire-github-for-7-5-billion/) will probably thank you 🙃

If you have any recommendations or tips, I would love to hear more! 👂

_Also, check out my previous post about_ [**_Essential Customizations for VSCode!_**](https://echobind.com/post/essential-customizations-for-vscode)

---

[View on echobind.com](https://echobind.com/post/integrating-prettier-eslint-airbnb-style-guide-in-vscode)

---

# Productive Performance for Engineers

> Jun 18, 2018 | Let's cover a topic that is often overlooked when starting an internship: organization.

_By Jeffrey Zhen · 2018-06-18_

It’s been a month now since I’ve joined the ranks here at Echobind.

In these past 4 weeks, I’ve struggled _a lot,_ but I’ve **learned even more**. Today, I wanted to cover a topic that I overlooked when I first started my internship: _organization_.

Previously, my usual development cycle went a little like this:

1. Get assigned user stories
2. Move one over to “In Progress” on the project board
3. Load up my editor
4. _\*click\* \*clack\* \*click\* \*clack\* \*click\* \*clack\*_
5. Move the assignment to “Done”
6. Grab next user story
7. Repeat steps 2–6 _ad infinitum_

With these kinds of habits, it was natural for me to neglect proper planning. At first, I honestly thought that organizing tasks would be counterproductive. You spend so much time thinking about what to do and how to do it. To me, it just seemed way more efficient to grab tasks and hack away until they were complete.

> Weeks of coding can save you hours of planning.

During my second week here, I hopped on a Ruby on Rails project and was assigned a _somewhat_ broad feature to implement: “**New Patient Referral Confirmation Page”**. A seasoned developer might be okay with a task like this, but I found it very challenging. I was _drowning_ in the code base; my browser window had 50 different tabs open, I was writing code that was impractical, I was going off tangents and digging myself deeper into programming limbo.

I found it especially challenging because:

1. I was working with a framework that I hadn’t touched in well over a year.
2. Ruby on Rails uses a lot of black magic under the hood that isn’t clearly explained.

_What problem does the feature actually try to solve? What directory do I start working in? What files do I need to create or edit? Am I missing something important or is my syntax just off?_ I had no idea where to begin..

## Create Actionable Tasks in a Linear Fashion

Later down the road, we created acceptance criteria and actionable tasks from the user stories that were given. We broke it down into bite-sized, consumable pieces that could be easily completed.

```javascript
User Story
As a new patient, I should be able to confirm a referral that was emailed to me.

Tasks
 Create static page
 Create route /invite/referral/:referral_id
 Create view Displays the following fields:
 Title (Referal #XYZ)
 Created By (Referrer Lab Name)
 Created For (Patient Name)
 Patient Email
 Patient Phone Number
 Actionable Tasks
 Can edit the patient information (Form)
 First Name
 Last Name
 Email
 Phone
 Setup password
 Logs in user upon acceptance
 Can accept the invitation
 "Accept Referral and Create Account" Button
Acceptance Criteria
As a developer, I should be able to hit /invite/referal/1 and see a static page with the information for the referrer and patient on that page. There should be a form with the fields filled in and I should be able to edit those fields.

Referrals that have been accepted should not be viewable.

This does not include saving or plumbing hookup to the referral creation.
```

I instantly felt more comfortable. I had direction now. I knew what to do and how to do it. I knew what tasks to focus on and every time I finished one, I could mark the checkbox and move on to the next task. _I felt capable and accomplished._ My productivity was now visible and tangible.

## Streamline Productivity with a Weekly Agenda

Working in a perpetual and endless cycle of tasks for your project might work well for some people, but I found it much more rewarding and productive when I created a weekly agenda. Something that helped me a lot with this was [**Notion**](https://www.notion.so/)**.**

![Notion page](https://res.cloudinary.com/echobind/image/upload/v1661872637/echobind_blog/owkqpecin9v0ahuagyu8.png)

My agenda for this week created in Notion 📔

> _Notion is a workspace that allows for collaboration between everybody you include in your organization. You can create tables, to-dos, lists, and even project boards. You can share notes and documents, @mention team members, and add comments to anything. It’s sort of like a wiki for your organization._

It allowed for me and my mentor to create weekly agendas and notes together. I found myself using it more and more as the weeks went on. I love using it as an agenda/planner, for jotting down quick notes and for collaborating on documents — but most importantly, I just _really_ enjoy clicking checkboxes.

After a few weeks of working through my agenda, I realized a couple of things that were effective and left me feeling triumphant by the end of the week.

### 📚 Stack up your tasks near the beginning of the week

Try to fill up the beginning of the week with a good amount of tasks. You want to try to taper them so that the end of your week looks sort of bare. This will allow you to stay agile and move some of your work downstream if they took longer than expected.

### ☝ ️Keep important tasks near the top

Organize your days’ tasks so that the ones with higher priority are at the top. You’ll be able to focus on work that matters the most and get that done before looking at easier ones. It’ll also allow you to spend your energy on harder projects at the start of the day before tapering into easier tasks as the day goes on.

### ⏰ Time-box your tasks

Making deadlines and arbitrary time limits create a session where you’ll say _‘Hey, I need to lock down and focus so that I can get this done by this time’._ Finish what you can within your time constraints and move on to the next thing.

An added benefit is that it allows you to mix-up your work for the day, so if you have other projects, you can focus on those. You can switch to a different project and use a different part of your brain so that you don’t get burned out working on the same problem for hours.

## Closing Words

Sometimes, it’s hard to think about where to start when you get assigned a new project. There are a lot of variables you have to consider: _what does this project aim to do? How can I execute it efficiently? What are the first steps?_

Hopefully, you can see how sitting down, compiling your thoughts, and organizing your tasks can help you accomplish your objectives. Planning it all out creates a visual roadmap and pipeline that you can easily follow.

Planning things out like this might not work for everybody, but it worked really well for me. If you find yourself struggling with productivity, I would suggest you try mapping out your goals and tasks. You’ll feel very accomplished when all those empty checkboxes become filled! 💪

---

[View on echobind.com](https://echobind.com/post/productive-performance-for-engineers)

---

# Essential Customizations for VSCode

> Jun 13, 2018 | I have listed — what I think to be — essential tools and extensions for VSCode.

_By Jeffrey Zhen · 2018-06-13_

For the past few years, I have been using [**Atom**](https://atom.io/) as my code editor, but I recently noticed a surge of developers using [**VSCode**](https://code.visualstudio.com/). Just last week, I started my new role here at [**Echobind**](https://echobind.com/), so I thought it would be a great chance for me to try out a new editor.

> _I was hesitant to adopt VSCode at first — I still haven’t forgiven Microsoft for that gosh-darned Clippy. Much to my surprise, I actually found the code editor quite wonderful and pleasant. It incorporates IntelliSense, has built-in Git with an integrated terminal, and an array of debugging tools. I really suggest you give the editor a chance if you haven’t already (the software is even_ [_open-sourced_](https://github.com/Microsoft/vscode)_)!_

I’m very particular with my code editors and I like to have light-weight extensions that increase my _productivity_. I have listed — what I think to be — essential tools and extensions for VSCode.

## Font

![JavaScript code](https://res.cloudinary.com/echobind/image/upload/v1661874049/echobind_blog/cuwtuw945bdypy0baznu.png)

Input: Deja Vu/Menlo

Programming is a lot more reading than writing, so you will want to have a font that is very legible. I like to use the [**Input**](http://input.fontbureau.com/) font with Deja Vu / Menlo style. The font is very customizable; you can choose different variations of a, g, i, 0, {}, etc. **It is important to choose a font that can easily differentiate between similar looking characters (e.g. i vs j, 1 vs l vs I, O vs 0).**

> _Another cool alternative is_ [**_Fira Code_**](https://github.com/tonsky/FiraCode) _(recommended by my colleague_ [Dave Wasmer](https://medium.com/u/a6592f574c42?source=post%5Fpage-----ff4c5e3889d7-----------------------------------)). The font has awesome programming ligatures for greater-than, less-than, not-equal-to, arrows, etc.

### Install the font to your computer

On Mac, download and double-click the .ttf files to open Font Book. You will then be prompted with the installer dialogue for the font.

#### Add the font to VSCode

I like the way VSCode has you edit your settings. On the left side, you have a read-only section of the editor’s default settings. On the right side, you can change whatever properties you like. If in the future, you wanted to change a property, you could quickly find it on the right side without having to rescan through a large list of settings — like you would in other editors.

Now in VSCode access **User Settings** by clicking the gear on the bottom left, and then to the ‘Settings’ section in the menu.

![Visual Studio Code User Settings](https://res.cloudinary.com/echobind/image/upload/v1661874366/echobind_blog/gs2atmtuw10fadeqwm9w.png)

This left-side portion of settings is read-only

On the right side of the screen, place ‘Input’ at the very front of the string of font families. This will ensure that the Input font gets loaded first.

![Visual Studio Code User Settings](https://res.cloudinary.com/echobind/image/upload/v1661874834/echobind_blog/fsueqwnwmuqw9jtv88tm.png)

This is the right-side portion of settings (where you can edit)

> _Protip from_ [Dave Wasmer](https://medium.com/u/a6592f574c42?source=post%5Fpage-----ff4c5e3889d7-----------------------------------): _If you hover over the read-only property on the left, an “edit” pencil icon appears in the editor gutter. Click it, and it shows the available options for that value in a menu. If you select one from the menu, it edits your config on the right to reflect that choice._

## VSCode Icons

![Visual Studio Code](https://res.cloudinary.com/echobind/image/upload/v1661873307/echobind_blog/m2zbep9qvf6z6ycdd1mu.gif)

[vscode-icons](https://marketplace.visualstudio.com/items?itemName=robertohuertasm.vscode-icons)

By default, VSCode does not have any icons in the explorer. [**VSCode Icons**](https://marketplace.visualstudio.com/items?itemName=robertohuertasm.vscode-icons) help by easily identifying what type of files you have in your projects. I also like the look of a folder icon over the small arrows that VSCode defaults to.

## Syntax Highlighting — Babel

![React code in Visual Studio Code](https://res.cloudinary.com/echobind/image/upload/v1661874639/echobind_blog/ydt4sgluwwyffihzjx3y.png)

[vscode-language-babel](https://marketplace.visualstudio.com/items?itemName=mgmcdermott.vscode-language-babel)

Syntax highlighting is very important as it helps your eyes discern between keywords and variables. Since I do most of my work in JavaScript, I like to use [**Babel JavaScript**](https://marketplace.visualstudio.com/items?itemName=mgmcdermott.vscode-language-babel) as it includes up-to-date ECMA, React JSX, and GraphQL highlights. I think syntax highlighting is a **must-have**, so download and install any other similar extensions for languages that you use frequently.

## Bracket Pair Colorizer

![Bracket Pair Colorizer](https://res.cloudinary.com/echobind/image/upload/v1661874646/echobind_blog/co71ys3g6vkipqbrd7xr.png)

[bracket-pair-colorizer](https://marketplace.visualstudio.com/items?itemName=CoenraadS.bracket-pair-colorizer-2)

I work a lot in JavaScript, so I see a lot of parentheses and curly brackets. By default, VSCode has subtle lines that match brackets vertically, but [**Bracket Pair Colorizer**](https://marketplace.visualstudio.com/items?itemName=CoenraadS.bracket-pair-colorizer-2) can improve on that further. The extension rotates through a set of bright colors to help make code blocks easily discernible and pleasing to the eye.

## ESLint

![EsLint running in Visual Studio Code](https://res.cloudinary.com/echobind/image/upload/v1661874654/echobind_blog/ppat2ywq71ybb8ukwz60.gif)

[vscode-eslint](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint)

[**ESLint**](http://eslint%20is%20a%20javascript%20linter.%20a%20linter%20is%20a%20program%20that%20not%20only%20helps%20with%20styling%2C%20but%20can%20also%20help%20with%20best%20practices%20and%20avoiding%20errors./) is a JavaScript linter. A linter is a program that not only helps with styling, but can also help with best practices and avoiding errors.

> _Stay tuned! I will have an article up about how to setup_ [**_ESLint_**](https://eslint.org/) _concurrently with_ [**_Prettier_**](https://prettier.io/) _in VSCode soon._

> **_UPDATE:_** _Check out_ [**_my article_**](https://echobind.com/post/integrating-prettier-eslint-airbnb-style-guide-in-vscode) _on how to integrate them in VSCode!_

### Honorable Mention: Quit Control

![Quit Control running in Visual Studio Code](https://res.cloudinary.com/echobind/image/upload/v1661873192/echobind_blog/ozgoxa6j6icdbbxoz20t.gif)

[quitcontrol-vscode](https://marketplace.visualstudio.com/items?itemName=artdiniz.quitcontrol-vscode)

I downloaded this extension after I got sick of constantly quitting out of my editor accidentally (I spam ⌘+W and ⌘+Q a lot). When [**Quit Control**](https://marketplace.visualstudio.com/items?itemName=artdiniz.quitcontrol-vscode) is enabled, it will prompt you if you really want to quit/close a window. Just hit enter when prompted to actually quit/close the window.

🎉 That’s it! 🎉

These are the essential tools and extensions I try to setup when I work in a new editor. I hope your productivity skyrockets after installing these tools! Please let me know if you have any other extensions that you think are essential for development.

Happy coding! 😺

---

[View on echobind.com](https://echobind.com/post/essential-customizations-for-vscode)

---

# Improve Developer Productivity with Generators and Team Conventions

> May 08, 2018 | This post summarizes 2 recent talks. The ideas presented here use React as an example context but can apply to any project.

_By Chris Ball · 2018-05-08_

Team conventions and the tooling to enforce them can often be an afterthought on projects. Deciding on conventions for your team takes collaboration and time. Adding the required tooling to enforce them takes more time, so it tends to be something we avoid.

I recently gave two talks digging into this subject and the benefits of actually taking that time. The first was a lightning talk for [Portland ReactJS](https://speakerdeck.com/cball/boosting-team-productivity-with-clis) and the second was a full-length talk for [Boston ReactJS](https://speakerdeck.com/cball/team-productivity-plus-plus-with-conventions-and-clis). This post summarizes those talks. The ideas presented here use React as an example context, but can apply to any project.

## A familiar song and dance

When starting a new feature in a React app, we often start by creating a new component. But before any code is written, you need to think through a few things.

1. What is the proper folder structure?
2. Do I camel-case or title-case the file?
3. Where should I put styles and how are they imported?
4. Where do I put tests and how are they named?

To give a more concrete example, say your team has decided to create your app in a feature-based folder structure. In order to create a `Select` component, you need to create 3 (or more) files depending on how your team has decided to split things out.

![Select component with four files](https://res.cloudinary.com/echobind/image/upload/v1661874243/echobind_blog/jiuaoa6wohunesoelitb.png)

A feature-based folder structure

Even though creating these files is not complicated, think about how many actions you need to perform every single time you create a component using the structure above. You need to:

1. Create a new folder with the name titleized.
2. Create a component file with the name titleized. Copy and paste component content from another file.
3. Create an `index.js` file that imports the component file.
4. Create a styles file. Copy and paste the basic style layout.
5. Create a stories file with the name titleized. Copy and paste story content from another file.

Sound like something to automate? Sure does. **We’ll come back to that.**

### Code Reviews

Let’s say you finish the implementation of the component, and open a Pull Request. You might encounter feedback like the following:

“Can you add a test for this?”

“Actually, this is the old way we did this. Check out .”

Sound familiar? It probably does. This happens a lot.

## What’s the problem?

Who (or what) is the source of truth for the way your team creates files? What about the way you write code? Often, this knowledge resides entirely in someone’s head or is non-existent. People tend to copy a file and follow the patterns established within it, but that pattern might not be the latest one. Even worse, it might be a bad example.

Developers work hard to not repeat ourselves in code but we often fail to apply that concept to our daily workflows. If you need to constantly calculate averages of a set of numbers, you might want to make a spreadsheet. Likewise, if you’re continually creating files that follow similar patterns you should look at ways to automate it.

## Boilerplates and Starter kits

The React community has the concept of Boilerplates and Starter kits to help developers get started quickly. Most of them include a CLI to help you generate new files. The official React website even [maintains a list](https://reactjs.org/community/courses.html).

The potential problem with these, is that they include a set of conventions. Libraries like `styled-components` or `Redux` or a certain folder structure. These conventions might work for you initially, but as your project evolves they may not.

![To eat or not to eat sign](https://res.cloudinary.com/echobind/image/upload/v1661872861/echobind_blog/at63ryktku5qpdnnxuty.png)

You probably don’t want to fork.

When your team decides to take a different approach from a Boilerplate or starter kit, you’re faced with an important decision. Should you fork the project? If you do, just remember:

> _If you fork a project you are now a maintainer and must keep it up-to-date._

![Yeah that's not gonna happen image](https://res.cloudinary.com/echobind/image/upload/v1661872868/echobind_blog/ber0q5zfip1udab2gowl.png)

## A trend towards flexible conventions

Frontend development is constantly evolving, and some of the more recent changes are focused on “Zero Config”. But alongside this is a realization that the conventions included in these libraries need to be configurable as teams and projects evolve. A good example of this is [Create React App](https://github.com/facebook/create-react-app) and [react-app-rewired](https://github.com/timarney/react-app-rewired).

I’d like you think about **creating conventions for your team**. You’ll likely start from past projects or open source examples, just make sure you’ve had some group discussion and can confidently say “this is how we do things”.

Think about folder structure, file naming, and the way you write the code within the file. Perhaps you want to generate a failing test to enforce actually writing them.

Once you have established patterns, you can determine how to template and automate them.

## Why?

Generating files using a specified convention saves time, keystrokes, and clicks. But you also save something much more important.

### Decision Fatigue (also known as Cognitive Depletion)

Don’t waste time on low value choices. Yehuda Katz gave a great [keynote at Railsconf](https://youtu.be/9naDS3r4MbY?t=4m27shttps://youtu.be/9naDS3r4MbY?t=4m27s) years ago that illustrates this point well. To sum it up, you can only make a certain number of decisions per day. Think of your ability to make decisions as a cup — you can fill it with many small decisions or a few large ones, but once it’s full, you’re done for the day.

This phenomenon does not only occur in programming. It can happen in any profession that needs to make frequent decisions every day. The best way to make it easier on yourself is to try to reduce the number of decisions you have to make however you can.

![Barack Obama smiling in White House on left, Steve Jobs holding computer in the middle and Mark Zuckerberg](https://res.cloudinary.com/echobind/image/upload/v1661874776/echobind_blog/h3phtqijlr729jjxwbyu.jpg)

An easy way to reduce decision fatigue? Wear the same outfit every day.

### Developer Experience

The other major reason to leverage generators and form explicit team conventions is for a better developer experience. Your team does this stuff every day, so why not make it as frictionless and enjoyable as possible?

Here are a few of the many benefits you’ll get by taking this approach:

* No more copy and paste when creating new files
* Automatically ensure that everyone is doing things “the new way”.
* Simplify the onboarding of new developers
* Automating anything makes developers happy

## How

Sound like a win all around? Let’s look at a few ways to implement this approach. You will want to use a CLI to generate files for you, but make sure its easily customizable. Our favorite is [Hygen](http://www.hygen.io/).

![Hygen](https://res.cloudinary.com/echobind/image/upload/v1661874395/echobind_blog/i7dsc6mqi5phnfw5snwg.png)

www.hygen.io

### Getting Started

First, set up Hygen. The following examples show how to use Hygen to generate files for a React app, but Hygen can be used for plain JavaScript, static sites, and many other cases where you need to generate files.

```javascript
$ brew tap jondot/tap
$ brew install hygen
```

In your project folder, initialize it:

```javascript
hygen init self
hygen generator new --name component
```

Hygen will generate some files you can use as reference. We’ll add a few files to `_templates/components/new` to reflect the folder structure mentioned previously.

```javascript
---
to: src/components/<%= h.inflection.classify(name) %>/<%= h.inflection.classify(name) %>.js
---
<% classified = h.inflection.classify(name) -%>
import React from 'react';
import styles from './styles';
const <%= classified %> = () => (
  <div>Hello</div>
);
export default <%= classified %>;
```

```javascript
---
to: src/components/<%= h.inflection.classify(name) %>/index.js
---
<% classified = h.inflection.classify(name) -%>
export { default } from './<%= classified %>';
```

```javascript
---
to: src/components/<%= h.inflection.classify(name) %>/styles.js
---
<% classified = h.inflection.classify(name) -%>
import { css } from 'react-emotion';
import { colors } from '../../styles';
import { mediaQuery } from '../../styles/breakpoints';

export default {
  container: css`
    margin-top: 0;
    color: ${colors.black};

    ${mediaQuery.medium(css`
      color: ${colors.green};
    `)}
  `
}
```

```javascript
---
to: src/components/<%= h.inflection.classify(name) %>/stories.js
---
<% classified = h.inflection.classify(name) -%>
// @flow
import React from 'react';
import { storiesOf } from '@storybook/react';
import { withInfo } from '@storybook/addon-info';
import <%= classified %> from './<%= classified %>';

const stories = storiesOf('<%= classified %>', module);

stories.add(
  'Default',
  withInfo(`
    # <%= classified %> Component
    This component does something, you should probably change this.
  `)(() => <<%= classified %> />),
);
```

Want to get fancy? Prompt users if they want a functional or stateful component and generate accordingly:

```javascript
---
to: src/components/<%= h.inflection.classify(name) %>/<%= h.inflection.classify(name) %>.js
---
<% classified = h.inflection.classify(name) -%>
<% if(componentType === 'functional'){ -%>
import React from 'react';
import styles from './styles';
const <%= classified %> = () => (
  <div classname={styles.container} />;
)
<% } -%>
<% if(componentType === 'stateful'){ -%>
import React, { Component } from 'react';
import styles from './styles';
class <%= classified %> extends Component {
  state = {}
  
  render() {
    return (
      <div className={styles.container} />
    );
  }
}
<% } -%>

export default <%= classified %>;
```

```javascript
module.exports = [
  {
    type: 'list',
    name: 'componentType',
    message: 'Functional or Stateful?',
    choices: ['functional', 'stateful'],
    default: 'functional'
];
```

Want some starter templates that do this? Check out [hygen-CRA](https://github.com/jondot/hygen-CRA).

### Alternatives

If you don’t think Hygen is right for you, try [Plop](https://plopjs.com/) or [Yeoman](http://yeoman.io/). Before we switched to Hygen, we even [rolled our own](https://github.com/echobind/launchbox).

The tool you use isn’t important, but the process is.

### When things change

Regardless of the tool you choose, we’ve found co-locating generator templates with project code is best. When team preferences change, your generators can evolve right alongside them.

For example, say your team adopts [TypeScript](https://www.typescriptlang.org/). The developer adding TypeScript support can simply update the generator templates to use TypeScript in the same Pull Request and everyone will generate TypeScript components going forward.

## Productivity for the win

Find and extract conventions for your team by taking note of repetitive patterns. Note that conventions may differ from project to project or team to team within a company. That’s fine!

> Eliminate low value choices and **focus on the implementation details**.

We’ve really loved the productivity boost that customizable generators have given us and the teams we’ve worked with. Next to updating a READMEor adding [PR templates](https://github.com/echobind/pr-templates), it’s often one of our first contributions to a project. If you want to chat with us about this approach or want us to help you implement it for your team, [say hi](https://echobind.com/contact)!

---

[View on echobind.com](https://echobind.com/post/improve-developer-productivity-with-generators-and-team-conventions)

---

# GDPR Compliance For App Developers

> Apr 28, 2018 | General Data Protection Regulation (GDPR) is an EU law framing the legal bounds of personal data and privacy and went into effect on May 25, 2018.

_By Michael Yared · 2018-04-28_

General Data Protection Regulation (GDPR) is an EU law framing the legal bounds of personal data and privacy and goes into effect on May 25, 2018.

## Why it matters

Foreign companies outside the EU are required to adhere to the regulations when processing personal data involving EU residents. As a result, many see GDPR as a new standard for apps serving a global audience.

Thanks to massive breaches of trust at [Yahoo](https://en.wikipedia.org/wiki/Yahoo!%5Fdata%5Fbreaches#July%5F2016%5Fdiscovery), [Facebook](https://en.wikipedia.org/wiki/Facebook%E2%80%93Cambridge%5FAnalytica%5Fdata%5Fscandal) and [Sony](https://en.wikipedia.org/wiki/Sony%5FPictures%5Fhack), officials and politicians all over the world are taking note. Personal privacy is becoming a staple in mainstream current events.

## What developers need to know

In the last six months, we’ve been told multiple times that budget has been allocated for a project specifically to prevent an [embarrassment on the scale of Equifax](https://en.wikipedia.org/wiki/Equifax#May%E2%80%93July%5F2017%5Fdata%5Fbreach). Our team is auditing existing applications, upgrading or phasing out legacy apps, crafting rules to automatically purge data, and creating new utilities that give users the ability to request and update their information.

The best advice we can give is something we’ve said before on this blog. Companies should anonymize data because [you can’t lose what you don’t have](https://echobind.com/post/understanding-hipaa-compliance-for-apps). Collect and secure the personal data you need, stop asking for data that isn’t of value, and anonymize your data before using it for secondary purposes such as analytics or logs.

## Important action items

Your app is likely in good shape if you feel good about the following action items.

1. **Know what data you have and where you keep it.** Data finds its way outside of databases easily. It’s important that your developers have a map of the sensitive fields in your database schema.
2. **Ensure your data is safeguarded to the best of your company’s ability.** This is a tough one even for large companies. If you expose an API, audit the permissions and write tests to ensure sensitive data requires authentication.
3. **Give your users the ability to request, edit or purge their personal information.** This is both a GDPR requirement and an opportunity to think about how you securely send and remove user data.
4. **Keep your internal and external teams up-to-date through trainings.** If you don’t have a formal training, start with a lunch and learn where your team can ask questions.

One resource we’ve been sharing with clients is [GDPRchecklist.io](https://gdprchecklist.io/), a checklist put together by the folks at [Knowlex](https://www.knowlex.be/). The checklist summarizes top level considerations and links to the full text of the corresponding law.

[Contact us](https://echobind.com/contact) with your compliance questions. We’re happy to hop on a call to answer quick questions. And if you’d like a formal audit, our team will analyze your code and provide a recommendations document with actionable steps to improve your app.

---

[View on echobind.com](https://echobind.com/post/gdpr-compliance-for-app-developers)

---

# The Secret Art of Effective Developer Mentorship

> Apr 26, 2018 | Developer mentorship isn’t so much about transferring technical information as it is building a supportive relationship.

_By Ryan Atkinson · 2018-04-26_

These people are doing kung-fu, not developing software.

![a gif of two people practing kung fu](https://res.cloudinary.com/echobind/image/upload/v1661874063/echobind_blog/jozafg9p55mbqtfxf8q7.gif)

Developer mentorship has become an afterthought in the tech world. Project budgets are tight, and senior dev hours ain’t cheap. Besides, developers like to learn in their free time. Couldn’t they just teach themselves? While it’s true that there are countless coding education resources available online these days, teaching coding patterns was never what mentorship was about to begin with. Or at least not what I see as its significance today.

Developer mentorship isn’t so much about transferring technical information as it is building a supportive relationship. I’ll say that word again: relationship.

> _Relationships are the essence of mentorship._

Junior developers experience a myriad of perfectly normal feelings such as inadequacy and self-doubt. A good mentor doesn’t solve their problems for them, but gives them the reassurance they need to solve them on their own. Maybe even an occasional breadcrumb of a solution. But when it comes to PR review time, they don’t hold anything back. 🔥

The key is that when junior developers inevitably find themselves in the weeds, a mentor doesn’t come with a weed-wacker, he comes with a glass of lemonade.

So how does one become this coding saint you’ve described?
‍
Well, 5 Tips:

1. **_Sacrifice your own time to mentor others; don’t rely on project management to allocate explicit mentorship time._**
2. **_Always assume junior developers knows less than they say. We all have a tendency to say “I know” even when we don’t. In general, be overly communicative._**
3. **_Transparency. Be honest when you don’t know something yourself, and share your own failures. Share your honest viewpoints. Share all of your development habits without reserve._**
4. **_Focus on the relationship more than the task. “How are you”, not “how’s the project”? Let them know that they aren’t alone, no matter where they’re at._**
5. **_Challenge them but don’t torture them. Calm seas never made a skilled sailor, but we don’t need anyone drowning. It’s OK to intervene with some coding help if they are legitimately in over their heads._**

I have firsthand experience with this formula, and I have seen its benefits. I have even made friends that transcended roles at work and ultimately became a local network of supportive co-developers. As my first mentor once said, “Be the change you want to see.” …Okay, Ghandi said it too.

I hope some of this article resonates with you. Reach out to me directly and let me know how you’ve been able to incorporate these tips into your mentorship efforts!

---

[View on echobind.com](https://echobind.com/post/the-secret-art-of-effective-developer-mentorship)

---

# Thanks for 2017!

> Jan 09, 2018 | 2017 was a great year for Echobind! You may have heard us classify last year as an investment year, but it was so much more than that.

_By Chris Ball · 2018-01-09_

2017 was a great year for Echobind! You may have heard us classify last year as an investment year, but it was so much more than that. We solidified the foundation of our company by taking some time away from consulting work to improve our processes. That investment allows us to do better work more efficiently. We’re excited about Echobind’s direction and have some announcements below, but let’s first start with a recap of 2017.

## A look back on the year

![Chris Ball laughing with co-worker](https://res.cloudinary.com/echobind/image/upload/v1661873681/echobind_blog/txokuvs44zcq9gkvktu2.jpg)

The majority of last year’s business included a good mix of team augmentation, greenfield projects and code audits. Four of our top five revenue generating clients were from the healthcare space. With years of developing medical and life science applications, healthcare continues to be a sweet spot for our team. Here are a some of the projects we had a hand in:

* Lead the charge on multiple Elixir projects for one of our largest clients
* Helped upgrade, build features, and later simplify several large Ember and Ruby on Rails applications
* Developed and executed a plan to migrate a patient database from MSSQL to Postgres allowing the consuming applications to reduce external dependencies
* Brought balance to a company with a large dev team during employee transitions
* Helped a healthcare startup scope out an application to replace their manual processes with a small application that is built to grow alongside their business
* Built a highly customized lead management system to delegate and incentivize resellers to _treat their leads like gold_ as future leads are predicated on positive user actions
* Created and launched our first react native application early last year
* Audited the codebase of a company that one of our clients was interesting in acquiring
* Audited existing mobile apps before embarking on a rewrite in React Native

## What our clients said about us

![Chris Ball and Sarah Case at client meeting](https://res.cloudinary.com/echobind/image/upload/v1661872724/echobind_blog/hrw84zkiyhsfcud0wmbb.jpg)

A day of user stories in Boston, MA.

We made an effort to better collect feedback throughout the project. We’re not just surveying new clients. We’re reaching out to long term clients to ensure they’re as happy with us now as they were when we started. It’s been valuable to have a constant pulse on [our partnerships](https://echobind.com/post/working-together). Many of these learnings have found their way back into [our corporate checklists](https://echobind.com/post/10-questions-to-ask-around-safeguarding-patient-data). A Healthcare organization that we worked with for a second time said this about our standards:

> _“The results exceeded my expectations. We wanted to maintain certain high standards of code and at the same time do a robust amount of testing. They created a big part of the application from scratch, proving to have a good understanding of the frameworks and the languages they were working with.”_

An Educational company that we’ve worked with over multiple years said:

> _“I’ve had people look at the code, and they’ve been blown away by its quality. There are standards for working with and building an application like ours, and Echobind has gone above-and-beyond.”_

Finally, a life sciences company that we’ve work with on and off again over the last two years wrote:

> _“They’re accountable and there’s not much handholding in the sense of getting Echobind up to speed. They’re experts in their domain, so we got the team up-and-running in our environment quickly. Echobind was responsive and understood our goals and deadlines. They were accurate in terms of estimates, so we didn’t require a long planning phase.”_

## Expanding our team

![Michael Yared and Dave Wasmer at lunch](https://res.cloudinary.com/echobind/image/upload/v1661872731/echobind_blog/hnd0v1w2onydalcqb95u.jpg)

We welcomed Dave Wasmer to our team in July. Dave brought an expertise in design, UX, Ember, and Node to Echobind. Having additional UX and design capabilities in house has proven to benefit our clients even if they’re not specifically contracting us for that purpose. We’ll continue to expand upon those capabilities this year.

We’ve also reorganized how we lead accounts. Every account, regardless of size, has the full braintrust of our entire agency. We achieve this by having both client and agency advocates assigned on each team. This ensures that our project managers and development team discuss estimates and critical decisions before a solution is decided upon. We dedicate time each week to review these lessons agency wide.

## Building community

![Chris Ball giving a speech](https://res.cloudinary.com/echobind/image/upload/v1661872969/echobind_blog/q5cijfhhhnpe8t5nid4a.jpg)

Chris Ball at a Boston Ember meetup.

Conferences and community are really important to us. We continued to be a part of key conferences and meetups in the communities we’re involved with.

We sponsored two conferences in 2017:

* [EmberConf](http://emberconf.com/)
* [Chain React](https://cr.infinite.red/)

Our team members spoke at four conferences:

* [ElixirConf](https://elixirconf.com/)
* [Elixir with Love](https://www.elixir-with-love.com/)
* [BEAM Camp](http://www.beamcamp.io/2017)
* [Chain React](https://infinite.red/ChainReactConf)

We attended three other conferences:

* [OpsConf](https://www.ops-conf.com/)
* [Lonestar Elixir](http://lonestarelixir.com/)
* [Erlang and Elixir Factory](http://www.erlang-factory.com/)

We also gave talks, sponsored, and helped organize the following meetups:

* Boston Ember
* React Native Boston
* Boston Elixir
* Elixir Louisville
* Ember.js Denver

We plan to attend, speak, and sponsor even more conferences in 2018.

## Building Content

![Robert Beene speaking at ElixirConf](https://res.cloudinary.com/echobind/image/upload/v1661872976/echobind_blog/n1q8qulfpgrarnibsqvt.jpg)

Robert Beene at Lonestar ElixirConf in Austin, TX.

Our team wrote on a variety of topics last year. This year, you can expect more of the same with some additional formats making their way into the mix. Here are a few of our top articles from last year in case you missed them:

* [Betting on React Native](https://echobind.com/post/betting-on-react-native)
* Composable Queries with Ecto
* [Headless Browser testing with CircleCI 2.0](https://echobind.com/post/headless-browser-testing-with-circleci-2-0)
* [Understanding HIPAA Compliance for Apps](https://echobind.com/post/understanding-hipaa-compliance-for-apps)
* [Pressure Indicating UI](https://echobind.com/post/pressure-indicating-ui)

## Agency Partnerships

![Chris Ball and Michael Yared on ski lift](https://res.cloudinary.com/echobind/image/upload/v1661874690/echobind_blog/wmans8i6m7dde7bgo5th.jpg)

Chris Ball and Michael Yared meeting 9,000' high in Breckenridge, CO.

We’ve always viewed other agencies as potential partners and friends. This year, we met a lot of great agencies and had the opportunity to work with a handful. One worth calling out are the fine folks at Adorable. We look forward to helping each other build great companies in 2018!

## Kicking off the new year 🚀

To start, we’re diversifying our company focus. We’ve identified opportunities to reduce cost and risk for our clients, and we’re excited to package and share our solutions. In 2018, we are dedicating resources toward developing agency products that serve the needs of our client base. Our goal is to build a suite of long-term products that create value for Echobind. Chris Ball’s primary focus will be leading the product business.

Our consulting business will continue to get the lion share of our attention and resources. We’re growing our team to support new clients and broaden our expertise. As we’ve always done, we’ll continue to invest in employee growth and support our communities through mentorship and open source initiatives. Michael Yared’s primary focus will be leading the consulting business.

**We’re thrilled for 2018**, so [send us a note](https://echobind.com/contact) if your company is looking to develop custom software or you just want to chat. We’re always available to bounce ideas off of and explain how we approach problems.

Happy New Year from Team Echobind!

---

[View on echobind.com](https://echobind.com/post/thanks-for-2017)

---

# How to Engage a Community

> Dec 29, 2017 | With Elixir now in its sixth year (albeit with decades of Erlang behind it), it should be no surprise that the train keeps on chugging.

_By Robert Beene · 2017-12-29_

With [Elixir](http://elixir-lang.github.io/) now in its sixth year (albeit with decades of Erlang behind it), it should be no surprise that the train keeps on chugging. From the increasing list of [Meetup](https://meetup.com/) groups to the number of Elixir conferences, it’s clear that this community is engaged and growing.

There are now over [200 Elixir meetups](https://www.meetup.com/topics/elixir/) worldwide.

![World map with markers](https://res.cloudinary.com/echobind/image/upload/v1661873998/echobind_blog/i3qzeegbaokmrzhbgyqm.png)

Elixir Meetups (<https://www.meetup.com/topics/elixir/>)

In 2014, there was one Elixir conference.

In 2015, there were two Elixir conferences.

In 2016, the list grew to six.

In 2017, the community supported seven Elixir-specific conferences. Erlang Factory changed their name to Erlang and Elixir Factory — reflecting the growing presence of the Elixir community.

![Elixir Conference](https://res.cloudinary.com/echobind/image/upload/v1661874387/echobind_blog/revayxqhifxf4q3tqdaj.jpg)

ElixirConf 2017

Every year has been a year of growth as Elixir continues to make an appearance on lists of languages to learn in the new year. If you’ve been sitting on the outskirts of the community thinking about diving in, we can’t recommend it enough.

**There are so many ways to take part in 2018.**

From chatting on [Slack](https://elixir-slackin.herokuapp.com/) to meeting in-person at meetups and conferences, we all have an opportunity to be an active participant.

You could give a talk at your local meetup. You could answer questions on the [community Slack](https://elixir-slackin.herokuapp.com/). You could give a talk at one of the several conferences. It all can start by writing a blog article about Elixir.

In 2017, Echobind increased the time and resources put into Elixir. The majority of our APIs are now built on this platform. We attended four of the major Elixir conferences — speaking at [ElixirConf](https://www.youtube.com/watch?v=ENolm5T0bkU&t=5s) and [Elixir with Love](https://www.elixir-with-love.com/). We have written a number of blog posts on Elixir and given talks at meetups as well. We’re happy to be organizers of Elixir meetups in [Boston](https://www.meetup.com/Boston-Elixir/) and [Louisville, KY](https://www.meetup.com/Elixir-Louisville/).

In 2018, we’ll continue doing more of the same. We’ll also be doing a webinar on Elixir deployments — _Beyond Heroku: Deploying your Phoenix Application_.

How will you engage the community in 2018?

---

[View on echobind.com](https://echobind.com/post/how-to-engage-a-community)

---

# Happy Holidays

> Dec 20, 2017 | One of the real joys during the holidays is the opportunity to say thanks. Thanks to our clients, both past and present, for giving us the opportunity to collaborate with you.

_By Echobind Team · 2017-12-20_

‍One of the real joys during the holidays is the opportunity to say thanks. Thanks to our clients, both past and present, for giving us the opportunity to collaborate with you. Thanks to our partners who help make Echobind run at full throttle. And thanks to all of the friends we’ve made along the way.

We are sincerely grateful for your loyalty and goodwill throughout the year, and we hope 2018 is amazing for you. Have a wonderful holiday season!

And for those who were stuck…

![Red squiggly line with black background](https://res.cloudinary.com/echobind/image/upload/v1661874956/echobind_blog/idq4b9xylx6n3fshaa51.png)

---

[View on echobind.com](https://echobind.com/post/happy-holidays)

---

# Pressure Indicating UI

> Dec 19, 2017 | There are many ways to measure customer demand for a planned feature but all approaches have a common shortcoming.

_By Dave Wasmer · 2017-12-19_

> _“What feature should we build next?”_

It’s a common question from product owners, and it’s not always easy to answer. The feature backlog is a mile long — which one will give you the most bang for the buck? Which one do customers want the most?

There’s many ways to measure customer demand for a planned feature: user surveys, public voting, support feedback, social media. But all these approaches have a common shortcoming: they rely on users telling you what they want, rather than showing.

And the cardinal rule of user feedback:

> _“Everybody lies.”_

## Stated vs. revealed preferences

It’s tempting to rely on tools like surveys to gauge customer interest. It’s simple, direct, and obvious: just ask them what they want.

But users aren’t always consciously aware of what they want or able to clearly articulate what that is. As the apocryphal Henry Ford supposedly said:

> _“If I asked people what they wanted, they would have said a faster horse.”_

Economists refer to this phenomenon as “stated vs. revealed preferences”. It’s the idea that captures contradictory behavior, like when someone says they want to lose a few pounds, but goes back for a second helping of dessert. Their stated preference (to lose weight) is contradicted by their true, revealed preference (to eat dessert).

## Capture revealed preferences with “pressure indicators”

So revealed preferences help show us the customer’s true intent, but how do we figure out what that is? Since we can’t simply ask, we need to be creative.  
Let’s say you are building a CRM SaaS product that helps salespeople track leads and close opportunities. You’ve heard some requests from customers to include an in-app dialer that lets salespeople place phone calls directly from the app. How can we know if these requests are stated or true preferences?

Use **pressure indicating UI**.

What is a pressure indicator? It’s a UI element that helps capture user preference by allowing users to reveal it with intentional action. The simplest example might be something like this:

![User profile card](https://res.cloudinary.com/echobind/image/upload/v1661874301/echobind_blog/gmyu5sxa9vdzbanmybae.jpg)

The key is what happens when the user clicks on the “Call Frank” button: we fire off an analytics tracking event, and show a modal like this:

![Model informing user about error](https://res.cloudinary.com/echobind/image/upload/v1661873955/echobind_blog/tjazav2n7hw90ue58tjq.jpg)

Note that we didn’t build the full, complex feature of an in-app dialer. All we did here is add a button and a modal — a trivial effort by comparison.

The goal here is to sort out whether the in-app dialer is a feature that users _actually want_ vs. what they _think_ they want. By providing an avenue for users to express intent through their actions rather than their words, we can be far more confident that the results reflect reality.

Why are these called “pressure indicators”? Because the level of activity you see on something like the “Call Frank” button gives you a sense of the force of user preference behind it. If you add that button and are overwhelmed with users attempting to use it, it’s a strong indicator that lots of users are bumping into that particular boundary of your product’s feature set.

## Capturing more intent

In the above example, we captured the intent of the user to use the in-app dialer feature. This is a huge improvement over simply asking users if they want it — but we can do even better.

In that example, all we captured was binary intent: yes, they tried to use the feature, or no, they didn’t.

With a subtle tweak of the modal, we can capture more:

![Model with two buttons](https://res.cloudinary.com/echobind/image/upload/v1661873962/echobind_blog/bi3s1w3z7p8l1jvlnaaz.jpg)

By offering to notify users when the feature is ready, you get two important benefits:

1. **Stronger indicators**: by comparing the ratio of how many people clicked the “Call Frank” button vs how many signed up for notification, we can get a clearer sense of how many clicks were exploratory vs. earnestly attempting to use the feature.
2. **Feature launch marketing list**: anyone who signs up to be notified is sending a strong signal that they are deeply interested in this feature. You could craft a special email campaign targeting these users when the feature rolls out, aiming to convert them to customer evangelists.

## Avoiding User Frustration

Capturing revealed preferences is tricky, because users must think that they have a chance to use the feature — otherwise, you end up capturing stated preferences instead.

The risk here is user frustration — in our example above, if a user planned to call Frank through the app after seeing the button, they might get frustrated if they attempt to place the call via the apparent in-app dialer. Instead they are greeted with our modal and have to fumble to find the phone number and manually dial.

There is no simple rule for this, but in general, try to keep a few things in mind:

* **Bail early**: you want to let the user know the feature doesn’t exist yet **as soon as possible** in the process, so they don’t invest more time or mental effort than necessary going down a dead-end path.
* **Users may be busy**: be sure to think through scenarios where the user might be trying to use the feature in question, and make sure the pressure indicator UI doesn’t become disruptively misleading. For example, don’t show a “Rollback deploy” button on your Heroku competitor as a pressure indicator — no one wants to find out that feature isn’t finished in the middle of a bad deploy.
* **Only show existing users**: be careful not to use pressure indicating UI in marketing materials aimed at potential customers. You don’t want someone signing up thinking the feature is available, only to discover a bait-and-switch.

## Work smarter, not harder

Pressure indicating UI is all about approaching product design from an intentional, focused perspective. By understanding users’ true preferences, we can build the product they need that makes their lives better, with fewer false starts for our teams.

Want to chat more about how to add pressure indicating UI to your app, or product design in general? Feel free to reach out on [Twitter](http://twitter.com/echobind)!

---

[View on echobind.com](https://echobind.com/post/pressure-indicating-ui)

---

# 10 Questions to Ask Around Safeguarding Patient Data

> Dec 18, 2017 | Securing private data comes up every week at Echobind, safeguarding data is important whether the application is a monolith for a start-up or many microservices for a large manufacturer.

_By Michael Yared · 2017-12-18_

Securing private data comes up every week at Echobind. For us, this usually involves [safeguarding patient data](https://echobind.com/post/understanding-hipaa-compliance-for-apps), but it’s equally important whether the application we’re developing is a monolith for a start up or many microservices and third party integrations for a large manufacturer.

Most developers would look at these individual recommendations as common sense, but that’s exactly the problem. With so much to consider when developing a new app, it’s easy to focus on the hard problems and forget about the seemingly easy issues.

To combat this, we’ve invested time in creating internal checklists for our team. Our goal is to make sure our team consistently performs at a high level. When we encounter an issue that we haven’t seen before, we learn from it and our checklist becomes better.

Here’s ten questions that made it to our list this year. We feel all organizations looking to protect data should consider these when building a new application.

1. **How will users authenticate?** Are we leveraging a secure system that already exists today or building one from scratch?**‍**
2. **Can users enable two factor authentication?** Will certain applications enforce 2FA? Does 2FA have a backup scenario if email or SMS capabilities are offline?**‍**
3. **Are communications to users secure?** Do you know which columns in your database contain personal information? Is there a check to ensure your app isn’t leaking personally identifiable information?**‍**
4. **How many roles exist?** Are separate roles for users and administrators provided? Is the ability to add a new role after the application is developed challenging?**‍**
5. **How will data be entered into the system for the first time?** Will data need to be converted from another application?**‍**
6. **How are compliance events being tracked?** Is audit logging in place and tied to individuals accessing the system?**‍**
7. **Are application documents being shared?** Are we sharing the data flow diagram, the system architecture and any technical requirements with internal and external stakeholders? Does the diagram show when and where data is encrypted?**‍**
8. **Is there a written policy for handling, storing and disposing of private information?** Is a delete a soft or hard delete? What about social security numbers and other sensitive information? What do local laws stipulate regarding storing and archiving of data?**‍**
9. **How will future risk assessments take place?** Who is in charge of adding new features and maintaining security patches? Are individuals managing the system tested regularly for their adherence to compliance?**‍**
10. **Where will the application be hosted?** If a healthcare organization is hosting information offsite, is the hosting provider willing to sign a BAA?

If you considering building a new application or need help with one that’s in development, [shoot us a note](https://echobind.com/contact). We’re always happy to hop on the phone and talk through how we would tackle a challenge and our company process. 

***Learn more about Echobind's [Healthcare capabilities](https://echobind.com/industries/healthcare).***

---

[View on echobind.com](https://echobind.com/post/10-questions-to-ask-around-safeguarding-patient-data)

---

# The Graphcool Framework: A path to instant GraphQL greatness

> Nov 08, 2017 | Graphcool is a great service. We got a chance to put it through the paces on a recent React Native project, and we were impressed.

_By Chris Ball · 2017-11-08_

[Graphcool](https://graph.cool/) is a great service. We got a chance to put it through the paces on a recent React Native project, and I was impressed. Graphcool began as a GraphQL Backend-as-a-Service and recently released the (open source!) Graphcool Framework. The Graphcool Framework manages to bring an instant GraphQL backend to your local machine with minimal effort on your part. All you have to do is define the schema.

Running the Graphcool Framework locally enables you to easily manage your project and develop apps the way you’d develop anything else — using your favorite editor and git. When you’re ready to deploy, you can host the API yourself or use Graphcool’s hosted infrastructure.

Let’s take a look and see how easy it is to get going.

## Setup

1\. Install the graphcool cli: `npm install -g graphcool`. 2.Initialize a new Graphcool API. For smaller projects, it’s fine to use a subfolder in the main project. For larger projects, or projects that may have many different front-end clients, you’re better off using a separate git repo. In this example, we’re going to keep things separate.

![CLI of the setup for graphcool](https://res.cloudinary.com/echobind/image/upload/v1661873624/echobind_blog/ymd5liaapytucs2bgj1k.png)

When it’s done, initialize a new git repo & commit the changes.

`cd api`

`git init && git commit . -m “New Graphcool API"`

## Running Locally

Running Graphcool locally is optional, but doing so enables you to work anywhere: 🚂 ✈️ ⛺️ ⛱.

1. Make sure you have Docker installed. _Here’s a link for_ [_Mac_](https://www.docker.com/docker-mac)_. Other platforms are available under the “Get Docker” menu_. If you don’t have Docker yet, you’ll see this when trying to start your local environment:

![An example of graphcool local command](https://res.cloudinary.com/echobind/image/upload/v1661874430/echobind_blog/ctwjahemi5ltjkre6nug.png)

Oops, no Docker.

2\. Start your local Graphcool service using `graphcool local up`. This will download a few different Docker images, so make sure you’re not tethering to your phone.

![CLI UI of docker being set up](https://res.cloudinary.com/echobind/image/upload/v1661874697/echobind_blog/zzgil2cmvijmygtgpsio.png)

Installing local Graphcool Docker containers

3\. Deploy those changes to the container using `graphcool deploy`. Doing this the first time will prompt for your default target (typically `dev`).

It will also prompt you for the location to deploy. For staging & production you’ll likely choose one of the “Shared Cluster” options, but we’re going to **choose “local”**.

If asked for the service name, just keep the default (api in our case).

![CLI UI - Naming conventions as you deploy](https://res.cloudinary.com/echobind/image/upload/v1661872458/echobind_blog/a1ehvvqehegfrquxneyj.png)

A successful Graphcool deploy!

Not only did Graphcool Framework configure everything for us, we also have a new `User` type ready for use. Graphcool uses this schema information to build us a CRUD API automatically.

## Testing it out

If you’re not familiar with [GraphiQL](https://github.com/graphql/graphiql), it is an in-browser IDE for [GraphQL](http://graphql.org/) that allows you to inspect your schema and try out queries, mutations, and subscriptions. GraphiQL is built-in to Graphcool (it’s is called the playground internally).

Since GraphiQL knows about the entire schema, you get some pretty great autocomplete features. To open it up, just use `graphcool playground`.

Let’s make sure we can properly query `Users`:

![GraphQL UI showing a query](https://res.cloudinary.com/echobind/image/upload/v1661872465/echobind_blog/ea3l4npptnggtbjg8vqw.gif)

And create them:

![GraphQL UI of opening a new tab to create a Query](https://res.cloudinary.com/echobind/image/upload/v1661872472/echobind_blog/ec1zxgvnilfmxbp6myow.gif)

If we go back to our `allUsers` query, we can see that things have persisted and we’re good to go.

![GraphQL UI of receiving a response from all users.](https://res.cloudinary.com/echobind/image/upload/v1661873890/echobind_blog/cwfcv5f7qb1oyaqjjg6c.gif)

If you want to see detailed information about your schema, just use the green schema tab on the right of the screen.

![GraphQL Schema tab opened to show what's available](https://res.cloudinary.com/echobind/image/upload/v1661873897/echobind_blog/cbpq8548ac6skbhsxuvp.png)

We get a lot for free!

## Custom Functions

Automatic CRUD operations are great, but custom functions are some next level awesomeness. Graphcool has [3 types of custom functions available](https://www.graph.cool/docs/reference/functions/overview-aiw4aimie9).

* Hooks
* Subscriptions
* Resolvers

Let’s check our custom resolver function that was added by `graphcool init`:

![GraphQL UI - Custom resolver function example](https://res.cloudinary.com/echobind/image/upload/v1661873905/echobind_blog/dlkabk2dm9qt5amiikax.gif)

Testing out the default hello function

### Define a custom function

Let’s assume for some reason, we want to give users a default `dateOfBirth` if one is not provided. We can leverage Graphcool’s `operationBefore` hook for that.

Add the definition to our `graphcool.yml` file. We’ll tell Graphcool to run the `setBirthDate` function before a `User` is created:

```javascript
functions:
  hello:
    handler:
      code: src/hello.js
    type: resolver
    schema: src/hello.graphql

  setBirthDate:
    handler:
      code: src/setBirthDate.js
    type: operationBefore
    operation: User.create
```

If you want to remove sensitive information from the return payload, there’s a corresponding `operationAfter` type.

### Create the function

* First, create the function to run. Make sure and name the file using the same path you specified in `graphcool.yml`.

```javascript
export default async event => {
  const data = { ...event.data };

  data.dateOfBirth = data.dateOfBirth || new Date(1999, 1, 1);

  return {
    data
  };
};
```

### Deploying our changes

For your local Graphcool server to reflect these changes, just run `graphcool deploy` again.

Running our `createUser` mutation again, shows that the user does get a `dateOfBirth` properly set to party like its 1999.

![Graphql UI creating a user with the mutation function to receive Date of Birth](https://res.cloudinary.com/echobind/image/upload/v1661874510/echobind_blog/ckmrdrplrfgomkqtvkhw.png)

### Webhooks

There two ways to handle custom functions using Graphcool. We’ve already used the first, which runs a function local to the server. The other option (which is great for integrating with existing systems) is to use a webhook.

First, we define the webhook in `graphcool.yml` just like we defined `setBirthDate`.

For this example, I’ve set up a demo Heroku app that returns some mock data.

```javascript

functions:
  hello:
    handler:
      code: src/hello.js
    type: resolver
    schema: src/hello.graphql

  setBirthDate:
    handler:
      code: src/setBirthDate.js
    type: operationBefore
    operation: User.create

  queryLegacySystem:
    type: resolver
    schema: src/queryLegacySystem.graphql
    handler:
      webhook:
        url:  https://vast-eyrie-90387.herokuapp.com/
        headers:
          Content-Type: application/json
```

If you want to set up a local server to test the webhook, here’s the express code we’re using:

```javascript
const express = require('express')
const app = express()
app.use(express.json());

const data = [{"id":1,"first_name":"Martainn","last_name":"Moorwood","email":"mmoorwood0@blogger.com","gender":"Male","ip_address":"52.105.79.153","location":{"city":"Cincinnati","state":"Ohio"}},
{"id":2,"first_name":"Shannan","last_name":"Jakubovitch","email":"sjakubovitch1@biglobe.ne.jp","gender":"Male","ip_address":"57.51.60.154","location":{"city":"Charlotte","state":"North Carolina"}},
{"id":3,"first_name":"Alyson","last_name":"Itzkowicz","email":"aitzkowicz2@twitter.com","gender":"Female","ip_address":"210.162.183.75","location":{"city":"Chicago","state":"Illinois"}},
{"id":4,"first_name":"Lalo","last_name":"Ference","email":"lference3@elegantthemes.com","gender":"Male","ip_address":"61.254.152.136","location":{"city":"Reading","state":"Pennsylvania"}},
{"id":5,"first_name":"Creight","last_name":"McGeaney","email":"cmcgeaney4@senate.gov","gender":"Male","ip_address":"121.9.2.0","location":{"city":"Las Vegas","state":"Nevada"}},
{"id":6,"first_name":"Anabel","last_name":"Dutnall","email":"adutnall5@artisteer.com","gender":"Female","ip_address":"174.237.252.181","location":{"city":"Melbourne","state":"Florida"}},
{"id":7,"first_name":"Chicky","last_name":"Rustadge","email":"crustadge6@blog.com","gender":"Male","ip_address":"240.115.81.219","location":{"city":"Merrifield","state":"Virginia"}},
{"id":8,"first_name":"Janette","last_name":"Duval","email":"jduval7@springer.com","gender":"Female","ip_address":"231.173.106.49","location":{"city":"Fairbanks","state":"Alaska"}},
{"id":9,"first_name":"Eran","last_name":"Beddin","email":"ebeddin8@ted.com","gender":"Female","ip_address":"165.190.138.171","location":{"city":"Independence","state":"Missouri"}},
{"id":10,"first_name":"Gilberte","last_name":"Bratcher","email":"gbratcher9@pinterest.com","gender":"Female","ip_address":"250.227.243.236","location":{"city":"Brooklyn","state":"New York"}},
{"id":11,"first_name":"Courtnay","last_name":"Trenoweth","email":"ctrenowetha@bandcamp.com","gender":"Male","ip_address":"35.163.119.198","location":{"city":"Washington","state":"District of Columbia"}},
{"id":12,"first_name":"Kalila","last_name":"Pinock","email":"kpinockb@gravatar.com","gender":"Female","ip_address":"173.250.231.15","location":{"city":"Bronx","state":"New York"}},
{"id":13,"first_name":"Gerrard","last_name":"Meakes","email":"gmeakesc@miitbeian.gov.cn","gender":"Male","ip_address":"253.174.49.32","location":{"city":"Des Moines","state":"Iowa"}},
{"id":14,"first_name":"Kiley","last_name":"Honnan","email":"khonnand@prlog.org","gender":"Male","ip_address":"49.50.71.136","location":{"city":"Chula Vista","state":"California"}},
{"id":15,"first_name":"Susan","last_name":"Fetherston","email":"sfetherstone@prnewswire.com","gender":"Female","ip_address":"186.238.114.230","location":{"city":"Orlando","state":"Florida"}},
{"id":16,"first_name":"Ilysa","last_name":"Hutchinges","email":"ihutchingesf@slideshare.net","gender":"Female","ip_address":"58.121.6.64","location":{"city":"Harrisburg","state":"Pennsylvania"}},
{"id":17,"first_name":"Merrilee","last_name":"Coppledike","email":"mcoppledikeg@google.co.uk","gender":"Female","ip_address":"59.43.136.210","location":{"city":"Springfield","state":"Illinois"}},
{"id":18,"first_name":"Codi","last_name":"Moreinis","email":"cmoreinish@ebay.co.uk","gender":"Female","ip_address":"243.138.168.112","location":{"city":"Harrisburg","state":"Pennsylvania"}},
{"id":19,"first_name":"Gilles","last_name":"Behrendsen","email":"gbehrendseni@simplemachines.org","gender":"Male","ip_address":"168.119.83.215","location":{"city":"Mansfield","state":"Ohio"}},
{"id":20,"first_name":"Hinda","last_name":"Crabbe","email":"hcrabbej@skype.com","gender":"Female","ip_address":"0.84.221.30","location":{"city":"Denver","state":"Colorado"}}]

app.post('/', function (req, res) {
  console.log(req.body)
  res.send({ data: { users: data }});
})

app.listen(3000, function () {
  console.log('Example app listening on port 3000!')
})
```

When testing out webhooks of any kind, it’s a good idea to use [ngrok](https://ngrok.com/) to tunnel a publicly accessible https url back to your local machine.

Finally, create the schema file at the path you specified in `graphcool.yml` above. There’s no need to add a JavaScript file since we’re calling a webhook instead.

```javascript
type LegacySystemPayload {
  users: Json
}

extend type Query {
  queryLegacySystem(userId: ID!): LegacySystemPayload
}
```

Run `graphcool deploy` and let’s try it out.

![GraphQL UI to show the entire response of users](https://res.cloudinary.com/echobind/image/upload/v1661872962/echobind_blog/ghjqypmkiwgltywkqhzj.png)

There’s one slight gotcha to keep in mind. _The response from your existing server needs to be wrapped in a top level `data` key_ to be recognized by GraphQL.

## Staging & Production Environments

We’re off and running with a dev environment, but what about `staging` and `production`? Turns out that’s easy! Just use the `--target` (or `-t`) option available to most cli commands.

![](https://res.cloudinary.com/echobind/image/upload/v1661872681/echobind_blog/q5dylkgayzzd5ruszzoh.png)

Creating a new staging environment

## There’s a Graphcool in your CI!

In a follow up article, we’ll take a look at how to run Graphcool inside a CI service to enable true E2E testing of a React Native app.

The good news for now is that syncing up Graphcool staging deploys with your CI process is pretty painless. It works like this:

1. `npm install -g graphcool`
2. run tests
3. `graphcool deploy -t staging`

## Bonus

By the way, if you have an error in your functions along the way, you get wonderful little error messages when trying to deploy. This combined with `graphcool logs` makes debugging issues pretty painless.

![CLI to deploy to AWS](https://res.cloudinary.com/echobind/image/upload/v1661872688/echobind_blog/tis2pzibx2xwfgxai9vj.png)

Nice, informative error messages

Recommended links for additional reading:

[graphcool-lib examples](https://github.com/graphcool/framework/tree/master/examples/graphcool-lib)  
[Permission rules examples](https://github.com/graphcool/framework/tree/master/examples/permissions)  
[Wrapping an existing REST API](https://github.com/graphcool/framework/tree/master/examples/rest-wrapper)  
[Graphcool Reference Docs](https://www.graph.cool/docs/reference/)

_Update 11/17/17: Removed `setBirthDate.graphql` as it’s not required for `operationBefore` hooks._

---

[View on echobind.com](https://echobind.com/post/the-graphcool-framework-a-path-to-instant-graphql-greatness)

---

# Understanding HIPAA Compliance for Apps

> Oct 31, 2017 | Many of the applications we develop at Echobind involve accessing protected health information and patient data.

_By Michael Yared · 2017-10-31_

Many of the [applications we develop](https://echobind.com/services) at Echobind involve accessing protected health information and patient data. We don’t take this responsibility lightly. As such, HIPAA compliance is a phrase used quite a bit between our team and our clients.

If you’re developing a web or mobile app that accesses health data, you can find a number of resources online recommending dos and donts. We’ve linked several sites throughout this article. Our focus for today is helping companies understand how they can reduce or completely eliminate their exposure and risk.

## What is HIPAA?

If you’re reading this, you’re probably already aware of what HIPAA is, but here’s a formal description:

> _HIPAA (Health Insurance Portability and Accountability Act) is US legislation that provides security provisions and data privacy for safeguarding medical information._

The part of HIPAA that most people know and refer to are the national standards that were set by the US government to protect electronic health care transactions. To summarize, any breach is bad, but a breach accessing medical records and health information is significantly worse.

HIPAA applies to healthcare organizations, health clearinghouses, employer sponsored health plans, insurers, medical service providers, and any business associate (the broad term for consultants, accountants, devops, etc) that has access to personal health information. Even if you’re not directly working on a healthcare application or don’t fall in one of the previously listed groups, HIPAA guidelines are generally helpful security precautions to take into consideration for any app.

## What happens if my organization violates HIPAA?

Great question. First, you’ll probably end up on the government sponsored [HIPAA wall of shame](https://ocrportal.hhs.gov/ocr/breach/breach%5Freport.jsf). Second, it’s probably [going to cost you](https://www.ibm.com/security/data-breach/) as the average data breach in 2017 costs $3.62 million. That [same study](https://www.ibm.com/security/data-breach/) showed the odds of an organization having a data breach are 1 in 4.

So now that we know a bit more about HIPAA, who it applies to and what a bad case scenario looks like, let’s talk about how we can **reduce our risk**.

## Safeguarding your Data

The best rule of thumb we can share is to limit your PHI access to an absolute minimum. Organizations have to constantly ask themselves the question: _Do we really need this data to achieve our goal?_

For example, if your API strategy involves passing back related records that you aren’t directly using, don’t. If you’ve developed an app, properly dispose of the cache when a user logs out and make sure you are automatically logging them out if they don’t themselves. Spend the extra time and resources to properly log each and every time an individual accesses PHI and have a sane way to retrieve that information when you need it.

Many of these tips seem obvious to developers when they hear them, but developers learn to build apps using conventions to optimize for speed and user experience. Developers may need to write more code and users may need login more often. That’s alright. We’re trading some convenience for a higher level of security.

In many cases, companies want to share data with higher ups or third party partners for all sorts of legitimate reasons including invoicing, analytics or even selling the data. This is a situation where you can **completely eliminate your risk**. If your company crafts a strategy to [anonymize your data](https://www.amazon.com/Anonymizing-Health-Data-Studies-Methods-ebook/dp/B00H8B64A4) properly, it is no longer deemed PHI and no patient consent is required. (And if you need help with such a strategy, [contact us](https://echobind.com/contact).)

You can’t lose what you don’t have. If anonymized data were to be stolen, your organization has not committed a HIPAA violation. You’ll still probably want to figure out how the bad guys got into your network and patch those servers, but patient data won’t be exposed and you won’t have to send one of those credit monitoring letters to everyone you know.

## Training & Knowledge Transfer

Despite the hundreds of places which will let you take a quiz and print a certificate in exchange for money, there is no official HIPAA certification to be had. Training falls to organizations themselves, and implementation varies widely. Sometimes HIPAA training is baked into onboarding of new team members and revisited often; other times, training consists of a compliance officer asking a developer to sign a piece of paper. Health & Human Services [has this to say](https://www.hhs.gov/hipaa/for-professionals/training):

> _The HIPAA Rules are flexible and scalable to accommodate the enormous range in types and sizes of entities that must comply with them. This means that there is no single standardized program that could appropriately train employees of all entities._

As developers, we strongly encourage anyone writing code to bake HIPAA into their app. This includes identifying and maintaining database tables that contain PHI, creating automated tests to ensure PHI isn’t leaked, and overcommunicating the reasoning for business logic related to safeguarding PHI via comments.

Lastly, developers should want to avoid risk themselves. As a technology lover, I don’t want a drone for the fear that I may cause [an international incident](https://vimeo.com/228662010). And as a developer, I don’t want [credentials to production](https://aws.amazon.com/message/41926/) databases unless it’s absolutely necessary.

We’ll keep this theme going in a future post and discuss how we leverage hosting providers like [Aptible](https://www.aptible.com/), [TrueVault](https://www.truevault.com/), [Datica](https://datica.com/), and [Heroku Shield](https://blog.heroku.com/announcing-heroku-shield) and compare them to the offerings of [AWS](https://aws.amazon.com/compliance/hipaa-compliance/), [Azure](https://www.microsoft.com/en-us/TrustCenter/Compliance/HIPAA), and [Google Cloud](https://cloud.google.com/security/compliance/hipaa/) to further reduce our risk. 

## Noteworthy HIPAA Checklists

* [IHS HIPAA Security Checklist (PDF)](https://www.ihs.gov/sites/hipaa/themes/responsive2017/display%5Fobjects/documents/IHS%5FHIPAA%5FSecurity%5FChecklist.pdf) — Print this one. IHS put together an exhaustive checklist that corresponds to specific HIPAA references in the law. It covers administrative, physical and technical safeguards.
* [HIPAA Journal’s HIPAA Compliance Checklist](https://www.hipaajournal.com/hipaa-compliance-checklist/) — A nice summary of the major rules with an infographic that’ll scare organizations by sharing some facts about non-compliance.

***Learn more about Echobind's [Healthcare capabilities](https://echobind.com/industries/healthcare).***

---

[View on echobind.com](https://echobind.com/post/understanding-hipaa-compliance-for-apps)

---

# Headless Browser testing with CircleCI 2.0

> Sep 25, 2017 | Continuous integration is one of the first steps we take to ensure the quality of the app improves over time.

_By Alvin Crespo · 2017-09-25_

Here at Echobind, we’ve setup many greenfield applications. Continuous integration is one of the first steps we take to ensure the quality of the app improves over time. We prefer [CircleCI](https://circleci.com/), and recently, version 2.0 of their platform was released.

Given that [Ember 2.15.1](https://www.emberjs.com/blog/2017/09/01/ember-2-15-released.html) supports headless chrome out of the box, I decided to use that framework here to get going quickly.

## EmberCLI Goes Headless

If you’ve been working in Ember for several years, you probably have had to deal with many weird PhantomJS errors. For example, Array destructuring is [not supported](https://github.com/ariya/phantomjs/issues/14506) in Phantom JS 2.1.1\. Well, those days are over.

Recently [headless chrome](https://developers.google.com/web/updates/2017/04/headless-chrome) was [made the default to the testem.js](https://github.com/ember-cli/ember-cli/commit/2001c2d93359c42b14dc8da9775948d04bd6e188) file that gets included in your app when you create a new project. This means we can now utilize headless chrome for our tests.

## CircleCI and Browser Testing

CircleCI supports [browser testing](https://circleci.com/docs/2.0/project-walkthrough/#install-and-run-selenium-to-automate-browser-testing) out of the box.

If you clicked the link above, you’re taken to a Selenium article. What is that? Don’t worry about it. The useful piece of information is this:

> _The primary image has the current stable version of Chrome pre-installed (this is designated by the -browsers suffix)_

This means, that your `.circleci/config.yml` file needs to utilize an image with the `-browsers` suffix. A little more on that later.

## Setting up CircleCI

First things first. I have a sample project for you to check out, that contains the configuration needed to get CircleCI 2.0 running your tests [here](https://github.com/alvincrespo/circleci-2.0-and-ember).

_Prerequisites_

* You have a CircleCI account
* Allowed CircleCI to your Github account
* Your application is using Github

If you want to skip the below, feel free to do so. I’m going to guide you on setting up your project in CircleCI before configuring your project.

## Adding your project to CircleCI

So if you have a project that is **not** running in CircleCI, you’re going to have to add your project:

![UI Set up part one with CircleCI](https://res.cloudinary.com/echobind/image/upload/v1661872911/echobind_blog/i0gdpwrztt79hzhbrv1i.jpg)

Once you do that, you’ll be taken to a page with all your projects listed. Click on “Setup project” to the right of the project you want setup:

![UI Set up part two with CircleCI](https://res.cloudinary.com/echobind/image/upload/v1661873473/echobind_blog/hl7hcw8d58u4rjrtvl6f.jpg)

When you click on “Setup project”, you’re taken to the setup-project page where you configure the settings for your project. For my project, I want it to run on:

As you see here, if you’re project contains a package.json file, CircleCI will pick that up and automatically asume you want Node, Linux and 2.0 will be selected for you:

![UI Set up part three with CircleCI](https://res.cloudinary.com/echobind/image/upload/v1661873473/echobind_blog/hl7hcw8d58u4rjrtvl6f.jpg)

Once that section is done, scroll down to see what you need to configure in your project to get things running:

![UI Set up part three with CircleCI](https://res.cloudinary.com/echobind/image/upload/v1661873473/echobind_blog/hl7hcw8d58u4rjrtvl6f.jpg)

As it states here, we need to do a couple of things:

* Create a .circleci/config.yml file
* Copy/Paste the default contents provided by CircleCI
* Start the build

So let’s leave this page for now and setup the configuration in our project.

## Configuring CircleCI in our project

If you’re in your project, you’ll want to do this:

```javascript
mkdir .circleci && cd .circleci && touch config.yml 
```

Once you have the directory and file created, you’ll want to add the default contents that CircleCI provided you to the `.circleci/config.yml` file.

We won’t go into detail about the configuration options here, that’s for a later discussion. We do want to simplify what’s here and get the basics rolling, so here is a configuration I put together:

```javascript
: 2
jobs:
  build:
    docker:
      - image: circleci/node:7.10.1-browsers
    steps:
      - checkout
      - restore_cache:
          keys:
          - v1-dependencies-{{ checksum "package.json" }}
          - v1-dependencies-
      - run: yarn install
      - save_cache:
          paths:
            - node_modules
          key: v1-dependencies-{{ checksum "package.json" }}
      - run: yarn test
```

There aren’t many differences than what CircleCI provides you by default. But we do see that the docker image we use is different:

`circleci/node:7.10.1-browsers` instead of `image: circleci/node:7.10`

Remember, when we utitlize the `-browsers` suffix, we're telling CircleCI to fetch the image that contains node 7.10.1 with the browsers pre-installed. This means we get browser images for free, and we don't have any setup!

This is all you need to do to get going with CircleCI.

Note: If you’re interested in trying out other images, here is the repo with all the images youc an use for Node: <https://hub.docker.com/r/circleci/node/>

## Getting our builds to pass

Lets go back to CircleCI, we should be here:

![UI Set up part four with CircleCI](https://res.cloudinary.com/echobind/image/upload/v1661873473/echobind_blog/hl7hcw8d58u4rjrtvl6f.jpg)

Click on “Start building”. When you do that, your builds will most likely fail. That’s because you haven’t pushed your CircleCI configuration. So let’s push up those changes and see what happens:

![UI Set up part five with CircleCI](https://res.cloudinary.com/echobind/image/upload/v1661873473/echobind_blog/hl7hcw8d58u4rjrtvl6f.jpg)

Ah, our builds pass!

And we can verify our builds are working because `yarn test` was run and exited correctly:

![UI Set up part six with CircleCI](https://res.cloudinary.com/echobind/image/upload/v1661873473/echobind_blog/hl7hcw8d58u4rjrtvl6f.jpg)

## TL;DR

Getting Ember and CircleCI to work in harmony is easy. EmberCLI’s latest release and CircleCI’s latest platform update means you spend more time building your app.

### References

[Ember 2.15 and 2.16 Beta Released](https://www.emberjs.com/blog/2017/09/01/ember-2-15-released.html)

[Switch to headless chrome instead of phantom on testem & travis](https://github.com/ember-cli/ember-cli/commit/2001c2d93359c42b14dc8da9775948d04bd6e188)

[Getting Started with Headless Chrome](https://developers.google.com/web/updates/2017/04/headless-chrome)

[Support ES6/ES2015 Features](https://github.com/ariya/phantomjs/issues/14506)

[Install and Run Selenium to automate browser testing](https://circleci.com/docs/2.0/project-walkthrough/#install-and-run-selenium-to-automate-browser-testing)

[Using Pre-Built CircleCI Docker Images](https://circleci.com/docs/2.0/circleci-images/)

[circleci/node](https://hub.docker.com/r/circleci/node/)

---

[View on echobind.com](https://echobind.com/post/headless-browser-testing-with-circleci-2-0)

---

# Betting on React Native

> Feb 16, 2017 | We are betting on React Native at Echobind, it is the best way to create great mobile apps today.

_By Chris Ball · 2017-02-16_

## Betting on React Native

We are betting on [React Native](https://facebook.github.io/react-native/) at Echobind. We are convinced that it is the best way to create great mobile apps today. We’re also quite excited about what React Native enables us to produce for our clients.

## Experiment to find the best path

We work on client projects Monday through Thursday each week. On Fridays, we invest in ourselves. We work on [Open Source](https://echobind.com/blog/contribute-to-open-source/), learn new skills, work on internal projects, and experiment with new technologies. The results are shared with the rest of the team.

What we don’t do is base our recommended technology choices on what’s [shiny and new](https://blog.codinghorror.com/the-magpie-developer/). There’s always a new “Next Big Thing”, especially in the world of frontend and JavaScript. Chasing that is not a good decision for us our for our clients. As a [trusted partner](https://echobind.com/blog/client-agency-partnerships/), we’ll always choose what’s best for the project.

After experimenting with React Native, it became clear that it was a great path forward for our clients.

## Why React Native over XXXX?

There are an overwhelming number of ways to build a mobile app in 2017\. To explain why we are choosing React Native, let’s look at our options:

![An icon of the world wide web](https://res.cloudinary.com/echobind/image/upload/v1661872703/echobind_blog/tptqf5tqzp6kolowofhe.jpg)

## 1\. Web Apps (Do you actually need a mobile app?)

The wrong reason to build a mobile app is to assume you need one. Instead consider if the addition of a mobile app benefits your users. Does your site work well on mobile devices? In some cases, that might be all you need.

**Benefits**

* Creating a standard web app has a low barrier to entry. You’re likely already doing it.
* If the user adds the web app to their homescreen, the browser UI is automatically removed.

**Challenges**

* Users must be prompted to add the app to their homescreen, since many don’t know how
* The end result is hard to customize, especially loading screens
* What happens when the user has no connectivity?

![An icon of android and internet](https://res.cloudinary.com/echobind/image/upload/v1661872710/echobind_blog/mput73jrsioqruh72u90.jpg)

## 2\. Progressive Web Apps (PWAs)

Progressive Web Apps promise to deliver an app-like experience using web technology. As a user interacts with a PWA, they receive a prompt to install the app to their homescreen.

Offline use and push notifications are examples of “native only” features that PWAs support.

**Benefits**

* No large download up front
* The user will be auto-prompted to add to homescreen
* Android has good support already
* No need to link the user to an App Store to download

**Challenges**

* Does not work in iOS Safari, though it is [under consideration](https://webkit.org/status/#specification-service-workers)
* Implementing Service Workers (which power much of a PWA) is non-trivial

We evaluated PWAs throughout 2016\. They have come a long way, but we feel they are at least a year away from being one of our recommended defaults. We currently consider PWAs a nice to have option. If an app targets areas with poor connectivity or connection speeds, PWAs may play a larger role.

I polled a small group of technical and non/technical users. Out of this group, only one (who happened to be a developer) had used or was interested in “Installing an App from the web without having to use the App Store”

It’s worth noting that Twitter [just recently shipped a PWA](https://twitter.com/necolas/status/829128165314306048) version of their mobile site. The new site is a massive improvement over the previous one (and really well done!). It’s a great alternative to the native app but not a full replacement.

![An icon of Cordova](https://res.cloudinary.com/echobind/image/upload/v1661874027/echobind_blog/azkcvyb2btmvq0iv7ccx.jpg)

## 3\. Hybrid apps (Cordova)

Cordova has been around for a long time. As such, it has become the standard for developing native apps using web technology. Cordova wraps a WebView with a native shell, which loads and runs your application.

**Benefits**

* Use existing JavaScript skills
* Bring any frontend framework you want
* Access native features using Cordova’s large plugin ecosystem

**Challenges**

* Performance & memory usage must be closely monitored
* No native UI components, you must create them

![An icon of react native](https://res.cloudinary.com/echobind/image/upload/v1661874193/echobind_blog/yunkx9vfrm3ix2ksxahi.jpg)

## 4\. “JSNative” apps (React Native, NativeScript)

These apps are a newer type of hybrid app with code written in JavaScript. Building a project creates a binary that contains JavaScript and native code. (JSNative is a made up term to differentiate these apps from their Cordova counterparts).

In the case of React Native, React runs on a separate thread from the main app thread. React calculates the UI to render, but native components handle the actual rendering. On the other hand, NativeScript attempts to provide a way to call any native method via JavaScript.

I was initially skeptical. But after experimenting with a few apps, I realized how different React Native was. I was sold after seeing how well it worked as a developer and an end user.

**Benefits**

* Use existing JavaScript skills
* One common language, regardless of platform
* Better performance than Hybrid since code is not running in a WebView

**Challenges**

* Requires some knowledge of native code and app store publishing

![An Icon of Android and Apple](https://res.cloudinary.com/echobind/image/upload/v1661874200/echobind_blog/qy5dd3c2ar9es8nk8ugu.jpg)

## 5\. Native (Objective-C, Swift, Java)

AKA classic mobile development. We’ve historically avoided working on native applications. We don’t feel it’s worth the additional time and budget investment required to ship a quality app with two completely different codebases.

We also discourage companies from focusing on a single platform, so traditional native development was never a good fit for our team.

**Benefits**

* Full control over the environment (great for game developers)
* Great performance by default since your code is “closer to the metal”

**Challenges**

* Requires building and maintaining separate teams (iOS team, Android team, Web team)
* Each team requires different skillsets and programming languages
* Every app change must go through the associated App Store
* Typically highest cost to create

![Previous icons grouped together](https://res.cloudinary.com/echobind/image/upload/v1661872875/echobind_blog/psdehdetsfxftljvw6br.jpg)

## So why choose React Native?

In a nutshell: we get to keep almost everything we love about the web, but with the added performance and quality typically only seen in native apps.

Awesome things for us, as developers:

Awesome things for our clients:

* Web-like iteration speed
* Anyone that knows JavaScript can learn React Native
* High percentage of shared code = lower overall budget
* [Some](https://www.techatbloomberg.com/blog/bloomberg-used-react-native-develop-new-consumer-app/) [really](https://engineering.instagram.com/react-native-at-instagram-dd828a9a90c7#.32pi6wcc3) [large](https://twitter.com/spikebrehm/status/799338174979842050?lang=en) [apps](https://medium.com/walmartlabs/react-native-at-walmartlabs-cdd140589560#.13kmlwdut) [and](https://twitter.com/timdorr/status/830423561592532993) [companies](https://itunes.apple.com/us/app/discovery-vr/id1030815031?mt=8) are successfully using it

## Our bet at Echobind

Over the next few years, Progressive Web Apps will continue to improve. They will eventually be another great choice for mobile apps. However, we’re focused on the best choice for our clients and our team today. For us, that choice is to build mobile apps using React Native.

It’s all about using the right tool for the job to deliver a great final product.

---

[View on echobind.com](https://echobind.com/post/betting-on-react-native)

---

# How to Easily Create Custom Skills for Alexa

> Jan 14, 2017 | Many companies hope to create custom skills. We’ve had the opportunity to integrate custom business logic that will keep our clients top of mind.

_By Chris Power · 2017-01-14_

After another influx of Alexa powered devices made their way into consumer homes, [many companies hope to create custom skills](http://fortune.com/2016/12/20/Amazons-echo-snag-entrepreneurs/). We’ve had the opportunity to help integrate custom business logic that will keep our clients top of mind, and you can too.

The [Amazon documentation](https://developer.amazon.com/public/solutions/alexa/alexa-skills-kit/getting-started-guide) is very straightforward, so we made a tutorial to help create custom skills that involve linking your user’s Amazon account with their profile on your application.

Throughout this article, you will learn the process of creating a custom skill, linking it with a user in a Rails application (using [Devise](https://github.com/plataformatec/devise) and [Doorkeeper](https://github.com/doorkeeper-gem/doorkeeper)), and querying data on the user’s behalf.

If that sounds like fun, let’s get started!

## Meet our application: PokeHOT or PokeNOT

![A group of pokemons with the title of PokeHOT and PokeNOT](https://res.cloudinary.com/echobind/image/upload/v1661874409/echobind_blog/apeb4ae30ggz1sykydxr.png)

I have had the pleasure of working with the **premiere** Pokemon hotness rating application on the Internet today. It’s very disruptive. Thankfully, this author was kind enough to let me use their application as an example of writing custom Alexa skills. This is a basic application that allows a user to sign in, vote on the hottest Pokemon, and see the results.

For our Alexa skill, we will enable a user to:
1. link their account
2. check which Pokemon is currently the hottest
3. ask for the last vote they cast on a Pokemon

All by using their voice!

## Step one: Get an Amazon Developer Account and create a Custom Skill in Alexa

Sign up for a [developer account on Amazon](https://developer.amazon.com/), click on the Alexa Tab, then [Alexa Skills Kit](https://developer.amazon.com/edw/home.html#/skills/list). Once in the Alexa skills dashboard, click on the “Add a new Skill” button.

Let’s go through the new skill sections one-by-one.

**Skill Information**: This is where you put basic info like your skill name, invocation name, etc. All we do here is put “Pokemon Hot or Not” for skill name, and “Pokemon hot” for the invocation name.

_Note: the invocation name is what users say to ask questions through your skill._

![Form inputs to insert skill information](https://res.cloudinary.com/echobind/image/upload/v1661874675/echobind_blog/y7eji6yfqqff5uwtkvsh.png)

**Interaction Model**: Place your “Intent Schema” and your “Sample Utterances” here. In short, your Intent Schema is the list of intents you want for your skill. An “Intent” is basically a question. We are going to keep this part simple with only a couple intents. For more information on intents, [see this section of the Alexa documentation](https://developer.amazon.com/public/solutions/alexa/alexa-skills-kit/docs/alexa-skills-kit-interaction-model-reference). We will also add some sample utterances on this page. An utterance is an example of _how_ your user can ask a question. You will generally want **a lot** of sample utterances in your skill.

![Interaction Model UI to configure](https://res.cloudinary.com/echobind/image/upload/v1661874121/echobind_blog/ykv65lmujyqhz26cvkrj.png)

Let’s leave the rest of the skill configuration blank for now. We’ll come back to the configuration after we’ve set up our application to talk to Amazon. For now, take a break, grab a coffee, and rest up. You’ve done a lot.

## Step Duex: Setting up your application to talk with Alexa

Let’s set up our application to handle Alexa’s requests. For this section, we’re going to assume you have a Rails API available.

**Create a new controller for requests from Alexa**  

Alexa will hit our server with POST requests. These requests will contain data, like an access token, Intent name, etc. In order to get these requests, let’s create a new controller. I like to namespace mine, so I opt for `api/alexa/handler_controller.rb`

In this controller, you’ll note that I return an odd piece of JSON. A lot of this is boilerplate you need for Amazon. The most important part is the “outputSpeech” section. [Here is the documentation](https://developer.amazon.com/public/solutions/alexa/alexa-skills-kit/docs/alexa-skills-kit-interface-reference#response-examples) to learn more about responses and requests from Amazon. For now, we’ll stub out a simple response “hello from Pokemon Hot!”

```javascript
#app/controllers/api/alexa/handlers_controller.rb
class Api::Alexa::HandlersController < ActionController::Base
  def create
    message = "hello from Pokemon Hot!"
    session_attributes = {"previous_session": "something"}
    session_end = true

    render json: {
      "response": {
        "outputSpeech": {
          "type": "PlainText",
          "text": message,
        },
        "shouldEndSession": session_end
      },
      "sessionAttributes": session_attributes
    }
  end
end
```

and update your routes file

```javascript
#config/routes.rb
  namespace :api do
    namespace :Alexa do
      resource :handler, only: [:create]
    end
  end
```

Once you’re finished make sure to restart your Rails server.

**Install ngrok for SSL locally**  
[ngrok](https://ngrok.com/) will host a local version of our ap, and allow Amazon servers to speak to it. Amazon requires our server to have SSL. We don’t want to host a heroku SSL instance simply for testing, so ngrok will work perfectly.

```javascript
brew update
brew cask install ngrok
```

After installing ngrok, set it to run on whatever port you’re running your Rails server on. In our case, it’s good ol’ port 3000.

```javascript
ngrok http 3000
```

After running this command, you should see something like this:

![ngrok example in the CLI](https://res.cloudinary.com/echobind/image/upload/v1661874466/echobind_blog/yrjdqr1jkoiawh8gvkkp.png)

Do you see that https link above? That is what we’ll tell Alexa to communicate with.

**Get Alexa to talk to us**  
Now that we have:

1. ngrok tunneling our application to https
2. we have our controller and route

Let’s point Alexa at our application. Go to the Alexa skill you created earlier, click on “configuration” tab, and paste in the https link from ngrok, including the route we created:

![Adding endpoints to a form](https://res.cloudinary.com/echobind/image/upload/v1661874474/echobind_blog/wiohg4poqeolrra3vhdm.png)

‍**Now let’s test!**  
Go to the “Test” tab in your Alexa skill, and type in an utterance. If you did everything correctly, you should see output similar to below:

![The response object from a specific endpoint](https://res.cloudinary.com/echobind/image/upload/v1661874481/echobind_blog/lw8ph6oflmahzpumvtg3.png)

Great Job! You see we got a response back from our API. You can even hear Alexa say it out loud by clicking the “Listen” button. This is another great opportunity to take a break. We’ll finish this up when you get back!

## Step Three: Authenticate users with DoorKeeper and Query on their behalf

This is where things get very interesting. We have the building blocks in place currently, and now it’s time to finalize everything. We are going to focus on a few major things from here on out:

1. Install Doorkeeper to become an Oauth2 provider
2. create application in Doorkeeper for Amazon to connect with
3. configure Doorkeeper to play nicely with Amazon and how Amazon handles tokens
4. flesh out actual responses for our api

**Install and configure Doorkeeper**  
[Doorkeeper](https://github.com/doorkeeper-gem/doorkeeper) is a great gem that allows you to introduce OAuth 2 provider functionality to your Rails application. Let’s install and configure Doorkeeper.

```javascript
#gemfile.rb
gem 'doorkeeper'
```

Then generate migrations and boilerplate Doorkeeper stuff:

```javascript
 bundle
Rails generate doorkeeper:install
Rails generate doorkeeper:migration
rake db:migrate
```

Then make sure Doorkeeper added routes to your app:

```javascript
#config/routes.rb
Rails.application.routes.draw do
  use_doorkeeper
  # your routes
end
```

Configure Doorkeeper to use the current\_user in resource\_owner\_authenticator. Since we use Devise, this is handled easily:

```javascript
#config/initializers/doorkeeper.rb
  resource_owner_authenticator do
    # Put your resource owner authentication logic here.
    # Example implementation:
    current_user || warden.authenticate!(:scope => :user)
  end
```

For our purpose, we’re going to use “implicit grant” for OAuth. Configure that in Doorkeeper config again:

```javascript
#config/initializers/doorkeeper.rb

# implicit and password grant flows have risks that you should understand
# before enabling:
#   http://tools.ietf.org/html/rfc6819#section-4.4.2
#   http://tools.ietf.org/html/rfc6819#section-4.4.3
grant_flows %w(implicit)
```

**Create an OAuth application in Doorkeeper to handle the Amazon requests**  

This is pretty straightforward, you need an application for Amazon to connect to. You set this up in both Doorkeeper and Amazon. First, go to your local Doorkeeper applications instance. (Mine is running at `http://localhost:3000/oauth/applications`.) Click "New Application". You can name this application whatever you want.

For the “redirect URIs”, go to your Amazon developer account, click on “Configuration” in your custom skill, then click “Yes” for account linking.

![A highlight of grabbing the redirect URL](https://res.cloudinary.com/echobind/image/upload/v1661874538/echobind_blog/lfalqt2oevgdup4fgwxk.png)

* In the “Authorization URL” field, put in your ngrok URL for OAuth. It is `/oauth/authorize` in standard Doorkeeper installs.
* Copy the two redirect urls (highlighted above). Doorkeeper will redirect to one of these after linking a user account

Next, go back to Doorkeeper and finish your new application

![Creating a new application UI](https://res.cloudinary.com/echobind/image/upload/v1661873113/echobind_blog/hbmaftzz2msc2c2cwtuv.png)

**One thing to note:** Doorkeeper does not allow query params in Redirect URI’s see Github issue here. Make sure to remove the trailing `?vendor=XXXXXXX` from your redirect\_uris from Amazon when pasting into Doorkeeper.

After hitting “Submit” you should have an application for Amazon to connect to!

![Application created successfull UI](https://res.cloudinary.com/echobind/image/upload/v1661874128/echobind_blog/pmjf5iqo9rzor5bym2w2.png)

Now copy and paste your application ID to Amazon’s `Client Id` field under "Account Linking" and hit save!

**Let’s test this out**

Restart your server and “Authorize” the app with Amazon.

If you don’t already have an Alexa account, create one with the same email as your developer account. Then, go to [alexa.amazon.com](http://alexa.amazon.com/), click on ‘home’ and click ‘Your skills’ at the top right. You should see your custom skill listed there. Click on it and authorize:

![Amazon Alexa showing the app now exists](https://res.cloudinary.com/echobind/image/upload/v1661873862/echobind_blog/yz1r4xibf66q3e1vgef0.gif)

Awesome! We’re almost there!

**Protect controller with Doorkeeper**  

It’s time to finally handle the intents and grab information from an actual linked user! Let’s configure our `alexa/handler` controller to 'handle' the requests and respond with actual data.

First things first, let’s protect the controller with Doorkeeper. We’re going to add a few methods that I will explain shortly.

```javascript
#controllers/api/alexa/handlers_controller.rb
prepend_before_action :set_access_token_in_params
before_action :doorkeeper_authorize!

def current_doorkeeper_user
  @current_doorkeeper_user ||= User.find(doorkeeper_token.resource_owner_id)
end

def set_access_token_in_params
  request.parameters[:access_token] = token_from_params
end

def token_from_params
  params["session"]["user"]["accessToken"] rescue nil
end
```

* `dookeeper_authorize!` is what Doorkeeper uses to protect actions from unauthorized users
* `set_access_token_in_params` takes a bit of explanation. When Amazon sends a request to your API, it includes the `accessToken` for the user in a nested JSON object. Doorkeeper doesn't know where to look for this access token, so we prepend our `before_action` with a method that moves `access_token` into the params where Doorkeeper expects it.
* `current_doorkeeper_user` is just our convenience method for grabbing a user from the passed over access\_token.

**Actually get user data for responses**  
We are just about done! Now let’s grab information from the actual database and return it to the user depending on what they asked our app for. If you remember, we have two intents to handle “HottestPokemon” and “LastPokemonVote”.

* For “HottestPokemon”, we’ll grab the Pokemon with the most vote and return the name
* For “LastPokemonVote”, we’ll get the most recent vote from the user, and return the name of the Pokemon they voted for.

**The final code should look like this**

```javascript
class Api::Alexa::HandlersController < ActionController::Base
  prepend_before_action :set_access_token_in_params
  before_action :doorkeeper_authorize!

  def create
    user = current_doorkeeper_user
    intent_name = params["request"]["intent"]["name"]
    case intent_name
    when "HottestPokemon"
      Pokemon = Pokemon.order(vote_count: :desc).first
      message = "The hottest Pokemon is #{Pokemon.name}!"
      render response_with_message(message)
    when "LastPokemonVote"
      Pokemon = user.votes.order(created_at: :desc).first.Pokemon
      message = "Your last vote was for #{Pokemon.name}"
      render response_with_message(message)
    else
      #error somehow
      render response_with_message("Error. We couldn't find your request")
    end
  end

  def current_doorkeeper_user
    @current_doorkeeper_user ||= User.find(doorkeeper_token.resource_owner_id)
  end

  private

  def response_with_message(message)
    {
      json: {
        "response": {
          "outputSpeech": {
            "type": "PlainText",
            "text": message,
          },
          "shouldEndSession": true
        },
        "sessionAttributes": {}
      }
    }
  end

  def set_doorkeeper_token
    request.parameters[:access_token] = token_from_params
  end

  def token_from_params
    params["session"]["user"]["accessToken"] rescue nil
  end
end
```

For simplicity, we use a case-statement based on the `params["request"]["intent"]["name"]` passed along from Alexa. From there, we find data from our database, and return the message to our user.

If you’d like to see the demo app used in this post, [check it out here](https://github.com/cpow/pokemon-alexa)

## Your Turn

This tutorial scratches the surface of what is possible with an open platform like Alexa. Although this demo showcases simple responses, you can build complex interactions that span multiple skills. [Contact us](https://gist.github.com/contact/) if you have an idea for a custom skill you would like to integrate for your business.

---

[View on echobind.com](https://echobind.com/post/how-to-easily-create-custom-skills-for-alexa)

---

# Why Your Company Should Contribute to Open Source

> Jan 09, 2017 | Why open source? This is a question I was asked when inquiring whether a client wanted to open source a portion of their project.

_By Robert Beene · 2017-01-09_

Why open source? This is a question I was asked when inquiring whether a client wanted to open source a portion of their project. For clients, it seems counterintuitive to give away something that costs money. For those businesses that do, it can pay back in spades.

Companies who require outside help typically fall into one of three categories:

* No internal developers
* Not enough internal developers
* A need for developers with a different skill set

Open source can solve much of this. It boils down down to being able to keep and retain talented developers.

In today’s market, high demand makes retention just as hard as hiring. When we talk to developers, the ones that are most excited about their jobs derive happiness from the type of work and the available learning opportunities. Others that are looking for new opportunities want to be challenged and afforded room to grow.

If you can hire **and** retain talented resources, you’ll be able to deliver. Open source helps on both counts.

## Technical Clout

Giving back to broader community demonstrates technical ability at your organization. This respect and awareness is something that shouldn’t be discounted for recruiting and retention. When I think of companies that use our core technologies, the ones that come to mind are the ones who have contributed great tools or frameworks to the development community.

> _The more community members leverage a project, the better it becomes._

That technical clout also flows down to the employees involved in open source. Employees have the opportunity to further raise the visibility of their companies through speaking engagements at meetups or conferences.

## Giving To Receive

At first blush, open sourcing can be perceived as increasing the workload of internal staff. From responding to issue reports or reviewing pull requests from outside parties, it’s easy to conclude that it’s a time sink. However, the hidden power of open source becomes clear over time. The more community members leverage a project, the better it becomes. Projects that do open source get contributions that can resolve bugs unseen by the original developers. Features not originally envisioned can be added after thoughtful review.

What company doesn’t want to free software development?

> _Rails has over 3000 contributors while the founding company has no more than 50 employees_

## I’m a Believer — Now What?

Although it could be as easy as flipping a project over from private to public on Github, that isn’t setting it up for success.

## Legal Perspective

One of the most important things to determine when open sourcing is which license to use. Not sure which one is right for you? Read here and [choose your own adventure](http://choosealicense.com/). For many, the MIT License is chosen but every organization is different.

Another legal consideration is contributor license agreements (CLA). Typically, a CLA is used to protect a company from code submitted from those without license to do so. Although these were in use on many high-profile projects, they have for the most part fell out of [favor](https://www.joyent.com/blog/broadening-node-js-contributions). Requiring contributors to sign a CLA is a speed bump and can prevent otherwise useful submissions.

## Maintenance

Although open source gives back to the maintainers, it’s not something to toss over the community wall and hope for the best. As issues and pull requests are submitted, it’s important for the company be responsive. If you treat the community engagement the same way as you would internal bug reports and pull requests, code quality will increase. In extremely successful projects, this will eclipse your own contributions over time.

> _Ember was started by two developers and now has over 600 contributors_

## Still Not Sure?

If it still feels like open source is not a good fit, then you might be right. Not everything can be open sourced. This is particularly challenging with monolothic applications. Beyond the inherent benefits of microservices, splitting up your application frequently opens the door to making tools public.

> _Sidekiq — an excellent queueing solution for Ruby was started by one developer and now has more than 300 contributors_

If you look at your current technology stack, many of the core components are probably open source. From major frameworks to tools used within them, many open source projects have opted to use the MIT-license and have grown considerably as a result. The number of contributors in many cases far exceeds the number of internal resources with commits.

Your application or homegrown tools could be next. We are happy to talk with you about how open source can help change your organization.

---

[View on echobind.com](https://echobind.com/post/why-your-company-should-contribute-to-open-source)

---

# Thanks for 2016!

> Jan 02, 2017 | From having fun with “Island Survival Kits”, to training developers on the other side of the world, 2016 was a great year for us. We’re capping off our year by talking about some of the apps we launched, the fun times we had, and the friends we made.

_By Chris Ball · 2017-01-02_

From having fun with “Island Survival Kits”, to training developers on the other side of the world, 2016 was a great year for us. We’re capping off our year by talking about some of the apps we launched, the fun times we had, and the friends we made.

## Conferences

We attended five conferences in 2016.

In March, our entire company (at the time) attended and sponsored [EmberConf](http://emberconf.com/) and [Ruby on Ales](http://ruby.onales.com/) back-to-back. It’s no secret that we love EmberConf, and it’s not just because we need an annual excuse to eat [ridiculously amazing chicken](http://screendoorrestaurant.com/).

After EmberConf, we packed up for Ruby on Ales. We rented a Yukon XL SUV and drove through the Cascade mountains with a newfound friend (Hi Vaidehi!). Ruby on Ales was a different kind of conference, [but it was a really fun one](https://echobind.com/blog/recap-ruby-on-ales-2016/).

![On the road to Rube on Ales in an SUV](https://res.cloudinary.com/echobind/image/upload/v1661873480/echobind_blog/nsmbwiy1gxkry7ngisiv.jpg)

Our EmberConf 

We went to and sponsored Wicked Good Ember in June. Since this conference was on an island, we made surprise “Island Survival Kits” to hand out to everyone. The conference also allowed camping, so I decided to take the opportunity to sleep in a hammock overlooking the Boston Harbor. Recommended.

![A collage photo with dishing out island survival kits](https://res.cloudinary.com/echobind/image/upload/v1661874704/echobind_blog/j4e7b3rowi31cl8zxfwz.jpg)

![A hammock over the harbor](https://res.cloudinary.com/echobind/image/upload/v1661874711/echobind_blog/chrsblyij4gyg4cfxv9y.jpg)

If you weren’t able to make it, check out our video that captures the [sights and musical sounds](https://vimeo.com/172609760) of the conference.

We sent multiple people to ElixirConf in Orlando, [had a blast](https://echobind.com/post/elixir-phoenix-conf-2016-recap-for-the-love-of-programming) despite the weather, and documented many of the talks through photos. Taking a Nerves workshop made it clear that this language thrives in places you wouldn’t expect. Elixir is making waves, and we’re happy to be a part of it.

We also went to the very first elm-conf in St. Louis. Not surprisingly, many of our friends from the Ember and Elixir communities were there too.

## Trainings

In 2016 we did trainings in:

* Boston, Massachusetts
* Bangalore, India
* Petaluma, California
* Remote to Ottawa, Canada

![Training in Bangalore. The mural read “Amber Fort” and was used for an Ember training!](https://res.cloudinary.com/echobind/image/upload/v1661874718/echobind_blog/ojok4m46nsvabsy19eta.jpg)

![Our impromptu remote training studio](https://res.cloudinary.com/echobind/image/upload/v1661874726/echobind_blog/bgikwjumebkgxwddlnuj.jpg)

We tried to do an on-site training in Ottawa, but the Canadian border patrol had better ideas. Unfortunately, it’s easier to get training VISAs for India or Costa Rica than it is to help our neighbors to the North. Ask us sometime if you want the full story!

Trainings require a lot of prep time. We’ve found that to really maximize value for the trainees, the course should be adapted to the skill level of the group and changed on-the-fly.

In 2017, we are considering adding hyper-focused workshops on specific topics instead of trying to teach everything we know about a specific framework in a few days.

We’ll continue to offer full scale trainings as they are still useful to some companies. We think for many individuals and teams though, workshops are easier to digest. They are also easier on us to prepare.

## Meetup groups

In 2016, we ran the Boston Ember and Ember.js Louisville meetup groups, and started [Elixir Louisville](https://www.meetup.com/Elixir-Louisville/) and [Boston Frontend](https://www.meetup.com/Boston-Frontend/) near the end of the year.

We love giving back to the communities we’re involved with every day. We want to continue and grow these groups in 2017.

![A collage pic of different conference rooms](https://res.cloudinary.com/echobind/image/upload/v1661874258/echobind_blog/vxhdjke89vsze8i3iym8.jpg)

## Growing our team

We hired Charlotte Emslie as a marketing intern in May. Charlotte was our first intern at Echobind and did great work for us. She helped us throughout the summer and a little bit into fall, but it became (understandably) difficult for her to balance school and work. Thanks for everything Charlotte!

We also hired Alvin Crespo at the end of August. Alvin has been an incredible addition to the team and we can’t wait to see where he enables us to take the company in 2017.

Thanks to Chris Power, Colin Mathews, Glenn Erikson, and Tyler Hill for working with us on various projects throughout the year and continuing to be a part of our team.

![Collage with the echobind team networking](https://res.cloudinary.com/echobind/image/upload/v1661873912/echobind_blog/clsui7ybuvtraelkompw.jpg)

## Clients

We wouldn’t be able to do what we do without all of the amazing clients we’ve worked with.

In 2016, we had the opportunity to build or help teams build:

* Healthcare analytics platforms with large datasets
* Internal human resource tools
* A data platform for scientific companies
* An admin dashboard for team analytics
* A platform to match Boston tech companies with students looking for internships
* A gameified mobile web app to encourage people to save money
* Alexa skill integrations
* An on-demand video conferencing solution for doctors & patients
* A sales portal to intelligently automate the distribution of leads and collect feedback

In no particular order, thank you so much to our friends at Teladoc, QPID Health, Guardant Health, Humanyze, TechGen, Decision Resources Group, Ovation, MailHaven, Utile, VersaPay and Ciena. We loved working with all of you!

## What’s up next?

Some plans are already in place, and others are just being formed. But we’re really excited about 2017\. Here are a few things you’ll see from us soon:

## A new brand

We’ve had our current brand since the beginning of the company. It’s served us well, but we decided that it’s time to update and modernize it. You can see our new logo on the site now. Expect a completely new brand (including a new site, copy and assets) to launch in early Q1.

## More content

We started sharing our knowledge more in 2016\. We’ve put plans in place to further increase the content we provide. We hope to build a valuable resource for fellow developers and potential clients to learn from our experiences.

We want you to be a part of the conversation. Join our once-a-month emails to receive our best articles and stay informed on important industry trends.

## A bet on React Native

At Echobind, we love and believe in the web. Progressive Web Apps certainly seem like the future. But after experimenting with them, we don’t feel they are the best option for clients just yet. In 2017, we’ve decided to focus on React Native for our clients that need a native app rather than try to pitch PWAs or Cordova as a native solution.

We’re really excited about React Native, and we have an article coming soon that will explain all the reasons why.

## More additions to the team

We’ll continue to grow the company in 2017 and plan to add more amazing developers to our team.

## Thanks for 2016!

It’s been an understandably hard year for many people, but for us as a company it’s been a great one. We’re very proud of the path we’re on and the trajectory we have going into 2017.

---

[View on echobind.com](https://echobind.com/post/thanks-for-2016)

---

# Working Together

> Dec 27, 2016 | People looking to build an application know what they want, it’s our job to make their lives easier by guiding them through the process.

_By Michael Yared · 2016-12-27_

People looking to build an application know what they want, but they don’t always know the most effective way to get there. It’s our job to make their lives easier by guiding them through the process. Having a team that has collectively worked on hundreds of applications means we know what a successful project looks like. The early working relationship we establish means absolutely everything to us.

As a consulting agency, we get a variety of emails and calls about all sorts of potential work. We build custom applications from scratch, augment and lead existing teams, and train developers all over the world. And since we work with companies of all shapes and sizes, we feel that we’ve gotten pretty good about knowing where we fit in well and where we don’t.

Our work is typically strategic in nature. If we’re building an application from scratch, it’s because someone has an idea and needs a team to build it. When we augment existing teams, it is to add extra throughput to achieve a deadline or to bring a skill set that doesn’t currently exist.

## Finding the right partner

For us, the factors to determine if there’s a fit are fairly obvious even though we don’t write them in stone or add them to our wiki. We look for common ground on the following:

1. Relationship
2. Type of work
3. Length of the engagement
4. Project budget

Money is certainly what allows us to keep this machine running, but compensation isn’t what unlocks the most value for our agency. We’ve taken on projects below our weekly rate because they have given us an opportunity to enter a new industry or utilize a new technology.

So conversely, one would think that we would demand more compensation if the factors above weren’t ideal. The opposite is true. We simply don’t take the business. That is even the case for projects that seem good at first but turn sour after months of negotiations trying to find common ground.

We’ve found that it isn’t worth trying to make a bad situation into a good one. Whether right or wrong, we’ve successfully grown our business by choosing partnerships over vendor relationships.

## Being treated like a vendor sucks

No one wants to be a vendor, order taker or outsider. These type of relationships may solve short term pains, but they do nothing for the long term. It’s the difference of being sent a long email chain with a comment saying “we need this done in a month and here’s our budget” versus being asked to join in on a brainstorming session with stakeholders.

Now imagine a relationship where the other side is always looking out for your best interest and thinking about future opportunities. Compare that to simply being told what the immediate needs are and what the budget is. The two scenarios yield completely different long term results.

Early on, we knew what type of partnerships we wanted to engage in. To help foster those type of relationships, we created a [playbook](https://echobind.com/playbook/) to show our potential clients how we’ve been most successful. Here’s the copy from our opening page:

> _The Playbook is a guide that outlines our operating procedures and coding processes. These practices help us to create the best possible software products while ensuring a successful working relationship with our clients. This is how we work. —_ [_Echobind Playbook_](https://echobind.com/playbook/)

Transparency is a word we use often at Echobind, and for good reason. Transparency is one of our key differentiators from being a vendor. It is what gives us the ability to work effectively internally and to provide a truly collaborative experience with our clients.

Being perfectly transparent: **our goal is to make our partners look like heroes within their organization**. We know that when this happens, we have created another longterm partnership.

---

[View on echobind.com](https://echobind.com/post/working-together)

---

# What Is JWT and Why Does It Matter

> Nov 30, 2016 | As web and mobile applications integrate with other services, it becomes increasingly important to be able to give access in a secure fashion. Introduced in RFC 7519 in May 2015, JSON Web Tokens (JWT) has quickly become a trusted way to solve this problem.

_By Robert Beene · 2016-11-30_

As web and mobile applications integrate with other services, it becomes increasingly important to be able to give access in a secure fashion. Introduced in [RFC 7519](https://tools.ietf.org/html/rfc7519) in May 2015, JSON Web Tokens (JWT) has quickly become a trusted way to solve this problem.

Before we get to JWT, let’s think about security. You can think of most security schemes in three ways: what you know (password), what you have (smart card) or what you are (fingerprint). What happens though when I want to give someone access to a system, but I don’t want to give my password or give them a smart card to get in at any time? We’ll come back to this.

## So what is JWT?

At a base level, you can think of JWT as having three parts.

## Header

The header states the algorithm used to encrypt the signature and the type, JWT.

```javascript

header = {alg: "HS256", typ: "JWT"}
=> {:alg=>"HS256", :typ=>"JWT"}
```

## Payload

The payload is dictated by the application who will receive it. An example payload could be a user ID and whether or not the user is an admin. Unless you use JSON Web Encryption, any data stored in the payload should be considered insecure. In addition, there are [special fields](https://en.wikipedia.org/wiki/JSON%5FWeb%5FToken#Standard%5Ffields) that add expiry time and “not before” timestamps to limit when tokens are considered valid.

```javascript

payload = {user_id: 1, admin: true, exp: 1480532324}
=> {:user_id=>1, :admin=>true, :exp=>1480532324}
```

## Signature

The signature is generated by hashing a secret string key with a combination of the header and payload. Both the header and payload must be Base64 urlsafe encoded.

![A diagram of JWT Part one Header to Base64](https://res.cloudinary.com/echobind/image/upload/v1661872853/echobind_blog/pe0jorrlgv61tvz5ewbo.png)

```javascript

encoded_header = Base64.urlsafe_encode64(header.to_json.encode("UTF-8")).delete("=")
=> "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9"
```

![A diagram of JWT Part two](https://res.cloudinary.com/echobind/image/upload/v1661874805/echobind_blog/x5gbnd5x6bxtge9lzw2u.png)

```javascript
encoded_payload = Base64.urlsafe_encode64(payload.to_json.encode("UTF-8")).delete("=")
=> "eyJ1c2VyX2lkIjoxLCJhZG1pbiI6dHJ1ZSwiZXhwIjoxNDgwNTMyMzI0fQ"
```

Once we have the unsigned token, we can generate the signature. We do this by hashing the secret key with the combination of the encoded header and encoded payload.

```javascript
key = 'secret'
=> "secret"
unsigned_token = encoded_header + "." + encoded_payload
=> "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoxLCJhZG1pbiI6dHJ1ZSwiZXhwIjoxNDgwNTMyMzI0fQ"
signature = OpenSSL::HMAC.digest("sha256", key, unsigned_token)
=> "E&\xEAZ/1\xC1'\x02H\xE6wQ\x06\x9B\x10\x14\x87$\xB0^\xF0\xFB\xA6\xCD\x92\xCFH\xAE\x85\xA1\xC2"
encoded_signature = Base64.urlsafe_encode64(signature).delete("=")
=> "VkD2JXzAP-hgpKbVX14gII8faO3NadRGyEWelQcg5Yo"
```

![A diagram of JWT Part three](https://res.cloudinary.com/echobind/image/upload/v1661874812/echobind_blog/fleper9keglw5n4c6td0.png)

> _You might wonder why we’ve been deleting ‘=’ characters. When you base64 encode a string, one or two ‘=’ signs might be added to pad the string out to the proper length. For JWT, these need to be removed as the signature will not be valid otherwise._

Making a JWT is as simple as joining the unsigned token with the signature with a period. For the above header and payload, we end up with the following token.

```javascript
 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoxLCJhZG1pbiI6dHJ1ZSwiZXhwIjoxNDgwNTMyMzI0fQ.VkD2JXzAP-hgpKbVX14gII8faO3NadRGyEWelQcg5Yo

```

> _Although the below demonstrates the process of creating a JWT in Ruby, JWT has been implemented in most_ [_languages_](https://jwt.io/)

## So What’s the Big Deal?

Let’s think about this concretely. Twilio just recently launched a video service where users can join a room to meet. Let’s say we launch the next great dating application, **Flair**. When people match, they can quickly connect over video conference on their mobile or desktop browser. We all know the world needs another dating app, but pictures just don’t cut it anymore. The thing is we need to make sure that only the potential couple can enter the conference room.

In short, we need a **secure**, short-term way to give access.

JWT solves this problem. The payload in this case might contain information about our Twilio API key and application ID. In fact, this is exactly the technique that [Twilio](https://www.twilio.com/docs/api/rest/access-tokens) uses for security. With an added expiry time, **Flair** can ensure that our lovebirds will have the privacy to talk about long walks on the beach, their favorite color, and make jokes about all the flair they used to wear at Chotchkie’s.

## Wait — how does it do that?

When attempts are made to connect to Twilio, our token is decrypted based on the header (which indicates which algorithm was used) and is validated against the secret string known only to our application and Twilio. If the payload was tampered with at any point, the signature would not match. The consuming application would consider the request invalid.

Now that’s what I call privacy.

---

[View on echobind.com](https://echobind.com/post/what-is-jwt-and-why-does-it-matter)

---

# Elixir & Phoenix Conf 2016 Recap — For the Love of Programming

> Sep 08, 2016 | Elixir and Phoenix conference 2016 recap, the community and the language continue to grow.

_By Robert Beene · 2016-09-08_

If you’re a developer, it’s pretty much a guarantee that you self-selected into your career path. For many, myself included, programming tapped into something that sparked a deep interest. Perhaps you’re a tinkerer — exploring the inner-workings of code and discovering all that is possible. Perhaps you’re a doer — empowered by the tools that programming puts in your hands.

Perhaps it’s simply for the love of programming.

Returning from Elixirconf 2016, I’m reminded that it can as simple as that. It can be the \[Nerves team\] (<https://twitter.com/NervesProject>) making embeddable software with Elixir. It can be [Lauren Tan](https://twitter.com/sugarpirate%5F) making the leap into full stack development from the front-end and learning what this language can do. It can be seen in the hallways as people hack away together.

![One sitting on the ground with their laptop and another person leaning over to look at their screen.](https://res.cloudinary.com/echobind/image/upload/v1661873048/echobind_blog/sq8zuvygwrglp6lx4upe.jpg)

The community continues to scale as well as the language does itself.

![A conference hall where many are raising their hands and the speaker taking a picture of the audience](https://res.cloudinary.com/echobind/image/upload/v1661874531/echobind_blog/spdugslms47pynxegipj.jpg)

We’re happy to be a part of the Elixir and Phoenix community, and we hope to see you in Bellevue next year. We’ll be releasing the full gallery of everything we captured in Orlando — minus the hurricane.

---

[View on echobind.com](https://echobind.com/post/elixir-phoenix-conf-2016-recap-for-the-love-of-programming)

---

# Leveling Up With Echobind

> May 05, 2016 | As a development agency, Echobind makes it a core tenet to be a friendly, helpful participant in the communities we operate in. We strive to level up everyone: not just our clients.

_By Robert Beene · 2016-05-05_

As a development agency, Echobind makes it a core tenet to be a friendly, helpful participant in the communities we operate in. We strive to level up everyone: not just our clients.

## Community

Many developers who are working with Ember today have a background in Rails. It’s so common in fact, Chris Ball started [From Rails to Ember](http://fromrailstoember.com/), a blog devoted to helping Rails developers make the leap to a powerful framework in JavaScript land.

In addition, we give back to our local communities by helping organize Ember Meetups in Boston and Louisville. So much of what people enjoy about Ember is the quality of the _community_. It’s easy to give back to a community that has given so much to us.

## Open Source

Do you love addons? We do. Once you’ve worked on a couple projects that implement the same type of behavior, you begin to appreciate the power of this ecosystem. With that in mind, we just released [Ember Links With Follower](https://github.com/echobind/ember-links-with-follower). Like a puppy that follows you around (or maybe a pirate), an underline border animates, following your currently active menu item. A rising tide lifts all boats and every technology we touch is no different.

## Training

Although these are great ways to give back to the community, we recognize that some companies need more hands-on learning. We’ve done trainings on both coasts in the US as well as in Canada, Costa Rica, and India. We also offer virtual training, allowing attendees from multiple locations to take part. It’s a new offering that we found to be an effective tool to reach a larger number of people with fewer logistical hurdles.

![A person with a laptop and a monitor sitting by a whiteboard and desk](https://res.cloudinary.com/echobind/image/upload/v1661874970/echobind_blog/dgtbinuwuiqgwgpoowsw.jpg)

## Level+= 1

Want to level up with Echobind? [Let’s talk](https://echobind.com/contact) about what you’re looking for. From basic to advanced, we’re able to assist in getting your developers up to speed with current best practices using this framework _and_ the community we enjoy so much.

---

[View on echobind.com](https://echobind.com/post/leveling-up-with-echobind)

---

# Recap of Ruby on Ales 2016

> Apr 10, 2016 | If you have the chance to go to Ruby on Ales, take it. You won’t be disappointed.

_By Michael Yared · 2016-04-10_

If you have the chance to go to Ruby on Ales, take it. You won’t be disappointed.

We had heard many great stories about a Ruby conference located in Bend, Oregon. This year, we made it a company goal to both attend and help sponsor the conference. We’re so glad we did.

We met up with old friends, made new ones, and visited one of the most beautiful parts of the country. The weather was cool, and the food was delicious. No complaints.

Oh, and did I mention the beer? There was plenty to drink of every variety. Ambers, blondes, hefeweizens, and IPAs where available from the moment you checked in until you went to bed. We even brought some of our own [favorite beer](https://twitter.com/TreeHouseBrewCo) along.

Here are a few photos from our time in Bend. We hope to see you there next year!

![Sitting by a campfire with a laptop](https://res.cloudinary.com/echobind/image/upload/v1661873343/echobind_blog/usppr2igdvuyu8m6jzel.jpg)

![A lake in Snohomish County known as Little Lake Martha](https://res.cloudinary.com/echobind/image/upload/v1661874143/echobind_blog/lhs4ptdwt2gn0bt8jrzi.jpg)

![Driving down a highway with a view of Mt. Hood National Forest](https://res.cloudinary.com/echobind/image/upload/v1661874150/echobind_blog/bloqzkhkvmgkwe3xvstx.jpg)

![The Tower Theatre in Bend, Oregon](https://res.cloudinary.com/echobind/image/upload/v1661874322/echobind_blog/owffrkkzovq9ybwbbhjx.jpg)

![A view of a lake from a park in Bend, Oregon](https://res.cloudinary.com/echobind/image/upload/v1661873703/echobind_blog/lmugzf5zvow7sv7uw5pw.jpg)

---

[View on echobind.com](https://echobind.com/post/recap-of-ruby-on-ales-2016)

---

# 40 Hours are Optimal

> It’s shocking how many people tell me they work for companies where 60 hour weeks are normal.

_By Michael Yared · 2016-03-15_

It’s shocking how many people tell me they work for companies where 60 hour weeks are normal. Many say that they are expected to always be on call and answer emails before and after work. Employees who simply put in 40 hours a week are looked down upon or penalized.

But should they be?

Ample research exists that show adding hours to an employees work week doesn’t yield more production. If the perception of working hard is what leads to more opportunities or a better bonus, it’s easy to see why employees are willing to fall in line. Perhaps we should then just follow George Constanza’s advice and always look annoyed.

> _“When you look annoyed all the time, people think you’re busy.” — George Constanza_

![Seinfeld George saying he's got lots to do!](https://res.cloudinary.com/echobind/image/upload/v1661874337/echobind_blog/clfn4bkwkua1gvh1s2ol.gif)

## Needing a Change of Pace

During an interview for an opening we had, we spoke with one individual who mentioned falling in the camp of mostly working 60+ hour weeks. The interviewee was looking for a new position because the current workload was not allowing for things that were important to the individual such as exercising and contributing to open source.

When we asked what was driving the 60 hour weeks, the answer was “deadlines”. Their next big corporate deadline was two months away. Think about that for a minute. A dev team of almost 20 people knew they had to work that long just to meet a deadline.

> _“Who estimated that job?” — Michael Yared_

We reassured the candidate that at Echobind, we can give back 20 hours a week because we limit our work week to 40 hours. Further, as a remote agency we can give back 5 hours a week as there is little to no commute. **Those 25 hours a week end up being 1,175 hours per year**. Put another way, over 48 full days were made available to learn, travel, exercise, sleep or do as they please!

## The Work Hard Badge

There are times when I like to feel exhausted. I know that after a long ride, I’ll be in better shape and ready to go further the next time. Unfortunately, this doesn’t translate to the business world as we should be training to work smarter, not longer. Working while exhausted leads to less output, more mistakes and worst of all: poor judgement. An [HBR article](https://hbr.org/2015/08/the-research-is-clear-long-hours-backfire-for-people-and-for-companies) on the subject cited how overworked employees even have trouble prioritizing work. They went on to say:

> _“In sum, the story of overwork is literally a story of diminishing returns: keep overworking, and you’ll progressively work more stupidly on tasks that are increasingly meaningless.” — Sarah Green Carmichael_

With all this being true, you still find that proud person proclaiming that they always work 80 hour weeks as though they want to be recognized for an achievement. No.

> _“Workaholics aren’t heroes. They don’t save the day, they just use it up. The real hero is already home because she figured out a faster way to get things done.” — Jason Fried_

For software developers, mistakes often times don’t show themselves for days. Worse for business owners, mistakes are costly. Programming is typically a team sport, and the actions of one person can lead to more work for everyone else. Being mentally and physically drained from overwork and lack of sleep doesn’t help you or anyone on your project.

So, the next time you hear someone bragging that they work 60, 70 or 80 hours a week, please tell them you’re sorry, and ask how you can help. If they don’t believe that they have a problem, point them to [experts](https://cs.stanford.edu/people/eroberts/cs181/projects/crunchmode/econ-hours-productivity.html) or [science](http://ftp.iza.org/dp8129.pdf) to help persuade them.

Work-life balance is a worthy cause. It’s less about how much you work, and more about how productive you can be while enjoying life.

---

[View on echobind.com](https://echobind.com/post/40-hours-are-optimal)

---

# The Real Costs of Not Keeping Software Current

> Dec 13, 2015 | Staying current is a developer’s lifeblood for future success. As new technologies come out and are mastered by more people, the cost to hire a developer with that skill set naturally goes down.

_By Michael Yared · 2015-12-13_

Have you ever been in an interview, either as the employer or a candidate, and felt the cringe occur when the developer is told that the software stack the company is running on is years out-of-date? It’s incredibly awkward. Any positive momentum that the conversation had is abruptly halted as the developer is now mentally weighing compensation or job security against dealing with legacy software.

Staying current is a developer’s lifeblood for future success. As new technologies come out and are mastered by more people, the cost to hire a developer with that skill set naturally goes down. The best developers will typically take their knowledge and move on to the next big thing to continue commanding the best rates and improving their skill sets. But not many want to be a maintenance programmer.

## Why do upgrades take a back seat?

Many companies will say that it takes time away from feature sprints. Others might consider it difficult to potentially leave behind current customers with old, out of date browsers. But the biggest reason we’ve found is that companies do not appreciate the true cost of not upgrading. Not keeping your software current means:

1. The company’s ability to hire new developers is hampered
2. Existing developers begin to look for new opportunities
3. Features, that may otherwise be simple, take much longer to ship
4. Technical debt builds at a faster pace.

If this sounds like your company, don’t worry. It’s pretty common.

We can help. Our team will put together a realistic plan to bring your software stack current without losing time for valuable feature sprints. For more information on how our team can integrate with yours, see our [our playbook](https://echobind.com/playbook) for how we work or [contact us](https://echobind.com/contact) to setup a quick phone call.

Remember that the longer you wait, the harder the upgrade will be.

---

[View on echobind.com](https://echobind.com/post/the-real-costs-of-not-keeping-software-current)