Forem: Clean Code Studio

TS Dependency Injection with @Findhow/Container No Decorators Required 🔥

Clean Code Studio — Wed, 02 Oct 2024 00:15:19 +0000

@findhow/container

A TypeScript-based Dependency Injection (DI) container supporting various binding types (singleton, transient, scoped), contextual bindings, middleware, circular dependency detection, and Zod schema validation for runtime type safety.

@findhow/container GitHub Repo

🚀 Unleash the Power of TypeScript Dependency Injection with @findhow/container 🔥

Introduction
@findhow/container Compared
🚀 Key Features Breakdown
Examples
- Basic Container Binding
- Singleton Binding
- Contextual Binding
- Middleware Usage
- Circular Dependency Detection
- Tagging Services
- Scoped Instances
- Zod Schema Validation Examples
- Zod Schema Validation on Binding
- Invalid Schema Detection
- Schema Validation with Nested Objects
- Schema Validation for Contextual Bindings
- Conditional Schema Validation
- Async Binding with Zod Schema Validation
- Other Dependency Injection Examples
- Multiple Implementations with Interfaces
- Nested Dependencies
- Property Injection with Optional Dependencies
Why @findhow/container?

Check out the GitHub repository

@findhow/container Compared

Feature	@findhow/container	Inversify	NestJS	TypeDI	TSyringe
TypeScript Support	✅	✅	✅	✅	✅
No Decorator-based DI Required	✅	❌	❌	❌	❌
Constructor Injection	✅	✅	✅	✅	✅
Property Injection	✅	✅	✅	✅	✅
Method Injection	✅	✅	✅	✅	✅
Circular Dependency Detection	✅	✅	✅	✅	✅
Lazy Injection	✅	✅	✅	✅	❌
Named Injections	✅	✅	✅	✅	✅
Tagged Injections	✅	✅	✅	❌	❌
Scoped Injections	✅	✅	✅	✅	✅
Async Injection	✅	❌	✅	✅	❌
Middleware Support	✅	❌	✅	❌	❌
Zod Schema Validation	✅	❌	❌	❌	❌
Framework Integration	❌	❌	✅ (Full)	❌	❌

Compare full feature set on GitHub

🚀 Key Features Breakdown

Here are some key features that make @findhow/container a great choice for dependency injection in TypeScript:

Singleton, Transient, and Scoped Bindings: Control the lifecycle of your services with different binding strategies.
Contextual Bindings: Bind different values depending on the context.
Zod Schema Validation: Validate resolved instances against Zod schemas for type safety.
Middleware Support: Intercept and modify resolution logic using middleware.
Async Bindings: Resolve dependencies that require asynchronous initialization.
Circular Dependency Detection: Prevent infinite loops by detecting circular dependencies.
Tagging and Aliasing: Bind services to tags or aliases for more flexible resolution.

Explore these features in the GitHub repository

Examples

View all examples on GitHub

Basic Container Binding

This example demonstrates how to bind a simple class to the container and resolve it. It's useful for basic dependency injection where you want to decouple your code from direct instantiations.

import { Container } from "@findhow/container";

class Logger {
  log(message: string) {
    console.log(message);
  }
}

const container = new Container();
container.bind('Logger', () => new Logger());

const logger = container.resolve<Logger>('Logger');
logger.log('Hello, World!'); // Output: Hello, World!

See this example on GitHub

Singleton Binding

This example demonstrates how to bind a class as a singleton. This ensures that the same instance is returned every time the service is resolved, useful when you want to maintain shared state.

import { Container } from "@findhow/container";

class Config {
  constructor(public env: string) {}
}

const container = new Container();
container.singleton('Config', () => new Config('production'));

const config1 = container.resolve<Config>('Config');
const config2 = container.resolve<Config>('Config');

console.log(config1 === config2); // Output: true

See this example on GitHub

Zod Schema Validation on Binding

This example shows how to use Zod schema validation when binding a service to ensure that the resolved instance meets the expected schema. This is useful for enforcing runtime type safety.

import { Container } from "@findhow/container";
import { z } from "zod";

// Define a Zod schema for the service
const userSchema = z.object({
  id: z.number(),
  name: z.string(),
});

class UserService {
  constructor(public id: number, public name: string) {}
}

const container = new Container();

// Bind the service and validate it against the Zod schema
container.bind('UserService', () => new UserService(1, 'Alice'), userSchema);

const userService = container.resolve<UserService>('UserService');
console.log(userService); // Output: UserService { id: 1, name: 'Alice' }

@findhow/container GitHub

Invalid Schema Detection

This example demonstrates how the container throws an error if the resolved instance does not conform to the Zod schema, helping catch errors early during service resolution.

import { Container } from "@findhow/container";
import { z } from "zod";

// Define a Zod schema for validation
const userSchema = z.object({
  id: z.number(),
  name: z.string(),
});

class InvalidUserService {
  constructor(public id: string, public name: number) {} // Invalid types
}

const container = new Container();

try {
  // Try binding the invalid service and validate against the schema
  container.bind('InvalidUserService', () => new InvalidUserService('one', 123), userSchema);
  container.resolve<InvalidUserService>('InvalidUserService');
} catch (error) {
  console.error(error.message); 
  // Output: Invalid schema for InvalidUserService: Expected number, received string...
}

@findhow/container GitHub

Schema Validation with Nested Objects

This example shows how Zod can be used to validate more complex services with nested objects, ensuring that the entire structure is type-safe at runtime.

import { Container } from "@findhow/container";
import { z } from "zod";

// Define a nested Zod schema
const configSchema = z.object({
  database: z.object({
    host: z.string(),
    port: z.number(),
  }),
  apiKey: z.string(),
});

class ConfigService {
  constructor(public config: { database: { host: string; port: number }; apiKey: string }) {}
}

const container = new Container();

// Bind the service with schema validation
container.bind('ConfigService', () => new ConfigService({
  database: { host: 'localhost', port: 5432 },
  apiKey: 'abc123',
}), configSchema);

const configService = container.resolve<ConfigService>('ConfigService');
console.log(configService.config.database.host); // Output: localhost

@findhow/container GitHub

Conditional Schema Validation

This example shows how you can use conditional logic inside Zod schemas to handle more dynamic validation scenarios during dependency injection, such as checking optional fields based on other conditions.

import { Container } from "@findhow/container";
import { z } from "zod";

// Define a schema with conditional fields
const userSchema = z.object({
  id: z.number(),
  name: z.string(),
  email: z.string().optional(), // Optional field
  role: z.enum(['admin', 'user']),
}).refine(data => data.role === 'admin' ? !!data.email : true, {
  message: "Admin users must have an email",
});

class UserService {
  constructor(public id: number, public name: string, public email?: string, public role: string) {}
}

const container = new Container();

// Bind a user with valid schema (admin with email)
container.bind('UserServiceAdmin', () => new UserService(1, 'Alice', 'alice@example.com', 'admin'), userSchema);

const userServiceAdmin = container.resolve<UserService>('UserServiceAdmin');
console.log(userServiceAdmin); // Output: UserService { id: 1, name: 'Alice', email: 'alice@example.com', role: 'admin' }

try {
  // Try binding a user without an email for an admin role (invalid)
  container.bind('UserServiceInvalid', () => new UserService(2, 'Bob', undefined, 'admin'), userSchema);
  container.resolve<UserService>('UserServiceInvalid');
} catch (error) {
  console.error(error.message); // Output: Admin users must have an email
}

@findhow/container GitHub

Async Binding with Zod Schema Validation

This example demonstrates how you can use Zod schema validation with asynchronous services, ensuring that even services resolved asynchronously meet the expected type safety criteria.

import { Container } from "@findhow/container";
import { z } from "zod";

// Define a Zod schema for validation
const userSchema = z.object({
  id: z.number(),
  name: z.string(),
});

class UserService {
  constructor(public id: number, public name: string) {}

  static async create() {
    // Simulate async service creation
    return new Promise<UserService>((resolve) => {
      setTimeout(() => resolve(new UserService(1, 'Async Alice')), 1000);
    });
  }
}

const container = new Container();

// Bind the async service and validate against the schema
container.bind('UserService', async () => await UserService.create(), userSchema);

(async () => {
  const userService = await container.resolveAsync<UserService>('UserService');
  console.log(userService); // Output: UserService { id: 1, name: 'Async Alice' }
})();

@findhow/container GitHub

Contextual Binding with Zod Schema Validation

This example shows how Zod schema validation can be combined with contextual bindings, ensuring that each context adheres to the correct schema.

import { Container } from "@findhow/container";
import { z } from "zod";

// Define a Zod schema
const configSchema = z.object({
  host: z.string(),
  port: z.number(),
});

class ConfigService {
  constructor(public config: { host: string; port: number }) {}
}

const container = new Container();

// Bind a default config service
container.bind('ConfigService', () => new ConfigService({ host: 'localhost', port: 5432 }), configSchema);

// Contextual binding with different config
container.when('AdminService').needs('ConfigService').give(() => new ConfigService({ host: 'admin-host', port: 3306 }), configSchema);

const defaultConfigService = container.resolve<ConfigService>('ConfigService');
console.log(defaultConfigService.config); // Output: { host: 'localhost', port: 5432 }

const adminConfigService = container.resolve<ConfigService>('ConfigService', 'AdminService');
console.log(adminConfigService.config); // Output: { host: 'admin-host', port: 3306 }

@findhow/container GitHub

Zod Schema Validation with Bound Object

This example demonstrates how Zod schema validation can be used to validate the structure of a bound object in the container. It ensures that the object conforms to the defined schema when resolved.

import { Container } from "@findhow/container";
import { z } from "zod";

// Define a Zod schema
const userSchema = z.object({
  id: z.number(),
  name: z.string(),
});

const container = new Container();

// Bind an object that matches the Zod schema
container.bind('User', () => ({ id: 1, name: 'Alice' }), userSchema);

const user = container.resolve('User');
console.log(user); // Output: { id: 1, name: 'Alice' }

@findhow/container GitHub

Invalid Zod Schema Error

This example shows how the container throws an InvalidSchemaError when the bound object doesn't conform to the expected Zod schema.

import { Container } from "@findhow/container";
import { z } from "zod";
import { InvalidSchemaError } from './errors.ts';

// Define a Zod schema
const schema = z.object({ name: z.string() });

const container = new Container();

// Attempt to bind an object that doesn't conform to the schema
try {
  container.bind('InvalidObject', () => ({ name: 123 }), schema);
} catch (error) {
  console.error(error instanceof InvalidSchemaError); // Output: true
  console.error(error.message); // Output: Invalid schema for InvalidObject
}

@findhow/container GitHub

Async Binding with Zod Schema Validation

This example demonstrates how you can bind an asynchronous service and validate it against a Zod schema after it's resolved. It ensures that even async services are validated for type safety.

import { Container } from "@findhow/container";
import { z } from "zod";

// Define a Zod schema for validation
const serviceSchema = z.object({
  id: z.number(),
  name: z.string(),
});

class AsyncService {
  id = 1;
  name = 'AsyncService';
  async getValue() {
    return this.name;
  }
}

const container = new Container();

// Bind the async service and validate against the schema
container.bind('AsyncService', async () => new AsyncService(), serviceSchema);

(async () => {
  const service = await container.resolveAsync<AsyncService>('AsyncService');
  console.log(await service.getValue()); // Output: AsyncService
})();

@findhow/container GitHub

These examples demonstrate the flexibility of combining Zod schema validation with the @findhow/container dependency injection system to ensure runtime safety for both synchronous and asynchronous services. You can enforce validation in various contexts, including conditional logic and nested structures.

Why `@findhow/container`?

Unlike other DI libraries, @findhow/container doesn't require decorators, supports Zod for validation, and is highly flexible with contextual and scoped bindings.

This library stands out because it offers:

Decorator-free DI: You don’t need to clutter your codebase with decorators.
Zod validation: Runtime schema validation is integrated directly.

Discover more benefits on GitHub
Clean Code Studio

(NEW) [Product Initiative] Requirements Gathering Automation with AI Agents

Clean Code Studio — Sat, 20 Apr 2024 22:57:02 +0000

(Product Initiative)

Requirements Gathering Capable AI Agents

This document compiles all relevant information regarding a product initiative intending to use AI agents as a way to streamline and automate the Requirements Gathering and Ticket Refinement process.

We have five documents within this page we are creating before doing any code work.

Product requirements doc
Product technical design doc
Product system design doc (normally a visual diagram)
Product user guide doc
AI agent responsibility & prompt engineering strategy
Conclusion

1. Product Requirements Doc (PRD)

Develop an AI-powered agent that automates and refines the software development requirements gathering process to increase accuracy and efficiency across project teams.

Goals

Business Goals

Reduce the time to gather and refine development requirements by 30%.
Minimize errors in requirements documentation by enhancing accuracy and traceability.
Improve stakeholder satisfaction with the development process through better alignment and communication.

User Goals

Provide developers and project managers with a streamlined, automated tool for requirements gathering that reduces manual effort and ambiguity.
Enhance collaboration and clarity among stakeholders through more effective communication and documentation practices.

Non-Goals

This tool will not replace the need for initial human-based requirements analysis.
It will not serve as a project management tool for tasks beyond requirements gathering and refinement.

User Stories

As a project manager, I want to initiate requirements gathering with the AI agent so that I can ensure all necessary inputs are collected without manual oversight.
As a developer, I want the tool to automatically notify me of any ambiguities in the requirements so that I can clarify or provide additional information promptly.
As a stakeholder, I want to receive periodic updates from the AI agent about the status of requirements refinement so that I remain informed without attending frequent meetings.

User Experience

Initiation: The user initiates the AI agent from within their existing project management tools.
Data Collection: The agent gathers data from multiple sources, including interviews, existing documentation, and system analysis.
Clarification Requests: When ambiguities are detected, the agent sends automated requests for clarification to the relevant parties.
Feedback Loop: Stakeholders provide feedback through preferred communication channels, which the agent uses to refine requirements.
Documentation: The agent maintains an up-to-date repository of requirements that stakeholders can access at any time.
Notifications: Users receive alerts about changes or needed inputs through integrated communication tools.

Success Metrics

Reduction in time required to gather and refine requirements.
Decrease in the number of errors or inconsistencies in requirements documentation.
User satisfaction ratings from stakeholders and developers.

Technical Considerations

Integration with existing tools such as JIRA and Confluence.
Compliance with data privacy and security standards.
Scalability to accommodate projects of varying sizes and complexities.

Milestones & Sequencing

Requirements Definition and Planning - XX weeks
Prototype Development and Initial Testing - XX weeks
Integration with Existing Tools and Systems - XX weeks
Beta Testing with Key Stakeholders - XX weeks
Launch and Iterative Refinements - XX weeks

Narrative

Imagine a world where project managers and developers spend less time in meetings clarifying what needs to be done and more time actually doing it. Our AI requirements agent not only automates the mundane parts of requirements gathering but also ensures that every piece of information is precisely where it should be, clear and actionable. This tool will revolutionize how projects are initiated, making the entire development process smoother and more efficient.

This document serves as the foundation for the AI Requirements Agent, outlining the product vision, target audience, goals, user stories, and success metrics. It provides a high-level overview of the user experience, technical considerations, and development roadmap.

2. Technical Design Document (TDD): AI Requirements Agent

The TDD delves into the technical intricacies of the AI Requirements Agent. It details the multi-agent system architecture, individual agent design, data management strategies, deployment procedures, and future considerations for expansion and improvement.

1. Introduction

This document details the technical design of the AI Requirements Agent, a multi-agent system designed to automate and refine the software development requirements gathering process. The agent aims to improve efficiency, accuracy, and collaboration among project stakeholders.

2. System Architecture

The AI Requirements Agent is a distributed, multi-agent system composed of four primary agents, each specializing in a specific aspect of requirements gathering and analysis:

Documentation Agent: Analyzes existing project documentation, extracting relevant information and identifying potential gaps or inconsistencies.
Code Analysis Agent: Reviews the code base, suggesting requirements based on current system functionalities and limitations.
Stakeholder Interview Agent: Conducts and analyzes stakeholder interviews, deriving requirements from natural language input.
Feedback Coordination Agent: Manages the feedback loop, integrating input from stakeholders and other agents to refine requirements iteratively.

2.1 Agent Communication and Interaction

The agents communicate and exchange information asynchronously through a message queue system. Each agent publishes messages to specific topics on the queue, and other agents subscribe to relevant topics to receive updates and requests. A standardized data format (e.g., JSON) ensures seamless communication and interoperability between agents.

2.2 Data Flow

Project Initiation: The user provides initial project information and goals through a web interface or API. This information is published to the message queue, triggering the data collection process.
Data Collection: Each agent independently gathers data from relevant sources:
- Documentation Agent: Accesses and parses project documents stored in a document repository (e.g., Confluence) using APIs.
- Code Analysis Agent: Analyzes code from a version control system (e.g., GitHub) using APIs and static code analysis tools.
- Stakeholder Interview Agent: Conducts interviews with stakeholders via video conferencing or chat platforms, transcribing and analyzing the conversations.
Requirement Generation: Each agent generates initial requirement suggestions based on its analysis. These suggestions are published to the message queue.
Feedback Loop: The Feedback Coordination Agent collects feedback from stakeholders through various channels (e.g., email, surveys) and distributes it to relevant agents for further analysis and refinement.
Requirement Refinement: Agents iteratively refine requirements based on feedback and collaboration, updating the requirements document stored in a central repository.

3. Agent Design

3.1 Documentation Agent

Natural Language Processing (NLP): Utilizes NLP libraries such as spaCy and NLTK for:
- Named Entity Recognition (NER): Identifies key entities (e.g., system components, users, actions) within documents.
- Part-of-Speech (POS) Tagging: Analyzes grammatical structure to understand the context and relationships between entities.
- Dependency Parsing: Extracts relationships between words to identify actions, subjects, and objects, building a semantic understanding of requirements.
- Topic Modeling: Identifies latent topics and themes within the documentation to understand the high-level scope and functionalities.
Requirement Extraction: Employs rule-based and machine learning models trained on labeled data to extract requirements from unstructured text.

3.2 Code Analysis Agent

Static Code Analysis: Leverages tools like SonarQube or PMD to analyze code for potential issues, design patterns, and code complexity.
Machine Learning Models: Utilizes models trained on code repositories to identify potential features, functionalities, and limitations based on existing code structure and patterns.

3.3 Stakeholder Interview Agent

Speech-to-Text: Employs speech recognition APIs (e.g., Google Cloud Speech-to-Text) to transcribe stakeholder interviews.
Natural Language Understanding (NLU): Leverages NLU models to interpret the meaning and intent behind stakeholder statements, identifying key requirements and concerns.
Dialogue Management: Utilizes dialogue management techniques to maintain context and generate relevant follow-up questions during interviews.

3.4 Feedback Coordination Agent

Feedback Aggregation: Collects and categorizes feedback from various sources.
Conflict Resolution: Identifies and resolves conflicting feedback through voting mechanisms, consensus-building techniques, or escalation to human supervisors.
Prioritization: Prioritizes feedback based on severity, urgency, and relevance to project goals.

4. Data Management

Database: A NoSQL database (e.g., MongoDB) will be used for flexible and scalable storage of project data, requirements, and feedback.
Data Security: Data at rest and in transit will be encrypted using industry-standard encryption algorithms. Access control mechanisms and user authentication will be implemented to restrict unauthorized access.
Data Anonymization: When handling sensitive information, techniques like data masking and differential privacy will be employed to protect confidentiality.

5. Deployment and Maintenance

Cloud Platform: Google Cloud Platform (GCP) will be used for its scalability, reliability, and security features.
Containerization: Docker containers will be used to package and deploy the agent microservices, ensuring portability and ease of management.
Orchestration: Kubernetes will manage container deployment, scaling, and service discovery.
Monitoring and Logging:
- Prometheus and Grafana for monitoring system performance and resource utilization.
- Cloud Logging for centralized logging and analysis of system events.
CI/CD Pipeline: A continuous integration and continuous delivery (CI/CD) pipeline will automate the build, testing, and deployment process.

6. Future Considerations

Integration with additional AI tools: Explore integration with natural language generation tools for automated documentation generation, and machine learning platforms for incorporating predictive analytics and anomaly detection capabilities.
Expansion of agent capabilities: Develop specialized agents for tasks like user interface design, testing, and risk assessment.
Incorporate Explainable AI (XAI) techniques: Provide insights into the reasoning and decision-making processes of the AI agents, enhancing transparency and trust.

7. Technical Design Doc Conclusion

The AI Requirements Agent offers a novel approach to automating and refining requirements gathering in software development. The multi-agent architecture allows for specialized expertise, scalability, and adaptability to various project needs. By leveraging NLP, machine learning, and robust data management, the system promotes efficiency, accuracy, and collaboration among stakeholders, ultimately contributing to successful project outcomes.

3. User Guide

Getting Started:

Access: The AI Requirements Agent is accessible via a web interface or API integration, depending on your preferred workflow.
Project Setup: Create a new project within the platform and input basic information like project name, description, and objectives.
Data Source Integration: Connect the AI Agent to relevant data sources such as document repositories (e.g., Confluence), code repositories (e.g., GitHub), and communication channels for stakeholder feedback.

Using the AI Agent:

Initiation: Provide the AI Agent with initial project information and goals. This can include uploading relevant documents, specifying code repositories, and scheduling stakeholder interviews.
Requirement Review: The AI Agent will process the data and generate an initial set of requirements. Review these requirements and provide feedback or clarification as needed.
Feedback Loop: Respond to prompts from the AI Agent to clarify ambiguities or provide additional information. This feedback will be used to refine the requirements iteratively.
Documentation: Access the continuously updated requirements document generated by the AI Agent. You can export the document in various formats for further use.
Notifications: Stay informed about the progress of requirements gathering and refinement through notifications and alerts sent by the AI Agent.

Troubleshooting and FAQs:

Issue: Difficulty connecting to data sources.
- Solution: Ensure you have the correct access credentials and permissions for the data sources. Contact your system administrator if necessary.
Issue: Ambiguous or incomplete requirements generated.
- Solution: Provide additional context and feedback to the AI Agent through prompts and clarification requests.
Issue: Conflicting feedback from stakeholders.
- Solution: The AI Agent will identify and highlight conflicting feedback. Collaborate with stakeholders to reach a consensus or escalate the issue to a human supervisor if needed.

For more detailed troubleshooting and FAQs, please refer to the dedicated support documentation (normally link to further support documentation).

4. System Design Diagram

This (normally a flowchart, not text) visually depicts the system design of the AI Requirements Agent, outlining the data flow, agent interactions, and key processes involved in requirements gathering and refinement. It provides a high-level overview of how the system functions and interacts with external data sources and user feedback.

Flowchart Elements:

Terminator: Represents the start and end points of the process (oval shape).
Process: Represents an action or operation performed by the system (rectangle shape).
Decision: Represents a point where the flow branches based on a condition (diamond shape).
Data: Represents data input or output (parallelogram shape).
Subroutine: Represents a reusable set of actions (rounded rectangle shape).
Document: Represents a document or report (rectangle with wavy bottom).

Flowchart Flow:

Start: The process begins with the user initiating the AI Requirements Agent and providing initial project information (e.g., project description, goals).
Data Collection:
- Documentation Agent: Accesses and parses project documents from a document repository (e.g., Confluence).
- Code Analysis Agent: Analyzes code from a version control system (e.g., GitHub).
- Stakeholder Interview Agent: Conducts interviews with stakeholders and transcribes the conversations.
Requirement Generation: Each agent analyzes the gathered data and generates initial requirement suggestions.
Feedback Loop:
- Feedback Collection: The Feedback Coordination Agent gathers feedback from stakeholders through various channels (e.g., email, surveys).
- Feedback Analysis: The Feedback Coordination Agent analyzes and categorizes the feedback.
- Conflict Resolution: The Feedback Coordination Agent resolves conflicting feedback through voting, consensus building, or escalation.
Requirement Refinement: Agents refine requirements based on the feedback received, iteratively improving accuracy and completeness.
Requirements Documentation: The refined requirements are compiled into a comprehensive document accessible to all stakeholders.
Notifications: The AI Agent sends alerts to users about updates, changes, or required actions.
End: The process concludes with a well-defined set of requirements documented and accessible for software development.

Functional Requirements (represented by process boxes):

Gather data from various sources (documents, code, interviews).
Analyze data using NLP and ML techniques.
Generate initial requirement suggestions.
Collect and analyze stakeholder feedback.
Resolve conflicting feedback.
Refine requirements based on feedback.
Generate requirements documentation.
Send notifications to users.

Non-Functional Requirements (implicitly represented):

Performance: The system should be responsive and efficient in processing data and generating outputs.
Scalability: The system should be able to handle projects of different sizes and complexities.
Security: The system should protect sensitive project information and comply with data privacy regulations.
Availability: The system should be accessible to users when needed.
Usability: The user interface should be intuitive and easy to use.
Maintainability: The system should be easy to maintain and update.
Reliability: The system should function consistently and reliably.

Additional Notes:

The flowchart can be further elaborated to show the specific NLP and ML techniques used by each agent.
Decision points can be added to illustrate conditional branching based on specific criteria (e.g., confidence level of generated requirements).
Data inputs and outputs can be labeled with specific data formats (e.g., JSON, text files).

By visualizing the system design with a flowchart, we gain a clearer understanding of the AI Requirements Agent's workflow and the functional and non-functional requirements that guide its development and implementation.

Agent Responsibilities and Prompting Techniques:

This document details the prompting techniques and interaction strategies employed by the AI Requirements Agent to facilitate efficient and accurate requirements gathering and refinement. We will explore how each agent leverages prompts to elicit information, generate suggestions, and collaborate with other agents.

1. Documentation Agent:

Responsibility: Analyze existing project documentation, extract relevant information, and identify potential gaps or inconsistencies.
Prompting Techniques:
- Information Extraction Prompts: These prompts guide the agent to extract specific information from documents, such as functional requirements, use cases, and user stories.
- Gap Analysis Prompts: These prompts help the agent identify missing or incomplete information in the documentation, prompting further investigation or clarification requests.
- Consistency Check Prompts: These prompts guide the agent to compare information across different documents and identify inconsistencies or contradictions.

2. Code Analysis Agent:

Responsibility: Review the code base, suggesting requirements based on current system functionalities and limitations.
Prompting Techniques:
- Functionality Identification Prompts: These prompts guide the agent to identify functionalities implemented in the code, helping to define functional requirements.
- Limitation Detection Prompts: These prompts guide the agent to identify limitations or constraints imposed by the current codebase, informing non-functional requirements.
- Design Pattern Recognition Prompts: These prompts help the agent identify design patterns and architectural decisions, offering insights into potential system requirements.

3. Stakeholder Interview Agent:

Responsibility: Conduct and analyze stakeholder interviews, deriving requirements from natural language input.
Prompting Techniques:
- Open-Ended Interview Prompts: These prompts encourage stakeholders to share their needs, expectations, and concerns openly.
- Specific Inquiry Prompts: These prompts are used to clarify specific details or gather additional information on particular topics.
- Follow-up Prompts: These prompts are generated dynamically based on stakeholder responses to probe deeper into specific areas of interest.

4. Feedback Coordination Agent:

Responsibility: Manage the feedback loop, integrating input from stakeholders and other agents to refine requirements iteratively.
Prompting Techniques:
- Feedback Categorization Prompts: These prompts help the agent categorize feedback based on its nature (e.g., clarification, suggestion, concern).
- Conflict Identification Prompts: These prompts guide the agent to identify conflicting feedback or opinions from different stakeholders.
- Consensus Building Prompts: These prompts facilitate discussion and collaboration between stakeholders to reach consensus on requirements.

Agent Communication and Prompt Chaining:

The AI agents communicate and collaborate using a message queue system and a standardized data format. This enables prompt chaining, where the output of one agent's prompts can become the input for another agent's prompts, creating an iterative refinement process.

Examples of Agent Interactions:

Documentation Agent to Stakeholder Interview Agent: If the Documentation Agent identifies missing information or inconsistencies, it can generate prompts for the Stakeholder Interview Agent to ask specific clarifying questions during interviews.
Code Analysis Agent to Documentation Agent: If the Code Analysis Agent identifies functionalities not documented, it can prompt the Documentation Agent to review specific code sections and update the documentation accordingly.
Stakeholder Interview Agent to Feedback Coordination Agent: The Stakeholder Interview Agent provides transcribed interviews and summarized insights to the Feedback Coordination Agent, enabling targeted feedback collection and analysis.
Feedback Coordination Agent to all agents: The Feedback Coordination Agent distributes categorized feedback to relevant agents, triggering further analysis and refinement of requirements.

Iterative Prompt Generation and Tuning:

Prompt Templates: Each agent utilizes pre-defined prompt templates tailored to their specific tasks and responsibilities.
Dynamic Prompt Generation: Based on the context and information gathered, agents dynamically generate prompts to gather additional details, clarify ambiguities, and refine requirements.
Prompt Tuning: The effectiveness of prompts is continuously monitored and evaluated. Agents can learn from feedback and adapt their prompting techniques to improve accuracy and efficiency.

By implementing these prompt engineering techniques and inter-agent communication strategies, the AI Requirements Agent facilitates a collaborative and iterative process, leading to well-defined, comprehensive, and accurate software requirements.

Citation close

Conclusion

The AI Requirements Agent, with its comprehensive documentation encompassing PRD, TDD, User Guide, System Design Diagram, and Prompt Engineering strategies, provides a robust and transparent framework for automating and refining the software requirements process. This initiative promises to significantly improve efficiency, accuracy, and collaboration, leading to more successful software development projects.

Glossary of AI Agent Types

In artificial intelligence, the concept of an agent refers to a computer program or system designed to perceive its environment and act towards achieving specific goals. Agents can operate autonomously and are fundamental to many applications, including robotics, gaming, and intelligent systems.

Here’s an overview of different types of agents and their use cases:

Simple Reflex Agents: Operate on a direct condition-action basis, responding only to current percepts. Their use is limited to highly predictable environments where every percept can be accounted for with a specific action. They are not suitable for environments where past or future states need consideration.
Model-Based Reflex Agents: These agents maintain an internal state to handle partially observable environments. They rely on a model of the world to decide actions, considering both the current percept and the knowledge of how the world works. These agents are more adaptable to changing conditions than simple reflex agents.
Goal-Based Agents: These agents act to achieve specific goals and make decisions based on the likelihood of actions bringing them closer to these goals. They are used in complex environments where several paths might achieve the desired outcome, requiring planning and decision-making capabilities.
Utility-Based Agents: They not only aim to achieve goals but also do so with an optimal performance metric, maximizing their perceived happiness or utility. This approach is useful in scenarios where there are multiple possible satisfactory outcomes, and some are preferable over others.
Learning Agents: These agents can improve their performance over time based on experience, adapting to new conditions and requirements without direct programming. Learning agents are vital in environments that evolve or where initial information is incomplete.
Multi-Agent Systems (MAS): Involving multiple interacting agents, MAS can solve problems that are too large or complex for a single agent. These systems are categorized based on whether the agents cooperate, compete, or both. Applications include automated trading systems, robotic teams, and complex simulation environments.
Hierarchical Agents: Organized in a tiered structure, these agents delegate responsibilities from higher-level agents down to lower-level agents who handle specific tasks. This setup is effective in managing complex systems with multiple interacting components, such as manufacturing and transportation management systems.

Each type of agent is suited to particular environments and tasks, from simple automation and responses to complex problem-solving and learning scenarios. The deployment of these agents depends significantly on the specific requirements and constraints of the application area.

Clean Code Studio

There's a reason neurologist don't do open heart surgery.

Clean Code Studio — Mon, 20 Nov 2023 20:03:36 +0000

There’s a reason Neurologist don’t do open heart surgery.

The medical field is too large for any single doctor to know everything.

The technology field is the same way.

Being deliberate, choosing a path, and following thru with daily disciplined practice is a requirement for mastery in the technology field as well.

It’s easy to forget this lesson sometimes.

Clean Code Studio

Don't Eat the 🍪 [All In One Bite]

Clean Code Studio — Sun, 05 Nov 2023 22:48:28 +0000

So it Began...

I was 22 years of age, it was the year of 2019 nearing the now historic year of 2020.

My dedication, or more specifically my unconstrained willingness to give enormous amounts of my time beyond 40 hours in order to get ahead early in my corporate career, provided me with a great deal of “real world” experience that empowered me to handle many complex(ish) tasks from an early age before most had even graduated from college.

Gazing thru second story windows that arched 25 feet and spanned hundreds of feet from wall to wall, I would often allow myself to zone out into the mind palace as I playfully gazed with twinkled eyes at the airplane lanes as toylike planes that were all but toys came tuttering down from the clouds as if to want to greet you first hand while others fluttered from inches off the ground as they sped off into the distance until they were miles in the sky and nothing more than a distance spec as they went on their way without ever as much as an audible goodbye.

Each and every day, good weather permitting, these little private airplanes came cruising on in and fluttering on off within this magnificent vantage point that was accessible to those who were fortunate to have the benefit of working at a Marketing Agency like VMLY&R who used such a perspective as a way to aww their potential clients and captivate fortune 500 companies by walking them from the runway directly into the board meeting rooms one sliding door away from the very private airplane the executives who came to do business flew into Kansas City on.

VMLY&R quite brilliantly re-modeled an old downtown Kansas City airport into an eye catching spectacle that one could call a marketing agency's dream of a corporate Head Quarters that intended and succeeded in capturing interest and attention from the many clients they courted from the Fortune 500 list including the likes of Wendy's, United Rentals, Ford, Heinz, Gatorade, Taco Bell, and several more easily recognizable brands.

Visualize a “Google-esc” design with the added meditative benefits of small planes dazzling your vantage points with fascination thru out the day as things that are as intrinsically interesting as flight tend to do when it comes to directing a statistically measurable amount of the human attention into a given direction relative to other potential stimuli that are simply often less fascinating than the pursuits of flight.

VMLY&R had an impressive Authority in the Marketing world in which they pinnacled their Digital Marketing excellence for display to the world at that remodeled Kansas City Airport they dubbed as their marketing empire's Home Base.

Out of context Wisdom, captivated my curiosity

“Don’t eat the 🍪 all in one bite.”

Whoa...I thought for half a second, was that my own sub-conscience?

It was so profound in terms of its timing and quality. The kind of advice that just sank into the very being of your essence as it was both the information and within the right location in which you were traveling thru space time to have profound impact to the point of it becoming a life long memory.

After a second of realizing my conscience hadn’t suddenly actualized part of its essence into a Yoda like essense to transcend the normal internal communication and perception capabilities -- I came to realize I had to focus on the physical world outside of my own thoughts which had previously engulfed my entire attention span with ideas drifted off into space alongside the airplanes flying in and eventually taking off from the run ways. A place where thought was unconfined by prior ideas and was just freely wondering - I was in my own mind palace that day and very content being there at that.

Yet, once I had shifted and properly interfaced my attention towards the physical world immediately around me again, I quickly was caught off guard by the fact my mentor - an older dude named logan (one of the best mentors I've ever had with decades of experience on me at the time) had just dropped some timeless old man wisdom on me during the exact moment in which my mind was completely caught off guard to the point of genuine curiosity being the default state as I was surprised by the very voice -- and then overwhelmed with happiness at the content of the words spoken.

Wisdom is both well said as well as said at the right time and in a place in which the thing being said has the potential to genuinely be heard.

“Huh?” I asked - as if I hadn't heard it. But I had, what I lacked was an understanding of the context in which Logan decided it was of value to randomly drop such a profound statement of wisdom in which appeared from my perspective to be coming out of the blue of nothingness which felt as profound as a color being derived from the color-less.

Logan expanded the context to allow my attention to direct towards a shared point within his attention span in which the reasoning for such profound wisdom being dropped made more contextual since.

Adding context to his of his original remark, Logan continued

“Your PR man, a lot of your PRs actually, they’re good but these things are absolutely freaking huge. You’re trying to tackle very complex things all in one go. The problem isn’t the quality or how your tackling the problem in terms of design or architecture - the problem is the size of the 🍪. You're trying to eat it all in one bite.

Don’t do that, break it up into smaller bites. Quit trying to eat the 🍪 all in one bite and break it up into smaller more digestible chunks”

Logan’s Wisdom stunned me with the [now paraphrased] quote because he was right - and I had not noticed in the least bit until then. I had always liked eating cookies in one bite (and yes, I mean both literally and metaphorically).

The truth was, that - although simple - it was (and still is) the best advice I have ever received in my career as an engineer.

“Don’t eat the 🍪 all in one bite.”

Clean Code Studio

Mastering Binary Search

Clean Code Studio — Mon, 16 Oct 2023 00:22:28 +0000

LeetCode Practice Problems for each Binary Search Implementation and Variation Linked Below

(My personal study notes)

Mastering Binary Search
- Variations of Binary Search (patterns to practice)
  - 1. Classic Binary Search
  - 2. Modified Binary Search
  - 3. Find the Closest Element to a Target
  - 4. Find the Peak Element
  - 5. Find Rotation Point in a Rotated Sorted Array
  - 6. Find First and Last Position of an Element
  - When to Use Binary Search
  - When Not to Use Binary Search
- LeetCode Binary Search
- Points of note to study

Variations of Binary Search (patterns to practice)

Worth knocking these into muscle memory

1. Classic Binary Search

function binarySearch(arr, target) {
    let start = 0
    let end = arr.length - 1

    while (start <= end) {
        let mid = Math.floor((start + end) / 2)

        if (arr[mid] === target) return mid

        if (arr[mid] < target) start = mid + 1
        if (arr[mid] > target) end = mid - 1
    }

    return - 1
}

2. Modified Binary Search

function modifiedBinarySearch(arr, target) {
  let start = 0;
  let end = arr.length - 1;
  let result = -1;  // Initialize result

  while (start <= end) {
    let mid = Math.floor((start + end) / 2);

    // Exact match
    if (arr[mid] === target) {
      result = mid;
      // For the first occurrence, keep going left
      end = mid - 1;
    }

    // Standard binary search logic
    if (arr[mid] < target) {
      start = mid + 1;
    } else {
      end = mid - 1;
    }
  }

  return result;
}

Remember, the "Modified Condition" is the part you'd customize based on what specific problem you're tackling.

3. Find the Closest Element to a Target

Here, you have to find the closest element to a given target in a sorted array.

function closestElement(arr, target) {
  let start = 0, end = arr.length - 1;
  while (start < end) {
    let mid = Math.floor((start + end) / 2);
    if (arr[mid] === target) return mid;
    if (Math.abs(arr[mid] - target) <= Math.abs(arr[mid + 1] - target)) {
      end = mid;
    } else {
      start = mid + 1;
    }
  }
  return start;
}

4. Find the Peak Element

In an array where adjacent elements are distinct, find a peak element. An element is considered peak if it is greater than its neighbors.

function findPeakElement(arr) {
  let start = 0, end = arr.length - 1;
  while (start < end) {
    let mid = Math.floor((start + end) / 2);
    if (arr[mid] < arr[mid + 1]) {
      start = mid + 1;
    } else {
      end = mid;
    }
  }
  return start;
}

5. Find Rotation Point in a Rotated Sorted Array

For a rotated sorted array, find the index where the smallest element is.

function findRotationPoint(arr) {
  let start = 0, end = arr.length - 1;
  while (start < end) {
    let mid = Math.floor((start + end) / 2);
    if (arr[mid] > arr[end]) {
      start = mid + 1;
    } else {
      end = mid;
    }
  }
  return start;
}

6. Find First and Last Position of an Element

In a sorted array with duplicates, find the starting and ending position of a given target value.

function searchRange(arr, target) {
  let start = 0, end = arr.length - 1, first = -1, last = -1;
  while (start <= end) {
    let mid = Math.floor((start + end) / 2);
    if (arr[mid] === target) {
      first = mid;
      end = mid - 1;
    } else if (arr[mid] < target) {
      start = mid + 1;
    } else {
      end = mid - 1;
    }
  }

  start = 0, end = arr.length - 1;
  while (start <= end) {
    let mid = Math.floor((start + end) / 2);
    if (arr[mid] === target) {
      last = mid;
      start = mid + 1;
    } else if (arr[mid] < target) {
      start = mid + 1;
    } else {
      end = mid - 1;
    }
  }

  return [first, last];
}

Knowing when to use binary search depends on several factors, such as the problem constraints and the properties of the data. Here are some general guidelines:

When to Use Binary Search

Sorted Data: The most fundamental prerequisite for binary search is that the data must be sorted.
Time Complexity: If the problem requires better than O(n)O(n)O(n) time complexity, binary search often becomes a candidate with its O(log⁡n)O(\log n)O(logn) time.
Constant Space: If you need to solve the problem with constant extra space, binary search can be a good choice since it only requires pointers like start, end, and mid.
Multiple Queries: In cases where there are multiple queries on static data, preparing a sorted structure for binary search might be beneficial in the long run.
Search Conditions: If the problem involves searching for a particular condition rather than a specific element (e.g., find the point where a function changes behavior), binary search could apply.

When Not to Use Binary Search

Unsorted Data: If the data is not sorted and cannot be sorted in better than O(nlog⁡n)O(n \log n)O(nlogn) time, then binary search is likely not a fit.
Updates: If the data set is being updated frequently, maintaining the sorted order might be costly unless specialized data structures like balanced trees are used.
Linear Scanning is Enough: For smaller datasets or when O(n)O(n)O(n) time complexity is acceptable, a simpler linear search might suffice.
Exact Matches: If you're looking for a range or pair of values rather than an exact match, binary search might require modifications and might not be the most straightforward approach.
Space Complexity: When extra space is not a constraint, other techniques like Hashing might be simpler and more suitable for certain types of search problems.

When approaching a problem, look at the constraints and see if binary search can give you an edge in time complexity, or if the problem's nature naturally lends itself to a binary search approach.

LeetCode Binary Search

Standard Binary Search (Standard Binary Search)
- Binary Search
Find First and Last Position of Element in Sorted Array (Standard Binary Search)
- Find First and Last Position of Element in Sorted Array
Search in Rotated Sorted Array (Rotated Array Binary Search)
- Search in Rotated Sorted Array
- Search in Rotated Sorted Array II
Find Minimum in Rotated Sorted Array (Rotated Array Binary Search)
- Find Minimum in Rotated Sorted Array
- Find Minimum in Rotated Sorted Array II
Closest Element to a Target (Standard Binary Search)
- Closest Binary Search Tree Value
Find Peak Element (Modified Binary Search)
- Find Peak Element
Find the Smallest or Largest Element Greater Than a Given Number (Modified Binary Search)
- First Bad Version
Find Kth Element (Modified Binary Search)
- Kth Smallest Element in a Sorted Matrix
- Find Kth Smallest Pair Distance
Variable Length Arrays (String, Range Queries) (Modified Binary Search)
- Longest Increasing Subsequence
- Range Sum Query - Immutable
Others (Miscellaneous)
- Search a 2D Matrix
- Search a 2D Matrix II

Points of note to study

Classic Binary Search vs. Modified Binary Search
while(start <= end) vs. while(start < end)

I built an industrial scale web scraper. Here's what I learned.

Clean Code Studio — Tue, 18 Jul 2023 01:44:54 +0000

Recently, I built an industrial scale web scraper. Here's what I learned.

1. Why build a scalable scraper/crawler?

Google's primary product (their Search Engine) is empowered by web scrapers & crawl extracting data from the internet at an unfathomable level of scale.
Open AI's capability (and willingness) to access data using scrapers & crawlers at internet wide scale is what empowered them to build (and continually improve) ChatGPT.
Unlike last decade, intelligence is something you can build, use, and sell with the one catch being you require an immense amount of one resource to do so and that resource is a hell of a lot of data.

*2. Using chromium programmatically is helpful (I chose Puppeteer)
*

3. Industrial scale requires using proxies (I rotated between residential proxies)

*4. Bots can find rules via a robots.txt file for a site (Ask SEO experts about it)
*

5. Bypassing captchas, although ethically questionable, doesn't seem to be an illegal act to program your robot to take. (I explored Github python programs that were capable of this to satisfy my own curiosity).

Why cross-platform apps looking to scale should use RPC (over plain old IPC and instead of REST)

Clean Code Studio — Fri, 09 Jun 2023 23:13:54 +0000

IPC (Inter-process communication) and RPC (Remote procedure call) are both methods of communication between processes. However, there are some key differences between the two methods that make RPC a more suitable choice for cross-platform desktop applications.

IPC is a general term for any method of communication between processes. It can be implemented in a variety of ways, including shared memory, pipes, and sockets. IPC is typically used for communication between processes on the same machine.

RPC is a more specific type of IPC that allows processes to communicate with each other over a network. RPC is typically implemented using a client-server model. The client process makes a request to the server process, and the server process returns a response.

There are several reasons why using RPC over IPC is important for cross-platform desktop applications:

Security: RPC can be used to implement security features, such as authentication and authorization. This is important for cross-platform desktop applications, as they may need to communicate with servers that are not under the control of the application developer.
Scalability: RPC can be used to scale applications. For example, an application can use RPC to communicate with a server that is running on a different machine. This can help to improve the performance of the application, as it can offload some of the processing to the server.
Portability: RPC is a more portable method of communication than IPC. This is because RPC is typically implemented using a standard protocol, such as the Remote Procedure Call (RPC) Protocol. This means that RPC can be used to communicate between processes that are running on different platforms.

Overall, RPC is a more secure, scalable, and portable method of communication than IPC. This makes RPC a more suitable choice for cross-platform desktop applications.

RPC (Remote Procedure Call) and REST (Representational State Transfer) are both methods of communication between a client and a server. However, there are some key differences between the two methods that make RPC a more suitable choice for cross-platform desktop applications.

RPC

RPC is a method of communication that allows a client to call a procedure on a server as if it were calling a local procedure. This is done by sending a message to the server that contains the name of the procedure and the arguments to be passed to the procedure. The server then executes the procedure and returns a message to the client containing the results of the procedure.

REST

REST is a method of communication that uses HTTP requests to access resources on a server. This is done by sending an HTTP request to the server that specifies the resource to be accessed and the desired action to be performed on the resource. The server then returns an HTTP response that contains the requested resource or an error message.

Why RPC is important for cross-platform desktop applications that want to scale

There are several reasons why RPC is important for cross-platform desktop applications:

Performance: RPC can be more efficient than REST for cross-platform desktop applications because it can avoid the overhead of HTTP requests.
Security: RPC can be more secure than REST for cross-platform desktop applications because it can use authentication and authorization mechanisms to protect data.
Portability: RPC can be more portable than REST for cross-platform desktop applications because it is not tied to a specific protocol.

Why REST is not as suitable for cross platform apps

REST is not suitable for cross-platform desktop applications because it is not as efficient, secure, or portable as RPC.

Efficiency: REST is less efficient than RPC because it requires the client to make an HTTP request for every resource that it needs to access. This can add overhead and latency to the application.
Security: REST is less secure than RPC because it does not support authentication and authorization mechanisms. This can make it easier for unauthorized users to access sensitive data.
Portability: REST is less portable than RPC because it is tied to the HTTP protocol. This can make it difficult to use REST with applications that are not web-based.

Overall, RPC is a more suitable choice for cross-platform desktop applications than REST. RPC is more efficient, secure, and portable than REST, which makes it a better choice for applications that need to be performant, secure, and portable.

By implementing RPC based on something like JSON RPC 2.0 and using an RPC implementation as a layer on top of your IPC communication you are able to decouple the data layer from the GUI layer of your cross platform application and ultimately expand beyond the constraints put on you, your team, and your project by default when building a cross platform desktop app's like when building out applications when any of the following technologies:

Conclusion

While RPC APIs, REST APIs, and IPC communication can all be used together, our industry has a bias towards using REST over RPC and IPC due to a lack of knowledge and a lack of need for tools that allow processes to communicate with each other.

Using REST instead of RPC can make it difficult to build applications that need to have services communicate with each other via server-side streaming, client-side streaming, or bi-directional streaming.

My team needed to create a click and point GUI alternative around an existing command line interface, and command line interface programs come with a lot of streaming of data.

Rest wasn't an option, IPC was our default because for Tauri, Electron, and Wails that's what is in the documentation.

But the best option is to implement IPC via some sort of RPC specification and decouple the data layer from the GUI layer.

Using IPC without a specification, such as the JSON RPC 2.0 spec, can make it difficult to authenticate users and can limit an application's data layer to only communicating between processes on the same machine. This can prevent an application from being able to run as a process on any device or server and as a cross platform application scales and grows, the monolithic nature of distributed artifacts will constrain the ability to build cool things while also greatly slowing down the software development cycle as the User Interface and User Experience becomes inhibited by any cross platform concerns and bugs.

Instead, from the get go, use RPC for IPC communication and decouple your front-end GUI from your back-end data layer while setting your self, your project, and your team up for long term success by eliminating any constraints.

Chat GPT-4 Already Used In the Wild (Stripe, Duolingo, Khan Academy, etc...)

Clean Code Studio — Thu, 16 Mar 2023 02:41:20 +0000

Stripe

Stripe, a leading online payment processing platform, is leveraging ChatGPT-4 to enhance its customer support experience. Read more

Automating customer support responses
Assisting human agents with accurate information
Reducing response times for customer queries

Duolingo

Duolingo, a popular language-learning platform, is using ChatGPT-4 to improve its language learning tools and user experience. Read more

Enhancing language learning exercises
Generating contextual language examples
Offering personalized feedback to users

Khan Academy

Khan Academy, an educational organization providing free online courses, is utilizing ChatGPT-4 to supplement its learning materials. Read more

Providing instant feedback on student work
Generating additional practice questions
Assisting teachers in creating personalized learning experiences

Be My Eyes

Be My Eyes, an app that connects blind and low-vision individuals with sighted volunteers, is implementing ChatGPT-4 to offer real-time assistance. Read more

Translating text in images for visually impaired users
Providing instant support through AI-based responses
Reducing dependency on human volunteers for text recognition tasks

Morgan Stanley

Morgan Stanley, a multinational investment bank and financial services company, is employing ChatGPT-4 for various financial applications. Read more

Analyzing financial documents
Generating market insights and summaries
Enhancing customer support in finance-related queries

Government of Iceland

The Government of Iceland, in collaboration with Almannarómur and Miðeind, is using ChatGPT-4 to preserve the Icelandic language. Read more

Training GPT-4 on Icelandic grammar and cultural knowledge
Developing voice assistant apps (Embla) for fluent Icelandic conversations
Creating Icelandic-speaking chatbots for company websites

AI Technology

Each of these companies is using ChatGPT-4 in unique ways to improve their products, services, and user experience, demonstrating the versatility and potential of AI technology across various industries available as of today.

Clean Code Studio

Insertion Sort (Python Algorithms)

Clean Code Studio — Sun, 05 Feb 2023 14:12:53 +0000

Insertion sort is a simple sorting algorithm that builds the final sorted array (or list) one item at a time. It is much less efficient on large lists than more advanced algorithms such as quicksort, heapsort, or merge sort.

def insertion_sort(arr):
    for i in range(1, len(arr)):
        key = arr[i]
        j = i-1
        while j >= 0 and key < arr[j] :
                arr[j + 1] = arr[j]
                j -= 1
        arr[j + 1] = key
    return arr

The time complexity of insertion sort is O(n^2).

Python
Algorithms
Sorting Algorithms
Insertion Sorting Algorithm

Python Insertion Sorting Algorithm

Bubble Sort (Python Algorithms)

Clean Code Studio — Sun, 05 Feb 2023 14:04:40 +0000

Bubble sort is a simple sorting algorithm that repeatedly steps through the list, compares adjacent elements and swaps them if they are in the wrong order. The algorithm gets its name from the way smaller elements "bubble" to the top of the list.

def bubble_sort(arr):
    n = len(arr)
    for i in range(n):
        for j in range(0, n-i-1):
            if arr[j] > arr[j+1]:
                arr[j], arr[j+1] = arr[j+1], arr[j]
    return arr

The time complexity of bubble sort is O(n^2).

Clean Code Studio ~ Python ~ Algorithms

Liskov's Substitution Principle (Python Design Patterns)

Clean Code Studio — Sun, 05 Feb 2023 13:40:17 +0000

The Liskov Substitution Principle (LSP) states that objects of a superclass should be replaceable with objects of a subclass without affecting the correctness of the program. This means that a subclass should be a subtype of its superclass, and the behavior of the program should remain the same whether we use the superclass or a subclass. Here's an example in Python:

In this example, the Rectangle class defines the behavior for rectangles, and the Square class inherits from it and represents squares. The use_it function uses a rectangle-like object, such as a Rectangle or a Square, to calculate its area. The function calls the set_height method and then asserts that the area is correct.

When we pass a Rectangle object to use_it, it works as expected and the assertion is true. When we pass a Square object to use_it, it also works and the assertion is true, even though the Square class overrides the behavior of the set_width and set_height methods. This means that the Square class is a subtype of the Rectangle class, and objects of the Square class can be used wherever objects of the Rectangle class are expected, without affecting the correctness of the program. This adheres to the Liskov Substitution Principle.

Python
Design Patterns
Clean Code Studio
Python Design Patterns
Python Liskov's Substitution Principle Design Pattern
Liskov Substitution Design Pattern

Python Open Closed Design Pattern (Python SOLID Principles)

Clean Code Studio — Sun, 05 Feb 2023 13:25:42 +0000

The Open/Closed Principle states that a module (such as a class, function, etc.) should be open for extension but closed for modification. In other words, a module should be designed in such a way that it can be easily extended without changing its existing code.

Here's an example in Python:

In this example, the Shape class is an abstract base class that defines the interface for all shapes, and the Circle and Rectangle classes inherit from it and provide concrete implementations of the area method. The calculate_area function takes a list of shapes and calculates the total area by calling the area method on each shape.

By using inheritance and an abstract base class, the existing code can be extended to support new shapes without having to modify the existing code. For example, if we wanted to add a square shape, we could simply create a Square class that inherits from Shapeand provide an implementation of the area method. This adheres to the Open/Closed Principle as the existing code remains closed for modification, while new functionality can be added through extension.

Python
Design Patterns
Clean Code Studio
Python Design Patterns
Python Open Closed Principle Design Pattern
Open Closed Principle (OCP)

Forem: Clean Code Studio

TS Dependency Injection with @Findhow/Container No Decorators Required 🔥

@findhow/container

@findhow/container Compared

🚀 Key Features Breakdown

Examples

Basic Container Binding

Singleton Binding

Zod Schema Validation on Binding

Invalid Schema Detection

Schema Validation with Nested Objects

Conditional Schema Validation

Async Binding with Zod Schema Validation

Contextual Binding with Zod Schema Validation

Zod Schema Validation with Bound Object

Invalid Zod Schema Error

Async Binding with Zod Schema Validation

Why @findhow/container?

(NEW) [Product Initiative] Requirements Gathering Automation with AI Agents

Requirements Gathering Capable AI Agents

1. Product Requirements Doc (PRD)

Goals

Business Goals

User Goals

Non-Goals

User Stories

User Experience

Success Metrics

Technical Considerations

Milestones & Sequencing

Narrative

2. Technical Design Document (TDD): AI Requirements Agent

1. Introduction

2. System Architecture

2.1 Agent Communication and Interaction

2.2 Data Flow

3. Agent Design

3.1 Documentation Agent

3.2 Code Analysis Agent

3.3 Stakeholder Interview Agent

3.4 Feedback Coordination Agent

4. Data Management

5. Deployment and Maintenance

6. Future Considerations

7. Technical Design Doc Conclusion

3. User Guide

Getting Started:

Using the AI Agent:

Troubleshooting and FAQs:

4. System Design Diagram

Flowchart Elements:

Flowchart Flow:

Functional Requirements (represented by process boxes):

Non-Functional Requirements (implicitly represented):

Additional Notes:

Agent Responsibilities and Prompting Techniques:

1. Documentation Agent:

2. Code Analysis Agent:

3. Stakeholder Interview Agent:

4. Feedback Coordination Agent:

Agent Communication and Prompt Chaining:

Iterative Prompt Generation and Tuning:

Conclusion

Glossary of AI Agent Types

There's a reason neurologist don't do open heart surgery.

Don't Eat the 🍪 [All In One Bite]

So it Began...

Out of context Wisdom, captivated my curiosity

Mastering Binary Search

Variations of Binary Search (patterns to practice)

1. Classic Binary Search

2. Modified Binary Search

3. Find the Closest Element to a Target

4. Find the Peak Element

5. Find Rotation Point in a Rotated Sorted Array

6. Find First and Last Position of an Element

When to Use Binary Search

When Not to Use Binary Search

LeetCode Binary Search

Points of note to study

Why `@findhow/container`?