На днях вышла прекрасная, хотя и спорная статья — Please, stop using GitFlow! (и еще десяток на эту же тему после нее).

Ее основными тезисами были:

• GitFlow противоречит тезису "ветки должны быть короткоживущими".
  Это важно, потому что чем меньше живет ветка — тем меньше шанс конфликтов (не только git, но и логических)
• GitFlow препятствует rebase-ам, чтобы сохранить merge-коммиты.
  Да, их можно сохранять и при ребейзах, но команды Git Flow не делают этого.
• GitFlow отрицает подход Contunious Delivery, считая, что каждый акт Delivery должен совершаться релиз-инженером, да и в целом можно увидеть, что он ориентирован только на долгий релизный цикл.
• GitFlow не дружит с микросервисами поверх мультирепозиториев (впрочем, тут вообще мало что подходит, это идея, которая всегда плохо заканчивается)

• Но проблема GitFlow в том, что он и с монорепозиториями тоже не дружит.

  
  

  Я сам об это споткнулся в процессе дизайна пайплайнов CI: GitFlow чудовищно мешает, когда работает поверх монорепозитория с несколькими deliverables, например, когда в одном репозитории отдельно и бэкэнд, и фронтэнд — уже из-за того, что он позволяет докоммичивать в релизные ветки, могут возникнуть конфликты при обратном мердже, если в один момент времени существует больше, чем одна релизная ветка. Да даже если одна, все равно плохо — в таких условиях надо патчить в принципе релизные механизмы GitFlow, чтобы хоть как-то заработали отдельные релизы сущностей.

  
  

Так что делать-то?

В 1970 г. американские инженеры запустили аппарат Аполлон-13 к Луне. На борту три батареи топливных элементов, беспокоиться не о чем, всё надежно и многократно продублировано. Но никто не мог предположить, что взрыв кислородного баллона выведет из строя две батареи из трёх. Трагедия! Астронавты вернулись домой, о событии сняли художественный фильм с Томом Хэнксом, а фраза астронавта Джека Свигерта: «Хьюстон, у нас проблема!», вошла в историю.



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

Для больших распределенных систем такое поведение нормально, это следствие эффекта масштаба и статистики. Именно поэтому Design for Failure (дизайн на отказ) — базовый принцип проектирования облачных сервисов AWS. Системы изначально строятся так, чтобы максимально быстро восстановить штатную работу и минимизировать ущерб от известных и ещё неизвестных сбоев. На HighLoad++ Василий Пантюхин на примерах реальных проблем с боевыми сервисами показал паттерны проектирования распределенных систем, которые используют разработчики AWS.

Предлагаю ознакомиться с расшифровкой доклада начала 2020 года Андрея Бородина "Odyssey: архитектура, настройка, мониторинг"

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

В сети гуляет интересная задача, которую задавали на собеседовании в Twitter.

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

Да, Intercepter еще жив! И после длительного затишья я рад представить новую версию.

Изначально ставилась задача причесать интерфейс, исправить ошибки, ввести некоторые нововведения и протестировать работоспособность на новых версиях Android.

Что из этого вышло — под катом.

Мы широко используем микросервисную архитектуру, хоть и не считаем ее панацеей, и чуть больше 2 лет назад начали переходить на язык Go. Он сравнительно прост и, на мой взгляд, очень хорошо подходит для создания простых, небольших и быстрых микросервисов. Эта простота имеет и обратную сторону: из-за неё возникает множество способов решить одну и ту же задачу.

Казалось бы, насколько сильно может отличаться один микросервис, который ходит в базу данных, от другого микросервиса, который ходит в соседнюю базу данных? Например, одна команда использует Go 1.9, glide, стандартный database/sql и одну структуру проекта, а в это же время другая команда использует Go 1.13, modules, sqlx и, конечно же, другую структуру проекта.

Когда один микросервис в компании отличается от другого, а он, в свою очередь, отличается от третьего — это замедляет разработку. А медленная разработка — это убытки повод для оптимизации.

Меня зовут Алексей Партилов, я техлид команды web-разработки в компании Lamoda. В этой статье я расскажу, как мы справляемся с разношерстностью около 40 наших микросервисов на Go. Статья будет полезна разработчикам, которые только вливаются в Go и не знают, с чего начать более сложный проект, чем “helloworld”.

Привет, я Рэнд Миллер, соавтор «Myst». Мы поставили перед собой задачу создать реальный мир «Myst», но болезненно ударились о реальные ограничения CD-ROM. Играми я начал заниматься ещё с начала старшей школы, и я уже не молод, то есть это было довольно давно. Игры, которые у меня тогда были на компьютере, непохожи на современные. Меня очень захватила игра Lunar Lander. Я помню её до сих пор. В ней не было графики. Это была строка текста на ЭЛТ-экране, сообщавшая мне, насколько далеко я был от лунной поверхности, насколько быстро я перемещался, сколько топлива осталось, а ещё вопросительный знак. Нужно было вводить количество топлива, которое вы хотите сжечь, нажимать на ввод, и так повторять, пока не упадёшь на поверхность.

В начале старшей школы друг из колледжа взял меня с собой в компьютерный центр Университета Нью-Мексико. Я увидел эту игру на экране, и это была настоящая магия. Для меня это была магия. И он сказал: «Есть и другие игры», и что можно самому делать игры. «Вот, ты пишешь программы, чтобы они делали это». Для меня это изменило всё, и с тех пор я захотел этим заниматься. Cyan была образована примерно в середине 80-х, и в то время нам казалось, что это очень многозначное название, поэтому мы можем заниматься чем угодно. У нас с моим братом Робином была идея голубого неба, и она нам понравилось, поэтому мы выбрали такое название.

Привет, Хабр! Где-то месяц назад у меня появилось чувство постоянного беспокойства. Я стал плохо есть, еще хуже спать и постоянно читать-смотреть-слушать тонну новостей о пандемии. Исходя из них коронавирус то ли захватывал, то ли освобождал нашу планету, являлся то ли заговором масонов мировых правительств, а то ли местью панголина, вирус то ли угрожал всем и сразу, а то ли персонально мне и моему коту…

Сотни статей, постов в соцсетях, youtube-telegram-instagram-tik-tok (да уж простите) контента разной степени содержательности (и сомнительности) не приводили меня ни к чему, кроме уже описанного на Хабре разрушения мозга и еще большему чувству беспокойства.

Но в один день я купил гречки решил со всем этим нужно покончить. Как можно скорее!

UPD: добавил секцию 'Результат'.

Современные накопители данных такие как SSD нуждаются в команде TRIM интерфейса ATA и для этого в ОС построенных на базе ядра Linux предусмотрено два метода управления на уровне файловых систем:

• discard — устанавливается как опция монтировании файловой системы. Позволяет ядру Linux сразу отправлять команду TRIM на устройство, как только об этом сообщит файловая система.
• fstrim — утилита которая запускается вручную или по расписанию как сервис ОС, отправляет список удаленных блоков с ФС для зачистки их на устройстве.

Для включения fstrim достаточно активировать сервис fstrim.service в systemd, но лучше вместо сервиса, который будет висеть в памяти, использовать таймер fstrim.timer который будет запускать еженедельный TRIM.

Пример включения сервиса:

# Включение, старт и вывод статуса сервиса:
systemctl enable fstrim.service && \
systemctl start fstrim.service && \
systemctl status fstrim.service

Но этих мер недостаточно, если у вас файловые системы располагаются на томах LVM, а LVM в LUKS игла в яйце, яйцо в утке, утка в зайце:

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


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

Доброго времени суток всем.

На сегодняшний день Python является одним из наиболее используемых языков в сфере создания не только непосредственно программных продуктов, но также обеспечения их инфраструктуры. Вследствие этого многим девопсам, по их воле или против оной, пришлось учить новый язык для последующего использования в качестве дополнения к старым добрым Bash-скриптам. Однако Bash и Python исповедуют различные подходы к написанию кода и имеют определенные особенности, в виду чего портирование Bash-скриптов на «змеиный язык» иногда оказывается ёмкой и далеко не тривиальной задачей.

Чтобы упростить жизнь девопсам, создано и продолжает создаваться много полезных библиотек и утилит на Python. Данная статья описывает сразу две новых библиотеки, созданные автором сего поста — smart-env и python-shell — и призванные избавить девопса от необходимости уделять много внимания тонкостям работы с Python, оставляя простор для более интересных задач. Сфера деятельности библиотек — переменные окружения и запуск внешних утилит.

Кого заинтересовало, прошу под кат.

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

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

Суть происшествия

Иногда она тривиальная («самопроизвольно перезагрузился сервер», или «упал самолёт»). Иногда она крайне трудная для объяснения («клиенты жалуются что у не получается поменять регион», при этом все сотрудники с клиентскими аккаунтами регион поменять могут). Чаще всего, чем дальше от системного администратора источник жалобы, тем более размытой становится жалоба: «клиент говорит, что после заказа в интернет-магазине плюшевого медведя он не может поменять регион на IE7 при использовании LTE-коннекта через USB-модем, а ещё он получает 500ую ошибку при попытке отменить операцию и нажатии „назад“).

Ещё более сложным является случай, когда несколько проблем сливаются вместе: „сервер внезапно перезагрузился, а на другом сервере был таймаут работы с базой данных, а клиенты в это время писали, что у них не грузятся картинки“. Сколько тут проблем? Одна, две, три, а может и больше? Какие из проблем надо молча объединить (база данных и отсутствие картинок), а какие надо учитывать раздельно? А если в этот момент ещё придёт жалоба, что пользователь не может залогиниться в систему — это обычное „забыл пароль“ или тоже симптом? А если таких пользователей два? Или кто-то мимоходом говорит, „что-то у меня почта не проходит“?

Подсознательно в момент начала проблем, каждая новая жалоба тут же объединяется с существующими (и может завести не туда), плюс резко увеличивает стресс из-за того, что приходится думать не о трёх симптомах, а о восьми, например. А в голове хорошо только семь удерживаются. Но в то же время в моей практике бывало так, что пришедший „новый“ симптом с лёгкостью приводил к сути проблемы и её устранению…… за вычетом того, что серьёзная проблема (с которой всё началось) не имеет никакого отношения к радостно и быстро починенной ерунде. А время потрачено.

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

То есть журнал (в sticky notes) выглядит так:

• Мониторинг сработал на srv1 (22:05)
• (имя) сказал про проблемы с почтой (22:07)
• Не могу залогиниться на srv12 (22:08)/refused — Зашёл 22:16, dmesg чисто, аптайм большой
• Не могу залогиниться на srv13 (22:10) (timeout) — отвалился офисный wifi (22:11)
• Не открывается панель (22:12)
• Саппорт пишет, что клиент жалуется, что ничего не работает, 22:15

Не стоит увлекаться (не время печатать), но симптомы стоит выписывать. Один это случай или несколько, важные это симптомы или нет, станет понятно потом. Я обычно начинаю выписывать примерно после третьего отвлекающего обращения.

Вторым аспектом проблемы является доказательство существования проблемы. Самая ненавистная фраза, которой не удаётся избежать:

У меня всё работает

После того, как Энийские Авиалинии пожаловались производителю на то, что самолёты иногда падают, разработчик проверил, что самолёты взлетают/садятся и закрыл тикет с 'Unable to reproduce'. Сотрудники поддержки Энийских Авиалиний продолжают собирать статистику по падению самолётов и пытаются научиться воспроизводить падение в лабораторных условиях.

Вот уже около 20 лет Cisco живет без привычного периметра, а ее сотрудники пользуются всеми преимуществами удаленной работы. Помню, когда я пришел в 2004-м году в Cisco, я получил на руки корпоративный ноутбук с установленным Cisco VPN Client и получил право работать из… да откуда угодно. За это время я работал из дома и гостиницы, из электрички и такси, из самолета на высоте 10000 метров и в метро. По сути у нас реализован принцип «работа там, где я», а не «я там, где работа». Как нам удалось это сделать? Как мы реализовали концепцию «доверенного предприятия», которая вот уже много лет помогает нам не замечать неприятных событий, заставляющих многих из нас безвылазно сидеть по домам (разумеется, есть ряд процессов, которые требуют физического присутствия, например, производство оборудования)?

«Я разработал сюжетную линию „Теневого человека“. Он появляется в игре в заранее определённые моменты. В одном случае он крадёт зелье. Когда игрок уже готов схватить пузырёк, прибегает Теневой человек, выпивает его и сбегает. В другой раз, когда игрок уже собирается пройти через ворота, появляется Теневой человек, нажимает на плиту и закрывает ворота. После этого игрок падает на три уровня вниз, и ему приходится снова проделывать весь путь наверх. Я прописал эти столкновения в сюжете, чтобы игрок возненавидел Теневого человека и считал его своим врагом. Чтобы в момент, когда ему придётся скрестить с ним мечи в конце игры, он по-настоящему хотел поквитаться, ведь тот столько раз препятствовал игроку. Это был мой способ создания эмоциональной связи между игроком и противником через игровой процесс, а не кинематографические вставки».

Привет, я Джордан Мекнер, автор Prince of Persia. Это история о том, как я загнал себя в угол анимациями, а потом смог выбраться из него благодаря боям.

Я был ребёнком, росшим в Нью-Йорке в середине 70-х. Фанатом комиксов. Я любил кино. Рос на журнале «MAD», и если бы не появились компьютеры, я мог бы заняться комиксами и анимацией. Но когда в 1978 году появился Apple II, я воспринял его как машину, на которой я в первую очередь могу играть в игры дома, что раньше было совершенно невозможно. Вместо того, чтобы тратить четвертаки в местных залах игровых автоматов, я мог оставаться дома и играть сколько пожелаю в «Space Invaders» на Apple II. Кроме того, компьютер позволял мне создавать собственные игры, и меня это восхитило. Это случилось ещё до появления Интернета, поэтому почти все были самоучками. Я подписался на журнал «Creative Computing», а чуть позже — на журнал в «Softalk», в котором были статьи о том, как программировать. Я начал обмениваться опытом с друзьями, которые тоже любили компьютеры.

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

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


О спикере: Александр Хаёров (allexx) 10 лет занимается разработкой, в основном веб-проектами, связанными с инфраструктурой, а сейчас руководит разработкой в Chainstack. В этой должности приходится примерять на себя самые разные роли и заниматься всем: от классической разработки до принятия технических решений и управления людьми. Это позволяет исследовать разные темы, в том числе ту, о которой пойдет речь в статье — далее от первого лица.

Всем добрый день.

Недавно на Хабре появилась статья Побеждая C двадцатью строками Haskell: пишем свой wc от @0xd34df00d. Автор, известный своей симпатией к функциональному программированию, реализовал на Хаскеле аналог утилиты wc, и подверг его оптимизации, получив в результате вариант, работающий более чем в 7 раз быстрее стандартной юниксовой утилиты.

Flipper Zero — проект карманного мультитула для хакеров в формфакторе тамагочи, который я разрабатываю с друзьями. Предыдущий пост [1].

Много всего произошло с момента первого поста про флиппер. Мы усердно работали все это время и проект претерпел радикальные изменения. Главная новость в том, что мы решили полностью отказаться от Raspberry Pi Zero и делать свою плату с нуля на базе чипа i.MX6. Это значительно усложняет разработку и полностью меняет всю концепцию, но я уверен, что оно того стоит.

Также мы до сих пор не нашли правильный WiFi чипсет, который поддерживает все нужные функции для WiFi-атак, при этом поддерживает диапазон 5Ghz и не устарел на 15 лет. Поэтому я приглашаю всех поучаствовать в нашем исследовании.

В статье я расскажу, почему мы приняли такое решение, на каком этапе находится проект, текущие задачи, и как можно принять участие.

Авторы: Андрей Карпов, khandeliants Филипп Хандельянц.

Хочется поделиться интересной ситуацией, когда вопрос, используемый нами на собеседовании, оказался сложнее, чем задумывал его автор. С языком C++ и компиляторами надо всегда быть начеку. Не заскучаешь.

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

Сегодняшняя визуализация обрисовывает в общих чертах некоторые из самых смертоносных пандемий в истории, от чумы Антонина до сегодняшних событий с COVID-19.

Можно бесконечно холиварить о том, является ли GitLab хорошим продуктом. Лучше посмотреть на цифры: по итогам раунда инвестирования оценка GitLab составила 2,7 млрд долларов, в то время как предыдущая оценка была $1,1 млрд. Это означает бурный рост и то, что компания будет нанимать все больше и больше фронтенд-разработчиков.

Так выглядит история появления фронтенда в GitLab.



Это график количества фронтендеров в GitLab, начиная с 2016 года, когда их не было вообще, и заканчивая 2019-м, когда их стало уже несколько десятков. Но сам GitLab существует 7 лет. Значит, до 2017 года основной код на фронтенде писали бэкенд-разработчики, хуже того, бэкенд-разработчики на Ruby on Rails (ни в коем случае никого не хотим обидеть и ниже поясним, о чем идет речь).

За 7 лет любой проект, хотите вы того или нет, устаревает. В какой-то момент рефакторинг становится невозможно больше откладывать. И начинается полный приключений путь, конечный пункт которого никогда не достигнуть. О том, как это происходит в GitLab, рассказал Илья Климов.