Anders Reinhardt Hansen

#OpenAI - side note on a new feature - but huge impact #OpenAI just recently announced: https://lnkd.in/eS8t-ri4 A "strict" structured output in JSON - oki, so what you might think, it was somewhat possible before - but: - it is a reliable output with a JSON format only (from a given question/text/etc ) - we can now use our schema -> which saves hours of defining interoperability with other program outputs, customers, etc .. just throw your data at the #LLM and get your data format back - whatever JSON format you want. - it might make endless standardization meetings obsolete whenever two systems want to communicate - we all had that: I need 8 numbers for my order numbers - oh no - we should use 12, etc .. and the re-programming effort -> now: all gone This new feature has the potential to speed up innovation and avoid super boring meetings :-) #AIControlledByYou #Innovation #SpeedUp #NeverStopLearning #GenAI

18

Don't do what I call the Fake Debugging activities. It will only: • waste your valuable time • waste your attention • waste your energy Fake debugging activity is fake because you "do work, but substantially you don't get anything done". Here's what I mean: When you have bugs, and you don't have a systematic approach, you tend to tweak random parts of your code, and see if the bug vanished. I bet you've done this (in fact, I was also guilty of it too): you change some random part, "fix" the bug, only to have another bug pop up somewhere else. You think the variable temp1 is the problem, so you just change it to 0 and somehow the problem’s gone. Aaand you get another bug in another place. Congrats, you just moved the bug. It’s like sweeping trash from your bedroom and dumping it into your living room. Now, debugging can be made systematic and actually more enjoyable. You just need to be exposed to how debugging works, what tools to use, where to look. Unfortunately exposing yourself to debugging via trial & error will cost you too much time. Why don’t you just learn the bitter experience from someone who has done it before?

64

9 Comments

Transforming a Bot into a Distributed Real-Time Architecture in .NET Real-time distributed processing is often misunderstood in the .NET ecosystem. Many confuse asynchronous event-driven systems with real-time capabilities. Tools like RabbitMQ or Azure Service Bus excel in messaging, but they are not real-time. Even SignalR, while often referred to as "real-time," struggles with the ultra-low latency required in true real-time scenarios. ⚡ True real-time systems demand millisecond-level responsiveness, efficient communication, and streamlined deployment. This is where tools like ZeroMQ and NetMQ shine, offering brokerless, high-performance messaging. But let’s face it—real-time isn’t always the answer. Applications often require a mix of approaches to balance speed, simplicity, and maintainability. In a series of posts, I’ll walk you through the journey of transforming a monolithic bot into a distributed architecture. Together, we’ll explore: 🚀 Distributed orchestration with Aspire 🔍 Observability with OpenTelemetry 🔐 Security with Identity ⚙️ Serialization with Protobuf 🏗️ Clean architecture using SOLID principles and Mediatr 🌐 Integrating SignalR and secure Minimal APIs for scenarios that don’t need true real-time processing And to our friends using React or Angular: while Node.js might limit your access to the true real-time world 🚧, don’t worry—when we cover quasi-real-time solutions like SignalR and Minimal APIs, the door will be wide open for you too 🚪. 💡 Follow me to join this deep dive into distributed architectures and see how .NET can scale your applications to the next level! #RealTime #DistributedSystems #DotNet #NetMQ #ZeroMQ #Aspire #OpenTelemetry #Identity #Protobuf #Mediatr #Architecture

5

1 Comment

https://lnkd.in/ehf4_RK8 NDC Conferences always has interesting videos. This one is worth watching if you are a software architect. It gives a different perspective about software development and software architecture in general.

2

Traditionally, API management platforms combined different features (like gateways, analytics, and developer portals) into one big package. But this approach has limitations - it isn't very flexible or scalable. Shift toward unbundling API management allows organizations to pick and choose the specific components they need. This way, they can create customized solutions that fit their requirements. However, this approach also comes with challenges, such as dealing with complex integrations and managing different vendors. Feel free to explore the full article for more in-depth insights! https://lnkd.in/eag23q3s #APIDesign #APILifecycle #APIManagement #APIs

5

3 Comments

I keep hearing the idea that pull requests are bad and that developers shouldn't do them. Well, to me, most of these arguments are somewhat of a straw man variety and they encourage throwing the baby out with the bathwater. Pull requests aren't the problem. Pull requests won't prevent you from doing continuous delivery. The problem is pull requests that take a long time to review and approve. This is the thing that will prevent you from doing continuous delivery. But this is a very avoidable problem. It doesn't have to be this way. In our team, PRs don't normally take long to review and things in the trunk are being updated regularly. So it was in my previous team in my previous place of work. I worked in at least three different teams where we would try to get rid of PRs to see what will happen. In all of those cases, we had to get back to doing PRs because removing them caused more problems that we were trying to solve by removing them. I get it. It may work for some teams that do pair programming all the time, which I see as the only way to keep the code quality up without the PRs. However, this approach will not suit every company and every developer. Many developers I know will find it exhausting having to pair-program all the time. Even when you pair program, PRs still have their use. Just before you push all those commits you created, you can create a PR to view all the challenges to make sure you haven't missed anything. You will not only be able to verify that no temporary code changes go in, but you will also create a nice audit trail of who made the change and who reviewed it. I even sometimes create a PR for my own changes because because it's a tool that makes a pre-push verification very convenient. PRs are just a tool. Just like any other tool, it can either be used or misused. It only causes problems when it's misused and not when it's used properly. This tool may not be useful to you, in which case you may discard it. But you may also find out that it's not as useless as some people say it is and it won't stop you from doing continuous delivery, as these people say.

38

26 Comments

🚀 Stop the Tab vs. Spaces Wars! Use EditorConfig: Your Lint Equivalent for .NET! 🚀 Are you a .NET dev trying to mimic your JS pals' code formatting? Look no further! EditorConfig has your back – it's like having a built-in lint for .NET, but with extra sass! ✨ End Formatting Fiascos ✨ 🔧 Consistency: Wave goodbye to the chaos of mismatched styles. ⚡ Efficiency: Spend less time on formatting, more time on cat memes. 🌐 Compatibility: Works across .NET like a charm – no more cross-platform nightmares! Get Started: Embrace EditorConfig: It's your coding standards' fairy godmother. Define Your Style: Tabs, spaces, braces – it's all up to you! Enjoy the Laughs: Because consistent code is a joke no more! Join the .NET elite – use EditorConfig and put an end to the formatting fracas! Read more: https://lnkd.in/et2JhKbp #EditorConfig #CodingStandards #DotNetDazzle

3

𝗠𝗶𝘀𝘁𝗿𝗮𝗹 𝗟𝗮𝗿𝗴𝗲 𝟮 - 𝗻𝗲𝘄 𝗟𝗟𝗠 𝗿𝗲𝗹𝗲𝗮𝘀𝗲 Another model was released yesterday!! #𝗠𝗶𝘀𝘁𝗿𝗮𝗹 𝗟𝗮𝗿𝗴𝗲 𝟮 - I tested it, and it is high quality. I never programmed with the React framework, but I got a nice result, and it worked out of the box. Oki, I need to specify my requirements, like color and additional fields, but for a one-shot prompt, it's not too bad! But read the announcement by yourself: https://lnkd.in/gSgJZDVX and if you want to test: register here: https://chat.mistral.ai/ And of course, it already runs on #Azure: https://lnkd.in/gy2rwnPX #MistralAI #Mistral #MistralLarge2 #AIControlledByYou #GenAI #NeverStopLearning #TheFutureIsNow

5

I recently had a conversation with Mariia Vain, a Staff Software Engineer at AgencyAnalytics, about one of the most critical skills for Staff+ engineers: prioritization. As Mariia pointed out, there will always be countless things you could be fixing, improving, or building. The challenge isn’t in finding what to work on but in narrowing it down to the 2-3 things that will have the most impact over the year. This can involve engaging in deep conversations and interviews with engineers across different areas, identifying opportunities where solving one issue could have rippling effects across teams. Using data like performance metrics, security reports, and reliability stats to back up these decisions can also make a stronger case for why a particular direction is chosen. Setting up recurring meetings with focused teams—like a backend council or guild—can help align on priorities and gather insights from those closest to the work. At the end of the day, it’s up to the Staff+ engineer to make the final call and communicate this clearly to engineering leadership. While ensuring that all voices are heard, sometimes you need to disagree and commit in order to move forward. How do you navigate prioritization in your role? I’d love to hear your strategies and experiences! If you're a Staff+ Engineer I'd love to connect: https://lnkd.in/gKT7unhC

9

GPT-powered software agents are heralded as the next step beyond chatbots, but have only partly lived up to the hype so far. 👿 Currently agents tend to be fail due to pile-up of errors in subprocesses. For example a five-step process for an agent with individual error rates of, say, 5% lead to overall error of 26,4%. That is without taking into account that all you do to make this better, tends to make the agents *fragile*. That is, they become prone to failing due to model updates or data drift for instance. Improving sub-processes at some point always involved human-annotated data, which doesn't really scale - up till now. 😯 In this very recent interesting paper by google deepmind, they seem to have found a way to potentially improve agentic workflows *without the need for human annotation*. If this approach works beyond the context they have tried this approach in the paper (math problems), this makes agents much more feasible then they are now! 😀 Incidentally the key idea is to provide much more detailed feedback to the model beyond a simple 'works' or 'doesn't work'. I find this type of feedback tends to work better for humans too :). #AI #AIImpact #Agents

10

Here's your map to much faster (and actually enjoyable) debugging: * Know the type of errors * Know the common root causes * Know your tools * Know various bug species

78

4 Comments

I had some time to spend and make contributions to the WinGet open-source repositories. This also gave me the chance to grab my notes again and publish all the work into a blog post. In this post, you will learn that .NET tools are not only for developers and how both can install it in a unified way. Check it out: https://lnkd.in/eVjZTUHr #dotnet #powershell #dsc #blog #devops #sdk

3

Sometimes when debugging, what you need isn’t another breakpoint in your firmware. Sometimes, what you need is just a little break from whatever you’re currently doing. In fact “Give up now, and try again later” can be surprisingly good advice. There are many forms of break: sleep, away from keyboard, eating well, doing chores, talking to your friends/coworkers, even talking to a duck (yes, it’s real. It’s called Rubber Duck Debugging method, Google it). If you’re too close to the problem you’re trying to solve, you can lose sight of the big picture. Your brain may get locked into analyzing only what's in front of you, missing the entire picture of your firmware. Giving yourself a break will break that vicious cycle. Just give up, and try again tomorrow, maybe the dream in your sleep will give you some hints, just like what I experienced. What? You’ve never experienced that? It’s like when you sleep, you dream about your problem, and suddenly you know where to look, and what to do. Upon waking up, you apply that solution and it’s just plainly working, flawlessly. Little did you know, when you sleep, your brain doesn’t stop processing your thoughts. Your brain enters creative mode (instead of pure analytical mode) to solve the issue. Sometimes creativity can solve the issue. It’s an effortless experience as if you have your brain think for you without you ever having to think. Repost if find this useful ♻️

108

7 Comments

Knowledge Sharing: Day 22 Breaking change if you are planning to upgrade your compileSDK to Android 15 or higher 📢 If you use Kotlin's list.removeFirst() or list.removeLast() extensions in your Android app, then, after bumping compileSdk to 35, your app will crash at runtime on older Android versions. #android15 #android #behaviour #development Kaara

34

3 Comments

☕ The Coffee-Driven Code Review Manifesto: A Sleep-Deprived Guide to Excellence [Everyone talks about clean code, but let's be honest - most of our best reviews happen after that third espresso shot] 🌅 6 AM: First Commit Code looking pristine Tests all green Documentation spotless Reality: Haven't written a single line yet ☀️ 9 AM: The Morning Stand-up Revelation "Wait, did I just promise to deliver this by EOD?" Frantically opens IDE Types while drinking coffee Spills coffee on keyboard Git commits anyway 🌮 12 PM: The Lunchtime Code Review PR Comment: "Interesting choice of variable names. Is 'pizzaTime' really the best name for a payment processing function?"  Me: "I was hungry when I wrote that..." 🌙 5 PM: The Final Push git commit -m "Fixed everything (hopefully)"  git push origin please-work  git prayer --recursive 📊 Our Revolutionary Metrics: Bugs Found vs Coffees Consumed (1:1 ratio) Time Spent Reviewing vs Time Spent Making Memes About Code Number of "LGTM" Comments That Actually Meant "I Trust You” 🎯 Pro Tips for Sleep-Deprived Reviews: If the code works on the fifth try, it's probably production-ready Comments like "Magic. Don't Touch." are perfectly acceptable documentation If you can't explain your code, blame it on the keyboard 🤔 The Real Code Review Checklist: Does it work? No one knows why it works But it works Ship it! 💭 Question for fellow night owls: What's your record for most consecutive hours staring at a PR before realizing you were looking at the wrong branch? #CodingLife #TechHumor #SoftwareEngineering #DeveloperLife #CodeReview #CoffeeDriver Development #TechMemes

2

Just blogged: Introducing Blobify - A .NET Global tool that archives (moves) files from a local folder to an Azure Blob Storage container. https://lnkd.in/d_knViBi #azure #storage #dotnet #blob

12