Luc van Donkersgoed

I published my first blog post about statically deobfuscating the Lazy Importer. Please check it out and don't forget to let me know your thoughts. Blog Link: https://lnkd.in/eW-9QV_2 .

4

Alright, it's a little behind schedule, but v4.15.0 of Nebula Logger is now available! This release brings several new features & bugfixes to the managed package (as well as few small enhancements to the unlocked package). Some of the highlights for anyone upgrading from v4.14.0 to v4.15.0: Key Features ✅ OmniStudio Logging: Built-in support to easily log from OmniStudio, a much-requested feature! ✅ Loosely-Coupled Dependencies: ISVs and consultants can now seamlessly leverage Nebula Logger without requiring it as a dependency. ✅ Enhanced JavaScript Logging: A new getLogger() function makes JavaScript logging even easier & provides improved support for logging in LWC lifecycle events Other Enhancements ℹ️ Dynamic highlights and related list components for flexipages, leveraging Salesforce's Winter '25 features. ℹ️ New list views and formula fields on logging objects, improving usability and visibility. ℹ️ Apex updates for better HttpRequest logging, async context handling, and more flexible LogEntryEventBuilder methods. ℹ️ Optimized internal performance and streamlined sf CLI commands to align with Salesforce’s latest standards. Bugfixes 🐞 Enhanced regular expressions for data masking sensitive info (e.g., SSNs). 🐞 Fixes to Apex context handling, long code snippets, and visibility rules on console tabs. More details are available in the release notes: https://lnkd.in/eBKVkfZr #Observability #Logging #Salesforce #SalesforceAdmins #SalesforceDevelopers #SalesforceArchitects #OpenSource #Apex #OmniStudio #ISV #LWC

99

7 Comments

Being in this profession for almost 28 years, I like to think I've seen the evolution that developers go through. In fact, I've experienced it firsthand and made my fair share of mistakes. I don't think terms like junior, medior, and senior make a lot of sense anymore, though. I've seen aspiring developers whose technical skills and breadth of knowledge far exceeded those of developers with 15+ years of experience. That’s why it’s so important not to judge a book by its cover. Nonetheless, experience is something to take into account when working with developers on your team.   In general, developers fresh out of school have a lot to learn. The gap between what they are trained for, and the reality of our profession is simply too big. They'll be introduced to many new techniques, so giving them overly strict guardrails isn't prudent. Even those who are self-educated need some guidance. Over time, you'll notice that they start to question those guardrails and offer suggestions that show they’re becoming more aware of the rationale behind them.   This is the point where you need to remove the guardrails to give them more room to explore and fail safely. This is also the fun period. You'll have great discussions about why certain patterns or principles make sense in particular scenarios—and when they don’t. Ironically, I've learned that developers with 15-20 years of experience are often the most dogmatic and the hardest to work with. And obviously, those with 25 years or more know exactly what they're doing, right… Or not? 🫣 #lessonslearned #consultancy #avivasolutions #carreerpath #softwareengineering

16

Today's Tip - API for GraphQL in Microsoft Fabric Learn how to share data currently stored in a Microsoft Fabric warehouse using a GraphQL API along with the steps to set this up. Author: Koen Verbeeck >>> https://lnkd.in/e2gQ-zk6 #sql #sqlserver #microsoftsqlserver #mssql #mssqlserver #microsoftfabric #graphqlapi

2

My new open source project is called "erwtensoep" (Dutch for "Pea soup") and it contains a helpful subcommand that yields my favorite recipe: ``` ❯ make && bin/erwtensoep recipe go build -o bin/erwtensoep cmd/*.go Ingredients: 500 gram of split peas (dried are fine) 2 decent sized boneless pork chops 200 gram of panchetta 2 liter of water 2 medium sized onions 2 leeks 900 gram celeriac 180 gram carrots 7.5 gram of fresh thyme 2 dryed bay leaves 2 beef Kielbasa sausages All of this can be obtained at the Albert Hein super market in the Netherlands or at the Wholefoods in the US. Step 1) Bring the peas to a boil along with the pork shoulder chops, pork belly strips, and water. Let it simmer on low heat for 30 minutes. Regularly skim the foam from the soup and stir well. Frequently scrape the bottom of the pan to prevent the soup from burning. Step 2) Meanwhile, finely chop the onion. Wash the leek and cut it into thin rings. Peel and dice the celery root into 1 cm cubes. Peel the carrot, cut it lengthwise into quarters, and then into 1 cm cubes. Strip the thyme leaves from the stems. Step 3) Add the onion, leek, celeriac, carrot, bay leaf, and thyme to the soup, and let it simmer gently for 30 minutes with the lid on the pan. Season with pepper and, if desired, salt. Step 4) Remove the pork shoulder chops and pork belly strips from the pan and cut the meat into small cubes. Slice the smoked sausage and stir it into the soup along with the meat. Let the soup simmer gently for another 15 minutes. Divide the soup into bowls and serve. Recipe courtsey of https://lnkd.in/eExnX_sC. Translation by ChatGPT 4o. ```

6

2 Comments

♦ Wrong mindset as a developer: “Why do I need to help unblock others? They should be able to take care of it on their own. I will focus on my own work.” ♦ Right mindset as a developer: “My team is blocked on this particular issue. I read this helpful blog yesterday. I will forward this with a summary. I think it will help a great deal, at the end of the day, we need to ace this project” Great software is always a collaborative effort. The sooner you understand that, the better you will do as a developer. 

127

5 Comments

🚀 Join us for an exciting live session on 𝑴𝒐𝒃𝒊𝒍𝒆 𝑨𝒑𝒑𝒍𝒊𝒄𝒂𝒕𝒊𝒐𝒏 𝑴𝒐𝒅𝒖𝒍𝒂𝒓𝒊𝒛𝒂𝒕𝒊𝒐𝒏 with 👾 Tjeerd In 't Veen https://lnkd.in/eg2hcCkG Are you looking to deepen your understanding of modularization and its critical role in modern app development? Don’t miss out on this insightful discussion where we'll cover: 🔍 𝐔𝐧𝐝𝐞𝐫𝐬𝐭𝐚𝐧𝐝𝐢𝐧𝐠 𝐌𝐨𝐝𝐮𝐥𝐚𝐫𝐢𝐳𝐚𝐭𝐢𝐨𝐧: What does it mean to modularize a mobile app, and why is it crucial for today’s development landscape? 🔍 𝐁𝐞𝐬𝐭 𝐏𝐫𝐚𝐜𝐭𝐢𝐜𝐞𝐬 𝐟𝐨𝐫 𝐂𝐨𝐝𝐞 𝐑𝐞𝐯𝐢𝐞𝐰: Discover effective strategies for conducting code reviews in feature modules, ensuring high-quality code and smoother collaboration. 🔍 𝐁𝐚𝐥𝐚𝐧𝐜𝐢𝐧𝐠 𝐋𝐞𝐠𝐚𝐜𝐲 𝐚𝐧𝐝 𝐍𝐞𝐰 𝐌𝐨𝐝𝐮𝐥𝐞𝐬: Learn how to progressively transition from legacy systems to a modular architecture while continuing to deliver new features. 🔍 𝐌𝐞𝐫𝐠𝐞 𝐂𝐨𝐧𝐟𝐥𝐢𝐜𝐭𝐬 & 𝐕𝐞𝐫𝐬𝐢𝐨𝐧 𝐂𝐨𝐧𝐭𝐫𝐨𝐥: Get practical tips on managing merge conflicts, version control, and maintaining consistency across different modules. Whether you're a seasoned developer or just starting out, this session is packed with valuable insights that can take your skills to the next level. 🕗 Time: 1 PM (Paris, France) 🇫🇷 / 1 PM (Amsterdam, Netherlands)🇳🇱 📍 Location: Only on Swift Academy 🇹🇳 See you there, and may the code be with you! ----------------------------------------------- 🚀 Support my work if you'd like! ☕️: Buy Me a Coffee https://lnkd.in/ei7cVejt 📨 Don't forget to subscribe to the newsletter of our site Swift Academy - Modern Mobile Development. https://lnkd.in/eUvvBk46 🎥You can also subscribe to my Youtube channel https://lnkd.in/eHKCft-E #MobileDevelopment #Modularization #CodeReview #VersionControl #AppDevelopment #TechTalk

36

Resharing this as endorsement - tech compensation is *at least* bimodal, and likely trimodal (depending on your location). This article is a great read for all engineers, to help explain the market and know their worth. I saw this firsthand in my job search last year. There were local companies in the Chicago area that capped out at ~120-160k for senior roles, and then larger firms (especially in finance and tech) that reached ~180-200k. But it wasn’t until I got into interviews with large public tech companies that I saw base salaries of 200k+ advertised, and total compensations reaching from 250k to 500k and up! Gergely Orosz's articles on this topic have been a huge help to me. If I had stuck to what I saw in the local market, I would've drastically limited my options and short-changed myself. The surge in remote work has made it more possible than ever to work for some of the best companies in the world, and even with lots of return-to-office happening, there are still plenty of great and well-paying companies out there. So if you're on the market (or thinking about it), keep this in mind! 🚀

6

In 2021, I tried to understand how tech compensation really works - at least in the Netherlands. I published "the trimodal nature of software engineering salaries" article. Time for an update: Back then, based on ~100 data points (and my own experience as a hiring manager,) I suspected that there are three, distinctively different compensation bands for software engineers: 1. Local companies (Tier 1) Most local businesses that benchmark to the numbers on most salary comparison sites. They usually offer close to – and sometimes slightly above – what government positions advertise for senior engineering roles. 2. Ambitious local companies (Tier 2) Startups, scaleups, and more ambitious local companies that want to hire and retain the best people, locally. 3. Companies benchmarking across a region (Tier 3). Big Tech companies, hedge funds and scaleups that hire across regions, frequently hire from abroad, and often compete with fellow Big Tech giants for talent. Curiously, the third tier (Tier 3) seemed to be missing from most public compensation data sources. Since publishing the model, I've both received lots of feedback suggesting it applies to the US, Canada, UK, Europe and many other countries. I've since then also collected far more data points, manually tagged companies by tier, and can finally confirm that yes, this model holds up when compared with actual data. Here is the longer analysis (and the stats behind this graph below) in yesterday's The Pragmatic Engineer issue. Read it here: https://lnkd.in/e7FV4gBB

708

43 Comments

My "Applet Runner" plugin has reached 20,000 downloads on the NetBeans IDE. 🎉 https://lnkd.in/eJZYVrUH #NetBeans #NetBeansIDE #java #plugin #applet

16

🚀 Exciting News for Developers! Join us on Friday, November 15th for an in-depth session on the upcoming new major version of the Fluent UI Blazor library. This release brings groundbreaking Web Components and major architectural innovations to take your web development to the next level. With Vincent Baaij https://www.dotnetconf.net 🔍 What to Expect: Overview of New Features: Explore the latest enhancements, including cutting-edge Web Components. Architectural Changes: Understand the performance, scalability, and maintainability improvements in the new architecture. Migration Guide: Yes, there will be breaking changes! But we’ll guide you with practical tips and best practices to smoothly transition your projects. Hands-On Demos: Watch the new features in action with live coding demonstrations. 📅 Don’t miss out! Mark your calendar and get ready for this transformative session. #Blazor #FluentUI #WebDevelopment #WebComponents #Architecture #Migration #LiveCoding #TechTalk #WebInnovation

38

2 Comments

Last Sunday in my #datapains post, I showed how to deploy Trino with Helm! I now also upload a video together with this post. https://lnkd.in/entAFH4E #trino #kubernetes #minio #delta #dataengineering

23

I don’t know who needs to hear this, but TDD is not about testing, it’s about designing great, maintainable software. Up to 90% of the effort spent on software is in maintenance. Anything we can do to reduce that cost has massive long-term benefits. TDD forces good modular design upfront. It makes your codebase easier to work with, allows for faster development over time, and gives you the confidence to make changes without fear of breaking things. The fact that you get good tests out of it? That’s just the cherry on top. (inspired by my comment on John Crickett's post)

638

336 Comments

My talk at #FrontendNation is available in full length on youtube. Let me know what you think.👇🏼 https://lnkd.in/e_GBNXTv I will post a link to an automation guide of my talk as comment. In this blog post you can also find the slides. ✅ #a11y #FrontendDevelopment #wcag #WebAccessibility

32

2 Comments

Lost Dutchman Software's most recent project is released under another company name, and I can't really talk about it here. I can share this short script I wrote to check every line of dialog in the game and print out when a word appears twice in a row. When my partner is writing they often type the same word twice if they pause to think while typing. Usually its words like 'to, and, for, or, so'. Then when they re-read their script they auto correct it in their head and just don.t see the mistake. This code tells them which file has 2 words in a row and surrounds the word in square brackets so they cannot miss it. Example Below: Double found on /Users/sgundaker/tcm/game/pronouns/pronoun_setup.rpy Line 51: ## These are the strings you will set the `pronoun` variable [to] [to] change the The script is available here - https://lnkd.in/gdCgMr32

7

Last year, when ASML moved to Kubernetes, the steep K8s learning curve posed a major challenge. As a Java Spring Boot developer, I dug deep into Kubernetes. While the documentation is comprehensive, it’s overwhelming for developers who don’t need every detail. After months of learning, filtering, and practice, I cleared the CKAD certification. Six months ago, I began writing a 21-article series to help developers avoid that struggle. It’s packed with practical, hands-on labs tailored for developers. Topics Covered: 1️⃣ Lab 0: Introduction to Kubernetes (https://lnkd.in/eTHDuWKg) 2️⃣ Lab 1: Pods (https://lnkd.in/eDZm7CGi) 3️⃣ Lab 2: Deployments (https://lnkd.in/e9PJC2Sj) 4️⃣ Lab 3: Commands & Arguments (https://lnkd.in/ejS5W5ag) 5️⃣ Lab 4: ConfigMaps (https://lnkd.in/e8yUHnyf) 6️⃣ Lab 5: Secrets (https://lnkd.in/etWCnMxQ) 7️⃣ Lab 6: Liveness & Readiness Probes (https://lnkd.in/eMwd_veH) 8️⃣ Lab 7: Startup Probe (https://lnkd.in/eiZhAWF8) 9️⃣ Lab 8: Jobs (https://lnkd.in/e_arVb5U) 🔟 Lab 9: CronJob (https://lnkd.in/eB66EtUj) 1️⃣1️⃣ Lab 10: Memory Resources (https://lnkd.in/eAjQ2fyZ) 1️⃣2️⃣ Lab 11: CPU Resources (https://lnkd.in/evDTrFCH) 1️⃣3️⃣ Lab 12: ClusterIP service (https://lnkd.in/e3TUFKeg) 1️⃣4️⃣ Lab 13: NodePort service (https://lnkd.in/ezY598p8) 1️⃣5️⃣ Lab 14: Ingress: (https://lnkd.in/epSJ83vV) 1️⃣6️⃣ Lab 15: Namespaces (https://lnkd.in/eAUC5Dpu) The rest of the topics are listed in the first comment. Learnk8s

55

4 Comments

I've been thinking (a dangerous thing to do) the biggest reason people give me against TDD mostly translates to: "I rather focus my efforts and attention in the code" and therefore one would think they would be able to deliver business value quicker. that's a very dangerous way of thinking, there's so many issues with this reasoning. if you write code that doesn't have tests from the API point of view (and if you do then most likely you are writing your tests first, obviously doing TDD) then the following is gonna happen: 1 - you will end up with more defects in your software 2 - you'll need a bigger QA team 3 - you will need better specifications 4 - as a result of 2 you increase communication effort which translates to more meetings 5 - you'll release more infrequently however the worst is still to come, you'll end up in a technical environment that is not excellent and why not strive for excellence? when doing TDD and TBD (trunk based development) with pairing or mobbing, you can make the complexity of software easier to manage: 1 - you focus on the problem domain, clarify requirements and discover there are a bunch of cases we don't know yet, you focus on the things you do know. 2 - you translate those requirements into a testable specification, I've created DSLs (domain specific languages) in #elixir and that was a joy. 3 - you write the code. 4 - you deploy to Prod. 5 - you observe the error rate by introspecting your system. the art of software really comes into problem discovery, why wouldn't you want to use TDD to discover your problem?

35

6 Comments

How many of your supposedly internal-only backends are serving critical end-user traffic? Probably more than you think! Most frontend services have many transitive dependencies, and understanding these dependencies becomes increasingly difficult as your system grows in scale and complexity. As a result, it becomes exceptionally tricky to ensure that internal-only backends are fully isolated from end users. Google uses a common infrastructure platform for almost all of its services, internal and external; this provides for a message-passing mechanism common to all of these services. One outcome is that systems engineers can build accurate dependency maps of services; and that we can ensure new services only depend on other services at the same level or higher in the dependency stack. Risky dependencies — in this case, dependencies which place internal-only backends on the critical path for end users — can be a source of major production outages, because the internal-only backends do not generally have necessary reliability or safety guarantees. For example, you might have an externally-visible service that requires high levels of availability and performance, and this system has an indirect dependency on a backend with no availability or performance SLOs. At Google, we found success preventing major and huge outages by clustering services into categories with distinct properties, clear perimeters, and limited blast surfaces. The properties will depend on the guarantees we want to enforce. In this article, we use Google Maps to demonstrate how risky dependencies proliferate in complex systems, and then showcase how clustering Google Maps services into just two categories ("Internal" and "External") can prevent major and huge serving outages. We also outline how OpenTelemetry is used to identify violations of this clustering, which can be fixed before the violations cause a major serving outage. This article is based on a talk by Pierre Theo Klein at SREcon EMEA, which you can see here: https://lnkd.in/e_cyxv_A. Jennifer Steiner Klein collaborated on turning the talk into an article.

39