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

• Проверка каждой ветки проходила локально. Приходилось откатывать базу от изменений с предыдущей проверки, билдить фронт. Когда несколько разработчиков вот-вот закончат работы и осталось проверить каждую по мелочи — это превращалось в ад;
• Различались окружения на проде и между разработчиками, что приводило к ошибкам: “у меня всё работает”.

Внутренний перфекционист жаждал организовать всё правильно. Делюсь результатами поисков ответа на вопрос: «а как, собственно, “правильно”»?

Мы добились

• Легкого и быстрого деплоя в production (ради эксперимента выводили каждый день две недели подряд);
• Гарантию защищённости от ошибок из-за различий в окружении приложения;
• Можем организовать эффективное взаимодействие с заказчиком:
  
  • демонстрировать каждую feature-ветку;
  • давать гостевой доступ для создания задач и наблюдения над ходом работ.

Данная статья будет полезна, если вы:

• начинающая IT-компания или в первый раз столкнулись с работой в команде над большим проектом;
• хотите обновить свой устаревший процесс разработки (workflow);
• ищете лучшие практики и хотите посмотреть, как у других;
• часто натыкаетесь на статьи про DevOps, CI/CD, облака и хотите, чтобы у вас одним нажатием кнопки создавались тестовые окружения, а очередное обновление прода не было рулеткой.

Под катом вы найдёте

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

Вступление

Фото сделано мной при посещении шоу-рума BMW Мюнхена.

Небольшая статья о там, как живется и чем дышится в большом и неповоротливом Automotive мире. Мире разработки программного обеспечения, какие технологии используются, какие задачи приходится решать, все исключительно на личном опыте. Да, тут я истины не открою, автомобильное ПО как правило использует устаревшие технологии и достаточно длинные циклы разработки, хотя конечно бывают исключения — Tesla, например. Хотя это лишь мои предположения по тому, что я могу прочесть об этой компании в интернете. Текст содержит небольшие вставки биографии автора.

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

Недавно я наткнулся на топик "Сервер онлайн-вещаний на базе nginx" о замечательном модуле Романа Арутюняна (@rarutyunyan) для nginx: nginx-rtmp-module. Модуль очень прост в настройке и позволяет на основе nginx создать сервер публикации видеозаписей и живого вещания.

Про сам модуль можно прочитать на его странице на GitHub, я же хочу привести несколько простых примеров использования. Надеюсь, топик поможет новичкам в видеоделах (таким как я).

Во время посещения PyConRu 2014 я, с удивлением, узнал, что достаточно большая аудитория python-разработчиков не использует SQLAlchemy в качестве основного инструмента для работы с базой данных. Порассуждав на данную тему после Light Talks с коллегами было принято решение — во чтобы то ни стало написать статью о том, что же можно делать со всей мощью SQLAlchemy.

Обычно в написании сайтов не требуется чего-нибудь этакого от штатного ORM. А если и требуется, то хватает замены на нештатный или прочтения основной части документации. И, как правило, голову ломать над сложными запросами не приходится. Достаточно много различных ORM предлагают классические схемы One-2-Many, One-2-One, Many-2-Many, и т.д. Для обычных запросов и связей этого вполне достаточно. К сожалению, в больших проектах не обходится без частных случаев и программисты при сложных запросах пишут либо raw sql, либо полагаются на то, что им предлагает базовый функционал ORM. Это выглядит не совсем красиво или создает достаточно большую нагрузку на базу данных.

Понятно, что в погоне за скоростью выполнения сценариев, можно пожертвовать красотой кода, но что если скоростью можно пренебречь, а вот кроссплатформенностью — нет? Да и не хочется в python коде видеть что-то кроме python кода. А что если хочется на полную катушку использовать любимый ORM (для меня SQLAlchemy) и не писать raw sql запросы?

Эмулятор карт EM Marine

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

Когда я начинал свою карьеру разработчика, моей первой работой стала DBA (администратор базы данных, АБД). В те годы, ещё до AWS RDS, Azure, Google Cloud и других облачных сервисов, существовало два типа АБД:

• АБД инфраструктуры отвечали за настройку базы данных, конфигурирование хранилища и заботу о резервных копиях и репликации. После настройки БД инфраструктурный администратор время от времени «настраивал экземпляры», например, уточнял размеры кэшей.
• АБД приложения получал от АБД инфраструктуры чистую базу и отвечал за её архитектуру: создание таблиц, индексов, ограничений и настройку SQL. АБД приложения также реализовывал ETL-процессы и миграцию данных. Если команды использовали хранимые процедуры, то АБД приложения поддерживал и их.

АБД приложений обычно были частью команд разработки. Они обладали глубокими познаниями по конкретной теме, поэтому обычно работали только над одним-двумя проектами. Инфраструктурные администраторы баз данных обычно входили в ИТ-команду и могли одновременно работать над несколькими проектами.

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

Сегодня разберем пару примеров, как неудачная организация БД и кода могут превратить наше приложение в клубок проблем:

• накрутка serial при ON CONFLICT
• накрутка счетчика транзакций

Всем привет! Меня зовут Роман Халкечев, я руковожу отделом аналитики в Яндекс.Еде. Одно из ключевых направлений этого сервиса — логистика. Эффективность алгоритмов логистики во многом и определяет само существование сервисов доставки. Сегодня я расскажу читателям Хабра о нашем новом алгоритме, который помог курьерам сократить время простоя. Вы узнаете, из чего складывается время ожидания доставки заказа и зачем мы считали скорость приготовления килограмма условной еды. Но обо всём по порядку.

Яндекс.Еда представляет собой маркетплейс: на сервисе есть спрос и есть предложение. Спрос — это заказы пользователей. Предложение — курьеры. Разумеется, под предложением мы также понимаем рестораны, но в контексте этого поста остановимся именно на курьерах. Главная задача сервиса — поддерживать баланс: тогда будут счастливы и пользователи (они быстро получат еду), и курьерские службы (заказов хватит всем курьерам). Чтобы сохранять баланс и переживать локальный рост или падение спроса, нам необходимо повышать эффективность доставки. Под эффективностью мы понимаем оборачиваемость — среднее число заказов, которые курьер успевает доставить за час. Чем выше этот показатель, тем эффективнее работает доставка в целом.

Моя статья про проводной умный дом была популярной на Хабре (159 тысяч просмотров) — в ней я описал положительный опыт от идеи до реализации умного дома в новостройке.

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

1. мониторинг приборов учета;
2. датчики контроля: домофона, температуры, шума, открытия дверей, ...;
3. единая панель управления умным домом;
4. подъездное видеонаблюдение;
5. настенный дисплей для текущего времени и температуры за окном;
6. освещение в квартире, включая кнопку «выключить всё»;
7. удаленное обесточивание квартиры;
8. удаленное перекрытие воды.

3D модель этой двухкомнатной квартиры 47 кв.м, которая была автоматизирована, нарисованная в Sweet Home 3D

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

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



И вроде как звучит всё прекрасно. Но не все компании спешат брать с пример с передовиков (Booking.com, Amazon.com) и продолжают работать по старинке. Так что же им мешает? Как минимум, понимания целесообразности масштабных инвестиций в инструментарий по обработке данных, трудозатратность внедрения процессов описания данных, появления новых ролей (кураторы данных, ответственные за качество данных, инженеры и архитекторы данных и т.п.), научиться считать экономический эффект от внедрения управления данными, четко вычленять драйверы затрат, как сделать дата офис самоокупаемым, увязать со стратегией компании и из возможных вызовов выбрать те, которые продвинут компанию вперед, и многое другое.

Меня зовут Виктория Краснова, я руководитель Управления корпоративными данными СИБУРа. Вместе с моим коллегой, лидером команды Data Governance Ринатом Абдурахмановым, расскажем, как это делаем мы.

В обычное время механизатор зарабатывает около 30 тысяч рублей в месяц. Но всё резко меняется во время уборки урожая, когда механизатор на время становится оператором комбайна — комбайнёром, за этот промежуток он получит до 150 тысяч рублей. Есть буквально две недели, когда нужно собрать всё, во что вы целый год вкладывали огромное количество денег за работу, удобрения, солярку и так далее. Работать можно примерно с восьми утра (настроить машину, в девять начать) до темноты, потому что роса и ночная влажность резко ухудшают качество зерна. На износ. И на третий-четвёртый день начинаются проблемы с авариями или перемалыванием не того и не так.

Со стороны кажется, что задача — проехать на комбайне по полю «змейкой» и «перемолоть» всю пшеницу или другую культуру. На деле всё далеко не так. Оператор должен следить за сотнями вещей и при этом постоянно смотреть на кромку поля, чтобы двигаться ровно. Представьте себе, что вы едете 12–14 часов по трассе на скорости 120 км/час за человеком, который раз в полчаса неожиданно тормозит. Примерно то же чувствует оператор: работа невероятно монотонная, но при этом постоянно нужно быть готовым к сюрпризу.


Сюрприз может выглядеть так. Пока мы ездили «в поля», не видели ни одного целого комбайна без следов сварки.

Фактически комбайнёр следит за процессом обработки зерна (одно рабочее место) и при этом ведёт технику (другое рабочее место). Но только это один человек. Следствие — страдает что-то одно. Поскольку, если плохо вести, можно случайно перемолоть камень или человека на поле, и страдает обычно качество уборки зерна.

Часть работы легко автоматизируется. Сейчас расскажу, что именно мы сделали и как мы модифицируем даже довольно старые комбайны своими роботами.

ООП (Объектно-Ориентированное Программирование) стало неотъемлемой частью разработки многих современных проектов, но, не смотря на популярность, эта парадигма является далеко не единственной. Если вы уже умеете работать с другими парадигмами и хотели бы ознакомиться с оккультизмом ООП, то впереди вас ждет немного лонгрид и два мегабайта картинок и анимаций. В качестве примеров будут выступать трансформеры.

Привет! Меня зовут Георгий, я дизайнер.

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

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

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

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

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

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

abstract: В статье описаны продвинутые функций OpenSSH, которые позволяют сильно упростить жизнь системным администраторам и программистам, которые не боятся шелла. В отличие от большинства руководств, которые кроме ключей и -L/D/R опций ничего не описывают, я попытался собрать все интересные фичи и удобства, которые с собой несёт ssh.

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

Оглавление:

• управление ключами
• копирование файлов через ssh
• Проброс потоков ввода/вывода
• Монтирование удалённой FS через ssh
• Удалённое исполнение кода
• Алиасы и опции для подключений в .ssh/config
• Опции по-умолчанию
• Проброс X-сервера
• ssh в качестве socks-proxy
• Проброс портов — прямой и обратный
• Реверс-сокс-прокси
• туннелирование L2/L3 трафика
• Проброс агента авторизации
• Туннелирование ssh через ssh сквозь недоверенный сервер (с большой вероятностью вы этого не знаете)

Как все начиналось

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

Когда у меня в очередной раз закончились деньги, наступил кризис. Я не смог найти работу, ситуация стала критической. Пришло время посмотреть на все вещи трезвым взглядом. Нужно было честно признаться себе, что я не знаю, какие ниши выбрать для бизнеса. Создавать проекты, которые просто нравятся, — путь в никуда.

Тележка будет медленно толкать своих жертв со скалы в больницу, удобно ожидающую внизу. Они, вероятно, переживут падение (физика мультфильмов!), но потребуют интенсивной медицинской помощи. Если вы потяните рычаг, отправив тележку на нижнюю колею, вы, по крайней мере, сможете выиграть немного времени на подготовку, сократить количество пострадавших и распределить их сильнее, тем самым предотвращая перегруженность персонала больницы. Но черт, это тяжелый рычаг, и тянуть его будет не приятно. (перевод Андрей Дунаев)

Я хочу инициировать создание ситуационного центра, где можно оперативно и централизованно получать информацию ДЛЯ САМОСТОЯТЕЛЬНЫХ выводов о текущем положении дел и принимаемых мерах по поводу:

а) вируса
б) действий правительств
в) действий медиков
г) действий работников и работодателей
д) действий каждого отдельного человека

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

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

В Африке, можно представить, как жили люди до начала индустриальной революции, еще до того, когда централизация средств производства вынудила людей собираться в одно и тоже время в одном месте для совместной работы. Но именно развитие промышленности сформировывало уклад, к которому мы привыкли сегодня. Только сейчас многие из нас собираются утром к 9 утра не для того, чтобы вместе собирать машины на конвейере, а скорее всего в офисе, где мы весь день будем писать друг другу письма по электронной почте, сообщения в мессенджерах, обсуждать что-то в переговорных и по телефону. Однако на сегодняшний день все больше видов работ, где и без физического присутствия группы людей в одном месте и в одно время можно получить требуемый результат труда. Во многих сферах бизнеса это уже стало нормой: международные корпорации успешно работают распределенными командами и часть из них задумывается об использовании опции удаленной работы. Компания IBM, к примеру, недавно объявила, что до 40% сотрудников частично или полностью работают удаленно.