Valentino Pellegrino

Sometimes when we think about technical debt, the immediate reaction is to want to stamp it out. Fix things, upgrade everything, refactor. Now. But sometimes you have to pause and ask: will an application gain value when we refactor it? Try flipping that question around: does a badly written app have enough value that it's worth refactoring? Maybe that's the question you need to ask.

16

Just discovered a valuable open-source tool at https://lnkd.in/dpHwAVUF that simplifies the documentation process for event-driven architectures. Building documentation with visualisations can be challenging, especially for complex architectures, but I'm excited to explore this tool and streamline the process. #EventDrivenArchitecture #Documentation #OpenSource

6

1 commento

Let’s go to the next level of software architecture & system design and redesign: domain driven design, redesigning a big ball of mud, design patterns, low coupling, modularity maturity index metric, etc.

2

1 commento

Returning to Java from Kotlin has me thinking again about nulls and null-safety. Kotlin has softened me somewhat on the subject of nulls, because its handling of them is safe and elegant: declaring a type as T? is more or less equivalent to declaring it as Maybe T in Haskell, and null is just a compact representation of None in that case. The compiler will simply reject anything that tries to pass null, or the unchecked value of a variable of nullable type, to a non-nullable receiver. It's one of the two things about the language I'm really going to miss (the other being the Ruby-like block syntax). After a phase of thinking Optional<T> should be used to do the same thing in Java, I'm actually swinging back more towards annotating optional fields and parameters as @Nullable, and relying on tooling (the IDE, build-time linting) to enforce Kotlin-like null-discipline. But there's a skeleton in the closet: older (pre-record-type) Java often has a lot of POJOs with default no-argument constructors lying around. You construct one, everything's null, you set fields one by one with the setters. It's much harder to impose null-discipline of any kind in this scenario. People depend on this behaviour, too - they create test value objects by newing up instances of POJOs and setting only the fields the code under test is interested in, and everything works. You can say "you should make it impossible to construct an object in an invalid state" all you like, but you're going to break all those tests if you actually take the ability to partially populate a value type away from them. Lombok doesn't help, either - there's no way to compile-time check that all the mandatory fields have been added to a builder before calling build(). And even with record types, the ability to use builders to supply field values by name, rather than relying on their order in the constructor signature, is going to be hard to take away from people working with value types with a dozen or more fields. Java is just an ever-burning tire fire around these issues, and always has been, and it's a major reason why "legacy" code tends to suck so much. At the moment the best I think I can do is try to promote a general pattern: if you can't ensure correctness on construction, validate correctness immediately after construction (and prevent illegal mutation after that). At least then you can eliminate ad hoc null checks downstream of validation, and be clear about when missing values are actually to be expected.

84

34 commenti

How do you set priorities effectively? 🤔 Check out this insightful article by [@MilanMilanovic](https://lnkd.in/etJVVWuZ) on prioritization best practices, frameworks, approaches, guidelines, and more. Perfect for technical leads, developers, and anyone looking to enhance their skills. Read more here: [How to Set Priorities](https://lnkd.in/ePVTyxez) #Prioritization #TechLeadership #DeveloperGrowth #ProjectManagement #TechnicalExcellence #CareerDevelopment #ProductivityTips

45

3 commenti

IntelliJ IDEA, built by JetBrains, is renowned for making coding easier and faster with its smart features and powerful tools. After years of using it, I’ve come to realize that its keyboard shortcuts are not just convenient—they're essential for coding efficiently and staying focused. By keeping your hands on the keyboard, you can write code quicker and maintain your flow. I’m excited to share the most useful shortcuts I use daily, hoping they’ll help you get the most out of IntelliJ IDEA, whether you're a beginner or an experienced user. #programming #java #kotlin #intellij

12

Taking a break from the courses that I've been writing (and warming up for writing a Node.js course): https://lnkd.in/eApqU3ee

22

1 commento

If Not React, Then What? Frameworkism isn't delivering. The answer isn't a different tool, it's the courage to do engineering. Code that runs on the server can be fully costed. Code that runs on the client, by contrast, is running on The Devil's Computer. As a result, an unreasonably effective strategy is to send less code. In practice, this means favouring HTML and CSS over JavaScript, as they degrade gracefully and feature higher compression ratios. Declarative forms generate more functional UI per byte sent. These improvements in resilience and reductions in costs are beneficial in compounding ways over a site's lifetime. Stacks based on React, Angular, and other legacy-oriented, desktop-focused JavaScript frameworks generally take the opposite bet. "Our product stack has bet on React and the various mythologies that the cool kids talk about on React-centric podcasts. You're asking us to rethink the whole thing. Which silver bullet should we adopt instead?" JavaScript remains at least 3x more expensive than equivalent HTML and CSS, byte-for-byte. The choice isn't between JavaScript frameworks, it's whether SPA-oriented tools should be entertained at all. For most sites, the answer is clearly "no". Sites built to inform should almost always be built using semantic HTML with optional progressive enhancement as necessary. Sites that have content that changes more frequently should look to "classic" CMSes or tools like WordPress to generate HTML and CSS. Blogs, marketing sites, company home pages, public information sites, and the like should minimise client-side JavaScript payloads to the greatest extent possible. They should never be built using frameworks that are designed to enable SPA architectures. Managers and tech leads that have become wedded to frameworkism often have to work through a series of easily falsified rationales offered by other Over Reactors in service of their chosen ideology. Note, as you read, that none of these protests put the lived user experience front-and-centre. "...it works for Facebook" To a statistical certainty, you aren't making Facebook. Your problems likely look nothing like Facebook's early 2010s problems, and even if they did, following their lead is a terrible idea. "...React is industry-standard" This is, at best, a comforting fiction. At worst, it's a knowing falsity that serves to omit the variability in React-based stacks because, you see, React isn't one thing. It's more of a lifestyle. Across more than 100 consulting engagements, I've never seen two identical React setups. There's nothing standard about any of this. It's all change, all the time, and anyone who tells you differently is not to be trusted. And if you don't mind me asking, how's that "CSS-in-JS" adventure working out? Still writing class components, or did you have a big forced (and partial) migration that's still creating headaches? https://lnkd.in/efB4PR-A

3

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 commenti

Something that landed unnoticed: Playwright support in the Angular CLI 🚀 We've been collaborating with the Playwright team to land this community schematic by Jean-François Greffier and Cédric Exbrayat in the CLI Pick between Puppeteer, Playwright, Cypress, WebdriverIO, or NightWatch! #angular #typescript #programming #webdev #webdevelopment #javascript #webperformance #webtesting

906

35 commenti

Good design to use

6

Here is the very useful repo for #remote job finders. list of active remote first companies available and well maintained in the repo. https://lnkd.in/dB-3dsXz Further you can subscribe to any company for regularly getting active positions in email from this link 👇 https://lnkd.in/dFAE4dzz #remotejob Thank you so much Yanir Seroussi for making this repo. This post is Inspired by the mission of Wajahat Karim 🇵🇰 . #remotekaro #remotejobs #remotelifestyle

112

5 commenti

I've just published a new article on Medium: "Next.js 14 Caching: An In-Depth Examination". This article explores the caching mechanisms and strategies employed by Next.js, delving deep into the automatically generated files, and their roles in enhancing the application's general performance.

15

Just so you know, with Angular's standalone components, if you have to import a module 10 times, Angular will only import it 1 time when building out the page.

10

2 commenti

Eng 🚀 Evolution of React with Hooks - From 2019 to 2024! When working with React, it's essential to stay updated on the innovations and improvements in the library, especially regarding hooks. I created a compilation of the evolution of key hooks from 2019 to 2024, covering versions from 16.8 to 19, as well as the Node.js versions supported. Check out how new features like useOptimistic, useActionState, and useFormStatus are transforming the way we handle UI and asynchronous states! Key Milestones: 🟦 2019 (React 16.8 - Node 12.x): Introduction of the first hooks such as useState, useEffect, and useReducer, revolutionizing state management and side effects. 🟩 2022 (React 18 - Node 16.x): Arrival of useId, useTransition, and useDeferredValue, helping maintain UI responsiveness in large applications. 🟧 2024 (React 19 - Node 18.x): The future is here with useOptimistic and other hooks focused on improving the experience with optimistic updates and asynchronous actions. You can check out the full image with all the hook details here!

1