Руководитель департамента разработки
Как показывает опыт Netflix, использование виртуальных потоков, представленных в Java 21, может спровоцировать возникновение неожиданных проблем. В новом переводе от команды Spring АйО мы подробно исследуем уникальные трудности, возникшие у команды Netflix при интеграции виртуальных потоков в Spring Boot на Tomcat.
Давайте же посмотрим, как виртуальные потоки могут повлиять на производительность и стабильность системы.
Первое полугодие 2024 всё, а значит, мы снова смотрим, сколько в этот период зарабатывали IT-специалисты.
Каждые полгода мы на Хабр Карьере выгружаем зарплаты, которые IT-специалисты оставили в калькуляторе, анализируем их и отслеживаем динамику. На этот раз мы изучили данные от 41 594 IT-специалистов и зовем смотреть, сколько на этот раз зарабатывали в городах, специализациях, языках программирования и компаниях.
А чтобы в следующий раз данные были еще точнее, укажите, сколько вы зарабатываете в своей специализации и заодно оцените, ниже или выше рынка сейчас ваш оклад — это анонимно.
Привет, Хабр!
Сегодня рассмотрим вариант установки утилиты модификации сетевых пакетов Zapret на роутеры Keenetic. В отличии от простого использования на конкретных устройствах, при установке на роутер появляется возможность обрабатывать трафик идущий от всех устройств, подключенных к домашней локальной сети (ПК, смартфоны и смарт телевизоры).
Всех категорический приветствую. Буквально первого августа, прямо в ночь, стал у меня жутко лагать YouTube. Естественно, мне это сильно не понравилось. Ну, что же, давайте разбираться, почему и как это исправить в условиях моей личной сети.
Что случилось?
Хорошо описано произошедшее здесь, на Хабре. Если совсем кратко, своими словами - во время установки SSL соединения в открытом виде домен передается к которому мы подключаемся(так называемое SNI). И если это googlevideo.com то начинают твориться "интересные вещи". Можно проверить это локально коммандами из статьи.
$ curl https://speedtest.selectel.ru/100MB -o/dev/null
Copilot инструмент автогенерации кода, который наделал много шуму и которым пользуются программисты по всему миру. Я тоже включился в этот хайп, поигрался, попробовал переключить свой флоу работы на него и обломался. Минусы в итоге перевесили плюсы. Сейчас про это расскажу. Ниже описание взаимодействия с автокомплитом copilot. К чату вопросов нет, хорошая и полезная штука, но в статье не про него.
У руководителей, как и у обычных специалистов, бывают самые разные проблемы: с хардами, софтами, мотивацией и прочим.
Самая неприятная ситуация возникает, когда личные ценности и майндсет человека сильно расходятся с работой, которую ему приходится выполнять. Если работа не подходит человеку из‑за конфликта с личными свойствами и мотивацией, это не исправить обучением. Если такой человек — руководитель, будет страдать он и все вокруг него.
После ошибочных назначений на должность отличные сотрудники демотивируются, выгорают в щепки и демеджат всех своих подчинённых и смежников. Не потому, что они недостаточно умны или старательны, а потому, что им каждый день приходится делать вещи, которые они ненавидят или фундаментально не могут делать.
Если ты уже давно и успешно руководишь командами, эта статья вряд ли откроет тебе что‑то новое. Если ты — инженер и думаешь, стоит ли переходить в управление или руководитель, сомневающийся, стоит ли конкретного человека делать лидом — приходи под кат.
Там я поделюсь мыслями о том, какая мотивация и ожидания от управленческой работы приводят или не приводят людей к успеху. Буду рад, если мой пост снизит количество боли и плохих карьерных решений у классных ребят.
Подобная статья должна была появиться раньше, лет десять или пятнадцать назад, когда Agile только начинал внедряться в ИТ-компаниях. Сколько можно бы было избежать ошибок, проблем, конфликтов, , если бы менеджеры сразу подходили к вопросу правильно, не отвлекаясь на лишние действия …
Зато за это время накопился опыт "внедрений" Agile в разных условиях, в разных компаниях, который следует обобщить и повсеместно распространять.
У вас есть звёзды, лидеры, ключевые сотрудники. Очень полезные и нужные люди, на них держится если не всё, то многое. А ещё у вас есть дефицит кадров. И Дамоклов меч - в любой момент могут уволиться те самые звёзды.
Вы прекрасно знаете: если звезда уходит из компании, за ним могут потянуться приверженцы и зависимые. Или туда же, куда звезда, или куда глаза глядят, потому что "мой мир рухнул", "я тут только из-за него работал(а)", "дальше будет одно болото" и т.д.
Не знаю, как в других отраслях, а у нас, в ИТ, это реально проблема, т.к. программисты не сильно привязаны к конкретной компании - слишком много вариантов, куда свалить примерно на тех же условиях (а то и лучше).
Привет, Хабр! Давайте рассмотрим способы запуска Docker в Docker контейнере (вложенное использование Docker). Такой подход не является повседневным использованием, но иногда помогает решить задачи при построении пайплайна CI/CD в GitLab или Jenkins для создания образов Docker и их публикации в реджестри (реестре образов), при...
Привет! Меня зовут Глеб Гончаров, и я руковожу подгруппой ИТ-инфраструктуры в СберМаркете. В работе мы широко используем Kafka как шину данных для микросервисов и не раз убедились на практике, что к инструменту важно подобрать правильный подход. Об этом сегодня и поговорим в двух частях — сначала обсудим основы, а в конце статьи будет ссылка на практические задания.
Проектирование REST API - это процесс создания дизайна методов обмена данными. Дизайн - это субъективное. У одних "так", у других "сяк". А кто прав? Иногда все, а иногда нет.
Можно ли сделать в проекте все методы POST? Как правильно именовать эндпоинты - ед. число или мн. число (/user или /users)? Можно ли использовать метод POST для получения данных? ...
Холиварные вопросы! Вкусовщина! Давайте разбираться!
Эту полу-шуточную теорию о проектном управлении я излагал коллегам по ИТ цеху лет 15 назад, и тогда же неоднократно слышал советы загрузить этот текст на Хабр, но руки не дошли. На днях, разгребая старые файлы наткнулся на свои записи и решил все таки поделиться ими с Вами. Частое употребление ключевого слова к сожалению, неизбежно и не отделимо для целостности этого текста, прошу принимать или нет 'as is'. Итак...
Каждая карьера развивается от Жопы к Жопе, и никак иначе. Хочешь повышения - ищи Жопу и принимай, как говорят в Америке, "challenge". Если Вам предлагают возглавить новый проект, либо занять какую то должность, да что угодно - знайте, там Вас ждет Жопа. Иначе не предложили бы, а сами бы справились. Равно как и если Вы ожидаете избавиться от надоевшей Вам сейчас деятельности, надеясь вырваться из "этого ада" и заняться "чем то новеньким" - будьте готовы встретиться с Большой Жопой.
Статья для менеджеров, которым необходимо вести управление проектами в изменчивом мире Agile. Поделюсь опытом использования двух приложений Jira Roadmap и Structure Gantt.
Для запуска и эксплуатации высоконагруженных ИТ-решений с петабайтами данных в активе, нужно проработанное решение, позволяющее гибко управлять ресурсами. Одним из критичных аспектов этого решения, является разделение Compute & Storage — разделение ресурсов инфраструктуры под вычисление и хранение соответственно. Если не реализовать такое разделение в крупном проекте, инфраструктура рискует превратиться в «чемодан без ручки» — эффективность использования ресурсов будет низкой, а сложность управления ресурсами и средами будет высока. На примере команды SberData и их корпоративной аналитической платформы я расскажу, когда требуется разделение Compute & Storage и как это реализовать максимально нативно.
Статья подготовлена по мотивам доклада на VK Data Meetup «Как разделить Compute & Storage в Hadoop и не утонуть в лавине миграций».
Apache Ozone: следующее поколение хранилища для платформы больших данных
Распределенная файловая система Apache Hadoop (HDFS) де-факто является файловой системой для больших данных. Верная своим корням big data, HDFS работает лучше всего, когда большинство файлов имеют большой размер - от десятков до сотен мегабайт.
Ozone - это распределенное хранилище, которое может управлять как малыми, так и большими файлами. Ozone разрабатывается и внедряется командой инженеров и архитекторов, имеющих значительный опыт управления большими кластерами Apache Hadoop. Это дало нам представление о том, что HDFS делает хорошо, и о некоторых вещах, которые можно делать по-другому.
Ozon и Wildberries завалены дешевыми китайскими ноутбуками «коленочной» сборки с ценниками 17–25 тыс. руб. и оперативной памятью 24 или 32 ГБ. Интересно то, что процессоры Intel Celeron N5095 и Celeron J4125, которые лежат в их основе, официально поддерживают лишь 16 и 8 ГБ соответственно.
Но тут есть любопытный момент — существуют примеры, когда эти процессоры работают с большим объемом ОЗУ, чем официально заявлено. Это может случиться по многим причинам, начиная с того, что процессоры могут являться отбраковкой каких‑то старших моделей, поддерживающих большие объемы памяти, и заканчивая обычным маркетингом, когда Intel на словах занижает характеристики, чтобы задекларировать большее число различий между линейками процессоров.
Как бы там ни было, к безымянным китайцам только один вопрос — это фейк или нет?
В 2024 году уже незачем рассказывать об S3-интерфейсе и сравнивать его с другими вариантами организации объектного хранилища. Вот и мы в Ozon, конечно, предоставляем такое платформенное решение широкому спектру внутренних потребителей. От сервисов, которые хранят картинки товаров для каталога, до бэкапов баз данных. От собственных внутренних разработок, до open-source-решений, таких как Gitlab и Thanos.
Пока у вас десятки терабайт и сотни RPS, вас устраивают такие решения, как MinIO. Но по мере роста объёмов и запросов приходится смотреть в сторону таких решений, как Ceph с RGW (RADOS Gateway / Object Gateway). Ну, а когда у вас 3 дата-центра, десятки петабайт данных, миллиарды объектов и десятки тысяч запросов в секунду — в таких условиях и у RGW начинаются проблемы.
Эта история началась с того, что и мы с проблемами масштабирования столкнулись. Под хабракатом вы узнаете, как мы прошли через отрицание проблемы, гнев на Ceph, торг с CTO и разработку собственного решения. Как выбирали технологии, на какие грабли наступили, и что в итоге получилось.
Привет, Хабр! Мы – Ярослав Насонов и Надежда Колезнева – развиваем витрину для внешних API в МТС. Сегодня обсудим тему управления API в корпорации. Поделимся опытом внедрения API-менеджмента в МТС, расскажем, что уже сделали, сколько потратили времени, с какими ошибками столкнулись, и зачем все это вообще нужно.
Эта статья будет интересна всем, кто задумывается о централизации IT-сервисов в своей компании, не знает с чего начать внедрение API-менеджмента в компанию, и поможет ответить на вопрос – а нужно ли вообще это внедрение у себя?
Чтобы сделать статью полезной, мы побеседовали с главным по API-менеджменту в МТС – руководителем платформы ЦФК Алексеем Неботовым.
Привет, Хабр! Я Федор Щудло, team lead и fullstack-разработчик. Всего я в разработке 15 лет, из них 11 в роли team lead.
Три года назад я сменил работу и занялся проектом, состояние которого можно описать кратко: ему 25 лет.
За этот долгий срок проект пережил несколько слияний и разделений компании, означающих серьезные потери людей, знаний, и даже исходников от некоторых сервисов по юридическим соображениям.
На проекте были благополучные периоды, когда были созданы очень крутые и амбициозные вещи. Но были также периоды, когда команды еле хватало на выполнение самых срочных задач. И в это время многие сделанные или не доделанные большие штуки изрядно обветшали.
Как результат, разработка шла с большими накладными расходами (все делали долго), и с высокими рисками (выкатили и разломали прод). А команда при этом работала на износ.
Но за три прошедших года мы с командой кардинально изменили ситуацию. В этой статье я расскажу про самую значимую перемену — простую, но кратно снизившую и накладные расходы, и риски. А это уже открыло дорогу сотням маленьких изменений, в итоге преобразивших проект.