coronapl

Reading so many contrary positions about which model is better or worse shows how difficult it is to measure intelligence based on personal experiences. Of course, benchmarks try to make the process as objective as possible, but they often don't correlate with our personal experiences.

The other day 4.6 was fantastic for x task. Today, 4.6 overengineered everything and I had to revert all my changes. When evaluating models, perhaps it makes sense to consider luck as an ingredient before reaching any personal conclusion.

I refer to the technical constraints of the on-promises model which affects the modernization of the healthcare sector in the DACH regions. There is a need for integrating with SaaS products for several use cases or having AI features. Both things are not easily possible will a fully isolated setup. Therefore, I have experienced that IT departments are becoming more open to adopting Saas solutions compared to a few years ago, where it was not rare for a solution to be immediately rejected because it was using a hyperscaler.

I very much agree with the fact that IT departments have a massive influence during the sale process. Though, based on my experience, things are slightly softening. We entered the DACH market in 2023 with a cloud based CRM for the care sector. Before that, it was pretty much inconceivable in the care sector to use anything that wasn’t installed on-promises and fully isolated from the internet. Nevertheless, companies are quickly realizing that this is not scalable anymore. There is an urgency for modernizing work tools which is simply not possible with the limitations of the on-promises software era. Additionally, things like C5 seem to give a lot of confidence to IT departments for speeding up the sales process.

Give way to people crossing the street.

I come from Mexico, where millions of people walk and take public transport every day. Unfortunately, poor infrastructure and our mobility culture hurt pedestrians the most. Sometimes people have to wait several minutes just to cross a street. Years ago, a teacher told me that giving way to pedestrians was a simple action to make the world better. It makes a real difference for those who don't have the privilege of being in a car. This stuck with me, and I try to do it whenever possible. It might not apply everywhere with better infrastructure, but I find it to be a small yet meaningful action.

I’ve used SST, Pulumi, CDK, and Terraform. I decided to stick with SST because it offers a far superior development experience. Sure, I could write IAM policies with plain CDK, but it’s more error-prone and harder to maintain. Features like linking and live lambdas just make development so much easier.

I actually think this project makes a lot of sense. It lets you get started in minutes without dealing with unnecessary details. Furthermore, you can always access the low-level Pulumi component and override whatever you need. Keep doing what you’re doing! Your project makes IaC more accessible to everyone, and that’s a good thing. I’ll be happy to try it.

I'm glad to see useful features like easily adding userId and sessionId to logs. That said, I wish it wasn't limited to just these properties. From my experience building enterprise SaaS, you need more metadata for proper filtering: tenantId, operation, and others. With Winston, I typically create child logger instances and pass them around to ensure all logs contain the right metadata, but that workflow is pretty annoying.

Quick question out of curiosity: why does the example include an API key when initializing the logger? I couldn't find an explanation on the GitHub page. Some people might be put off seeing that in the first example, thinking the logger requires a paid subscription.

Recently, I also started using queues for integrating with legacy health care applications. Most of them run on-promise and they don't have incoming internet connection for security reasons. The strategy is to send a message to a queue. The consumer application uses short polling to process the messages and then it can call a webhook to share the status of the job. Do you also follow a similar approach?

Agree! In fact, I would appreciate more well written articles explaining basic concepts on the front page of Hacker News. It is always good to revisit some basic concepts, but it is even better to relearn them. I am surprised by how often I realize that my definition of a concept is wrong or just superficial.

The analogy could be: “Queues are the like the todos list of your team. The todo item (message) stays there until it is successfully completed. It can be handled by the producer (monolith) or it can be handled by someone else (microservices).”