Bart van Arnhem

LinkedIn, your "AI" autocompletion for commenting on posts just started giving me recommendations in Dutch. I never spoke Dutch. I probably never will. How about some unit tests in your features, huh? Quick reminder: AI models are *statistical* models. If they work 95% or 90% of the time, that's 5 or 10% of failures. Add those numbers to your calculations for bounce rate, churn, whatever... do the math. It's expensive. My philosophy is: always use AI models with a fallback for when they fail, and never make the whole feature completely useless, even when the AI fails. The cost for failing must be very low. In this case, your failure to even detect my language (you have them in my profile?!) cost you this post. Not sure how expensive that is, but hey, bad publicity and all.

4

1 commentaar

No human intervention allowed during deployment. Humans will eventually make mistakes. Deployments should be fully automated and should be executable, over and over again. Ideally in an incremental fashion. But also from scratch if needed in case of a disaster (mind the data). So how do you do that? First use 'infrastructure as code' to provision any shared infrastructure such as networking, security, communication or storage infrastructure. Ideally your infrastructure as code allows composition in its own right. We use Azure Bicep, which has support to load bicep modules from the azure container registry. This allows teams to maintain their own templates for e.g their subnet, while the network is still provisioned as a whole. The same goes for their storage, security and communication needs. Once the infrastructure is in place each composed host can be provisioned independently through its own deployment orchestration pipeline. Teams are free to choose the orchestration technology of their choice. Kubernetes, container apps, app services, service fabric, or whatever else they feel most comfortable with. Finally there is the data. Make a habit from automatically restoring and rebuilding your data on a regular basis Data on the inside: maintain backups and restore, as is. Data on the outside: no need to maintain backups. You should be able to rebuild this data from the original source of truth at all time. Rebuild it from scratch into a new version for every deployment containing schema changes. I personally prefer Event Sourcing for data on the inside. As the storage schema stays the same over time, it is very easy to backup and restore. While the concept of Projections allows you to rebuild the 'data on the outside' over and over again targeting new versions.

27

1 commentaar

AI isn't replacing programmers anytime soon... This morning, I'm sitting in the Springleaf Prata Place at Sunset Way getting ready to eat delicious prata for breakfast, but I manage a server that I needed to remote into. Chrome is acting up so I needed to get into the Azure bash shell. It's been awhile... Adding a new exception to the network security group via bash isn't that hard, but the syntax and the parameters are... forgettable. Enter my intern, AI and like all interns it is not perfect. The first script was 90% right but failed. I just needed to tweak one parameter, but that one parameter was... interesting. Here is the original AI suggestion: az network nsg rule update --resource-group $RESOURCE_GROUP --nsg-name $NSG_NAME --name $RULE_NAME --source-address-prefixes $(echo $UPDATED_PREFIXES | jq -c '. | join(" ")') And here was the fix that was needed, bringing back the old but always useful "sed" command into play to fix the text: az network nsg rule update --resource-group $RESOURCE_GROUP --nsg-name $NSG_NAME --name $RULE_NAME --source-address-prefixes $(echo$UPDATED_PREFIXES | jq -c '. | join(" ")' | sed 's/"//g') AI isn't replacing programmers anytime soon because you need to know how to code to figure out the mistakes the AI (intern) consistently makes. In addition, if the earlier part of the script the AI wrote had been better I wouldn't have needed the sed command at all. Anyway, AI is still helpful; I wouldn't have wanted to start this from scratch. My work is done, and the prata is delicious here! #happymonday #AITheIntern #futureofwork p.s. Security wise: - No, I'm not connected to the cafe wifi - Yes, I am using a VPN anyway - No, I don't open subnets to the server - Yes, I delete the IP address access when I'm done - Yes, I am using two-factor auth Picture of prata is mine, picture of code from Canva

112

19 commentaren

The Aardvark Platform provides "awesome libraries for interactive high-performance visual computing and graphics applications". Its #dotnet rendering engine started in #csharp in 2006, but is now almost entirely written in #fsharp! #dotnet

4

Discover a new way to manage releases and changelogs in Laravel! 🚀 This package makes it super easy to add new changelog items and update versions using simple CLI commands. Give it a try today!

17

🌟 The Right Architecture for Your SaaS Platform 🌟 When it comes to building a SaaS platform, the architecture you choose can make or break your project. And guess what? The choice isn’t black and white—it depends on various factors. 🤔 Let’s talk about monolithic architecture first. It’s like a cozy studio apartment where everything you need is in one space. It’s perfect for simpler applications, quick launches, and when you want to keep things straightforward and snappy. Plus, if your team is small and you’re looking to hit the market fast, going monolithic can be like a speedboat—swift and efficient. 🏁 Now, onto microservices. Imagine a sprawling mansion with different rooms for everything. This is the go-to for complex, scalable applications that grow with your user base. If you’re planning to frequently update features, need high fault tolerance, and love the idea of using a variety of tech stacks, microservices are your best bet. It’s like having a team of specialists, each handling their own department. 🏠 For SaaS development, your choice should be tailored to the specific needs of your project, the expertise of your team, and the complexity of the application you’re dreaming up. Whether you’re a startup or a seasoned enterprise, the architecture you choose is the foundation of your service. So, choose wisely! 🧐 What’s your experience with monolithic vs. microservices architectures? Drop your thoughts below! 👇 #SaaSDevelopment #SaaSSolutions #SoftwareArchitecture #TechTalks #TechChoices #BuildingTogether

4