The ancient Phoenicians were very skilled sailors. They navigated the seas with ease and mastery and their ships depended to a large part on the effort of many rowers. The ships did have a sail, but it was underutilized. By and large power was derived from human labor. The Phoenicians were confident they could navigate any sea and sail from point to point predictably. But it wasn’t the fastest way to travel.

Fast forward to today where we have super sleek and hyper-engineered sailboats such as the AC75 pictured above, that seem to levitate over water as they hurtle across the sea. Humans are no longer on board to provide the raw power to move the ship but they are there to guide the ship effectively. The difference is that modern ship design is primarily focused on sails, hulls and materials. How to harness the wind efficiently and consistently is the main differentiator.

Software engineering is undergoing this exact transition. AI is no longer a supplementary “sail” to human typing. AI is the wind. It is the main power source, and as Steve Ballmer recently noted, the dynamic has inverted: humans are now a productivity tool for AI.

With great power comes great responsibility

This quote from Spider-Man is apt in the world of software development. Because as AI models become more powerful and AI agents act with greater autonomy it is incumbent on the human engineers to provide a level of governance to ensure that AI output properly reflects the design philosophy of your team and is guided by context and taste. Here’s an example that illustrates outcomes that can happen with unchecked AI: I attended a meetup a few weeks ago with CTOs and Product Managers. One topic of conversation revolved around the best ways to adopt AI coding assistants for your team. One person told a story about a junior engineer on her team who felt like he was falling behind in utilizing AI. So he started using an agent to refactor a gnarly piece of code. However, the agent over-engineered a solution and created a pull request that was 7000 lines long! The CTO looked over this code and said “this doesn’t make any sense. This is overkill. I can see that an AI created it. “

The junior engineer didn’t even know that a 7000 line pull request was not the best solution. That’s the pitfall of turning the reins over to an AI agent if you are not really in control. Because working with one agent puts that agent in control. But with the introduction of many, you remain in the driver’s seat and maintain your judgement. There is also the danger of hallucinations. Hallucinations are false but plausible sounding responses that AI models give because of training issues, gaps in source data or pattern-matching errors. Open-AI recently touted that GPT‑5’s responses are ~45% less likely to contain a factual error than GPT‑4o. This is great but when we’re developing software code we need to ensure that the accuracy of the solution is 99.99% (Four 9s) and not 85% (or a B+).

Designing Agentic Systems with Trust built-in

Given the potential pitfalls with handing over the reins of development to an AI assistant how can you build trust into your system. Interacting with an AI agent can feel like collaborating with a junior intern who is being managed as a senior developer; in reality, they often resemble a recent college graduate who possesses a misplaced sense of absolute expertise.We are moving from spec-driven development to ‘vibe coding’ and rapid, agent-assisted prototyping.

But the reality is this: Speed without governance is simply liability. To build trust, we have to move away from “blind faith” and toward architectural guardrails. (See this article on Harness Engineering) One way would be to use the tried-and-true method of Human-In-The-Loop verification, or the newer term “Human-On-The-Loop”. This can be applied to spot-check a percentage of AI decisions, however, this approach doesn’t scale well and could lead to subjective outcomes when the humans in the loop use different criteria to vet outcomes.

Another approach which is gaining traction is the multiple-agent approach. In this paradigm you use agents trained for specific tasks such as requirements gathering, code development, QA, UX verification, etc. and a team of other agents to “check their homework” This approach helps to reduce overall risk because no single agent is responsible for the outcome but instead a team of agents work together to ensure quality and build overall trust into the system.

Charting the path forward

For the past two years, every boardroom discussion has focused on the same question: How can AI be a productivity tool for humans?” But as Steve Ballmer recently observed, that view is already backward. We are rapidly entering an era where humans are becoming a productivity tool for AI. Think about it. AI has the speed of execution and the breadth of knowledge. What it lacks is context, judgment, and taste.

In this new paradigm, the AI acts as the engine, and the human role shrinks — but intensifies — into serving as the steering wheel.

So as we race at the speed of light towards a future with more and more AI, don’t forget that you are the driver and the steering wheel is yours.

Harnessing the Wind: Why Humans Are Now the Productivity Tool for AI was originally published in JOOR Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

When SwiftUI was introduced, it fundamentally changed the way developers think about building views.

Every view in SwiftUI is now a struct that must conform to the View protocol. To satisfy this requirement, a computed property called body must be implemented, which returns a value of type some View.

import SwiftUI

struct ContentView: View {
    var body: some View {
        // ...
    }
}

For many developers, this was the first time they encountered the some keyword — but what does it actually mean?

The “Some” keyword

The some keyword tells the compiler that a value conforms to a protocol but hides its exact type, while still guaranteeing that it’s always the same concrete type.

Hides the type

In this example, we’re returning a Text , which conforms to the View protocol, so the compiler accepts the result:

struct ContentView: View {
    var body: some View {
        Text("Hello, world!")
    }
}

Outside the view’s implementation, it’s impossible to know the concrete type used to build the view. In other words, the view’s type is opaque.

let view = ContentView()
let body = view.body
print(type(of: body)) // <- prints "AnyView" instead of "Text"

Ensures the same concrete type

To explain this point, let’s briefly look at a different example. Imagine we want to create an app that lets users manage all their consoles. Let’s start by defining what a Console can do:

protocol Console {
    func turnOn()
}

Now, let’s create some concrete console types that conform to that protocol:

class PlayStation: Console {
    func turnOn() {
        print("PlayStation is turned on")
    }
}

class Xbox: Console {
    func turnOn() {
        print("Xbox is turned on")
    }
}

Great 🎉 Now we need a way to create instances of each console. We might want to return different consoles depending on the brand. The pattern I’m using here is called the factory pattern:

enum ConsoleManufacturer {
    case sony
    case microsoft
}

class ConsoleFactory {
    func createConsole(manufacturer: ConsoleManufacturer) -> Console {
        switch manufacturer {
            case .sony: PlayStation()
            case .microsoft: Xbox()
        }
    }
}

Perfect — now everything is set up. If we wanted to create a new console and turn it on, we’d just need to do the following:

let factory = ConsoleFactory()
let console = factory.createConsole(manufacturer: .sony)
console.turnOn()

But what would happen if we used the some keyword in the method’s return type?

class ConsoleFactory {
    func createConsole(manufacturer: ConsoleManufacturer) -> some Console {
        switch manufacturer {
            case .sony: PlayStation()
            case .microsoft: Xbox()
        }
    }
}

The compiler would find the following error:

Branches have mismatching types ‘PlayStation’ and ‘Xbox’

By using the some keyword, we’d be telling the compiler that we’re returning a concrete — but unspecified — type that conforms to the Console protocol, and that this concrete type will always be the same. However, in our method’s implementation, we’re returning different types depending on the manufacturer parameter — which creates a contradiction the compiler can’t accept.

The “any” keyword

Now let’s take a closer look at the ConsoleFactory method. You’ll notice that its return type is Console, but there’s a problem: Console is a protocol, not a class. A very interesting question at this point would be:

Can a method return a protocol?

The answer is no — a method can’t return a bare protocol type. So what’s happening here? Why isn’t the compiler showing any errors?

This is because in Swift 5.7 and later, the compiler implicitly treats a protocol return type like Console as any Console, for backward compatibility.

This method:

func createConsole(manufacturer: ConsoleManufacturer) -> Console

Is automatically converted to this by default at compile time:

func createConsole(manufacturer: ConsoleManufacturer) -> any Console

In this case, the any keyword is hiding the exact type of the returned value. It doesn’t require all return values to be of the same concrete type — it only ensures that they all conform to the Console protocol.

Conclusion

Use some when you want to return a specific type that conforms to a protocol, but don’t want to expose its exact type. It ensures consistency and better performance. Use any when you need flexibility to return or store multiple types conforming to the same protocol. The right choice depends on whether you value type safety or flexibility in your design.

Swift — Understanding the “any” and “some” keywords was originally published in JOOR Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

At this stage, most of us on the court are dealing with old injuries and aging bodies, but we keep playing. Why?

Because we love it, and because we take ownership — not just of our game, but of everything that comes with it.

Yesterday morning, as I was cleaning my basketball, I realized how deeply that mindset extends beyond the court. Ownership is why I still play. It’s also why we care so much about the systems we build at JOOR.

The past few weeks have been challenging for our team.

With the first major markets of the year, platform activity surged — something we welcome, but also something that tests the limits of any system. While we proactively planned for this, we also faced unexpected slowdowns and downtime, and we take full responsibility for that.

Since January, we have implemented:

• 10 significant optimizations in our application features
• 6 improvements in our APIs and integration subsystems
• 6 upgrades in our infrastructure
• Additional enhancements to our monitoring systems
• and counting …

If you’re one of our customers and experienced disruptions, we sincerely apologize. We know how critical JOOR is to your business, and don’t take that lightly.

If you’re on our team, you know we’ll stay vigilant. We’ll continue to improve performance and stability week after week.

And now?

We have identified different opportunities to make JOOR faster and more reliable like:

• Better thresholds and limits on our alerts for early detection
• Implementing data archiving policies on non-needed data
• Optimizing scaling policies on our clusters
• Reviewing legacy services with not-so-great queries
• …

The job is not done, we own it — end to end.

Getting back to basics: Ownership was originally published in JOOR Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

What is FOSDEM?

FOSDEM (Free and Open Source Software Developers’ European Meeting) is an annual conference held in Brussels, Belgium, dedicated to free and open-source software. The event features various talks covering various topics, including programming languages, security, cloud computing, and embedded systems. FOSDEM is free to attend and is known for its community-driven, non-commercial atmosphere.

From my perspective, it’s a must-attend event every year to stay informed about what’s happening in the open-source world. It not only helps you stay up to date but also allows you to see how other engineering teams have tackled various challenges.

How to prepare for it?

To prepare for FOSDEM, the first thing to consider is your profile and interests. In my case, I’m particularly passionate about backend technologies and infrastructure, so I tend to prioritize those tracks.

Additionally, as I mentioned last year, to organize myself and decide which tracks to attend and what talks are available in each, I use an excellent Android app called FOSDEM Companion.

Once we’ve decided which tracks we want to attend, we need to check the rooms where they take place. It’s also important to consider that not all rooms are the same size, and the number of attendees for each talk can vary. If there’s a talk you don’t want to miss, I recommend attending the previous session on the same track to secure your spot.

My 2025 favourite talks

This year, as in previous ones, the tracks I prioritized were Containers, Monitoring, Postgres, Python, and a new track they introduced: Cloud Native Databases. Based on this my favorite talks:

• Reusing PostgreSQL codebase in a Distributed SQL Architecture (YugabyteDB): I found this talk really interesting because it explained how they reused PostgreSQL’s code for their new database engine.
• Migrating Massive Aurora and MySQL Databases to Vitess Kubernetes Clusters with Near-Zero Downtime: They provide a very visual and instructive explanation of how to perform a database migration. Although they focus on their own service, the general principles are applicable to any migration.
• Tracing the Internals of a Cloud-Native DatabaseIn this case, they talk about how the tracing system works within ClickHouse.
• Distributed SQL Technologies: Raft, LSM Trees, Time, and More: What I found most interesting about this talk was its format. They discussed how they tackled various database challenges from the perspective of TiDB and YugabyteDB.
• Distributed Databases: Essential or Optional?: A short talk, but since it’s given by Peter Zaitsev, it’s a must-attend.
• Discovering the Magic Behind OpenTelemetry Instrumentation: Yet another talk about OpenTelemetry, but this time, it was well-explained and very visual.
• The performance impact of auto-instrumentation: The analysis was very interesting, although the conclusions were a bit strange, and the way the data was presented felt somewhat disorganized.
• Zero-Code Distributed Traces for any programming language: My favorite this year within the monitoring track was a talk about how to add traces to any application using eBPF by embedding certain metadata within the information traveling through TCP/IP.
• Anatomy of Table-Level Locks in PostgreSQL: A super interesting talk about the locks PostgreSQL applies when making schema changes and how we could perform these changes with fewer locks.
• How browsers REALLY load Web pages: It demystifies a lot of what happens every time a browser loads a webpage.

And these are the talks I would highlight from this year, 2025. I still have a few saved that I haven’t watched yet, most of which haven’t had their videos uploaded, but I check them every day. Honestly, I’m already looking forward to attending again next year!

Next steps

Attending FOSDEM is a great personal experience, but it doesn’t end there, the real impact comes from what we do next. To maximize the benefits of this experience, we should share key takeaways with our teammates, and encourage discussions about open-source adoptions. Evangelizing open-source principles within our teams is essential to fostering a culture of collaboration, transparency, and innovation.

We also have to keep trying to attend these types of events. The next one on my radar is the OpenSouthCode held in Malaga. I hope to find you there :)

FOSDEM 2025 My Review was originally published in JOOR Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Of course, a senior engineer can solve 55 LeetCode exercises in a minute, make 475 tests per feature, and recite any O’Reilly book by heart, but today I want to talk about something that I think is as important (if not more) as all those things, that is: communication.

I’ll be especially focusing on some tips I learned along the way all these past years while working remotely, that I found out (sometimes not in the best of ways…) and I think they could be pretty useful either if you’re new to professional async communication, or if you have been doing it for a long time but want to contrast your learnings :)

Channel etiquette

• I’ll begin with one of my most recent finds and something that I find quite useful: I think that 99% of people hate when they’re tagged in a thread where a lot of people are discussing and you shouldn’t have been included from the beginning. I propose 2 different solutions for this:
  - One (👎): Just mute the thread. Go to the three dots and click on ‘Turn off notifications for replies’.
  - Two (👍): I like to write whatever is going to start a thread in a message, and then write another one tagging the people that could be interested or implicated. That way, whoever feels they need to contribute to the discussion, can write the proper message and if not, just ignore it.

• Talking about threads… Threads are the best. Use them. Please!!!
• Use carbon copy in messages. In an ideal world, we wouldn’t have that many Slack messages to read, but just in case you do, it takes 5 seconds to tag in a ‘cc:’ at the end of the message all of the people you expect to read your message.
• Along with the threads, I think pins are your best friends! I love pinning important messages in channels! But also, please, don’t forget to unpin them later 😅
• Reactions are a double-edged sword:
  - They are a really good option to follow up a message instead of writing in a thread ‘ok!’ ‘I agree’ ‘thanks!’
  - But: I also think that they’re difficult to follow sometimes, as it notifies you in a very subtle way and I think is very easy to lose track of them. So think about how urgently you want your message to be delivered & read. I’ll show you an example later on.

Short n sweet

• Brevity is the soul of wit. Nothing new.
• Keep info to a minimum. One of the things where I struggle the most is that, when trying to explain some kind of problem, I tend to give the full context of it. And by full context I mean a lot of things that probably make sense in my mind but it can be superfluous to the recipient, and can even worsen the understanding of the message itself.
• please, please, please… try to keep everything in one message. We all have suffered the infamous hello, the even worse Do you have a minute? and several others, where we have to stay put waiting for the other person, seeing the ‘typing…’ while not knowing if they’re going to ask for help or they are going to tell you bad news. PLEASE !!! normalize giving context even if you think the message you want to explain requires a meeting 🙏

Being a good teammate

• Because… yes!! sometimes meets are the best option!! I’m the #1 fan of async communication, but sometimes a quick meet or huddle can save you from spending a lot of time having a conversation that is leading nowhere.
• About the example, I talked about before: which one do you prefer?

• Reactions are good, but there are some cases where I, at least, prefer to have faster and clearer feedback.
• The most important tip from this article: Better to Over-Communicate Than Under. It is also the best relationship advice ever. I know I said earlier that it is nice to avoid unnecessary information when trying to share a message and this could ‘clash’ with this one, but what I’m thinking when writing this tip is that it is better to leave everything you feel the need to share written somewhere, that just believe that everything is well placed in your head and as long as you know it, everything will be okay (spoiler: ❌)
• Remember that having a conversation in Slack is very different from one in real life. I tend to be a very ironic person and sometimes it is difficult for people to get the tone in real life, so just imagine what somebody can think of a Slack message 😬. I love being witty and writing not the way I’m supposed to but the way I feel my words are expressed the closest to how I speak in real life, but sometimes I have to take a step back and think a little if my message can be misunderstood.

Handling personal space

• First and foremost: Take into account the trust level you have with that person. I know it sounds pretty obvious but it has happened to me many times that people talk to me (privately) making some jokes that are not only not funny but offensive to me 😅
• This leads us to two other tips: The first one is, I LOVE having informal conversations via Slack! Most of my work friends were made that way. I remember the first day I started at Joor everyone was so nice to me via Slack 😊. But sometimes people get the wrong idea and can tell you about their day or their problems when you just want to be focused on your work tasks. This is a two-way work: As the sender, know the time and place. As a recipient, let people cordially know that maybe it is not the time and place to do that.
• The second one: know the correct channel & time to talk about. If I for example want to talk about how good Wicked is, maybe I can use a public channel where interested people can discuss it, instead of just boring my teammate to death. But also it would be nice to do that at a time when the production environment is not down 😬
• And if it was not clear: channels are the best. I’m sure there are a lot of repeated work questions or lost information which its cause was that they were made in private conversations. Even if you think nobody cares about what you’re asking, maybe somebody takes a quick look at your question and three months later can search in that channel for that, saving themselves a lot of time.
• Also, something that it is not necessary at all but my Capricorn brain enjoys a lot: it is okay if I send a message and you cannot reply, but if you happen to read it and just don’t feel like answering at that moment, saying something like ‘I’ll reply to you in 2 hours’ reduces my cognitive load a lot.

Make your messages spark joy

This is the point with which I personally struggle the most 😬 I think Tumblr posts damaged my brain forever…
But here’s a series of stylistic choices you can use to help people understand your (long) messages better:

• bullet points (the best one)
• numbered lists: at least for questions for me it is a must. I can’t count how many times I asked several questions with bullet points and only got replies to a few of them 😅 but with numbers I think it is easier for the replier to not skip any answer.
• bold and italics: for keywords! I don’t use these ones that much and I think that usually people tend to highlight entire quotes (which kind of defeats its purpose) but highlighting specific words is your best ally 😌

New Era

My most controversial takes: this is for everyone who likes to call younger generations snowflakes instead of thinking with a little bit of empathy 😬

• This is a nitpick but I’m 100% sure you don’t need to send me a gigantic GIF that takes almost the whole space of our Slack conversation and is redundant with what we have just talked about. I think most of these types of messages come from a place to be more friendly but I find them quite annoying 😪 I just simply prefer to read the message you’re searching for in Giphy than the gif itself!

• Same with emojis… I understand that they are kind of important to balance a little the tone of the message but I think that if you communicate in a good way, you don’t even need them! and if you do, I’m 100% you don’t need them to show exactly the same word you have just written before:

• We don't need that many periods anymore, you can use a new line. I had long conversations about this, and the problem is not that much about using periods per se, but if somebody doesn’t usually use periods when writing Slack messages and then they use one when they are sharing a message that could or could not have the best intentions… seems a little weird. I don’t think everybody takes this the wrong way but some people sure do:
  - Linguistics Explains Why Ending a Text With a Period Makes You Seem Like a Monster
  - Why Using a Period at the End of a Sentence Sounds So Angry
  - There’s a reason why using a period in a text message makes you sound angry — I liked the part about A different form of sincerity
• Take into account the language barrier: As you have for sure noticed in this article English is not my first language, and there are some words that even though we’re writing in the same language, we don’t understand the same way.
  In Spain when we want to laugh we usually use ‘jaja’, and if somebody writes ‘haha’ it seems more like a mocking laugh than the real sound we make while laughing. Also when Spanish people use ‘lol’, they mostly use it as if it means ‘wtf’, not like a real laugh. And this goes both ways, so if I see somebody from the US writing lol at the end of a sentence, I do my best to understand that they’re really laughing and not wondering what I just say 😅
• The same happens with the memes! I myself love Pepe the Frog. It is cute and I love frogs and there’s a lot of cute pictures you can use as reactions. But it has a complicated story and I can understand that some people could take using a reaction the wrong way (although I wish more people knew about the documentary and the artist and could just separate those two things, but as it is not very well known, it is not that much on an effort for me to learn and try not to be disrespectful).
• And that goes along with not taking everything the wrong way and overreacting. I think a lot of the tips mentioned here are things that people may have not thought about or don’t know about. So if you’re in a situation where you’re feeling uncomfortable, we’re all adult people and you can kindly share your opinion and say something like: ‘Hey, I didn’t like that much the way you said that thing to me. did I misunderstand you or is there a real problem we should talk about?’

And that’s all! don’t take this article too seriously as these are just based on my personal experience and I’m constantly growing and learning how can I improve communication every day! I hope some of them were useful to you :)

Slack tips from a gen Z was originally published in JOOR Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this article, we will explain how we integrated SSO into our platform. Our approach was based on this official Zendesk article.

Introduction

We first need to understand how the login flow with a third-party service works within Zendesk. In this case, the first step is to create a new SSO client within Zendesk. To do this, Zendesk will ask for the URL to which users should be redirected when they select this login option. After completing this setup, Zendesk will provide a key that we must use to sign the tokens that will authenticate users within the Zendesk platform.

Once we have the key to sign the Zendesk login token, we’ll go through the detailed steps needed to authenticate a user from our platform in Zendesk:

1. A user wants to log in to our Zendesk through our platform
2. Zendesk redirects this user to the URL with the path that we indicate in the configuration
3. The route within our platform to which Zendesk redirects our user validates whether the user is already logged in within our platform or forces them to log in.
4. Once the user has an active session within JOOR, we ask our API to generate a session token for Zendesk using the key that Zendesk provided us.
5. Our web portal redirects with this session token to Zendesk
6. The user finally accesses Zendesk as a logged-in user

Implementation details

Once we have a clear understanding of the generic process for authenticating users in Zendesk from a third-party service, we can explain how we’ve implemented it within our platform.

The JOOR platform can be summarized as a Single Page Application (SPA) built with React, along with an API that retrieves the data clients see on each page. Both our web application and API have certain endpoints that are public (access without being logged in) and others that are private (logged-in access only).

To implement this authentication flow within our platform, we need to create a private endpoint in our API that logged-in users can use to request their Zendesk authentication token. This endpoint must be private and accessible only to registered users. It will return a JWT signed with the secret provided by Zendesk. The structure of the JWT expected by Zendesk is described here, and an example of the code would be:

import jwt
import time
import uuid
import os

def generate_zendesk_sso_token(logged_user: User) -> str:

  payload = {
      'iat': int(time.time()),
      'jti': str(uuid.uuid4()),
      'external_id': logged_user.id,
      'email': logged_user.email,
      'email_verified': True,
      'name': logged_user.name,
  }

  zendesk_secret = os.getenv('ZENDESK_SSO_SECRET')  
  token = jwt.encode(payload, zendesk_secret, algorithm='HS256')

  return token

Once we have this API endpoint implemented, we move on to our SPA page. In this case, it will be a page on a new path that simply redirects to Zendesk via a POST request. Before performing this POST redirection, it will need to obtain the Zendesk token from the API to authenticate the user.

$ # cURL format required by Zendesk
$ curl --location 'https://<your-zendesk-domain>.zendesk.com/access/jwt' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'jwt=<user-jwt>' \
--data-urlencode 'return_to=<return_to_url>'

In the official Zendesk article we’ve mentioned several times here, they explain that when Zendesk redirects users for login, they add a query parameter called return_to, which indicates the original path from which our users decided to log in. To improve their browsing experience, it’s highly recommended to send this parameter back to Zendesk, so these users can continue navigating from the point where they left off. With that in mind, our React component would look like this:

const ZendeskSSOLoginPage = () => {
  const DEFAULT_ZENDESK_URL = getDefaultZendeskUrl()
  const ZENDESK_SSO_URL = getZendeskSSOUrl()

  const { data, loading } = useFetchSSOToken()
  const searchParams = new URLSearchParams(useLocation().search)
  const returnTo = searchParams.get('return_to') || DEFAULT_ZENDESK_URL

  const sendPostRequest = (jwt_token: string, returnTo: string) => {
    const form = document.createElement('form')
    form.method = 'POST'
    form.action = ZENDESK_SSO_URL

    const jwtInput = document.createElement('input')
    jwtInput.type = 'hidden'
    jwtInput.name = 'jwt'
    jwtInput.value = encodeURIComponent(jwt_token)
    form.appendChild(jwtInput)

    const returnToInput = document.createElement('input')
    returnToInput.type = 'hidden'
    returnToInput.name = 'return_to'
    returnToInput.value = encodeURIComponent(returnTo)
    form.appendChild(returnToInput)

    document.body.appendChild(form)
    form.submit()
  }
  useEffect(() => {
    if (!loading && !!data) {
      sendPostRequest(data.token, returnTo)
    }
  }, [data, loading])


  return (
    <LoaderComponent>
        Redirecting...
    </LoaderComponent>
  )
}

Conclusion

As seen in the article, integrating our platform with Zendesk to authenticate users has been quite straightforward. If you have any questions or suggestions, please let us know. We hope this article has been helpful to you.

How we integrate Zendesk SSO login into JOOR was originally published in JOOR Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

These days, it’s very common for Software Engineers to create applications that require access to third-party services. Examples of such third-party services include APIs, databases, and cloud-based applications. Many applications and companies operate and deploy their services on Amazon Web Services (AWS). Additionally, one of the first and most renowned services offered by AWS is Simple Storage Service (S3).

When Docker entered the realm of development, setting up a local database for development became extremely easy. You could create a docker-compose.yml file where you had both the database and your service defined. This allowed for relatively simple end-to-end testing of certain services locally.

But what about other third-party services? Do I have to create mocks in my tests? Furthermore, in the case of certain services like S3, operations (both read and write) incur a cost. Would I have to pay every time I want to perform an end-to-end test?

Each type of third-party service has its way of being simulated. In this case, I’m here to explain how we can simulate S3 locally, enabling us to carry out all the operations that S3 allows without needing to access the AWS cloud.

LocalStack

LocalStack is a powerful tool used in software development for creating local environments that replicate various AWS cloud services. It allows developers to emulate the behavior of AWS services, such as S3 (Simple Storage Service), SQS (Simple Queue Service), SNS (Simple Notification Service), DynamoDB (NoSQL database), and many others, on their local machines.

Essentially, LocalStack provides a local sandbox environment that mimics the AWS cloud infrastructure, enabling developers to test their applications locally without incurring any costs associated with using the actual AWS services. This is particularly useful for development and testing purposes, as it allows developers to experiment with AWS services, develop and debug their applications, and run end-to-end tests without relying on the internet or incurring expenses.

Moreover, this tool comes neatly packaged in a Docker image, ready to be configured in our typical docker-compose.yml file.

In this article, we won’t delve deeply into all the options and what can or cannot be done, as LocalStack has very good documentation on its website.

Example

In this section, we’re going to perform an exercise as generic and simple as possible. For this reason, we’ll create a playground environment with the following requirements:

• We’ll have two containers: a Debian and a LocalStack.
• When we start the playground environment (docker compose up -d), the S3 bucket named ‘david-garcia-medium’ must exist.
• From the Debian container, using AWS CLI, I should be able to perform operations with S3 as if it were the actual AWS itself.

First of all, let’s display the file structure of our repository.

./
  playground/
    aws/
      config
      credentials
    aws_cli/
      awscliv2-amd64.zip
      awscliv2-arm64.zip
    localstack/
      s3.sh
  .env.debian
  .env.localstack
  docker-compose.yml
  Dockerfile

In the ‘playground’ directory, we have the necessary configuration to make our playground environment work. In this case, we have three subdirectories:

• aws: which contains the authentication configuration required by AWS CLI to access AWS.
• aws_cli: where we have the downloaded AWS CLI binaries — in this case, we’ve downloaded both the AMD (for Linux in general) and ARM (for Mac with M1 in general) versions.
• localstack: with a script, which will be used to configure the startup of the LocalStack container.

The .env.debian and .env.localstack files are files with declared environment variables that will be mounted to the containers in the docker-compose.yml. They contain the following information

# .env.debian
# AWS cli configuration
AWS_PROFILE=localstack

The .env.debian is very simple, and only contains the AWS environment variable used by AWS CLI to know what profile must be used by default. If we review the files available in playground/aws path we find the following

# config
[profile localstack]
output = json
endpoint_url = http://localstack:4566
region = us-east-1

# credentials
[localstack]
aws_access_key_id=test
aws_secret_access_key=test

In the playground/aws/config file, we overwrite the endpoint_url to use our LocalStack as AWS backend instead of the official AWS. In the playground/aws/credentials we configure the credentials to the localstack profile.

Let’s review the .env.localstack

# .env.localstack

SERVICES=s3

# Checker
TRIES=30

# Base
HOSTNAME_EXTERNAL=localstack

LOCALSTACK_API=http://localstack:4566
LOCALSTACK_HEALTH_ENDPOINT=http://localstack:4566/health

# S3
BUCKET_NAMES=david-garcia-medium

# AWS cli configuration
AWS_DEFAULT_PROFILE=localstack

These environment variables are typically utilized by the script located at playground/localstack/s3.sh. This script serves as a fundamental tool that executes once the LocalStack container is up and running, facilitating the creation of the pre-existing S3 bucket that we require. This script will be mounted in the path /etc/localstack/initi/ready.d and the localstack container will execute when it is ready. More info here

Let’s review the docker image with debian, the Dockerfile

FROM docker.io/debian:bookworm-slim

# Added TARGETARCH to differenciate between amd64 (Linux and Windows) and arm64 (Mac) when install awscliv2.zip
ARG TARGETARCH

# Install zip
RUN apt update && \
    apt install -y zip=3.0-13 && \
    rm -rf /var/lib/apt/lists/*

# Install awscli
COPY playground/aws_cli/awscliv2-${TARGETARCH}.zip .
RUN unzip awscliv2-${TARGETARCH}.zip && \
    ./aws/install && \
    rm -rf awscliv2-${TARGETARCH}.zip aws

# By default, this container does not execute anything; it simply sleeps indefinitely.
CMD ["tail", "-f", "/dev/null"]

In this scenario, the image is quite straightforward, with the only sophisticated aspect being our readiness to build the image for both amd64 and arm64 architectures, utilizing the TARGETARCH Docker ARG. We use the binaries stored in playground/aws_cli instead of downloading them via curl in the Dockerfile to ensure consistent installation of the same version of AWS CLI. This practice guarantees that each time we rebuild the image, we maintain uniformity in the awscli version.

And finally, we see the docker-compose.yml file with the definition of the services before running a test and verifying that everything works.

version: '3.7'


services:
  debian:
    build:
      context: .
      dockerfile: Dockerfile
    depends_on:
      - localstack
    env_file:
      - .env.debian
    volumes:
      - ./playground/aws:/root/.aws:ro


  localstack:
    image: docker.io/localstack/localstack:3.1
    ports:
      - "4566:4566"
    env_file:
      - .env.localstack
    volumes:
      - ./playground/localstack:/etc/localstack/init/ready.d/:ro
      - ./playground/aws:/root/.aws:ro

As you can see, there’s nothing unfamiliar here that we haven’t commented on previously. Let’s test it:

$ docker compose down -v && docker compose up -d && docker compose exec debian bash
...
root@9698486ac759:/# # List the aws s3 buckets availables
root@9698486ac759:/# aws s3 ls  
2024-04-02 17:57:15 david-garcia-medium
root@9698486ac759:/# # Create a file and upload to S3
root@9698486ac759:/# echo "hello medium" > my_file.txt
root@9698486ac759:/# aws s3 cp my_file.txt s3://david-garcia-medium
upload: ./my_file.txt to s3://david-garcia-medium/my_file.txt   
root@9698486ac759:/# aws s3 ls s3://david-garcia-medium
2024-04-02 18:02:06         13 my_file.txt
root@9698486ac759:/# # Create a new S3 bucket
root@9698486ac759:/# aws s3 mb "s3://my-new-bucket"
make_bucket: my-new-bucket
root@9698486ac759:/# aws s3 ls                     
2024-04-02 17:57:15 david-garcia-medium
2024-04-02 18:04:20 my-new-bucket
root@9698486ac759:/# # you can test other commands!

Extra example

Furthermore, LocalStack provides the files we have uploaded to S3 at the following path: http://localhost:4566/<bucket-name>, and you can download them using the S3 key.

$ curl http://localhost:4566/david-garcia-medium
<ListBucketResult xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
  <IsTruncated>false</IsTruncated>
  <Marker/>
  <Name>david-garcia-medium</Name>
  <Prefix/>
  <MaxKeys>1000</MaxKeys>
  <Contents>
    <Key>my_file.txt</Key>
    <ETag>"5047cdd6613d55aa1a3143639a81cf78"</ETag>
    <Owner>
      <DisplayName>webfile</DisplayName>
      <ID>75aa57f09aa0c8caeab4f8c24e99d10f8e7faeebf76c078efc7c6caea54ba06a</ID>
    </Owner>
    <Size>13</Size>
    <LastModified>2024-04-02T18:02:06.000Z</LastModified>
    <StorageClass>STANDARD</StorageClass>
  </Contents>
</ListBucketResult>

$ curl http://localhost:4566/david-garcia-medium/my_file.txt
hello medium

To conclude, you have all the code available in the following GitHub repository.

Setting Up a Local AWS S3 Environment for Development: A Step-by-Step Guide was originally published in JOOR Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

How do we organize our hiring pipeline?

We recognise that applying to any position sucks no matter what, that’s why we are transparent with our processes.

Everything starts with the job description.

We try to include some context about us, our expectations, the future type of work, available locations, and, above all, a comprehensive list of perks, including the compensation range for the position, no mystery, we don’t want you to lose your time.

Once the offer is published, we review internally every applicant looking for potential fits. Surprisingly, many of the candidates can’t qualify for the position: non-viable locations, total lack of experience in the role (not talking about tech stacks), a salad of buzzwords with no rhyme, resumes with lots of typos…

When we find you (😉 a lovely candidate), Naomi will arrange a super brief HR intro screening with you. Don’t be afraid, we ain’t gonna challenge your talent yet, but we need to confirm a few things: a legit interest in the role, you can speak good enough English, and our mutual expectations are aligned. 15mins or less.

99% of people will move quickly from the HR call to the leveling interview. Our goal here is to discover if the candidate can fill our expectations for the role: experience, knowledge, appetite, and, above all, humanity 😅. 30mins.

No kidding, like any other organization, we have our fair share of challenges but we can’t afford to hire a bad teammate regardless of how great (s)he codes.

One or two days after the leveling interview you receive an invite to our final boss… the (remote) onsite.

The onsite

The last stage consists in a series of 3 interviews that we try to run in a row to close our mutual discovery:

• Culture fit: An open talk with 1 or 2 future teammates where they try to answer the question “Would you like to work with this person?” 30mins.
• Technical interview: A longer session with a couple of other people to do some work together. Mostly consists of a few closed technical questions, a brief open design question, and some pairing on a minimalistic exercise. 1hour.
• [Management interview]: Lastly, depending on the role, we will have a last session with one of the managers to close the process. 30mins.

In total a JOOR process for you should no longer than 2h45mins with no take-home assignment 🚀

😴 I crushed it, why no offer?

Maybe you:

• Only talked about frameworks instead of designs decisions.
• Didn’t listen while pairing with your future teammates.
• Coudn’t recognize any mistake from your past.
• Didn’t care about the big picture.
• Navigated the code with no rhyme or reason.
• Copied and pasted until a miracle happens.
• Didn’t show curiosity.
• Didn’t recognize the value of writing and reading.
• Have a gigantic ego. 🙅

or … maybe you actually did a very good job on your interview but somebody else did better.

In the end, the question is not if you are qualified for the role but if you’re the one that, we think, can help us the most.

That’s all folks!

You might be wondering why anybody should care about the hiring philosophy of a mid-sized scale-up.

It’s just a testament of our vision for building the right company, with the right values and, above all, the right people.

Neither you as a candidate nor we as a company are perfect. We may surely lose some incredible candidates along the way 🤷‍♂. However, if you’re curious, we often have some open positions here👇

https://www.joor.com/current-openings

Why was I rejected from my JOOR interview? was originally published in JOOR Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Why FOSDEM?

For me, it’s an incredibly exciting experience to witness the latest developments in open-source projects and to learn about new technologies that have emerged over the past year.

I’m a backend engineer with a strong interest in databases, observability, Linux, and programming. In my current role, I work extensively with Python, PostgreSQL, and Kubernetes. Therefore, the most interesting tracks for me were:

• Containers devroom: Saturday 3 February 2024
• Monitoring & Observability devroom: Sunday 4 February 2024
• PostgreSQL devroom: Sunday 4 February 2024
• Python Devroom devroom: Sunday 4 February 2024

How to prepare for it?

I always start by selecting my favourite tracks to choose the talks that I find most interesting there. Once I’ve chosen the talks I’m most interested in from my favourite tracks, I then explore the remaining tracks to see which talks I like.

An important thing to keep in mind about FOSDEM is that not all rooms where talks are held are equally large, nor are they all in the same building. It’s worth considering that if a talk looks very promising, it may fill up before its scheduled time, and you might end up being unable to attend. Similarly, if it’s in a distant building, you may not make it in time.

To organise which talks to attend and to know where they are, my recommendation is to use the FOSDEM Companion app. This app not only includes all the tracks with their talks and schedules, but it also provides maps of the university campus to show you where the buildings are located, and within each building, it indicates the location of each room.

My 2024 favourite talks

With that said, here are my favourite talks:

• Forensic container checkpointing and analysis (Containers devroom): a very interesting talk about checkpointing containers. It’s a continuation of the talk he gave last year.
• Introducing Incus (Containers devroom): It teaches us what Icus (fully-fledged system container and virtual machine manager) is, in addition to providing a live demo, which is always appreciated.
• Open Food Facts : Acting on the health and environmental impacts of the food system (Lightning talks): It shows us how, through an OpenSource community, we can monitor the food we buy at the supermarket.
• Reinventing database exploration with Azimutt (Lightning talks): In this case, since I’ve been reviewing a very large database in my last month of work, this type of tool would have been very helpful for me.
• Passbolt — Open source password manager for teams (Lightning talks): It teaches us how to have our own password manager, in addition to giving us a sneak peek at some features that will come in the future.
• Testing Containers with Python and pytest (Lightning talks): It teaches us about the pytest-container library, a library that I wasn’t familiar with and found super interesting and useful for testing our Docker images.
• Platform engineering for dummies (Lightning talks): What is platform engineering? Here you have the detailed answer.
• Isolation Levels and MVCC in SQL Databases: A Technical Comparative Study (PostgreSQL devroom): A graphical and visual explanation of the different types of isolation levels in database transactions and how PostgreSQL applies them.
• Reducing Costs and Improving Performance With Data Modeling in Postgres (PostgreSQL devroom): It explains how data is stored on disk in PostgreSQL and how the order in which we declare columns in a table matters and can help us save space.
• Linux load average and other silly metrics (Monitoring & Observability devroom): It teaches us how to interpret typical metrics of Linux systems, such as load average.
• Practical CI/CD Observability with OpenTelemetry (Monitoring & Observability devroom): A good practical example of integration with OpenTelemetry.
• Implementing distributed traces with eBPF (Monitoring & Observability devroom): In this case, they teach us how to leverage the features provided by eBPF to add traces to our applications in order to monitor the entire system.
• Your Virtual DBA (PostgreSQL on Kubernetes using an Operator) (PostgreSQL devroom): They discuss the role of a DBA and the requirements a Kubernetes Operator must have to deploy a database.

These are the talks I’ve liked the most so far. I haven’t finished watching all the ones I couldn’t attend in person yet. Additionally, some of them haven’t been uploaded to the website yet, so I still have to wait a bit.

This year has left me with a good impression, and to be honest, I’m looking forward to attending again next year.

About JOOR

Founded in 2010, JOOR now services more than 14,000 brands and over 600,000 buyers across 150 countries, processing an incredible $1.7B in wholesale transaction volume each month.

We have some open positions from time to time, if interested and curious just check them here.

FOSDEM 2024 My Review was originally published in JOOR Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Preventing bugs is a complicated task, but we can reduce the number of errors in our code by following best practices such as writing tickets with very detailed descriptions that cover all possible use cases, using clean code when developing features, or writing robust tests, among other things.

Whose responsibility is it to ensure there are no bugs?

We could say that the responsibility lies solely with QA (Quality Assurance) engineers (if there are any), but besides being false, it’s unfair because we would be delegating all the responsibility to them.

In some teams, there is the perception of a QA engineer as a role that ensures no ticket introduces bugs into production. I’ve heard developers say, “I write the code and then the QA tests it.” This shouldn’t be the case.

The quality of the code is a shared responsibility among the entire team.

When should I start thinking about the bugs that the code might generate?

Most bugs are introduced during the development phase, and this happens for different reasons: what if the developer has started working on a ticket with an incorrect task description? What if the acceptance criteria are vague and ambiguous or not even defined?

We must think about bugs from the very moment we create and refine a task. Thinking about them during development is too late.

Let’s suppose we have the following software development lifecycle:

1. Requirements
2. Design
3. Implementation
4. Review and QA
5. Deploy to production

If you notice, QA is in the last phase before reaching production, which means that QA feedback comes very late, and the developer will take that feedback into account in the last phase before deploying to production. This can lead to an endless conversation between the developer and QA when reviewing the functionality, and a single task can have multiple back-and-forth exchanges (like a ping-pong match) simply because QA wasn’t involved even before starting the development.

Fixing a bug incurs a cost that significantly grows as it progresses through the development stages. It’s much easier and cheaper to fix a bug in the earlier stages of development than once it’s deployed in production.

Therefore, not using shift left testing has several implications:

• By not focusing on testing from the first stage, implementation time increases
• With increased implementation time, feedback on the task arrives very late
• If feedback arrives late, the effort and cost of changing the code are higher

So, what is shift left testing?

Shift left testing means focusing on testing from the very beginning when we start thinking about how to approach a task. We must consider all use cases, both happy paths and corner cases, to ensure that task acceptance criteria are as detailed as possible.

Benefits of shift left testing

1. Early bug detection: by moving testing activities earlier in the development process, bugs and issues can be identified and addressed sooner, reducing the cost and effort required for fixing them later in the development lifecycle.
2. Improved product quality: with testing integrated earlier in the software development cycle, the quality of the software improves as issues are identified and resolved in earlier stages.
3. Faster feedback loop: developers receive quicker feedback on their code, allowing them to make necessary adjustments promptly, leading to faster iteration and development cycles.
4. Cost reduction and faster time-to-market: identifying and fixing issues earlier in the development process reduces the overall cost of software development by avoiding expensive rework and late-stage bug fixing.
5. Increased collaboration: shift left testing encourages collaboration between developers, testers, and other stakeholders from the outset of the project, fostering a culture of shared responsibility and collaboration.
6. Customer satisfaction: by delivering higher quality software with fewer defects, shift left testing ultimately leads to increased customer satisfaction.

How to implement shift left testing?

Include testers in the earliest stage possible

Including testers in the requirements gathering phase is crucial for successfully implementing shift left, as they provide a detailed perspective on how developments should be tested even before developers start writing code.

If developers have very detailed acceptance criteria and know exactly how the code should behave and what will be tested, the number of bugs and rework will be drastically reduced.

However, this also implies an evolution of the tester’s role, typically focused on capturing bugs once development has concluded; to the role of QA itself, oriented towards preventing bugs throughout the entire SDLC. This transition is not always easy, and QAs may need some mentorship when adapting to these new functions in their daily routine.

Add very detailed acceptance criteria to your tasks

Acceptance criteria are a contract that, if we have done a good job of researching the problem beforehand, should not change during development.

Making changes to acceptance criteria after development is very expensive, as it forces the programmer to rewrite already completed code due to incorrect requirements.

Make sure all the team understands the acceptance criteria

Developers must test their code before sending it to the review stage

Multiple bugs and conversations between developers and QA can be avoided by testing the code correctly. Unit testing is an extremely powerful tool that can be used to reduce review time and the number of bugs in the code. Manual testing is expensive and should be avoided.

Continuous feedback

Developers should work with QA and the Product Manager (if any) during the implementation stage so they can provide feedback to the developer as soon as possible. This way, we reduce the amount of rework and the number of late-stage bugs.

Real results

At JOOR, we have several teams within the engineering team, and I would like to show you some numbers on how shift left testing can save time, bugs, and money.

I won’t be showing the numbers for all teams and all quarters to simplify, but the rest of the teams have had similar results.

Metrics

• Cycle time: how long does a story take to be completed after being started
• Dev time: how long does a story remain in progress
• Review time: how long does a story take to be moved from in-review (code review and QA) to merged/deployed

Shape of work

Takeaways

In Q2, we didn’t work with shift left. The percentage of bugs we fixed was 10.3%. As you can see, the review time was over two days.

In Q3, we started using shift left testing, but you know how these things go. Establishing a new methodology in a team is not easy and takes time for everyone to get used to working with it and start seeing the benefits.

Despite this, we managed to reduce the cycle time by 23 hours and also the review time by 6 hours.

In the last quarter, Q4, we reduced the cycle time to 2 days and 11 hours, which is a reduction of 1 day and a half compared to 6 months ago. The review time was reduced to 14 hours, which is very low compared to the initial 2 days and 5 hours.

In addition to that, we were able to complete much more work while reducing the percentage of bugs.

As you can see, it doesn’t take more time to program using shift left because the development time is maintained, but the review time is greatly reduced, so we get more work done in less time and also without adding more bugs.

How shift left testing can save you bugs, time, and money was originally published in JOOR Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.