I wondered why I was asked twice about network troubleshooting between two machines and the destination machine is not reachable directly. It seems there are somethings I didn’t understand fully or I missed something. Today I googled "tracert is not enough" and found Traceroute Limitations Explained. It explains my doubts now. Traceroute Limitations Explained gives some limitations of traceroute and introduce their production to avoid those limitations. Are there any other ways?

The real differences is quoted here. You can find the content here A kustomization that is marked as a Component has basically the same capabilities as a normal kustomization. The main distinction is that they are evaluated after the resources of the parent kustomization (overlay or component) have been accumulated, and on top of them. This means that: A component with transformers can transform the resources that an overlay has previously specified in the resources field.

Today I was asked which framework was used in my design of microservice systems. I answered those concerns of microservice are handled natively by kubernetes when my systems are deployed into kubernetes clusters. I will not use those frameworks in my design of microservices. The question sparked several questions in my mind. Here are those questions. Why do we still need microservice frameworks when kubernetes is the de-facto platform now?

In normal kubernetes metrics, you will find cAdvisor, Metrics Server, Kubernetes API Server, Node Exporter, and Kube-State-Metrics as source of metrics. In last 2 days, I noticed prometheus-adapter. Today KEDA popped up in my mind. I checked its website and found it can be source of metric as well. cAdvisor, Metrics Server, Kubernetes API Server, Node Exporter, and Kube-State-Metrics can be considered as in-cluster source of metric. However KEDA is about out-cluster source of metrics.

Recently I added Crashlytics into my project on Oct 25, 2022. I encountered this issue and spent a while to fix it. Today I had to figure out how to do it again, and spent a while. I hated to do that again, so here is this article. The key message is the first one below. It is quite misleading and lead me to wrong direction to change DEBUG_INFORMATION_FORMAT.

Last three days, I found an issue can only be reproduced in realease mode.The beta testing cycle via testflight takes too long and it definitely is not the option. I debugged my application in iOS before. One thing popped up in my mind whether I can put release mode of my application into iOS using the debug tool of vs code. I changed my launch.json as below in my project and debug my application.

Today when I leant SRE course from cloudskillsboost, the first course is google cloud foundation. SRE is great. cloudskillsboost should be best place to learn SRE as it is originated there.

Today I re-read Technology Radar Volume 26, SDUI got my attention. In the past, I was very interested in ERP systems, and studied several open source ERP systems such as openerp(now odoo), ofbiz and adempiere. SDUI is quite similar to technologies used in those open sourced ERP systems. technology data source ui complex SDUI server end logic decides/graphQL odoo

iPhone Enable developer mode: Setting -→ PPrivacy & Security -→ Developer Mode IDE Android Studio It is quite straight forward in Android Studio. Install flutter plugin and restart Android studio VSCode select the Run and Debug icon in the Activity Bar Select "Dart & Flutter" in "RUN AND DEBUG" dropdown list Edit flutter iphone setting Change launch.

It is quite easy to refactor code using IDEs, however it will be a different story considing to refactor to testable code. Concerns The refactor functionality in IDE is based on rigor theories and algorithm to make sure the refactors don’t change the behaviours of programs and get it better organized. One of the theories, can be found here Target Refactor code to testable codes following best practices.