Дмитрий Грошев, Фёдор Гоголев. Erlang и Haskell в production: проблемы и решенияFProg
В докладе рассматривается мотивация и опыт перехода процесса разработки API с большим количеством внутренней логики с Python на сочетание Erlang и Haskell, проблемы в процессе разработки и способы их решения.
Евгений Лазин. Неизменяемая структура данных HAMT для создания БД в памятиFProg
В данном докладе рассматривается пример использования персистентной структуры данных - функциональной версии HAMT, для создания main memory базы данных. Данная реализация HAMT располагается в shared memory и используется для хранения индексов.
Рассматриваются задачи, которые были быстро и эффективно решены благодаря использованию неизменяемых структур данных (управление изменениями, поддержка ACID-свойств), а также проблемы, возникшие из-за этого. Также, рассмотрен метод реализации персистентного графа, использующий изменяемые данные и позволяющий достичь большей производительности, по сравнению с аналогичной, неизменяемой структурой данных.
Дмитрий Грошев, Фёдор Гоголев. Erlang и Haskell в production: проблемы и решенияFProg
В докладе рассматривается мотивация и опыт перехода процесса разработки API с большим количеством внутренней логики с Python на сочетание Erlang и Haskell, проблемы в процессе разработки и способы их решения.
Евгений Лазин. Неизменяемая структура данных HAMT для создания БД в памятиFProg
В данном докладе рассматривается пример использования персистентной структуры данных - функциональной версии HAMT, для создания main memory базы данных. Данная реализация HAMT располагается в shared memory и используется для хранения индексов.
Рассматриваются задачи, которые были быстро и эффективно решены благодаря использованию неизменяемых структур данных (управление изменениями, поддержка ACID-свойств), а также проблемы, возникшие из-за этого. Также, рассмотрен метод реализации персистентного графа, использующий изменяемые данные и позволяющий достичь большей производительности, по сравнению с аналогичной, неизменяемой структурой данных.
С точки зрения программиста Agda представляет собой язык с зависимой системой типов и Haskellеподобным синтаксисом. С точки зрения математика — это система проверки доказательств, отдающая предпочтение прямому манипулированию proof-термами, а не тактикам. Доклад рассматривает основные особенности и идиомы системы Agda на примерах, широко используемых в дискретной математике.
От слушателя ожидаются базовые знания функционального программирования и дискретной математики на уровне первого курса университета, хотя бы поверхностное знакомство с зависимыми типами.
Евгений Котельников. Зависимые типы в HaskellFProg
Системы зависимых типов позволяют оперировать данными на уровне типов, что может значительно повысить точность спецификации программ. Несмотря на отсутствие поддержки самих зависимых типов в Haskell, некоторые их свойства могут быть реализованы с помощью расширений языка. Будет представлен ряд техник, приближающий Haskell к возможностям языков вроде Agda, Coq и Epigram. Доклад имеет вводный характер и не требует предварительных знаний в обсуждаемых в нём темах.
Study: The Future of VR, AR and Self-Driving CarsLinkedIn
We asked LinkedIn members worldwide about their levels of interest in the latest wave of technology: whether they’re using wearables, and whether they intend to buy self-driving cars and VR headsets as they become available. We asked them too about their attitudes to technology and to the growing role of Artificial Intelligence (AI) in the devices that they use. The answers were fascinating – and in many cases, surprising.
This SlideShare explores the full results of this study, including detailed market-by-market breakdowns of intention levels for each technology – and how attitudes change with age, location and seniority level. If you’re marketing a tech brand – or planning to use VR and wearables to reach a professional audience – then these are insights you won’t want to miss.
Tech Talks @NSU: Организация тестирования в IT-компаниях Академгородка. Карье...Tech Talks @NSU
http://techtalks.nsu.ru
5 апреля 2012. Организация тестирования в IT-компаниях Академгородка. Карьерный путь тестировщика (Мария Колчинская, AcademSoft)
«Мария Колчинская (AcademSoft) рассказывает о процессах тестирования и карьере тестировщика»
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
Test Strategy: creation and optimization - QA Fest-2017 (Тестовая стратегия: ...Andrey Ladutko
Тест-менеджер ставит перед собой и командой долгосрочные и сложные цели. Например, как выбрать и соединить вместе изученные техники и виды тестирования, как понять, почему в одних условиях у нас получилось провести “качественное” тестирование, а в других нет? Как понять, будет ли эффективна автоматизация на проекте прежде, чем вложиться человека-годами в Фреймворк и тесты? Ответы на эти вопросы находятся в «стратегии тестирования». Она есть у каждой команды, пусть и не в осознанном и формализованном виде. Поэтому нужно научиться пользоваться этим инструментом, уметь как составлять тестовую стратегию с нуля на проекте, так и оптимизировать уже существующую стратегию.
QA Fest 2017. Андрей Ладутько.Тестовая стратегия: создание и оптимизацияQAFest
Тест-менеджер ставит перед собой и командой долгосрочные и сложные цели. Например, как выбрать и соединить вместе изученные техники и виды тестирования, как понять, почему в одних условиях у нас получилось провести “качественное” тестирование, а в других нет? Как понять, будет ли эффективна автоматизация на проекте прежде, чем вложиться человека-годами в Фреймворк и тесты? Ответы на эти вопросы находятся в «стратегии тестирования». Она есть у каждой команды, пусть и не в осознанном и формализованном виде. Поэтому нужно научиться пользоваться этим инструментом, уметь как составлять тестовую стратегию с нуля на проекте, так и оптимизировать уже существующую стратегию.
Презентация на комплексную тему Continious integration-Automated Testing-Agile, показывается связи между этими темам, обоснование автоматического тестирования , и вложения ресурсов для развертывания автоматического тестирования и непрерываной интеграциия. Все темы тесно связаны между собой , хотя бы появились независимос друг от друга.
2. Отдел тестирования 1. Формирование и развитие профессионального центра компетенции по тестированию. 2. Более гибкое управление группами тестировщиков по проектам или продуктам.
3. Что было 3-4 проекта ― 1 тестировщик: Страдает качество; Страдает проект; Нужно довольно много времени, чтобы перестраиваться с одного проекта на другой; Страдает планирование работы тестировщика;
4. Как будет Четкое планирование работы тестировщика на проекте по времени. Например, 1 проект несложный, кратковременный, а второй только в стадии планирования, разработки, когда тестировщику приходится тратить немного времени на написание тест-кейсов, на тестирование каких-либо небольших разрозненных функциональностей. Погружение в работу Осведомленность о мелочах проекта Возможность приглашения тестировщика с другого проекта для помощи или освежения взгляда на продукт
5. Обучение Непрекращающееся обучение: самообучение, чтение книг/статей; участие в конференциях; проведение тренингов внутри отдела; делиться полученными знаниями/опытом с коллегами; «Прочитал статью/книгу, дай ссылку коллеге, сделай доклад/презентацию» Участие в online-конференциях всем отделом ― просмотр докладов через проектор. Повышение компетенции в областях разрабатываемых продуктов (мобильные приложения, трейдинговые приложения).
6. Анализ проблем Постоянный анализ проблем, возникающих при работе (ошибки, непонимание и т. д.); Изучение фидбека от заказчика, пользователей (в зависимости от проекта).
7. Bug tracking system Введение шаблонов описания ошибок: поиск; исключение дублирования. Введение обязательных полей для заполнения. Изменение приоритета/важности/статуса только с обоснованием. И т.д.
11. Метрики Цель контроля - обратная связь и визуализация процесса тестирования. Вручную и автоматически. Оценка: покрытия (например, покрытие требований или кода тестами) критериев выхода (например, критерии окончания тестирования) прогресса выполнения запланированных работ Примеры метрик : Метрики по тестовым случаям (Test Cases) Метрики по багам Метрики по задачам
12. Метрики По багам: Open/Closed Bugs - отношение количества открытых багов к закрытым (исправленным и перепроверенным) Feedback/Closed Bugs -отношение количества возвращеных багов к закрытым (исправленным и перепроверенным) Метрики "Open/Closed Bugs", "Bugs by Severity" и "Bugs by Priority" визуализируют степень приближения продукта к достижению критериев качества по багам. Метрики "Feedback/Closed Bugs" и "Rejected/Opened Bugs" направлены на отслеживание работы отдельных участников групп разработки и тестирования. Пример: Количество переоткрываемых после починки багов не уменьшается или даже растет. Это сигнал к тому, что необходимо провести анализ причин, т.к. подобная ситуация может показать, что: Требования к функции можно трактовать по разному Тестировщик не точно описал проблему Некачественное поверхностное решение проблемы (фикс бага)
13. Версионность, формализация На тестирование принимается замороженая версия продукта. Формализация (Функционал: проверка задач/тестирование функционала -> исправление ошибок -> проверка исправлений -> ... -> конфигурационнное тестирование/интеграционанное тестирование и т. д. … -> регресс) VS «Разработчик сказал посмотреть здесь, я посмотрел и сказал, что все хорошо» и забыли. Регистрация всех найденых багов в баг-трекере, даже если используется гибкая методология разработки.
14. Тестовый сервер Отдельный тестовый сервер: проведение ночных автотестов конфигурационное тестирование (разные ОС, браузеры, эмуляторы) оценка возможности и рентабельности введения.