DEV Community: sarabadu

Backstage logbook: Migrating the Catalog Plugin to the New Frontend System

sarabadu — Sun, 15 Mar 2026 23:14:56 +0000

Before we start: where are we?

This post assumes you've already done the initial hybrid-mode migration — switching createApp to the new version, wrapping legacy options and your root component with the compatibility helpers, and confirming the app still boots. If you haven't done that yet, follow the official migration guide first and come back. That part is fairly mechanical and the docs cover it well.

Once your app is running in hybrid mode, you have something like this: a FlatRoutes tree that still manually wires up all your routes (including the catalog ones), and a large EntityPage.tsx that manually composes tabs and cards for every entity kind. At this point, convertLegacyAppRoot is doing the heavy lifting of keeping things working while we incrementally replace them.

Step 1: Drop in the new Catalog plugin

The first real NFS(new frontend system) step is to import the catalog plugin from its alpha entrypoint and add it to your createApp features list:

import catalogPlugin from '@backstage/plugin-catalog/alpha';

const app = createApp({
  features: [
    catalogPlugin,
    convertedOptionsModule, // from the hybrid-mode migration
    ...convertedRootFeatures, // from the hybrid-mode migration
  ],
});

Once that's in place, you can add the current entityPage to the convertLegacyAppRoot function

const convertedRootFeatures = convertLegacyAppRoot(routes, { entityPage });

And remove the legacy catalog routes from your FlatRoutes tree:

const routes = (
  <FlatRoutes>
    {/* remove these two */}
    {/* <Route path="/catalog" element={<CatalogIndexPage />} />
    <Route
      path="/catalog/:namespace/:kind/:name"
      element={<CatalogEntityPage />}
    >
      {entityPage}
    </Route> */}

    {/* ...the rest of your routes stay for now */}
    <Route path="/settings" element={<UserSettingsPage />} />
    {/* ... */}
  </FlatRoutes>
);

At this point, you can navigate to /catalog and see the index page, and you can click into entity pages too. But the entity page probably looks a bit odd, maybe even broken. That's expected, and it's exactly what we're going to fix.

Step 1.1: Understand what just happened

Here's the key thing to understand about the new frontend system. In the legacy world, plugins handed you a bag of React components — EntityAboutCard, EntityLinksCard, and so on — and it was your job to compose them in EntityPage.tsx. You were the integrator.

In the new system, plugins declare their own extensions and those extensions are added directly to the extension tree. The catalog plugin already ships with extensions for the most common cards:

entity-content:catalog/overview — the overview tab for all entities
entity-card:catalog/about — replaces EntityAboutCard
entity-card:catalog/links — replaces EntityLinksCard
entity-card:catalog/labels — replaces EntityLabelsCard
...and several more

So right now, with convertLegacyAppRoot still processing your old EntityPage.tsx, you're rendering both the new plugin-provided cards and the legacy ones. Duplicate about cards, duplicate links cards — the works.

The same thing happened to the catalog index page: it's now coming entirely from the plugin, which means any customizations you had — custom columns, custom actions, initial filters — are gone for now. We'll address how to bring those back in the Catalog Index Page section.

This is also a good moment to add @backstage/plugin-app-visualizer to your app. Navigate to /visualizer and you'll get a full tree view of every extension in the system — what's enabled, what's disabled, how they're connected. It's invaluable for understanding how all these pieces couple together before you start pulling the legacy code apart.

Step 2: Entity Pages Overview cards

This is the most involved part of the migration. The entity page in a typical Backstage app is a large hand-composed JSX tree — different layouts and tabs per entity kind. In the new frontend system, all of that gets replaced piece by piece with extensions. Here's how.

Step 2.1: Clean up the duplicate cards

Go through your EntityPage.tsx and remove the cards that the catalog plugin now provides natively. For a typical overview page, that might look like this:

const overviewContent = (
  <Grid container spacing={3} alignItems="stretch">
    {/* Remove entityWarningContent — the default layout now handles this */}
    {/* Remove EntityAboutCard — catalog plugin provides entity-card:catalog/about */}

    {/* Keep: EntityCatalogGraphCard — not yet provided by catalog plugin */}
    <Grid item md={6} xs={12}>
      <EntityCatalogGraphCard variant="gridItem" height={400} />
    </Grid>

    {/* Keep: your custom cards */}
    <Grid item md={6} xs={12}>
      <EntityCustomCard />
    </Grid>

    {/* Remove EntityLinksCard — catalog plugin provides entity-card:catalog/links */}
    {/* Remove EntityHasSubcomponentsCard — catalog plugin provides this */}
  </Grid>
);

The only items you keep here are the ones that aren't provided by the catalog plugin, cards from other plugins, and anything you built yourself. Things could still look a bit out of order at this point, but that's okay, we will arrange things later.

Step 2.2: Bring in other plugins as NFS features

Some of the cards you kept around are provided by other Backstage plugins, just not yet added in the new way. For example, EntityCatalogGraphCard comes from the catalog-graph plugin. Add it the same way you added the catalog plugin:

import catalogGraph from '@backstage/plugin-catalog-graph/alpha';

const app = createApp({
  features: [
    catalogPlugin,
    catalogGraph, // adds entity-card:catalog-graph/relations and friends
    ...convertedRootFeatures,
  ],
});

Then remove the corresponding card from your legacy entity page. Keep doing this for every plugin that has an /alpha NFS export. You'll be surprised how much of your EntityPage.tsx just... evaporates.

If a third-party plugin you depend on doesn't have an NFS release yet, you can try converting it yourself following the plugin conversion guide. And don't forget to ping the maintainers 😄

Step 2.3: Convert your custom cards into extensions

Whatever is left after the plugin cleanup is either a card you built in-house or something that doesn't have an NFS equivalent yet. For in-house cards, you need to create an extension using EntityCardBlueprint from @backstage/plugin-catalog-react/alpha.

Here's a straightforward example:

import { createFrontendModule } from '@backstage/frontend-plugin-api';
import { EntityCardBlueprint } from '@backstage/plugin-catalog-react/alpha';

const customCardExtension = EntityCardBlueprint.make({
  name: 'custom-internal-card',
  params: {
    type: 'info',
    filter: entity => entity.kind === 'Component',
    loader: async () =>
      import('./components/EntityCustomCard').then(m => (
        <m.EntityCustomCard />
      )),
  },
});

const myCustomModule = createFrontendModule({
  pluginId: 'catalog',
  extensions: [customCardExtension],
});

Then add myCustomModule to your features list in createApp.

The filter prop is how you scope a card to specific entity kinds (or any other condition you want). The type controls where in the layout the card appears: 'info' places the card in the narrow right-hand info sticky column (like the default About and Links cards), while 'content' spans the full width of the main area. When in doubt, check how similar cards look in the /visualizer and match accordingly.

If your card needs configurable props (say, a title the operator can set per-deployment), you can use makeWithOverrides to define a config schema:

import { z } from 'zod';
import { EntityCardBlueprint } from '@backstage/plugin-catalog-react/alpha';

const customEntityCardExtension = EntityCardBlueprint.makeWithOverrides({
  name: 'custom-internal-card',
  config: {
    schema: {
      title: z => z.string().optional().describe('Title for the custom card'),
    },
  },
  factory(originalFactory, { config }) {
    return originalFactory({
      filter: entity => entity.kind === 'Component',
      type: 'info',
      loader: async () =>
        import('./components/EntityCustomCard').then(m => (
          <m.EntityCustomCard title={config.title ?? 'Custom Card'} />
        )),
    });
  },
});

Now the card title can be overridden per environment via app-config.yaml — no code change needed.

Step 2.4: Control ordering and per-card config

Once all the cards are coming through extensions, you'll probably notice the order isn't quite what you had before. Extensions render in the order they're declared in your config, so you can control this from app-config.yaml:

app:
  extensions:
    - "entity-card:catalog-graph/relations":
    - "entity-card:catalog/depends-on-components":
        disabled: true # you can also disable cards you don't want showing up
    - "entity-card:catalog/about"
    - "entity-card:catalog/custom-internal-card":
        config:
          type: content # we can still override config options
          title: "Custom Internal Card" # our config option can be set here

A couple of things to note here: you can disabled: true any card you don't want showing up, and you can pass configuration to the cards that expose a config schema (like the one we built with makeWithOverrides). To find the exact extension names, I'd recommend using the /visualizer but basically it's entity-card:${pluginId}/${cardName} for cards, and entity-content:${pluginId}/${contentName} for content extensions.

Step 2.5: Custom layouts per entity kind

The default entity layout looks quite nice, but if you had a completely custom grid arrangement for specific entity kinds, you can replicate that with a layout extension.

First, create your layout component. It receives a cards prop that you can render however you want:

import { EntityContentLayoutProps } from '@backstage/plugin-catalog-react/alpha';

export const CustomEntityLayout = (props: EntityContentLayoutProps) => {
  return (
    <div>
      <h2>Custom Entity Layout</h2>
      {props.cards.map((card, index) => (
        <div key={index}>{card.element}</div>
      ))}
    </div>
  );
};

That's a minimal example — in practice you'd want to replicate the warning/error components that the default layout handles. Take a look at the default layout implementation for inspiration.

Then wrap it in a blueprint and add it to your module:

import { EntityContentLayoutBlueprint } from '@backstage/plugin-catalog-react/alpha';

const componentLayout = EntityContentLayoutBlueprint.make({
  name: 'custom-layout',
  params: {
    filter: entity => entity.kind === 'Component',
    loader: async () =>
      import('./components/catalog/CustomEntityLayout').then(
        m => m.CustomEntityLayout,
      ),
  },
});

The filter here means this layout only applies to Component entities. Any entity kind not matched will fall back to the default layout.

Step 3: Entity Page Tabs and Custom Content

Step 3.1: Custom tabs and content

The entity page overview tab isn't the only thing that lives in EntityPage.tsx. You probably also have tabs for CI/CD, documentation, Kubernetes, and so on. The approach here is the same: if the plugin supporting that tab has an NFS export, import it and remove the tab from the legacy entity page.

For Kubernetes, for example:

import kubernetes from '@backstage/plugin-kubernetes/alpha';

const app = createApp({
  features: [
    ...convertedRootFeatures,
    catalogPlugin,
    kubernetes, // adds the Kubernetes tab automatically
  ],
});

Then remove the EntityLayout.Route for Kubernetes from your legacy entity page — the plugin now owns it.

For tabs that don't have an NFS plugin yet, or for truly custom content you built in-house, use EntityContentBlueprint:

import { EntityContentBlueprint } from '@backstage/plugin-catalog-react/alpha';

const customEntityContent = EntityContentBlueprint.make({
  name: 'custom-content',
  params: {
    filter: entity =>
      entity.kind === 'Component' && entity.spec?.type === 'website',
    path: '/custom',
    title: 'Custom Tab',
    group: 'deployment',
    icon: 'laptop',
    loader: async () =>
      import('./components/catalog/CustomEntityContent').then(m => (
        <m.CustomEntityContent />
      )),
  },
});

The group and icon fields control how the tab appears in the entity page navigation. Tab ordering and grouping can also be tuned through config — the Backstage docs have the full details.

One thing worth flagging: at the time of writing, I did not find a way to feature-flag a content extension in whole. There's an open discussion about this in the Backstage repo if you need to follow along.

Step 4: Catalog Index Page

With the entity pages sorted, let's look at what we can recover. Many of the props you used to pass directly to <CatalogIndexPage /> now map to config options on their corresponding extensions. For example:

initialKind → catalog-filter:catalog/kind config initialFilter
ownerPickerMode → catalog-filter:catalog/mode config mode
initiallySelectedFilter → catalog-filter:catalog/list config initialFilter
pagination → page:catalog config pagination

So instead of passing those as JSX props, you configure them per extension:

app:
  extensions:
    - "page:catalog":
        config:
          pagination:
            mode: cursor
            limit: 20
    - "catalog-filter:catalog/mode":
        config:
          mode: owners-only
    - "catalog-filter:catalog/kind":
        config:
          initialFilter: system
    - "catalog-filter:catalog/list":
        config:
          initialFilter: all

In the same way we had with cards, the order of the filter entries in the config also controls the order they appear in the UI.

If you had custom filters built in-house, those become extensions too, using CatalogFilterBlueprint:

import { CatalogFilterBlueprint } from '@backstage/plugin-catalog-react/alpha';

const customCatalogFilter = CatalogFilterBlueprint.make({
  name: 'custom-catalog-filter',
  params: {
    loader: async () =>
      import('./components/catalog/CustomCatalogFilter').then(m => (
        <m.CustomCatalogFilter />
      )),
  },
});

For more advanced catalog page customizations like custom table columns and action buttons, there aren't dedicated extension points yet. If you need those you can override the whole page extension:

const customCatalogIndexPage = catalogPlugin
  .getExtension('page:catalog')
  .override({
    params: {
      path: '/catalog',
      loader: async () => (
        <CatalogIndexPage
          initialKind="Component"
          ownerPickerMode="all"
          columns={customColumnFunc}
          tableOptions={{ search: false }}
        />
      ),
    },
  });

This gives you an escape hatch when the standard config options aren't enough.

Wrapping up

The catalog plugin is probably the most involved NFS migration you'll do, it sits at the center of the entity page, it has its own layout system, and it exposes more extension points than most other plugins. That's exactly why I picked it as a learning ground.

The mental shift that helped me most: you're no longer the composer. In the legacy system, you assembled all the pieces in React. In NFS, each plugin brings its own pieces and your job is to configure and override rather than wire. Once that clicks, the whole migration approach starts to click.

Reference

All the code shown in this post is based on a scaffolded Backstage app I set up specifically to test and validate each step of this migration: Sarabadu/backstage-catalog-migration. It's not a production app — just a clean starting point to try things out without breaking anything real. If something in the post isn't clicking, looking at the repository might help.

Did this help?

If you went through this migration yourself, I'd love to hear how it went. Did something not work the way I described? Did you run into edge cases I missed? And what would you like to see covered next — maybe migrating the other plugin, converting a third-party plugin that doesn't have an NFS export yet, or going deeper on writing custom blueprints?

Drop a comment below or reach out directly. The more feedback I get, the more useful the next one can be.

AI fluff generation

sarabadu — Wed, 27 Aug 2025 21:49:53 +0000

I've never been too picky on PR descriptions, but getting good context and details in a PR is a lovely experience. Now AI (Github copilot) gives you that experience with one click, right? RIGHT?

Well sometimes, maybe... but many times what you get is a detailed summary of what changed in each file and that is something I already have in a different tab, I see a lot of text but still gives me no value.

This happens mostly on the GH web interface while editing the PR description, and it is understandable in that instance the only context available is the files being modified, and commit messages, not much more. but the most valuable information inside a PR description is maybe the "Why" are we doing this.

How the fluff looks like

If you ask an llm to generate text, It will by default add some fluff to it: unnecessary data, fancy wording, and unchecked facts.

This means you can easily end up with fluffy content everywhere.

"add test" -> ends up with 20 test you hardly read or follow
"write the commit message" -> end in "improvements and refactors in file X"
"Writing social media post" -> fancy words everywhere
"user story"... who knows

The bigger issue with this fluff is getting the perception of value, but not real value. Your 20 test maybe test the same thing, or miss the actual business edge cases logic you need, but there are 20 of them and all of them are green!!! That LinkedIn post looks really professional you can remove some em dashes and nobody will notice is not you the one talking there.

Taking the control back

After all this we need to filter the fluff to get the real value out and take the control back eventually. So why not try to work fluff free from the beginning.

I love to use llm on all this tasks, are really handy. So I look strategies to keep control.

While writing content like LinkedIn, PR descriptions, Documentation, and this post, I like to write it first and then ask for pointing out improvements or typos, but always being explicit on "Do not re-write it, just explain what to improve". This in my experience give a lot of value by correcting some things, and challenge my text but without losing my identity and the control of what I'm writing

While coding I like to use agents in this way:
1- I start explain what Im trying to do, my objective, and some indications on how I'm thinking to do it
2- I usually ask for "create a plan" and "do it step by step waiting for my input between steps"
3- Then I challenge the plan or ask the llm agent to challenge my plan until I find a plan that makes sense for me
4- Finally i execute the plan step by step

When exploring new usages or tools using llm agents, I always try to find this way to keep in control and fluff free. It looks slower at first but at the end is much better to get a controlled result rather that getting a lot of "content" but some personal debt

Many times I hear "It was (copilot|cursor|the AI)", I like to think on "It was me/us using (copilot|cursor|the AI)" and take the responsibility of my content

"But I like to vibe code", I understand I like it too, it's great in some situations like exploring ideas, trying out things, or work in hackathon mode, but eventually I need to get the control back.

What is blocking us from contributing more

sarabadu — Thu, 21 Aug 2025 14:33:00 +0000

I have been encouraging colleagues to contribute to open source for some time, but there’s always a lot of friction. And the friction not only exists in open source; sometimes it is even harder for developers to contribute to internal projects.

In my experience those friction points fall into these categories

Friction point 1: I'm not the owner

While working on internal tools and libraries shared across organisations, I often get Slack messages or comments like::

- You can improve X, this way.
- Ohh good point, could you raise a PR on that repo, please?
- No worries, I will create a ticket on your board and wait.
- Ok, :sadcat:

Sometimes people get blocked by those changes, but still prefer to wait before trying to help with some changes. After digging into why this happens, one of the reasons is the "I'm not the owner"

And this could mean many things:

I'm not the owner -> I'm not entitled to make any changes.
I'm not the owner -> I have no idea how this works.
I'm not the owner -> this is not my task.
You are the owner, I expect you to do this work.

So what does ownership mean? All above assumptions can be true, so it is important to be clear on this.

So I try to reply with:

I'm the owner -> but you can raise a PR, and I will take a look at that.
I'm the owner -> we can kick off something together, or provide some directions.
I'm the owner -> but this is not our main priority.
I'm the owner -> but we are both users of/involved in X.

I truly believe every library or service should have one, and only one, owner team in the organisation. My favourite description of ownership is:

"The owner team should be the team having the holistic view on that project, having the last word on what gets in or not, and taking care of the general maintenance, and in many cases the ones on call if something goes wrong and needs quick attention"

Friction point 2: I don't have time for it

Some years ago I remember having a timesheet with: Code, Test, Review and Deploy

Sure, because those are the only tasks, right? If I would need to break down my daily tasks, they would look more like: Read/Learn, Code, Debug, Get into the Rabbit hole, Code, Test, Review, Go back 10 steps, Deploy

I think this is still alive in many orgs, where we have the conception that only writing code in "My repo" is part of my work. So many people only contribute privately and in "my personal time", we need to declare when changes are needed outside our repos and make contributions part of our daily work.

After all we and our employer are benefiting from those contributions

Friction point 3: It is too hard

Contributing can often leave us with a single feeling: This is too hard. From figuring out how to set up the project and finding where to start, to understanding contribution directives and getting useful feedback. All of this can make contributing feel far more difficult than working in our own projects.

To deal with this friction, awareness is key here. Encouraging people to contribute saying "it's easy, just push a PR" can end up with a frustrated contributor who rarely wants to come back. So personally I try to support people contributing together, and changing the "it's easy" to "it is challenging, but pay off" and "I'm able to help on that".

On the other side creating a good path for contributors it also helps a lot, I love when projects provide progressive introduction to setup the project, being concise on the best way to raise things and whenever is possible also share how the reviewing process work so they know what to expect before hand.

In conclusion

After sorting the friction point contribution brings a lot of benefits, for both maintainers and contributors.

Breaking our own bubble makes us learn and be challenged in many different ways improving our knowledge.

For maintainers it is most of the time better to get a feature to review rather that a feature request.

Having people who are used to contributing internally and externally helps companies break down silos, reuse more software, and create a culture where people are eager to unblock themselves.

So... Let's go out there and contribute, help other to contribute and explicitly enable contribution!!

El Peer Review no sirve para nada (Spanish)

sarabadu — Thu, 24 Sep 2020 16:02:10 +0000

Bueno, en realidad no creo que no sirva para nada, de hecho, el peer review me parece una de las herramientas más productivas para la interacción entre compañeros, el crecimiento de un equipo y la calidad de nuestro trabajo.

Sin embargo, en muchos equipos de trabajo observe como menospreciaban esta práctica o bien la habían dejado completamente de lado. ¿Pero cuáles son los problemas?

No tenemos tiempo para eso

Bueno esto lo escuche muchas veces tanto para los peer review como para los tests unitarios.
Nunca vas a tener tiempo para las tareas que no les destines tiempo.

Cuando el problema es el tiempo necesitaremos decisiones fuertes y de largo plazo. Tanto el peer review como el testing unitario o el TDD, son prácticas que demuestran resultados cuando son constantes, se mantienen en el tiempo y se hacen costumbre.

¿Qué importancia tiene la calidad?
¿Qué tan valioso es la discusión entre colegas sobre el trabajo que estamos realizando?
¿Cuánto tiempo sería aceptable dedicarles a estas prácticas?

¿Y qué puedo hacer entonces?

Adapta el proceso (o crea un proceso) de desarrollo para que incluya el Peer Review y revisa que se cumpla.
¿Necesitas convencer a alguien? Medí los tiempos de desarrollo y peer review
Pon metas a largo plazo

Y por último ten en cuenta que Arreglar cosas que no tuvieron peer review lleva tiempo también!!

No me gusta que me muestren mis errores

Siempre puede existir algo de incomodidad a la hora de marcar y que nos marquen errores, pero tenemos que poner el foco en el objetivo por el cual hacemos estas practicas

El peer review es para que nosotros, como equipo, tengamos mejores resultados

Ese es el objetivo, ¡si solo ese! En el peer review se pueden encontrar errores, también para compartir puntos de vista, validar si lo que hicimos se entiende y aprender del otro. Si nos enfocamos en solo buscar y encontrar errores, estamos desperdiciando la posibilidad de crecer en otros aspectos.

Por otro lado, acá juega mucho el cómo hacemos el peer review y como lo recibimos.

Cuando hagas un Peer Review:

Intenta entender que decisiones tomo tu colega
Toma nota de que cosas harías distinto y por que
Intenta buscar todos los detalles posibles: mala identación, nombre de variables, ¡¡todo sirve!!

Pero tu trabajo no termina ahí, si dejamos esto anotado y nos desentendemos estamos haciendo solo la mitad del trabajo...

Júntate con quien realizo el desarrollo y revisen tus notas juntos
Intenta reforzar "intentemos mejorar juntos con esto" para mantener el objetivo en mente
Mide tus palabras, ten especial cuidado en cómo te comunicas frases como "acá te equivocaste", "esto está mal" son fácilmente reemplazable con "yo esto lo haría diferente", "esto se ve raro, revisemos", "no entendí esta parte"

Pero si algo está mal, está mal y yo le voy a decir porque un error es un error y etc....

Si, si, pero ¿qué cuesta modificar un poco tus palabras para lograr el mismo objetivo? no hablo de decir que algo está bien cuando no lo es, ni que algo es aceptable cuando no lo es... hablo de mostrar eso mismo de la manera mas amable que se te ocurra.

Y cuando recibas un Peer Review

Tu trabajo no está terminado, solo es un boceto que está a punto de perfeccionarse. Si tomas como una revisión de algo que ya estaba "terminado" puede ser chocante. Mientras desarrollas piensa "aún faltan los cambios del peer"
Tu colega no es el enemigo, el enemigo es el llamado a las 3am por un bug, o el código spaghetti de hace 3 meses (que sí, vos escribiste)
Da tu opinión no tomes el peer como una lista de cambios y ya, discute con el peer porque tomaste una decisión, porque elegiste ese nombre, porque te equivocaste ahí.

El Peer Review puede impactar negativamente en mi carrera

EL PEER REVIEW NO PUEDE SER MÉTRICA PARA MEDIR PERFORMANCE. -necesito mayúsculas más grandes -

Bueno soy encargado de los Peer Reviews

Si tu puesto es Jefe, PM, CEO, o simplemente el que le gusta seguir métricas para ver como trabaja la gente, te recomiendo lo siguiente:

No tomes los errores de un peer review como indicador de performance de una persona, solo lograras que nadie quiera encontrar errores, puede que al principio veas algún dato, pero con el tiempo no vas a tener información.
Cuando planifiques prácticas de Peer Review, intenta plantearlas dentro del proceso de desarrollo, antes de "los últimos retoques" y antes de hacer las pruebas finales. si se planifican al final genera una sensación de retrabajo que no es necesaria

Pero encontré que Alejandra le encontró 500 errores a Anselmo, ¿Qué hago me quedo de brazos cruzados?

No, de ninguna manera, en ese caso felicita a Alejandra, está haciendo muy buen trabajo.
Anselmo solo mostró un borrador de su trabajo, es esperable que se encuentren errores.

To:CEO; Subject:TESTING

sarabadu — Mon, 31 Aug 2020 21:21:14 +0000

Last week I received a mail from a user:

Subject: "RE: Testing WTF"
Body: "please stop sending these test emails"

At first, we tried to replace all the email addresses on the database and config files, but the feature that sends the emails uses a lot of business logic. So we wanted to test the feature with a more realistic and end-to-end approach.

After looking for a while I found this lovely piece of software. MockMock is a very simple but powerful SMTP mock server built in java.

How it works:
Simply download the MockMock.jar and run java -jar MockMock.jar this starts the SMTP server on the port 25 and an HTTP server on port 8282.

Now you can configure your SMTP server as localhost on port 25, when the application sends an email just browse on http://localhost:8282/ and you'll see something like this:

And we can see de detailed info of each mail:

You can also change the ports with -p argument for SMPT and -h for HTML like java -jar MockMock.jar -p 25250 -h 8080

I love this type of test because we can extend our test cases and look for the result in a fancy and safe way.

breaking my yotube bubble

sarabadu — Sat, 22 Sep 2018 18:35:33 +0000

i use YouTube for learning every day but i notice that my timeline only have mens channels, so i wonder where is the women in tech tutorials

Every social app creates a bubble around us preferences and that is ok somtimes but after some time you are missing a lot of content

Today i look at my YouTube home timeline and didnt see any woman

I follow channels like fun fun function, devtips, kyle simpson talks, Coding train....
Maybe YouTube in some point think uhmm let show mens talking about tech to think user.

So id like to break this bubble whit women in tech channels.

Can you recomend me some channels?
Thanks!!!!

who need unit test in their open source project?

sarabadu — Mon, 27 Aug 2018 01:14:47 +0000

i need to practice unit testing in java and js. And i want to start contributing to community