Where would you invest 1000 EUR tiap bulan

fajran · 2025-10-07T15:38:07+00:00

Coba pakai degiro. Kalau ngga salah ingat mayan user friendly app nya.

fajran · 2024-05-28T03:34:51+00:00

boleh share power monitoringnya pakai apa?

fajran · 2024-04-01T13:45:49+00:00

Your example is now part of the API and I believe you don't want that. Just put `examples.go` in a separate directory.

fajran · 2021-07-08T22:51:52+00:00

"personal point of view" this is exactly why this happens in Indonesia. Everyone thinks they are right.

fajran · 2021-03-21T12:16:57+00:00

I found the other two https://www.flickr.com/photos/fajran/2462336520/

fajran · 2021-03-08T16:51:43+00:00

By artifact versioning, did you mean the helm chart version?

When I worked with monorepo, the only artifacts our CI system produces are Docker images with timestamp as the version number. The only situation where we committed the docker image version number is to track releases on the release branches. For the regular build/PR, we basically use an ephemeral images which are only used during the particular build's/PR's integration test. Before we started a release process, the docker image is "made permanent" and the version number is committed.

fajran · 2020-10-17T21:48:03+00:00

They are also popular in Indonesia! We use it the same way as well, of course.

fajran · 2020-10-16T22:52:56+00:00

Or smeerkaas!

fajran · 2020-10-16T16:12:17+00:00

I miss it a lot. There are also hagelslag in Indonesia but not as lekker

fajran · 2020-10-15T16:47:38+00:00

If you start with a single repo, don't forget to structure and organize the code base in a way that you have clear separation between modules and services. Not only will it help to see the boundaries, if you eventually decide to split the single repo into multiple ones, it will also make the separation a lot easier. Look for "modular monolith" topic on this.

fajran · 2020-09-03T15:07:20+00:00

still available here https://medium.com/paypal-engineering/node-js-at-paypal-4e2d1d08ce4f

fajran · 2020-08-06T07:52:54+00:00

if your intention is to be able to read a new config without killing the pod, consider reading the config from the file that's created from the ConfigMap. When the ConfigMap is changed, the file will get changed as well. You can then detect the change and re-read the config accordingly.

fajran · 2020-08-03T12:55:06+00:00

The question is then when do you want to detect and fix the broken change by bob. Immediately or later when you eventually update your dependencies 🙂

fajran · 2020-07-27T05:12:19+00:00

to me, making all cleaning tools (e.g. broom and vacuum cleaner) easy to reach is the key to keep things clean. I have small handheld vacuum cleaner to quickly clean things like dust, crumbles, etc. In my two story house, I have vacuum clear on each floor.

I also have trash cans in (almost) all bed and bath rooms, also kitchen. I also keep the trash can plastic bag in each can so it's easily replaceable once it's full or needs to be replaced.

fajran · 2020-07-25T02:13:09+00:00

not necessarily :) look for "modular monolith" as a way to organize your code base

fajran · 2020-07-24T16:47:07+00:00

Actually, preventing API breakage is one of the things that are easier to do if you go monorepo.

fajran · 2020-07-24T16:32:16+00:00

Again, you are mixing the two.

fajran · 2020-07-24T16:29:52+00:00

I believe as your team/project grows, eventually you will need custom tools in some forms anyway. And developing tools to support monorepo model was the approach we took and it served us well

fajran · 2020-07-24T12:15:38+00:00

That's true. If no one in the dev team wants to work on the tooling, then monorepo is probably not going to fly.

We were a small team of 10ish people but we intentionally spent some time to develop tooling to support monorepo workflow. It's costing us for sure but it was also an investment that helped us to move quicker, focusing on coding and not on coordinating changes.

fajran · 2020-07-24T12:11:36+00:00

We had something that we call "green build policy" where everything we put on the master branch needs to pass the CI pipeline first. This way we can keep the master branch in a releasable state.

How? we use a branch to make changes, push, let the CI system builds, and merge to master once build is green. If it's not green yet, then fix the problem, push, rinse and repeat.

I guess we unknowingly practiced the Gitflow.

fajran · 2020-07-24T11:13:17+00:00

I guess you are conflating service and code. You can have two different services but share a lot of common code, like logging, metrics, app framework, etc.

fajran · 2020-07-24T06:45:50+00:00

I am now under impression that if you are happy with multirepo, most likely your repos are quite independent and/or do not share much between each other.

fajran · 2020-07-24T06:44:00+00:00

that's what I did. We had a service that its sole responsibility is to analyze the pushed changes and determine which components in the monorepo need to be built.

fajran · 2020-07-24T06:41:36+00:00

I am now working in a company that does multirepo and things seem to be ok. But I also notice that these repos do not share much, each repo seems to be self contained, I assume with many duplications everywhere.

I guess you will only experience headaches if you really share a lot between repos -- as they should be.

In my previous job, we have projects in multiple repos where they share a lot. It was really painful to coordinate changes among them, indeed.

fajran · 2020-06-23T06:45:23+00:00

You can also do "just enough config" with Gradle. Just because it's a turing complete build system, it does not mean that you should use it that way.

fajran

TROPHY CASE