Всем привет, я руководитель отдела тестирования, и недавно по работе появилась задача на тестирование API. Для ее решения освоил новый для меня инструмент Postman и JavaScript.

Первоначально на каждый API я писал свои коллекции и готовил тестовые данные в JSON формате. Это достаточно удобно, но при большом количестве тестов и коллекций поддерживать это становится накладно. Да и проводить валидацию данных в JSON не удобно.

Для решения этих проблем я написал макрос для Excel и коллекцию в Postman. Теперь в Postman у меня одна коллекция на все API и стандартный набор функций для обработки входящих данных и валидации возвращаемых результатов. Мне удалось перенести управление тестовыми данными и последовательность выполнения запросов в Excel.

Что было

1. JSON с данными


Раньше тестовый набор хранился в таком виде

Из документации Google's Engineering Practices

В этом руководстве приведены рекомендации по оптимальному проведению код-ревью, основанные на многолетнем опыте. Все вместе они составляют один документ, разбитый на множество разделов. Необязательно читать их все, но часто для себя и команды лучше изучить руководство полностью.

• Стандарт код-ревью
  
• Что проверять в коде
  
• Навигация по списку изменений (CL)
  
• Скорость код-ревью
  
• Как писать комментарии
  
• Как преодолевать сопротивление

См. также Руководство автора CL, в котором даются подробные советы разработчикам, чьи коммиты проходят ревью.

 В 19:00 начинаем трансляцию Дня СТО в Санкт-Петербурге.



 Что мы планировали?

Даниил Подольский, руководитель разработки в MTGroup, расскажет про выгорание айтишников, которое чревато потерей самых вовлеченных и ключевых сотрудников.

Кирилл Малеванов, технический директор Selectel, расскажет про инфраструктуру глазами провайдера.

Иван Михеев, Deputy CTO в AGIMA, покажет кейсы из своей практики: «Как потерять 3 руководителя и понять, что без них может быть лучше» и т. д.

Денис Ильиных, технический директор GT-Shop, расскажет про задачи техдира, решением которых занят.

Основной задачей проекта является мониторинг температуры в теплице удаленной от дома на 11-15 метров. Без возможности организации прокладки UTP и питания до нее.

Дети, рожденные в год подписания Agile Manifesto, в этом году празднуют совершеннолетие. А взрослые люди продолжают спорить, где Agile применим. Обычно бьют по площадям: можно ли использовать Agile вне IT. Иногда добавляют драмы: пробовали ли вы строить атомную электростанцию по Agile? Для художественного эффекта так, конечно, лучше. Но если вы хотите сделать продукт, а не победить в конкурсе ораторов, то лучше смотреть применительно к конкретной ситуации.

В этой статье мы расскажем о нескольких моделях оценки применимости Agile и подробнее остановимся на одной их них — Agile Suitability Model, представленной в Agile Practice Guide от PMI и Agile Alliance.

Если вы озаботитесь хотя бы некоторыми полезными вещами:

а. базовой дисциплиной
б. формированием оговоренных процессов взаимодействия друг с другом и смежниками
в. объяснением, чем и как занимаются смежники
г. гибкостью в управлению процессами
д. своевременным реагированием на возникающие проблемы

то они улучшат рабочий климат в команде разработке.

В прошлом на Хабре публиковалась статья "Orchid CMS — ещё одна CMS на Laravel", а теперь спустя два года и больше 100 релизов попробуем разобрать ошибки и проблемы которые стояли на пути разработки.

В общем случае с помощью shell команды можно получить любую метрику, без написания кода и интеграций. А значит в консоли должен быть простой и удобный инструмент для визуализации.

Наблюдение за изменением состояния в базе данных, мониторинг размера очередей, телеметрия с удаленных серверов, запуск деплой скриптов и получение нотификации по завершению — конфигурируется за минуту простым YAML файлом.

Код доступен на гитхабе. Инструкции по установке — для Linux, macOS и (экспериментально) Windows.

Некоторое время назад передо мной встал выбор инструмента для управления небольшими проектами по SCRUM-методологии. У меня был довольно большой опыт использования различных инструментов включая Jira, Asana, Trello и проч., но ни один из них не подходил в полной мере для моего проекта: какой-то был чересчур монструозен, а какому-то недоставало важных для меня фич. В итоге пришлось изобретать инструмент самому, на базе Google Sheets.


Требования, предъявляемые мною к инструменту, были таковы:

Данный пост написан по заявкам трудящихся, которые с завидной периодичностью спрашивают о том "Как запустить Illuminate / Symfony / MyOwnPsr7 приложение в докере". Давать ссылку на ранее написанный пост уже не хочется, так как взгляды относительно того, как следует решать поставленную задачу, довольно сильно изменились.

Всё, что будет написано ниже, является субъективным опытом, который (как и всегда) не претендует на право считаться единственно верным решением, но некоторые подходы и решения, возможно, тебе покажутся интересными и полезными.

В качестве приложения так же буду использовать Laravel, так как он мне наиболее знаком и довольно широко распространен. Адаптировать под другие PSR-7-based фреймворки/компоненты возможно, но этот рассказ не про это.

Тимлид – это снежинка. При детальном рассмотрении в каждой компании тимлид принимает разную форму. Где-то от него ждут только передвижения задач по доске, где-то – наймов и увольнений, а где-то просят одновременно проектировать архитектуру, ставить бизнес-цели и думать о болях пользователей продукта. На самом деле все обстоит еще сложнее. Различия встречаются не только между разными компаниями, но и даже в рамках команд, находящихся в одном офисе.

Это становится особенно заметно, когда компания сталкивается с одним из следующих вопросов: как собеседовать тимлида, как оценивать его работу, как составить ему план развития. Тимлиды тоже довольно много фрустрируют – они не понимают, насколько их текущий опыт работы останется релевантным при переходе в новую компанию, какие пробелы в знаниях и навыках существуют и как их можно заполнить. Короче говоря, куда не посмотришь, везде с тимлидами как-то сложно.

С этой проблемой столкнулись и мы со Стасом Цыгановым. Но в этот раз вместо того, чтобы обойтись простым решением текущих проблем, мы захотели подойти к вопросу фундаментальнее, собрать информацию об ожиданиях от тимлидов в разных компаниях и обобщить ее в единую общую модель. И, кажется, у нас получилось.

Вредные советы для Go-программиста



В первой части публикации я объяснил, как стать «злобным» программистом Go. Зло приходит во многих формах, но в программировании оно заключается в намеренном затруднении понимания и поддержки кода. «Злые» программы игнорируют основные средства языка в пользу техник, которые обеспечивают краткосрочные выгоды, в обмен на долгосрочные проблемы. В качестве краткого напоминания, злые «практики» Go включают в себя:

• Плохо названные и организованные пакеты
• Неправильно организованные интерфейсы
• Передача указателей на переменные в функции для заполнения их значений
• Использование паники вместо ошибок
• Использование init-функций и пустого импорта для настройки зависимостей
• Загрузка файлов конфигурации с использованием init-функций
• Использование фреймворков вместо библиотек

Большой клубок зла

Что будет, если собрать все наши злые практики вместе? У нас получился бы фреймворк, который использовала бы множество файлов конфигурации, заполнял поля структур с помощью указателей, определял интерфейсы для описания публикуемых типов, опирался на «магический» код и паниковала всякий раз, когда возникала проблема.

И я сделал такой. Если вы зайдете на https://github.com/evil-go, вы увидите Fall (падение), — DI фреймворк, дающий возможность внедрять любые «злые» практики, которые только захотите. Я спаял Fall с крошечным веб-фреймворком Outboy, который следует тем же принципам.

Вы можете спросить, насколько они злодейские? Давайте посмотрим. Предлагаю пройтись по простой программе Go (написанной с использованием лучших практик), которая предоставляет http endpoint. А затем перепишем ее, используя Fall и Outboy.

Эта статья — краткое руководство для тех, кто хочет запустить свой собственный подкаст. Когда я вместе с моим нынешним соведущим год назад запускал подкаст “В бесконечность и далее”, я не смог найти ни одной по-настоящему всеобъемлющей статьи. Поэтому я решил попытаться заполнить этот пробел и написать руководство для себя из прошлого.

Немного о структуре — это руководство содержит 4 статьи:

1. Общая философия
   1.1. Зачем делать подкаст?
   1.2. Целевая аудитория
   1.3. Выбор жанра
   1.4. Формат
2. Технический базис
   2.1. Что такое подкаст с технической точки зрения
   2.2. Аудио-формат
   2.3. Про динамики, наушники и ламповый звук
   2.4. Про тихое помещение
3. Делаем покупки
   3.1. Покупаем микрофон
   3.2. Выбираем аудиоредактор
   3.3. Выбираем программу для записи звука
   3.4. Выбираем хостинг подкаста
   3.5. Сайт-визитка
4. Записываем и выпускаем
   4.1. Запись выпуска
   4.2. Редактирование выпуска
   4.3. Про джинглы и звуковые схемы
   4.4. Про фоновый шум
   4.5. Про фильтры
   4.6. Про Show Notes, а также про то, зачем слушать свой подкаст
   4.7. Публикация подкаста
   4.8. Монетизация
   4.9. Темы, которые есть, но о которых мы не говорили

Каждый раздел статьи содержит три блока

• Суть раздела — основная мысль, изложенная тезисно
• Детальное описание “что, зачем и почему”. Обычно — много букв, которые поясняют основную мысль, и находятся они в скрытой секции “Дополнительная информация”
• Ответ, который нашли мы

Интересно — читайте все. Нет времени — читайте первый и последний абзац.

1. Общая философия

1.1. Зачем делать подкаст?

Ответ может быть любым, но только не “потом посмотрим”, ”ещё не думал” или “не знаю”. Если ответа нет, весьма высока вероятность что

Вредные советы для Go-программиста

После десятилетий программирования на Java, последние несколько лет я в основном работал на Go. Работать с Go — здорово, прежде всего потому, что за кодом очень легко следовать. Java упростила модель программирования C ++, удалив множественное наследование, ручное управление памятью и перегрузку операторов. Go делает то же самое, продолжая двигаться к простому и понятному стилю программирования, полностью удаляя наследование и перегрузку функций. Простой код — читаемый код, а читаемый код — поддерживаемый код. И это здорово для компании и моих сотрудников.

Как и во всех культурах, у разработки программного обеспечения есть свои легенды, истории, которые пересказываются у кулера для воды. Все мы слышали о разработчиках, которые вместо того, чтобы сосредоточиться на создании качественного продукта, зацикливаются на защите собственной работы от посторонних. Им не нужен поддерживаемый код, потому что это означает, что другие люди смогут его понять и доработать. А возможно ли такое на Go? Можно ли сделать код на Go настолько сложным? Скажу сразу – дело это непростое. Давайте рассмотрим возможные варианты.

Неотредактированная версия статьи была изначально опубликована на haydenjames.io и публикуется здесь с разрешения ее автора.

Я в двух словах расскажу, как лучше всего настроить PHP-FPM, чтобы увеличить пропускную способность, снизить задержку и более стабильно использовать процессорные ресурсы и память. По умолчанию строка PM (process manager, менеджер процессов) в PHP-FPM имеет значение dynamic, а если у вас не хватает памяти, то лучше установить ondemand. Давайте сравним 2 варианта управления на основе документации php.net и посмотрим, чем от них отличается мой любимый static pm для большого объема трафика:

pm = dynamic — количество дочерних процессов настраивается динамически на основе следующих директив: pm.max_children, pm.start_servers,pm.min_spare_servers, pm.max_spare_servers.
pm = ondemand — процессы создаются по требованию (в отличие от динамического создания, когда pm.start_servers запускаются при запуске сервиса).
pm = static — количество дочерних процессов фиксировано и указывается параметром pm.max_children.

Привет! Меня зовут Алёна Исакова, я ведущий тестировщик в Авито, и я хочу рассказать вам про свой опыт введения Agile-тестирования в команду. Когда я читала доступные на русском языке статьи про Agile-тестирование и ATDD, у меня сложилось впечатление, что я «не модная», «не по Agile». Казалось, что это некая сложная структура, которая требует включения разработчиков, и до её применения мне ещё «пахать и пахать».

Какое-то время я жила с этой мыслью, писала в задачи чек-лист проверок при постановке, собирала встречи «feature-team», на которую приглашались PM, QA, Frontend и Backend для обсуждения нюансов задачи до начала реализации.

Те, кто понимает о чем речь, уже заметили подвох, не правда ли?

1. Неправильный полёт неправильного шмеля. (Вступление)

Откуда взялись науки математика и физика?

Человечество искало ответы на то, как создан окружающий мир. Частично из любопытства, в гораздо большей мере, из желания управлять этим миром, предсказывать события на основе открытых закономерностей и адаптироваться к ним.

В сегодняшнем состоянии математика и физика не совершенны — это просто системы нашей интерпретации окружающего мира, и они переплетаются и взаимодополняются в вещах, которые просты и нам понятны и начинают расходиться и противоречить друг другу и себе там, где появляются силы, феномены и законы нам непонятные или до конца не познанные. Для того чтобы объяснить эту добавочную сложность, проявляющуюся в мире, приходится вводить новые понятия и системы интерпретации (пример: квантовая физика и математика Лобачевского). И чем глубже простирается наше понимание устройства Вселенной, тем больше правок нам приходится вносить в то, что раньше считалось незыблемым законом.

Есть известный случай, когда на заре аэродинамики учёные попытались рассчитать по её законам полёт шмеля, оказалось, что он летает против законов физики. Причиной, конечно, была не «неправильность» шмеля, а несовершенная научная интерпретация законов природы, которая потом была исправлена, и счастливый шмель вновь залетал, но теперь уже в строгом соответствии с аэродинамикой.

Наверное, самый полезный вывод из этого будет звучать следующим образом: за любой закономерностью или отдельным феноменом стоит система, где все гармонично и взаимосвязано. Это утверждение применимо как к науке, так и к бизнесу.

2. Бизнес как слон

Бизнес организации тоже являются гармоничными системами, функционирующими по строгим законам, представление у человечества, о которых пока далеко не полное.

Все знают притчу о том, как слепые щупали слона за разные места и пытались описать животное. Представление у того, кто держался за хобот, сильно отличалось от того, кто держался за ногу или бивень.

За последние несколько лет я очень тесно работаю с кластерами Proxmox: многим клиентам требуется своя собственная инфраструктура, где они могут развивать свой проект. Именно поэтому я могу рассказать про самые распространенные ошибки и проблемы, с которыми также можете столкнуться и вы. Помимо этого мы конечно же настроим кластер из трех нод с нуля.

В прошлой заметке речь шла о том, как можно, по мнению автора, запрограммировать обычные действия микроконтроллера в реальном времени, разделив их на несколько не зависящих (или почти не зависящих) друг от друга задач.

Был выбран микроконтроллер, с ядром из очень распространенного семейства ARM Cortex M. Из знакомых многим, а не только автору, вариантов с цифрами 0,3,4 и 7 был выбран M4, поскольку, оказался под рукой.

Два соображения, которые побудили стать на скользкий и шаткий путь «изобретения велосипеда», как остроумно заметили некоторые читатели, на самом деле, были простыми. Первое сводилось к тому, что нам с этими «кортексами» еще жить да жить. И второе — попытаться сделать не что-то универсальное (стяжав славу и богатство), а сделать нечто более узко направленное, надеясь добиться эффективности и простоты. Те, кто иногда делают что-то руками, без труда вспомнят, что, как правило, специально подобранная отвертка подходит лучше той, что взята из блестящего универсального набора.

Плагины(Расширения)

Расширения это совместно используемая динамическая библиотека предназначенная для загрузки в процессе исполнения основного приложения, которая обязательно должна реализовывать хотя бы один специальный интерфейс.

Расширения делятся на два типа:

• Для Qt
• Для собственных приложений

Разберём как создать свою систему расширений и сами расширения для него.

Связь с расширением осуществляется с помощью интерфейса (сигналы, слоты и методы класса). Расширение загружается приложением при помощи класса QPluginLoader. Для загрузки расширения используется метод instance(), который создаёт объект расширения и возвращает указатель на него. Для выгрузки расширения используется метод unload().

Часть 1

В первом примере создадим расширение которое будет использовать функцию(алгоритм, формулу) из расширения.

Визуальная схема проекта будет выглядеть следующим образом.