Всем привет!
Меня зовут Коля, и я периодически собеседую кандидатов на позицию системного аналитика. За последние два месяца провёл порядка 20 десятков собеседований. В основном были кандидаты с опытом 1.5-3 года, на пути к уровню Middle и с зарплатными ожиданиями 150-200 тысяч рублей в месяц.
В данной статье хочу побрюзжать про несколько расстроивших меня особенностей, которыми обладало большинство кандидатов данного уровня.
Раньше у нас использовалась заливка ОС по PXE с использованием syslinux, но как бывает с самодостаточными системами и без достаточного контроля и внимания - быстро превратилась в кашу из конфигураций, библиотек, загрузчиков.
Так же была необходимость в поддержке заливки разных ОС в режиме EFI - на тот момент заливка была только в Legacy.
В желании разобраться в этом наследстве, упростить и облегчить добавление новых образов в список, я познакомился с iPXE.
Всë надоело, я устал. Мне бы сейчас полежать, а не вот это вот всë…
Не хочу больше ничего. Все козлы. Что за непонятная постановка задачи, кто еë написал? Зачем это нужно?
Если я не сделаю, всë равно ведь ничего не изменится, зачем это всë?
Эти и куча похожих фраз появляются в голове почти каждого человека с разной частотой в течение дня, недели или месяца, и почему-то я уверен, что эти мысли были во все времена. Так устроен организм — он стремится экономить энергию.
2 дня унижения в чатах, пачка Ново-Пассита, но я выдержал это испытание и узнал, что до сих пор думают о фронтенд разработчиках «другие» разработчики. Будет интересно.
В октябре 2020 года в техническую поддержку Авито стали обращаться пользователи с проблемами нагрева девайса и просадками FPS вплоть до полного фриза iOS-приложения. Проблема, как казалось, была глобальной. Она не относилась к какой-то конкретной функциональности приложения и поэтому не подходила в бэклоги продуктовых команд. Выход был один: засучить рукава и самому разобраться, что пошло не так. Не даром же я performance engineer.
Привет! Меня зовут Андрей Литвиненко и я имею почти 15-летний опыт разработки на PHP. Уже около трех месяцев я активно пишу на Go и хочу поделиться наблюдениями, которые отметил для себя. Возможно, этот текст будет полезен тем, кто сейчас знаком с PHP и подумывает познакомиться с Go.
Рассмотрим предложения для системного администратора на рынке труда в Москве.
Данная информация понадобилась для планирования фонда оплаты труда специалистов на следующий год, а также для понимания: "насколько сильно рынок убежал от текущих зарплат". Кроме организаций, такой анализ может дать мотивацию сотрудникам данной профессии для спроса индексации с работодателя или смены работы на более оплачиваемую, а может даже сдвинет в сторону саморазвития и продвижения по карьерной лестнице.
SingleA — это набор Symfony бандлов, которые позволяют развернуть свой PHP’шный SSO, реализующий фреймворк SingleAuth. Тот, в свою очередь, позволяет пользователям веб-приложений, живущих на общем домене (2 уровня и выше) перестать повторно ходить на SSO после того, как они один раз уже залогинились (даже ради простого редиректа).
Всё это призвано кардинально изменить подход к разработке проектов на базе SOA и микросервисов, упростив получение пользовательских данных на стороне приложений без утомительных интеграций.
В заметке приведен краткий обзор рефлектометров российского производства ARINST VR 23 - 6200 компании “Крокс” и CABAN R60 компании “Планар”. В качестве примера рассматривается задача измерения характеристик двухпортового устройства (кабельной сборки).
По началу я хотел назвать статью “Сравнительный обзор рефлектометров…”, но потом понял, что это было бы некорректно, т.к. рассматриваемые рефлектометры относятся к разным категориям оборудования: ARINST - серия приборов, рассчитанных на любительское применение, а CABAN - серия профессиональных приборов, внесенных в российский реестр средств измерений. Поэтому в этой статье я не пытаюсь сравнивать приборы друг с другом, а лишь рассматриваю их применение для одной и той же задачи. А что больше понравилось лично вам - решайте сами, уважаемые хабравчане.
Давно хотел написать статью на такую интересную и больную тему как импортозамещение. А именно, как это все выглядит и чем пахнет в той сфере, где я работаю – разработка и производство электронной техники, а конкретно – аппаратуры связи. У меня накопилось множество мыслей, занимательных историй, ознакомиться с которыми будет наверняка небезынтересно даже тем людям, кто далек от этой сферы.
Привет, Хабр! Я Лена Маеркина, CPO в AGIMA. Сегодня хотела бы поделиться опытом, который упросит жизнь продактам и сделает продукт удобнее для пользователей. Как вы поняли, речь пойдет о Self-service-аналитике. Погнали!
Привет! Меня зовут Григорий, я техлид в Cloud Infrastructure Team в Сравни. Моя команда отвечает за observability системы и облачную инфраструктуру. Не так давно мы полностью обновили наш стек мониторинга. Хочу рассказать, как у нас организовано хранение long-term метрик без использования Object Storage.
Мы в Сравни долгое время использовали связку Prometheus + Thanos для мониторинга и хранения данных. Для Thanos мы использовали схему с sidecar’ом. Эта схема работала довольно неплохо, но с ростом проекта — росло и потребление ресурсов. Со временем задачи по scrape samples уже потребляли значительные ресурсы. Когда только на Prometheus стало уходить больше 30 ядер vCPU и 100 гигабайт RAM, мы начали искать способы оптимизации потребления ресурсов.
Первым делом определили требования, которые необходимы для системы мониторинга:
- должно поддерживаться развертывание в Kubernetes;
- система должна быть способна переезжать из одного Kubernetes-кластера в другой без потери данных;
- нужна поддержка downsampling;
- возможность построить high availability систему;
- в идеале, чтобы система требовала очень мало внимания на обслуживание ;)
Мы поизучали варианты, и сперва показалось, что будет хорошей идеей взять стек VMAgent + Thanos receiver. Как несложно угадать из названия статьи, этого у нас не получилось. Недавно я увидел в одном профессиональном чате, что коллеги захотели использовать такой же стек и по тем же причинам, что и мы. Поэтому решил поделиться нашим опытом и рассказать, к чему мы в итоге пришли.
Всем привет! Я Виталий Дощенко, ньюбиз-директор AGIMA. Обычно на Хабре мы рассказываем, как работаем над цифровыми продуктами. Над мобильными приложениями, высоконагруженными системами или чат-ботами. Но только не в этот раз. В этой статье я расскажу, как Канбан-метод помог нам устранить последствия пожара. Не того пожара, где куча задач и ты ничего не успеваешь, а самого настоящего пожара, который чуть не уничтожил дом моей семьи.
Дисклаймер: Я написал такую статью, какую сам хотел бы прочитать полгода-год назад, когда мы стартовали миграцию в облако. Мне бы она здорово помогла сэкономить силы, время и нервы – надеюсь, теперь поможет кому-то ещё. Здесь нет исчерпывающей экспертизы, только немного моего опыта для конкретных условий и наработанные мною решения и инструменты.
Кажется это уже стало традицией: каждый раз, когда я выхожу на новое рабочее место, моя деятельность начинается с бенчмарков различных SDS-решений. Мой приход во «Флант» не стал исключением. Я попал в команду разработки Kubernetes-платформы Deckhouse, где решили развивать возможность запуска виртуальных машин в Kubernetes. Но для этого сначала потребовалось найти простое и надежное хранилище блочного типа, которое можно предложить клиентам платформы.
Я взял несколько свободных решений и протестировал, как они поведут себя в тех или иных условиях. В первую очередь интересовала производительность DRBD в различных конфигурациях и сравнение с Ceph.
Но рынок программно-определяемых хранилищ не стоит на месте и постоянно растёт. Появляются новые амбициозные проекты, включая недавно релизнутый Mayastor и pet-проект моего товарища-соратника Vitastor. Результаты оказались очень интересными.
Достаточно плотно разработкой программного обеспечения для часов я занимаюсь с 2017 года. За этот период сменилось 4 версии WatchOS (5, 6, 7, 8). Появилось больше функционала и исправлено множество баг с внедрением каждой новой версии Swift. Complications стали более самостоятельной частью приложения.
За 5 лет работы в сфере разработки приложений для часов мне пришлось столкнуться с множеством различных проблем и задач. Я хотел бы поделиться опытом и получить критические замечания относительно проделанной работы. Заранее сделаю оговорку, что решения, используемые в моей разработке, не претендуют на истинно верные. Не буду спорить, что что-то можно было бы сделать по-другому и лучше.
Всем привет!
Меня зовут Иван Антипин, я заместитель технического директора AGIMA. На рынке сложилась тяжелая ситуация: многие компании закрываются, а сработанные и крепкие команды распадаются под давлением обстоятельств. В этой статье расскажу об инструменте управления рисками — о матрице компетенций. Этот подход помогает распределять задачи с учетом балансировки нагрузки, избегать выгорания и неожиданной потери ключевых компетенций в команде. Текст написан на основе нашего с GeekBrains курса для тимлидов, по материалам лекции Ивана Михеева.
Представьте: теплый осенний вечер, на столе перед вами чашечка чего-нибудь вкусного, за окном порхают пожелтевшие листья, тонко насвистывает ветер, но на душе скребутся коварные мыши. И вам точно известно, откуда эти мыши растут: еще летом вышел стабильный Jetpack Compose, а вы таки не затащили его в ваши продакшн-приложения.
Всем привет! Меня зовут Паша Стрельченко, я Android-разработчик в hh.ru. В этой статье поведаю историю о том, как начиналась адаптация Jetpack Compose в нашем продакшн-приложении.
Привет, Хабр! Меня зовут Артём Шубский, я техлид в компании AGIMA. Заметили, что на Хабре и на конференциях часто рассказывают, как перешли с монолита на микросервисы. Мы тоже всем сердцем любим микросервисы, но в этой статье я расскажу об обратном примере: как и почему на одном из проектов шли от микросервисов к монолиту. Это поучительная история о том, почему не страшно поменять архитектуру, даже когда кажется, что поздно.
Расскажем, как решить задачу кастомной маркетинговой аналитики так, чтобы:
- данные были хорошо документированы;
- данные были доступны бизнес-пользователям в самостоятельном режиме;
- систему можно было легко поддерживать и, при необходимости, быстро подключать других аналитиков к работе.