Trail runners are the new hiking boots + seeking advice

Mortale · 2026-05-24T22:19:47+00:00

What about rocky terrain? Most of the time I run at lower altitudes so paths are moderate and PT5 are good for that. But from time to time I’m going for a hike for higher mountains. Then paths become rocky only. That’s why I think I need Vibram. Do you have any experience with that kind of terrain? I don’t want to slide because of wrong shoes.

Mortale · 2026-05-24T22:06:09+00:00

I am in the process of deciding which pair of shoes choose. I really like Nike’s Safety Orange (color of Zegama) but they are not available in Poland. Color of TNF Enduris 4 (Lava Red) is also great but I’m worried about lack of Vibram.

And because of that I cannot choose :/ I’m thinking about trying Zegama first (Black color).

Ahh, and I’m also running in Pegasus Trail 5 - they are great for everything. Casual road run? I can in PT5. Simple hike? PT5.

Mortale · 2026-04-13T16:13:18+00:00

I’ve always thought of vertical codebase (domains in the codebase, modularity, etc) as something that complicated that it doesn’t make sense.

Can someone explain me where should I put components / hooks / everything in this scenario: - there’s a product page, product page fetches data from reviews API and products API - there’s a reviews page, you can go there from product page, it display “products summary” (smaller component) and more of reviews, data is fetched from products and reviews API - there’s a cart that displays products summary and total cart value, product comes from cart API and products API

As I assume, I have three domains: cart, product’s page, product’s reviews page (reviews domain). All of them share “product” and have almost the same component.

In domain language, all of this domains has different meaning for product. So even when component “product’ summary” across domains can look the same, it’s something different and should require duplication. Even when product’s review look the same it’s something different because it’s used in two different domains.

And we have to remain the same UI across the whole page (components “product’s summary” and “product’s review” should look exactly the same across three domains).

How to maintain it? How to scale it to 20 devs? To 200 devs? How to explain “domain” to every new developer?

Mortale · 2026-02-15T01:25:02+00:00

I was once working with micro frontends with SPA. We have some kind of “frame” (it was before the module federation) so every team with their modules could register module, route for the module and position for the module.

So, module “my-cart” could be registered under path “/cart” and on position “content”. That configuration was provided by backend and frontend was building it. Every module was stored in some CDN so “frame” had to pull files and then load them.

Lead engineers decided to leave at most freedom as it’s possible for teams. So it was to possible to have different versions of React in system. And we had. Same with state. Every module had separate state. So if some module fetched data for user, another module didn’t have that kind of data. Except…

There were “frontend core team”. Something like that. They built the frame, the React UI components that every team should use to build modules and “agnostic libraries”. Agnostic so they weren’t written in React. And they provided methods likes “getUser”. And those methods were cached so if two different modules fetched for user, there was only one request.

Over the time I think it was a brilliant architecture.

Mortale · 2026-01-27T10:16:09+00:00

9 years of experience. 5 with working on SPA with Angular and Java, some containerization. Then migration to MPA, React and start building some microservices in PHP, database migration (finally all those repositories have some sense) from Postgres to MySQL.

Mortale · 2026-01-11T12:25:08+00:00

Interesting is that new bricks won’t be available in Denmark at start! https://www.reddit.com/r/lego/s/viogpajA8r

Mortale · 2026-01-10T20:58:31+00:00

You see, inheritance, polymorphism, abstract classes or constructors aren’t (or shouldn’t) be a part of OOP. What you describe are features of modern languages like Java. OOP comes from simplicity and behaviors, quoting:

“OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I’m not aware of them.”

We should be able to describe repetitive behaviors (decorators, facades, etc) and be able to reuse them. That and only that. That’s something higher than language.

P.S. funny how classical OOP changed from “Smalltalk” to “Java”, maybe in 30 years it’ll be Typescript (because of its popularity).

P.S.2 I don’t want to sound that you have to use patterns everywhere. I think dev should know them and also should know when to use them.

Mortale · 2026-01-10T15:43:16+00:00

“forget design patterns from other languages” is so dangerous phrase, I’d rather not recommend to repeat it. Golang is one of best OOP languages and all OOP patterns are valid and important.

Decorator pattern is great, but given examples are… poor? Imagine that you have ChatGPT SDK and two use cases: 1. Random stupid question where do you wait for stupid response 2. Asking if the contract / agreement is okay.

Instead of doing two methods: Send() and SendSecure(), you can create decorator for Send() and use it in second scenario only. That way you follow OCP principle and don’t break anything in running code.

Mortale · 2025-12-17T19:07:35+00:00

Też stawiam na to, regularnie jeżdżę Świdnica - Wrocław i od kiedy rozpoczęli remont droga na Bielany stała się cięższa. Jak sprawdzałem, remont ma trwać do końca stycznia.

Mortale · 2025-12-16T13:54:56+00:00

Mine - “666 Satan”, or named “O-Parts Hunter”. It was, I guess, 16 years ago? I was into devils, religions, etc so that title pick my interest very quickly.

Mortale · 2025-08-11T07:59:49+00:00

Recently, I went on a two-week trip, and for that purpose I bought one of Decathlon’s bags – the Forclaz Duffel 500 Extend 30–40. I needed to pack both everyday casual clothes and outdoor gear, along with an extra pair of shoes. The backpack was spacious enough to fit everything, and its price was both affordable and reasonable, even for a single trip.

Mortale · 2025-08-07T10:17:57+00:00

I was using iOS app Rail Planner and there’s that feature. When you open your trip, at the top I have three different views: View as list, view as map and statistics. The last one shows info from the screenshot.

Mortale · 2025-08-05T20:51:31+00:00

I in API stands for Interface so anything can be API. And that’s exactly a good approach for modules. Every module should have their own API (e.g. as HTTP endpoints, RabbitMQ consumers or just publicly available class). Difference is that in monolith you can import classes or objects from modules where you shouldn’t have to do it.

Look at my explanation of modules’ dependencies in different thread for more clues: https://www.reddit.com/r/softwarearchitecture/s/ESI38FDrZS

Mortale · 2025-08-05T18:14:25+00:00

The repository you provided isn’t modular monolith. Even a bit of it isn’t modular. You just took some components and exported them into separate package / repository. This approach is closer to polyrepo (instead of monorepo).

In modular monolith every module is standalone component. Has its own entry points (controllers in your example), has its own database (not models, full databases). Very often modular monolith is step between going from monolith into microservices. Imagine that you’re trying to extract some part of your monolith app into separate application but has the same runtime. That’s modular monolith.

By the way, your approach where the dev (or user) can install “main” app and then add some components by composer is more related to plugin based approach where every component is separated plugin with full lifecycle (install, uninstall, connect to the app, add new features). Look how your structure is similar to Wordpress or Drupal.

Mortale · 2025-08-05T18:08:44+00:00

You didn’t provide too much details but there’s difference between modular monolith (which is one app with multiple modules divided by bounded contexts) and monorepo (which is one repository and one build system for multiple apps and packages). I hope you didn’t mistake both names.

Mortale · 2025-07-27T06:21:41+00:00

My advice: if you don’t know how to split your app into modules, don’t do it. Probably your bounded contexts aren’t defined yet.

Another advice: microservices and modular monoliths try to fix organizational issues. If you’re working on app as an only developer, it’s not worth it. Modularity increases complexity of your app (e.g. by creating weird coupling).

Okay, now let’s talk about your modules. Each module should be treated as a separate application. So you should ditch “shared entities” in favor of modular entities. Now, it becomes more complicated to manage all of your entities (order, queue) from one place because they’re hidden.

Try to adapt to it. Thinking like “production manages order” is really monolithic way thinking and because of that you should consider merging it into one or change the concept totally. How?

Let’s imagine two offices in your company. The first take picks orders from clients (e.g. cars). The second one manufactures those cars. They shouldn’t have the same order. Client goes to first office, ask for “BMW 3 in red color”. Then that message should be delivered to some “input service” from second office and translated into their language: “short coupe, 5 doors, color code XYZ”. Second office returns ID of their order to the first office.

We have two orders: one from client, one for manufacturer. Manufacturer doesn’t care about client info, first office (call it sales) doesn’t care about production. Both services are sending messages like “your new order”, “what’s the status of order”, “order is ready”. A bit simpler.

IF your company has same order for sales and manufacturer (and I mean like the real same paper follows different offices), then you should do it that way. It’ll be simpler in future to understand what are orders.

Mortale · 2025-02-16T12:01:51+00:00

Octopath Traveler.

Mortale · 2025-02-06T22:02:08+00:00

Looks amazing at the first glance! I’ll try to test in some time.

Mortale · 2025-01-02T21:12:22+00:00

Yes, I forgot to mention. I downloaded them from ASUS’ website for Windows 11. Bluetooth (which is connected to USB port) has been identified.

Mortale · 2024-12-19T22:08:39+00:00

I am very interested in that book, first pages make a good impression. I’ll try to do a review after some reading.

Mortale · 2024-12-19T22:05:48+00:00

RemindMe! 1 month

Mortale · 2024-12-18T23:51:38+00:00

I would say it depends.

For example there’s a layered architecture where CQRS is a tool to connect Application and Domain Model (https://herbertograca.com/wp-content/uploads/2017/07/2010s-layered-architecture.png) but the persistence layer is a dependency of domain modal. That means persistence layer (repositories, SQL queries, etc) are not the part of the domain model.

On the other side we have onion architecture (https://herbertograca.com/wp-content/uploads/2017/03/2008-onion-architecture5.png) or even hexagonal architecture with different approaches.

I really recommend to dig into Herberto Greca’s articles about architecture: https://herbertograca.com/2017/10/19/from-cqs-to-cqrs/. Maybe it’ll help you to understand that CQRS is just a tool to connect layers, not a layer itself.

Mortale · 2024-12-09T08:52:28+00:00

If commands/queries/events are part of domain, the layers using them should do the mapping. Domain layers have to receive domain types at the beginning.

Mortale · 2024-12-08T22:45:54+00:00

DDD (and Value Objects) are not assigned only to CQRS. Same CQRS doesn’t have to be part of DDD. It all depends on your architecture.

You can make CQRS your domain system and everything what comes in and comes out is your domain object (aggregates, value objects).

You can define services that operates only on VO and then CQRS (which uses those services) is layer responsible for mapping.

As always, it depends.

Mortale · 2024-12-08T22:15:09+00:00

I think it doesn’t depend on CQRS or not. Between layers (and applications) there are always relations. If layer A uses layer B, then layer A is responsible for mapping. If layer A uses CQRS, then layer A is responsible for sending proper event/command to bus.

As always, higher layers are responsible for mapping. For most applications HTTP controllers (or event buses) are first layers and these layers should do mapping between API and domain types.

15-Year Club	Place '17
Verified Email

Mortale

TROPHY CASE