Concurrent Collections — набор коллекций, более эффективно работающие в многопоточной среде нежели стандартные универсальные коллекции из java.util пакета. Вместо базового враппера Collections.synchronizedList с блокированием доступа ко всей коллекции используются блокировки по сегментам данных или же оптимизируется работа для параллельного чтения данных по wait-free алгоритмам.
Queues — неблокирующие и блокирующие очереди с поддержкой многопоточности. Неблокирующие очереди заточены на скорость и работу без блокирования потоков. Блокирующие очереди используются, когда нужно «притормозить» потоки «Producer» или «Consumer», если не выполнены какие-либо условия, например, очередь пуста или перепонена, или же нет свободного «Consumer»'a.
Synchronizers — вспомогательные утилиты для синхронизации потоков. Представляют собой мощное оружие в «параллельных» вычислениях.
Executors — содержит в себе отличные фрейморки для создания пулов потоков, планирования работы асинхронных задач с получением результатов.
Locks — представляет собой альтернативные и более гибкие механизмы синхронизации потоков по сравнению с базовыми synchronized, wait, notify, notifyAll.
Atomics — классы с поддержкой атомарных операций над примитивами и ссылками.
CI/CD-приложений на Tarantool: от пустого репозитория — до продакшнаMail.ru Group
Константин рассказал про новый подход в структурировании и поставке приложений в Tarantool:
как управлять зависимостями (rockspec + друзья);
как писать и запускать юнит- и интеграционные тесты;
покажу превью нового тестового фреймворка для приложений;
как паковать приложения вместе с зависимостями (и почему мы выбрали статическую линковку);
как задеплоить в продакшн с systemd.
Concurrent Collections — набор коллекций, более эффективно работающие в многопоточной среде нежели стандартные универсальные коллекции из java.util пакета. Вместо базового враппера Collections.synchronizedList с блокированием доступа ко всей коллекции используются блокировки по сегментам данных или же оптимизируется работа для параллельного чтения данных по wait-free алгоритмам.
Queues — неблокирующие и блокирующие очереди с поддержкой многопоточности. Неблокирующие очереди заточены на скорость и работу без блокирования потоков. Блокирующие очереди используются, когда нужно «притормозить» потоки «Producer» или «Consumer», если не выполнены какие-либо условия, например, очередь пуста или перепонена, или же нет свободного «Consumer»'a.
Synchronizers — вспомогательные утилиты для синхронизации потоков. Представляют собой мощное оружие в «параллельных» вычислениях.
Executors — содержит в себе отличные фрейморки для создания пулов потоков, планирования работы асинхронных задач с получением результатов.
Locks — представляет собой альтернативные и более гибкие механизмы синхронизации потоков по сравнению с базовыми synchronized, wait, notify, notifyAll.
Atomics — классы с поддержкой атомарных операций над примитивами и ссылками.
CI/CD-приложений на Tarantool: от пустого репозитория — до продакшнаMail.ru Group
Константин рассказал про новый подход в структурировании и поставке приложений в Tarantool:
как управлять зависимостями (rockspec + друзья);
как писать и запускать юнит- и интеграционные тесты;
покажу превью нового тестового фреймворка для приложений;
как паковать приложения вместе с зависимостями (и почему мы выбрали статическую линковку);
как задеплоить в продакшн с systemd.
Владимир Алаев "Разработка на Node.js: инструменты, библиотеки, сервисы"Yandex
Платформа Node.js становится все более популярной. Для нее уже создано много библиотек и инструментов. Рассказ о том, какие из них и для чего мы используем.
Михаил Рахманов рассказывает о паттерне Promise и его использовании в iOS разработке.
Краткие тезисы:
- Что такое promises?
- Использование promises в iOS разработке (существующие библиотеки и подходы)
- Реализация promises библиотекой PromiseKit (основные методы, цепочки promises, обработка ошибок)
- Какие задачи можно решить с помощью promises, а какие - нельзя
- Использование promises на примере приложения: драм-машины с возможностью сохранять аудио-дорожки
- Подведение итогов: преимущества и недостатки.
RDSDataSource - внутренние пятничные митапы iOS-команды RAMBLER&Co.
Подходы и технологии, используемые в разработке iOS-клиента Viber, Кирилл Лаш...Yandex
Рассказ об основных принципах, которых придерживается Viber в длительной разработке приложения с большой кодовой базой — если разработкой занимается распределённая команда. Мы обсудим используемые технологии, библиотеки, работу с кодом и многое другое.
Внедрение Docker в процесс разработки демонов. Доклад Константина Карпова на ...Badoo Development
Рассказываем о том, как мы жили без Docker'а и зачем его решили использовать. А также описываем процесс внедрения в CI и, в частности, в тесты, плюс с какими проблемами столкнулись и как их побороли.
Docker Containers orchestrators: Kubernetes vs. SwarmDmitry Lazarenko
Обзор рынка оркестраторов Docker. Детальное технологическое сравнение Docker Swarm и Kubernetes. Обзор архитектуры и возможностей каждогого из них. Кто лучше справляется с построением масштабируемых микросервисных архитектур
Владимир Алаев "Разработка на Node.js: инструменты, библиотеки, сервисы"Yandex
Платформа Node.js становится все более популярной. Для нее уже создано много библиотек и инструментов. Рассказ о том, какие из них и для чего мы используем.
Михаил Рахманов рассказывает о паттерне Promise и его использовании в iOS разработке.
Краткие тезисы:
- Что такое promises?
- Использование promises в iOS разработке (существующие библиотеки и подходы)
- Реализация promises библиотекой PromiseKit (основные методы, цепочки promises, обработка ошибок)
- Какие задачи можно решить с помощью promises, а какие - нельзя
- Использование promises на примере приложения: драм-машины с возможностью сохранять аудио-дорожки
- Подведение итогов: преимущества и недостатки.
RDSDataSource - внутренние пятничные митапы iOS-команды RAMBLER&Co.
Подходы и технологии, используемые в разработке iOS-клиента Viber, Кирилл Лаш...Yandex
Рассказ об основных принципах, которых придерживается Viber в длительной разработке приложения с большой кодовой базой — если разработкой занимается распределённая команда. Мы обсудим используемые технологии, библиотеки, работу с кодом и многое другое.
Внедрение Docker в процесс разработки демонов. Доклад Константина Карпова на ...Badoo Development
Рассказываем о том, как мы жили без Docker'а и зачем его решили использовать. А также описываем процесс внедрения в CI и, в частности, в тесты, плюс с какими проблемами столкнулись и как их побороли.
Docker Containers orchestrators: Kubernetes vs. SwarmDmitry Lazarenko
Обзор рынка оркестраторов Docker. Детальное технологическое сравнение Docker Swarm и Kubernetes. Обзор архитектуры и возможностей каждогого из них. Кто лучше справляется с построением масштабируемых микросервисных архитектур
Модным ныне словом «виртуализация» сейчас называют различные обёртки аппаратной виртуализации, однако этот термин намного старше и более всеохватывающий. На уровне ознакомления с технологией мы поговорим о виртуализации ресурсов в кластере и на примере pacemaker.
SETCON'18 - Vitali Fokin - Kubernetes 101Nadzeya Pus
Обзор возможностей Kubernetes, зачем он нужен, кому и когда, а также немного хороших практик по развертыванию и разработке Kubernetes-powered приложений.
Осуществим вводный экскурс в Node.JS. Действительно это что-то новое и гениальное? Что оно может, а что нет? Кому будет полезен? В каких случаях применять, а в каких нет? На все эти вопросы я постараюсь ответить в своём докладе.
Презентация к докладу - работа с потоками в .net
* Основе работы с потоками
* Средства блокирующей синхронизации
* Неблокирующая синхронизация
* Асинхронная модель программирования
* Пул потоков
* Класс BackGroundWorker
* Задачи
* Модель поставщик-потребитель
* Блокировка с двойной проверкой
Управление ресурсами в Linux и OpenVZ Кирилл Колышкин kir@openvz.org http://openvz.org/
Отчет - http://yourcmc.ru/wiki/RootConf_2009:_%D0%9E%D1%82%D1%87%D1%91%D1%82_%D0%92%D0%B8%D1%82%D0%B0%D0%BB%D0%B8%D1%8F_%D0%A4%D0%B8%D0%BB%D0%B8%D0%BF%D0%BF%D0%BE%D0%B2%D0%B0#.D0.A3.D0.BF.D1.80.D0.B0.D0.B2.D0.BB.D0.B5.D0.BD.D0.B8.D0.B5_.D1.80.D0.B5.D1.81.D1.83.D1.80.D1.81.D0.B0.D0.BC.D0.B8_.D0.B2_Linux_.D0.B8_OpenVZ_.28.D0.B7.D0.B0.D1.87.D1.91.D1.82.21.29
Лабораторные работы (практикум) по операционным системам и средам. Материал разработан специально для ресурса www.studentam-in.ru на котором Вы можете найти бесплатные учебные материалы и получить качественные образовательные услуги: китайский и английский перевод; репетиторство; заказ курсовых, контрольных; создание презентации, баннера, контента, сайта и многое другое.
«История строителя: Maven - от новичка до мастера. Сборка простых и сложных Java- проектов.»
BitByte: 20 апреля 2013, Санкт-Петербург
http://bitbyte.itmozg.ru/
Инфраструктура распределенных приложений на nodejs / Станислав Гуменюк (Rambl...Ontico
Мы создаем nodejs приложения, используя различные современные технологии, такие как Docker, Consul, pm2. Современный спектр решений настолько обширен, что сложно не заблудиться. Как же выбрать нужные вашему проекту технологии, чтобы успешно его запустить и поддерживать? Будут рассказаны истории и, конечно же, даны вредные советы :)
Как на nodejs пройти путь от Hello world приложения до распределённого решения, состоящего из микросервисов?
Мы пройдём жизненный цикл продукта, начав с простого приложения на nodejs. Научимся его правильно запускать и будем постепенно добавлять элементы, убирая при этом ненужные. Так к нашему приложению присоединится гипервизор, а само оно будет разделено на части, где каждая сущность будет управлять своей частью приложения.
Построив таким образом архитектуру на чистом nodejs, мы займёмся развитием приложения, добавим современные технологии и применим новые подходы к организации инфраструктуры. Запакуем приложение в Docker, попутно обсудим, зачем он нужен и что может дать. И, наконец, решим проблему поиска запущенных сервисов и отслеживания их статусов, используя Consul.
Automated testing: Openshift on OpenstackOleg Popov
The document discusses automated testing and proposes improvements to the current workflow. It notes cons of the current approach, including a lack of full virtualization and testing things that don't need to be tested. The future workflow envisions full virtualization support, an application container catalog, intelligent testing, and declarative environments. YAML examples are provided for OpenShift pods and OpenStack resources to demonstrate connecting Windows instances to OpenShift networks.
This document discusses changes to the organization of projects in Openshift and the implementation of Jenkins pipelines for continuous integration and delivery.
For Openshift projects, a new product-based approach is proposed with fewer total projects that are named based on the product, environment, and attributes. This is compared to the old component-based approach with more projects.
For Jenkins pipelines, a new approach is proposed with a base pipeline to build Docker images and a product pipeline with build and test stages. This is compared to the old approach with multiple separate jobs instead of a unified pipeline. Examples of the new base and product pipelines are provided.
This document provides an overview of IoT (Internet of Things) including definitions of key terms like IoT, IoT platform, and IoT gateway. It also discusses IoT standards and protocols, examples of IoT deployments in different countries, popular IoT solutions from companies like AWS and Microsoft, IoT security solutions, and examples of IoT hacks that have occurred.
The document discusses automated testing inside Openshift including the contour of automated testing, dynamic configurations of Openshift, and integration with TestLink. It outlines pros and cons of automated testing using lightweight containers across a variety of operating systems. It describes how to dynamically configure tests by variables like project, branch, product name and version, and OS. It also covers how to create, execute, verify and delete configurations as well as generate reports and artifacts from test runs. Finally, it discusses integrating test results with TestLink for reporting.
The document discusses options for testing software including manual testing with Vagrant and Robot Framework as well as automated testing. It recommends using OpenShift for automated testing as it provides a reliable solution with Kubernetes that is scalable and controllable while Docker provides speed and high density. Open vSwitch enables network connectivity in OpenShift. Workflow and reference details are also included.
3. 3
Компоненты Openshift
1. Openshift Master – рабочий узел, которые содержит основные компоненты управления
кластером (API, etcd, controller manger server)
4. 4
Компоненты Openshift
1. Openshift Master – рабочий узел, которые содержит основные компоненты управления
кластером (API, etcd, controller manger server)
2. Openshift Node – рабочий узел, на котором происходит непосредственный запуск
контейнеров
5. 5
Компоненты Openshift
1. Openshift Master – рабочий узел, которые содержит основные компоненты управления
кластером (API, etcd, controller manger server)
2. Openshift Node – рабочий узел, на котором происходит непосредственный запуск
контейнеров
3. Kuryr Controller – демон (может быть запущен где угодно), который отслеживает
запросы на создание контейнера через Openshift API, создает сетевые порты в
виртуальной сети Neutron, добавляет сетевые метаданные к конфигурации контейнера
6. 6
Компоненты Openshift
1. Openshift Master – рабочий узел, которые содержит основные компоненты управления
кластером (API, etcd, controller manger server)
2. Openshift Node – рабочий узел, на котором происходит непосредственный запуск
контейнеров
3. Kuryr Controller – демон (может быть запущен где угодно), который отслеживает
запросы на создание контейнера через Openshift API, создает сетевые порты в
виртуальной сети Neutron, добавляет сетевые метаданные к конфигурации контейнера
4. Kuryr CNI – демон (работает непосредственно на рабочем узле), который
отслеживает запросы на создание контейнера через Openshift API, подключает
контейнер к виртуальной сети Neutron на основе метаданных указанных в конфигурации
контейнера
7. 7
Компоненты Openshift
1. Openshift Master – рабочий узел, которые содержит основные компоненты управления кластером
(API, etcd, controller manger server)
2. Openshift Node – рабочий узел, на котором происходит непосредственный запуск контейнеров
3. Kuryr Controller – демон (может быть запущен где угодно), который отслеживает запросы на
создание контейнера через Openshift API, создает сетевые порты в виртуальной сети Neutron,
добавляет сетевые метаданные к конфигурации контейнера
4. Kuryr CNI – демон (работает непосредственно на рабочем узле), который отслеживает
запросы на создание контейнера через Openshift API, подключает контейнер к виртуальной сети
Neutron на основе метаданных указанных в конфигурации контейнера
5. Neutron LBaaS – сетевой балансировщик Neutron (HAProxy), прослушивает заданный порт и
проксирует трафик на заданный IP-адрес