Raul Junco’s Post

Good pull requests invite comments. Here are some tips and tricks for improving your pull requests and making them easier to review.

Hypermedia is a cool word. It’s also a cool concept that undergirds the most successful network architecture project of all time: the WorldWide Web! Hypermedia (specifically hypertext) appears in two acronyms that you should recognize: HTML and HTTP. Let’s talk a bit about HTML and its capabilities! HTML (HyperText Markup Language) defines the structure of elements on a webpage. All webpages ultimately render to an HTML document, even if you only wrote JavaScript or JSX during development! So why call HTML this strange word ‘hypertext’? The defining characteristic of hypermedia is the presence of ‘hypermedia controls’. “A hypermedia control is an element in a hypermedia that describes (or controls) some sort of interaction, often with a remote server, by encoding information about that interaction directly and completely within itself.” — Gross, Carson, et al. “Hypermedia: A Reintroduction .” Hypermedia Systems The two best examples of such controls in HTML documents are the ‘anchor’ and ‘form’ elements. Anchor tags allow the client to navigate to a related resource by following the link provided in the href attribute. Form elements allow the client to submit a request to the server, including all input elements contained by the form. This is how clients can make changes to modify resources owned by the server, using the control provided to them by the server. The concept of hypermedia controls is new to me, but not new to the world of software. It’s a core element to the REST architecture outlined by Roy Fielding in his doctoral dissertation "Architectural Styles and the Design of Network-based Software Architectures" published in 2000. Because it’s such a fundamental element of the web, learning the constraints and design philosophy of distributed hypermedia applications is a worthy pursuit for developers. I encourage you to learn more about hypermedia and its modern applications; I certainly will!

The Open/Closed Principle: A Door That Never Shuts, A Room That Always Grows In the ever-shifting architecture of software design, one rule whispers louder than the rest: “Open for extension, closed for modification.” This is the Open/Closed Principle (OCP), a cornerstone of SOLID, a path to designs that endure the chaos of constant change. The Perils of Modifying the Past Picture it: a class designed long ago, a proud construct of methods and logic, its purpose clear. But time passes, requirements shift, and now—your old class must change. Each modification stirs the ghosts of prior logic, introducing new risks, new bugs, unraveling the careful tapestry of what once worked. The past grows fragile, and your class becomes a liability. Extending the Future Without Breaking the Past OCP urges you to stop rewriting the past. Instead, extend functionality through abstraction, interfaces, and inheritance. Let your class remain stable—a foundation upon which new features stand tall, untouched by the shifting winds of requirements. Example: Open/Closed in Action public abstract class Notification { public abstract void Send(string message); } public class EmailNotification : Notification { public override void Send(string message) { Console.WriteLine($"Email sent: {message}"); } } public class SmsNotification : Notification { public override void Send(string message) { Console.WriteLine($"SMS sent: {message}"); } } public class NotificationService { private readonly List<Notification> _notifications = new List<Notification>(); public void AddNotification(Notification notification) { _notifications.Add(notification); } public void NotifyAll(string message) { foreach (var notification in _notifications) { notification.Send(message); } } } What Changed? Instead of altering existing code to add new notification types (like Slack or Push), we extend by adding new classes. Email and SMS are stable, untouched—open for new features but closed to risky modifications. Takeaway The Open/Closed Principle is a design philosophy that respects the stability of the past while embracing the inevitability of future growth. Build your classes to extend without fear of breaking what’s already there. Stay tuned as we continue our journey through SOLID’s winding corridors. #writtenfrommyphone #latenightthoughts

I was exploring .NET's collection hierarchy today and noticed something interesting about the Liskov Substitution Principle (LSP). We have: IEnumerable<T>: Represents an infinite stream of data that you can enumerate through elements one by one without knowing how many there are. ICollection<T>: Inherits from IEnumerable<T>. It’s a finite collection where you can add or remove items. a bag, you know how many items are in it (Count), but the items aren't necessarily ordered. IList<T>: Inherits from ICollection<T>. It's an ordered collection where you can access elements by index. list where you can get or set items at specific positions. So far, everything aligns with LSP. A List is a Collection, which is an Enumerable. You can substitute a subclass wherever its superclass is expected without breaking the program. IReadOnlyCollection<T>. Based on the name, you'd expect it to be a collection you can't modify which makes sense right? It inherits from IEnumerable<T>, not from ICollection<T>, because you can't add or remove items. But ReadOnlyCollection<T>: a class, not just an interface which implements IList<T>. 🎊 If ReadOnlyCollection<T> implements IList<T>, which inherits from ICollection<T>, shouldn't it support adding and removing items? But it's read-only! So, what happens if you call Add or Remove on a ReadOnlyCollection<T>? It throws a NotSupportedException. Isn't the whole point of static typing to prevent runtime errors like this? At first, this seems like a violation of the Liskov Substitution Principle. But actually, I think it isn't. Here's why: The ICollection<T> interface includes an IsReadOnly property. According to the documentation, if IsReadOnly is true, methods like Add or Remove will throw a NotSupportedException. Since ReadOnlyCollection<T> sets IsReadOnly to true, it adheres to the contract defined by ICollection<T>. So, the substitution doesn't introduce any new errors beyond what's already specified. It might be the case that the design decisions in frameworks have historical or practical reasons that I don't know about. Just thought I'd share this little discovery.

Server-Driven-UI brings some benefits to your projects, but the cons are much bigger, and that's why I consider that a huge anti-pattern. I list 6 reasons for that here, but for short, I think this is a great enemy of the SOLID principles and clean architectures. The cover image was chosen by purpose. I strongly encourage you all to post your opinions here.

Low-Level Design (LLD) for Improved Software Solutions. Thank you Ashish Misal Want to improve your software development skills? Low-Level Design (LLD) is crucial for building scalable, efficient, and maintainable systems. 𝟏. 𝐎𝐛𝐣𝐞𝐜𝐭-𝐎𝐫𝐢𝐞𝐧𝐭𝐞𝐝 𝐃𝐞𝐬𝐢𝐠𝐧 (𝐎𝐎𝐃) 𝐏𝐫𝐢𝐧𝐜𝐢𝐩𝐥𝐞𝐬 - SOLID : https://lnkd.in/dafK6TzQ - DRY : https://lnkd.in/dreUT7_h - KISS : https://lnkd.in/d-nFYfdR - YAGNI :https://lnkd.in/dHzEi__Y 𝟐. 𝐃𝐞𝐬𝐢𝐠𝐧 𝐏𝐚𝐭𝐭𝐞𝐫𝐧𝐬 - Singleton : https://lnkd.in/dB5aDUXr - Factory : https://lnkd.in/dvZtfe-k - Adapter : https://lnkd.in/dKQpsTfe - Observer : https://lnkd.in/dByc-whP - Strategy :https://lnkd.in/d9dz8ER7 𝟑. 𝐒𝐲𝐬𝐭𝐞𝐦 𝐂𝐨𝐦𝐩𝐨𝐧𝐞𝐧𝐭𝐬 𝐃𝐞𝐬𝐢𝐠𝐧 - Class diagrams : https://lnkd.in/d8_8rYCp - Sequence diagrams : https://lnkd.in/duPf_cJ2 - Interfaces : https://lnkd.in/d8NzSRgG 𝟒. 𝐃𝐚𝐭𝐚𝐛𝐚𝐬𝐞 𝐃𝐞𝐬𝐢𝐠𝐧 - ER diagrams : https://lnkd.in/d6xygCrb - Normalization : https://lnkd.in/dz7MCVaj - Relationships : https://lnkd.in/da3YTaJN 𝟓. 𝐂𝐨𝐧𝐜𝐮𝐫𝐫𝐞𝐧𝐜𝐲 & 𝐌𝐮𝐥𝐭𝐢𝐭𝐡𝐫𝐞𝐚𝐝𝐢𝐧𝐠 - Thread safety : https://lnkd.in/dNe6FpfS - Locks : https://lnkd.in/dN2YdpvU - Atomic operations : https://lnkd.in/dcfZF9Jb 𝟔. 𝐄𝐫𝐫𝐨𝐫 𝐇𝐚𝐧𝐝𝐥𝐢𝐧𝐠 & 𝐋𝐨𝐠𝐠𝐢𝐧𝐠 - Exception handling : https://lnkd.in/dkUHDGBu - Logging strategies : https://lnkd.in/dvikcadQ 𝟕. 𝐀𝐏𝐈 𝐃𝐞𝐬𝐢𝐠𝐧 - RESTful API: https://lnkd.in/dqDrkbDS - Pagination : https://lnkd.in/dJfwFqmd - Authentication : https://lnkd.in/dQ94BgzQ 𝟖. 𝐒𝐜𝐚𝐥𝐚𝐛𝐢𝐥𝐢𝐭𝐲 & 𝐏𝐞𝐫𝐟𝐨𝐫𝐦𝐚𝐧𝐜𝐞 - Caching : https://lnkd.in/deMQvEJ9 - Load balancing : https://lnkd.in/dkeYMX74 - Lazy loading : https://lnkd.in/dvcdY_RX

Processing billions of records in step by step optimized manner than it will be the helpful read article to implementation and optimization 😀

https://lnkd.in/echiDvF6 Nice tips! A good architecture is the principal main to be scale up software

Responding to the request of several people to write more about Micro frontends I did a brief research and analysis of tools and libraries most used! https://lnkd.in/dGKpFE7m #frontEnd #microservice #angular #react #tools #arquiteture

https://lnkd.in/d5mrkyVt A binary Converter is a handy tool that converts binary numbers to their decimal equivalents and vice versa. #ToolPrime #tools #converter