Singleis in the Cryptocurrencies Industry

Single

single

Table of Links Abstract and 1. Introduction Abstract and 1. Introduction 2 Methodology 2 Methodology 3 Hardware 3 Hardware 4 Software 4 Software 5 Network 5 Network 6 Consensus 6 Consensus 7 Cryptocurrency Economics 7 Cryptocurrency Economics 8 Client API 8 Client API 9 Governance 9 Governance 10 Geography 10 Geography 11 Case Studies 11 Case Studies 12 Discussion and References 12 Discussion and References A. Decentralization and Policymaking A. Decentralization and Policymaking B. Software Testing B. Software Testing C. Brief Evaluations per Layer C. Brief Evaluations per Layer D. Measuring decentralization D. Measuring decentralization E. Fault Tolerance and Decentralization E. Fault Tolerance and Decentralization 4 Software Software development is another dimension of distributed ledgers that has been associated with potential centralization [44,147,11]. Diverse software development and usage is a core element of stability and safety of distributed ledgers, as it increases resilience to catastrophic bugs in a product’s code. A vulnerability in one implementation may jeopardize a part of the system, but if the system is sufficiently decentralized, such vulnerabilities would not escalate to systemic threats. Following, we discuss the development of core blockchain software components, namely transaction validation and PoW mining (via full nodes) and management of keys and digital assets (via wallets).[7] Protocol Participation. The principal type of software in blockchain systems is the full node. Full nodes implement the ledger protocol by: i) keeping a local chain; ii) validating new transactions; iii) extending the local chain with new blocks; iv) participating in the consensus mechanism to incorporate new blocks. To analyze decentralization, we identify two resources of interest: 1) (number of) full nodes; 2) participating power (e.g., computational or stake) that is hosted on full nodes. The relevant parties are: 1) full node software implementations; 2) full node software developers. Protocol Participation. Protocol Participation. Relying on a handful of full node implementations introduces safety, liveness, and stability hazards. A bug that fails to validate correct transactions would hurt the system’s liveness, whereas accepting incorrect transactions could hurt the system’s safety and stability, e.g., via a network split or token forgery. Such bugs have been observed in Bitcoin Core and could have resulted in Denial-of-Service (DoS) attacks [75] and token forgery [48]. Implementation bugs could also threaten privacy, if nodes reveal information about message origin (e.g., IP addresses). Similar threats arise when code gets reused across different projects. Often, a new blockchain is only a “derivative”, that is a project that started by forking an existing codebase, including copyrighted information [147]. Such projects often remain unpatched, so bugs in the initial implementation tend to spill over [44]. Vulnerabilities may also arise when adapting an existing implementation in a new setting, e.g., copying Bitcoin’s code and replacing PoW with PoS [96]. Thus, widespread usage of multiple node implementations, developed by different teams, is a hallmark of a secure and reliant ecosystem. Asset Management. Distributed ledgers are mostly used for bookkeeping of digital asset transactions, so securely managing and transferring assets is a core necessity. Digital assets are typically managed by private keys and represented via addresses. The software responsible for managing keys and addresses is the wallet [100] and its principal functionalities are: i) store the user’s keys; ii) prove ownership of the assets (managed by the keys); iii) issue transactions that transfer assets to other accounts; iv) retrieve the user’s (keys’) balance and history information. Therefore, the resource of interest is the set of all assets managed via the ledger and the relevant parties are, accordingly: i) wallet implementations; ii) developers of wallet software. Asset Management. Asset Management. The wallet is a major point of security consideration, so multiple properties rely on it. A bug which e.g., corrupts the user’s keys could not only prohibit a user from transacting with their assets (liveness hazard), but forever lose access to them (stability hazard). This was demonstrated in 2017, when the “Parity” Ethereum wallet saw a vulnerability that allowed a user to take ownership of multiple assets and then lock them [89]; as a result, 300m worth of Ethereum tokens were forever lost. In another example, some Bitcoin wallets possibly displayed incorrect balance, effectively enabling a double spending attack [116]. Consequently, if a few implementations are predominantly used, a vulnerability could result in assets being unusable or stolen. Such vulnerability could also turn into a systemic point of failure, with the whole ledger becoming unusable.[8] Authors:
(1) Christina Ovezik, University of Edinburgh (c.ovezik@ed.ac.uk);
(2) Dimitris Karakostas, University of Edinburgh (dkarakos@ed.ac.uk);
(3) Aggelos Kiayias, University of Edinburgh and IOG (akiayias@ed.ac.uk). Authors: Authors: (1) Christina Ovezik, University of Edinburgh (c.ovezik@ed.ac.uk); (2) Dimitris Karakostas, University of Edinburgh (dkarakos@ed.ac.uk); (3) Aggelos Kiayias, University of Edinburgh and IOG (akiayias@ed.ac.uk). This paper is available on arxiv under CC BY 4.0 DEED license. This paper is available on arxiv under CC BY 4.0 DEED license. available on arxiv available on arxiv [7] Appendix B also explores software testing. [8] A prime such example was “The DAO”, which in 2016 attracted nearly 14% of all Ethereum tokens and, when hacked, instigated a change in Ethereum’s consensus layer and a hard fork which split the network [169].

Blockchain’s Single Point of Failure? The Software Running It

I remember reading some years ago an L1’s proposal to migrate to an L2. That's where I came across the term decentralized sequencers. At the time, it seemed like an interesting but somewhat distant concept—an optimization rather than a necessity. But today, as rollups solidify their role as the dominant scaling solution for Ethereum and beyond, the importance of decentralized sequencers has grown considerably. decentralized sequencers For all the innovation that rollups bring, they still carry a significant centralization risk: most of them rely on a single, privileged sequencer. While this approach helps improve transaction speed and cost efficiency, it reintroduces some of the trust assumptions that blockchains were designed to eliminate. The debate around decentralized sequencers is not just about removing centralization for the sake of ideology; it’s about solving real bottlenecks in performance, censorship resistance, and fair transaction ordering. In this deep dive, we'll explore why sequencers matter, how decentralized sequencer networks work, the emerging designs in this space, and what challenges remain before they see widespread adoption. What is a sequencer and why does it matter? What is a sequencer and why does it matter? Sequencers play a critical role in rollup architectures. In simple terms, a sequencer is responsible for: Ordering transactions before they are posted on L1.


Providing rapid confirmations to users, even before final settlement on Ethereum.


Mitigating MEV (Maximal Extractable Value) by controlling how transactions are arranged. Ordering transactions before they are posted on L1. Ordering transactions before they are posted on L1. Providing rapid confirmations to users, even before final settlement on Ethereum. Providing rapid confirmations to users, even before final settlement on Ethereum. Mitigating MEV (Maximal Extractable Value) by controlling how transactions are arranged. Mitigating MEV (Maximal Extractable Value) by controlling how transactions are arranged. Without sequencers, rollups would function much like L1 blockchains—transactions would have to wait for finalization before they can be considered confirmed, resulting in slower user experiences. A sequencer brings the benefit of near-instant finality, making rollups feel as fast as traditional Web2 applications. Okay, but why do we need decentralized sequencers? Well, decentralized sequencers implies the opposite exists too. What's interesting is that centralized sequencers are more scalable and even faster. But its a double edged sword, its advantages in terms of scaling, comes with significant risk. Censorship – A centralized sequencer can choose which transactions to include or exclude, leading to concerns about neutrality, fair access and defeats the purpose of decentralized technology.
Single point of failure – If the sequencer goes offline, transactions cannot be processed until it comes back. While some rollups have fallback mechanisms, they are inefficient and not ideal for mainstream adoption. Censorship – A centralized sequencer can choose which transactions to include or exclude, leading to concerns about neutrality, fair access and defeats the purpose of decentralized technology. Single point of failure – If the sequencer goes offline, transactions cannot be processed until it comes back. While some rollups have fallback mechanisms, they are inefficient and not ideal for mainstream adoption. This might also seem like an unlikely scenario but it has in fact happened before. Arbitrum’s sequencer once stalled, making the network unusable for over an hour. MEV exploitation – A centralized sequencer can extract value from users through unfair transaction ordering, front-running, or sandwich attacks. MEV exploitation – A centralized sequencer can extract value from users through unfair transaction ordering, front-running, or sandwich attacks. These risks make it pertinent that L2s move towards a decentralized sequencer architecture.While a number of chains are still using centralized sequencers like Arbitrum one, optimism and base, we have seen new players like Morph adopting the decentralized sequencer model. How do decentralized sequencers work? A decentralized sequencer network, distributes the sequencing function across multiple entities, removing the reliance on a single entity. Its essentially the opposite of centralized sequencers. Its more time consuming and more expensive (in comparison with centralized sequencers) but for what it lacks, it makes up for it with: Censorship resistance – No single entity can exclude transactions.
High availability – Even if one sequencer node goes down, others can take over. This eliminates the risk of network downtime.
Fair transaction ordering – Preventing MEV abuse and ensuring a level playing field. Censorship resistance – No single entity can exclude transactions. High availability – Even if one sequencer node goes down, others can take over. This eliminates the risk of network downtime. Fair transaction ordering – Preventing MEV abuse and ensuring a level playing field. Shared Sequencing In the shared sequencing approach, multiple sequencers collaborate to process transactions in a shared mempool. The sequencers collectively determine the order of transactions and propose blocks to the L1 chain based on a consensus mechanism. Advantages: Ensures consistent transaction ordering across all sequencers
Reduces the risk of MEV exploitation through a fair ordering mechanism
Enables seamless failover in case of individual sequencer failures\ Ensures consistent transaction ordering across all sequencers Reduces the risk of MEV exploitation through a fair ordering mechanism Enables seamless failover in case of individual sequencer failures\ Challenges: Requires a robust consensus mechanism to ensure fair participation and prevent attacks
Potential for lower throughput compared to centralized sequencing due to the coordination overhead
Increased communication complexity among sequencers Requires a robust consensus mechanism to ensure fair participation and prevent attacks Potential for lower throughput compared to centralized sequencing due to the coordination overhead Increased communication complexity among sequencers Example: The Morph rollup uses a shared sequencing model based on a proof-of-stake consensus among sequencers. Example The Future of Decentralized Sequencing As the Ethereum ecosystem continues to scale and mature, the need for decentralized sequencing solutions will only grow. While the current approaches offer significant improvements over centralized sequencers, there is still room for innovation and optimization. One area of active research is the development of hybrid sequencing models that combine the benefits of different approaches. For example, a system could use shared sequencing for high-value transactions that require strong censorship resistance, while employing a more centralized approach for low-value transactions to maximize throughput. Another promising direction is the integration of privacy-preserving technologies like zero-knowledge proofs into decentralized sequencers. This could enable users to submit transactions without revealing their identities or transaction details to the sequencers, further enhancing the censorship resistance and neutrality of the system. As the technology evolves, we can expect to see more rollups and L2 solutions adopting decentralized sequencing architectures. This will not only improve the security and fairness of these systems but also bring us closer to the vision of a fully decentralized and scalable blockchain ecosystem. Conclusion Decentralized sequencers are a critical component of the Ethereum scaling puzzle. By removing the reliance on a single, privileged entity, they mitigate the risks of censorship, single points of failure, and MEV exploitation. While the current approaches have their tradeoffs and challenges, they represent a significant step towards a more resilient and trustless blockchain infrastructure. As the space continues to innovate and mature, we can expect to see more advanced and efficient decentralized sequencing solutions emerge. These developments will not only benefit Ethereum but also have far-reaching implications for the broader blockchain ecosystem, enabling new use cases and unlocking the full potential of decentralized technologies.

Rollups Are the Future—But Their Biggest Bottleneck Might Be a Single Point of Failure

A Single Point of Access or Chaos — Unlocking Non-Blocking API Gateways

How to Troubleshoot 'hostpolicy.dll' and 'singlefilehost.exe' Errors in .NET 8.0.11

Kunjamas ‘hostpolicy.dll’ ukat ‘singlefilehost.exe’ pantjasiwinak askichañax .NET 8.0.11

Com solucionar els errors "hostpolicy.dll" i "singlefilehost.exe" a .NET 8.0.11

Jak odstraňovat chyby 'hostpolicy.dll' a 'singlefilehost.exe' v .NET 8.0.11

Τρόπος αντιμετώπισης σφαλμάτων "hostpolicy.dll" και "singlefilehost.exe" στο .NET 8.0.11

Cómo solucionar los errores 'hostpolicy.dll' y 'singlefilehost.exe' en .NET 8.0.11

نحوه عیب‌یابی خطاهای «hostpolicy.dll» و «singlefilehost.exe» در NET 8.0.11

Kako otkloniti pogreške 'hostpolicy.dll' i 'singlefilehost.exe' u .NET 8.0.11

.NET 8.0.11 での「hostpolicy.dll」および「singlefilehost.exe」エラーのトラブルシューティング方法

.NET 8.0.11 හි 'hostpolicy.dll' සහ 'singlefilehost.exe' දෝෂ නිරාකරණය කරන්නේ කෙසේද?

Maitiro eku Troubleshoot 'hostpolicy.dll' uye 'singlefilehost.exe' Zvakanganisa mu.NET 8.0.11

Чӣ гуна хатогиҳои "hostpolicy.dll" ва "singlefilehost.exe" -ро дар .NET 8.0.11 бартараф кардан мумкин аст

วิธีการแก้ไขปัญหาข้อผิดพลาด 'hostpolicy.dll' และ 'singlefilehost.exe' ใน .NET 8.0.11

Table of Links Abstract and 1 Introduction 2. Related Works 2.1. 2D Diffusion Models for 3D Generation 2.2. 3D Generative Models and 2.3. Multi-view Diffusion Models 3. Problem Formulation 3.1. Diffusion Models 3.2. The Distribution of 3D Assets 4. Method and 4.1. Consistent Multi-view Generation 4.2. Cross-Domain Diffusion 4.3. Textured Mesh Extraction 5. Experiments 5.1. Implementation Details 5.2. Baselines 5.3. Evaluation Protocol 5.4. Single View Reconstruction 5.5. Novel View Synthesis and 5.6. Discussions 6. Conclusions and Future Works, Acknowledgements and References Abstract In this work, we introduce Wonder3D, a novel method for efficiently generating high-fidelity textured meshes from single-view images. Recent methods based on Score Distillation Sampling (SDS) have shown the potential to recover 3D geometry from 2D diffusion priors, but they typically suffer from time-consuming per-shape optimization and inconsistent geometry. In contrast, certain works directly produce 3D information via fast network inferences, but their results are often of low quality and lack geometric details. To holistically improve the quality, consistency, and efficiency of single-view reconstruction tasks, we propose a cross-domain diffusion model that generates multiview normal maps and the corresponding color images. To ensure the consistency of generation, we employ a multiview cross-domain attention mechanism that facilitates information exchange across views and modalities. Lastly, we introduce a geometry-aware normal fusion algorithm that extracts high-quality surfaces from the multi-view 2D representations. Our extensive evaluations demonstrate that our method achieves high-quality reconstruction results, robust generalization, and good efficiency compared to prior works Introduction Reconstructing 3D geometry from a single image stands as a fundamental task in computer graphics and 3D computer vision [12, 25, 31, 33, 35, 38, 41, 44], offering a wide range of versatile applications such as virtual reality, video games, 3D content creation, and the precision of robotics grasping. However, this task is notably challenging since it is ill-posed and demands the ability to discern the 3D geometry of both visible and invisible parts. This ability requires extensive knowledge of the 3D world. knowledge of the 3D world. Recently, the field of 3D generation has experienced rapid and flourishing development with the introduction of diffusion models. A growing body of research [5, 29, 43, 59, 63], such as DreamField [24], DreamFusion [43], and Magic3D [29], resort to distilling prior knowledge of 2D image diffusion models or vision language models to create 3D models from text or images via Score Distillation Sampling (SDS) [43]. Despite their compelling results, these methods suffer from two main limitations: efficiency and consistency. The per-shape optimization process typically entails tens of thousands of iterations, involving full-image volume rendering and inferences of the diffusion models. Consequently, it often consumes tens of minutes or even hours on per-shape optimization. Moreover, the 2D prior model operates by considering only a single view at each iteration and strives to make every view resemble the input image. This often results in the generation of 3D shapes exhibiting inconsistencies, thus, often leading to the generation of 3D shapes with inconsistencies such as multiple faces (i.e., the Janus problem [43]). There exists another group of works that endeavor to directly produce 3D geometries like point clouds [37, 41, 71, 75], meshes [16, 34], neural fields [1, 4, 7, 14, 17, 21, 25– 27, 40, 42, 61, 72] via network inference to avoid timeconsuming per-shape optimization. Most of them attempt to train 3D generative diffusion models from scratch on 3D assets. However, due to the limited size of publicly available 3D datasets, these methods demonstrate poor generalizability, most of which can only generate shapes on specific categories. More recently, several methods have emerged that directly generate multi-view 2D images, with representative works including SyncDreamer [33] and MVDream [51]. By enhancing the multi-view consistency of image generation, these methods can recover 3D shapes from the generated multi-view images. Following these works, our method also adopts a multi-view generation scheme to favor the flexibility and efficiency of 2D representations. However, due to only relying on color images, the fidelity of the generated shapes is not well-maintained, and they struggle to recover geometric details or come with enormous computational costs. To better address the issues of fidelity, consistency, generalizability and efficiency in the aforementioned works, in this paper, we introduce a new approach to the task of single-view 3D reconstruction by generating multi-view consistent normal maps and their corresponding color images with a cross-domain diffusion model. The key idea is to extend the stable diffusion framework to model the joint distribution of two different domains, i.e., normals and colors. We demonstrate that this can be achieved by introducing a domain switcher and a cross-domain attention scheme. In particular, the domain switcher allows the diffusion model to generate either normal maps or color images, while the cross-domain attention mechanisms assist in the information exchange between the two domains, ultimately improving consistency and quality. Finally, in order to stably extract surfaces from the generated views, we propose a geometry-aware normal fusion algorithm that is robust to the inaccuracies and capable of reconstructing clean and high-quality geometries (see Figure 1). We conduct extensive experiments on the Google Scanned Object dataset [13] and various 2D images with different styles. The experiments validate that Wonder3D is capable of producing high-quality geometry with high efficiency in comparison with baseline methods. Wonder3D possesses several distinctive properties and accordingly has the following contributions: • Wonder3D holistically considers the issues of generation quality, efficiency, generalizability, and consistency for 2 single-view 3D reconstruction. It has achieved a leading level of geometric details with reasonably good efficiency among current zero-shot single-view reconstruction methods. • We propose a new multi-view cross-domain 2D diffusion model to predict normal maps and color images. This representation not only adapts to the original data distribution of Stable Diffusion model but also effectively captures the rich surface details of the target shape. • We propose a cross-domain attention mechanism to produce multi-view normal maps and color images that are consistently aligned. This mechanism facilitates information perception across different domains, enabling our method to recover high-fidelity geometry. • We introduce a novel geometry-aware normal fusion algorithm that can robustly extract surfaces from the generated normal maps and color images. This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. Authors:
(1) Xiaoxiao Long, The University of Hong Kong, VAST, MPI Informatik and Equal Contributions;
(2) Yuan-Chen Guo, Tsinghua University, VAST and Equal Contributions.
(3) Cheng Lin, The University of Hong Kong with Corresponding authors;
(4) Yuan Liu, The University of Hong Kong;
(5) Zhiyang Dou, The University of Hong Kong;
(6) Lingjie Liu, University of Pennsylvania;
(7) Yuexin Ma, Shanghai Tech University;
(8) Song-Hai Zhang, The University of Hong Kong;
(9) Marc Habermann, MPI Informatik;
(10) Christian Theobalt, MPI Informatik;
(11) Wenping Wang, Texas A&M University with Corresponding authors. Table of Links Abstract and 1 Introduction Abstract and 1 Introduction 2. Related Works 2.1. 2D Diffusion Models for 3D Generation 2.1. 2D Diffusion Models for 3D Generation 2.2. 3D Generative Models and 2.3. Multi-view Diffusion Models 2.2. 3D Generative Models and 2.3. Multi-view Diffusion Models 3. Problem Formulation 3.1. Diffusion Models 3.1. Diffusion Models 3.2. The Distribution of 3D Assets 3.2. The Distribution of 3D Assets 4. Method and 4.1. Consistent Multi-view Generation 4. Method and 4.1. Consistent Multi-view Generation 4.2. Cross-Domain Diffusion 4.2. Cross-Domain Diffusion 4.3. Textured Mesh Extraction 4.3. Textured Mesh Extraction 5. Experiments 5.1. Implementation Details 5.1. Implementation Details 5.2. Baselines 5.2. Baselines 5.3. Evaluation Protocol 5.3. Evaluation Protocol 5.4. Single View Reconstruction 5.4. Single View Reconstruction 5.5. Novel View Synthesis and 5.6. Discussions 5.5. Novel View Synthesis and 5.6. Discussions 6. Conclusions and Future Works, Acknowledgements and References 6. Conclusions and Future Works, Acknowledgements and References Abstract In this work, we introduce Wonder3D , a novel method for efficiently generating high-fidelity textured meshes from single-view images. Recent methods based on Score Distillation Sampling (SDS) have shown the potential to recover 3D geometry from 2D diffusion priors, but they typically suffer from time-consuming per-shape optimization and inconsistent geometry. In contrast, certain works directly produce 3D information via fast network inferences, but their results are often of low quality and lack geometric details. Wonder3D To holistically improve the quality, consistency, and efficiency of single-view reconstruction tasks, we propose a cross-domain diffusion model that generates multiview normal maps and the corresponding color images. To ensure the consistency of generation, we employ a multiview cross-domain attention mechanism that facilitates information exchange across views and modalities. Lastly, we introduce a geometry-aware normal fusion algorithm that extracts high-quality surfaces from the multi-view 2D representations. Our extensive evaluations demonstrate that our method achieves high-quality reconstruction results, robust generalization, and good efficiency compared to prior works Introduction Reconstructing 3D geometry from a single image stands as a fundamental task in computer graphics and 3D computer vision [12, 25, 31, 33, 35, 38, 41, 44], offering a wide range of versatile applications such as virtual reality, video games, 3D content creation, and the precision of robotics grasping. However, this task is notably challenging since it is ill-posed and demands the ability to discern the 3D geometry of both visible and invisible parts. This ability requires extensive knowledge of the 3D world. knowledge of the 3D world. Recently, the field of 3D generation has experienced rapid and flourishing development with the introduction of diffusion models. A growing body of research [5, 29, 43, 59, 63], such as DreamField [24], DreamFusion [43], and Magic3D [29], resort to distilling prior knowledge of 2D image diffusion models or vision language models to create 3D models from text or images via Score Distillation Sampling (SDS) [43]. Despite their compelling results, these methods suffer from two main limitations: efficiency and consistency. The per-shape optimization process typically entails tens of thousands of iterations, involving full-image volume rendering and inferences of the diffusion models. Consequently, it often consumes tens of minutes or even hours on per-shape optimization. Moreover, the 2D prior model operates by considering only a single view at each iteration and strives to make every view resemble the input image. This often results in the generation of 3D shapes exhibiting inconsistencies, thus, often leading to the generation of 3D shapes with inconsistencies such as multiple faces (i.e., the Janus problem [43]). There exists another group of works that endeavor to directly produce 3D geometries like point clouds [37, 41, 71, 75], meshes [16, 34], neural fields [1, 4, 7, 14, 17, 21, 25– 27, 40, 42, 61, 72] via network inference to avoid timeconsuming per-shape optimization. Most of them attempt to train 3D generative diffusion models from scratch on 3D assets. However, due to the limited size of publicly available 3D datasets, these methods demonstrate poor generalizability, most of which can only generate shapes on specific categories. More recently, several methods have emerged that directly generate multi-view 2D images, with representative works including SyncDreamer [33] and MVDream [51]. By enhancing the multi-view consistency of image generation, these methods can recover 3D shapes from the generated multi-view images. Following these works, our method also adopts a multi-view generation scheme to favor the flexibility and efficiency of 2D representations. However, due to only relying on color images, the fidelity of the generated shapes is not well-maintained, and they struggle to recover geometric details or come with enormous computational costs. To better address the issues of fidelity, consistency, generalizability and efficiency in the aforementioned works, in this paper, we introduce a new approach to the task of single-view 3D reconstruction by generating multi-view consistent normal maps and their corresponding color images with a cross-domain diffusion model. The key idea is to extend the stable diffusion framework to model the joint distribution of two different domains, i.e., normals and colors. We demonstrate that this can be achieved by introducing a domain switcher and a cross-domain attention scheme. In particular, the domain switcher allows the diffusion model to generate either normal maps or color images, while the cross-domain attention mechanisms assist in the information exchange between the two domains, ultimately improving consistency and quality. Finally, in order to stably extract surfaces from the generated views, we propose a geometry-aware normal fusion algorithm that is robust to the inaccuracies and capable of reconstructing clean and high-quality geometries (see Figure 1). We conduct extensive experiments on the Google Scanned Object dataset [13] and various 2D images with different styles. The experiments validate that Wonder3D is capable of producing high-quality geometry with high efficiency in comparison with baseline methods. Wonder3D possesses several distinctive properties and accordingly has the following contributions: • Wonder3D holistically considers the issues of generation quality, efficiency, generalizability, and consistency for 2 single-view 3D reconstruction. It has achieved a leading level of geometric details with reasonably good efficiency among current zero-shot single-view reconstruction methods. • We propose a new multi-view cross-domain 2D diffusion model to predict normal maps and color images. This representation not only adapts to the original data distribution of Stable Diffusion model but also effectively captures the rich surface details of the target shape. • We propose a cross-domain attention mechanism to produce multi-view normal maps and color images that are consistently aligned. This mechanism facilitates information perception across different domains, enabling our method to recover high-fidelity geometry. • We introduce a novel geometry-aware normal fusion algorithm that can robustly extract surfaces from the generated normal maps and color images. This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. available on arxiv Authors: (1) Xiaoxiao Long, The University of Hong Kong, VAST, MPI Informatik and Equal Contributions; (2) Yuan-Chen Guo, Tsinghua University, VAST and Equal Contributions. (3) Cheng Lin, The University of Hong Kong with Corresponding authors; (4) Yuan Liu, The University of Hong Kong; (5) Zhiyang Dou, The University of Hong Kong; (6) Lingjie Liu, University of Pennsylvania; (7) Yuexin Ma, Shanghai Tech University; (8) Song-Hai Zhang, The University of Hong Kong; (9) Marc Habermann, MPI Informatik; (10) Christian Theobalt, MPI Informatik; (11) Wenping Wang, Texas A&M University with Corresponding authors. Authors: Authors: (1) Xiaoxiao Long, The University of Hong Kong, VAST, MPI Informatik and Equal Contributions; (2) Yuan-Chen Guo, Tsinghua University, VAST and Equal Contributions. (3) Cheng Lin, The University of Hong Kong with Corresponding authors; (4) Yuan Liu, The University of Hong Kong; (5) Zhiyang Dou, The University of Hong Kong; (6) Lingjie Liu, University of Pennsylvania; (7) Yuexin Ma, Shanghai Tech University; (8) Song-Hai Zhang, The University of Hong Kong; (9) Marc Habermann, MPI Informatik; (10) Christian Theobalt, MPI Informatik; (11) Wenping Wang, Texas A&M University with Corresponding authors.

What Is Wonder3D? A Method for Generating High-Fidelity Textured Meshes From Single-View Images

Authors:
(1) Hanoona Rasheed, Mohamed bin Zayed University of AI and equally contributing first authors;
(2) Muhammad Maaz, Mohamed bin Zayed University of AI and equally contributing first authors;
(3) Sahal Shaji, Mohamed bin Zayed University of AI;
(4) Abdelrahman Shaker, Mohamed bin Zayed University of AI;
(5) Salman Khan, Mohamed bin Zayed University of AI and Australian National University;
(6) Hisham Cholakkal, Mohamed bin Zayed University of AI;
(7) Rao M. Anwer, Mohamed bin Zayed University of AI and Aalto University;
(8) Eric Xing, Mohamed bin Zayed University of AI and Carnegie Mellon University;
(9) Ming-Hsuan Yang, University of California - Merced and Google Research;
(10) Fahad S. Khan, Mohamed bin Zayed University of AI and Linköping University. Editor's Note: This is Part 9 of 10 of a study detailing the development of an AI model that is designed to describe images to users. Read the rest below. Table of Links Abstract and 1 Introduction
2. Related Work
3. Method
4. Data Annotation Pipeline
5. Experiments
6. Conclusion and References Supplementary Material (Part 1) A. Additional Implementation Details
B. Additional Downstream Tasks
C. Additional Qualitative Results Supplementary Material (Part 2) D. Dataset Visualization
E. Limitations and Future Work
F. Ethics and Societal Impact C. Additional Qualitative Results In this section, we provide more qualitative examples to better understand the capacity of GLaMM. C.1. Grounded Conversation Generation (GCG) Fig. 7 shows qualitative results of GLaMM finetuned on GranDf dataset. The model could produce dense captions and provide dense pixel-level groundings of the caption. C.2. Referring Segmentation Fig. 8 shows the effectiveness of GLaMM in understanding the natural language query and segmenting the corresponding objects. Note that GLaMM can also segment multiple objects via multi-round conversations. C.3. Region-level Captioning Fig. 9 shows the qualitative results of GLaMM for regionlevel understanding. Our model can generate detailed descriptions about the user-specified regions in an image. C.4. Image-level Captioning Fig. 10 shows GLaMM’s qualitative results on captioning tasks. Our model can generate dense captions for images. C.5. Conditional Image Generation Fig. 12 shows GLaMM’s seamless integration for generative tasks. We use the Stable Diffusion inpainting model stable-diffusion-xl-1.0-inpainting [41] for this task. We first generate a segmentation mask using our GlaMM model based on the user query. This segmentation mask along with the user prompt is given as the input to the Stable Diffusion inpainting model, which generates the final output. Figure 14. Dataset samples from GranDf. The figure shows the GPT4 [34] prompts used and the created dataset samples from Grandf dataset. This repurposed human-annotated dataset provides rich semantics to GLaMM for GCG task. C.6. Conversations Fig. 13 illustrates the unique functionality of GLaMM to engage in multi-purpose task conversations. GLaMM is a generic conversational model that can accept prompts in the form of text and/or region and can answer in the form of text and/or segmentation masks. Note that our model is not explicitly trained to handle such scenarios, and this behavior emerges mainly due to our pretraining on GranD dataset, where an image is presented to LMM in different contexts. This paper is available on arxiv under CC BY 4.0 DEED license. Authors: (1) Hanoona Rasheed, Mohamed bin Zayed University of AI and equally contributing first authors; (2) Muhammad Maaz, Mohamed bin Zayed University of AI and equally contributing first authors; (3) Sahal Shaji, Mohamed bin Zayed University of AI; (4) Abdelrahman Shaker, Mohamed bin Zayed University of AI; (5) Salman Khan, Mohamed bin Zayed University of AI and Australian National University; (6) Hisham Cholakkal, Mohamed bin Zayed University of AI; (7) Rao M. Anwer, Mohamed bin Zayed University of AI and Aalto University; (8) Eric Xing, Mohamed bin Zayed University of AI and Carnegie Mellon University; (9) Ming-Hsuan Yang, University of California - Merced and Google Research; (10) Fahad S. Khan, Mohamed bin Zayed University of AI and Linköping University. Authors: Authors: (1) Hanoona Rasheed, Mohamed bin Zayed University of AI and equally contributing first authors; (2) Muhammad Maaz, Mohamed bin Zayed University of AI and equally contributing first authors; (3) Sahal Shaji, Mohamed bin Zayed University of AI; (4) Abdelrahman Shaker, Mohamed bin Zayed University of AI; (5) Salman Khan, Mohamed bin Zayed University of AI and Australian National University; (6) Hisham Cholakkal, Mohamed bin Zayed University of AI; (7) Rao M. Anwer, Mohamed bin Zayed University of AI and Aalto University; (8) Eric Xing, Mohamed bin Zayed University of AI and Carnegie Mellon University; (9) Ming-Hsuan Yang, University of California - Merced and Google Research; (10) Fahad S. Khan, Mohamed bin Zayed University of AI and Linköping University. Editor's Note: This is Part 9 of 10 of a study detailing the development of an AI model that is designed to describe images to users. Read the rest below. Editor's Note: This is Part 9 of 10 of a study detailing the development of an AI model that is designed to describe images to users. Read the rest below. Editor's Note: This is Part 9 of 10 of a study detailing the development of an AI model that is designed to describe images to users. Read the rest below. Editor's Note: This is Part 9 of 10 of a study detailing the development of an AI model that is designed to describe images to users. Read the rest below. Table of Links Abstract and 1 Introduction 2. Related Work 3. Method 4. Data Annotation Pipeline 5. Experiments 6. Conclusion and References Abstract and 1 Introduction Abstract and 1 Introduction 2. Related Work 2. Related Work 3. Method 3. Method 4. Data Annotation Pipeline 4. Data Annotation Pipeline 5. Experiments 5. Experiments 6. Conclusion and References 6. Conclusion and References Supplementary Material (Part 1) Supplementary Material (Part 1) A. Additional Implementation Details B. Additional Downstream Tasks C. Additional Qualitative Results A. Additional Implementation Details A. Additional Implementation Details B. Additional Downstream Tasks B. Additional Downstream Tasks C. Additional Qualitative Results C. Additional Qualitative Results Supplementary Material (Part 2) Supplementary Material (Part 2) D. Dataset Visualization E. Limitations and Future Work F. Ethics and Societal Impact D. Dataset Visualization D. Dataset Visualization E. Limitations and Future Work E. Limitations and Future Work F. Ethics and Societal Impact F. Ethics and Societal Impact C. Additional Qualitative Results In this section, we provide more qualitative examples to better understand the capacity of GLaMM. C.1. Grounded Conversation Generation (GCG) Fig. 7 shows qualitative results of GLaMM finetuned on GranD f dataset. The model could produce dense captions and provide dense pixel-level groundings of the caption. f C.2. Referring Segmentation Fig. 8 shows the effectiveness of GLaMM in understanding the natural language query and segmenting the corresponding objects. Note that GLaMM can also segment multiple objects via multi-round conversations. C.3. Region-level Captioning Fig. 9 shows the qualitative results of GLaMM for regionlevel understanding. Our model can generate detailed descriptions about the user-specified regions in an image. C.4. Image-level Captioning Fig. 10 shows GLaMM’s qualitative results on captioning tasks. Our model can generate dense captions for images. C.5. Conditional Image Generation Fig. 12 shows GLaMM’s seamless integration for generative tasks. We use the Stable Diffusion inpainting model stable-diffusion-xl-1.0-inpainting [41] for this task. We first generate a segmentation mask using our GlaMM model based on the user query. This segmentation mask along with the user prompt is given as the input to the Stable Diffusion inpainting model, which generates the final output. Figure 14. Dataset samples from GranDf. The figure shows the GPT4 [34] prompts used and the created dataset samples from Grandf dataset. This repurposed human-annotated dataset provides rich semantics to GLaMM for GCG task. Dataset samples from GranD f . f C.6. Conversations Fig. 13 illustrates the unique functionality of GLaMM to engage in multi-purpose task conversations. GLaMM is a generic conversational model that can accept prompts in the form of text and/or region and can answer in the form of text and/or segmentation masks. Note that our model is not explicitly trained to handle such scenarios, and this behavior emerges mainly due to our pretraining on GranD dataset, where an image is presented to LMM in different contexts. This paper is available on arxiv under CC BY 4.0 DEED license. This paper is available on arxiv under CC BY 4.0 DEED license. available on arxiv

This New AI Can See, Talk, and Even Edit Images in a Single Conversation

This article outlines how to transition from singletons to dependency injection in a SwiftUI app with minimal effort. If you're here, you likely already know that you should avoid singletons with various of reasons like: Hidden Dependencies: Classes rely on singletons without explicit indicators, making it harder to track app dependencies and leading to unintended coupling.
Circular Dependencies: Singletons depending on each other can create cycles, leading to initialization deadlocks as instances wait for each other.
Testing Challenges: Using singletons complicates testing and SwiftUI previews since singletons can't easily be swapped for mocks. Lack of Flexibility: Singletons make it difficult to provide different implementations for different environments (e.g., live vs. mock versions for testing). And many others. Dependency Injection To overcome most issues we can use Dependency injection (DI). Using it, swapping in a new implementation becomes much easier, as components don’t rely on a single shared instance but on protocols that can be implemented in different ways. This promotes flexibility, easier testing, and adaptability as app requirements evolve. Constructor Injection Constructor injection is a straightforward technique for injecting dependencies by passing them through initializers. While effective, it often increases the size and complexity of initializers. A common challenge with constructor injection is passing dependencies through a deep UI hierarchy. If a dependency is only needed on a specific screen but must be passed down through multiple intermediary screens, this can quickly become cumbersome. One way to handle this is by using the Coordinator pattern, which centralizes navigation and manages dependencies more efficiently. Check out this article to learn how to make it. Why Not Use @EnvironmentObject? While @EnvironmentObject simplifies dependency sharing in SwiftUI, it has limitations: It only works with ObservableObject
It doesn’t allow using protocols for implementation switching.
It only works in SwiftUI views hierarchy
It only checks for service existence when accessed, increasing the risk of unintentional omissions in views. Dependency injection with property wrappers This is similar to the @EnvironmentObject solution where the dependency management happens inside of property wrappers, but without drawbacks. DependencyContainer This small library contains only a couple files, can be copied directly into your project or integrated via SPM. Please, make sure you put a star on it if you like it. Here is the link on GitHub. Let’s create an example of the service we need to pass as a dependency. As we are assuming that we are going to make a mock for testing, we need to implement our service as a protocol. Also we make it as ObservableObject, to review additional features of the framework. import Combine

protocol DataRepository: Actor, ObservableObject {
    
    func fetchData() async throws
}

actor DataRepositoryImp: DataRepository {
    
    func fetchData() async throws {
        // do real stuff
    }
}

actor DataRepositoryMock: DataRepository {
    
    func fetchData() async throws {
        // do mocked stuff
    }
} Defining a DI container Once integrated, you’ll set up a DI container to manage your services. Each service requires a unique key. You have no limitations in creating keys with the same service type. import DependencyContainer

extension DI {
    static let data = Key<any DataRepository>()
} Next let’s create a function for registering service in DI Container. extension DI.Container {
    
    static func setup() {
        register(DI.data, DataRepositoryImp())
    }
} Then, call this function at app startup. @main
struct ExampleApp: App {
    
    @MainActor final class AppState: ObservableObject {
        
        init() {
            DI.Container.setup()
        }
    }
    @StateObject var state = AppState()
    
    var body: some Scene {
        WindowGroup {
            MainView()
        }
    }
} Injecting Dependencies The actual injection is done with several property wrappers. The most common one is @DI.Static. You just need to pass a key we defined earlier. struct MainView: View {
    
    @DI.Static(DI.data) var data
    
    var body: some View {
        Color.clear.task {
            try? await data.fetchData()
        }
    }
} The points we need to make attention to: No Need to Specify Type. As you may have noticed we don’t need to write a type here, because Swift gets the type from the key.
It’s very convenient in case you start with a concrete type for your service and later decide to use a protocol to enable mocking. You only need to update the type in the key definition. This change propagates automatically without requiring updates to any code referencing that service. Dependency Existence Checked on Initialization. The property wrapper checks that the service exists when initialized. This helps prevent accidental circular dependencies, where services might try to reference each other. The framework enforces a clear initialization order, encouraging thoughtful dependency management and avoiding deadlocks. Additional property wrappers: @DI.Observed Use this in SwiftUI views when your service is ObservableObject. Views will be updated when the service is changed. struct MainView: View {
    
    //updates the view when data is posting objectWillChange
    @DI.Observed(DI.data) var data
    
    var body: some View {
        Color.clear.task {
            try? await data.fetchData()
        }
    }
} @DI.RePublished Should be used in ObservableObject. If your service is ObservableObject, the update will be republished further by the owner of the property wrapper. struct MainView: View {
    
    final class State: ObservableObject {
        
        // Republishes the data.objectWillChange to the State.objectWillChange
        // The view will be updated
        @DI.RePublished(DI.data) var data
    }
    
    @StateObject var state = State()
    
    var body: some View {
        Color.clear.task {
            try? await data.fetchData()
        }
    }
} In addition, if you have nested services you can use a key path in property wrappers. In this case the observing logic uses the service referenced by a keypath. @DI.Static(DI.data, \.innerService) var innerService

@DI.Observed(DI.data, \.innerService) var innerService

@DI.RePublished(DI.data, \.innerService) var innerService Mocking To swap out implementations for testing or previews, you have two options: Initialize with mocked dependency
MainView(data: .init(value: DataRepositoryMock())) Replace service with mock in DI Container
DI.Container.register(DI.data, DataRepositoryMock())
    
MainView() Conclusion This guide provides a straightforward approach to adopting DI using a DependencyContainer framework and moving away from singletons, enhancing flexibility, modularity, and testability in your iOS apps. This article outlines how to transition from singletons to dependency injection in a SwiftUI app with minimal effort. singletons dependency injection minimal If you're here, you likely already know that you should avoid singletons with various of reasons like: reasons Hidden Dependencies: Classes rely on singletons without explicit indicators, making it harder to track app dependencies and leading to unintended coupling. Circular Dependencies: Singletons depending on each other can create cycles, leading to initialization deadlocks as instances wait for each other. Testing Challenges: Using singletons complicates testing and SwiftUI previews since singletons can't easily be swapped for mocks. Hidden Dependencies: Classes rely on singletons without explicit indicators, making it harder to track app dependencies and leading to unintended coupling. Hidden Dependencies: Circular Dependencies: Singletons depending on each other can create cycles, leading to initialization deadlocks as instances wait for each other. Circular Dependencies: Testing Challenges : Using singletons complicates testing and SwiftUI previews since singletons can't easily be swapped for mocks. Testing Challenges Lack of Flexibility : Singletons make it difficult to provide different implementations for different environments (e.g., live vs. mock versions for testing). Lack of Flexibility And many others. Dependency Injection Dependency Injection To overcome most issues we can use Dependency injection (DI). Using it, swapping in a new implementation becomes much easier, as components don’t rely on a single shared instance but on protocols that can be implemented in different ways. This promotes flexibility, easier testing, and adaptability as app requirements evolve. Dependency injection protocols Constructor Injection Constructor Injection Constructor injection is a straightforward technique for injecting dependencies by passing them through initializers . While effective, it often increases the size and complexity of initializers. initializers A common challenge with constructor injection is passing dependencies through a deep UI hierarchy . If a dependency is only needed on a specific screen but must be passed down through multiple intermediary screens, this can quickly become cumbersome. deep UI hierarchy One way to handle this is by using the Coordinator pattern, which centralizes navigation and manages dependencies more efficiently. Check out this article to learn how to make it. Coordinator this article this article this article Why Not Use @EnvironmentObject ? Why Not Use @EnvironmentObject ? While @EnvironmentObject simplifies dependency sharing in SwiftUI, it has limitations : @EnvironmentObject limitations It only works with ObservableObject It doesn’t allow using protocols for implementation switching. It only works in SwiftUI views hierarchy It only checks for service existence when accessed, increasing the risk of unintentional omissions in views. It only works with ObservableObject ObservableObject It doesn’t allow using protocols for implementation switching. protocols It only works in SwiftUI views hierarchy views It only checks for service existence when accessed, increasing the risk of unintentional omissions in views. existence Dependency injection with property wrappers Dependency injection with property wrappers This is similar to the @EnvironmentObject solution where the dependency management happens inside of property wrappers , but without drawbacks. @EnvironmentObject property wrappers DependencyContainer DependencyContainer This small library contains only a couple files , can be copied directly into your project or integrated via SPM . couple files SPM Please, make sure you put a star on it if you like it. star Here is the link on GitHub . link on GitHub link on GitHub link on GitHub link on GitHub Let’s create an example of the service we need to pass as a dependency. As we are assuming that we are going to make a mock for testing, we need to implement our service as a protocol. Also we make it as ObservableObject , to review additional features of the framework. ObservableObject import Combine

protocol DataRepository: Actor, ObservableObject {
    
    func fetchData() async throws
}

actor DataRepositoryImp: DataRepository {
    
    func fetchData() async throws {
        // do real stuff
    }
}

actor DataRepositoryMock: DataRepository {
    
    func fetchData() async throws {
        // do mocked stuff
    }
} import Combine

protocol DataRepository: Actor, ObservableObject {
    
    func fetchData() async throws
}

actor DataRepositoryImp: DataRepository {
    
    func fetchData() async throws {
        // do real stuff
    }
}

actor DataRepositoryMock: DataRepository {
    
    func fetchData() async throws {
        // do mocked stuff
    }
} Defining a DI container Defining a DI container Once integrated, you’ll set up a DI container to manage your services. Each service requires a unique key. You have no limitations in creating keys with the same service type . DI container unique key. service type import DependencyContainer

extension DI {
    static let data = Key<any DataRepository>()
} import DependencyContainer

extension DI {
    static let data = Key<any DataRepository>()
} Next let’s create a function for registering service in DI Container. function extension DI.Container {
    
    static func setup() {
        register(DI.data, DataRepositoryImp())
    }
} extension DI.Container {
    
    static func setup() {
        register(DI.data, DataRepositoryImp())
    }
} Then, call this function at app startup . app startup @main
struct ExampleApp: App {
    
    @MainActor final class AppState: ObservableObject {
        
        init() {
            DI.Container.setup()
        }
    }
    @StateObject var state = AppState()
    
    var body: some Scene {
        WindowGroup {
            MainView()
        }
    }
} @main
struct ExampleApp: App {
    
    @MainActor final class AppState: ObservableObject {
        
        init() {
            DI.Container.setup()
        }
    }
    @StateObject var state = AppState()
    
    var body: some Scene {
        WindowGroup {
            MainView()
        }
    }
} Injecting Dependencies Injecting Dependencies The actual injection is done with several property wrappers. The most common one is @DI.Static . You just need to pass a key we defined earlier. injection common @DI.Static key struct MainView: View {
    
    @DI.Static(DI.data) var data
    
    var body: some View {
        Color.clear.task {
            try? await data.fetchData()
        }
    }
} struct MainView: View {
    
    @DI.Static(DI.data) var data
    
    var body: some View {
        Color.clear.task {
            try? await data.fetchData()
        }
    }
} The points we need to make attention to: attention No Need to Specify Type. As you may have noticed we don’t need to write a type here, because Swift gets the type from the key.
It’s very convenient in case you start with a concrete type for your service and later decide to use a protocol to enable mocking. You only need to update the type in the key definition. This change propagates automatically without requiring updates to any code referencing that service. No Need to Specify Type. As you may have noticed we don’t need to write a type here, because Swift gets the type from the key. It’s very convenient in case you start with a concrete type for your service and later decide to use a protocol to enable mocking. You only need to update the type in the key definition. This change propagates automatically without requiring updates to any code referencing that service. No Need to Specify Type. As you may have noticed we don’t need to write a type here, because Swift gets the type from the key. No Need to Specify Type. type It’s very convenient in case you start with a concrete type for your service and later decide to use a protocol to enable mocking. You only need to update the type in the key definition. This change propagates automatically without requiring updates to any code referencing that service. concrete type protocol Dependency Existence Checked on Initialization. The property wrapper checks that the service exists when initialized. This helps prevent accidental circular dependencies, where services might try to reference each other. The framework enforces a clear initialization order, encouraging thoughtful dependency management and avoiding deadlocks. Dependency Existence Checked on Initialization. The property wrapper checks that the service exists when initialized . This helps prevent accidental circular dependencies, where services might try to reference each other. The framework enforces a clear initialization order, encouraging thoughtful dependency management and avoiding deadlocks . Dependency Existence Checked on Initialization. initialized deadlocks Additional property wrappers: @DI.Observed Use this in SwiftUI views when your service is ObservableObject . Views will be updated when the service is changed. @DI.Observed ObservableObject struct MainView: View {
    
    //updates the view when data is posting objectWillChange
    @DI.Observed(DI.data) var data
    
    var body: some View {
        Color.clear.task {
            try? await data.fetchData()
        }
    }
} struct MainView: View {
    
    //updates the view when data is posting objectWillChange
    @DI.Observed(DI.data) var data
    
    var body: some View {
        Color.clear.task {
            try? await data.fetchData()
        }
    }
} @DI.RePublished Should be used in ObservableObject . If your service is ObservableObject , the update will be republished further by the owner of the property wrapper. @DI.RePublished ObservableObject ObservableObject struct MainView: View {
    
    final class State: ObservableObject {
        
        // Republishes the data.objectWillChange to the State.objectWillChange
        // The view will be updated
        @DI.RePublished(DI.data) var data
    }
    
    @StateObject var state = State()
    
    var body: some View {
        Color.clear.task {
            try? await data.fetchData()
        }
    }
} struct MainView: View {
    
    final class State: ObservableObject {
        
        // Republishes the data.objectWillChange to the State.objectWillChange
        // The view will be updated
        @DI.RePublished(DI.data) var data
    }
    
    @StateObject var state = State()
    
    var body: some View {
        Color.clear.task {
            try? await data.fetchData()
        }
    }
} In addition, if you have nested services you can use a key path in property wrappers. In this case the observing logic uses the service referenced by a keypath. key path observing logic @DI.Static(DI.data, \.innerService) var innerService

@DI.Observed(DI.data, \.innerService) var innerService

@DI.RePublished(DI.data, \.innerService) var innerService @DI.Static(DI.data, \.innerService) var innerService

@DI.Observed(DI.data, \.innerService) var innerService

@DI.RePublished(DI.data, \.innerService) var innerService Mocking Mocking To swap out implementations for testing or previews, you have two options: Initialize with mocked dependency
MainView(data: .init(value: DataRepositoryMock())) Initialize with mocked dependency MainView(data: .init(value: DataRepositoryMock())) Initialize with mocked dependency MainView(data: .init(value: DataRepositoryMock())) MainView(data: .init(value: DataRepositoryMock())) Replace service with mock in DI Container
DI.Container.register(DI.data, DataRepositoryMock())
    
MainView() Replace service with mock in DI Container DI.Container.register(DI.data, DataRepositoryMock())
    
MainView() Replace service with mock in DI Container DI.Container.register(DI.data, DataRepositoryMock())
    
MainView() DI.Container.register(DI.data, DataRepositoryMock())
    
MainView() Conclusion Conclusion This guide provides a straightforward approach to adopting DI using a DependencyContainer framework and moving away from singletons, enhancing flexibility, modularity, and testability in your iOS apps. DependencyContainer DependencyContainer DependencyContainer DependencyContainer

How to Stop Making Singletons in Swift: A Dependency Injection Guide

Breaking Free from the Evil Singleton TL;DR: Refactor singletons to reduce coupling Problems Addressed High coupling
Difficult testability
Multi-threading issues Related Code Smells https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-vii-8dk31x0?embedable=true https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-v-evj3zs9?embedable=true https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-v-evj3zs9?embedable=true Steps Identify the singleton
Locate all references to its getInstance() method
Refactor the singleton to a standard class
Inject it as a dependency Sample Code Before public class DatabaseConnection {
    private static DatabaseConnection instance;

    private DatabaseConnection() {}

    public static DatabaseConnection getInstance() {
        if (instance == null) {
            instance = new DatabaseConnection();
        }
        return instance;
    }

    public void connect() { 
    }
}

public class Service {
    public void performTask() {
        DatabaseConnection connection = DatabaseConnection.getInstance();
        connection.connect(); 
    }
} After public class DatabaseConnection {  
    // 1. Identify the singleton 
    public void connect() { 
    }
}

public class Service {
    // 2. Locate all references to its getInstance() method.
    private DatabaseConnection connection;

    // 3. Refactor the singleton to a standard class. 
    public Service(DatabaseConnection connection) {
        // 4. Inject it as a dependency.
        this.connection = connection;
    }

    public void performTask() {
        connection.connect(); 
    }
}

DatabaseConnection connection = new DatabaseConnection();
// You can also mock the connection in your tests

Service service = new Service(connection);
service.performTask(); Type [x]Semi-Automatic Safety This refactoring is safe when you update all references to the singleton and handle its dependencies correctly. Testing each step ensures that no references to the singleton are missed. Why Is the Code Better? Refactoring away from a singleton makes the code more modular, testable, and less prone to issues caused by the global state. Injecting dependencies allows you to easily replace DatabaseConnection with a mock or different implementation in testing and other contexts. Tags Coupling Related Refactorings https://maximilianocontieri.com/refactoring-007-extract-class?embedable=true See also https://hackernoon.com/singleton-pattern-the-root-of-all-evil-e4r3up7?embedable=true https://hackernoon.com/coupling-the-one-and-only-software-designing-problem-9z5a321h?embedable=true Credits Image by PublicDomainPictures from Pixabay This article is part of the Refactoring Series. How to Improve Your Code With Easy Refactorings Breaking Free from the Evil Singleton Breaking Free from the Evil Singleton TL;DR: Refactor singletons to reduce coupling TL;DR: Refactor singletons to reduce coupling Problems Addressed High coupling Difficult testability Multi-threading issues High coupling coupling Difficult testability testability Multi-threading issues Related Code Smells https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-vii-8dk31x0?embedable=true https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-vii-8dk31x0?embedable=true https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-v-evj3zs9?embedable=true https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-v-evj3zs9?embedable=true https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-v-evj3zs9?embedable=true https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-v-evj3zs9?embedable=true Steps Identify the singleton Locate all references to its getInstance() method Refactor the singleton to a standard class Inject it as a dependency Identify the singleton Locate all references to its getInstance() method getInstance() Refactor the singleton to a standard class Inject it as a dependency Sample Code Before public class DatabaseConnection {
    private static DatabaseConnection instance;

    private DatabaseConnection() {}

    public static DatabaseConnection getInstance() {
        if (instance == null) {
            instance = new DatabaseConnection();
        }
        return instance;
    }

    public void connect() { 
    }
}

public class Service {
    public void performTask() {
        DatabaseConnection connection = DatabaseConnection.getInstance();
        connection.connect(); 
    }
} public class DatabaseConnection {
    private static DatabaseConnection instance;

    private DatabaseConnection() {}

    public static DatabaseConnection getInstance() {
        if (instance == null) {
            instance = new DatabaseConnection();
        }
        return instance;
    }

    public void connect() { 
    }
}

public class Service {
    public void performTask() {
        DatabaseConnection connection = DatabaseConnection.getInstance();
        connection.connect(); 
    }
} After public class DatabaseConnection {  
    // 1. Identify the singleton 
    public void connect() { 
    }
}

public class Service {
    // 2. Locate all references to its getInstance() method.
    private DatabaseConnection connection;

    // 3. Refactor the singleton to a standard class. 
    public Service(DatabaseConnection connection) {
        // 4. Inject it as a dependency.
        this.connection = connection;
    }

    public void performTask() {
        connection.connect(); 
    }
}

DatabaseConnection connection = new DatabaseConnection();
// You can also mock the connection in your tests

Service service = new Service(connection);
service.performTask(); public class DatabaseConnection {  
    // 1. Identify the singleton 
    public void connect() { 
    }
}

public class Service {
    // 2. Locate all references to its getInstance() method.
    private DatabaseConnection connection;

    // 3. Refactor the singleton to a standard class. 
    public Service(DatabaseConnection connection) {
        // 4. Inject it as a dependency.
        this.connection = connection;
    }

    public void performTask() {
        connection.connect(); 
    }
}

DatabaseConnection connection = new DatabaseConnection();
// You can also mock the connection in your tests

Service service = new Service(connection);
service.performTask(); Type [x]Semi-Automatic [x] Semi-Automatic [x] Safety This refactoring is safe when you update all references to the singleton and handle its dependencies correctly. Testing each step ensures that no references to the singleton are missed. Why Is the Code Better? Refactoring away from a singleton makes the code more modular, testable, and less prone to issues caused by the global state. Injecting dependencies allows you to easily replace DatabaseConnection with a mock or different implementation in testing and other contexts. Tags Coupling Coupling Related Refactorings https://maximilianocontieri.com/refactoring-007-extract-class?embedable=true https://maximilianocontieri.com/refactoring-007-extract-class?embedable=true See also https://hackernoon.com/singleton-pattern-the-root-of-all-evil-e4r3up7?embedable=true https://hackernoon.com/singleton-pattern-the-root-of-all-evil-e4r3up7?embedable=true https://hackernoon.com/coupling-the-one-and-only-software-designing-problem-9z5a321h?embedable=true https://hackernoon.com/coupling-the-one-and-only-software-designing-problem-9z5a321h?embedable=true Credits Image by PublicDomainPictures from Pixabay PublicDomainPictures Pixabay This article is part of the Refactoring Series. How to Improve Your Code With Easy Refactorings How to Improve Your Code With Easy Refactorings

Refactoring 018 - How to Replace a Singleton

Authors:
(1) Dustin Podell, Stability AI, Applied Research;
(2) Zion English, Stability AI, Applied Research;
(3) Kyle Lacey, Stability AI, Applied Research;
(4) Andreas Blattmann, Stability AI, Applied Research;
(5) Tim Dockhorn, Stability AI, Applied Research;
(6) Jonas Müller, Stability AI, Applied Research;
(7) Joe Penna, Stability AI, Applied Research;
(8) Robin Rombach, Stability AI, Applied Research. Table of Links Abstract and 1 Introduction 2 Improving Stable Diffusion 2.1 Architecture & Scale 2.2 Micro-Conditioning 2.3 Multi-Aspect Training 2.4 Improved Autoencoder and 2.5 Putting Everything Together 3 Future Work Appendix A Acknowledgements B Limitations C Diffusion Models D Comparison to the State of the Art E Comparison to Midjourney v5.1 F On FID Assessment of Generative Text-Image Foundation Models G Additional Comparison between Single- and Two-Stage SDXL pipeline References G Additional Comparison between Single- and Two-Stage SDXL pipeline H Comparison between SD 1.5 vs. SD 2.1 vs. SDXL I Multi-Aspect Training Hyperparameters We use the following image resolutions for mixed-aspect ratio finetuning as described in Sec. 2.3. J Pseudo-code for Conditioning Concatenation along the Channel Axis This paper is available on arxiv under CC BY 4.0 DEED license. Authors: (1) Dustin Podell, Stability AI, Applied Research; (2) Zion English, Stability AI, Applied Research; (3) Kyle Lacey, Stability AI, Applied Research; (4) Andreas Blattmann, Stability AI, Applied Research; (5) Tim Dockhorn, Stability AI, Applied Research; (6) Jonas Müller, Stability AI, Applied Research; (7) Joe Penna, Stability AI, Applied Research; (8) Robin Rombach, Stability AI, Applied Research. Authors: Authors: (1) Dustin Podell, Stability AI, Applied Research; (2) Zion English, Stability AI, Applied Research; (3) Kyle Lacey, Stability AI, Applied Research; (4) Andreas Blattmann, Stability AI, Applied Research; (5) Tim Dockhorn, Stability AI, Applied Research; (6) Jonas Müller, Stability AI, Applied Research; (7) Joe Penna, Stability AI, Applied Research; (8) Robin Rombach, Stability AI, Applied Research. Table of Links Abstract and 1 Introduction Abstract and 1 Introduction 2 Improving Stable Diffusion 2 Improving Stable Diffusion 2.1 Architecture & Scale 2.1 Architecture & Scale 2.2 Micro-Conditioning 2.2 Micro-Conditioning 2.3 Multi-Aspect Training 2.3 Multi-Aspect Training 2.4 Improved Autoencoder and 2.5 Putting Everything Together 2.4 Improved Autoencoder and 2.5 Putting Everything Together 3 Future Work 3 Future Work Appendix Appendix A Acknowledgements A Acknowledgements B Limitations B Limitations C Diffusion Models C Diffusion Models D Comparison to the State of the Art D Comparison to the State of the Art E Comparison to Midjourney v5.1 E Comparison to Midjourney v5.1 F On FID Assessment of Generative Text-Image Foundation Models F On FID Assessment of Generative Text-Image Foundation Models G Additional Comparison between Single- and Two-Stage SDXL pipeline G Additional Comparison between Single- and Two-Stage SDXL pipeline References References G Additional Comparison between Single- and Two-Stage SDXL pipeline H Comparison between SD 1.5 vs. SD 2.1 vs. SDXL I Multi-Aspect Training Hyperparameters We use the following image resolutions for mixed-aspect ratio finetuning as described in Sec. 2.3. J Pseudo-code for Conditioning Concatenation along the Channel Axis This paper is available on arxiv under CC BY 4.0 DEED license. This paper is available on arxiv under CC BY 4.0 DEED license. available on arxiv

Additional Comparison between Single- and Two-Stage SDXL pipeline

Authors:
(1) Seokil Ham, KAIST;
(2) Jungwuk Park, KAIST;
(3) Dong-Jun Han, Purdue University;
(4) Jaekyun Moon, KAIST. Table of Links Abstract and 1. Introduction 2. Related Works 3. Proposed NEO-KD Algorithm and 3.1 Problem Setup: Adversarial Training in Multi-Exit Networks 3.2 Algorithm Description 4. Experiments and 4.1 Experimental Setup 4.2. Main Experimental Results 4.3. Ablation Studies and Discussions 5. Conclusion, Acknowledgement and References A. Experiment Details B. Clean Test Accuracy and C. Adversarial Training via Average Attack D. Hyperparameter Tuning E. Discussions on Performance Degradation at Later Exits F. Comparison with Recent Defense Methods for Single-Exit Networks G. Comparison with SKD and ARD and H. Implementations of Stronger Attacker Algorithms F Comparison with Recent Defense Methods for Single-Exit Networks The baselines in the main paper were generally the adversarial defense methods designed for multi-exit networks. In this section, we conduct additional experiments with a recent defense method, TEAT [7], and compare with our method. Since TEAT was originally designed for the single-exit network, we first adapt TEAT to the multi-exit network setting. Instead of the original TEAT that generates the adversarial examples considering the final output of the network, we modify TEAT to generate adversarial examples that maximizes the average loss of all exits in the multi-exit network. Table A3 below shows the results using max-average attack on CIFAR-10/100. It can be seen that our NEO-KD, which is designed for multi-exit networks, achieves higher adversarial test accuracy compared to the TEAT methods (PGD-TE and TRADES-TE) designed for single-exit networks. The results highlight the necessity of developing adversarial defense techniques geared to multi-exit networks rather than adapting general defense methods used for single-exit networks. This paper is available on arxiv under CC 4.0 license. Authors: (1) Seokil Ham, KAIST; (2) Jungwuk Park, KAIST; (3) Dong-Jun Han, Purdue University; (4) Jaekyun Moon, KAIST. Authors: Authors: (1) Seokil Ham, KAIST; (2) Jungwuk Park, KAIST; (3) Dong-Jun Han, Purdue University; (4) Jaekyun Moon, KAIST. Table of Links Abstract and 1. Introduction Abstract and 1. Introduction 2. Related Works 2. Related Works 3. Proposed NEO-KD Algorithm and 3.1 Problem Setup: Adversarial Training in Multi-Exit Networks 3. Proposed NEO-KD Algorithm and 3.1 Problem Setup: Adversarial Training in Multi-Exit Networks 3.2 Algorithm Description 3.2 Algorithm Description 4. Experiments and 4.1 Experimental Setup 4. Experiments and 4.1 Experimental Setup 4.2. Main Experimental Results 4.2. Main Experimental Results 4.3. Ablation Studies and Discussions 4.3. Ablation Studies and Discussions 5. Conclusion, Acknowledgement and References 5. Conclusion, Acknowledgement and References A. Experiment Details A. Experiment Details B. Clean Test Accuracy and C. Adversarial Training via Average Attack B. Clean Test Accuracy and C. Adversarial Training via Average Attack D. Hyperparameter Tuning D. Hyperparameter Tuning E. Discussions on Performance Degradation at Later Exits E. Discussions on Performance Degradation at Later Exits F. Comparison with Recent Defense Methods for Single-Exit Networks F. Comparison with Recent Defense Methods for Single-Exit Networks G. Comparison with SKD and ARD and H. Implementations of Stronger Attacker Algorithms G. Comparison with SKD and ARD and H. Implementations of Stronger Attacker Algorithms F Comparison with Recent Defense Methods for Single-Exit Networks The baselines in the main paper were generally the adversarial defense methods designed for multi-exit networks. In this section, we conduct additional experiments with a recent defense method, TEAT [7], and compare with our method. Since TEAT was originally designed for the single-exit network, we first adapt TEAT to the multi-exit network setting. Instead of the original TEAT that generates the adversarial examples considering the final output of the network, we modify TEAT to generate adversarial examples that maximizes the average loss of all exits in the multi-exit network. Table A3 below shows the results using max-average attack on CIFAR-10/100. It can be seen that our NEO-KD, which is designed for multi-exit networks, achieves higher adversarial test accuracy compared to the TEAT methods (PGD-TE and TRADES-TE) designed for single-exit networks. The results highlight the necessity of developing adversarial defense techniques geared to multi-exit networks rather than adapting general defense methods used for single-exit networks. This paper is available on arxiv under CC 4.0 license. This paper is available on arxiv under CC 4.0 license. available on arxiv

Evaluating NEO-KD Against Single-Exit Defense Methods in Multi-Exit Networks

Authors:
(1) Oleksandr Kuznetsov, Proxima Labs, 1501 Larkin Street, suite 300, San Francisco, USA and Department of Political Sciences, Communication and International Relations, University of Macerata, Via Crescimbeni, 30/32, 62100 Macerata, Italy (kuznetsov@karazin.ua);
(2) Dzianis Kanonik, Proxima Labs, 1501 Larkin Street, suite 300, San Francisco, USA;
(3) Alex Rusnak, Proxima Labs, 1501 Larkin Street, suite 300, San Francisco, USA (alex@proxima.one);
(4) Anton Yezhov, Proxima Labs, 1501 Larkin Street, suite 300, San Francisco, USA;
(5) Oleksandr Domin, Proxima Labs, 1501 Larkin Street, suite 300, San Francisco, USA. Table of Links Abstract and 1. Introduction 1.1. The Blockchain Paradigm and the Challenge of Scalability 1.2. State of the art 1.3. Our contribution and 1.4. Article structure 2. Conceptualizing the Problem 3. Our Idea for Optimizing Trees in Blockchain 4. Efficiency of adaptive Merkle trees 5. Algorithm for Merkle Tree Restructuring 6. Examples of Merkle Tree Restructuring Algorithm Execution and 6.1 Example 1: Restructuring a Binary Tree by Adding One Leaf 6.2. Example 1.1: Binary Tree Restructuring Through Leaf Node Swapping 6.3. Example 2.1: Restructuring a Non-Binary Tree by Adding a Single Leaf 6.4. Example 2.2: Restructuring a Non-Binary Tree Through Leaf Pair Swapping 6.5. Example 2.3: Restructuring a Patricia-Merkle Tree Fragment Through Leaf Pair Swapping 7. Path Encoding in the Adaptive Merkle Tree 8. Enhancing Verkle Trees Through Adaptive Restructuring and 8.1. Application of Adaptive Trees in Verkle Tree Technology 8.2. Technology and Advantages 9. Discussion 9.1. Our Contribution 9.2. Comparison with Existing Solutions 10. Conclusion and References 6.3. Example 2.1: Restructuring a Non-Binary Tree by Adding a Single Leaf In this example, we explore a non-binary tree where each node can have up to four children (m = 4), closely mirroring a simplified real-world scenario of Patricia-Merkle trees in the Ethereum blockchain. Let's assume the initial state of the tree is as shown in Figure 11.a, similar to the previous example. Also, let the newly added leaves and their probability distributions follow the pattern established in Example 1. These changes in probabilities are summarized in Table 5, which also lists the number of alternatives and the unique discrepancy value (1). Figures 21-30 depict the corresponding tree graphs. . The calculations of discrepancies in Table 5 show that the configuration of the restructured trees tends towards optimality by minimizing the average path length. Now, let's demonstrate the algorithm's operation in the mode of swapping positions between pairs of nodes, as in Example 1.1. This paper is available on arxiv under CC by 4.0 Deed (Attribution 4.0 International) license. Authors: (1) Oleksandr Kuznetsov, Proxima Labs, 1501 Larkin Street, suite 300, San Francisco, USA and Department of Political Sciences, Communication and International Relations, University of Macerata, Via Crescimbeni, 30/32, 62100 Macerata, Italy (kuznetsov@karazin.ua); (2) Dzianis Kanonik, Proxima Labs, 1501 Larkin Street, suite 300, San Francisco, USA; (3) Alex Rusnak, Proxima Labs, 1501 Larkin Street, suite 300, San Francisco, USA (alex@proxima.one); (4) Anton Yezhov, Proxima Labs, 1501 Larkin Street, suite 300, San Francisco, USA; (5) Oleksandr Domin, Proxima Labs, 1501 Larkin Street, suite 300, San Francisco, USA. Authors: Authors: (1) Oleksandr Kuznetsov, Proxima Labs, 1501 Larkin Street, suite 300, San Francisco, USA and Department of Political Sciences, Communication and International Relations, University of Macerata, Via Crescimbeni, 30/32, 62100 Macerata, Italy (kuznetsov@karazin.ua); (2) Dzianis Kanonik, Proxima Labs, 1501 Larkin Street, suite 300, San Francisco, USA; (3) Alex Rusnak, Proxima Labs, 1501 Larkin Street, suite 300, San Francisco, USA (alex@proxima.one); (4) Anton Yezhov, Proxima Labs, 1501 Larkin Street, suite 300, San Francisco, USA; (5) Oleksandr Domin, Proxima Labs, 1501 Larkin Street, suite 300, San Francisco, USA. Table of Links Abstract and 1. Introduction Abstract and 1. Introduction 1.1. The Blockchain Paradigm and the Challenge of Scalability 1.1. The Blockchain Paradigm and the Challenge of Scalability 1.2. State of the art 1.2. State of the art 1.3. Our contribution and 1.4. Article structure 1.3. Our contribution and 1.4. Article structure 2. Conceptualizing the Problem 2. Conceptualizing the Problem 3. Our Idea for Optimizing Trees in Blockchain 3. Our Idea for Optimizing Trees in Blockchain 4. Efficiency of adaptive Merkle trees 4. Efficiency of adaptive Merkle trees 5. Algorithm for Merkle Tree Restructuring 5. Algorithm for Merkle Tree Restructuring 6. Examples of Merkle Tree Restructuring Algorithm Execution and 6.1 Example 1: Restructuring a Binary Tree by Adding One Leaf 6. Examples of Merkle Tree Restructuring Algorithm Execution and 6.1 Example 1: Restructuring a Binary Tree by Adding One Leaf 6.2. Example 1.1: Binary Tree Restructuring Through Leaf Node Swapping 6.2. Example 1.1: Binary Tree Restructuring Through Leaf Node Swapping 6.3. Example 2.1: Restructuring a Non-Binary Tree by Adding a Single Leaf 6.3. Example 2.1: Restructuring a Non-Binary Tree by Adding a Single Leaf 6.4. Example 2.2: Restructuring a Non-Binary Tree Through Leaf Pair Swapping 6.4. Example 2.2: Restructuring a Non-Binary Tree Through Leaf Pair Swapping 6.5. Example 2.3: Restructuring a Patricia-Merkle Tree Fragment Through Leaf Pair Swapping 6.5. Example 2.3: Restructuring a Patricia-Merkle Tree Fragment Through Leaf Pair Swapping 7. Path Encoding in the Adaptive Merkle Tree 7. Path Encoding in the Adaptive Merkle Tree 8. Enhancing Verkle Trees Through Adaptive Restructuring and 8.1. Application of Adaptive Trees in Verkle Tree Technology 8. Enhancing Verkle Trees Through Adaptive Restructuring and 8.1. Application of Adaptive Trees in Verkle Tree Technology 8.2. Technology and Advantages 8.2. Technology and Advantages 9. Discussion 9. Discussion 9.1. Our Contribution 9.1. Our Contribution 9.2. Comparison with Existing Solutions 9.2. Comparison with Existing Solutions 10. Conclusion and References 10. Conclusion and References 6.3. Example 2.1: Restructuring a Non-Binary Tree by Adding a Single Leaf In this example, we explore a non-binary tree where each node can have up to four children (m = 4), closely mirroring a simplified real-world scenario of Patricia-Merkle trees in the Ethereum blockchain. Let's assume the initial state of the tree is as shown in Figure 11.a, similar to the previous example. Also, let the newly added leaves and their probability distributions follow the pattern established in Example 1. These changes in probabilities are summarized in Table 5, which also lists the number of alternatives and the unique discrepancy value (1). Figures 21-30 depict the corresponding tree graphs. . The calculations of discrepancies in Table 5 show that the configuration of the restructured trees tends towards optimality by minimizing the average path length. Now, let's demonstrate the algorithm's operation in the mode of swapping positions between pairs of nodes, as in Example 1.1. This paper is available on arxiv under CC by 4.0 Deed (Attribution 4.0 International) license. This paper is available on arxiv under CC by 4.0 Deed (Attribution 4.0 International) license. available on arxiv

Restructuring a Non-Binary Tree by Adding a Single Leaf

Recent Photo of HackerNoon Founder & CEO David Smooke. Tim Keary from Techopedia: Confidence in journalism is at an all time low, and artificial intelligence threatens to destabilize this further. Currently news publishers of all sizes are being forced to decide what role AI plays in the newsroom. Will they accept AI-generated content and headlines, how much AI use needs to be disclosed to readers, and will AI-generated news will take traffic away from human-written journalism? Techopedia reached out to David Smooke, founder and CEO of HackerNoon, a technology publisher with over 45,000 contributing writers and 4 million monthly readers, to find out how his organization is experimenting with AI, and to get his thoughts on how AI should be approached by journalists and news publishers. The Q&A provides a brief look at how HackerNoon is experimenting with AI in its operations, what the acceptable limits of AI’s role in the newsroom should be, Smooke’s thoughts on the The New York Times vs OpenAI lawsuit, and the future of human-written journalism. Smooke, from Colorado, founded HackerNoon in 2013, back when AI was still effectively confined to the dreams of Hollywood. Comments and formatting have been edited slightly for brevity. Tim Keary: As a journalist and the CEO of a news organization, what role do you think that AI should play in the newsroom? David Smooke: I’m more of  a writer and a product manager than a journalist. HackerNoon publishes all types of technology blog posts, like op eds, tutorials, interviews, columns, research papers, and some journalism. We’re building a community driven content management system, and there are many places where AI can assist writers, readers, and editors, such as through brainstorming new ideas, fixing grammar, or finding your next relevant story. Within our text editor, we have a custom ChatGPT layer for rewrites, a handful of image generation models, and leverage AI to generate summaries for the native character count per distribution channel. We use AI to make stories more accessible by making more versions of the story; for example we use Google AI to translate stories into foreign languages and generate audio versions of the blog post. As a consumer of news, when it comes to the newsroom specifically I would like journalists to research their stories with whatever the most advanced and relevant search technology or specific methodology that story calls for, but to never fully trust the AI, and always always verify. More specifically, what level of use is acceptable in your view, and what level of transparency is required? It’s not acceptable for content to be presented as human made when it was made by AI. Platforms should do what they can to indicate where and how AI contributed to the experience.  For example, we use emoji credibility indicators to indicate to the reader if AI assisted in the writing of the story. People on the internet should trust the author is who the site says the author is. Do you see AI-generated news sites as a threat to the future of human-written journalism? There are side effects from the mass production and mass consumption of AI generated content. Deep fakes create billions of views across social media. Platforms are getting better at detecting them and labeling them, but they are just easier than ever to make. When TUAW recently relaunched with newly AI generated content and accredited them to real humans that used to write there - it did not go over well. Writers don’t want that misattribution, and for blog posts, readers trust the content more if they trust the human on the other side of the screen. Many financial websites and tools have been using natural language processing and automation to dish out headlines in seconds because that information is important for investors. It's a speed and convenience thing vs. slower human input, but it's been going on for far longer than the generative AI boom we're currently seeing. I.e., is there a risk that AI-generated content will take clicks, attention, and money away from content that journalists have put time and effort into developing even if it can’t replicate on the ground reporting? Yes, there is a risk of more attention moving from the publisher to search experience.  If a Google generated AI search results solves the problem today that a page on someone’s site would have solved yesterday, that is a lost visitor. On the plus side for publishers, super powerful AI functions are a single API call away, meaning the publisher’s discovery and search experience may also be able to retain quality traffic longer. What do you make of The New York Times’ lawsuit against OpenAI and the wider trend of AI vendors training models on news content generated by human authors and journalists? In the future, I anticipate the government and even the private sector will reign in the wild west approach of anything on internet could be used as training data. Will this case of the New York Times vs. OpenAI be the milestone case for how content creators are compensated by AI companies? I have my doubts, but it certainly is two big names. It emerged after a content licensing agreement failed. Reading between the lines, if OpenAI was able to compensate the New York Times more, the case would have never made it to court. The verbatim regurgitation of another’s content is plagiarism. The New York Times knows this, OpenAI knows this, and even your grade school teacher knows this. I expect OpenAI to pay The New York Times more money before this is over, but I don’t see this case shaping the future for how internet content is licensed to AI training. What do you make of AI news tools like Perplexity AI which offer news summaries with citations? (Do you think these can be useful tools or is there a concern they will take readers away from traditional news sites). Curating is a value add. Sometimes, especially if given reliable and detailed rules, AI can curate as effectively as some humans. AI is 100% changing how we search and research on the internet. I’m not even certain that Perplexity’s search differentiation is the use of AI as Perplexity has amazing design choices. Was not surprised to see Meta roll out a very similar scrolling topics homepage during the launch of Meta AI chat and for SearchGPT to use a similar design for displaying relevant sources. Google search still dominates the market, their use of generative AI in search results demonstrates that generative AI will be a part of the future of the internet search market. How can news publishers use AI to enhance their operations? We use AI in a number of publishing systems across HackerNoon. Before publication, AI recommends headlines based on the story draft and past performance of HackerNoon stories. The humans still write the headlines better 95% of the time, but it’s nice to have the machines generate a few relevant options. We also use AI to better curate stories, like when we had to categorize 50k technology tags into 22 technology categories, it made more sense for an AI to make those 50k assignments than for human editors to do. Do you have any comments on the impact of AI on SEO? More specifically, do you think it’s going to be harder to rank human-written content against AI-driven content in the future? AI content is not source material. Sources will always need to be cited and linked to.  With the rise of AI generated search result summaries and the aggregate number of human to AI interactions increasing daily, it is becoming expected for search experiences to be supplemented by an AI assistant. What would you say to writers and journalists who are entering the industry who are concerned about the future of news publishing as a whole? Don’t be afraid of competing with robots. The demand for authentic human stories is as high as it's ever been. As AI floods the internet with billions of pieces of bad content, mediocre content, acceptable-ish content and even some remarkable content, great storytellers will continue to rise above. Whenever the writer lives/d, there’s barriers to entry to acquiring readers. Most of human history there were no magazines or internet. Whoever had a quality story to tell, found a way to tell their story. If you have stories to write, there are more ways than ever before to acquire readers from around the globe. Are there any other comments you’d like to add? We will always need human originality… because we’re humans, we crave human stories. Also Published as “What is the Role of AI in the Newsroom? We Ask Hackernoon’s CEO” Recent Photo of HackerNoon Founder & CEO David Smooke. Recent Photo of HackerNoon Founder & CEO David Smooke . HackerNoon Founder & CEO David Smooke Tim Keary from Techopedia : Confidence in journalism is at an all time low , and artificial intelligence threatens to destabilize this further. Currently news publishers of all sizes are being forced to decide what role AI plays in the newsroom. Tim Keary from Techopedia all time low Will they accept AI-generated content and headlines, how much AI use needs to be disclosed to readers, and will AI-generated news will take traffic away from human-written journalism? Techopedia reached out to David Smooke, founder and CEO of HackerNoon , a technology publisher with over 45,000 contributing writers and 4 million monthly readers, to find out how his organization is experimenting with AI, and to get his thoughts on how AI should be approached by journalists and news publishers. founder and CEO of HackerNoon The Q&A provides a brief look at how HackerNoon is experimenting with AI in its operations, what the acceptable limits of AI’s role in the newsroom should be, Smooke’s thoughts on the The New York Times vs OpenAI lawsuit, and the future of human-written journalism. Smooke, from Colorado, founded HackerNoon in 2013, back when AI was still effectively confined to the dreams of Hollywood. Comments and formatting have been edited slightly for brevity. Tim Keary : As a journalist and the CEO of a news organization, what role do you think that AI should play in the newsroom? Tim Keary David Smooke : I’m more of  a writer and a product manager than a journalist. HackerNoon publishes all types of technology blog posts, like op eds, tutorials, interviews, columns, research papers, and some journalism. We’re building a community driven content management system, and there are many places where AI can assist writers, readers, and editors, such as through brainstorming new ideas, fixing grammar, or finding your next relevant story. David Smooke HackerNoon HackerNoon Within our text editor , we have a custom ChatGPT layer for rewrites, a handful of image generation models, and leverage AI to generate summaries for the native character count per distribution channel. We use AI to make stories more accessible by making more versions of the story; for example we use Google AI to translate stories into foreign languages and generate audio versions of the blog post. Within our text editor As a consumer of news, when it comes to the newsroom specifically I would like journalists to research their stories with whatever the most advanced and relevant search technology or specific methodology that story calls for, but to never fully trust the AI, and always always verify. More specifically, what level of use is acceptable in your view, and what level of transparency is required? It’s not acceptable for content to be presented as human made when it was made by AI. Platforms should do what they can to indicate where and how AI contributed to the experience.  For example, we use emoji credibility indicators to indicate to the reader if AI assisted in the writing of the story. People on the internet should trust the author is who the site says the author is. emoji credibility indicators emoji credibility indicators AI assisted AI assisted Do you see AI-generated news sites as a threat to the future of human-written journalism? There are side effects from the mass production and mass consumption of AI generated content. Deep fakes create billions of views across social media. Platforms are getting better at detecting them and labeling them, but they are just easier than ever to make. When TUAW recently relaunched with newly AI generated content and accredited them to real humans that used to write there - it did not go over well. Writers don’t want that misattribution, and for blog posts, readers trust the content more if they trust the human on the other side of the screen. TUAW recently relaunched TUAW recently relaunched Many financial websites and tools have been using natural language processing and automation to dish out headlines in seconds because that information is important for investors. It's a speed and convenience thing vs. slower human input, but it's been going on for far longer than the generative AI boom we're currently seeing. I.e., is there a risk that AI-generated content will take clicks, attention, and money away from content that journalists have put time and effort into developing even if it can’t replicate on the ground reporting? Yes, there is a risk of more attention moving from the publisher to search experience.  If a Google generated AI search results solves the problem today that a page on someone’s site would have solved yesterday, that is a lost visitor. On the plus side for publishers, super powerful AI functions are a single API call away, meaning the publisher’s discovery and search experience may also be able to retain quality traffic longer. What do you make of The New York Times’ lawsuit against OpenAI and the wider trend of AI vendors training models on news content generated by human authors and journalists? In the future, I anticipate the government and even the private sector will reign in the wild west approach of anything on internet could be used as training data. Will this case of the New York Times vs. OpenAI be the milestone case for how content creators are compensated by AI companies? I have my doubts, but it certainly is two big names. It emerged after a content licensing agreement failed. Reading between the lines, if OpenAI was able to compensate the New York Times more, the case would have never made it to court. The verbatim regurgitation of another’s content is plagiarism. The New York Times knows this, OpenAI knows this, and even your grade school teacher knows this. I expect OpenAI to pay The New York Times more money before this is over, but I don’t see this case shaping the future for how internet content is licensed to AI training. this case of the New York Times vs. OpenAI this case of the New York Times vs. OpenAI What do you make of AI news tools like Perplexity AI which offer news summaries with citations? (Do you think these can be useful tools or is there a concern they will take readers away from traditional news sites). Curating is a value add. Sometimes, especially if given reliable and detailed rules, AI can curate as effectively as some humans. AI is 100% changing how we search and research on the internet. I’m not even certain that Perplexity’s search differentiation is the use of AI as Perplexity has amazing design choices. Was not surprised to see Meta roll out a very similar scrolling topics homepage during the launch of Meta AI chat and for SearchGPT to use a similar design for displaying relevant sources. Google search still dominates the market, their use of generative AI in search results demonstrates that generative AI will be a part of the future of the internet search market. How can news publishers use AI to enhance their operations? We use AI in a number of publishing systems across HackerNoon. Before publication, AI recommends headlines based on the story draft and past performance of HackerNoon stories. The humans still write the headlines better 95% of the time, but it’s nice to have the machines generate a few relevant options. We also use AI to better curate stories, like when we had to categorize 50k technology tags into 22 technology categories , it made more sense for an AI to make those 50k assignments than for human editors to do. 50k technology tags 50k technology tags 22 technology categories 22 technology categories Do you have any comments on the impact of AI on SEO? More specifically, do you think it’s going to be harder to rank human-written content against AI-driven content in the future? AI content is not source material. Sources will always need to be cited and linked to.  With the rise of AI generated search result summaries and the aggregate number of human to AI interactions increasing daily, it is becoming expected for search experiences to be supplemented by an AI assistant. What would you say to writers and journalists who are entering the industry who are concerned about the future of news publishing as a whole? Don’t be afraid of competing with robots. The demand for authentic human stories is as high as it's ever been. As AI floods the internet with billions of pieces of bad content, mediocre content, acceptable-ish content and even some remarkable content, great storytellers will continue to rise above. Whenever the writer lives/d, there’s barriers to entry to acquiring readers. Most of human history there were no magazines or internet. Whoever had a quality story to tell, found a way to tell their story. If you have stories to write, there are more ways than ever before to acquire readers from around the globe. Are there any other comments you’d like to add? We will always need human originality… because we’re humans, we crave human stories. Also Published as “What is the Role of AI in the Newsroom? We Ask Hackernoon’s CEO” Also Published as “ What is the Role of AI in the Newsroom? We Ask Hackernoon’s CEO ” What is the Role of AI in the Newsroom? We Ask Hackernoon’s CEO

"For Publishers, Super Powerful AI Functions are a Single API Call Away" says HackerNoon Founder/CEO

"ለአሳታሚዎች፣ እጅግ በጣም ኃይለኛ AI Functions ነጠላ የኤፒአይ ጥሪ ነው" ይላል HackerNoon Founder/CEO

"Nəşriyyatçılar üçün Super Güclü Süni İntellekt Funksiyaları Tək API Zəngidir" deyir HackerNoon təsisçisi/CEO

হ্যাকারনুন প্রতিষ্ঠাতা/সিইও বলেছেন "প্রকাশকদের জন্য, সুপার পাওয়ারফুল এআই ফাংশনগুলি একটি একক API কল অ্যাওয়ে"

"Para los editores, las funciones de inteligencia artificial superpoderosas están a una sola llamada de API de distancia", afirma el fundador y director ejecutivo de HackerNoon

「パブリッシャーにとって、超強力なAI機能は1回のAPI呼び出しで利用可能」とHackerNoonの創設者兼CEOは語る

"Жарыялоочулар үчүн супер күчтүү AI функциялары бир гана API чалуу болуп саналат" дейт HackerNoon негиздөөчүсү/CEO

„Dla wydawców niezwykle wydajne funkcje AI są dostępne po jednym wywołaniu API” – twierdzi założyciel i dyrektor generalny HackerNoon

"ප්‍රකාශකයන් සඳහා, සුපිරි බලගතු AI ක්‍රියාකාරකම් තනි API ඇමතුමක් වේ" HackerNoon නිර්මාතෘ/ප්‍රධාන විධායක නිලධාරී පවසයි

„Pre vydavateľov sú super výkonné funkcie AI jediným volaním cez API,“ hovorí zakladateľ/CEO HackerNoon

"För utgivare är superkraftiga AI-funktioner ett enda API-samtal borta" säger HackerNoon grundare/VD

"Kwa Wachapishaji, Kazi za AI zenye Nguvu Zaidi ni Simu Moja ya API" anasema Mwanzilishi wa HackerNoon/CEO

"ንኣሕተምቲ፡ ሱፐር ፓወርፉል ኤኣይ ፋንክሽንስ ሓደ ኤፒኣይ ኮል ኣዌይ እዩ" ይብል መስራቲ/ዋና ኣካያዲ ስራሕ ሃከርኑን።

Meet New & Improved BigQuery: Single, Unified AI-Ready Data Platform

Single-Threaded Node.js is a Myth  

Developing Next-Gen Data Solutions: SingleStore, MinIO, and the Modern Datalake Stack

নেক্সট-জেন ডেটা সলিউশন তৈরি করা: একক স্টোর, মিনিও এবং আধুনিক ডেটালেক স্ট্যাক

Entwicklung von Datenlösungen der nächsten Generation: SingleStore, MinIO und der moderne Datalake-Stack

Desarrollo de soluciones de datos de próxima generación: SingleStore, MinIO y Modern Datalake Stack

Développer des solutions de données de nouvelle génération : SingleStore, MinIO et la pile Datalake moderne

अगली पीढ़ी के डेटा समाधान विकसित करना: सिंगलस्टोर, मिनियो और आधुनिक डेटालेक स्टैक

次世代データソリューションの開発: SingleStore、MinIO、最新のデータレイク スタック

차세대 데이터 솔루션 개발: SingleStore, MinIO 및 최신 Datalake 스택

Desenvolvendo soluções de dados de última geração: SingleStore, MinIO e Modern Datalake Stack

Разработка решений для обработки данных следующего поколения: SingleStore, MinIO и современный стек Datalake

Yeni Nesil Veri Çözümlerinin Geliştirilmesi: SingleStore, MinIO ve Modern Datalake Stack

Phát triển các giải pháp dữ liệu thế hệ tiếp theo: SingleStore, MinIO và Datalake Stack hiện đại

开发下一代数据解决方案：SingleStore、MinIO 和现代 Datalake 堆栈

100 Complex Cryptocurrency Terminologies Explained in a Single Sentence

100 Complex LLM Terminology Explained in One Single & One Simple Sentence

The Single Responsibility Principle (SRP) is one of the five SOLID principles of code design. It states that a unit of code should have only one reason to change. However, this principle is often misunderstood and misapplied, as we can see in too numerous 'big (or distributed) balls of mud' and 'spaghetti' code bases. In this article, we will explore what the SRP is and how to make following it practical and actually beneficial. First things first, why the SRP? Why should we care about it? The SRP helps write code that is easier to understand, maintain, and extend. Essentially, being able to follow the SRP is one of the key factors in writing clean code. The next thing is that the SRP can be applied not only to classes but also to methods and contracts in general. This means that the SRP is not just about classes but about any unit of code that can change. And by a 'contact' I mean a set of inputs, outputs, and behaviors that a unit of code is expected to provide. The main challenge in the SRP is exactly in defining the 'reason' to change, to outline the responsibilities - this is what the article will revolve around. The irony is that there is probably not a single developer who would not know about the SRP or would say that it is not important. However, in practice, we see high coupling, overcomplicated dependency graphs, the costs of changes and maintenance keep growing way too fast, and the code becomes a nightmare to work with - and all the while everyone knows about the SRP and even tries to follow it. How the SRP Is Often Introduced and Why It Does Not Really Help Normally, the description of the SRP starts with an example where a few different responsibilities are combined together, and then it goes by separating those responsibilities into different classes, and stating that this is it, this is the SRP. Yes, separating concerns may lead to a good and cleaner design, and it would be an example of the SRP, but it is just a limited application of it. Essentially, such examples show how to separate concerns, but not how to really apply the SRP. Once the concerns are separated, we still need to implement the functionality that uses them together in a single flow. So, the SRP is not about separating different concerns, it is about how to properly outline the responsibilities in the first place. And the definition of 'proper' comes from the definition of the SRP itself - 'a unit of code should have only one reason to change.' Let's take the of a class that compiles and prints a report, even though it is rather limited, but we can start with it. Clearly, building or compiling a report and printing or saving it into a representation are two different functionalities that are quite independent of each other. However, in the end, they form a single responsibility. Wikipedia example may Let's ask ourselves a question: is this software ever going to need a different way to compile or build a report? Or a different way to print it or save it into another representation form? Does it actually have such reasons to change? The answer to these questions comes from the business requirements - it is not about the code itself or not about the code itself. only So, the typical view on the Single Responsibility Principle is fine we balance it with proper bounds that will not lead us into a trap of over-engineering the code. It is very much like premature optimizations - just not in terms of performance or memory consumption but in terms of design and architecture. "If it is not broken, do not fix it. If it is not needed, do not add it." Do not write code or create designs that are not needed now and may never be needed. if It would be great to augment the canonical definition of the SRP - 'a unit of code should have only one reason to change' - with an understanding that the 'reasons to change' should be limited by the existing and potential, though still justified, requirements. What the piece of software that this unit of code is a part of is supposed to do, and what it is not supposed to do. Ok, all this sounds good but there may be a question: why not just separate concerns and be done with it? Even if this separation will never be required by our software, even if we will have only a single implementation of each of those concerns and probably just a single use for each of them - why not separate them? We can have a cleaner implementation, more in line with the SRP, 'clean code', etc. Again, if our software is small and simple, this separation will not actually hurt. The answer to this question is that such separation of concerns creates new abstractions, new interfaces, new classes, and new dependencies. More abstractions potentially mean higher coupling. And since we are normally dealing with large and complex software, this separation may lead to a combinatorial explosion of abstractions, and thus - higher coupling. So, it will help with making our code cleaner and easier to understand and maintain. What is often omitted when describing the SOLID principles, and the SRP in particular, is that everything comes at a cost, and we need to balance these costs in order to keep our code maintainable and understandable. not To make this statement clearer, just count how many new abstractions we have after we carelessly separated concerns, and how many new dependencies we would need to inject into our classes to make them work - the higher the numbers, the higher the coupling. Well, the next arising and rather justified question can be about the testability of such code, if we do not separate concerns. And yes, it can be very justified to separate concerns in order to make the code more testable, as this is often a part of our NFRs (non-functional requirements). But again, should we really introduce new abstractions and dependencies just to make our code more testable? Can it be tested just fine without introducing new abstractions? And the answer, surprisingly, can often be 'yes.' Following the Wikipedia example, we can still apply the SRP on the level of methods, without introducing additional abstractions, and such methods can be tested just fine. The SRP From the Point of View of Contracts The Single Responsibility Principle is a design principle, and the design often starts with contracts. We can describe the contracts in a rather wide form - as a set of inputs, outputs, and behaviors that a unit of code is expected to use and provide. This description should be good enough for the purpose of this article. Let's see how the SRP can be applied to contracts, and let's repeat its definition - 'a unit of code should have only one reason to change.' The contracts often have the most direct influence on when and why the code should change; if a contract changes, the code that implements or uses it should change as well. And while we strive to maintain the contracts stable, they connect the pieces of code together, and thus, are quite likely to change when the co-related requirements change. In other words, we do not control some of the 'reasons to change' even if the requirements for our own unit of code are stable. A contract can be described in terms of a 'dependency-consumer' relationship: another piece of code provides some behaviors used by our unit of code and those behaviors may create some data required by our unit of code. In turn, our unit of code gets consumed by other units of code. A method with its list of parameters and return values is an example of such a contract. In the same way, a class or interface provides a contract with its methods, and we can keep climbing the abstraction ladder, speaking about the contracts on the level of modules, services, APIs, and so on. When designing contracts for our code, we normally take into account this co-relation between the units of code, as it is quite clear that a contract we are designing should serve specific 'consumers' and will depend on other contracts. However, when looking at a contract from the point of view of the SRP, we should also consider that the 'reasons to change' for our contract are also influenced by those 'consumers' and 'dependencies', or if we look 'from inside out' - the behavior provided by our contract, and thus its output, influence the 'reasons to change' for the 'consumers' of our contract. If we deal with quite a stable code base where the requirements are not changing often, and our contract most likely is going to be stable, we just need to design it well with sufficient thoughtfulness regarding its consumers and dependencies. However, if we deal with a code base that is more fluid, where the requirements for our consumers and dependencies may change, we may want or will have to, either accept that our contract will keep changing as well, or design additional abstractions that will protect our contract from those changes. One such abstraction is a mapping layer that will convert the data from the representation produced by the dependencies into the representation that our contract expects, and the same way around for our consumers. In fact, this is a common practice in the design of APIs, bounded contexts, and other similar units of code. The main question is the cost - what is going to be less expensive, changing our contract and implementation when the dependencies change, thus invoking in turn potential change in our consumers, or introducing additional abstractions that will isolate our contract from those changes? In real-world scenarios, we often begin with what is faster to implement, and then, we see how it evolves. Ideally, our working process has enough space to address and solve the arising technical debt, and we can refactor our code when needed with the goal of keeping it maintainable at the lowest cost. And by the 'cost' I mean not only the time and effort needed to implement a particular change but also how costly it will be to maintain and extend the code in the future. Many of us know all too well that what costs very little to do right away may and will cost a lot in the future. So, a bit unexpectedly, the SRP got connected not only with immediate design decisions and long-term maintainability but also with the costs of maintaining the code and addressing the technical debt. Of course, the developers are not seers, but by applying the SRP properly for code design at the contract level, we can achieve better maintainability and lower future costs - both for the business and for the developers. The SRP and the Leaky Abstractions A leaky abstraction is an abstraction that leaks details of what it is supposed to abstract away. Wikipedia On the practical level, a leaky abstraction can be anything that exposes, directly or indirectly, how a unit of code works - something that the consuming code is not expected to know about or use. For example, the response object contains a public property that logically should not be there, as it exposes internal state or implementation detail that the consuming code should not be aware of. Another example is when a class method output should be additionally processed by another method of the same class in certain scenarios, which the consuming code does not control but is forced to check for. One more example is submitting a parameter that controls the input data processing while the parameter value could be deducted from the input itself or should come from another source that the consuming code does not own or use for any other purpose. Leaky abstractions are related to the Single Responsibility Principle because they introduce additional 'reasons to change' for a unit of code, even if only potentially. Leaky abstractions add to contract instability, both in terms of consumption and exposure. Let's look at leaky abstractions from the point of view of contract design, which we discussed in the previous part. A few good checkup questions to ask when designing a contract are: Does the contract really need a particular input parameter? Is the exposed behavior atomic and self-sufficient, or will the consumers have to invoke additional behaviors of our contract on a condition not determined by the consumer? Does the contract expose any internal, or even public, state that is not required by the consumers? Let's go over these checkpoints in more detail to see why they may be related to leaky abstractions and the SRP. Does the contract really need a particular input parameter? Why should we be concerned about an input parameter of a contract? Besides the obvious reason of not being used by the code, we should also consider if we can deduce this parameter from the input data itself without incurring additional costs or if the parameter is a part of the global application state, and thus, could be injected into the contract implementation at the dependency resolution stage. Well, normally we do need our parameters at the calling site, but we should be sure that it is within the responsibility of our consumers to provide them, and it is not the responsibility of our contract to obtain them. If these responsibilities are mixed up, we may have a leaky abstraction and we create an additional 'reason to change' either for our unit code or for its consumers. Is the exposed behavior atomic and self-sufficient? This may not affect our own unit of code 'reasons to change' directly, but it may affect the consumers of our contract, as this influences the contract stability. If the exposed contract behavior is not atomic, changes in its internal logic are more likely to affect the contract itself which will be a breaking change for the consumers. This would also be a violation of the SRP on the contract level as the contract should not change when only the internal behavior changes. While the contract still provides the same final result, it has changed because of internal reasons that should not be exposed to the consumers, and this is another example of leaky abstractions. Does the contract expose any internal or even public state that is not required by the consumers? As well as introducing the risk of potentially breaking changes for the consumers, exposing internal or not needed state may also lead to unexpected coupling or 'reasons to change'. Let's say the consumers of our contract came to rely on an unintentionally exposed state, and for some reason, it is impossible or too expensive now to update the consumers; while this state cannot or should not be maintained by our code because the requirements have changed, and the code should be updated. So, our code will be forced to maintain this state and implement an additional workaround to keep the consumers working - we now have an extra 'reason to change' for our code. Consuming Leaky Abstractions Of course, we should also be watchful when consuming leaky abstractions. Let's again take the Wikipedia example for the SRP regarding a class implementing a report persistence functionality. A report may be persisted into a local file, a database, or any other type of storage. Each of these methods of persistence has its own internal specifics that may leak out, and our code may mistakenly rely on them. For example, the local or remote file persistence may expose the file location that our code may want to use for some reason. When the application is expanded with a new persistence method, say, a database, our code will have to change - simply because it was built around a leaky abstraction. In a sense, leaky abstractions provide 'false contracts' that are not stable and may change at any time or simply be absent or different in other contract implementations, thus introducing additional 'reasons to change' for a unit of code and violating the SRP. Let's Summarize... Of course, all code is written in a context, and the context is the king, as it is defined by business requirements, NFRs, the current state of the code base, the current level of expertise of developers, the way the costs are balanced, and by many other factors. Nonetheless, it is possible to outline some points for additional considerations when creating designs or implementing code that would help to stay more in line with the Single Responsibility Principle within the context present at the moment. Outline the responsibilities within the units of code based on valid 'reasons to change' that are defined by the business and non-functional requirements, and not by the code itself. "If it is not broken, do not fix it. If it is not needed, do not add it." Before extracting or creating a new abstraction, consider if it is really needed - check the 'reasons to change' for already existing code and for the new abstraction. If they are not different, it may most likely be better to keep the code together. When driven by the code testability requirements, consider applying the SRP on the level of methods, not only on the level of abstractions. If the only reason for a new abstraction is to make the code more testable, try adjusting your testing approach first, and introduce new abstractions only when there is no other way. When designing contracts in a complex system, consider if the potentially required dependencies are stable enough to be used directly, or if it is better to introduce additional abstractions that will protect your code from the changes in those dependencies. The cost of adding and maintaining extra abstractions should be balanced with the cost of potentially breaking changes when the dependencies change. Check for leaky abstraction in your code and in the dependencies it needs. If you see that the abstractions are leaking, consider replacing them with more stable abstractions. The cost of relying on leaky abstractions, or better to say the risk, should be balanced with the cost of replacing them. As you see, sometimes, we should not add a new abstraction and sometimes we should - the context is the king, we just need to make sure it can rule happily for as long as possible and define the 'reasons to change' and the cost balancing are the keys in applying the SRP.

Making the Single Responsibility Principle Practical

Stories, News & Mentions about SINGLE

Single’s Stories on HackerNoon