Tiago Dall'Igna

Hello everyone, how are you? Today, Tiago Nascimento Souza and I had the opportunity to speak to the platform engineering community about our journey in building our IDP. This journey started in 2015 and we have continued to evolve up to the present day. If you couldn't attend the webinar, here is the YouTube link: https://lnkd.in/dF4mpHgF #platformengineering #devops Sicredi Platform Engineering

77

New post in the blog! 🥊 In this post, the author talks about his experience participating in the second edition of the "Rinha de Backend" using Erlang and Elixir. https://lnkd.in/dWfQZHSt #Blog #Codeminer42 #Elixir #Erlang

19

1 Kommentar

Imagine you’re trying to migrate to Serverless as fast as possible, but have all HTTP servers in docker container images. Where would you start? Felipe Gené de Faria has an easy solution to lift and shift to AWS Lambda in our newest article:

11

In this episode, José Nuno Oliveira talks about how Haskell is the perfect language to introduce programming to all sorts of audiences, why it is important to start with Haskell, and how the programmers of the future have been learning Haskell for several years already! https://lnkd.in/gQHPXE43

29

Nowadays, we frequently hear about TCA (The Composable Architecture). Here is an insightful article that highlights the challenges and realities of TCA: https://lnkd.in/dcBhggxn Important to remember: #software #architecture is ALWAYS about tradeoffs.

5

PHP Architect had a good overview of how to ensure our code is readable by other developers, in the August 2024 issue. “The Art and Mechanics of Readable Code” by Oscar Merida (https://lnkd.in/gwhECECN) The quote from Robert C Martin, “The ratio of time spent reading versus writing is well over 10 to 1” is particularly on point I feel. I think it’s important to keep in mind that you will not be looking at the code the same way when you see it again in the future, so readability and simplicity are among some of the most important attributes of good code.

2

Last week (in the middle of holidays) I published my thoughts about Definition of Done and how it can impact and be applied in software development. https://lnkd.in/dtNmBgXh

5

3 Kommentare

Rediscovering Java Lately, I’ve had the chance to dive back into Java, and I’ve been impressed by the simplicity and elegance of the language and its vast ecosystem. IntelliJ was fast and snappy too. While I’ve spent a lot of time working with C#, which is undoubtedly a great language, I sometimes find the abundance of syntactic sugar can be a bit overwhelming. Java, in comparison, offers a clean and straightforward approach that allows me to focus more on solving problems without getting too distracted by the language itself. It’s been a refreshing experience! What are your thoughts on Java vs. C#? Would love to hear about your experiences. #Java #SoftwareEngineering #Programming #TechThoughts

9

9 Kommentare

Big thanks to my awesome teammate Andrés Gutiérrez Ramírez for introducing me to "Agile Technical Practices Distilled" by Pedro Santos! / Marco Consolaro 📚✨ https://lnkd.in/dyPGcdd3 It's been a long time since a tech book has captivated me this much! For anyone looking to boost their technical skills and embrace agile methodologies, this book is a must-read. Let's keep growing together! 🚀👏 #Agile #TechnicalPractices #Teamwork #ContinuousLearning #BookRecommendation

16

5 Kommentare

Balancing Reusability and Flexibility in Angular Architecture One of the most challenging aspects of scaling large codebases is finding the balance between reusability and flexibility. 🌱 When working in an agile environment, businesses often don't know what they'll need next week, let alone months from now. That's why it's essential to Keep It Simple, Stupid (KISS)—start with unexposed code and extract logic only when it’s clear there’s a need. Remember: Flexibility first, reusability second. Seriously! Don't make thins reusable unless you need to, write reusable code, but don't expose it 🌱 Constantly refactor and move code as new requirements emerge. 🌱 Avoid over-engineering early on, as it can lead to unnecessary complexity later. 🌱 By maintaining this balance, we can ensure that our architecture remains scalable and adaptable as business needs evolve. Let me hear your thoughts. If you want to learn more about this subject, check out my Modern Large-scale Angular enterprise Architecture course and learn to scale massive code-bases until infinity!🤓

27

1 Kommentar

Using AI to generate an implemented tested Angular Pipe in seconds 🚀👇 In this video I'll show you how quickly you can generate a pipe with implementation and unit-tests and write it to the file system. What will AI do for us? ☘️ Create implementation of pipe ☘️ Create unittests for pipe ☘️ Write those contents to the file system in the right folder structure with the right filenames ☘️ export it through the barrel file of the correct module How does it work? 🚀 AI agent asks LLM to understand the question 🚀 AI agent understands the question 🚀 AI agent decides to execute a pipe generator 🚀 Pipe generator calls LLM with expected implementation 🚀 AI agent writes to the files system Will share a snippet with the code of the Pipe generator when this post reaches 100 likes 🥰 Here is the video: https://lnkd.in/eKznGBK5

8

3 Kommentare

Drawing insights from my conversation with Thiago Bomfim, an experienced software engineer who made the leap from Brazil to Portugal, here are the 10 most crucial tips for developers considering a move to Portugal. Read more 👉 https://lttr.ai/ASUEe #RichCulturalHeritage #ExperiencedSoftwareEngineer #InternationalCareer #LifeChangingDecision #AttractiveDestination #DrawingInsights

5

Briefly about the Graal compiler https://lnkd.in/dpkxTTCK

4

Due to the specificities of frontend applications, modelling the domain in this context has always been challenging. Ranging from generating aggregate ids and designing their lifecycles, to the need to represent invalid states, to context mapping when communicating with vendor APIs, there are a series of factors to be considered when modelling the domain. In this talk, I will show you these specificities and how to tackle everyday frontend complexities using canonical DDD concepts, designing new bounded contexts just for the frontend, while still embracing modern frontend approaches. Watch https://bit.ly/3XzGaOR and join us again next year in Antwerp!

6

1 Kommentar

A few weeks ago I was upgrading AWS API from v1 to v2 in one of our services to unblock the transition to Java 21, and I took the chance to improve the code a bit: I removed many dups by applying the template method pattern and the result was a better organized more consistent code without dups 🙂 This shows that the gang of four design pattern book remains today as relevant as 30 years ago! #OOD #OOP #objectoriented #designpatterns #java21 #cleancode

7

1 Kommentar

Blog post #11 - Becoming a better manager – The Power of Pair Programming https://lnkd.in/eYRpXkDX In this post, I dive into the concept of pair programming and share my personal experiences with it. Pair programming involves two engineers working together on the same problem, often boosting productivity and code quality through real-time collaboration. I discuss how pairing has enhanced my understanding of team workflows, reduced single points of failure, and allowed me to support my team’s growth as an engineering manager.

2

🔧 Struggling with "Too Many Connections" errors in Spring Hibernate applications? You're not alone! In my latest Medium article, I tackle this tricky issue, explaining why it happens and how to prevent it with best practices for efficient database management. 🛠️ From implementing HikariCP for connection pooling to using @Transactional for proper transaction management, I share strategies that ensure your connections are managed correctly, helping you avoid bottlenecks and keep your application performing at its best. If you're building scalable, database-driven applications, this guide can save you a lot of headaches down the road. Check it out and let me know if these tips help! 🔗 https://lnkd.in/gwDz6HhP #SpringBoot #Hibernate #Java #DatabaseManagement #ConnectionPooling #SoftwareEngineering #BackendDevelopment #CodingBestPractices #Medium

6

1 Kommentar

Choose refactoring over rewriting, unless you are well prepared for these: ==== 1. Everything takes longer and costs more We chronically underestimate the effort required to reimplement existing functionality in a new architecture. Even with the best-laid plans, unforeseen complications inevitably arise. Changing requirements, unexpected dependencies, and scope creep can stretch initial timelines by months or even years. Meanwhile, the opportunity cost is immense as new feature development grinds to a halt, leaving the business unable to respond to market needs. Data migration poses a particularly thorny challenge that's easy to brush over during initial planning. Rearchitecting datastores and schemas requires carefully mapping and migrating every data element while maintaining compatibility between old and new systems. Comprehensive migration testing is a project unto itself. Budget overruns are all but guaranteed as these "minor details" end up consuming major engineering resources. 2. Subtle knowledge gets lost in translation Mature software contains a wealth of wisdom in the form of edge cases, bug fixes, and subtle behaviors accumulated over years of real-world usage. While happy path functionality is usually well-understood, the long tail of nuanced behaviors is rarely documented in detail. When rewriting, it's almost inevitable that some of these subtleties will be missed - often not discovered until the new system is in production. Even with the most diligent QA, flipping the switch on a completely rebuilt system is always a nerve-wracking experience. Unexpected issues have a way of cropping up at the worst times, sending teams scrambling to fix showstopper bugs while stakeholders wonder why the new system seems worse than the old one. The fact is, it's nearly impossible to achieve true parity with a battle-tested codebase within any realistic rewrite timeframe. Some degree of regression is inevitable. 3. The human toll is high Rewrite projects are notoriously high-pressure environments. As timelines slip and stakeholder patience wears thin, teams often find themselves working unsustainable hours for months on end. Burnout and churn become endemic, further undermining velocity. Recruiting for long-running rewrites is challenging, so teams frequently end up understaffed. Those who remain must shoulder an ever-increasing workload with no end in sight. In any multi-quarter / year project, shifting company priorities pose a constant threat. What began as a strategic imperative can quickly become an expensive distraction in the eyes of new leadership. Funding gets cut, deliverables get descoped, and engineers grow demoralized as the vision they signed up for appears increasingly unattainable. Many grand rewrites end up abandoned partway through, having burned untold engineering effort for little gain. #softwareengineering #softwaredesign #techlead #softwarearchitecture

31

1 Kommentar