Backend Node.js Developer
Сегодняшняя тема посвящена нелегким взаимоотношениям клиентского приложения и сервера PostgreSQL: как на ровном месте, неудачной архитектурой приложения, можно обеспечить себе хронические проблемы производительности.
Рассмотрим классические ситуации, когда разработчики начинают жаловаться на производительность БД - а виновата-то и не она!
Привет, Хабр! Это Саша Бардаш, главный архитектор интеграционных платформ в МТС Диджитал. В прошлый раз я рассказывал о пяти книгах, которые стоит почитать начинающему ИТ-архитектору. Большое спасибо всем, кто читал. Были интересные комментарии на тему, какие еще книги почитать — кое-что из этого я добавил в свою новую подборку. Итак, под катом пять книг, которые будут интересны уже более опытным ИТ-архитекторам. Что ж, поехали!
О том, как сделать прозрачную синхронизацию заметок Obsidian между устройствами (Desktop, Android, iOS) через GitHub:
1. Без сторонних приложений (вроде iCloud, SyncThing, Termux и пр)
2. Бесплатно
3. Бонусом — резервная копия: как самих заметок, так и истории изменений.
В результате получается полноценная замена Notion: структурированные заметки с автоматической синхронизацией между устройствами.
Представьте себе такую ситуацию: передо мной сидит талантливый разработчик, когда-то полный энтузиазма, но сейчас абсолютно вымотанный и разочарованный. Он уже начал ходить на собеседования и всерьез рассматривал возможность уйти из компании, которая больше не приносила ему радости. Диагноз был очевиден - выгорание.
В этот момент я поняла, что это не обычная управленческая задача. Здесь не шла речь о показателях KPI или соблюдении дедлайнов. Это был вопрос, возможно, о спасении чьей-то карьеры и еще веры в себя.
Привет, друзья!
В этой серии статей мы разбираем структуры данных и алгоритмы, представленные в этом замечательном репозитории. Это пятая часть серии.
Сегодня мы рассмотрим систему непересекающихся множеств, фильтр Блума и кэш актуальных данных.
Код, представленный в этой и других статьях серии, можно найти в этом репозитории.
Интересно? Тогда прошу под кат.
Мы все любим пробовать новые инструменты, но ненавидим их поддерживать и обновлять. Это касается всего: операционных систем, приложений, API, пакетов Linux. Больно, когда наш код перестает работать из-за обновления, и вдвойне больно, когда обновление было инициировано не нами.
В разработке API вы рискуете сломать код ваших пользователей с каждым новым обновлением. Если API -- ваш основной продукт, то обновления будут ещё более пугающими.
Общепринятое решение — редко нарушать обратную совместимость и предупреждать клиентов заранее. Внезапно, ваши релизы начинают занимать месяцы, а часть функциональности спит на дне древнего фичабранча (или фичатоггла, если повезло) до следующего релиза. Это замедляет ваших разработчиков и заставляет ваших клиентов постоянно обновлять их код, чтобы, не дай бог, он не сломался в следующем релизе.
Я расскажу на нашем примере, насколько глубока кроличья нора и как сильно можно упороться на пути к идеальному версионированию.
В этом тексте хочется подробнее рассмотреть хранение данных в PostgreSQL на физическом уровне.
Для начала определимся с общеизвестными вещами. Данные хранятся в таблицах, таблицы находятся в схемах, схемы, в свою очередь, в базах данных. Под данными я тут подразумеваю одну или несколько строк. В качестве примера будем рассматривать эталон критики, по моему личному мнению, цитаты Линуса Торвальдса.
Наступает осень – студенты всех возрастов выходят на учебу за новыми знаниями. На работе появляется больше новых проектов, дел, которые откладывали в сезон отпусков. Именно сейчас нужно максимально сконцентрироваться. Для тех, кому ее не хватает на работе или просто сейчас необходимо включиться на максимум собраны несколько важных шагов, как это сделать.
Несколько лет назад произошел Kafka-хайп. Kafka хотели использовать все, не всегда понимая, для чего конкретно она им нужна. И сегодня многие продолжают брать Kafka в свои проекты, зачастую ожидая, что её применение само по себе сделает всё лучше.
С одной стороны, это может быть и хорошо. Такие шаги стимулируют индустрию. Но всё же лучше понимать, что ты делаешь, иначе проекту можно сделать только хуже. В этой статье я обращаюсь к разработчикам, аналитикам и тестировщикам, которые еще не сталкивались с Kafka по работе. Помогу понять, почему все же в микросервисной среде многие не ходят просто по REST, а используют этот инструмент - что конкретно делает Kafka и когда есть смысл её применять.
Моя самая большая мечта при смене работы: узнать все о проекте самостоятельно. Не задать ни одного вопроса, а просто потратить немного времени на изучение материалов.
Я стремлюсь к ней. И если готовых материалов на проекте может не быть, то код есть всегда. Поэтому я читаю код.
Я совсем не разработчик. Как быстро изучить новый язык программирования?
Привет! Меня зовут Дмитрий. Я архитектор решений в крупной российской компании, более 15 лет проектирую, пишу код и руковожу командами. Сотрудничаю с Практикумом как ревьюер курса по Java и как автор курса «Архитектура программного обеспечения» в Яндекс Практикуме.
Предположим, вы решили развлечься дизайном систем (System design), пусть даже и не добровольно, на собеседовании. Если компания поленилась поделиться рабочим контекстом, то задача может быть в формате «запроектируй Твиттер». Более кандидатоориентированная компания N может попросить «спроектируй поиск на сервисе N».
Хотя статей типа «как запилить Твиттер» довольно много, не все помогут сориентироваться на реальном собеседовании. В этой статье предлагаю покопать вглубь и составить чек-лист, некий алгоритм. Он будет чуть шире, чем принято «для Твиттера», хотя универсальным его сделать не получится. Мне эта схема помогала и помогает, хотя у каждого свои фишки и предпочтения.
Эта статья — это своего рода маленький гайд или роудмап для тех, кто хочет погрузиться в микросервисы, но без лишнего стресса. Я расскажу о том, что действительно работает на практике, какие приемы стоит взять на вооружение, а от каких лучше держаться подальше. Всё это будет основано на реальных примерах и моем опыте, без излишней теории и заумных терминов.
Если ты только начинаешь разбираться в микросервисах или уже погружен в них по уши, но всё ещё чувствуешь, что некоторые моменты не до конца ясны, эта статья как раз для тебя. Она поможет понять, как построить систему, которая будет работать стабильно, масштабируемо и, что самое важное, не заставит тебя хвататься за голову каждый раз, когда что-то идёт не так. Надеюсь, мои советы и наблюдения окажутся полезными, и ты избежишь тех граблей, на которые я сам не раз наступал. Ведь, как говорится, учиться на чужих ошибках всегда приятнее.
Аудитории Хабра нравятся рецензии на книги по базовым ИТ-технологиям. И сегодня — как раз такая:«Docker. Вводный курс. 3 издание» (Docker: Up & Running, 3rd Edition) от издательства O'Reilly Media, в переводе от БХВ Петербург. Популярное руководство по Docker, написанное Шоном П. Кейном и Карлом Маттиасом, выпущено в 2023 году и предназначена для разработчиков, сисадминов и DevOps-инженеров. Полезность книги — в подробном объяснении технологии Docker от самых основ и до продвинутых концепций и практик.
Что такое дофамин и почему в среде любителей самосовершенствования он считается гормоном, способствующим отвлечению внимания?
Выражение «дофаминовый детокс» на первый взгляд звучит как полный отказ от дофамина на какое-то время, что в корне неверно. От дофамина избавиться невозможно.
Дофамин нередко называют нейромедиатором «хорошего самочувствия», однако его функция заключается в регуляции системы мотивации и вознаграждения. Когда уровень дофамина повышается, организм получает сигнал о том, что то или иное занятие доставляет нам удовольствие и его стоит повторять.
Проблема в том, что дофамин активно выделяется и во время пролистывания социальных сетей, и при достижении какой-либо значимой цели.
Редис – это кеш? А, может быть, это основная база данных? Так мы и живём в Мойре – опенсорс-системе реалтайм-алёртинга, родом из компании Контур. Расскажу вам про плюсы и минусы такого подхода, про жизнь в Редисе при 3 миллионах RPS, про миграции данных и оптимизацию базы.
Привет! Наш отдел разработки в Ozon Tech часто сталкивается с проблемой онбординга руководителей команд, ведь в каждой компании работа тимлида имеет свою специфику и не всегда позволяет ощутить остроту всех граней управления группой разработчиков. Статья представляет собой настольную инструкцию для лида, которую можно изучать самому или адаптировать для своей команды тимлидов.
Меня зовут Арманд, я руководитель отдела Ozon Crowd. Наш основной продукт — это краудсорс-система Ozon Profit. Изначально я собирал материал для приватной страницы онбординга руководителя в нашу команду, но получилось выделить общие моменты (убрать всю секретную информацию) и составить цельную картину того, с чем может столкнуться начинающий менеджер. Этим я и хочу поделиться с сообществом.
Материал статьи не претендует на объективность. Все упомянутые истории происходили в моей практике или в практике моих сотрудников, совпадения не случайны. Без лишних предисловий, начнём!
Продолжаем делиться полезными инсайтами с наших корпоративных митапов. Сегодняшний спикер, старший бэкенд-разработчик Factory5 Роман Гордиенко рассказывает об основных понятиях реляционных баз данных и о том, как использовать индексы в PostgreSQL. Информация будет полезна всем, кто работает с реляционными базами данных или планирует это делать в будущем.
Привет, друзья!
В этой серии статей мы продолжаем разбирать структуры данных и алгоритмы, представленные в этом замечательном репозитории. Это вторая часть серии.
Сегодня мы будем говорить о таких структурах данных, как хэш-таблица, куча, очередь с приоритетом и префиксное дерево.
Код, представленный в этой и других статьях серии, можно найти в этом репозитории.
Интересно? Тогда прошу под кат.
Кто ходил на собеседования по устройству на работу, тот знает, спрашивают там всякое и странное. Нередко можно встретить задачу SQL по нахождению сотрудников с максимальной зарплатой в отделе. Причем ваш потенциальный начальник считает, что у этой задачи есть только одно «правильное решение», то, про которое он прочитал в Интернете. Так ли это?