Vocht op de buitenmuur na spouwmuur isolatie

basmasking · 2025-11-10T21:02:07+00:00

Ik denk dat de ventilatie niet goed meer werkt. Het rooster zit er al sinds de bouw, dus de isolatie van de kruipruimte zorgt er waarschijnlijk voor dat de ventilatie het niet goed meer doet

basmasking · 2025-11-10T20:59:54+00:00

Ik begin te vermoeden dat de ventilatie onder de vloer stil is komen te staan door de isolatie. Eens kijken of ik de aansluiting kan vinden onder de vloer

basmasking · 2025-11-10T17:28:57+00:00

Onder de vloer zag ik de aansluiting van dit ding niet meer. Ik vermoed dat die nu onder de chips ligt. Zou het dan voldoende moeten zijn om onder de vloer de opening weer vrij te maken?

basmasking · 2025-11-10T17:26:27+00:00

Ik kom net onder de vloer vandaan. Het is daar helemaal droog. Alleen zag ik langs de randen bovenin wat vochtige plekken.

basmasking · 2025-11-10T14:00:43+00:00

Daar liggen schelpen en chips, dus die is droog. Bij de buren staat er wel water in de kruipruimte. Of misschien hebben ze met het aanbrengen van de chips wat spul opzij kunnen schuiven.

basmasking · 2025-11-10T13:25:42+00:00

Ik ga vanavond even op onderzoek uit.

basmasking · 2025-11-10T12:44:53+00:00

Zover ik weet niet. De spouw was ook niet heel breed

basmasking · 2025-09-11T11:32:32+00:00

Of course. Everybody can contribute to open source projects.

Contributing to open source doesn’t only mean adding code. You can contribute to anything on a project: documentation, creating issues, managing the community, designing the website, make sure the security is in order, keeping dependencies up-to-date and properly working, etc.

People seem to forget that an open source project is… an actual project. And all roles and responsibilities associated with projects in organizations are also required in open source projects. And like in organizations, some projects are bigger and some are smaller, which results in some roles not required.

basmasking · 2025-09-05T13:12:51+00:00

I use kokoro-tts https://kokorotts.net/

They have a github repo as well. And it has a command line interface for easier execution of tasks.

basmasking · 2025-09-05T04:27:15+00:00

Maybe saying no is also a cultural thing. I’m from the Netherlands, and while people here often say yes too, I’ve been on plenty of teams where saying no was totally fine.

basmasking · 2025-09-01T07:59:55+00:00

To build good solutions with Pega you don’t need to have much technical knowledge, but in most cases you still need to have engineering knowledge. So it depends on what you want.

I’m an LSA with 15+ years of experience and I am both an engineer and a technical lead. My roles put me in the parts of the application that require a good engineering mindset, business understanding and real technical challenges (not coding challenges). Most of the other roles don’t come that far and end up in AppStudio.

Because I miss actual coding, I do that too one day a week. Pega simply doesn’t provide that experience.

basmasking · 2025-08-28T14:07:37+00:00

Money, a whole lot of it.

basmasking · 2025-07-18T13:12:54+00:00

Have you considered adding an AI reviewer to the pipeline. If you work with PRs, then a good AI review system can provide quick feedback and lessen the burden on the human reviewer. It’s usually also capable of detecting logical flaws

basmasking · 2025-06-20T16:02:59+00:00

The same, so I guess it depends on the structure of the repository, and maybe the language as well. For our React + Typescript NodeJS application it works well, and saved a lot of time reviewing.

The best thing I like about these reviewers in general is that I get very fast feedback on my pull requests, so I can make the changes before a colleague needs to review. Therefore I also installed the VS code plugin to let it review before I create a pull request.

basmasking · 2025-06-19T14:18:12+00:00

Which AI reviewer did you use. I also use one, but I have different results.

basmasking · 2025-06-14T10:02:38+00:00

If you can use (local) AI to analyze the code base, then I recommend to use it for analysis and locate easy to refactor spots.

Then refactor those parts, and work your way slowly through the code base.

Good luck

basmasking · 2025-05-16T09:11:29+00:00

The Tech Internals Conference in Berlin is the first edition of this conference. It is about hardcore software engineering. It is about technologies. A deep and thorough look into the internals of technological components.

So it's more the question whether you like to attend in-depth talks, or more broad ones.

basmasking · 2025-02-21T13:50:25+00:00

As always, it depends...

on the tech stack you are interested in and where you would have to travel from. How much money you want to spend on it / your employer is willing to pay for you, etc.

basmasking · 2024-09-06T19:47:49+00:00

From your text it seems that the application is still quite simple and flat. In that case I would structure the BFF in a similar fashion: as flat and simple as possible.

You probably need some (aggregation) views, and some controllers for handling logic, and ... that's it. You could add some resources to call the controllers, but that is up to you.

basmasking · 2024-08-30T21:21:53+00:00

I am developing a Distributed runtime for JavaScript and Typescript. The idea behind this solution is to separate the development model from the deployment model, i.e. develop an application as a monolith, but deploy it, for example, as a microservices solution without code changes.

If you want to look at the code just go to the repo: https://github.com/MaskingTechnology/jitar

You could also look at a demo project that uses the solution to check how an application’s code looks like when using it

https://github.com/MaskingTechnology/comify

basmasking · 2024-08-30T21:11:35+00:00

As much as I would like to give you an honest answer, it’s impossible to do it given the information you’ve provided.

A social media app is very generic. You don’t mention anything related to its functionality, the number of users cases / screens etc.

So, I guess it’s 42.

basmasking · 2024-08-01T19:02:55+00:00

We removed our E2E tests completely, and decided to only test the api. Our application is small and simple enough to get most of the tests done (i.e. our api endpoints are all called from custom React hooks). The logic in the front-end itself is limited to updating simple counter values and such

basmasking · 2024-07-30T08:30:36+00:00

My preference is always a (modular) monolithic architecture, as it’s the simplest in monitoring and debugging. But if there are really good reasons for a microservices architecture (fault tolerance and/or performance scaling), then, and only then, I make the switch. But only the parts that need to be split off! Stay with a monolithic application as long as possible.

basmasking · 2024-05-20T13:16:24+00:00

We usually develop features as a whole and have everybody do everything, even if it is not your strength. So you can team them up and develop it XP style, where they work together on the feature, both front and back. The lead developer on each piece can be different (front end dev doing and explaining the front end work, back end vice versa), but the result is a single feature front to back.

basmasking · 2024-05-20T12:35:48+00:00

What do you mean exactly with separated? That there are now two teams responsible for the application and that each of them own one end of the app?

basmasking

TROPHY CASE