What do you mean by tactics? Explain the availability tactics with a neat diagram

 

What do you mean by Tactics?

In the context of software architecture and quality attributes, tactics are design decisions or architectural approaches used to achieve particular quality attribute goals, such as performance, availability, security, or modifiability.

Tactics are reusable solutions that influence the response of a system to a stimulus affecting a quality attribute.

Each quality attribute (like Availability) has a set of tactics that either help to achieve, maintain, or recover that attribute.

---

What are Availability Tactics?

Availability refers to the readiness of the system to provide its services when needed. Availability tactics aim to reduce system downtime (both planned and unplanned).

Availability tactics are broadly categorized into two:

1. Fault Detection Tactics

2. Fault Recovery Tactics

---

1. Fault Detection Tactics

These help in identifying the presence of a fault as early as possible.

Tactic	Description
Ping/Echo	Periodic message exchanges to check if a component is responsive.
Heartbeat	Regular signals sent from one component to another to indicate it's alive.
Exceptions	Use of try/catch blocks to detect faults during execution.
Monitoring	Continuously observe metrics like CPU usage, latency, etc., to detect anomalies.

---

2. Fault Recovery Tactics

These help in restoring the system to normal operation after a fault has occurred.

They are further classified into:

A. Preparation and Repair

Tactic	Description
Retry	Automatically retry failed operations.
Exception Handling	Gracefully handle exceptions without crashing.
Checkpoint/Restart	Save system state periodically and resume from last known good state.
State Repair	Correct corrupted data to bring it to a consistent state.

B. Reintroduction

Tactic	Description
Reinitialize	Restart components or services.
Shadowing	Maintain a shadow/standby component that can take over.

C. Redundancy

Tactic	Description
Active Redundancy	Multiple components run in parallel; if one fails, others take over instantly.
Passive Redundancy	Standby component activated only when the active one fails.
Spare Components	Idle components available to replace faulty ones.

---

📘 Diagram: Availability Tactics

                           +----------------------+
                           |  Availability Tactics |
                           +----------------------+
                                      |
              --------------------------------------------------
              |                                                |
   +-------------------+                          +--------------------------+
   | Fault Detection   |                          |   Fault Recovery          |
   +-------------------+                          +--------------------------+
   | - Ping/Echo       |                          |  A. Preparation & Repair |
   | - Heartbeat       |                          |   - Retry                |
   | - Exceptions       |                         |   - Exception Handling   |
   | - Monitoring       |                         |   - Checkpoint/Restart   |
                                                   |   - State Repair        |
                                                   |
                                                   |  B. Reintroduction      |
                                                   |   - Reinitialize        |
                                                   |   - Shadowing           |
                                                   |
                                                   |  C. Redundancy          |
                                                   |   - Active              |
                                                   |   - Passive             |
                                                   |   - Spare Components    |

---

If you'd like, I can generate a neat graphical version of this diagram. Just let me know!

What concepts do programmers need to know in order to work on any tech stack?

 You're welcome! Now, to your next (excellent) question:

🧠 Core Concepts Every Programmer Should Know — Regardless of Tech Stack

Whether you’re building in Python, JavaScript, C++, or Rust… or working in frontend, backend, data science, or embedded systems, there are fundamental concepts that transcend tech stacks.

Here’s a structured breakdown:

---

✅ 1. Programming Fundamentals

These are universal across all programming languages:

• Variables, data types, and operators

• Control flow: if, for, while, switch, etc.

• Functions and recursion

• Error handling: exceptions, return codes

• Modularity: splitting logic into functions or modules

---

✅ 2. Data Structures & Algorithms (DSA)

• Common Data Structures:

  • Arrays, Lists, Stacks, Queues

  • Hash Maps / Dictionaries

  • Trees, Graphs, Heaps

• Key Algorithms:

  • Sorting, Searching

  • Recursion and Dynamic Programming

  • Graph traversal (DFS/BFS)

• Complexity Analysis: Big O notation, space/time trade-offs

💡 DSA is the backbone of problem-solving, especially in interviews and high-performance code.

---

✅ 3. Version Control

• Git: branching, commits, merges, conflict resolution

• Platforms: GitHub, GitLab, Bitbucket

💡 Crucial for collaborating and managing codebases effectively.

---

✅ 4. Problem Decomposition & Debugging

• How to break down a problem into smaller parts

• How to use print debugging, interactive debuggers, and logging

• Familiarity with stack traces, core dumps, error logs

---

✅ 5. Memory & Resource Management

Even if you're in a garbage-collected language, understanding memory helps:

• Stack vs heap

• References, pointers (esp. in C/C++)

• Garbage collection basics (for high-level langs)

• Resource cleanup (files, DB connections)

---

✅ 6. Networking Basics

• What are HTTP, TCP/IP, DNS, REST APIs

• How client-server architecture works

• How to call APIs and interpret JSON/XML responses

---

✅ 7. Databases

• Relational (SQL): Tables, Joins, Indexes, Normalization

• Non-relational (NoSQL): Key-Value, Document Stores (like MongoDB)

• Querying, transactions, and basic optimization

---

✅ 8. Operating System Concepts

• Processes, threads, concurrency

• File systems and I/O

• Scheduling and multitasking

• Permissions and user management

• Signals, system calls, interrupts

---

✅ 9. Security Basics

• Input validation and sanitization

• Authentication & Authorization

• Encryption basics (HTTPS, hashing)

• Avoiding common pitfalls like SQL injection, XSS, CSRF

---

✅ 10. Software Development Practices

• Testing: unit, integration, end-to-end

• CI/CD: pipelines, automation, deployments

• Agile/Scrum basics: sprints, standups, stories

• Writing clean code and following code conventions

---

✅ 11. Design Patterns and Architecture

• OOP Principles: Encapsulation, Inheritance, Polymorphism, Abstraction

• Design patterns: Singleton, Factory, Observer, etc.

• Architectural Patterns: MVC, microservices, monoliths, event-driven

---

✅ 12. Communication and Documentation

• Reading and writing technical documentation

• Explaining code to others

• Writing useful comments and meaningful commit messages

• Being comfortable in code reviews and pair programming

---

🧭 TL;DR – Must-Know Concepts for All Programmers

Area	Core Concepts
Fundamentals	Variables, control flow, functions
DSA	Arrays, trees, graphs, Big-O
Git	Branching, merging, collaboration
Debugging	Logs, breakpoints, stack traces
Memory	Stack/heap, garbage collection
Networking	HTTP, APIs, DNS
Databases	SQL & NoSQL, querying
OS	Threads, processes, I/O
Security	Input validation, HTTPS
Dev Practices	Testing, CI/CD, clean code
Architecture	Design patterns, MVC
Communication	Docs, code reviews, clarity

---

Would you like this turned into a printable PDF or checklist format for sharing or teaching purposes?

Q: Among must know concepts for programmers..I am not that good in debugging, memory, networking, OS, HTTPS, Clean code and CI/CD, Design Patterns and MVC and communication. I am from the old school. Could you please slightly elaborate on these.

Absolutely, and it's great that you're taking the initiative to revisit these important areas. Here's a practical and beginner-friendly breakdown of each concept, tailored for someone with solid programming experience but looking to modernize their understanding.

---

🧩 1. Debugging

What it is:

• Diagnosing and fixing bugs by understanding what your code is actually doing vs what it's supposed to do.

How to get better:

• Use a debugger (like gdb for C/C++, built-in ones in VS Code or PyCharm).

• Set breakpoints, step through code, and inspect variable values.

• Practice reading stack traces to locate the origin of crashes or exceptions.

• Use logging to record internal state without needing a debugger.

---

🧠 2. Memory Management

Key ideas:

• Stack vs Heap: Stack is fast and managed automatically (for local vars), heap is manual (malloc/free) and more flexible.

• Leaks happen when memory is allocated but not freed.

• Dangling pointers occur when memory is freed but still accessed.

Modern tools:

• Valgrind (for C/C++) detects leaks.

• Garbage-collected languages (like Python, Java) hide this, but understanding helps performance and correctness.

---

🌐 3. Networking (Basics)

What to know:

• Client-server model: a browser (client) sends requests to a server (website).

• HTTP: the protocol that powers the web.

• Understand URLs, GET/POST, and how APIs work.

• Use tools like curl or Postman to experiment with REST APIs.

---

🔐 4. HTTPS and Security

Simplified view:

• HTTP vs HTTPS: HTTPS encrypts data in transit using SSL/TLS.

• Avoids eavesdropping and man-in-the-middle attacks.

• Common web vulnerabilities to be aware of: SQL injection, XSS, CSRF.

Action:

• Use HTTPS endpoints.

• Validate inputs and escape outputs (especially in web apps).

---

🧮 5. Operating System (OS) Concepts

What matters for programmers:

• Processes & threads: How programs run concurrently.

• Context switching: What the OS does to juggle multiple programs.

• System calls: How your code talks to hardware (e.g., file I/O).

• Understand file permissions, signals, and scheduling.

---

🧼 6. Clean Code

Think of it as:

Writing code that’s easy to read, understand, and maintain.

Tips:

• Use meaningful variable and function names.

• Keep functions short and do one thing.

• Follow a consistent style guide.

• Write code for humans, not just machines.

📘 Recommended book: "Clean Code" by Robert C. Martin

---

🔄 7. CI/CD (Continuous Integration / Continuous Deployment)

Simplified:

• CI: Automatically test code when someone commits changes (e.g., GitHub Actions, Jenkins).

• CD: Automatically deploy your app when tests pass.

Why it matters:

• Avoids "it works on my machine" problems.

• Enables faster, safer releases.

• Essential in teams and large projects.

---

🏛 8. Design Patterns & MVC

Design Patterns:

• Reusable solutions to common problems in software design.

• Examples:

  • Singleton: one instance of a class

  • Factory: create objects without specifying exact class

  • Observer: subscribe to events or changes

MVC (Model-View-Controller):

• A pattern for organizing apps, especially web/GUI:

  • Model: data and business logic

  • View: UI

  • Controller: handles input and updates model/view

Why it helps:

• Promotes separation of concerns

• Easier to manage code as it grows

---

📢 9. Communication (Soft Skills)

Why it matters:

• Clear communication = fewer bugs and misunderstandings.

• Essential for teamwork, code reviews, documentation, and meetings.

Tips:

• Explain your code simply (as if teaching).

• Write clear commit messages: e.g., "Fix login bug when password is empty".

• Use diagrams or pseudocode to explain architecture.

---

🌱 Final Thought

You don’t need to master all at once, but improving a bit in each area goes a long way in becoming a modern, well-rounded developer. I can help guide you with:

• Practice tasks

• Tools to try

• Books or video resources

Would you like a weekly study plan to go through these topics bit by bit?

Q: Weekly Na!! No way I want you GPT to make life hell for people and spare me these bit by bit learnings.. sorry.

What are the consequences of letting go of strong typing in C language and making it dynamically typed?

 Letting go of strong typing in the C language and making it dynamically typed would fundamentally change the language's behavior and have significant consequences — both beneficial and detrimental. Here’s a breakdown:

---

🔧 What does it mean to make C dynamically typed?

Currently, C is statically typed and strongly typed (though not as strict as some languages like Rust or Ada). Every variable must have a declared type, and most type checks happen at compile time.

In a dynamically typed version of C:

• Variables would not need explicit type declarations.

• Type information would be tracked at runtime, not compile time.

• Type conversions could happen automatically (e.g., assigning a string to an int variable).

• It would resemble scripting languages like Python, JavaScript, or Lua in behavior.

---

✅ Possible Advantages

1. Ease of Use / Faster Prototyping

   • You can write programs faster with fewer type declarations.

   • More flexibility in variable usage (e.g., same variable holding different types at runtime).

2. More Dynamic Behaviors

   • Easier to write generic code (like what void pointers try to do today).

   • Could enable features like reflection, dynamic dispatch, or runtime method overloading.

3. Scripting Use Cases

   • C would be more usable in contexts traditionally dominated by scripting languages (e.g., configuration files, simple automation).

---

❌ Major Disadvantages

1. Performance Loss

   • C’s low-level speed comes from knowing types at compile time.

   • Runtime type checking would require additional metadata, memory usage, and slower execution (e.g., dynamic dispatch vs. static calls).

2. Increased Runtime Errors

   • Type errors would be caught only during execution, not at compile time.

   • You lose compile-time guarantees, which makes large codebases harder to maintain.

3. Memory Management Complexity

   • Dynamic types need to carry type info + size info + sometimes reference counting or garbage collection.

   • C has manual memory management—without strict types, tracking allocations, deallocations, and buffer sizes becomes error-prone.

4. Tooling Breakage

   • Existing tools like gcc, clang, linters, static analyzers, and debuggers rely heavily on type info.

   • Most of the C ecosystem would break or need to be rebuilt.

5. Undefined Behavior May Increase

   • C already has lots of undefined/unspecified behaviors.

   • Removing type checks further opens the door for memory corruption, segmentation faults, etc.

6. Loss of System Programming Use Case

   • C is used for OS kernels, device drivers, and embedded systems where strict control of memory and types is essential.

   • A dynamically typed C would be unsuitable for these applications.

---

⚖️ Analogy with Existing Languages

• Python is dynamically typed and safe, but slower and requires an interpreter.

• JavaScript is dynamically typed and loosely typed — very flexible, but notorious for confusing type coercions.

• Rust or Go are strongly and statically typed — sacrificing some flexibility for safety and performance.

• TypeScript adds types to JavaScript, not the other way around — showing that typed systems help organize large codebases.

---

🧪 Conclusion

Turning C into a dynamically typed language would:

• Remove many of the language's core advantages: speed, predictability, and low-level control.

• Make C more flexible but also more dangerous, harder to debug, and less performant.

• Essentially transform it into a completely different language.

If dynamic typing is the goal, using a different language (or embedding something like Lua/Python into a C project) is usually the better route.

Would you like to see what a "dynamically typed C-like language" might look like in practice with an example?

Q: yes

Great! Let's simulate what a dynamically typed C-like language might look like using a Python-like syntax, but with C-style flavor.

We'll take a basic statically typed C snippet and contrast it with its dynamically typed equivalent.

---

✅ C (Statically Typed Version)

#include <stdio.h>

int add(int a, int b) {
    return a + b;
}

int main() {
    int x = 10;
    int y = 20;
    int result = add(x, y);
    printf("Result: %d\n", result);
    return 0;
}

---

🔄 Hypothetical Dynamically Typed C-like Version

Let’s imagine a version where:

• No type declarations (int, char, etc.).

• Type information is handled at runtime.

• Type safety is checked only when needed.

#include <dynio> // Imaginary dynamic IO header

func add(a, b) {
    return a + b;  // Types inferred at runtime
}

func main() {
    x = 10
    y = "20"  // Mix of int and string types

    result = add(x, y)  // Could raise runtime error or do coercion
    print("Result: " + result)  // Implicit string conversion
}

In this hypothetical language:

• Variables like x, y, and result carry hidden metadata like {type: int, value: 10}.

• Operations like + must decide at runtime what behavior to apply (e.g., int + int vs string + int).

• Errors are detected at runtime: e.g., trying to add 10 + "20" may cause an error or return "1020" depending on coercion rules.

---

🔧 Under the Hood

To implement this kind of language in C (or a C runtime):

• Each variable could be a struct like:

typedef struct {
    enum { TYPE_INT, TYPE_STRING, TYPE_FLOAT, TYPE_BOOL } type;
    union {
        int i;
        float f;
        char *s;
        bool b;
    } value;
} DynamicVar;

• Every operation (+, -, *, etc.) would need a handler that checks types at runtime and dispatches accordingly.

• Memory management becomes more complex: strings and dynamic structures need ref counting or garbage collection.

---

🧪 Real-World Analogs

Some real-world languages and tools try this concept:

Tool/Language	Description
Python	Fully dynamically typed, high-level scripting.
JavaScript	Dynamically typed with implicit coercions.
Ch	A C interpreter with some dynamic features.
TinyC / tcc	A tiny C compiler, sometimes used interactively.
CINT / Cling	C/C++ interpreters used in ROOT (scientific computing).
Lua + C	Lua is a lightweight, dynamically typed language often embedded in C apps.

---

🤔 Final Thoughts

If you're interested in exploring this further, you could:

• Prototype a toy interpreter in C that treats all variables as DynamicVar.

• Embed Lua or Python into a C program to get the dynamic behavior.

• Explore languages like Zig, which are low-level like C but allow more modern features.

Would you like a toy example of how to build a "dynamic variable system" in C?

Thank you GPT Avare.. Dodd namskara

How can I train AI to program by example?

 Training AI to program by example involves creating a system that learns to generate code based on example inputs and outputs, or demonstrations of how tasks are solved. There are several approaches depending on your goals, the scale of the system, and available data and compute. Here's a roadmap:

---

🧠 1. Define the Problem Type

You need to determine what "programming by example" means in your context:

• Input-Output based Programming (Inductive Programming)
  Example: Given input 2, output 4 → infer: f(x) = 2x.

• Code Completion / Code Synthesis
  Given partial code, generate the rest or complete a function.

• Instruction + Example → Code
  Given a natural language prompt and examples, generate code.

---

📊 2. Gather or Create a Dataset

Depending on the approach:

a. Input-Output Pairs

• Use existing datasets like:

  • DeepFix

  • FlashFill

• Or create your own:

  • Create small programming puzzles.

  • Store multiple input-output examples for each task.

b. Code Synthesis from Examples

• Datasets like:

  • CoNaLa (NL ↔ code)

  • MBPP (input/output examples and code)

  • HumanEval (by OpenAI, includes Python functions with examples)

---

🧰 3. Choose a Model Architecture

a. Small Scale (Prototypes)

• Use tree-based models (decision trees, DSL-based solvers)

• Meta-interpretive learning (in Prolog or Python)

b. Deep Learning Based

• Transformers:

  • GPT-2, GPT-3, Codex, StarCoder, CodeT5, CodeGen (all fine-tunable for code)

• Fine-tune or use prompting on these.

---

🔧 4. Training Techniques

a. Supervised Learning

• Train on (NL + I/O examples) → Code pairs.

• Loss: Cross-entropy between predicted and target code tokens.

b. Reinforcement Learning

• Reward models that generate correct code (verified via test cases).

• Use when ground truth code is unavailable.

c. Neural Program Induction / Synthesis

• Use I/O examples to guide generation.

• Differentiable interpreters or learned embeddings of I/O pairs.

---

🛠️ 5. Tools and Frameworks

• HuggingFace Transformers – for training/fine-tuning code models

• OpenAI API – for few-shot and fine-tuned Codex-like models

• Tracr / DreamCoder / SKETCH / Prose (Microsoft) – for symbolic or hybrid approaches

---

🧪 6. Evaluation

Use test cases to verify correctness:

• Given a model-generated program, check if it passes all given input/output cases.

• Use metrics like:

  • Exact Match (EM)

  • Pass@k (e.g. if one of 5 generated solutions works)

  • BLEU / CodeBLEU (for syntactic similarity)

---

📌 Example Setup: Few-Shot Prompting with GPT-4

Task: Write a function to reverse a string.

Example 1:
Input: "hello"
Output: "olleh"

Example 2:
Input: "OpenAI"
Output: "IAnepO"

Now write a function in Python that performs this task.

→ GPT-4 generates the function based on just these examples.

---

💡 Tips

• Start simple: First focus on toy problems (e.g. string manipulations).

• Program synthesis is hard – especially when generalizing beyond seen examples.

• Use constrained languages or domain-specific languages (DSLs) for tractability.

• Hybrid approaches (symbolic + neural) are promising for scalability and correctness.

---

If you're serious about building such a system, I can help guide you through creating a prototype, designing a custom DSL, or even building a simple program-synthesis engine step-by-step. Let me know your preference.

Store all users data in their own mobile or digital twin

 Is it possible to store all users data in his or her mobile or digital twin and just let queries accessing user data run on only those data of users who choose to participate in the campaign or offer?

Yes — it’s not only possible, it’s actually the core idea behind privacy-preserving, user-centric data architectures like personal data pods, edge computing, and digital twin concepts.

Here’s how it would work in practice:

---

1. Core Concept

Instead of a central server storing everyone’s data, each user’s device (or their cloud-hosted “digital twin”) keeps their complete personal dataset.
When a business, research project, or marketing campaign wants to run a query, the query itself is sent to the user’s device or twin. The device/twin executes it locally and only returns the relevant, consented output — not the raw personal data.

---

2. Technology Enablers

• On-Device Storage & Processing

  • Secure storage on smartphones (encrypted DB like SQLite + OS-level keychain)

  • Edge processing frameworks (e.g., TensorFlow Lite, Core ML) for running ML queries locally.

• Digital Twin Hosting

  • Cloud-based replicas controlled by the user (e.g., Solid PODs, IPFS nodes)

  • User grants/revokes access tokens for specific queries.

• Privacy-Preserving Query Execution

  • Federated Learning: The query (or model) travels to the data, model updates come back without sharing raw data.

  • Secure Multiparty Computation (SMPC): Multiple users can compute a result jointly without exposing their individual data.

  • Zero-Knowledge Proofs (ZKP): User proves a statement about their data without revealing the data itself.

---

3. Example Scenario

Let’s say a supermarket wants to find “users who bought milk more than twice last month” for a discount offer.

1. User Device: Stores shopping history.

2. Campaign Query: Sent to all devices (or only opted-in users).

3. Local Execution: Device runs the query locally.

4. Return: Device returns only a “yes” or “no” flag — or even better, directly redeems the coupon locally without sending identifiable info.

Result:

• The supermarket never sees the full purchase history.

• Users who didn’t opt in are never contacted.

• The system is GDPR/DPDP-compliant by design.

---

4. Benefits

• Full User Control – Participation is opt-in at the data level.

• Lower Breach Risk – No single central repository to hack.

• Regulatory Compliance – Aligns with data minimization principles.

• Trust Building – Users know exactly what leaves their device.

---

5. Challenges

• Performance – Some queries may require heavy computation; on-device optimization is needed.

• Standardization – Need a universal query language and API format for campaigns.

• Network Efficiency – Efficient broadcasting of queries without leaking participation status.

• Business Buy-In – Companies must be willing to give up centralized data collection.

---

I could outline an architecture for such a system where:

• The data pods are on mobile or cloud twin.

• The queries are sandboxed and cryptographically signed.

• The results are anonymized or aggregated before leaving the device.

That would essentially make the whole system “privacy by design” but still commercially useful.

If you want, I can map this into a practical system design with both mobile and cloud twin options, and show how consent and query execution would flow. This would turn your idea into a clear implementation blueprint.

why don't websites provide feature to merge two accounts of users who are one and the same?

 Websites generally avoid providing a "merge two accounts" feature for a few reasons, and they’re mostly about security, data consistency, and business rules:

---

1. Security & Identity Verification

• Merging accounts means one account gets full access to the other’s data, transactions, and possibly payment methods.

• It’s hard to prove beyond doubt that both accounts belong to the same person without strong identity verification.

• If there’s a bug in the merge process or someone fakes ownership of a second account, it can lead to massive data breaches.

---

2. Data Integrity & Technical Complexity

• Different accounts may have overlapping or conflicting data:

  • Different email addresses, phone numbers, usernames.

  • Different purchase histories or subscriptions.

  • Conflicting preferences or privacy settings.

• Merging needs careful handling to avoid duplication, overwriting, or corruption of data.

---

3. Compliance & Legal Issues

• In regulated industries (banking, healthcare, government services), merging user data might break legal requirements for record-keeping.

• Some records are tied to a single immutable identity for auditing and legal traceability.

---

4. Business Considerations

• Many companies treat account signups as key growth metrics. Removing “duplicate” accounts may make user numbers look smaller.

• Support teams prefer handling merges manually after verification, rather than offering a self-service tool that could be abused.

---

5. Rare User Demand

• While the problem exists, only a small percentage of users ever request an account merge, so many companies don’t prioritize building such a feature.

• Instead, they usually suggest:

  • Deleting one account and continuing with the other.

  • Exporting/importing certain data manually (if the platform supports it).

---

If you want, I can also explain how some platforms like GitHub, Google, or Microsoft handle merges, because they actually do allow it but with strong safeguards. This way you can see why others avoid it.

BIS601 FSD - Passing props as Children in React

 Passing props as Children

In React, props.children allows you to pass nested JSX (child elements) into a component. This is great for wrapping content or creating layout components.

Using props.children

We’ll create a Card component that wraps whatever content you place inside it.

import React from 'react';

function Card(props) {

  return (

    <div style={{ border: '1px solid #ccc', padding: '1rem', borderRadius: '8px' }}>

      {props.children}

    </div>

  );

}

export default Card;

App.jsx

import React from 'react';

import Card from './Card';

function App() {

  return (

    <div style={{ padding: '2rem' }}>

      <h1>Using props.children</h1>

      

      <Card>

        <h2>This is inside the Card</h2>

        <p>Card content is passed as children.</p>

      </Card>

      

      <Card>

        <button>Click Me</button>

      </Card>

    </div>

  );

}

export default App;