The document discusses the roles and responsibilities of a project manager in software development. It covers the software development lifecycle (SDLC), common methodologies like SCRUM, and the differences between projects and products. It also describes the typical project team roles and the key duties and qualities of an effective project manager, such as planning, organizing, leading, controlling, clear communication, managing expectations, and prioritizing the team over oneself.
Integration tests test multiple components together by using dependencies like databases, services, and APIs. They are useful for testing typical workflows and ensuring components interact smoothly but can be hard to write, maintain, and localize errors. UI tests with Selenium automate interactions with a web application like users do in order to detect errors not found by other test types, but take more time and setup compared to unit tests.
This document discusses improving proto types when using them in collections for RPC applications. It recommends adding an empty message type for void parameters and repeatable types for data collections. Sample code shows defining request/response messages for getting a user by name including a repeated field for the user collection. The server code returns the collection while the client code iterates over it. Implementing an online shop sample is suggested along with using the template method pattern for server internal logic. The document recommends a design patterns book and thanks the reader.
This document provides an overview of software quality assurance and testing. It defines quality as meeting specifications and customer expectations. Software testing investigates quality by providing stakeholders information. Testing is important to prevent defects, as shown by examples of bugs that caused spacecraft and airplane failures costing lives and money. Quality assurance focuses on preventing defects through planning and verification, while quality control identifies defects through action and validation. Defects can be costly so issue tracking systems are used to manage bug lifecycles. Manual testing is time-consuming and relies on human resources while automation testing is faster, more reliable and programmable.
The document discusses different MV* software design patterns - MVC, MVP, and MVVM. It explains the basic structure of each pattern, including how the view, controller/presenter, and model components interact. It provides examples of each pattern, including links to sample applications. The key benefits of these patterns are also summarized, such as separation of concerns, easier testing, and independence of the UI from business logic.
This document discusses best practices for writing clean, readable code. It covers topics like code layout, naming conventions, documentation, code smells, and code reviews. Specifically, it recommends:
- Consistent indentation and ordering for clean layout
- Meaningful naming styles like PascalCase to enhance readability
- Comments to explain difficult code or describe design decisions
- Addressing code smells like long methods or classes that could make code harder to maintain
- Conducting code reviews to improve quality and catch potential bugs
This document discusses design patterns, which are general and reusable solutions to common problems in software design. It covers three categories of design patterns: creational patterns, structural patterns, and behavioral patterns. The document also lists some common antipatterns to avoid, such as singleton patterns, spaghetti code, and magic numbers. It recommends some online resources for learning more about design patterns with examples and explanations of when to use specific patterns.
This document discusses code quality tools and metrics. It defines technical debt and introduces various metrics like cyclomatic complexity and Chidamber & Kemerer object-oriented metrics to measure code quality. It also discusses tools like SonarQube and SonarLint that can analyze code and provide metrics and reports on code quality, complexity, technical debt and more. SonarQube allows centralizing these metrics and provides different views like code coverage, issues and files. It also features quality gates.
The document provides an overview of communication capabilities in Android, including networking, useful networking libraries, Bluetooth, and Near Field Communication (NFC). It discusses how to connect to networks, perform network operations on a separate thread, check network connectivity, download data using HTTPURLConnection, and efficiently manage network usage. Libraries covered include Retrofit, okHTTP, Volley, and RoboSpice. The document also provides examples of discovering Bluetooth devices, connecting to Bluetooth devices, and implementing Bluetooth profiles. It concludes with a brief description of NFC technology.
This document provides an overview of best practices for Android Wear development. It discusses how to pair Wear devices, common APIs with Android, showing notifications, distributing Wear apps, defining layouts, accessing views, useful libraries like Gson and EventBus, and other tips.
The document summarizes the SOLID principles of object-oriented design, including the Single Responsibility Principle, Open/Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, and Dependency Inversion Principle. It also discusses Inversion of Control and Dependency Injection, explaining how following these principles helps make software more reusable, extensible, replaceable, loosely coupled, cohesive, and testable. The document provides definitions and examples for each principle and design pattern.
The document discusses the advantages and disadvantages of N-tier architecture. The key advantages are scalability, security, maintainability, reusability, extensibility, and fault tolerance. Scalability allows individual tiers to scale independently. Security places more secure tiers behind firewalls. Maintainability allows individual tiers to upgrade without affecting others. Reusability makes components reusable across applications. Extensibility easily allows adding new features. Fault tolerance keeps applications running if servers fail. However, performance may be slower if hardware and bandwidth are insufficient, and it has higher costs for more required hardware and maintenance.
The document discusses different MV* software design patterns - MVC, MVP, and MVVM. It explains the basic structure of each pattern, including how the view, controller/presenter, and model components interact. It provides examples of each pattern, including links to sample applications. The key benefits of these patterns are also summarized, such as separation of concerns, easier testing, and independence of the UI from business logic.
This document discusses best practices for writing clean, readable code. It covers topics like code layout, naming conventions, documentation, code smells, and code reviews. Specifically, it recommends:
- Consistent indentation and ordering for clean layout
- Meaningful naming styles like PascalCase to enhance readability
- Comments to explain difficult code or describe design decisions
- Addressing code smells like long methods or classes that could make code harder to maintain
- Conducting code reviews to improve quality and catch potential bugs
This document discusses design patterns, which are general and reusable solutions to common problems in software design. It covers three categories of design patterns: creational patterns, structural patterns, and behavioral patterns. The document also lists some common antipatterns to avoid, such as singleton patterns, spaghetti code, and magic numbers. It recommends some online resources for learning more about design patterns with examples and explanations of when to use specific patterns.
This document discusses code quality tools and metrics. It defines technical debt and introduces various metrics like cyclomatic complexity and Chidamber & Kemerer object-oriented metrics to measure code quality. It also discusses tools like SonarQube and SonarLint that can analyze code and provide metrics and reports on code quality, complexity, technical debt and more. SonarQube allows centralizing these metrics and provides different views like code coverage, issues and files. It also features quality gates.
The document provides an overview of communication capabilities in Android, including networking, useful networking libraries, Bluetooth, and Near Field Communication (NFC). It discusses how to connect to networks, perform network operations on a separate thread, check network connectivity, download data using HTTPURLConnection, and efficiently manage network usage. Libraries covered include Retrofit, okHTTP, Volley, and RoboSpice. The document also provides examples of discovering Bluetooth devices, connecting to Bluetooth devices, and implementing Bluetooth profiles. It concludes with a brief description of NFC technology.
This document provides an overview of best practices for Android Wear development. It discusses how to pair Wear devices, common APIs with Android, showing notifications, distributing Wear apps, defining layouts, accessing views, useful libraries like Gson and EventBus, and other tips.
The document summarizes the SOLID principles of object-oriented design, including the Single Responsibility Principle, Open/Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, and Dependency Inversion Principle. It also discusses Inversion of Control and Dependency Injection, explaining how following these principles helps make software more reusable, extensible, replaceable, loosely coupled, cohesive, and testable. The document provides definitions and examples for each principle and design pattern.
The document discusses the advantages and disadvantages of N-tier architecture. The key advantages are scalability, security, maintainability, reusability, extensibility, and fault tolerance. Scalability allows individual tiers to scale independently. Security places more secure tiers behind firewalls. Maintainability allows individual tiers to upgrade without affecting others. Reusability makes components reusable across applications. Extensibility easily allows adding new features. Fault tolerance keeps applications running if servers fail. However, performance may be slower if hardware and bandwidth are insufficient, and it has higher costs for more required hardware and maintenance.
"How to craft your AI bot using PHP. Step by step guide", Maksym MovaFwdays
In this topic, we will go through the step by step guide how to build an AI application using PHP and large language models. We will understand how your bot can respond like ChatGPT and manage your private data without training or extensive expertise in Data Science. We will also review existing libraries and how these approaches can be utilized in your applications.
The document provides an overview of Android application development fundamentals including application components, intents, manifest files, and more. It discusses that Android apps are written in Java and compiled to APK files. The core application components are activities, services, broadcast receivers, and content providers. Intents are used to start components and broadcast receivers register to receive system or app events. Every app must declare its components in the Android manifest.
The document discusses Android location and sensor APIs. It provides an overview of location services in Android, which allows apps to access location through the LocationManager. It also discusses the sensors framework, which gives access to motion, position, and environment sensors. It describes how to identify available sensors, register listeners to receive sensor events, and handle the sensor data. Key classes like SensorManager, Sensor, and SensorEventListener are also summarized.
This document provides an introduction to the Java programming language. It discusses the goals of Java, including being cross-platform, providing security through sandboxing with the Java Virtual Machine, and replacing C/C++. It explains what is needed to run and develop Java applications and the differences between Java editions. The document outlines some key differences between Java and C#/C++ and how to write a basic Java application. It also defines JAR files and provides principles for designing class structures in Java.
This document provides instructions for creating a gRPC Hello World sample in C# using .NET Core. It describes creating client and server projects with protobuf definition files. The server project implements a Greeter service that returns a greeting message. The client project calls the SayHello method to get a response from the server. Running the projects demonstrates a basic gRPC communication.
DevOps is a culture and practice that aims to rapidly build, test, and release software. Continuous integration requires developers to integrate code into a shared repository multiple times a day, with each check-in verified by automated builds to detect problems early. Continuous delivery is the practice of releasing every good build to users. Popular tools for continuous integration include TeamCity, Jenkins, and others.
The document discusses the role of a user experience designer, outlining their design process which includes discovering user requirements, creating design concepts and prototypes, validating designs through research and testing, and iterating on their work through collaboration and learning. It emphasizes the importance of an iterative design process driven by user needs.
The document discusses the role of a business analyst in a software project. It explains that a business analyst is involved in requirements gathering and representation. This includes eliciting requirements through preliminary discussions with customers, reviewing requirements with other roles like architects and UX designers, and specifying requirements. Requirements can be represented through user stories, use cases, documents, and other methods. User stories are written from the perspective of users and define what they want to do. Use cases outline interactions between actors and a system. Together, clearly documented requirements help ensure a project delivers business value through the right software solution.
This document discusses documentation in software development and architecture. It provides an overview of different types of diagrams used for documentation, including structure diagrams like class and component diagrams, behavior diagrams like activity and state machine diagrams, and interaction diagrams like sequence and communication diagrams. The document also discusses challenges with documentation, including that UML can be too technical or not technical enough, as well as strategies for documentation like self-documenting code, XML documentation, and naming conventions. Finally, it presents some popular tools for documentation like Visio, Draw.io, Gliffy, and Sparx Enterprise Architect.
2. Job placement criteria: Evaluate
students code
• Project code convention;
• Follows best practices in code writing;
• Follows OOD principles (SOLID, design patterns, IoC
Container);
• Able to resolve issues in the most optimal and logical way;
3. Job placement criteria: Evaluate
students attitude and responsibilities
• Using tools by established rules (git, trello, IDE);
• Timely homework/tasks execution;
• lectures attendance;
• activity on the lectures (participate in discussions, respond to the
lecturer’s questions, asks questions etc.);
• Teamwork (shares information with team members, performs
assigned duties, participate in proj discussions, avoids conflicts etc.);
4. Job placement criteria: Evaluate
course projects
• Code Quality;
• Solution structure and architecture;
• Compliance with original requirements;
• Able to resolve issues in the most optimal and logical way;
• Extra features;
5. Project requirements
General
- Парсер повідомлення перед відправкою. Коли користувач відправляє повідомлення з
певними командами – ця команда повинна бути оброблена на сервері і змінене
повідомлення повинне прийти іншому користувачу. Оригінальне і нова повідомлення
повинне бути збережене. Нове – показане користувачу.
Architecture
- Apply Inversion of Control container.
- Implement MVPMVC.
- General project architecture + refactoring. Separate logic by layers, etc.
- Separate DAL
Documentation
- Architecture diagrams
- XML documentation to public methods
Testing
- Cover calculation logic with unit tests. (Coverage more than 30%)
6. Message Parser
Підтримка URL
- Якщо повідомлення містить url – програма повинна зробити запит за адресою, отримати
header сторінки і замісnь url в оригінальному повідомленні вставити <a
href=“url”>Caption</a>
Підтримка Email
- Якщо повідомлення містить email адресу – програма повинна поміняти адресу на тег <a
href=“mailto:emailAddress”>emailAddress</a>
Підтримка математичних операцій
- Якщо повідомлення містить =math(<operation>) – повинна порахувати вираз в дужках і
вставити його замість вхідного тексту. Приклад =math(2+2*2) повинно бути ставлено число
6.
7. Bot
Реалізувати бот-користувача який буде автоматично відповідати на повідомлення.
Підтримуванні команди:
v 1.0
Help – повертається повідомлення зі списком доступних команд
=math() – повертається повідомлення з результатом операції
=parse(urlemail) - повертається повідомлення у форматі який буде бачити користувач
отримувач.
Якщо писати будь який інший текст боту – він повинен відповідати, що ‘не знає як правильно
відповісти’
8. Bot 2.0
• Якщо користувач пише повідомлення якого не знає бот – бот повинен відповідати будь яку
випадкову фразу. (список фраз має міститись в конфігураційному файлі)
• Якщо користувач пише просто математичний вираз без команди =math() – цей вираз
повинен бути опрацьований і число має бути показане.
• Підтримка команди What is …
Якщо користувач присилає повідомлення боту What is c# delegates - ‘бот’ повинен надіслати в
googlewiki повідомлення з тестом ‘C# Delegates’ для пошуку і за знайдемим посиланням
вичитати інформацію. Повернути користувачеві перших 2 абзаци тексту і знизу посилання на
джерело. (можливо повернути певну кількість обмежених символів, або просто перші 2
речення)
• Кешувати відповіді по What is.. – якщо відповідь уже є в кеші, то не робити запити в
інтернет, а результат повертати з кешу.