Forem: Flare

Habits of Great Developers: The Underrated Power of Small, Frequent Merge Requests

Benoit Doyon — Tue, 10 Jun 2025 15:31:19 +0000

Trying to measure developer productivity is a famously difficult and often misguided effort. IBM’s historic attempt to gauge output by lines of code written is perhaps the most notorious example. It rewarded verbosity over clarity and activity over outcome.

Yet despite the limitations of rigid metrics, some patterns consistently emerge when you observe highly effective software engineers. At Flare, one habit we’ve seen repeatedly among our best developers is simple and powerful:

They make small and frequent merge requests.

In this post, we’ll unpack why this behavior works so well and how it supports better collaboration, faster iteration, and stronger product delivery.

Why Small, Frequent MRs Work

1. They Reflect Deep Understanding

At Flare, we work within a Shape Up-inspired product development framework. A large part of each cycle is spent on shaping and understanding the problem. By the time execution begins, the scope is usually de-risked and well understood.

When a developer has that deep understanding, they naturally break the work down into clear, manageable chunks. Each merge request becomes one of those chunks: focused, self-contained, and purposeful.

2. They’re Easier to Review and Safer to Ship

Large change sets are difficult to review thoroughly. Even experienced teammates can miss important details when too much is packed into a single MR. In contrast, small MRs:

Surface issues earlier
Make reviews faster and more focused
Reduce the risk of regressions
Are easier to revert if something goes wrong

This supports faster iteration and higher confidence in production releases.

3. They Encourage a Collaborative Mindset

A steady stream of small MRs creates rhythm in a team’s workflow. It encourages collaboration, builds trust, and makes progress visible.

Being stuck on something for too long, however, is a red flag. In one of the most effective teams I’ve worked with, we had a simple rule: if you were blocked for more than 40 minutes, raise a flag. That one principle saved days of frustration and kept momentum high.

What About Big Refactors?

None of this means that large, exploratory change sets have no value. Sometimes, a big refactor is the best way to learn. I often create a scratch branch where I pull apart a system to understand it better.

But that’s not what I submit for review.

Instead, I use that learning to map out a sequence of clean, logical steps. Then I go back and start fresh, delivering the solution through a set of small, testable MRs. That’s when the real progress begins.

Summary: Strong Developers, Small Chunks

Here are a few things you’ll often see among high-performing developers:

Merge requests are small, focused, and submitted regularly
Blockers are raised early and solved collaboratively
Large refactors are used for learning, but final changes are delivered incrementally

Frequent, small merge requests are more than a habit. They’re the outcome of thoughtful problem-solving and deliberate communication. If you want to move fast and build confidently, this is one of the clearest paths forward.

Why LLMs Won't Replace My Junior Developers

Benoit Doyon — Fri, 07 Mar 2025 14:09:53 +0000

We're hiring quite a bit at Flare these days, so I spend a few minutes each day on LinkedIn to scout candidates. It seems that the algorithm has decided that endless posts describing the downfall of the junior developers in the face of machine learning are going to capture my engagement. I guess it's not wrong in a sense, as it has compelled me to explain exactly why LLMs won't be replacing the junior developers in my team anytime soon.

Learning and Growth Require Real Experience

Junior developers aren't here just to ship code. They're learning how to think critically, solve complex problems and collaborate with the team. My AI assistant might write a function given a decent prompt, but it won't be as useful when debugging production, communicating technical ideas, or adapt to ever-changing project requirements. I can't overstate how happy it makes me when I give an assignment to a junior developer and instead of coming up with a flawed merge request, they come back with a question instead.

Context Matters

LLMs are great at generating snippets of code, but they lack the full context of a project's architecture, business logic, and long-term goals. Junior developers, on the other hand, learn the nuances of the codebase, understand why certain design decisions were made, and can make informed contributions that align with the bigger picture. I don't value junior developers as code monkeys, but rather as wielders of a fresh pair of eyes with which to look at a problem.

Over-Reliance on AI Can Be Risky

Using LLMs as a crutch can lead to complacency. Developers, especially those early in their careers, need to understand why code works, not just what code to write. Developing these habits is what allows them to grow into competent senior developers. If juniors skip the learning process and rely solely on AI-generated solutions, they miss out on developing critical problem-solving skills. It's like using a calculator without ever learning basic math. Sure, you might get an answer, but it all breaks down when confronting changing requirements and a nuanced playground. When building products, this basically means all the time.

Junior Developers Bring Long-Term Value

Investing in junior developers isn't just about the present, it's about the future. Today's juniors are tomorrow's leaders. By nurturing their growth, you're building a team that understands your product deeply, values continuous improvement, and can mentor the next generation. More senior developers also gain a lot by having junior members in the team. Flexing those mentoring muscles and learning how to become a multiplier in a team, instead of being a single contributor, is how developers unlock greater potential.

Final Thoughts

LLMs are powerful tools, and I encourage my team to explore them as a way to enhance productivity. But they're just that—tools. They can't replace the curiosity, growth potential, and human connection that junior developers bring.

If you're interested in fostering an environment where junior developers can thrive, we're currently hiring a lead for our platform team. Send me a message and I'll be happy to chat about building an engineering culture where humans are at the center of everything.

https://flare.bamboohr.com/hiring/jobs/73

Why A Great Developer Onboarding Matters

Benoit Doyon — Tue, 18 Feb 2025 13:32:24 +0000

I think most technical onboarding experiences throughout my career have looked something like:

Receive a company laptop
Clone the code repository
Find the latest person who's been through the painful process of setting up a local environment, and hope that they remember what they're doing, especially when trying to attempt to debug the inevitable errors

A poor onboarding process can lead to confusion and frustration, setting the wrong tone for a developer's experience at your company. On the other hand, a well-structured onboarding process ensures they start with clarity and confidence. At Flare, I believe we've found the key to effective onboarding: structured guidance, hands-on experience, and continuous support. And to be honest, it's nothing complicated. These small investments will go a long way to get developers started on the right foot.

The Cost of Poor Onboarding

Hiring great developers is hard. Once you hire someone who's excited to get started, the last thing you want to do is to be a hurdle to their momentum.

Long ramp-up times – New hires spend weeks or months just figuring out where things are and how to get started.
Frustration and disengagement – Without clear guidance, new developers can feel lost or undervalued.
Higher turnover – If onboarding is disorganized, developers may leave before they ever hit their stride.
Team slowdowns – A poorly onboarded developer pulls others away from their work for constant questions and troubleshooting.

On the flip side, a strong onboarding process accelerates learning, boosts confidence, and makes developers feel like they belong.

What Makes a Great Developer Onboarding Experience?

A great onboarding process goes beyond just documentation and checklists. Here’s what truly makes a difference:

1. Clear Expectations from Day One

Developers should know exactly what’s expected of them, what success looks like, and how they’ll get there. A structured onboarding plan with milestones helps keep everything on track. At Flare, since we work with Shape Up cycles, new developers typically follow a specific learning curve. You spend one cycle onboarding and learning, you spend one cycle executing and contributing within a team, and finally you are ready to lead a cycle and champion a project.

2. Easy Access to Tools and Information

Nothing slows down a new hire like missing credentials or outdated documentation. We make sure to automate setup where possible and ensure essential resources (like API keys, test environments, and architecture diagrams) are easy to find. As part of our onboarding, the new hire updates the onboarding documents to ensure they remain accurate and relevant. This ensures that they are always up-to-date, and free of any ambiguity.

3. Hands-on Learning and Small Wins

Instead of drowning developers in documentation, we let them start with small, meaningful tasks. Fixing a minor bug or improving documentation in their first week builds confidence and helps them understand the codebase faster. The way we do this at Flare is with something we call quests, which are sample tasks that everyone does (ex: change the color of a button in the UI, implement a new API listing feature flags). This way you can get relevant comments from everyone on the team, while also making sure your development setup functions correctly in a controlled environment.

4. Mentorship and Support

Assigning a buddy or mentor gives new hires a go-to person for questions and guidance. This helps them integrate socially and technically into the team more smoothly. On top of the buddy system, we make sure new developers spend a day shadowing each member of the team during their second week. This gives them exposure to different workflows, coding styles, and problem-solving approaches, helping them understand how various parts of the team collaborate and function together.

5. Team and Culture Integration

Onboarding isn’t just about code. We want to help new developers connect with their team, understand the company’s culture, and feel like they belong. Casual introductions, team lunches, and pairing sessions make a big difference. We tend to group new hires in cohorts, and we plan a welcome lunch, as well as introductions during the weekly company all-hands.

The Payoff: Faster, Happier, and More Effective Teams

Investing in great onboarding isn’t just about making new hires feel good, it’s about making your entire team more effective. Developers ramp up faster, contribute sooner, and stay longer. A smooth onboarding experience signals that your company values its people and sets them up for success from day one.

If you want a stronger, more engaged engineering team, start with how you welcome them. Investing in great onboarding leads to faster productivity, higher retention, and a more cohesive team. Take the time to refine your process, and you’ll see the impact in every aspect of your development culture. Onboarding isn’t just the first step, it’s the foundation for everything that follows.

Why (and how) we hire software development interns

Benoit Doyon — Fri, 23 Aug 2024 15:16:47 +0000

Intern recruitment season is upon us! At Flare, we typically hire 2-3 interns each semester, with one joining one of our development teams. As we prepare to welcome a new cohort, we’re also gearing up to recruit for the following semester. Here’s an inside look at what an engineering internship at Flare entails, the benefits we gain as an organization, and how we ensure we recruit top-quality candidates.

What an Internship at Flare Looks Like

Before an intern starts at Flare, we’ve already identified a team that aligns well with their skills and interests. During the interview process, we discuss their previous experience, areas of interest, and what they hope to learn. However, once they’re more familiar with what we do at Flare, they’re free to choose the team they wish to join.

Interns undergo the same onboarding process as our full-time developers. The onboarding starts with an introduction to the company, where they learn about our mission, meet leadership from every department, and get a comprehensive overview of our operations. Following this, they dive into developer-specific onboarding, which includes a series of "quests." These quests are essentially sample tasks that cover various aspects of development, ensuring that interns have correctly set up their environment and tools. Throughout this process, they are guided by a "buddy" and supported by their assigned team. Typically, within the first two weeks, interns are ready to tackle a real issue.

Once onboarded, interns are fully integrated into their development teams, participating in our development cycle (see our ShapeUp article for more details). During their semester at Flare, interns work on two full development cycles. This means they will contribute to two meaningul and time-bound projects. The first project helps them get up to speed, gradually taking on larger tasks as they become more comfortable and independent. By the end of their internship, they’ve gained the experience of delivering two increments of user value—an ideal experience for budding engineers.

In summary, our interns are treated as full team members, working alongside experienced developers on meaningful projects. We set realistic expectations based on their experience level but ensure they are fully immersed in our development process.

Why We Hire Interns

Hiring interns offers numerous benefits beyond just increasing development velocity. While gaining additional hands on deck is valuable, the true benefits lie elsewhere.

Firstly, recruiting interns is an excellent way to engage our team in the recruitment process. It’s a low-stakes entry point that allows team members to gain experience in hiring, particularly those who might be hesitant about recruiting more experienced professionals. Our internship hiring process is shorter and less time-consuming than hiring full-time developers, making it an ideal starting point.

Once interns join the team, it’s a fantastic opportunity for team members to develop mentoring skills. Mentoring is a crucial skill that improves communication, processes, and team interactions far beyond the scope of the internship program. In my view, this is the greatest benefit of having interns.

Moreover, providing a great internship experience is important to us. It not only benefits the interns themselves but also contributes to a positive environment that makes future recruitment easier. It's a great pipeline to cultivate to ensure a steady flow of well-trained junior developers joining the team.

How We Recruit Great Candidates

Our recruitment process for interns consists of two main parts. First, we conduct a one-hour "fit" interview. This interview allows us to discuss the candidate’s experience, explain what an internship at Flare entails, and answer any questions they may have. If there’s a mutual fit, we move on to the next step.

The second step is a technical interview. We believe it’s essential to see interns code to ensure they can be productive within our development teams. Given the steep learning curve and the complexity of our distributed systems, we focus on onboarding interns to our way of doing things rather than teaching the basics of software engineering. Therefore, we prioritize candidates with prior experience and assess their capabilities during this interview.

While coding interviews can be daunting, we strive to make ours as comfortable as possible. We ask candidates to solve a simple problem involving around a dozen lines of code, conducted live over video chat. Though this might seem stressful, we allow candidates to use any programming language, tools, or documentation they’re comfortable with, including Google and language docs. They can also ask questions, and we guide them as needed. Our goal is to simulate real work, where we act more as colleagues than interviewers. Feedback suggests that while candidates may feel nervous initially, they quickly relax and enjoy the exercise.

Conclusion

Thanks for sticking with me through this overview of software development internships at Flare! If you’ve got thoughts on our process, I’d love to hear them. And if you’re looking for an internship yourself, don’t hesitate to reach out—we’re always on the lookout for great talent. https://flare.io/company/careers/

ShapeUp at Flare: A Game-Changer for Project Management

Benoit Doyon — Tue, 23 Jul 2024 17:12:29 +0000

I first encountered ShapeUp during one of my initial interviews for a position at Flare. My soon-to-be manager mentioned, “We’re using a methodology that works well for us, but you might not have heard of it before.” With over 10 years of software development experience under my belt, I was skeptical. “If there was a better way to do things, surely I’d have heard of it,” I thought. Little did I know, ShapeUp would fundamentally change my approach to project management and team dynamics.

Before extolling the virtues of ShapeUp, let me provide some context. Throughout my career, I’ve been part of many dysfunctional teams, as well as some exceptional ones that delivered far beyond the norm. I spent a great deal of time thinking about this and trying to replicate those particular conditions in every team I was part of. I was a solid SCRUM advocate. I tend to think that being “agile” works better with a lowercase “a”, and the guiding principle is to craft a process that best suits your situation. However, despite my dedication to SCRUM, I frequently encountered roadblocks in getting teams to perform well.

Enter ShapeUp

ShapeUp, created by BaseCamp, is a methodology that we use to run projects at Flare. The ShapeUp book is a mandatory read for all new employees, and while it’s concise, I’ll outline the key principles we follow:

Work is scheduled in 8-week cycles
- Each cycle consists of a 6-week project period followed by a 2-week cooldown.
No backlog
- Instead, we have a “shaping” process where top-of-mind tasks are defined into projects.
Blurry project definitions
- The problem statement and goals are clear, but the team is trusted to build the solution within the time constraints. Developers are assigned a problem to solve rather than a ticket to complete.
Cooldown periods
- Developers have the freedom to work on whatever they want during the cooldown.

ShapeUp’s simplicity and elegance lie in the details. Here are the main advantages we’ve experienced:

Meaningful increments
- We always focus on the most important tasks, and 6 weeks is sufficient to build something substantial.
Big-picture focus
- Developers are trusted with significant liberty in solving problems, fostering creativity and innovation.
No “just one more sprint…” death march
- With ShapeUp, projects conclude after 6 weeks, preventing endless extensions and allowing for fresh starts in the next cycle.
Protected developer time
- Developers’ time is safeguarded to focus, free from external interruptions during projects and unnecessary justifications during cooldown.

Cooldowns Are Awesome

Cooldowns are a beloved aspect of ShapeUp at Flare. Business stakeholders often remark, “There’s so much great stuff getting done, we should do cooldowns all the time.”

Cooldowns provide the perfect opportunity to:

Conduct retrospectives and plan the next cycle.
De-risk upcoming projects.
Fix bugs, perform meaningful refactorings, and work on passion projects.
Experiment with new technologies.

Developers get really excited about cooldowns, and the business as well. It turns out that if you hire developers that care about their craft and let them run loose for 2 weeks once in a while, they contribute meaningfully.

Additional Advantages

Interns at Flare, typically with us for a 4-month semester, greatly benefit from the ShapeUp cycles. Aligning our cycles with university semesters and holidays allows interns to:

Onboard at the start of a cycle.
Contribute meaningfully to a project.
Apply their knowledge in a subsequent project, experiencing two full cycles during their internship.

Conclusion

Usually seeing is believing, but something feels right even when just being introduced to the concept of ShapeUp. People immediately perk up when we mention how we work during interviews. Candidates we’ve hired that are experiencing ShapeUp for the first time are now becoming ambassadors. After a year with ShapeUp, I know I’m sold.

ShapeUp is more than just a project management approach. It changes the way we approach problem-solving and team dynamics, fostering trust, creativity, and enabling significant progress. If you’re struggling with your current methodology or just curious about alternatives, I highly recommend giving ShapeUp a try. It might just revolutionize your team’s productivity and satisfaction as it has for us at Flare.

Incorporating LLMs Into Cybersecurity

Alexandre Viau — Thu, 21 Sep 2023 15:21:48 +0000

Bombarded with multiple alerts coming from multiple disconnected services, security analysts continue to struggle with alert fatigue. While they need context about threats facing their organizations, many also find identifying the right context challenging.

Today, companies expect security analysts to be experts in everything from the technical to the criminal underground. In reality, this just isn’t possible. However, large language models (LLMs) excel at summarizing large quantities of data, offering security teams a starting point for their analyses.

Flare uses LLMs to help analysts get the insights and answers they need quickly so that they can filter out false positives and focus on what really matters.

Using LLMs to Provide Context

LLMs can help separate out important context. Typically we see two different use cases: non-technical and technical.

Non-Technical Context from LLMs

From a non-technical point of view, LLMs adapt well to given slang language. They understand the context and quickly summarize information, eliminating the need to do Google searches.

First, criminal underground chatter uses slang that has a different meaning within their community when compared to the technical community.

For example, they often use the term “logs,” referring to stolen usernames and passwords. Technical professionals usually recognize this term as the digital record of activity happening in their environment. With the prompt, LLMs can “translate” this for you.

Second, LLMs can help you understand what an application does. For example, when threat actors post stolen credentials for sale, they usually name the application. By explaining the application, LLM tools make it easier to determine whether the stolen credentials pose a risk to your organization’s security posture.

Technical Context from LLMs

At a technical level, ChatGPT does an excellent job of helping analysts better identify real, exploitable risks to their environments.

For example, when Flare identifies a GitHub match, the LLM can look at the code and understand whether the mention indicates a risk or not. When developers use a base template for an app rather than starting from scratch, they often make a copy and rename it for their company before they start working. Sometimes, these files may have a hardcoded password. However, this public facing hardcoded password poses little risk to the company until the developer starts modifying the code to build the company-specific application.

When Flare detects the company name in GitHub, the LLM provides context around whether the match poses little risk because it was in a default config file or could indicate a problem because the developer made a modification.

Limitations of LLMs

While LLMs provide various benefits, they also come with some limitations. LLMs analyze unstructured data which poses difficulties when writing prompts.

Unstructured Data

When inputting a query, the LLM has a hard time deciphering the difference between the question being asked and the data being supplied. For example, if you’re providing the text of a message and asking if it was written by a specific threat group, the LLM gets confused. It can often focus on the threat group’s name or a username in the prompt rather than analyzing the message’s text that you want to know about.

Input Size

LLMs can limit the amount of data that it can summarize so choosing what information the prompt includes is critical.

Although ChatGPT’s context window simulates a conversation to look human, the LLM doesn’t “remember” the beginning of conversations. If you engage in a long conversation, then it won’t be able to answer appropriately because it may not be accessing the original information, such as the threat actor's name.

To get the most accurate actor profile possible, you need to choose the inputs carefully. Ideally, when an actor is active on the criminal underground and the clear web, you want to take a little bit of both. You need to combine some of the:

Oldest criminal underground activity
Recent criminal underground activity
Oldest clear web activity
Recent clear web activity

With the right inputs, the model can fill the gaps, giving you a good high level view of what the threat actor does.

Source Code

LLM models use tokenization that transforms texts into numbers which often means that ChatGPT can analyze less code in a given input than it can text. Consider the following:

CHAT GPT
chat GPT

While the human eye and mind reads these as the same two phrases, the LLM model transforms following data point into a separate number:

chat
CHAT
G
P
T

What people think is two pieces of data, the LLM model views it as five.

When communicating code with ChatGPT, you have a smaller token budget than you do with text, meaning that you have to be more careful when inputting queries so that you don’t waste energy computing information that doesn’t matter.

In this case, you want to look for the interesting parts of the source code and only send those. Some examples might be inputting:

The metadata for the part of a file where your company’s name is mentioned
Specific project name, location, and developer

Lessons Learned: Engineering Prompts

When dealing with token budgets, engineering prompts become incredibly important. Unfortunately, no clear answer around best technique exists. The process requires you to test and iterate the prompt. Some prompt improvements more than doubled the output’s value.

LLMs can assume that all information provided at input is true or factual. For example, a prompt might ask a question about whether your company’s data was part of a specific data breach. The LLM will assume that the corporate data was part of the breach rather than researching the breach to look for the corporate data.

Future of LLMs in Cybersecurity

A fundamental problem in cybersecurity is the communication gap across different people in the company. LLMs are powerful for communication between different audiences, especially when looking at how teams can use them for reporting. LLMs empower less experience security team members by helping them understand context so that they know how to efficiently escalate alerts. Additionally, CISOs and others interacting with business leadership can use LLMs to explain technical bugs or data breach information in a way that addresses that audience’s needs.

Working around Vue 2's lack of types using Vue Property Decorator

Maxime Goyette — Mon, 03 Oct 2022 19:25:21 +0000

Vue 2 is not type-friendly. Vue Class Component and Vue Property Decorator are libraries that help improve this, but there is still a disconnect in templates when passing properties to components.

Take, for example, the following Vue component:

// SimpleCounter.vue

<template>
  {{ value }}
</template>

<script lang="ts">
@Component
export default class SimpleCounter extends Vue {
  private value: number = 0;
  @Prop() step!: number;
  @Prop({ default: 0 }) startAt!: number;
  created() {
    this.value = this.startAt;
  }
  increment() {
    this.value += this.step;
  }
}
</script>

And the following parent component (notice the error!):

// App.vue

<template>
  <!-- There should be an error here, "potato" isn't a number! -->
  <simple-counter step="potato">
</template>

Vue 2 wouldn't have a way to prevent this error at compile time.

At Flare, we have been working around this for a while by:

Declaring an interface associated with every component, defining the required properties.
Using computed properties to have type-checking on the interface.
Passing the properties to the component using the v-bind directive.

// SimpleCounter.ts
// This file exports an interface that is used by all Simplecounter users.
// The interface has to be defined by hand, but at least it allows for
// validating that all users of the component are updated when we update
// the interface.

export interface SimpleCounterProps {
  step: number;
  startAt?: number;
};

// App.vue

<template>
  <simple-counter v-bind="simpleCounterProps" />
</template>

<script>
@Component
class App extends Vue {

  get simpleCounterProps(): SimpleCounterProps {
    // We couldn’t make a mistake here.
    // Typescript would warn us.
    return {
      step: 10,
    };
  }
}
</script>

However, this isn't ideal because you have to declare the interface manually and there can be a discrepancy between the interface and the actual component. Developers modifying the component could potentially forget to update the interface and this would most likely cause bugs.

The solution would be to ~~use Vue 3~~ have a single source of truth by deriving the interface directly from the component itself. This could be done in the form of a generic utility type that takes in the class of the component and outputs an interface for its properties: PropsOf<SimpleCounter>.

The library Vue Property Decorators has this Prop decorator that automagically assigns class attributes as props. It's also possible to set default values to props using the following syntax: @Prop({ default: 'hey' }).

This allows us to have strictly defined (as opposed to optional) attributes from an internally in the component and still accept optional properties from the parent component.

We had the idea of using the class inferred interface to type the properties, but we get a bunch of Vue internals as properties such as $refs and $slots.

A good way to get rid of these is to omit the keys of Vue.

This is slightly better, but we still get all of the component functions in the auto-completion, which is bad. What if it were possible to define the props and the functions separately? Let's try it!

// SimpleCounter.vue

<template>
  {{ value }}
</template>

<script lang="ts">
@Component
class SimpleCounterProps extends Vue {
 @Prop() step!: number;
 @Prop({ default: 0 }) start!: number;
}

@Component
export default class SimpleCounter extends SimpleCounterProps {
 private value: number = 0;

 created() {
   this.value = this.start;
 }

 increment() {
   this.value += this.step;
 }
}
</script>

We now have a simple way to get an interface for the only the properties, or do we? Well yes, kind of, but also no, not really. The types are not fully accurate yet.

As we can see, step is correctly typed, but start is not defined as an optional property. What we're looking for here is to have start? instead of simply start . We can do this by splitting the properties declaration into two different classes. The first class would contain the required properties and the second class would contain the optional properties.

// SimpleCounter.vue

<template>
  {{ value }}
</template>

<script lang="ts">
@Component
class SimpleCounterRequiredProps extends Vue {
 @Prop() step!: number;
}
@Component
class SimpleCounterOptionalProps extends Vue {
 @Prop({ default: 0 }) start!: number;
}

@Component
export default class SimpleCounter extends Mixins(RequiredProps, OptionalProps) {
 private value: number = 0;

 created() {
   this.value = this.start;
 }

 increment() {
   this.value += this.step;
 }
}
</script>

This makes it easy to derive the correct types using a custom utility type.

// utilities.ts

type PropsOf<RequiredProps extends Vue, OptionalProps extends Vue> = Omit<Required<RequiredProps> & Partial<OptionalProps>, keyof Vue>;

Finally, let's export the derived interface.

// SimpleCounter.vue
// ...
export type SimpleCounterProps = PropsOf<SimpleCounterRequiredProps, SimpleCounterOptionalProps>;
// ...

Now we can import the property types in other components and we get exactly what we were looking for:

🎉🎉🎉

I would have really liked to be able to use the PropsOf<SimpleCounter> type with a single parameter, but I haven't found a way to achieve this yet.

Typing your way into safety

Israël Hallé — Thu, 21 Jul 2022 21:06:00 +0000

I've been working with Python typing annotation in the last few years as part of our main product at Flare Systems. I've found it to be a wonderful tool to support refactoring and make the code more readable. Lately, I explored how we can make API safer with the uses of types. I will specifically look about how we can use Python typing annotation to make os.system foolproof.

As a starting point, the current type of system is:

def system(command: StrOrBytesPath) -> int: ...

This typing is correct. It has the benefits of catching any call not using a string that would be bound to fail. But this doesn't check for any misuse such as passing unsanitized user input. For example, someone might want to use ImageMagick to resize an image:

def resize(size: str):
  system(f"convert INPUT -resize {size} OUTPUT")

def api(request):
  resize(request.args["size"])

Unfortunately, this simple implementation introduced a critical flaw in our application. A user could use a malicious size such as $(echo hacked). The size would then insert itself in the command and execute the following command: convert INPUT -resize $(echo hacked) OUTPUT. This exact vulnerability pattern is still very common to this day.

The fix is as simple as the mistake. shlex.quote can be used to ensure a string is used as a single string token in a command. Yet, there's no explicit check in system to ensure that the command has escaped user inputs.

Fortunately, we can think of ways to improve this. First of all, we can split all types into two categories: Safe and unsafe. As seen, using user input as system argument is unsafe. But, passing a literal string should be somewhat safer. At least, literals lead to predictable behavior. If you execute the rm --no-preserve-root -rf / literal you can predict that it will wipe your disk.

Typing annotation users might already be familiar with the Literal type. As a quick reminder, the literal type allows developers to type a variable with a literal value. This is useful for functions that might take only a finite amount of known literal value. For example, system could have used it this way:

def system(command: Literal["ls"] | Literal["id"]): ...

system("ls")  # ok
system("id")  # ok

system("rm -rf")  # error!
system(request.args["size"])  # error!

Note that in practice I usually favor Enum. This usually lead to safer code since it also check the value are correct at runtime.

One nice thing with this concept is that the type checker will not allow passing a str when expecting a Literal. The big limitation is that Literal only work on concrete literal. There's no way to set the type of a variable to take any literal of a type:

def system(command: Literal) -> int: ...  # error: Literal[...] must have at least one parameter

In our case this is quite restrictive since we want system to run any safe command. Until Python 3.10, there were no built-in ways to have a function that only takes Literal arguments. That is, before Python 3.11 adds the LiteralString type. LiteralString allows a variable to accept only literal strings.

def system(command: LiteralString) -> int: ...

system("convert INPUT OUTPUT")  # ok
system(f"convert INPUT -resize {size} OUTPUT")  # error!

At the time of publishing, Mypy define LiteralString as an alias to str. Thus, the latest version of Mypy with Python 3.11 won't catch any error in the snippets above and below.

It still limits us to literal values. Going back to our use case, we want to be able to pass in the size of the image. It is actually possible to make size safe by sanitizing the value for shell use. These are the usual quote or escape function that takes user input and return strings that are safe to use. For shells, Python has the shlex.quote function available. The input and output of these functions have different safeness property. It would be interesting to reflect this difference in the types:

ShellQuotedString = NewType("ShellQuotedString", str)

def quote(value: str) -> ShellQuotedString: ...

Here we introduce a new type that includes the safety property. Python includes the NewType tool to easily create a new type from an existing one. This new type can be used wherever the base time is used, but not the other way:

safe: ShellQuotedString = ShellQuotedString("This string is safe")
unsafe: str = safe  # ok
safe = unsafe  # error: Incompatible types in assignment

Now we have both kinds of safe data: Literal and quoted data. For ease of use, we can alias both to an enum:

ShellString = LiteralString | ShellQuotedString

This enum is all the safe types of command that system can execute. This ensures that a developer has to think about quoting user input before passing them to system.

def system(command: ShellString) -> int: ...

system("convert INPUT OUTPUT")  # ok
system("convert INPUT -resize {quote(size)} OUTPUT")  # error!

It's still not accepting our quoted size argument. An interesting property of NewType is that any operation done on it will convert it back to the base type. For example, concatenating a str to a ShellQuotedString will return a str. This put the burden on the API designer to define the set of safe operation. If we want to provide operations to work on our safe strings, we have to implement them.

In our case, we know that concatenating shell-safe strings will create a new shell-safe string. So we can expose this operation as the safe way to mix user input and literal values.

def shell_format(
  format_string: str
  *args: ShellString,
  *kwargs: ShellString,
) -> ShellQuotedString:
  return ShellQuotedString(format_string.format(*args, **kwargs))

output_path = "/tmp/out"
shell_format(
  "convert INPUT --resize {} {}", 
  quote(size), 
  output_path
)  # ok

shell_format(
  "convert INPUT --resize {} {}", 
  size, 
  output_path
)  # error!

Note that this implementation might still leave room for security vulnerability. Using the function like shell_format("convert -resize '{}'", size) would leave size effectively un-quoted. It would be possible to add some more checks to ensure any {} literals aren't surrounded by quotes. This is a great example of why regular strings operation might lead to unsafe behavior if applied to our new types.

Now that we have all the operation and safety property we need, we can now glue everything together:

Our system API is now proved to be safe. It should be catching any misuse with unsanitized values. Note that we are using here a ShellQuotedString instead of a SafeString type that could be reused for many other cases (SQL quoting, html.escape, etc.). Our type safety is relative to the usage of it. The return value of html.escape is safe to render without introducing XSS. Yet, the same value could introduce SQL injection if used as-is in a query.

Adding safety to types can go beyond escaping or quoting patterns. Types can expose most implicit preconditions to static analysis. For example, an static file API that open a file from user input could define a SafePath type. A function could then convert a str to SafePath after it checks that it's under a specific directory.

We have seen that we can easily use types to embed semantic in our code. Python typing annotation can do much more than just preventing TypeError. It can make precondition explicit and prevent critical security vulnerabilities.

Connect services across Kubernetes clusters using Teleproxy

Alexandre Viau — Thu, 21 Jul 2022 20:36:00 +0000

Teleproxy is a shell script that lets you quickly replace a Kubernetes deployment by a single pod that forwards incoming traffic to another pod running in a destination Kubernetes cluster.

The tool is based on telepresence. It is used at Flare Systems to keep our development setup light and still be able to quickly connect our test apps to a more realistic “staging” environment.

See the code at https://github.com/flared/teleproxy.

Ideal for minimal Minikube setups

Most of Flare Systems’ development setup is based around Minikube, a tool that lets you run Kubernetes locally as a single-node cluster.

While Minikube is great, we quickly ran into performance issues. Devs don’t necessarily have the resources to run all the services they need to test the software component they are working on, or maybe they’d rather have more than 30 minutes of battery life! They may also want to interface with a database that contains more data than the one that we ship in the local development environment.

It would be great if there was a tool that allowed you to quickly swap the database that runs locally inside Minikube with a proxy that points to a database running in another cluster. This would allow for all services running in Minikube to instantly connect with another database with little to no configuration changes. This is exactly what teleproxy allows you to do.

Using teleproxy to swap a kubernetes deployment with a proxy

Say you have local deployment called someservice with pods listening to port 8080 running in your local cluster and you want to replace it with a proxy to another deployment running in a destination cluster, you would run the following command:

tele-proxy \
    --source_context=minikube \
    --source_deployment=someservice \
    --source_port=8080 \
    --target_context=staging \
    --target_pod=someservice-77697866c6-vsk59 \
    --target_port=8080

How it works

Teleproxy is based on telepresence. All it does is it runs kubectl port-forward in telepresence’s replacement pod. If you don’t already know how telepresence works, the following deployment diagram should help. It follows traffic from a client pod, which uses the service that we are replacing, to the target pod, which is an equivalent pod running inside another cluster.

The traffic originates from the client, it probably targets someservice using the deployment's Kubernetes service.
The traffic is received by telepresence’s incluster container. Telepresence has scaled down the someservice deployment and has replaced the pods by this single incluster proxy. It forwards any incoming traffic to the telepresence local pod which is running outside of the cluster.
The traffic is received by telepresence’s local container, which forwards it to the teleproxy container.
The traffic is received by teleproxy and is forwarded to the destination pod in Cluster B trough kubectl port-forward. This container is able to run a port-forward to your destination cluster because it mounts your local kubectl config, some specific environment variable and contains common tools for authenticating against a kubernetes cluster such as the AWS and Google Cloud CLIs.

Debugging Teleproxy

If you start from a working telepresence setup, the only complexity that is added by teleproxy is that the teleproxy container must be able to connect to your target cluster. Depending on how you regularly connect to that cluster, you may need to mount configuration files or add environment variables to the teleproxy container.

We have configured teleproxy for our own use and have gotten it working with both GKE and AWS EKS, this required:

mounting ~/.aws , ~/.kube
Installing the AWS CLI and Google Cloud CLI
Setting up compat symlinks for OSX users.

There is probably more to do, and we are willing to merge anything that makes sense.

Appendix

Telepresence: https://www.telepresence.io/discussion/overview
Open Source @ Flare Systems: https://flared.github.io/
Teleproxy: https://github.com/Flared/teleproxy