Привет, Хабр!

Меня зовут Дмитрий, и я бэкенд-разработчик в SENSE с 10-летним опытом. За это время я успел поработать с финтех-проектами, автоматизировал обработку заказов для интернет-магазинов, но GraphQL долгое время оставался для меня загадочной технологией — я просто не сталкивался с ним в работе. А когда он мне понадобился, то обнаружил, что толковых материалов по Spring-реализации GraphQL очень мало. Поэтому, я решил не только разобраться самостоятельно в теме, но и написать гайд для тех, кто, как и я, только начинает погружаться в эту тему. 

Разбираться будем постепенно: в первой статье покажу, как создать проект с GraphQL с нуля. Поехали!

Привет, Хабр!

Меня зовут Ирина, я IT-рекрутер в компании SENSE. И сегодня хочу поговорить о проблеме, которую сложно не заметить, если вы так или иначе связаны с наймом, обучением или карьерой в сфере технологий. Вокруг нас полно курсов и карьерных консультантов, которые заманивают яркими обещаниями быстрого успеха, а в итоге создают коллапс на уровне джунов и даже задевают мидлов. Под красивой обёрткой скрываются псевдоэксперты и псевдопрограммы, последствия которых приходится разгребать работодателям, рекрутерам и самим соискателям.

Привет, Хабр!

Эта статья о том, как мы избавились от шаблонизации в пользу понятных слоёв в управлении инфраструктурой. Расскажу про предпосылки, поиск решения и инструмент, который мы выбрали — CUElang. Поехали!

В управлении Kubernetes-инфраструктурой рано или поздно наступает момент, когда шаблоны из удобного инструмента превращаются в источник боли.

Всем привет! И снова с вами Илья Криволапов – системный аналитик в SENSE, где мы вместе с командой трудимся над проектом одного из цветных банков РФ. Напоминаю, что в профессии я уже больше пяти лет и, несмотря на фамилию, прод все еще живой и здоровый (ну почти)!

В свободное от работы время, я преподаю курс «Хранение и обработка больших объемов данных», где успел накопить немало наблюдений, кейсов и выводов, которые не хочется держать в столе. Поэтому всё самое полезное оформил в цикл статей на Хабре – рассказываю как строить базы данных с прицелом на рост и не сойти с ума под нагрузкой.

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

Материал будет полезен всем, кто проектирует, масштабирует или просто поддерживает «здоровье» базы данных: DBA, архитекторам, DevOps-инженерам, аналитикам и разработчикам.

Финальный рывок – поехали!

Всем привет! На связи снова Илья Криволапов — системный аналитик в SENSE, где мы трудимся на проекте одного из цветных банков РФ. Работаю в профессии уже пятый год и, несмотря на мою фамилию, с продом у нас в целом тёплые отношения. 

Помимо боевых задач, я преподаю курс «Хранение и обработка больших объемов данных» и за это время накопил немало практических кейсов и наблюдений. Всё это добро я решил не держать при себе и собрал самое полезное в виде ультимативного гайда по оптимизации и грамотному проектированию баз данных с расчетом на масштабирование, который сейчас публикую на Хабре.

Цикл состоит из 3 частей. В первой мы обсудили два базовых подхода к масштабированию БД: вертикальный и горизонтальный. Поговорили о плюсах, минусах и о том, как делать точно не стоит. 

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

Материал по-прежнему будет полезен всем, кто заботится о «здоровье» базы данных: DBA, архитекторам, DevOps-инженерам, аналитикам и разработчикам.

Готовы продолжать? Тогда поехали!

Всем привет! Меня зовут Алексей, я тимлид команды разработки в SENSE. Как нанимающий специалист, я все чаще сталкиваюсь с кандидатами, которые притворяются разработчиками. Например, приходит человек, у которого в резюме 4 года коммерческого опыта, уверенный стек, проекты интересные. Думаешь: ну вот, наконец, нормальный разговор по делу. Но вместо этого – щелчки клавиатуры за кадром, невнятные паузы, ответы как заученные. А дальше ступор на задачах, а у некоторых «особенно одаренных» в коде «as per OpenAI suggestion».

Сначала я не понимал, что происходит. А потом узнал, что это не случайность, а целая субкультура. Таких людей называют ИТ-волки. Они учатся не программировать, а проходить собеседования – звучать убедительно, продавать себя и брать офферы, даже если за этим нет ничего.

Привет, Хабр!
Меня зовут Марина, я Head of Analytics and ML в SENSE, занимаюсь анализом данных уже более 5 лет. Сначала препарировала спектры в физике высоких энергий и сотрудничала с ЦЕРН-ом, а теперь строю рекомендательные системы и аналитику.

В статье расскажу про опыт работы с пакетом FEDOT для прогнозирования временных рядов. Статья пригодится тем, кто хочет вкатиться в тему временных рядов и потыкать свои первые модельки на примере отечественных библиотек. Объясняю на примере задачи прогнозирования выходов кандидатов.

Дисклеймер: во временных рядах я только начинаю свой путь, так что делюсь всеми своими фейлами и буду рада обратной связи в комментах.

Всем привет! Меня зовут Илья Криволапов, тружусь системным аналитиком в SENSE на проекте одного из цветных банков РФ. В профессии я уже пятый год и, несмотря на фамилию, ломал прод всего лишь несколько незначительных раз (надеюсь). 

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

Всего в цикле будет 3 статьи. В первой поговорим о двух разных подходах масштабирования БД и о том, как лучше его делать и как лучше не делать (Никогда. Пожалуйста). 

Кому будет полезно? Всем отвечающим за «здоровье» базы данных: DBA, архитекторам, DevOps-инженерам, аналитикам и разработчикам. 

Согласны? Узнали? Тогда поехали!