DOCSEARCHbyAlgolia
Submit Docs

Hexdrinker Blog

website·Indexed 31 days ago

https://hexdrinker.dev

A technical blog featuring a deep dive into Clean Architecture, covering principles like SRP, ISP, LSP, and DIP, as well as component coupling, functional programming, and object-oriented design. The site also includes technical articles on Shadow DOM, browser history, and personal professional retrospectives.

Tokens
21.6K
Snippets
36
Records
137
Agent score
60%

What's inside Hexdrinker

  1. Overview of early web browser evolution (1990-1995)

    The evolution of early web browsers began with WorldWideWeb (later renamed Nexus), developed by Tim Berners-Lee in 1990 for NeXTSTEP using Objective-C. In 1993, MOSAIC was released by Marc Andreessen and Eric Bana (NCSA), which popularized the web by being the first to display multimedia (images and music) inline. This led to the creation of Netscape Navigator in December 1994 by Netscape Communications, which further generalized the use of the World Wide Web through improved performance and usability.

  2. Overview of Shadow DOM for Web Components

    Shadow DOM is a core technology for Web Component-based UIs that enables encapsulation of DOM structure and styles. It protects a component's internal structure and styling from the external global scope, allowing for the creation of reusable components without relying on external frameworks or libraries. While it provides strong encapsulation, developers should consider strategies to address potential challenges regarding SEO, accessibility, and customization.

  3. Apply Clean Architecture to Backend and Native App systems

    Clean Architecture is particularly effective for systems where business policy is central and external dependencies are numerous. It is recommended for:

    1. Backend Systems: Where policies must survive database migrations, API changes (e.g., REST to GraphQL), or framework replacements. Backend systems typically have long lifespans (5-10 years), making the reduction of technology replacement costs critical.
    2. Native Mobile Apps: Where complexity is high due to offline modes, local databases, caching, synchronization, background tasks, OS lifecycle management, and native device APIs. In these cases, simple patterns like MVVM may be insufficient, and separating the domain from platform-specific code is necessary.

  4. Understand the balance between Software Behavior and Architecture

    Every software system provides two distinct values to stakeholders:

    1. Behavior: The functional requirements and specifications. This is the immediate goal of making the software 'work' and satisfy the user's needs. It is often perceived as 'urgent'.
    2. Architecture (Structure): The quality that makes software 'soft' (easy to change). The primary purpose of software is to allow the behavior of the machine to be changed easily. A good architecture is independent of the 'shape' of the change; the cost of a change should be proportional to its scope, not the specific type of change required.

  5. Identify signs of architectural decay and technical debt

    Architectural decay occurs when developers prioritize immediate market release over code quality, operating under the fallacy that 'messy code is faster in the short term.'

    Signs of a failing architecture include:

    • Inverse Productivity: Engineering staff numbers increase, but product growth stagnates or slows down.
    • Rising Cost per Line of Code: The financial cost to produce a single line of functional code increases over time.
    • Maintenance Trap: Developers spend more time fixing bugs and navigating messy legacy code (searching through multiple folders to find a cause) than developing new features.
    • The 'Later' Fallacy: The belief that code will be cleaned up 'later' is typically false, as market pressure remains constant and productivity eventually converges toward zero.

  6. Understand the difference between URI, URL, and URN

    Internet resources are identified using different naming and locating conventions:

    • URI (Uniform Resource Identifier): The overarching term for a string used to identify a resource. Both URLs and URNs are subsets of URIs.
    • URL (Uniform Resource Locator): Specifies the location of a resource and the mechanism to access it. If the resource is moved, the URL changes and the old one becomes invalid.
    • URN (Uniform Resource Name): Specifies a unique name for a resource that is independent of its location. It remains constant even if the resource is moved.

  7. Understand the relationship between static code and dynamic processes

    Programming is the act of producing a static text that creates a dynamic process. A high-quality program minimizes the conceptual gap between the static text and the dynamic process, ensuring that the execution flow is predictable and explainable by looking at the code. Because humans are better at understanding static relations than time-evolving processes, code that is difficult to simulate mentally is inherently risky.

  8. Apply the 'Why' and 'Concept' framework to product planning

    Effective planning starts with 'Why' rather than 'What'. In a market saturated with products, users are driven by emotional connection and a reason to purchase. A strong 'Concept' serves as the answer to the user's 'Why', bridging the gap between the current reality and the desired state. The planning process consists of defining the purpose and the problem, and then creating an execution plan to achieve that purpose.

  9. Apply a fundamental approach to creative planning

    To achieve 'sensible' or intuitive planning, one should not look for complex shortcuts but instead start from the most common-sense and basic thoughts. The core of professional intuition is returning to the essence by constantly questioning the 'why' behind everything—from a piece of bread to a city building.

  10. Effective communication principles for collaborative development

    When collaborating with team members, especially in remote or asynchronous environments, use the following checklist to ensure communication is purposeful and efficient:

    1. Define the Objective: Be clear about what you are trying to achieve.
    2. Identify the Right Person: Determine who has the specific knowledge or authority to help solve the problem.
    3. Provide Necessary Context: Give the helper exactly what they need to assist you (technical details, logs, etc.).
    4. Verify Necessity: Confirm that the communication is essential and cannot be solved independently.
    5. Align Method with Purpose: Ensure the communication channel and tone are appropriate for the goal.

  11. Combine Object-Oriented Programming (OOP) and Functional Programming (FP) for architecture

    OOP and FP are complementary rather than mutually exclusive. They provide different strengths at different scales of a system:

    • OOP (Macro perspective): Strong for overall system structure, module separation, and creating flexible architectures (e.g., using SOLID principles and design patterns).
    • FP (Micro perspective): Strong for internal logic, minimizing side effects through immutability, and creating predictable, safe data pipelines.

    A robust architecture uses OOP to provide a flexible structure and FP to ensure the logic within that structure is safe and predictable.

  12. Apply programming paradigms to software architecture

    Modern software architecture leverages the constraints of the three major paradigms to manage different concerns:

    • Polymorphism (OOP): Used as a mechanism to cross architectural boundaries.
    • Immutability/Functional Rules (Functional): Used to impose rules on data location and access methods.
    • Modular Algorithms (Structural): Used to organize the internal logic of modules.