Forem: Omer Rosenbaum

Creating up-to-date diagrams with Mermaid.js

Omer Rosenbaum — Mon, 06 Mar 2023 10:16:28 +0000

Humans are visual beings, so when we learn something new - whether simple or complex - it usually helps when we can visualize whatever we want to know.

On that note, our team at Swimm is happy to announce our integration with Mermaid!

Swimm’s integration with Mermaid provides software-related use cases to get the most out of this amazing combination.

What is Mermaid?

Mermaid is an open source diagramming and charting tool that lets you create flowcharts and diagrams with Markdown-inspired syntax. It is a wonderful way to visually explain flows, dependencies, and other aspects of your codebase. Mermaid won the JS Open Source Awards (2019) for "the most exciting use of technology." 🥇

Understanding a codebase or parts of it can be overwhelming and complex, and visualizations can significantly help with that. With Swimm’s Mermaid integration, you can create diagrams and charts that automatically remain up to date as code changes.

Mermaid + Swimm = up to date Diagrams 🤯

You can now create and edit Mermaid diagrams straight from Swimm’s editor. We even included sample diagrams to get you started:

We’ve taken this beautiful tool and extended its functionality with Swimm’s Smart Tokens. Type a backtick ` within your diagram labels to code-couple constants or variables. You won't need to worry about the impact of refactoring on your documentation and renaming those values referenced in your diagram. This means that diagrams in your documentation stay up to date with your code 🤯

The many benefits of diagrams in your docs

The impact of diagrams in your documentation are many. Here’s a closer look at the benefits.

Architecture overview

When approaching a large codebase, there is so much to learn, and it is quite easy to get overwhelmed. A good architectural diagram explains the different logical modules of a codebase and the main interactions between them.

You can use smart paths as well as definitions from the entry points of each module.

Here is an example from Sentry’s documentation:

A flow in the code

Logical code paths are hard to follow when they involve various areas of the code that interact with one another in a way that is not necessarily obvious. Imagine a straightforward web app where to fully understand the flow. You would need to go back and forth between various parts of the frontend and backend.

Here is another example, with a sequence graph showing Git commands:

Events pipeline

Pipelines of events are so ubiquitous they deserve a section of their own. When an event gets transmitted between different parts of the system, visualization can help explain the flow.

For example, consider the following diagram that explains the path of an Event through Sentry's Relay Server Application:

Multi-repo dependencies

The case described above regarding a flow in the code becomes even more complicated if the code is spanned across multiple repositories. For example, a system where the frontend code is in one repository and the backend is in another. The problem worsens as the number of repositories involved in the flow increases. Understanding the flow becomes straightforward when a document contains code parts from all relevant repositories.

Therefore, a diagram that describes code flow spanning multiple repositories is essential.

At a basic level, we can describe the flow of operations between the different repositories, and the document can connect each step of the process like this:

Another option is to have a more detailed representation relating to specific entities within different repositories, such as the following Swimm diagram:

We can see communication taking place between 4 different repositories.

A class diagram

Describing classes, and especially how they interact with one another, is a common use case for diagrams.

For instance, the following diagram is taken from the wiki of Taproot:

This diagram explains the usage of the comprised command, a “layer built on top of the Command class. The key idea is that a comprised command is an encapsulation of multiple commands.”

A process

Sometimes, a process requires a few steps that may or may not be directly linked to a part of the code, or something may happen on a remote service you cannot access. Especially in these cases, it may be difficult to understand the entire process by just looking at the code.

Consider this example of system flow between K8s components to start a container (from Kubernetes' documentation).

Here is another example (from k8s documentation, “What is Ingress”):

User journey

When creating products that interact with users, it’s crucial to understand how the flow of the code supports the user journey. What is the happy flow, and what are the other flows? Do you really cover all cases?

Using Swimm’s Mermaid charts, we can create user journey charts that couple the user journey and UX with the implementation, ensuring they are aligned and the link between them is clear.

Bottom line

With Swimm’s Mermaid integration, you can create diagrams that automatically stay up to date as the code evolves. This opens up the possibility for new use cases incorporating the powerful tool of visualization, and the impact for our dev teams around the globe has been tremendous.If you’d like to see Swimm’s Mermaid integration up close, sign up for a 1:1 demo.

10 reasons devs can be thankful this Thanksgiving 🦃

Omer Rosenbaum — Sun, 20 Nov 2022 08:49:43 +0000

Channeling my inner David Letterman here...

10: Dall-E for making all memes and gifs on Slack so much better.

9: Large external monitors. You don’t have to ask.

8: Name tags! 2022 in-person dev conferences were the best.

7: NASDAQ for adding spice to our lives and roadmap.

6: Your favorite dev tools for making you look so good at work.

5: The new developer you onboarded didn’t ask you “how to” questions once an hour, and used a Documentation Playlist instead.

4: All of the caffeine consumed this year.

3: Your go-to code reviewer who nails the funniest yet helpful comments.

2: Open source.

1: You can find your documentation, and it’s actually up to date.

Git Internals: Rewriting History and Overcoming Gitsasters

Omer Rosenbaum — Tue, 11 Oct 2022 17:23:52 +0000

Brief, or what I do for fun

When I'm not wearing my CTO hat at Swimm (we're building a documentation platform for devs), I create videos for my YouTube channel, Brief. Brief is my way of sharing knowledge and creating tutorials about Programming, Git, Computer Networks, Computer Science and more.

About the tutorial

Understanding the concepts of git can help us in many cases. Sometimes, it can help us when things go wrong - for example when we did something we did not want to do, and we would like to go back in time. We will call these cases - gitsasters, that is, disasters when working with git.

This video, as well as the next one, will provide you with some superpowers. After these two videos, you will feel confident when things go wrong in git. When someone commits to the wrong branch, they will call you, and you will be able to help out. When a team member loses important changes they have made, you will be the person to consult with.

In these two videos we will deepen our understanding of git while acquiring new tools, especially for rewriting history. We will also apply these tools to real-life scenarios.

I also wrote an article on this topic.

Let me know if you found this tutorial useful! And if you have an idea for a future tutorial, I'm all ears.

Need for speed: Migrating from Webpack 4 to Vite

Omer Rosenbaum — Mon, 03 Oct 2022 17:42:04 +0000

We migrated our web app’s codebase from Webpack 4 to Vite for one simple reason: speed 🏃🏃🏃.

Since Vite is relatively new, we can share that it’s stable and has made a tremendous difference in our lives as developers. Plus, the move was straightforward and didn’t take long—though our team here at Swimm learned some hard lessons along the way.

Here’s a bit more about why we made the switch in the first place.

What is Vite?

Vite is a Javascript build tool designed for speed. Vite consists of two major parts: a dev server that uses native ES modules that makes Hot Module Replacement incredibly faster, and a build command that uses Rollup behind the scenes.

Why we decided to migrate from Webpack

We used Webpack 4 at Swimm for over two years as it’s used in Vue CLI, which is the service we use for our app’s client-side. But about six months ago, we decided we needed to change when Webpack slowed us down as our codebase expanded and became more complex.

Though Webpack 5 has been available for a couple of years, migrating Vue CLI from v4 to v5 introduced several breaking changes that made the migration quite challenging.

Webpack’s performance was a deal breaker
Webpack’s Hot Module Replacement (HMR) works well until you have too many files in your codebase. As our web app became larger and larger and we had many files in the codebase, it made HMR so slow it would sometimes break.

Launching Webpack for local development took upwards of two minutes at best.
HMR in Webpack took about 10 seconds.

Moving from Webpack to Vite: the challenges

The entire move to Vite took just a couple of days. Most of the work was done in one day by four devs, with some pre-work done in the days prior.

While we were able to migrate quickly, we had to overcome some technical difficulties right off the bat.

Project separation
First off, our codebase needed some restructuring.

Swimm has several projects in addition to the web app including IDE plugins and Swimm’s GitHub app, and Webpack’s configuration was relevant for most of them. Because Vite is intended for web projects, we had to extract the shared code between the projects so that the web app would be isolated and independent.

Environment variables and configuration files
Second, we had to clean up our environment variables and config files including tokens, URLs, and .env files. In particular, our TypeScript and eslint configuration had to be readjusted.

Also, environments in Vite are handled very differently than in Webpack. Specifically, Vite has its own set of defaults and a new namespace. We imagine that other dev teams, like us, will need to go through extensive migration and configuration change work to work within Vite’s environmental expectations.

Using Swimm to Migrate to Vite

There were many code changes during the process of migrating from Webpack to Vite. No surprises there.

And since all of our code is documented in Swimm, this meant that we were able to ensure that our docs stayed up to date, current, and relevant. And, of course, we had a place to put all of the items we didn’t want to forget about the migration.

So, in addition to the Swimm documentation connected to the code changes, we also now have a “How We Use Vite doc” for our team at Swimm to read and use as we continue to ease into the migration.

Moving to Vite: the easy wins

Once the challenges for the migration were behind us, we saw the Vite wins immediately.

Speed
No matter how big the project size is in development mode, it doesn't impact Vite’s speed.

Vite launches in less than one second (~700 milliseconds).
HMR in Vite takes less than one second.

Native integrations and efficiency
Vite was written by the same developers as Vue, so we gained from a lot of the native integrations and synergies between the two. Vite also uses esbuild and doesn’t require bundling in pre-production environments, which makes local development so fast. It’s orders of magnitude faster than using Webpack. Also, Vite only supports modern browsers, so there’s no additional code to support legacy browsers many dev teams aren’t using.

But you don’t have to use Vue with Vite. Vite is completely separate so you can use it with React, Angular, and others however they best fit your project needs. Vite also has a lot of official plugins and many more community plugins.

Other technical details

A few other points to keep in mind if you’re considering migrating from Webpack to Vite:

Shims and Polyfills. Unlike Webpack 4 and earlier versions, you don’t get any automatic shims or polyfills for Node.JS modules with Vite. So, support for older mixed Node.JS/Browser modules can be a bit difficult. You can’t easily import anything and just expect it to work. And if you have some legacy Node.JS module that’s mission-critical, it will present challenges you’ll need to consider.
Bundling. When it comes to bundling, Vite is a general solution that does things a little differently. It’s not just a file watcher, web server, and bundler; it does on-demand compilation. As a browser requests updated JS files, Vite delivers them live and just in time. It’s super fast because of esbuild. There’s no need for complicated bundler solutions, and it only replaces the changed file via HMR.
Project configuration.Project configuration is also something to watch out for. We had all sorts of issues with templates and had to go deep into the documentation. We recommend you stick to configuration defaults and templates if you can and only change the configuration if you know what you’re doing.

Bottom Line

Migrating from Webpack to Vite was well worth it, and we are very happy with the results. The migration from Webpack to Vite may present some challenges if your code repository has shared resources and dependencies across projects. But if your code is well isolated and independent, you’ll hopefully have an easy time with it.

We think the migration to Vite is well worth the investment if Webpack has slowed you down.

Software Development Knowledge Sharing Methods Are Broken: Here’s Why

Omer Rosenbaum — Wed, 24 Aug 2022 11:38:36 +0000

Traditionally, developers gain knowledge gradually when working on projects over time. I’m not referring to general knowledge such as a programming language. Instead, I am referring to project-specific knowledge, including the many decisions made while planning a project. This includes product decisions (what to implement, what not to implement, and why) and design decisions (what architecture to use, how to split the system into its components, and how the components interact).

There is, of course, more specific knowledge that accumulates either when developing code or reading it to understand something - for example, during debugging. Knowledge about how the code is constructed, what parts are essential, and how the data flows in the system is gradually accumulated.

Gradually is key here because in the mind of the developers as they develop their system, this knowledge is an inseparable part of the craft of programming.

Not surprisingly, this knowledge is hard to transfer. For example, when new developers join the team, they need to quickly learn all kinds of things from the design decisions through the specific implementation details; when a bug occurs, we need to find the cause and make a fix; when performing a code review or basically whenever we interact with code we haven’t written ourselves, we need to get into the mind of the developer who originally has originally written the code.

Our existing methods for sharing knowledge about software are fundamentally broken, and we need to prioritize sharing this knowledge efficiently and effectively. In this post, I will explain why and what can be done about it.

Why knowledge sharing methods are broken

Knowledge sharing methods are broken for two fundamental reasons: knowledge is scattered, and documentation is outdated.

Knowledge is scattered

Where is that “knowledge” we want to transfer stored? Well, in the mind of the developers, of course. But then, when it is transferred, it is also stored somewhere. Some knowledge is found within the code itself, and some isn’t. Design decisions, for example, are hard to deduce from the code. Furthermore, in the code itself, you can’t find the reasons that made the developers not implement things in a certain way.

Knowledge about code can be transferred in oral conversations and, in this instance, not stored at all. They can be conveyed on recorded video calls, documents stored on shared folders or Wiki pages, code comments, README files, Slack conversations, emails, and more.

This scattered knowledge makes it extremely hard to find; most of the time, you don’t even know where to look for it - assuming there is any relevant documentation to begin with.

Documentation is outdated

Even when the relevant knowledge is documented, it is often outdated. This is the result of the nature of software; it quickly evolves. As developers create new features and fix bugs, the code constantly changes, and they simply don’t remember to update the relevant documentation or bother looking for it.

Time is always of the essence and locating and updating the documentation takes precious time that could be devoted to writing more code.

Developers no longer trust documentation

It’s a vicious cycle: when developers stumble on a document, they often lose trust in the documentation. Because once you find outdated documentation more than a couple of times, you are likely to assume that it’s probable that other docs are outdated as well.

So why would you, as a developer, bother to read the documentation? And of course, if it’s not valuable to read the documentation, it’s understandable why developers would not justify or prioritize the effort of writing the docs in the first place.

As a result, developers spend less time creating high-quality documentation, leading to other developers reading the documentation and not getting value from it, which leads to a stronger belief that there is no value in writing documentation at all.

Sometimes, developers try to avoid the problem of outdated documentation in advance - by writing only high-level documents describing general flows and architecture, as these are not liable to change frequently. However, this leaves many gaps. A lot of the important knowledge that simply cannot be covered by high-level documents is never documented.

Knowledge should be found and consumed at the right time

Even if we assume that all knowledge relevant to a software project exists in some written form and is centralized in a single place, it is not practical to just read all the relevant documentation once you join a new project. When, for example, should you read each document, and do you know when it’s the right time?

Swimm’s knowledge management solution

With Swimm, information is located and consumed in two forms.

Developers get a high-level overview of the project they enter upon entrance using our Swimm Playlists.
Using Swimm’s IDE plugins, developers find the relevant information just in time, when they need it, when trying to understand a part of the code that has relevant documentation, or when writing code where existing documentation can facilitate.

Swimm analyzes the changes introduced to the code on every PR. When the changes are minor, we Auto-sync them, track the relevant code parts, and update the documentation accordingly. When breaking changes are introduced, we mark them for the developer to manually update the documentation as part of the PR - when the information is fresh - as the breaking change has just been introduced.

Knowledge sharing is transforming teams

Knowledge sharing is transforming for developer teams with the use of code-coupled documentation. Learn more about Swimm’s knowledge management documentation platform and try out Swimm for yourself.

How we built our GitHub app

Omer Rosenbaum — Sun, 14 Aug 2022 16:31:52 +0000

Swimm’s GitHub app helps developer teams create, maintain, and find documentation as part of the development workflow.

When our team at Swimm began designing Swimm’s GitHub app, we needed to identify the best moment to interact with users. We knew, for example, that running and notifying users on every open branch can be annoying, and we wanted to make the experience simple and enjoyable. Moreover, we understood that we had to find the window of opportunity for developers - the best time when software engineers were looking for checks, reviews, and comments.

Design of Swimm’s GitHub App

Our team at Swimm started designing the GitHub app integration in 2021, keeping in mind that most interactions happen during Pull Requests because it’s usually the last point the code can be verified before it is merged into the main branch and deployed. But it’s also the first time when software engineers push their code and mark it as ready for review.

The initial version of Swimm’s GitHub App ran our Swimm Verify check whenever a PR was opened or an open PR was updated. This allowed us to make sure the documentation on the branch would stay up to date so that code changes would not require an update to the documentation.

Continuously improving Swimm’s GitHub App

Since then, we have added quite a few capabilities and features. Today we’re covering Swimm’s GitHub app features one by one.

Accepting Auto-synced changes from GitHub

Swimm's patented Auto-sync algorithm analyzes what happens in your codebase. When Swimm Verify check recognizes Auto-sync documentation changes, users are notified via a comment on your pull request. You can then trigger a Swimm Commit by clicking the “Approve Auto-sync” button in the check, which accepts all Auto-synced docs from the GitHub App.

Automatic Auto-sync approval

We’ve taken the Auto-sync feature one step further. In the GitHub app settings, you can set up automatic Auto-sync approval. Swimm’s GitHub app will automatically accept Auto-sync changes, committing them to your open pull request in a dedicated commit. Clients rely on Swimm’s trusted patented Auto-sync algorithm to automatically update their documentation with this feature.

New doc notifications

Since tracking and locating documentation is challenging, we designed a feature for New Doc Notifications: you can set an alert on Slack or via email whenever a new document is created and merged to your main branch. This helps keep track of new documentation in your repo and allows you to invite other members of your organization to read and learn more about new documentation. We’ve found that this encourages a better overall understanding of the codebase.

Draft Documents from Pull Requests

We all know too well that documentation is usually an afterthought, or something completed after writing tests and making code review requested changes to your PR.

This is exactly why Swimm’s GitHub App analyzes your code changes, and when a Pull Request is interesting enough to document, we notify you with a comment and encourage you to create it. With a single click on the Review Draft in App button in our comment, you go into Swimm’s Web App. All the code changes from your Pull Request are added to a document, and all that’s left for you is explaining what the code does. There are no rules for how to do this, but ideally, you would want to arrange it in an order that tells a story.

Doc recommendations

When you change code that has relevant documentation, Swimm’s GitHub app recommends documentation for you to review. This helps users access documentation about specific code changes by alerting you to relevant documentation on PRs.

Here are a few examples you might see: a doc is recommended to you for your E2E testing guide whenever someone changes a covered test; the CI deployment documentation is recommended when someone changes a configuration script; a fragile piece of code changes, and you are alerted to documentation that references an Incident Report.

Swimm Verify on PR changes only

We created an option to run Swimm Verify only on files that are changed in the Pull Request.

Here’s why: because we know that sometimes things break on the main branch. Perhaps a merge conflict or two competing changes are going on simultaneously. And we know that this can happen with your documentation as well. While these changes might take some time to be fixed, they might otherwise fail our Swimm Verify check across your repository, even on unrelated Pull Requests. So we suggest that it is a worthwhile option to turn this feature on until issues with your main branch are resolved. This feature helps our clients avoid unnecessary delays.

Disabling comments

Our engineering teams work in a fast-paced environment; we move quickly, frequently break things, and always work on bug fixes.

Therefore, we designed Swimm’s GitHub app with an option to disable comments. This helps reduce the number of notifications that you’ll be sent during busy deadlines and crunch time. And then, of course, you always have the option to enable the comments again whenever you wish.

Integrations with other tools

Swimm partnered with Atlassian Compass - bringing Swimm to Compass’ ecosystem so that you can see your latest documentation status for all your distributed services from a single place. You can also use Swimm’s Compass Integration to link Swimm documentation to the Compass component.

Swimm is currently integrating additional tools to facilitate understanding the bigger picture of your software development status with your Swimm documentation included.

Doc hooks - coming soon

Getting recommendations for a relevant document to existing code is helpful. But what about newly added code? There should be a way to locate documentation in situations such as:

When a new database migration is added → link to your database migration policy
When the configuration file is modified → link to your environment variable update process walkthrough
When a new record is added to your Infrastructure as a code setting → link to your explainer on how to verify it will be deployed correctly.

Our team at Swimm is currently working on solutions to these exact problems. We are testing an alpha version of a feature that will recommend a specific document when a certain file is changed or something is added to a folder. Stay tuned!

What's one piece of advice every dev should ignore? 🚩🚩🚩

Omer Rosenbaum — Wed, 23 Feb 2022 13:42:43 +0000

We'll go first >

"Good code is self-documenting"

What would you add?

Why Markdown?

Omer Rosenbaum — Wed, 26 Jan 2022 16:50:28 +0000

Here's the rationale behind our decision to base our docs' format on Markdown.

Why Markdown?

COMPATIBILITY! For example, if you're using Notion and Confluence to document your code, you can easily import to Swimm
GitHub and the IDEs know how to parse & render Markdowns
Markdown has become a standard and ultimately makes documentation easier

Why we moved?

We used to store content as .swm files in JSON format. So yes, it was easier for computers to read, but it wasn't readable as text and it didn't render in editors
.swm was not user friendly
we struggled to review changes
JSON's curly bracket format made editing harder than it needed to be

First things first, here is what sw.md looks like in:
Github

VSCode

Learn more about docs as code here.

E2E testing: challenges & lessons learned

Omer Rosenbaum — Sun, 23 Jan 2022 11:42:53 +0000

End-to-end testing. The holy grail of all testing types.

Here's everything we learned regarding the ins and outs of end-to-end testing - lessons, takeaways, mistakes, you name it.

So, let's start out with why

Swimm started growing, we added new features, and we found that we simply couldn't keep up with changes.

We realized that our goal for a testing solution had two parts:

Find a solution that allowed us to catch regressions bugs DURING development
Save manual regression QA time

E2E testing seemed to be the right answer to our testing paradigm.

We ended up choosing Cypress

Pros

Awesome community
Great documentation
Great features: automatic waiting, automatic sreenshots & videos, time travel
Cypress is intuitive & easy to set up
Writing tests is fun
Using Cypress' API applies for user behavior

Cons

Lack of multi-tab support
Difficulty with iFrames
Limited browser support (just Chrome-based browsers & firefox)

Challenges of E2E testing

Wins:

Identified & fixed a lot of bugs
Saved so much time by not having to repeat manual flows weekly
Dramatically increased stability & coverage
Challenges
Human vs machine testing
We had zero experience with e2e tests
Monitoring tests that are less reliable
It takes more time than you think

Key takeaways

Appoint an owner for E2E testing
Patience, patience, patience
Write stable tests
Trust. Your. Tests.
Stable tests = stable product

Here's a detailed blog on how we implemented E2E testing.

A dev's dillema: Vue vs React

Omer Rosenbaum — Thu, 13 Jan 2022 16:47:02 +0000

Why Vue?

Vue is lightweight & flexible and it feels more like a library than a framework
It's also less intrusive and has an easy onboarding experience
Project components & structure in Vue are similar and easy to recognize. This especially helps with onboarding.
READABILITY !!!! The html/css and JS are separated.

When React > Vue

React is an industry standard and oftentimes this makes it easier to recruit developers
React often provides better flexibility in some aspects
Docs are far more advanced. Check out the 100s of pages of questions on React on Stackoverflow

This all started with an email we received a while back asking why Swimm chose Vue.

Do you have this dilemma? Where do you stand?

Is self-documenting code a myth?

Omer Rosenbaum — Tue, 11 Jan 2022 09:55:23 +0000

To answer our own question - yes. Do you agree?

If after a month you can barely make sense of the code you wrote, imagine how a junior dev joining your team would feel? Or even someone more senior going back to legacy code. Documentation becomes obsolete fast and eventually it renders itself useless.

Continuous Documentation
calls for creating and maintaining code documentation as a part of the normal development workflow.

The principles of Continuous Documentation require that documentation is:

Always up-to-date
Created at the right time
Tightly coupled with the code itself

So you created a bunch of documentation. Now what? How do you make sure it stays up-to-date?

This tech checks docs as code evolves, notifying you if your changes affect your documentation.

So, what do you think? Will the "self-documenting" excuse disappear once documentation is (much) easier to maintain and keep up-to-date?

10 devtools for 2022

Omer Rosenbaum — Thu, 06 Jan 2022 17:38:32 +0000

Roundup of devtools for a more productive 2022

We outline the suite of tools our R&D team uses.

What tools do you use? What did we miss?

Forem: Omer Rosenbaum

Creating up-to-date diagrams with Mermaid.js

What is Mermaid?

Mermaid + Swimm = up to date Diagrams 🤯

The many benefits of diagrams in your docs

Architecture overview

A﻿ flow in the code

E﻿vents pipeline

Multi-repo dependencies

A﻿ class diagram

A﻿ process

User journey

B﻿ottom line

10 reasons devs can be thankful this Thanksgiving 🦃

Git Internals: Rewriting History and Overcoming Gitsasters

Brief, or what I do for fun

About the tutorial

Need for speed: Migrating from Webpack 4 to Vite

What is Vite?

Why we decided to migrate from Webpack

Moving from Webpack to Vite: the challenges

Using Swimm to Migrate to Vite

Moving to Vite: the easy wins

Other technical details

Bottom Line

Software Development Knowledge Sharing Methods Are Broken: Here’s Why

Why knowledge sharing methods are broken

Knowledge is scattered

Documentation is outdated

Developers no longer trust documentation

Knowledge should be found and consumed at the right time

Swimm’s knowledge management solution

Knowledge sharing is transforming teams

How we built our GitHub app

Design of Swimm’s GitHub App

Continuously improving Swimm’s GitHub App

Accepting Auto-synced changes from GitHub

Automatic Auto-sync approval

New doc notifications

Draft Documents from Pull Requests

Doc recommendations

Swimm Verify on PR changes only

Disabling comments

Integrations with other tools

Doc hooks - coming soon

What's one piece of advice every dev should ignore? 🚩🚩🚩

Why Markdown?

E2E testing: challenges & lessons learned

So, let's start out with why

Pros

Cons

Challenges of E2E testing

Key takeaways

A dev's dillema: Vue vs React

Why Vue?

When React > Vue

Is self-documenting code a myth?

So, what do you think? Will the "self-documenting" excuse disappear once documentation is (much) easier to maintain and keep up-to-date?

10 devtools for 2022

Roundup of devtools for a more productive 2022

A flow in the code

Events pipeline

A class diagram

A process

Bottom line