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

Вспомним наш любимый мультфильм «Падал прошлогодний снег» с его шикарными крылатыми фразами. Одна из них: «Уж послала, так послала». Вот и система так же — вместо отправки запроса посылает его куда-то далеко. А запросу обидно.

Переехать в микросервисы можно двумя способами. Можно построить платформу — это надежно, но очень сложно. Или можно поднять Kubernetes и начать в него коммитить новые сервисы. Переезд проходит быстро и легко, но редко получается то, на что вы рассчитываете. Например, вместо микросервисной структуры вы можете обнаружить распределенный монолит.

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

Меня зовут Олег Федоткин, я Head of PaaS СберМаркет, мы занимаемся той самой платформой, которая помогает разработчикам лучше, удобнее и быстрее писать микросервисы. Мы стандартизируем всю разработку, стараясь снизить Time to Market для новых фич. Но это всё равно очень сложно. Поэтому сегодня я разберу самые распространенные микросервисные проблемы.

В мире, где количество скачиваний Telegram перевалило за 1 млрд, есть простая задача — принимать звонки от клиентов. Будем разворачивать колл-центр?
Давайте представим себе сколько это головной боли:

• Арендовать номера телефонов, помещение для операторов
• Покупать, устанавливать телефоны (Хардфоны? Софтфоны ?)
• Нанимать-обучать операторов, платить им зарплату (… продолжать? :-) )
• Подумать как организовать удаленный доступ (vpn ?)

Почему бы просто не принимать звонки на Telegram сотрудников и назвать их операторами?
Просто, да не очень то уж и просто...

Довольно много дебатов ведется относительно того, какой термин более правилен: DevSecOps, SecDevOps, или же вообще "sec" часть этого термина является лишней. В этой статье хотел бы поделиться тем, каким мы видим ответ на это вопрос в компании GitLab, а также расскажу о наших текущих разработках в сфере обеспечения информационной безопасности.

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

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

Это становится сигналом, который я не могу игнорировать. Свидетельство того, что батарейка моя на исходе, и надо что-то с этим делать, чтобы не свалиться в очередное выгорание.

C++ — один из самых непонятных языков в современной поп-культуре разработчиков программного обеспечения. Люди часто сравнивают его с C, потому что это "низкоуровневый" язык. Следовательно, он получил репутацию эзотерического языка, который интересует только параноиков производительности. Это далеко не так. Я программирую на C++ в качестве основного языка уже некоторое время, и опыт разработчика на самом деле очень хорош — гораздо лучше, чем можно было себе представить.

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

Транспортная задача линейного программирования относится к перечню классических задач, решаемых в практике деятельности людей. Эта задача методами классической математики не решается. В задаче необходимо отыскивать экстремум целевой функции. В задаче целевая функция – линейная. Ограничения на переменные (их может быть очень много) описываются также линейными зависимостями. Казалось бы чего проще. Но как раз ограничения и порождают трудности, связанные не просто с поиском max и min при отсутствии ограничений, а с необходимостью учета таких ограничений. Искать требуется не просто экстремум, а условный экстремум. Методы решения задачи позволяют учитывать особенности структуры задачи и даже отказаться от симплексного метода решения в чистом виде.

20 марта 2013 года на конференции PyCon 2013, Соломон Хайкс (CEO компании dotCloud) выступил с пятиминутной презентацией The future of Linux Containers. В ней широкой общественности впервые была представлена внутренняя разработка компании dotCloud под названием Docker, а спустя несколько дней ее исходный код был выложен в открытый доступ. Хотя технологии LXC и Aufs, на которых была основана первая версия Docker существовали и активно использовались уже порядка пяти лет, но именно появление Docker послужило началом стремительного роста и эволюции систем контейнеризации, что кардинально преобразило многие процессы разработки и деплоймента программного обеспечения.

Этой статьей я собираюсь начать небольшой цикл посвященный изучению развития исходного кода Docker на протяжении нескольких лет. В первой части мы посмотрим на то, что представлял собой код на момент создания git репозитория датированного январем 2013 года. Тогда исходный код Docker (за исключением тестов) состоял всего из шести файлов общим объемом ~600 строк кода, написанных на языке Go. Это больше походило на библиотеку/api, функционал которой состоял лишь в создании, удалении, запуске и остановке контейнеров. Мы разберем принцип работы и даже сможем запустить с ее помощью подготовленный контейнер. 

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

Привет, Хабр. Меня зовут Рустам. Я работаю в Ozon: админю Kubernetes и пишу на Go.

У нас очень много сервисов на Go — их количество исчисляется тысячами. Запускаются они внутри кластеров Kubernetes. А я плотно работаю с Kubernetes и заметил, что при запуске кода внутри Kubernetes для резолва одного адреса делается до десяти DNS-запросов. Это, конечно, влияет на производительность.

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

Эта статья оперирует версией Go 1.14.

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

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

Хотя, подобные решения, не всегда хороши. В отличие от обыкновенных цифровых значений, которые легко кешировать и сортировать, UUID не так гибки в использовании. UUID версии 7 предназначен как раз для того, чтобы разобраться с подобными проблемами.

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

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

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

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

Представьте, что вам предстоит собеседование на позицию системного аналитика (СА). Что нужно знать для успешного прохождения интервью и какие вопросы могут задать? Эта статья может стать roadmap при подготовке к собеседованию.

Хабру катастрофически не хватает такого формата постов как "продолжение" или "дополнение". После написания статьи зачастую появляется материал, который хотелось бы добавить к сказанному, но update'ить статью, с её сроком жизни в 1-2 дня, бессмысленно, а писать в комментариях невозможно из-за объёма материала. В то же время этого материала может быть недостаточно для новой статьи, да и, в силу того, что он сильно перекликается с предыдущей статьёй, придется либо постоянно её цитировать, либо оставлять пробелы, подразумевая, что читатель понимает о чем идет речь.

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

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

Здравствуйте, меня зовут Дмитрий Карловский и я крайне опечален качеством поиска современных поисковиков.

Например, обсуждали мы как-то в $mol-чате стоит ли делать "человеко-понятную" псевдостатику в урлах вида /snjat-dvushku/s-remontom/v-vihino для SEO, или всё же сеошники - шарлатаны, гадающие на поисковой гуще. Решили проверить кто там у нас в топе по запросу "квартира купить однокомнатная горьковская" и получили такой результат:

Дыбенко, Лесная, Жопа Мира, всё, что угодно, только не то, что спрашивали. Первые 4 результата - нерелевантный мусор. А потом сервис самого же Яндекса. Как так получилось, что в 2к21, в эпоху машинного обучения и GPT-3, у нас получился поиск хуже, чем на заре интернета?