Francis Martens 🇺🇦

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

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

As the cost of code generation goes down because AI can do it faster and less expensively than a human, the cost to benefit ratio of adopting agile/xp practices favors adopting them. We know that AI doesn’t generate the best code sometimes but using tests/types as a specification mechanism reduces the risk that the generated code doesn’t meet the requirements. Being agile is all about fast feedback loops so why slow down the process by forcing a human to validate the generated code afterwards to assure it meets the spec? Don’t like the code it generated? Write another test/type spec to guide the AI in the direction you want it to go. Code is too slow? Write a test to specify the behavior and let AI fix it. Found a security vulnerability? Write a test to reproduce it and let AI fix it. What is stopping your teams from using this flow to more effectively use AI to generate value generating code? I’ve been researching this in my spare time building out an agentic AI system for balanced teams. You can follow athe journey here: https://lnkd.in/e85pUdKz

8

8 Comments

Learning some interesting stuff on Web and API testing with Katalon Studio during this - https://lnkd.in/e2K6Prm8 ! Thanks to the awesome community for sharing their insights. #kataloncommunity #askkatalonanything"

6

1 Comment

🚀 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

The more I work on the release, the more I wonder: Is this a Major or Minor upgrade 🤔? Another way to mark a release on the web is by using a calendar date or CalVer (https://calver.org/). This method looks easy and removes the guessing game for Major vs. Minor. You pick the format and follow it.

1

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

16

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

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

Test-driven development evangelists often complain that TDD isn't being adopted quickly enough. However, they themselves are often the biggest reason for it. I get it. If you are enthusiastic about TDD, of course you would want people to know how good it is! However, sometimes you should stop and think about how people will perceive your message, even if it was made with good intentions. When you say that you can't write any large-scale software without TDD, experienced engineers who wrote tons of great software and never used TDD will think you are either trying to gaslight them or you don't know what you are talking about. And there are many examples of great software written without TDD. When you say that you are doing it wrong unless you follow TDD, developers who never used TDD will see it as an attempt to question their professional competencies. Some may even refuse to have anything to do with TDD out of spite upon hearing this. When you say that TDD has been objectively proven to be a superior methodology over alternatives, those who come from a traditional science background will find at least a handful of peer-reviewed studies proving otherwise. I know at least two of these. When you advocate for extreme practices, such as saying that you must always follow TDD and your code coverage must always be 100%, TDD will be perceived as some sort of a quasi-religious cult rather than an engineering practice. And engineers tend to be too rational to willingly join a cult. Don't get me wrong. I do think that TDD is useful. I even teach it sometimes and I encourage developers to at least try it. But if you want to promote it, the above examples are not how you do it.

45

35 Comments

"A component should only reference Dependencies that have an expected lifetime that’s equal to or longer than that of the component itself. Captive Dependencies are a common problem [...]" Dependency Injection Principles, Practices, and Patterns by Steven van Deursen and Mark Seemann I am curious how often you think about captive dependencies. Honestly, this is not the first thing that crosses my mind when working with DI or work with dependencies in general.  #softwaredeveloper #softwareengineer #softwarearchitecture #softwaredesign #developerlife #cleancode #softwaredevelopment #softwarecraftsmanship #qualitycode #learnsomethingnew 

4

1 Comment

Curious how to optimize your role as an ASPICE consultant in an engineering team? Let's dive in! 🚀 10 Pitfalls ASPICE Consultants Should Avoid with Engineering Teams 🚀. My Personal Favourite is the eighth on the list... As an ASPICE consultant, driving process improvement in engineering teams is a rewarding challenge. However, to truly make an impact, it’s crucial to steer clear of these common pitfalls: - 𝗜𝗺𝗽𝗼𝘀𝗶𝗻𝗴 𝗦𝗼𝗹𝘂𝘁𝗶𝗼𝗻𝘀: Collaboration over imposition! Work with the team to uncover the best solutions. - 𝗜𝗴𝗻𝗼𝗿𝗶𝗻𝗴 𝗧𝗲𝗮𝗺 𝗜𝗻𝗽𝘂𝘁: Every team member’s insight counts. Value their experience and feedback. Being Overly Critical: Balance is key. Highlight strengths while addressing areas for improvement. - 𝗨𝘀𝗶𝗻𝗴 𝗝𝗮𝗿𝗴𝗼𝗻: Clarity over complexity. Ensure everyone understands the conversation. - 𝗡𝗲𝗴𝗹𝗲𝗰𝘁𝗶𝗻𝗴 𝗖𝘂𝘀𝘁𝗼𝗺𝗶𝘇𝗮𝘁𝗶𝗼𝗻: One size doesn’t fit all. Tailor processes to fit the team’s unique context. - 𝗥𝘂𝘀𝗵𝗶𝗻𝗴 𝘁𝗵𝗲 𝗣𝗿𝗼𝗰𝗲𝘀𝘀: Patience pays off. Sustainable improvements take time and careful implementation. - 𝗢𝘃𝗲𝗿𝗹𝗼𝗼𝗸𝗶𝗻𝗴 𝗧𝗿𝗮𝗶𝗻𝗶𝗻𝗴 𝗡𝗲𝗲𝗱𝘀: Don’t assume knowledge. Provide the necessary training and support. Focusing Solely on Documentation: Processes are about people, not just paperwork. Prioritize implementation. - 𝗜𝗴𝗻𝗼𝗿𝗶𝗻𝗴 𝗖𝘂𝗹𝘁𝘂𝗿𝗮𝗹 𝗗𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝗰𝗲𝘀: Be mindful of cultural and organizational nuances that shape team dynamics. - 𝗙𝗮𝗶𝗹𝗶𝗻𝗴 𝘁𝗼 𝗙𝗼𝗹𝗹𝗼𝘄-𝗨𝗽: Change doesn’t end at implementation. Regular follow-ups ensure long-term success. By avoiding these pitfalls, you can foster a collaborative, effective, and dynamic relationship with your engineering teams. Let’s drive meaningful change together! 🌟 #ASPICE #Engineering #ProcessImprovement #Consulting #Leadership #Teamwork #ContinuousImprovement What strategies have you found effective in fostering collaboration with your engineering team? Share your experiences! 🌟 Do you agree with these pitfalls, or have you encountered other challenges as an ASPICE consultant? Let’s discuss! 🚀 #ReachifyMe

14

1 Comment

Book "Learn Java with Projects" by Dr. Seán Kennedy and Maaike van Putten is really good piece of fun and technology, combined with agile dinosaur, probably T. Rex LTS 21 :) If you are starting with Java, that's good place to start, if you feel like you want to advance, Chapter 14 is where I am at and enjoying simple yet powerful examples of lambda expressions and next one, primitive streams, Can not wait to see more advanced topics like breakdown of code of Llama-3 java version, written using Vector API.

22

2 Comments

Our colleague Sebastiaan Koot has written a blog about testing: "Beyond the illusion of test coverage". "Have you ever spent hours on creating unit tests in order to reach a unit test coverage above 80%, only to discover in production that your software still harbours critical bugs?" "Discover the profound shift in unit testing philosophy that’s turning heads in the front-end and back-end communities." Read the full blog post here: https://lnkd.in/eXdznSuj #QualityAssurance #Testing #Blog

7

Nowadays, I am again on the process to build different OSS tools for my team. First one is kinject (Dependency Injector): It is a simple wrapper on InheritedWidget, that allows you to inject your dependencies on the fly. It has inter-dependencies and observer features. https://lnkd.in/eGJvHgDV The second one is kanza_lints. (Simple linter package for team) I have checked all Dart linter rules and collect some of them in the following package. https://lnkd.in/eF62TA5H #flutterteam #ossdevelopment #linter #di #dependencyinjection #opensource #flutter #dart #inheritedwidget

16

“Systems Engineering tools look like they are from the 90s!” “And even worse, they feel like it.” I hear that a lot when talking to potential customers and users. Many people don’t like using the Systems Engineering tool of their companies. And not only that… It is very hard to convince other domain engineers (e.g. hardware or software developers) to utilize the tools. So finally, the Systems Engineer might end up copying information from anywhere to the tool. However, this is a waste of time and also frustrating. Can you relate to that? Let me know in the comments. But it doesn't have to be this way! Tools can have easy accessibility, an appealing UI, and a simple workflow to attract your fellow engineers. That’s exactly our goal with Spicy SE. Want to know more? Get in touch for more information.

48

22 Comments