DEV Community: Shahar Kedar

Thoughts on using ChatGPT in job interviews

Shahar Kedar — Fri, 07 Jun 2024 08:52:59 +0000

A software developer friend told me yesterday that she had a job interview where she had to do live coding and was not allowed to use ChatGPT. She could search Google for what she needed, but not ask ChatGPT or similar tools. I'm not a big fan of live coding in the first place, but fine. But not using ChatGPT? Why? In my opinion, it's simply a lack of understanding of what the required skillset for developers is in the ~~future~~ present. To me, it's equivalent to asking in an interview to code in a text editor instead of an IDE. Let me explain.

A few days ago, a new article was published in The Pragmatic Engineer where he talks about AI Software Agents. Software agents know how to use language models to solve software problems autonomously and almost without human intervention. In a recent experiment conducted by researchers at Princeton University, software agents were able to correctly solve 12.5% of the tickets given to them completely independently. That's crazy. And this is after just 6 months of work by a team of only 7 people. Imagine what a company like Cognition Labs (the company behind Devin.ai), which received $175 million in funding, will manage (or already has) to do in the same timeframe.

Note that I wrote that software agents worked "almost" without human intervention. It seems that at least for now*, there are two places where human involvement is required - (1) defining the problem and (2) reviewing the solution. It also appears to be an iterative process where (1) and (2) run in a loop until a good enough solution is reached. As of today, the people who have the most suitable skillset and knowledge to operate software agents are ...drum roll... developers.

How does all this relate to job interviews? Even if we work with Princeton's numbers, it effectively means that the rate of solving at least 12.5% of software companies' software problems can be accelerated by orders of magnitude. In other words, all other things being equal, a company that encourages its developers to use software agents has a significant advantage over a company that doesn't. And if that is indeed the case, then a company that does not test the ability of developers to actively use tools like ChatGPT is effectively missing a critical skillset for the company's success.

By allowing the use of ChatGPT, the screening process would simulate a more realistic development scenario. Candidates could engage the AI assistant as they would when actually working, using it as a knowledgeable resource and collaborator to help break down problems, propose solutions, and refine their code.

The true skills being evaluated then become the abilities to properly frame problems, ask the right questions, and critically analyze the information or code snippets provided by ChatGPT. These higher-level skills of problem decomposition, communication, and critical thinking are arguably more important than brute memorization of syntax and algorithms.

I'm betting that even this will be replaced by AI agents in the near future, but that's for another post. Maybe.

Potential objections

(Thanks to David Shimon for raising interesting objections)

Objection #1:

When we interview developers, we're not looking to test if they know how to use ChatGPT because that's relatively easy and we assume they'll be ok with it. On the other hand, using ChatGPT might mask other abilities that the candidate may be lacking. If we use the IDE analogy, in an interview it's not interesting to test if the candidate knows how to use an IDE as it is to see them write code.

I disagree with this objection on several levels:
First, using ChatGPT is easy. But using it effectively isn't. At least for now, developers need to make sure ChatGPT doesn't hallucinate too much, writes quality code, and one that's suited to the technologies used at the company. Crafting the right prompt and improving it iteratively is no easy task.

Like I said, observing a candidate use ChatGPT live can provide valuable insights into their thought process. I argue that incorporating ChatGPT into the interview presents a better opportunity to assess how a candidate approaches problems than a traditional coding exercise. The focus shifts away from merely testing technical coding proficiency towards evaluating problem-solving skills, code review abilities, and the iterative refinement of solutions. With a sufficiently complex exercise, the interviewer could dive into more advanced aspects of programming that are seldom explored when a candidate must write all the code from scratch.

Lastly, live coding is a rather stressful setting already and necessarily time-boxed. In such a session, we want to lower as many barriers as possible that would unnecessarily slow the candidate down without being related to their day-to-day work.

Objection #2:

Many companies already have tried-and-tested exercises for screening candidates, but using ChatGPT would make them too easy. Starting to modify exercises just to allow ChatGPT isn't worth the investment.

This argument is irrelevant for new companies or those seeking to update their existing coding exercises. In my experience, many companies don't stick to a single exercise for years; instead, they adapt it to align with rapidly evolving technology requirements. As for the remaining companies, if their exercise can be easily solved using ChatGPT, it may indicate that the exercise is evaluating the wrong skills. For instance, numerous companies today assess algorithmic knowledge through "LeetCode"-style problems, which are rarely applicable to the day-to-day tasks of 99% of programmers. While ChatGPT, assuming no hallucinations, can trivialize such algorithmic questions, one must question the value these questions provided in the first place.

Have more objections? Drop a comment!

TIL: What is a Balint group?

Shahar Kedar — Sat, 25 May 2024 07:49:10 +0000

Yesterday, my wife casually mentioned a term I wasn't familiar with - Balint group. A Balint group is a method of clinical supervision for doctors, started by the psychoanalysts Michael and Enid Balint in the 1950s in London. The aim is to help doctors better understand the psychological and emotional aspects of the doctor-patient relationship. In a Balint group session, a doctor presents a case involving a challenging patient. The group discusses the emotional dynamics and tries to understand the patient's inner experience and motivations, rather than focusing just on medical solutions.

It wouldn't be the first time I learned something new from my wife. What was surprising to me was that, without really knowing, I had participated in a form of a Balint group for two years and led one myself for the past year as part of an initiative called Downleft. I just never realized there was a professional term for what we were doing.

In Downleft, we form peer groups (e.g., tech leads) from different tech companies that meet on a monthly basis and share dilemmas from their work. Each session, a different participant presents a dilemma or a challenge they have, and a lot of what's happening next is not discussing solutions (which is something tech people love to do), but rather surfacing the organizational and personal dynamics that underpin the situation.

The meeting format is as follows: the presenter gives a 5-10 minute overview of their dilemma, then we go around the table and do a "questions round". During this round, participants are allowed only to ask questions and not give any other input. Once the round is over, we do another round where participants can give their input, share their experiences, or offer tips.

I've noticed two kinds of dynamics that are super interesting to see. Firstly, the questions round is no less useful than the second round. I've seen presenters starting to deeply reflect on their situation and come up with meaningful insights only by answering questions. Secondly, other members of the group often share their own similar dilemmas, validating many of the feelings and frustrations the presenter is having. I'm always amazed by how powerful this peer-validation process is.

I'm pretty sure that when Downleft was conceptualized by Oren Ellenbogen, he was not aware of Balint groups, but the similarity is so striking that I would have to ask him if he was inspired by it. Surprisingly, Downleft is pretty unique in the tech industry. One would expect that such a simple and powerful format would be more widely adopted, but I'm pretty sure that is not the case. If you're reading this and familiar with similar types of groups, please leave a comment!

Why chess super computers do not excite me, but LLMs do

Shahar Kedar — Fri, 17 May 2024 17:29:16 +0000

This post is my humble attempt to share a random "shower thought."

Chess is an amazing game. For me, it's one of the top strategy games ever invented. So why am I not excited when I think about chess supercomputers? Why am I not amazed by this grand technology the same way I'm amazed by grandmasters?

I think the answer is that chess supercomputers have only a single application - playing chess. [Chess software is also great for learning chess, but I'm pretty sure you don't need a supercomputer to learn chess. Just to beat grandmasters. Please prove me wrong.]

But wait, there are many inventions that have only a single application that are exciting (e.g., penicillin), so what's the difference? The difference is that it's quite impressive to see people playing chess at the highest level, while it's not really impressive (for me) to see a computer playing chess at the highest level. Just like it doesn't impress anyone (anymore) that computers run complex arithmetic computations at the blink of an eye.

LLMs, on the other hand, are very exciting. Language is another skill that humans possess that, up until recently, was hard for computers to successfully imitate. To some extent, LLMs can do amazing things with language that humans can't (or can't do as fast as computers). However, what's more exciting to me is the countless applications that humans can build on top of LLMs. It was amazing to hear the hubbub of ideas thrown around the office, on social networks, or practically everywhere I went when people started to use ChatGPT. It felt as if humans unlocked something in their minds that up until that point was only constrained by their imagination. For me - that's beautiful (as well as terrifying, but that's for a different post).

Avoid stupid mistakes with type Branding and Flavoring

Shahar Kedar — Sun, 07 Apr 2024 05:49:12 +0000

In a structural type system like TypeScript, functions that accept multiple arguments of the same type can sometimes lead to unexpected behavior. This is because TypeScript only considers the structure of the arguments, not their explicit type names, when determining type compatibility.

Here's an example that illustrates this potential issue:

type BlogId = string;
type PostId = string;

async function getPost(blogId: BlogId, postId: PostId) {
  return posts.findOne({ blogId, postId });
}

// this code line compiles, but doesn't work correctly
const result = await getPost(postId, blogId);

What can we do about it?

Thanks to David, a colleague of mine, I've recently learned about two new techniques to avoid this problem - Branding and Flavoring.

Branding

Branding in TypeScript is a technique that allows you to create distinct types from any existing type, whether it's a primitive type (like string, number, or boolean) or a complex type (like an object, interface, class, or function). Branding is a form of nominal typing, which contrasts with TypeScript's default structural typing behavior.

With branding, you can introduce nominal typing for specific types in your codebase, ensuring that values representing different concepts or entities cannot be mixed accidentally, even if they share the same underlying structure or primitive type.

Let's see how this is done with our previous example:

// Branding a string
type PostId = string & { __brand: 'PostId' };
type BlogId = string & { __brand: 'BlogId' };

const postId: PostId = 'post-123' as PostId;
const blogId: BlogId = 'blog-456' as BlogId;

async function getPost(blogId: BlogId, postId: PostId) {
  return posts.findOne({ blogId, postId });
}

// Doesn't compile
const result = await getPost(postId, blogId);

In this example, we brand the string type by using an intersection type with an object literal that has a special __brand property. PostId and BrandId are distinct branded types, even though their underlying primitive type is string.

If we are using an input validation library like Zod, we can avoid casting when branding values:

const PostId = z.string().brand('PostId');
const BlogId = z.string().brand('BlogId');
// Branding a string
type PostId = z.infer<typeof PostId>
type BlogId = z.infer<typeof BlogId>

const postId: PostId = PostId.parse('post-123');
const blogId: BlogId = BlogId.parse('blog-456');

(checkout my blog posts series on Zod if you are not familiar with it)

While branding is useful for preventing careless mistakes, such as passing an incorrect value to the wrong positional argument of a function, it is not a foolproof solution It merely shifts the responsibility of properly constructing and branding values to the point where they are created. We can still make mistakes at that stage and inadvertently brand an incorrect value.

The problem with Branding

Branding has one caveat: we can no longer assign values to variables directly without 'blessing' them, either through casting or using a library like Zod. This can be problematic when writing tests or working with auto-generated code. For example:

type PostId = string & { __brand: 'PostId' };
const postId = "abc"; // This code doesn't compile

This issue is thoroughly explained in this great article and I highly recommend reading it. In the article, we are introduced to the Flavor solution. In short, flavoring is similar to branding but allows implicit conversion, addressing the issue we discussed earlier:

type Flavoring<FlavorT> {
  _type?: FlavorT;
}
type Flavor<T, FlavorT> = T & Flavoring<FlavorT>;
type PostId = Flavor<string, 'PostId'>;
const postId: PostId = "abc"; // This code compiles

type BlogId = Flavor<string, 'BlogId'>;
const blogId: BlogId = postId; // But this still doesn't

Why this works is perfectly explained in the original article, so I'll just quote it:

TypeScript won’t let us mix our ID types because, under the hood, the _type properties are incompatible. The optional string "PostId" is not assignable to the optional string "BlogId". But because the _type is optional, implicit conversion from unflavored values of the same underlying type is allowed. Once implicit conversion happens, however, TypeScript will henceforth treat the value as potentially having the declared _type and disallow mixing with other, differently flavored types. Thus, downstream consumers of the value will get the safety and semantic benefits.

Using Flavor with Zod

An immediate question arises: can we use Flavors with Zod? When using Zod, we first define a schema, and then infer types based on that schema. How can we use the Flavor type we wrote above as part of our Zod schemas?

To achieve that, we need to understand refining in Zod. Zod's refine method allows you to define a custom validation function for a schema, enabling you to enforce more complex validation rules beyond the built-in validations provided by Zod.

Here's a basic example of using Zod's refine method:

import { z } from 'zod';

// Define a schema for a user's age
const ageSchema = z.number().refine(
  (age) => age >= 18,
  { message: 'User must be at least 18 years old' }
);

// Usage
try {
  const validAge = ageSchema.parse(20); // Valid age
  console.log(validAge); // Output: 20

  const invalidAge = ageSchema.parse(16); // Invalid age
} catch (error) {
  console.error(error.message); // Output: User must be at least 18 years old
}

The first argument of the refine method is a function that accepts a single argument, the validated input - a number in this case, and returns a boolean. Interestingly, if we pass a Type Guard function, the parsed input type is narrowed based on the type predicate defined for the type guard.

type BlogId = Flavor<string, 'BlogId'>;
function isBlogId(id: string): id is BlogId {
  return !!id;
}
const BlogIdSchema = z.string().refine(isBlogId);
// The type of value is BlogId and not string
const value = BlogIdSchema.parse("123");

Summary

TypeScript is a structural type system, meaning it doesn't prevent us from passing an incorrect value to a function if the value's type matches the function parameter's type. A common technique to address this issue is Branding, which distinguishes between values with the same structure. While branding is useful, it makes value construction somewhat cumbersome. Flavoring is a more advanced approach that allows implicit conversion for easily constructing values while maintaining type safety. Zod provides built-in support for Branding. For Flavoring, we need to leverage type guard functions and Zod's refine method.

Schema Extension and Reuse

Shahar Kedar — Sat, 30 Mar 2024 11:23:46 +0000

TypeScript truly shines in large projects where we frequently encounter a wide array of complex types. To tackle such complexity, two commonly used strategies are inheritance and composition. These approaches encourage code reuse by allowing us to leverage existing functions and types across different code paths. By doing so, we establish a single source of truth for business logic and data models, fostering consistency and maintainability throughout the codebase.

Inheritance vs Composition

Inheritance is a concept where a new type (child) inherits properties and methods from an existing type (parent). On the other hand, composition is a way of combining types or objects together into a new type.

For example, let's say we have a Person type and an Employee type that extends from Person. With inheritance, Employee inherits all properties and methods from Person, and we can add additional properties or methods specific to Employee. This is achieved using the extends keyword:

class Person {
  name: string;
  age: number;
}

class Employee extends Person {
  employeeId: string;
  salary: number;
}

With composition, we create new types by combining existing types together. Instead of inheriting properties from a parent type, we create a new type that contains instances of other types as properties. This is often done using object literals or interfaces:

interface Address {
  street: string;
  city: string;
  state: string;
}

interface PersonDetails {
  name: string;
  age: number;
  address: Address;
}

In the above example, the PersonDetails type is composed of properties like name and age, as well as an instance of the Address type.

Just like in TypeScript, Zod also enables us to reuse schemas whether by extending them or composing them.

The .extend() Method

The core of Zod's extension functionality is the .extend() method available on every schema instance. This method allows us to create a new schema based on an existing one while adding, removing, or transforming properties.

Here's a basic example:

import { z } from 'zod';

const Base = z.object({
  name: z.string(),
  age: z.number().positive(),
});

const ExtendedSchema = Base.extend({
  email: z.string().email(),
});

type ExtendedType = z.infer<typeof extendedSchema>;
// Equivalent to { name: string; age: number; email: string; }

In the example above, we start with a Base that defines name and age properties. We then use .extend() to create a new schema ExtendedSchema that includes all properties from Base and adds an email property.

Beyond adding new properties, .extend() also allows us to override existing properties from the base schema. This can be useful when we want to apply additional validation rules.

const OverriddenSchema = Base.extend({
  age: z.number().int().positive(),
});

Here, we extend Base but override the age property to enforce that it must be a positive integer.

The .pick() and .omit() Methods

Sometimes, we may want to create a new schema by picking or omitting certain properties from an existing schema. Zod provides the .pick() and .omit() methods for this purpose.

const PickedSchema = Base.pick({ name: true });
// Equivalent to z.object({ name: z.string() })

const OmittedSchema = Base.omit({ age: true });
// Equivalent to z.object({ name: z.string() })

Schema Composition

The simplest form of schema composition, is using existing schemas for defining properties of other schemas:

import { z } from 'zod';

const Address = z.object({
  street: z.string(),
  city: z.string(),
  state: z.string(),
});

const PersonDetails = z.object({
  name: z.string(),
  age: z.number(),
  address: Address,
});

Zod also allows us to merge multiple schemas together using the .merge() method. This can be handy when we have different schema fragments that we want to combine.

const Schema1 = z.object({ name: z.string() });
const Schema2 = z.object({ age: z.number().positive() });

const MergedSchema = Schema1.merge(Schema2);
// Equivalent to z.object({ name: z.string(), age: z.number().positive() })

Alternatively we can use the .and method to create a slightly more readable code:

const MergedSchema = Schema1.and(Schema2);

Merge vs Extend

When should we use merge and when extend? We can always use merge instead of extend. However, in many cases, it would be an overhead to define an independent schema just to extend an existing schema. If, however, the extension is likely to be used independently, we should probably use merge from the beginning.

Extending Union Schemas

In the previous chapter we talked about Zod unions and discriminated unions. One gotcha with unions is that they lack the .extend method. So how do we extend union schemas? We use the .and method:

const Success = z.object({ type: z.literal('success'), code: z.number() })
const Error = z.object({ type: z.literal('error'), message: z.string() })

const Result = z.discriminatedUnion('type', [Success, Error])
// The following code does not compile
// const HttpResult = Result.extend( { httpStatus: z.number()}) 

// Use .and instead
const HttpResult = Result.and(z.object({httpStatus: z.number()}))

Summary

Schema extension through inheritance and compositions is a powerful feature allowing us developers to really use Zod as a single source of truth for our types.

Union Types

Shahar Kedar — Tue, 26 Mar 2024 19:25:33 +0000

In previous chapters I used pretty rudimentary schemas that involved mostly primitives. In reality our code is going to be much more complex, requiring complicated schemas to represent possible input.

The next few chapters will deep dive into some more complex schema examples. We will start with union types.

What are union types good for?

Union types are used to express a value that can be one of several types. There are many examples for the usefulness of union types:

A function parameter that can be either a string or a number can be defined using a union type as string | number. This is especially useful when dealing with values that might come from different sources or in different formats but can be handled by the same piece of code.

function formatAmount(amount: string | number) {}

They are ideal for modeling data structures that might hold different types under different conditions. For example, we might have a response from an API that can either be an object representing data or an error message string. In fact, we can see this pattern in Zod's safeParse API:

safeParse(data: unknown): SafeParseSuccess<Output> | SafeParseError<Input>;

We can achieve type structure polymorphism with union types. This is very powerful combined with type narrowing, enabling a form of runtime type inspection and branching logic that resembles polymorphic behavior in traditional OOP, where different code paths can be taken based on the actual type of an object.

type Animal = Dog | Cat | Bird;
type Dog = { type: "dog"; bark: boolean };
type Cat = { type: "cat"; meow: boolean };
type Bird = { type: "bird"; chirp: boolean };

function makeSound(animal: Animal): string {
  switch (animal.type) {
    case "dog":
      return animal.bark ? "woof" : "whimper";
    case "cat":
      return animal.meow ? "meow" : "purr";
    case "bird":
      return animal.chirp ? "chirp" : "tweet";
  }
}

Defining union schemas with Zod

Just like with types, we can create schemas which are a union of two or more schemas:

const StringOrNumber = z.union([z.string(), z.number()]);

For convenience, you can also use the .or method:

const StringOrNumber = z.string().or(z.number);

Unions are not reserved only to primitive types. You can easily create a union of objects:

const Success = z.object({ value: z.string() });
const Error = z.object({ message: z.string() });
const Result = z.union([Success, Error]);

Discriminated unions

Zod unions are useful but not very efficient. When we evaluate a value against a union schema, Zod will try to use all options to parse it, which could become quite slow. Not only that, if it fails, it will provide all the error from all the validations.

For example, if we run the following code:

Result.parse({ foo: 1 });

We will get the following error:

ZodError: [
  {
    "code": "invalid_union",
    "unionErrors": [
      {
        "issues": [
          {
            "code": "invalid_type",
            "expected": "string",
            "received": "undefined",
            "path": [
              "value"
            ],
            "message": "Required"
          }
        ],
        "name": "ZodError"
      },
      {
        "issues": [
          {
            "code": "invalid_type",
            "expected": "string",
            "received": "undefined",
            "path": [
              "message"
            ],
            "message": "Required"
          }
        ],
        "name": "ZodError"
      }
    ],
    "path": [],
    "message": "Invalid input"
  }
]

Discriminated unions provide a more efficient and user friendly way for parsing objects, by allowing us to define a discriminator key to determine which schema should be used to validate the input.

const Success = z.object({ status: z.literal("success"), value: z.string() });
const Error = z.object({ status: z.literal("error"), message: z.string() });
const Result = z.discriminatedUnion("status", [Success, Error]);

In the above example, we use the status property to discriminate between different input types. Let's see what happens now when we try to validate against an invalid input:

Result.parse({ type: "success", foo: 1 });

This time we get a concise error:

ZodError: [
  {
    "code": "invalid_type",
    "expected": "string",
    "received": "undefined",
    "path": [
      "value"
    ],
    "message": "Required"
  }
]

Another fun part of using discriminated unions is that we can now use type narrowing to handle inputs:

const result = Result.parse(input);
switch(result.status) {
  case "success": console.log(result.value); break;
  case "error": console.error(result.message); break;
}

A word of warning: while discriminated unions are very powerful, there's an ongoing discussion on whether discriminated unions should be deprecated and replaced with a different API.

Summary

Union types in TypeScript is a powerful way of expressing type variability. Zod enables us to define union schemas quite easily. We should consider using discriminated unions in Zod for better performance and user friendly errors.

In our next chapter we will explore schema extension.

Thoughts on Pair Programming

Shahar Kedar — Sun, 24 Mar 2024 19:29:29 +0000

I am currently leading a team of four very talented engineers, and we started practicing pair programming more often in the past few months. To be completely honest, my initial motives for pairing was mostly personal growth. I was happy to see though that not only was my team happier, but they were also more productive. I've known and practiced pair programming a lot in the past, but only recently have I given it some more serious thought.

A lot has been written over the years about pair programming. I'm not even sure if this is still a "thing" or a long-forgotten practice (if you're practicing this regularly, do tell!). But since people keep writing about it, I'll assume it's live and kicking. Unfortunately, the general vibe is that some people need to convince other people that pair programming is productive.

Honestly, I don't want to be part of the conversation. If you're not convinced that there's some merit to pair programming, you're welcome to stop reading now. I'm here to preach to the choir - because honestly it's more fun - and talk about something else: when does it make sense to pair with someone?

Certainty

As engineers we need to deal a lot with (un)certainty. Sometimes our job is to take a well defined task and implement it in a well defined architecture - high level of certainty. I would argue that in those cases we want to optimize for execution time. The quicker it gets into production and into the hands of customers the better.

In other cases, we receive a task with a lot of uncertainty. Either the task is not well-defined technically or from a product perspective, the architecture does not exist or doesn't fit, or there are other risks we identify early on. In my opinion, in those cases we want to optimize for clarity.

"Wait what? Why not also execution time?" you might ask. You wouldn't be wrong. As a business, especially as a startup, we always want to deliver as fast as possible. BUT there's also a price for running too fast especially with high degree of uncertainty. We might deliver the wrong thing, deliver a buggy or a poorly performant feature. We might, god forbid, have to write it all over again. And that affects execution time in a very sneaky way that's hard to identify and mitigate.

So... creating clarity. I think that should be our number one priority. Turn uncertainty into certainty as fast as possible so we can get back to optimizing execution time.

Pair programming in high certainty tasks

There are two cases, in my opinion, when pairing in high-certainty tasks makes sense:

The engineer who owns the task is not proficient enough - this usually happens with junior developers. Even though the task is well defined and poses little risk, there's a chance that a junior engineer will still not do it fast enough. Since we're optimizing for execution time, we need to find a solution. IMHO pair programming is an amazing solution for that. Not only it reduces deliver time, it also increases the junior developer's mastery - 2 at the price of 1.
The engineer who owns the task is proficient but not familiar with the code base - in this case pair programming has a simple goal: reduce ramp up time. Depending on the case, we could restrict the pairing to last only until the owner "gets it" and can continue solo.

Pair programming in low certainty tasks

Here the level of proficiency or knowledge plays a significantly smaller role. It is my belief that it's always worth pairing on low certainty tasks. Pairing serves different purposes:

Quickly identifying blindspots - many engineers tend to simply start writing code as a way of thinking about their task. I know I do that a lot. This often creates a "tunnel vision" where we think more about the code we're writing then the task we were given. Having another brain that's not occupied with writing code, really helps surface blindspots early on.
Fast feedback loop - one of the biggest advantages of pair programming in general is that we have a partner with whom we can bounce ideas around and zero in on the right solution quickly. With low certainty tasks we need that level of feedback and creativity, because we're almost sure to reach obstacles a lot. When there's no dedicated person to work with, we often spend a lot of idle time waiting for someone to become available.
Psychological commitment - sometimes when we're faced with a really difficult task, we tend to wander to other tasks on our plate that are easier (or death-scrolling on social media apps). This behaviour creates a lot of context switching and lengthens delivery times. When pairing we are committed to working on the task at hand. We have little chance to lose our focus. We also have the ability to switch roles if we become tired.

All of the above can significantly reduce delivery time while increasing quality. Theocratically, we could have done two different tasks in parallel - but the result would have been poorer and not necessarily faster.

What now?

Now I need to start practicing what I preach. I'm going to try and intentionally use the "certainty" criteria to decide if pair programming is necessary. I'm also going to try and find other criteria that I can apply consistently. I would love to hear your thoughts - what criteria do you use?

Input Sanitation

Shahar Kedar — Fri, 22 Mar 2024 07:06:52 +0000

Zod has a really nice feature that allows us to define, for schemas that describe objects, how properties not defined in the schema should be treated. We can choose one of 3 modes:

Strip: Zod will strip out unrecognized keys during parsing. This is the default behaviour.
Passthrough: Zod will keep unrecognized keys and will not validate them.
Strict: Zod will return an error for any unrecognized key.

All three modes have their uses, but in this post I will focus on strip and strict, who can help with what is called "Input Sanitation".

What is input sanitation?

Input sanitation is a critical security practice aimed at preventing malicious users from injecting harmful data into our software. This practice involves validating and cleaning up the data received from the user before processing or storing it.

Example scenario: unauthorized account modification

Imagine a web application that allows users to update their profile information, including their email but not their user role, which is intended to be controlled only by administrators. The application receives an object with the fields to be updated and directly passes it to the database query without properly sanitizing the input to remove or restrict fields.

Vulnerable code snippet:

app.post('/updateProfile', function(req, res) {
    // Assuming req.body is something like {email: "newemail@example.com"}
    const updates = req.body;
    const userId = req.session.userId; // The ID of the currently logged-in user

    // Update the user profile with the provided fields
    db.collection('users').updateOne({ _id: userId }, { $set: updates }, function(err, result) {
        if (err) {
            // handle error
        } else {
            // success
        }
    });
});

An attacker discovers this endpoint and decides to send a modified request that includes an additional property, role, in an attempt to escalate their privileges:

{
    "email": "attacker@example.com",
    "role": "admin"
}

By sending this payload, the attacker could potentially change their user role to "admin", assuming the application does not properly check the fields that are being updated. This happens because the database command directly uses the object from the request, allowing any properties provided to be included in the $set operation.

How can Zod help?

We can use one of the modes mentioned above to prevent this attack. Let's see what would be the behavior of each mode:

Strip

Strip is the default mode of every schema and does not require any explicit configuration. We can change the vulnerable endpoint above in the following way:

const Updates = z.object({
  email: z.string()
})
app.post('/updateProfile', function(req, res) {
    const updates = Updates.parse(req.body);
    // log updates to see the result
    console.log("You shall not pass!", updates);
    const userId = req.session.userId; 

    // Update the user profile with the provided fields
    db.collection('users').updateOne({ _id: userId }, { $set: updates }, function(err, result) {
        if (err) {
            // handle error
        } else {
            // success
        }
    });
});

Now when an attacker sends the following body:

{
    "email": "attacker@example.com",
    "role": "admin"
}

Zod will strip the role property from the body before passing it on to the update statement. We should expect to see the following log:

You shall not pass! { "email": "attacker@example.com" }

Strict

We can also configure a schema to be strict, causing unrecognized keys to throw an error:

const Updates = z.object({
  email: z.string()
}).strict()
// ... rest of code

Now calling the endpoint with the malicious payload will result in the following error:

ZodError: [
  {
    "code": "unrecognized_keys",
    "keys": [
      "role"
    ],
    "path": [],
    "message": "Unrecognized key(s) in object: 'role'"
  }
]

In the context of input sanitation for security, using strict could be useful if we are looking to identify security breaches attempts as they happen.

Another interesting option is to use a mix of strict and strip:

const Updates = z.object({
  email: z.string()
})
const StrictUpdates = Updates.strict();
app.post('/updateProfile', function(req, res) {
  const parseResult = StrictUpdates.safeParse(req.body);
  if (!parseResult.success && parseResult.error.issues.some(issue => issue.code === ZodIssueCode.unrecognized_keys)) {
    console.error("Unrecognized keys in updates");
  }
  const updates = Updates.parse(req.body);    
  console.log("You shall not pass!", updates);
  // ... rest of code
});

Notice that usage of safeParse instead of parse when using the StrictUpdates schema. safeParse allows us to validate input without throwing an error in case the input is invalid. In this case we use safeParse to identify and log unrecognized keys, but not fail the request.

Summary

Input sanitation is a very common and important security measure. Zod can help sanitize inputs in different ways - by silently dropping unrecognized keys or by throwing errors.

Next chapter we will learn how to define union types with Zod.

Input Validation

Shahar Kedar — Sun, 17 Mar 2024 07:25:34 +0000

On the previous chapter I used a boring example for using Zod. It was boring because there was no external input involved. Zod is useful when we need to deal with data, whose shape (and therefore type) is only determined in runtime and the TypeScript compiler can't keep us safe. A very common example is when handling incoming HTTP requests. For example:



const UserSchema = z.object({
  name: z.string(),
  age: z.number(),
  email: z.string().email(),
});
type User = z.infer<typeof UserSchema>;

async function createUser(req: Request, res: Response): Promise<void> {
  const userData: User = UserSchema.parse(req.body);
  const newUser = await saveUser(userData);
  res.json(newUser);
}

We get two main benefits by using Zod:

We can validate our input using Zod's built-in and tested validation logic. The createUser function will fail if the email property contains a random string.
userData is typed. We don't need to use casting (god forbid!) to work with the correct type in our application logic.

Why should I care about input validation?

Well... there are many good reasons but for starters it keeps your code secure, preventing code injection hacks and the like, but it also keeps you code less prone to unusual bugs. I feel like security has been discussed a lot so I'm not going to talk about that here. But the latter reason is as important IMHO.

There are a few questions we should ask ourselves:

Where do we rather catch an error?

I would argue that it's best to catch an error as close as possible to the source of the error. If the code is very simple, that might not be important, but if we run complex logics and/or transactions, catching the error at the beginning might prevent weird or critical bugs related to state inconsistency etc.

What kind of error do we prefer?

If you've been working with JavaScript for a while you're probably familiar with the infamous "Uncaught TypeError: Cannot Read Property of Undefined" error. I really hate when that happens! And really it could be easily avoided with Zod and the right schema.

Lets see this in action. First we'll change our HTTP handler to not use Zod and run some basic logic:



async function createUser(req: Request, res: Response): Promise<void> {
  const user: User = req.body;
  processEmail(user);
  res.status(200).end();
}

function processEmail(user: User) {
  if (user.email.split("@")[1].endsWith("gmail.com") {
    doSomethingGoogly(user);
  } else {
    doSomethingElse(user)
  }
}

What kind of error would we get if req.body doesn't contain an email?



TypeError: Cannot read properties of undefined (reading 'split')

Did I already mention that I hate this error? 🤬

What kind of error would we get with Zod?



ZodError: [
  {
    "code": "invalid_type",
    "expected": "string",
    "received": "undefined",
    "path": [
      "email"
    ],
    "message": "Required"
  }
]

Nice!

Summary

Zod becomes useful when you need to validate external input. One very common use case is when handling incoming HTTP requests. Zod is cool because it infers types out of schemas and allows you to use those types in your business logic. Assuming your schema is correct, the TypeScript compiler guarantees that correct input will be handled correctly. No surprises.

Input validation is important because it prevents bugs from happening deep in our code and provides meaningful error messages that's easier to understand and solve.

Next chapter would be on how to sanitize incoming HTTP requests with Zod.

Introduction to Zod

Shahar Kedar — Wed, 13 Mar 2024 06:56:55 +0000

I was first introduced to Zod by Adam Bobrow - a colleague of mine and a dear friend. Adam was sick and tired from JavaScript's brittleness, and about two years ago he started migrating our code base to TypeScript. But that wasn't enough for him. He kept complaining: "What good are my types, if some other service decides to send me bad data and breaks my code?". That's when he discovered Zod.

At first I thought: "Yah yah, yet another input validation library. We already use Joi." 5 minutes later I was convinced. Zod was not yet another input validation library. It does something extra, but very important, that other libraries don't do - it infers types out of schemas 🪄 .

The purpose of this series is to walk you through using Zod from the very basics to plugging it into every I/O operations your system does - making it de-facto strongly typed.

What is Zod?

Zod is a TypeScript library used for creating schemas to validate data types. It helps ensure that the data our program receives or works with matches the expected format, like checking if a variable is a number, a string, or a more complex object with specific properties. Zod is particularly useful because it's designed with TypeScript's type system in mind. It allows developers to define schemas that not only validate the shape and type of data at runtime but also automatically infer TypeScript types from these schemas.

Let's look at a basic example:



import { z } from 'zod';

// Define a schema for the user
const UserSchema = z.object({
  name: z.string(),
  age: z.number(),
  email: z.string().email(),
});

// Create a user data object to validate
const userData = {
  name: 'John Doe',
  age: 30,
  email: 'john.doe@example.com',
};

// Validate the user data against the schema
const validationResult = UserSchema.safeParse(userData);

if (validationResult.success) {
  console.log('Validation succeeded:', validationResult.data);
} else {
  console.log('Validation failed:', validationResult.error);
}

The above example is not very exciting since it's not that different from what we could do with other validation libraries. To make it interesting, let's add some type inference to the mix.



import { z } from 'zod';

// Define a schema for the user
const UserSchema = z.object({
  name: z.string(),
  age: z.number(),
  email: z.string().email(),
});

// This is where the magic happens..
type User = z.infer<typeof UserSchema>;

// Create a user data object to validate
const userData = {
  name: 'John Doe',
  age: 30,
  email: 'john.doe@example.com',
};

// Validate the user data against the schema
const user: User = UserSchema.parse(userData);

Notice how Zod automatically inferred the type User out of UserSchema. Why is that a big deal? Because it creates a single source of truth for all our types and enforces any external input to conform to that source of truth. Other schema validation libraries will force us to manually define types and keep those types in sync with our schemas. Here's an example of how we would do it with Joi:



import * as Joi from 'joi';

// Define a schema for the user with Joi
const UserSchema = Joi.object({
  name: Joi.string().required(),
  age: Joi.number().required(),
  email: Joi.string().email().required(),
});

type User = {
  name: string;
  age: number;
  email: string;
};

// Create a user data object to validate
const userData = {
  name: 'John Doe',
  age: 30,
  email: 'john.doe@example.com',
};

// Validate the user data against the schema
const { value } = UserSchema.validate(userData);

// Cast value to User
const user: User = value;

One clear difference is that we had to define the User type ourselves in addition to the schema. Unfortunately that also means that changing the schema does not force us to change the type or vice versa. So let's assume that we've added the address property to User but haven't changed the schema:



type User = {
  name: string;
  age: number;
  email: string;
  address: string; // <- new property
};

Our original code will continue to compile but the following code will fail in runtime:



const userData = {
  name: 'John Doe',
  age: 30,
  email: 'john.doe@example.com',
};

const { value } = UserSchema.validate(userData); // <- validation passes
const user: User = value;

console.log(user.address.toUpperCase()); // <- but this line fail miserably

With Zod, to change the type we would need to change the schema (single source of truth), ensuring that any bad input is validated before we reach any significant business logic.

Next in our series, we'll use Zod to validate input from HTTP requests.

Using self-signed certificates when developing Android applications

Shahar Kedar — Mon, 05 Sep 2022 17:36:23 +0000

I recently started learning how to develop mobile applications on Android. I've been doing mostly backend work before I joined RiseUp, but in the past 2 years I've learned to love web development, and mobile development seemed like a natural next step.

The first three weeks were awesome! Google created an amazing set of hands-on tutorials you can do to get started. But then I wanted to test my skills with real-world scenarios, and decided to implement our login flow in Android. The flow itself is not that interesting so I won't go into details there. What's important is that we use Nginx in our local (dev) environment to funnel all requests to our backend services. Nginx is responsible not only for routing API calls to the right service, but also for SSL termination. This allows our backend services to avoid meddling with SSL termination on their own.

Our local Nginx listens to port 9090, so I thought something like this should work pretty well*:

val loginApiService = Retrofit.Builder()
.baseUrl("https://localhost:9090")
.create(LoginApiService::class.java)                                

val token = loginApiService.authenticate(..)

*I simplified the code to make it more concise.

But when I ran the application, I got the following error:

java.net.ConnectException: Failed to connect to localhost/127.0.0.1:9090

Say what??? Well… apparently localhost on mobile devices is the device itself. That actually makes sense.

Problem no.1 - forwarding calls to localhost to my laptop

What I really wanted is that any calls to localhost should go to my laptop and not the device. adb to the rescue!

Android Debug Bridge (adb) is a CLI tool that helps you communicate with your mobile devices (virtual or physical). You can easily install in using brew:

brew install android-platform-tools

It has a cool command called reverse that allows you to forward any calls from any device to your laptop. This is how it's done:

adb reverse tcp:9090 tcp:9090

This basically tells the device that every TCP call on port 9090 should be forwarded to port 9090 on your laptop.

Problem solved! So I ran my application again and this time I got this:

javax.net.ssl.SSLHandshakeException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.

Problem no.2 - telling your device to trust a self-signed certificate

Our local Nginx uses a self-signed SSL certificate. It was created by an openssl command. This worked great for web development and we didn't have any real issues with it so far.

With Android (and iOS) devices, you need to tell your device to trust that certificate. There are two steps here:

Step 1 - Install a CA certificate on the device

First you need to tell your device to trust the root CA of your self signed certificate. Unfortunately, when using openssl to generate a certificate, you don't really have a root CA. So first I needed to change that.

I searched the Internet and found a great tool called mkcert. mkcert is a simple tool for making locally-trusted development certificates (I shamelessly copied from their README. Sue me).

When using mkcert you also get a PEM encoded CA Certificate which is exactly what our Android device is expecting. To find that certificate you can run:

 echo "$(mkcert -CAROOT)/rootCA.pem"

Copy the certificate to your device. Now on your device open the _CA Certificate _ settings screen and follow the instructions to install the certificate you copied.

Step 2 - Tell your application to trust user added CAs

By default, Android applications will not trust user added CAs. To make it trust your certificate you need to create a new file under res/xml called network_security_config with the following content:

<network-security-config>
    <debug-overrides>
        <trust-anchors>
            <!-- Trust preinstalled CAs -->
            <certificates src="system" />
            <!-- Additionally trust user added CAs -->
            <certificates src="user" />
        </trust-anchors>
    </debug-overrides>
</network-security-config>

Notice that we're trusting user added certificates only in debug mode. Released applications should work against properly signed SSL certificates.

Now add the configuration file to your AndroidManifest file:

<application   
...
android:networkSecurityConfig="@xml/network_security_config"
...
/>

That's it! 🎉

P.S. This works well for both physical and virtual devices.

To summarize, in order to enable your Android application to connect with an HTTPs server on your laptop with a self-signed certificate, you should:

Use adb to forward all calls to localhost
Generate a root CA certificate and install in on your device
Tell your application to trust user added CAs