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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
Relational data model
COPYRIGHT DISCLAIMER: Presentation aggregates information from multiple open-access resources. Author does not claim for copyright.
Darabase sql my sql mysql good presentationCharlie662408
"Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum."
"Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum."
"Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.""Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum." "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum."
jgjgj gjjgjn ngnnv gkgn gkjgnbn
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 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.
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 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. План
NoSQL концепції
Види NoSQL
NoSQL vs RDBMS
Реплікація
CAP теорема
Redis
MongoDB
4. NoSQL – це…
сукупність технологій баз даних, які були розроблені у
відповідь на вимоги сучасних додатків:
великі об’єми нових типів даних, що швидко
змінюються;
короткотривалі цикли розробки (1-2 тижні)
аплікації як сервіси, завжди доступні, масштабовані
для мільйонів користувачів
перевага масштабованих архітектур з використанням
відкритого ПЗ
6. NoSQL: Ключ-значення сховища
використовують асоціативні масиви (також відомі як
словники) як фундаментальну модель даних. В цій
моделі дані зберігаються як колекція пар ключ-
значення, так що кожен ключ зустрічається лише один
раз.
8. NoSQL: Документні БД
ставить у відповідність кожному ключу складну
структуру даних відому, як документ. Документ може
містити багато відмінних пар ключ-значеня, або ж ключ-
масив і навіть вкладені документи
14. NoSQL vs RDBMS
SQL NoSQL
Типи Одного типу (SQL) з
мінімальними відмінностями
Багато різних типів,
наприклад, сховища ключ-
значення, документні, графові
та інші
Модель зберігання даних Окремі записи зберігаються як
рядки в таблицях, де кожна
колонка зберігає специфічну
частину даних про даний
запис. Пов’язані дані
зберігаються в інших
таблицях, а потім
об’єднуються для виконання
складних запитів.
Варіюється в залежності від
виду бази даних. На приклад,
ключ-значення сховища
зберігають складні об’єкти як
BLOB. Документні БД
зберігають всю пов’язану
інформацію разом в одному
документі
15. NoSQL vs RDBMS
SQL NoSQL
Схема Структура та типи даних є
фіксованими. Для збереження
нових даних, вся база даних
повинна бути змінена.
Протягом цього часу база
даних є недоступною.
Переважно динамічна з
дотриманням деяких правил
валідації даних. Додатки
можуть додавати нові поля
«на льоту», і на відміну SQL
таблиць, несхожі дані при
потребі можуть зберігатись
разом.
Масштабування Вертикальне: сервер повинен
бути максимально потужним,
щоб справлятись з вимогами.
Можливо рознести SQL БД по
багатьох серверах, що є
складним технологічним
процесом.
Горизонтальне: додавання
нових серверів. Бази даних
автоматично розподіляють
дані між серверами при
потребі.
16. NoSQL vs RDBMS
SQL NoSQL
Модель розробки Поєднання відкритого ПЗ
(Postgres, MySQL та інші) з
закритим (Oracle, MSSQL та
інші)
Відкрите ПЗ (open-source)
Підтримка транзакцій Так. Зміни можуть бути
налаштовані таким чином,
щоб завершуватись разом або
ні.
При певних обставинах та на
певних рівнях.
17. NoSQL vs RDBMS
SQL NoSQL
Маніпулювання даними Використання операторів
специфічної мови: Select,
Insert, Update та інші.
Через об’єктно-орієнтовані
APIs
Узгодженість (Consistency) Можливе налаштування для
підтримки строгої
узгодженості.
Залежить від продукту. Деякі
забезпечують строгу
узгодженість, інші –
підсумкову узгодженість.
19. CAP теорема
Розподілена система може
одночасно забезпечувати
лише 2 з 3 властивостей:
- узгодженість
(consistency);
- доступність (availability);
- стійкість до розподілу
(partition tolerance)
20. Redis – REmote DIctionary Service
ключ-значення сховище;
зберігає дані в оперативній пам’яті (по замовчуванню).
21. Переваги Redis
надзвичайно швидкий;
можливість зберігати не тільки стрічки;
постійність;
реплікація;
вбудована підтримка Lua-скриптів.
28. MongoDB
Документно-орієнтована БД:
документи – аналоги ключ-значення структур у мовах
програмування (словники, хеші, мапи, асоціативні
масиви)
документи зберігаються у JSON форматі (насправді у
BSON – бінарний JSON)
всі документи зберігаються в колекціях. Колекція –
група пов’язаних документів, що мають набір спільних
індексів
35. MongoDB: Запити
- стосуються конкретної колекції документів
- вказують критерії чи умови, що
визначають документи, які поверне
MongoDB
- можуть включати проекцію, що вказує, які
поля повернути у знайдених документах