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

Стоявшая передо мной задача: улучшить инфраструктуру и качество работы приложения, успевшего вырасти из MVP и стенда для одного клиента в популярный SaaS. Отсутствие отказоустойчивости и масштабируемости компонентов сервиса начало ощутимо мешать пользователям. Настала пора адаптировать приложение под кластерный режим.

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

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

• можно ли git «подстроить» под тот процесс разработки, который мне нужен?
• будет ли менеджер и заказчик удовлетворён этим процессом?
• будет ли легко работать разработчикам?
• смогут ли новички быстро включиться в процесс?
• можно ли процесс относительно легко и быстро изменить?

Немного расскажу про установку Grafana на windows и настройку базовых метрик систем.

Пару слов о самой Grafana и для чего она нужна.

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

В данной статье буду использовать:

«Чем больше я узнаю, тем больше понимаю, как много я ещё не знаю».

Введение

Я делала много вещей с компьютерами, но в моих знаниях всегда был пробел: что конкретно происходит при запуске программы на компьютере? Я думала об этом пробеле — у меня было много низкоуровневых знаний, но не было цельной картины. Программы действительно выполняются прямо в центральном процессоре (central processing unit, CPU)? Я использовала системные вызовы (syscalls), но как они работают? Чем они являются на самом деле? Как несколько программ выполняются одновременно?

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

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

Более удобный формат статьи.

Недавно на Moscow Python Podcast прошлись по всем больным точкам в IT-найме: миграции, эйджизму, девальвации офферов, собеседованиям с HR и сексизму. Не могли пройти мимо — и сделали расшифровку.

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

Все подробности под катом.

Спикеры подкаста:
• Григорий Петров, евангелист Moscow Python и DevRel компании Evrone;
• Валентин Домбровский, руководитель GeekFactor;
• Анна Атрошкина, IT-рекрутёр и руководитель компании Index;
• Злата Обуховская, руководитель разработки Nvidia.

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

С первого взгляда кажется, что эта тема очень узкая и уж точно не имеет отношения к IT. Но уменьшение населения, а что ещё более важно, изменение его возрастной и национальной структуры затрагивает все стороны жизни. Экономику - как пример длительная рецессия в Японии или поднятие пенсионного возраста в разных странах, общество - беспорядки на национальной почве как во Франции, право - обсуждение запретов абортов в России. Представьте, ваша девушка (или вы сами, если вы девушка) беременна, в стране аборты запрещены, а улететь можно только сдав кровь на ХГЧ, и если тест положительный за границу не пускают. Сейчас выглядит как бред, но в 2019 году наша реальность тоже показалась бы бредом.

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

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

Так я и познакомился с Alpine Linux.

Этот дистрибутив может вам понравиться по следующим причинам:

• Если вы любите минимализм и инструменты, ориентированные на выполнение поставленной задачи без лишних свистелок и украшений;
• Если вы заметили, что имеющиеся «мэйнстримные» дистрибутивы немного (?) раздуты и избыточны;
• Если вы захотели решить имеющуюся задачу простым способом.

Под «мэйнстримом» я подразумеваю тройку CentOS — Debian — Ubuntu (конечно же, ими мир не заканчивается), да простят меня все верующие в эти замечательные дистрибутивы. При их использовании, периодически, на границе восприятия, возникает колкая мысль – «а может быть можно проще?».

Всем привет! Меня зовут Маша, и я Golang Backend Developer в компании Ozon. В этой статье я хотела бы поговорить о теме, так или иначе объединяющую все сферы нашего любимого мира IT. А именно — VCS Git.

Без системы контроля версий сейчас невозможно представить ни один проект. Это оплот любой кодовой базы, это мощнейший инструмент, с помощью которого эту базу можно изменять и отслеживать. Однако нередко чистотой истории изменений пренебрегают, полагаясь на старое доброе «И так сойдёт!», абсолютно игнорируя при этом сложность понимания и поддержки такой истории в будущем.

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

• почему Ричард считает себя причастным к провалу Motorola и Nokia;
• к каким проблемам привело масштабирование СУБД SQLite;
• сколько тест-кейсов нужно, чтобы обеспечить ей 100-процентное покрытие;
• о том, как Ричард добавил покрывающие индексы в SQLite;
• почему и как Ричард разрабатывает собственную систему контроля версий;
• какой совет он может дать младшим коллегам.