I use a MacBook Pro M1. The laptop works well for most tasks such as browsing or programming. I kind of miss the Touch Bar that Apple introduced and has discontinued a few years ago. Definitely gimmicky but not the worst gimmick in my opinion and sometimes neat functionality.

Somehow, the Touch Bar recently disappeared on my MacBook without warning. As the MacBook is still working fine I did not want to get rid of it yet. Hence I looked into what it takes to get the Touch Bar to work again.

Of course, there are the usual suspects:

• Restart the laptop
• Update MacOS to the latest version
• Go to System Settings -> Keyboard -> Touch Bar
• Kill the Touch Bar process using the Activity Monitor

If any of these steps did the trick for you: great! However, these things did not help me in my situation. I was afraid that it was a hardware issue. Instead, the following approach describes how I actually fixed the Touch Bar on my MacBook:

1. Turn off the MacBook completely
2. Start the MacBook and keep the power button pressed until you get to the boot menu
3. Press Shift, then select the volume (usually called “Macintosh HD”) and then select “Safe Boot”
4. Verify that you are in Safe Mode (e.g. the top menu bar on the login screen may say so). Login normally with your credentials in Safe Mode.
5. Your Touch bar may now work again. Turn off your MacBook and restart normally without Safe Mode.

It seems that the Safe Mode made the MacBook “remember” that it has a Touch Bar. Basically, it turned out to be yet another case of “a reboot fixes any issue” that IT people preach (for good reason) — but in this case, it needed a very particular kind of reboot 😄

In case it is still not working and you also tried the usual suspects mentioned above, then it might indeed be a hardware failure and the only thing that you can do is to let a professional repair it.

Conclusion

Thanks for reading this short post. I for one am glad that it was merely a software problem and not a hardware issue. Still, I wish this information would have showed up quicker in ChatGPT/Gemini/Google which gave me motivation to turn this into a quick blog post. Let me know in the comments in case you had a similar issue.

When you run a command with sudo in MacOS or Linux, the terminal prompts you to type in your password and it doesn't give you any visual feedback.

I am a fast typer, so when I mess up my password, I have to start over from scratch. Also, it sometimes happens that I am not even sure that something is happening while typing. I am fine with not showing the password while typing but it would be neat to see asterisks like in regular password fields. Luckily, it turns out it is easier than I initially thought.

Here is a quick tweak that will bring back those familiar asterisks (*) when you type in your password. We will use vi but other editors like nano should work as well. To bring back those asterisks, we can do the following:

1. Run the following command in a Terminal: sudo visudo
2. Scroll down to the line that looks like this: Defaults env_reset
3. Change it to this: Defaults env_reset,pwfeedback . Optional: you can provide a comment so that your future self remembers why you changed this setting in the first place.
4. Exit and save the changes. Mac users, for example, may use vi and will have to type :wq and press Enter to exit.
5. Restart the terminal and run a command requiring sudo: you should now see asterisks when typing.

Security Implications

Yes, there is a security risk, though it is relatively minor in most scenarios from what I can think of. Here is a breakdown of what changes when you enable pwfeedback.

Shoulder Surfing: One reason terminal passwords are invisible by default is to prevent someone standing behind you from seeing the length of your password.

• Without asterisks: A bystander has no idea if your password is 10 characters or 40.
• With asterisks: They can count the characters. This narrows down the “search space” if someone were trying to brute-force or guess your password later.

Systematic Vulnerability: In very high-security environments, even the timing of those asterisks appearing could theoretically be used in a “side-channel attack” to guess characters based on typing rhythm, though this is overkill for most regular users.

Caveats & Limitations

The only caveat I ran into is that this will not work everywhere. I will use Apple’s FileVault mechanism as an example. The reason it is not working there is that FileVault (and the fdesetup command) operates on a different security layer than standard sudo commands.

When you run a standard command like sudo brew install, the sudo utility is what asks for your password. Since you edited the sudoers file, sudo knows to show you the asterisks.

However, when you run sudo fdesetup, two things happen:

1. sudo asks for your admin password (this should show asterisks).
2. Once authorized, the fdesetup tool takes over and asks for your FileVault Recovery Key or password.

At that second step, fdesetup is talking directly to the macOS Disk Management framework, which does not care about your sudoers settings. It has its own hard-coded security behavior.

FileVault handles encryption at the disk level. Apple intentionally keeps these prompts as “sterile” and feedback-free as possible. I’d think it’s because FileVault passwords and recovery keys are the “keys to the kingdom” for your entire hard drive, macOS doesn’t allow user-level configuration files (like sudoers) to change how that data is handled or displayed.

Conclusion

Overall, this is a nice quality of life change that I wish I knew earlier. Even though the caveat mentioned above is a bit annoying, I appreciate that working with sudo becomes easier by seeing the asterisks.

Any other near tricks that come to mind when working with the terminal? Let me know in the comments.

At Sunhat, we spend a lot of time in TypeScript. Between technologies like Angular, NestJS, and Nx, there’s a lot of code moving fast across a SaaS product. The bigger a codebase grows, the more you rely on the small invisible things that keep it maintainable. ESLint is one of those things.

I’ve come to see ESLint not just as a linter but as a guardrail system. It keeps you from slowly drifting into chaos. We have a custom ESLint setup that evolved over time, and there are a few rules that have proven helpful to how we work.

This not only applies to the engineers themselves but also to AI tools like Cursor. We use tools like Cursor increasingly for refactorings, quick iterations, and exploring changes. When your codebase has strict, automated constraints, the AI doesn’t just write code: it writes "your" code. It is less hallucinating patterns that don’t exist and starts following your architecture and good practices.

ESLint rules effectively teach them how your code is supposed to look. If not already done automatically, you can let your AI tools make use of ESLint to validate itself. Hence the AI has far fewer degrees of freedom when it’s generating code. That’s a good thing.

These are the categories of rules we’ll be looking at:

• Avoiding to delete temporary code
• Prefer
• Avoid common bugs
• Consistency

Without further ado, let’s have a look.

1. @nrwl/nx/enforce-module-boundaries

If you use Nx, this rule is non-negotiable. We treat our Nx workspaces as modular systems. Each app and library has a clear domain. Without boundaries, developers will eventually take shortcuts — importing code from where it’s convenient rather than where it belongs.

This rule prevents that. It enforces dependency constraints between libraries, ensures each domain stays self-contained, and stops circular imports before they ever happen. Every time it blocks a “quick import” across layers, it saves you from future architectural debt.

Here is an example:

'@nx/enforce-module-boundaries': [
    'error',
    {
        allow: [],
        depConstraints: [{
                sourceTag: 'type:app',
                onlyDependOnLibsWithTags: ['type:feature', 'type:shared']
            },
            {
                sourceTag: 'type:feature',
                onlyDependOnLibsWithTags: ['type:shared', 'type:feature']
            },
            {
                sourceTag: 'type:shared',
                onlyDependOnLibsWithTags: ['type:shared']
            }
        ]
    }
]

2. @typescript-eslint/member-ordering

Codebases aren’t just about what they do, but how they feel when you read them. This rule enforces consistent ordering of class members: constructors, lifecycle hooks, public methods, private helpers, and so on. You don’t have to wonder where to find things.

'@typescript-eslint/member-ordering': ['warn', {
    default: ['field', 'get', 'constructor', 'method', 'signature']
}]

3. @typescript-eslint/naming-convention

Naming consistency is one of those things you don’t appreciate until it’s gone.

This rule enforces our conventions for classes, interfaces, constants, and private members. It’s the kind of detail that prevents friction: like whether we prefix private fields with _ or not, or if interfaces should start with I. More importantly, it makes code reviews shorter because we no longer have to discuss naming at all.

 '@typescript-eslint/naming-convention': ['error', {
     selector: 'default',
     format: ['camelCase']
 }, {
     selector: ['class', 'interface', 'typeParameter', 'typeAlias'],
     format: ['PascalCase']
 }, {
     selector: ['objectLiteralProperty', 'objectLiteralMethod'],
     format: null
 }, {
     selector: ['enum', 'enumMember'],
     format: ['PascalCase', 'snake_case']
 }, {
     selector: 'parameter',
     format: ['camelCase'],
     leadingUnderscore: 'allow'
 }, {
     selector: 'variable',
     format: ['UPPER_CASE', 'camelCase'],
     leadingUnderscore: 'allow'
 }, {
     selector: 'typeProperty',
     format: null,
     filter: {
         regex: '^_count$',
         match: true
     }
 }]

4. @typescript-eslint/prefer-optional-chain

Instead of deeply nested null checks, you just write foo?.bar?.baz. It reads like a sentence and eliminates a ton of boilerplate.

We enforce it to keep code clean and expressive — and to avoid the old “cannot read property of undefined” errors that everyone loves.

5. @typescript-eslint/prefer-nullish-coalescing

This rule complements the previous one. It enforces ?? instead of || when dealing with default values.

Why? Because 0 and " are valid values. With ||, they’re treated as falsy, and you might accidentally override them. ?? fixes that by only falling back on null or undefined. Small difference that can prevent easy-to-miss-bugs.

6. @typescript-eslint/switch-exhaustiveness-check

If you’re switching over a union type, this rule ensures all possible cases are handled. If a new variant is added later and you forget to handle it, then ESLint reminds you.

For us, this is crucial in large enums and discriminated unions that evolve as our business logic grows.

7. etc/no-commented-out-code

Dead code is noise. Commented-out code is lying noise: it suggests something might matter when it doesn’t. We don’t leave commented code behind. If it’s useful, it belongs in Git history. If it’s not, delete it.

This rule keeps our diffs smaller and our minds clearer.

8. lodash-fp/use-fp

We use lodash/fp instead of the classic lodash API. The functional version promotes immutability and better composability.

This rule enforces that all lodash imports come from lodash/fp. It prevents accidental mutable operations that could mess with state.

9. no-console

Logging is great. But stray console.logs in production code aren’t.
We use structured logging through proper monitoring and telemetry systems (Sentry, platform logs, etc.).

This rule blocks console.log and similar methods from creeping into production code while allowing explicit exceptions where necessary.

10. no-param-reassign

Mutating function parameters is one of those small bad habits that quietly leads to bugs.

We want our functions to be predictable and side-effect free.
This rule forces you to create new variables instead of mutating inputs. It makes data flow more explicit and debugging much easier.

11. prefer-const

If a variable never changes, it should be const. This rule is simple, but it’s one of those that make JavaScript feel more like a safe, typed language.

const means: “this won’t change.” It signals intent and thereby reduces mental load.

Conclusion

Our ESLint config is a small example of our philosophy in action. It encodes what we care about: safety, clarity, and consistency. And when those things are built into your tooling, your team gets to focus on what really matters: building. Of course it’s up to your team to decide which rules make sense. And if existing rules don’t cover it: why not create your own?

Thanks for reading this post. Let me know in the comments about useful tools and rules you are using.

If you’ve spent any time staring at slow CI runs on GitHub Actions, you know the pain: minutes tick away while runners spin up and tests crawl.

We’ve been chipping away at this for a while, constantly tweaking caching and optimizing job dependencies. But we recently hit a ceiling that came down to the simplest piece of infrastructure: the runners themselves.

Even when you pay for beefier GitHub hardware, per-minute pricing adds up quickly — and the default GitHub runners may still not keep up with how fast teams like us want to iterate.

The goal was simple: keep all the goodness of GitHub Actions (YAML workflows, integrations, secrets, triggers), but run them on hardware and tooling that gives you better performance per dollar. Hence we started to use Blacksmith as a drop-in replacement for GitHub’s hosted runners.

Benefits

Here’s what we found when we adopted Blacksmith:

• Significant speedups — Blacksmith runs Actions on high-performance machines with better throughput than GitHub’s default runners and even faster than their dedicated runners with the same hardware configuration, so builds and tests finish noticeably faster.
• Faster runs, lower bills: Blacksmith advertises ~2× faster execution and ~50% cheaper per‑minute cost than GitHub hosted runners, which in practice can cut your CI bill by up to ~75%. Your mileage may vary but we are seeing good improvements.
• Plug‑and‑play adoption: For most workflows, you only need to swap the runs‑on label to a Blacksmith runner — no major config rewrites.
• Better observability: You get deeper insights into pipeline performance and failures rather than the opaque logs you typically see in GitHub Actions.

Beyond the Cost-Per-Minute: The Hidden Factors

Startups and smaller CI providers don’t have the decades of uptime and SRE experience that GitHub itself has built up. Public status trackers do show occasional service warnings or outages reported for services such as Blacksmith, just like any modern SaaS. And it’s not like that GitHub does not experience outages as well.

That doesn’t mean these providers are flaky by default but it does mean you need to think about operational risk: how often does a CI provider go down? What’s your fallback? And how does that compare to simply accepting slower builds on a hyper‑scale provider?

For teams thinking about this, don’t ignore security and compliance either. CI runners execute arbitrary code and often have access to sensitive data, so the underlying platform needs to meet your security bar. In our case we were comfortable because the runner provider we chose publishes compliance details like SOC 2 Type II and standard data protection certifications, and runs jobs in isolated microVMs so that state isn’t shared across workflows.

Conclusion

Cutting down run times and CI costs means fewer context switches, faster PR cycles, and more predictable velocity. If you’re evaluating third‑party runners, there isn’t a single “right” choice — it’s a tradeoff between faster feedback, lower CI costs, and how much operational responsibility you want to shoulder for another service.

There’s a whole space of third-party runners out there (BuildJet, WarpBuild, Ubicloud, self-hosted options, etc.), and the right choice depends on your workload and priorities. But if you’re on GitHub Actions today and want an easy way to bump throughput without a big migration, Blacksmith or similar providers are worth trying.

Appendix

Just as I was about to post this article I had received an email from GitHub:

Coming soon: Simpler pricing and a better experience for GitHub Actions - GitHub Changelog

With this change, GitHub is introducing a $0.002 per-minute platform fee for all GitHub Actions usage, regardless of where jobs run. Going forward, CI costs will have two components:

• Compute costs (paid to whoever runs your runners, e.g. Blacksmith)
• A GitHub platform fee, charged per minute of Actions usage

If cost is the primary reason you are evaluating third party runner providers it may make sense to make a comparison. In our case, I expect the third party runner to still be cheaper overall.

Most engineers know the familiar rhythm of a PR review: glance at the diff, hunt for logic mistakes, debate naming, rinse, repeat. It’s essential work, but it’s also incredibly easy to miss the small but critical bugs — off-by-one errors, edge case logic, subtle null handling problems — especially when PRs are large or rushed.

For teams like ours running a tight CI/CD pipeline (we use GitHub Actions), efficiency is everything. Every minute spent waiting for a human to spot a simple fix is a minute the code isn’t deployed and delivering value.

As we are already Cursor we naturally started using Bugbot from Cursor more and more as a first-pass reviewer on our pull requests: initially more out of curiosity as we had tried CodeRabbit in the past which we did not like. Bugbot is not replacing human reviewers, but it changes when and where we catch issues.

At a high level, Bugbot:

• Runs automatically on new PRs and on updates, analyzing just the diff with context about intent and code relationships. It can also be triggered manually with commands like @cursor review or bugbot run.
• Comments directly on GitHub where it finds potential problems, complete with suggested fix ideas.
• Supports custom rules via .cursor/BUGBOT.md so you can encode team-specific guardrails or conventions.

Benefits of using Bugbot in our development process

Bugbot sits right at the start of that process, essentially becoming the fastest, least-tiring ‘first reviewer.’

• Before CI: Bugbot scans the code on the PR.
• During CI: Our existing tests (like those run with Angular Testing Library and Testcontainers) catch functional regressions.
• After CI: Human reviewers focus on architectural decisions and complex logic.

We’ve noticed a few concrete benefits from incorporating Bugbot into our flow:

• Fewer “oh my bad” bugs late in review. When Bugbot flags a logic issue early, the human reviewer can focus on architecture and design trade-offs, not basic correctness.
• Better alignment on standards. Having auto-comments up front nudges authors toward patterns we care about before the first human comment lands.
• Faster iteration. If a suggestion can be fixed quickly (even automated via Cursor links), the turnaround on a clean, merge-ready PR improves.

And if something specific keeps cropping up in your project (think domain-specific invariants or architectural patterns), we can add it as a Bugbot rule and let the bot enforce it consistently. That means fewer repetitive comments from reviewers and more time spent on what actually matters. A recent example: leave a comment on the PR to remind the engineer to bump the manifest version of our browser extension if the change should trigger a browser new extension release.

As with any AI assistant, there are edge cases. Bugbot doesn’t always catch every problem, and it may not understand deep business logic the way a domain expert reviewer does. It does not eliminate the need for a code review performed by an engineer. But using it as an early filter — catching obvious bugs and surfacing fix proposals — has already saved us plenty of time.

Conclusion

If your team is serious about minimizing noise and catching bugs earlier in the cycle, giving Bugbot rules a real place in your development workflow is worth exploring. Let me know about your experiences.

Deployments succeed. The CI/CD pipeline greets you with a green checkmark. You celebrate. Then … a teammate reports they still see old behavior. “But the deployment succeeded!” you might think.

In this post, I want to share a quick reality check on distributed systems. Just because a deployment succeeded doesn’t mean it’s instantly available to all users. Depending on what you are deploying, the “time-to-live” can vary from milliseconds to literal days.

What Actually Happens

Here is a short overview of how this plays out in our stack (and this applies to lots of web-centric ecosystems as well):

Backend: Once the service is live, API responses update right away. As soon as the new containers are healthy, traffic hits the new code.

Web App: With the next page refresh, users see the update. Users who are currently active might still be running the old JavaScript bundle until they reload (or see a “New version available” gray toaster message).

Office Add-In: Same mechanism as web apps if you change anything but the manifest, but with a twist. Users don’t “refresh” Outlook or Excel add-ins as often as browser tabs. They might keep the side panel open for days, running stale code.

Extensions: Things get really interesting when we talk about browser extensions. We don’t control the delivery mechanism here — the browser stores do.

• Chrome: It usually takes 1–2 hours until it’s live in the store. After that, it can take up to a day for the Chrome browser to actually update the extension in the background.
• Edge: In many cases, the review process may take up to 5 business days. Then, add another day for the background update to propagate to clients.

What This Means for You

This latency creates a dangerous synchronization gap. If you ship a breaking API change thinking all your clients are updated, you’re potentially breaking the app for users somewhere between hours and a few days.

Deployment is what happens on your servers (which you control). Release is what happens on the user’s device (which you don’t).

The trap is thinking that “deployment” and “release” are the same thing. They aren’t.

If your deploy includes non-backwards-compatible changes, you need to assume:

• Some users will still be on the old client
• Some will be on the new one
• And some will flip over hours or days later

Best Practices

Because of the lag in extensions and add-ins, your backend code effectively lives in the future while your users may still live in the past. To keep things running smooth, your API changes must be strictly backwards compatible for at least as long as your slowest delivery channel takes to update.

• Keep the backend compatible with old clients until you’re confident the majority of clients have updated.
• Feature flags help you toggle behavior safely across disparate client versions.
• Communicate expected propagation timelines to QA, support, and your teammates.
• Watch real usage, not just CI success.

Conclusion

A green CI/CD badge means your code made it out the door — not that everyone is instantly using it. In our ecosystem of web apps, add-ins, and extensions, real-world rollout is staggered and unpredictable:

• Web backends are available immediately
• Web apps and add-ins update on refresh
• Browser extensions take hours to days to land in users’ hands

So, until the majority of clients are on the newest version, your backend and APIs still need to behave in a backwards-compatible way. Plan releases with this in mind — feature flags, compatibility guards, and clear communication between teams will save you time, confusion, and late-night fire drills.

In short: deploy ≠ delivered. Build as if some users will always be “stuck” on the version before the latest — because, for a while, they often are. Understanding rollout windows saves you from weird bugs and awkward chat threads at 2am.

How are your experiences?

Thrilled to announce that Sunhat has raised €9.2M in Series A funding with the support of our newest partner, CommerzVentures! 🚀

Since our last fundraising in 2024, a lot has happened but just to name a few highlights:

• 🤖 Built Proof AI which is already used daily by customers in Europe, North America and the Middle East
• 🤝🏻 Grew the team of Sunnies by 2x
• 🇩🇪 Received Research Allowance on behalf of the German Federal Ministry of Education and Research
• 🔒 Achieved ISO 27001 certification

What’s next?

The funding will help us take Proof AI to even greater heights:

• Expanding coverage beyond ESG to 100+ global standards and certifications
• Connecting with even more enterprise systems and integration partners
• Getting smarter with every questionnaire, audit, and assessment

Reflecting on our journey so far, it is incredible to see what we have achieved so far. As the first person who has written code for Sunhat, it makes me proud to see how much the product is growing thanks to the stellar work of all Sunnies. In the last 18 months, I have been fortunate to be able to both grow myself in multiple areas (AI, security, management) and help others on their career as well.

A huge shoutout to my co-founders Lukas and Alex, the entire Sunhat crew and our investors for embarking on this awesome journey with us — the future continues to be exciting! Can’t wait to see what our team builds next 😎

Read more in our press release 🔽

Sunhat raises €9.2 Million Series A to solve the "Proof Gap"

Thanks for your attention and take care! Until next time 👋

There are lots of situations where user-defined text is displayed in web applications. If you only support one language, mobile-only and limit the amount of text to a minimum, it may be trivial to ensure a good layout. But the reality is often different: German text tend to be longer than English text, laptops have more space for displaying content and users can write entire poems in your software.

Using an ellipsis … is a commonly understood way to signal that there is more text than is being shown right now. To prevent an HTML element from overflowing and showing an ellipsis, one may write code like this:

.withEllipsis {
  overflow: hidden;
  white-space: nowrap;
  text-overflow: ellipsis;
}

This can work in many cases and we could end this post right here. But there are more advanced cases where this will not be enough:

• If you need to apply an ellipsis if text exceeds a specific amount of lines (e.g. after 3 lines)
• If you need to apply custom logic if the text is being shortened (e.g. applying a tooltip)

Maybe you are considering to use custom logic like “if text is longer than 80 characters then apply ellipsis and shorten the text” but this approach can also have quirks. Luckily, it does not have to be that complex.

Introducing line-clamp

-webkit-line-clamp is a CSS property that will contain text to a given amount of lines when used in combination with display: -webkit-box or display: -webkit-inline-box. It will end with ellipsis when text-overflow: ellipsis is included. Browser support for -webkit-line-clamp is pretty good nowadays, covering all common modern browsers at this point.

To make the code reusable I created a SCSS mixin but we can use vanilla CSS instead as well.

@mixin limitLines($numberOfLines) {
  -webkit-line-clamp: $numberOfLines;
  overflow: hidden;
  display: -webkit-inline-box;
  -webkit-box-orient: vertical;
  text-overflow: ellipsis;
}

This is already neat but we can go even further: what if we want to execute actions based on whether an ellipsis is shown? We can use a one-liner in JavaScript to determine whether we are seeing the ellipsis: which is the case if the text would be overflowing into more lines that we have specified using CSS. All we have to do is to compare scrollHeight (measurement of the height of an element’s content, including content not visible on the screen due to overflow) and clientHeight (inner height of an element in pixels, including padding but excluding borders, margins, and horizontal scrollbars).

function isShowingOverflowEllipsis(htmlElement: HTMLElement): boolean {
  return htmlElement.scrollHeight > htmlElement.clientHeight;
}

In our scenario, scrollHeight will always be equal or bigger than clientHeight. Note: Depending on your use case, you can swap the order of arguments or compare scrollWidth and clientWidth instead.

Example

Let’s have a look at a real world example: I will be using Angular but the approach works with any other framework as well. Imagine we have an element which contains a user-defined message. This message could be up to 1000 characters long. To not give it too much space on a crowded page, we want to limit the message to a defined amount of lines. But users should still be able to see the full message if they want to do so by hovering the text.

In the screenshot above, we have applied a limit of 2 lines: if our text exceeds this, an ellipsis is shown automatically. Since the ellipsis is shown we also apply the tooltip.

In this example, we have changed the maximum amount of lines to be 3. Since our text does not exceed 3 lines, it is displayed fully and with no ellipsis. Furthermore, no tooltip is applied as well because it would be unnecessary in this case: we can already see the full text.

Conclusion

Thanks for reading this short post. As you can see, a little bit of CSS and JS allows us to display multiline text and shorten it while having the option to react depending on this. This approach has worked well in our product. Let me know about your approaches. Till next time!

How To Limit Lines + Show Tooltip If Text Is Too Long With CSS & JavaScript was originally published in JavaScript in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

We are usually thinking about the future but it can be a good exercise to review decisions made in the past and check how well they held up. Inspired by this post, I want to use this post to review some product and technology choices which I pushed forward.

No matter how much we try to look at things objectively: choices are always biased to a certain degree. And it is not about bashing tools or vendors but about critically reviewing things that worked out for us and those that did not. That being said, let’s dive in!

The legend is as follows:

• ✅ Recommend, I would likely do this again
• ⚠️ Works to a degree but with drawbacks and would consider alternatives
• 🛑 Would likely not attempt to do this again

✅ Linear

Can Jira make sense in your organization? Sure. Is it overloaded and are there better alternatives? Definitely! Linear is not only great at what it does (helping us to plan and manage software projects effectively) but there is a lot to learn in how they do things (keyboard support, performance, UX design). Linear is worth the price point and we are very happy using it.

(✅) Netlify

Netlify is a great choice for hosting web projects. The Netlifolks created a simple yet solid platform to host any kind of web app. The developer experience is neat, especially when it comes to serverless.

The only downside for us is that this comes at a cost: Netlify is not as configurable or extensible if you need more power. And if you’re not 100% serverless then you will still need to use another cloud platform like AWS.

✅ Cloudflare

Cloudflare does almost anything Netlify did for us yet it offers much more. I find the developer experience slightly worse than Netlify and I feel that configuration and the CLI could harmonize better. But at a similar price Cloudflare offers a lot of helpful goodies, especially around security such as a WAF (web application firewall) and AI (e.g. AI Workers). Overall, Cloudflare has been pretty reliable for us since setting things up.

(✅) Render

Do you like AWS but you want to reduce maintenance and setup costs? Then Render might be a good choice for you. Similar to Netlify, it appeals strongly to startups and fast growing companies. With Render it’s simple to deploy and run a service: either by using the straightforward UI or by using infrastructure-as-code (which is what we do).

The main downside is that other tools may not provide a simple solution to connect with Render (AWS, GCP and Azure usually fare well in this regard). Of course Render does not offer all possible customization options that AWS would offer but the team is constantly shipping useful features that work. FWIW: Render is built on top of AWS.

⚠️ Serverless Functions

Personally, I am torn when it comes to serverless functions. As a user I like to have serverless as an option to only pay for what I consume. As a developer I like it when building a frontend that needs a backend part: serverless is handy for prototyping. But when it comes to developing and running those serverless functions in production on our own (e.g. with Cloudflare) I still prefer a “proper” backend service. While it may not always make sense for my own code I do like the serverless model in some products we use ourselves.

✅ Angular

Angular has evolved steadily over the last years. I feel it started to pick up significant pace since Angular 14 with the introduction of standalone components. Signals are another thing that make building reactive UIs easier as well. Of course, React’s ecosystem is still bigger but I rarely find this to be an issue in practice except rare cases. Angular is a framework and I like this fact.

✅ Nest.js

Overall, we are quite happy with Nest.js. If you like Angular you will Nest as well. Express.js is fine but I like the project structure and the testability that Nest brings out of the box. Similar to Angular, Nest is a framework and I like this fact.

✅ Prettier

It’s 2024, I do not want to deal with manually formatting code or even comment on PRs that things should be formatted in a certain way. Prettier takes care of this.

✅ Using a dedicated Log Management tool

We are using BetterStack Telemetry and it works pretty well for us. Log based alerts are a simple yet powerful way to deliver notifications over multiple channels to notify the team in case of issues. We have also created a bunch of presets for common scenarios such as to find endpoints with slow response times.

Their friendly and helpful support has been pretty stellar and deserves a special mention.

✅ GitOps

Git all the way. CI/CD or bust. Which brings me to…

✅ GitHub Actions & Workflows

Since GitHub introduced GitHub Actions, GitHub finally won me over GitLab. Similar to npm packages, there is probably an action for whatever you want to do. And if there is not then it is often not that hard to create a custom workflow.

As someone who has created a bunch of workflows: while act helps with local development and debugging workflows I wish GitHub would release more official tooling to simplify development.

⚠️ Jest

When Jest works it is great. There is a big ecosystem, the CLI is awesome and it works decently well with common frameworks. For me it was a big step up compared to Jasmine which I was used to before.

But if it does not then it can be quite annoying to deal with. I am not referring to missing web features unsupported by jsdom, I am talking about issues around TypeScript support and module imports causing test failures. While we are not actively looking to replace Jest at the moment I am keeping my eyes open for other test runners (e.g. vitest).

✅ Testing Library

Testing Library is a lightweight solution to write UI component tests that rely on minimal implementation details and focus on user behavior instead. In our case, it is Angular Testing Library to be precise. In many cases writing tests with Testing Library has helped us uncovering usability issues like poor accessibility (e.g. a button with no text). There had been a few breaking changes when upgrading to the next major version but our overall experience has been pretty good.

✅ Testcontainers

You should write integration tests. And we find Testcontainers to be a helpful to do so. Spinning up containers (e.g. a Postgres database) to test endpoints end-to-end becomes easy with Testcontainers.

(✅) Nx

Nx is a helpful tool to help us divide and manage our different product parts in a consistent way. The caching of task outputs is pretty nice as it can speed up local and especially CI workflow executions, saving CI minutes. That being said, updating Nx to the latest version has not always been trivial for us in the past and Nx can feel intimidating at first. Overall, it is still a strong net positive for us.

✅ Just use Postgres

Just use Postgres until you have a very good reason to use a database for special databases, e.g. a vector database. Postgres is open source and there is a large ecosystem around it.

⚠️ MongoDB

I like MongoDB in the early phases when all I need would be a database that takes anything and gives it back to me. MongoDB Atlas is a pretty compelling offering that I liked using in the past.

Nowadays, I rarely find a case where I would prefer MongoDB or other NoSQL databases over Postgres: SQL does have some benefits after all and jsonb can be used if we want to store arbitrary data as JSON. If you are not staying up-to-date with MongoDB you will have a bad time: a good friend of mine can tell you all about it.

✅ Prisma

Prisma is a fine ORM that plays well with TypeScript. We are generally quite happy with it. A considerable downside (and I guess this applies to other ORMs): by making it so easy to create sophisticated queries it naturally becomes easy to create pretty expensive SQL queries with Prisma.

✅ Sentry

Setting up Sentry is dead simple when getting started. The most important thing for us is the error monitoring and this is what we primarily use Sentry for. I am looking forward to seeing further improvements in performance monitoring.

⚠️ Cloudinary

Cloudinary is a solid product but it is not the best solution in all cases. If you are looking for a service handling all kinds of files (images, PDF, Excel, ZIP, …) you are better off looking at Amazon S3 or similar alternatives such as DigitalOcean Spaces or Cloudflare R2. If all you store are images and videos then Cloudinary is still a good tool with a nice admin dashboard.

✅ DigitalOcean Spaces

DigitalOcean Spaces is a simple to use solution for object storage. Their pricing is pretty fair and predictable. A huge advantage: its API is mostly compatible to Amazon S3 which means it is often compatible to tools that are compatible with S3.

🛑 Clarity

It’s free and easy to setup so I shouldn’t complain about Clarity. The video quality was shaky and inconsistent. Hence we dropped it. Maybe it works better on static websites.

⚠️ Snyk

Snyk is a solid product for analyzing code and dependencies. It hooks in nicely as a CI check in PRs and it can be invoked with their CLI as well. While I do not always agree with the way they rate vulnerabilities I do not find this to be a big issue in practice.

The thing that currently bothers me the most is a feature that is actually pretty neat: the creation of fix PRs that upgrade dependencies to a newer patched version. Unfortunately, despite my best efforts Snyk still occasionally creates PRs for dependencies that I explicitly excluded to be ignored (e.g. it should not create PRs for TypeScript as we’d typically upgrade TypeScript when upgrading Angular as well).

✅ Sendgrid

Sendgrid is a solid choice for sending emails. Note that even if you are not sending too many emails yet I would recommend to get a static IP address: without a static IP address your emails will more likely be blocked by corporate email filters.

✅ Transifex

Sooner or later, your will probably need to support more than one language. I toyed around with other translation management tools but I eventually settled with Transifex. Collaboration works well and the GitHub integration is pretty neat: if it could only stop formatting files which creates larger PRs than necessary then it would be perfect.

✅ SnapShooter

When we think about backups most people probably think about backing up their relational database. But what about files uploaded by users — those are usually managed in a tool like S3. It took me a bit to set up a backup job in SnapShooter (and one major f*ck up when I accidentally deleted all files— luckily, I had previously downloaded all files locally hence I could restore before customers noticed anything; this is a tale for another time) but the daily backup job is now working reliably and I feel more at ease.

✅ Metro Retro

If you are doing retrospectives (and you should do it from time to time) then I can recommend Metro Retro. Not only do I like the name, it also provides the essentials for conducting a retro including nice templates and the ability to throw confetti. Figjam or Miro are also decent alternatives.

These tools help but in the end, it is a team effort to conduct retros that help the team.

✅ Font Awesome Pro

The free version of Font Awesome is already pretty nice and the pro version builds up on the strong foundation, providing an icon for almost every case you will ever need.

One thing that slightly bothers me as a user is the private registry bandwidth: we are usually exceeding it since we have multiple GitHub workflows that call npm ci and we push/deploy a lot. One way to solve would be to store the Font Awesome files in the repository instead of installing them through npm: hence I will not hold it against them.

✅ Linters

Stylelint and ESLint are two helpful tools to get actionable feedback in the IDE and on CI. I am a big believer of automating the things that can be automated: everything which can be enforced automatically and which removes guess work or need for manual documentation should probably be automated.

Some Stylelint rules which we found to be helpful are around enforcing consistency (e.g. keep variable names at the top of stylesheets) and common issues (e.g. prevent using certain selectors). When it comes to ESLint I find framework specific rules (e.g. angular-eslint, eslint-plugin-nestjs-typed) to be particularly useful, especially for engineers who may not be familiar with certain frameworks yet.

✅ GitGuardian

Secrets should be, well, secret. And they should also not be hardcoded. GitGuardian provides capabilities to fix hardcoded secrets in Git repositories. It hooks in nicely as a CI check in PRs and I get alerted in case it finds secrets in our source code.

⚠️ Pendo

Pendo is a good product analytics tool and it is not too difficult to get started with it. However, it is fairly expensive and I intend to review other alternatives that may cover areas as well such as feature flagging. I have heard good things about Posthog.

(✅) Leveling up your compliance and security efforts early

Does a startup in year 1/2/3 need to be compliant to frameworks like ISO 27001? Not necessarily but you probably know how things tend to go: the earlier you set up the right foundations, the less effort you need to make in the future when your organization has grown slower and less nimble.

We are using Drata which automates compliance and best practices around security in our company. It also helps us maintain our ISMS (information security management system). There are some tools that are similarly capable like Vanta and Secureframe but I am happy with Drata. The integrated guidance helped me quite a lot not only in setting up processes and policies but understanding why things are the way they should be.

🛑 Not introducing a MDM earlier

MDM (mobile device management) helps us manage and secure our devices. One useful feature is the ability to install software (e.g. VS Code) directly through the MDM, reducing the onboarding efforts for new colleagues. If you wanna pursue security certifications such as ISO 27001 or SOC 2, a MDM can help with getting your organization ready.

Depending on the OS there are a couple of good tools that cost fairly similarly (e.g. Jamf, Swif, Jumpcloud, Kandji). We are using Swif which works well for us.

Conclusion

Thanks for reading this post! It was interesting to look back and see how some things turned out better than expected and how there are still some things on my todo list. Let me know in the comments about your experiences.

The textarea element is a useful native HTML element for allowing users to write multiline text. Unlike a regular input element, textarea can contain line breaks.

A common use case is to render the content of a textarea as plain text. Frameworks such as Angular, React and Vue.js make it easy to render text based on a property. E.g. with Angular you can do something like this:

<textarea *ngIf="!readonly" [(ngModel)]="description"></textarea>
<div *ngIf="readonly">{{ description }}</div>

A potentially surprising issue is that line breaks may not be rendered as expected. See the example below:

As you can tell, line breaks are ignored and text is rendered as one big block even though the textarea itself looks fine. Line breaks in textarea elements are typically stored as\n. And frameworks like Angular sanitize content rendered via data binding which is a good thing for various reasons like security.

Let’s investigate this issue and see how we can solve this with ease.

CSS to the rescue

A native approach could be to insert HTML. It is simple to use the innerHTML property or one of the DOM APIs to insert the text programmatically. However, we should avoid inserting raw HTML if possible as that can introduce the possibility of injection and it feels like shooting birds with cannons.

Luckily, there’s a simple CSS property called white-space we can use to solve our little issue. This property can take a couple of different values but I found pre-line to be what I’d typically need.

/* preserve line breaks for text originating from a textarea */
.preserveTextareaLineBreaks {
  white-space: pre-line;
}

Now let’s have another look at our simple example after applying our white-space change:

As you can tell, we can now see line breaks in the rendered text thanks to our little CSS change. If this is something we need more than a few times it may make sense to create a global CSS class that can be referenced across our application.

Conclusion

Thanks for reading this short post! Simple problem, simple solution — is that not what we want? Let me know in the comments about alternative approaches you have taken.

How to Preserve Line Breaks of Textarea Values with CSS was originally published in CodeX on Medium, where people are continuing the conversation by highlighting and responding to this story.