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

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

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

Мы добились

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

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

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

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

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

Полтора килограмма термоядерного Тринидадского Скорпиона я в итоге собрал с одного куста на гидропонике.

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

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

Сегодня в меню

1. Что такое гидропоника и почему она гораздо проще, чем почва с червячками
2. Никаких дорогих бутылочек. Мешаем компоненты по три рубля за ведро
3. Питание растения как алгоритм
4. Как быстро собрать прототип гидропонной установки
5. Что такое capsicum chinense и как выжить при дегустации

*"ублюдок" — вольный перевод слова "git" — "an unpleasant or contemptible person", "неприятный или презренный человек".

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

Давайте посмотрим, что можно использовать, чтобы улучшить себе жизнь. Статья предполагает, что читатель умеет пользоваться основными возможностями git и понимает что делает, когда, скажем, вводит в консоль git rebase --merge --autostash.

Привет, Хабр! Представляю вашему вниманию перевод статьи "Anatomy of Channels in Go" автора Uday Hiwarale.

Что такое каналы?

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

Создание канала

Go для создания канала предоставляет ключевое слово chan. Канал может передавать данные только одного типа, данные других типов через это канал передавать невозможно.

Безусловно одной из самых популярных технологий доставки оповещений на устройства пользователей являются Push уведомления. Технология такова, что для её работы необходим постоянный доступ к интернету, а именно доступ к серверам, на которых регистрируются устройства пользователя для получения уведомлений. В данной статье мы рассмотрим весь спектр механизмов технологии WebPush уведомлений, спрятанных за словами WebSocket, ServiceWorker, vapid, register, broadcast, message encryption и т.д. Основной причиной побудившей меня к реверсу и изучению механизма, являлась необходимость доставки уведомлений мониторинга на рабочие места техподдержки, находящиеся в закрытом сегменте сети без доступа в интернет. И да, это возможно! Подробности под катом.

Введение

• Front-End на JS
• Back-End на Python (за основу взята библиотека Seaborn)
• Back-End на R

Как то вечером, придя домой с работы, я решил немного позаниматься домашним проектом. Я сделал несколько правок и сразу захотел поэкспериментировать с ними. Но до экспериментов мне пришлось заходить на VPS, пулить изменения, пересобирать контейнер и запускать его. Тут я и решил, что пора разобраться с непрерывной доставкой.

1. Клон Notion

• HTML Drag and drop API. Пользователь может «схватить мышкой» draggable элемент и поместить его в droppable зону.
• Как синхронизировать в режиме реального времени данные между компьютером и смартфоном.
• Мы позволяем пользователям создавать, читать, обновлять и удалять записи, тем самым мы тренируем CRUD-навыки.