Все потоки

Умные часы за последние десять лет сильно изменились. От обычных гаджетов для уведомлений они превратились в мини-компьютеры с яркими экранами, множеством сенсоров и привязкой к облачным сервисам. Цена этого прогресса — слабая автономность и почти полный контроль со стороны производителей. На этом фоне возвращение Pebble выглядит логично: бренд, стоявший у истоков рынка, снова делает ставку на экран с электронными чернилами, продолжительный автономный режим и открытую платформу без ограничений. Ниже — история Pebble и причины, по которым его подход снова актуален в 2026 году.

В статье рассказывается, как команда интегрировала Qlik с OpenMetadata, создав собственный коннектор вместо использования коробочного решения. Авторы объясняют, почему стандартный подход не обеспечивал нужного lineage и привязки к глоссарию, и как они решили проблему с помощью парсера скриптов Qlik, поддержки include-файлов и доменной модели Business Views. В результате удалось связать дашборды с источниками данных и бизнес-терминами, сократив время поиска отчётов с 2 часов до 2 минут и обеспечив покрытие lineage более чем для 85% приложений. Статья будет полезна тем, кто сталкивается с управлением метаданными в крупных BI-инфраструктурах.

В системах, где генерируются миллионы событий в день (например логи), первичные ключи часто строятся на основе UUID. Это логично: они глобально уникальны, не требуют централизованного генератора и хорошо масштабируются.

Но не все UUID одинаково полезны. Особенно когда речь заходит о производительности БД.

В нашем сервисе мониторинга и анализа PostgreSQL мы использовали UUID v1 - и столкнулись с ростом дисковой нагрузки на PostgreSQL. После перехода на UUID v7 удалось добиться сокращения числа операций с диском в 2 раза, на четверть снизить размеры индексов и полностью устранить их фрагментацию.

Это вторая (и заключительная) часть цикла статей о нашей миграции с Zeppelin. О причинах и первом опыте перехода с Zeppelin я рассказал здесь. В данной статье я хочу большее внимание уделить второму виду Zeppelin notebook, которые срочно нуждались в переносе.
Конечно, отчеты для клиентов не были настолько "забагованы" как рассылки: большая часть проблем с Zeppelin крылась именно в cron-е, который временами работал как хотел (или в интерпретаторах, мы так и не смогли разобраться, но ошибка интерпретатора возникала только когда запускали через cron). В отчетах этого звена не было, поэтому их перенос был плавным и основан скорее на особенностях UI/UX дизайна.
Данная статья может быть полезна аналитикам, которые не знают, какой инструмент использовать для своих задач и думают, что писать графический интерфейс крайне сложно (спойлер, нет), а также для команд, которые устали от Zeppelin как UI-инструмента (и от Zeppelin в целом)

Всем привет!

Читая очередную книгу по архитектуре ПО, я в который раз столкнулся с новым определением того, что же это такое. И всё бы ничего — я уже как будто привык к этому, но буквально те же самые авторы давали совсем другое определение в предыдущей книге!

— Да сколько можно! — подумал я. И тут во мне проснулось любопытство: а сколько вообще таких определений от разных авторов? Есть ли какое-то общепризнанное мнение?

Как оказалось, нет — разные авторы, фреймворки и спецификации дают разные определения. SEI (Software Engineering Institute) даже составил документ около 10 лет назад со списком разных определений. Но в рамках исследования для этой статьи я понял, что и он неполный.

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

Качественное и своевременное внедрение корпоративных информационных систем как российского (1С, Галактика, Парус), так и западного производства (ранее преимущественно SAP, Oracle и Microsoft) требует досконального знания методологии имплементации, что накладывается свой отпечаток на жизненный цикл программного обеспечения. Несмотря на наличие гибких методов внедрения, жизненный цикл программных продуктов, по существу, остается единым: начиная с задумки и заканчивая выведением из эксплуатации. Внедрение корпоративных программных систем, представляющих собой имплементирование программного решения в масштабах предприятия или холдинга, имеет схожий жизненный цикл. Однако, если внимательнее к нему присмотреться, выходит, что процесс внедрения является не единственным, а фактически завершающим шагом. Не верите, тогда давайте разберемся в этом вопросе в рамках текущей статьи.

Приведем шаги классического жизненного цикла программного обеспечения [1]:

Развивать платформенные продукты не просто. С бизнес-продуктами всё более менее понятно: развивать надо то, что приносит деньги. Тут главный вопрос, как узнать, что именно приносит деньги. Это тоже очень не просто, и на эту тему написано десятки статей и даже учебников.

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

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

За зимние каникулы мы с Gemini (да, почти весь код написал ИИ) создали свой солвер на WebGPU. Весь софт - это один HTML-файл. Он работает в браузере, считает сетки до 16К в реальном времени и умеет то, чего нет у аналогов.

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

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

В этой статье я хочу показать подход, при котором автоматизированные e2e-тесты используются не только для проверки работоспособности продукта, но и для автоматического создания актуального пользовательского руководства — на базе реальных сценариев и реального интерфейса.

Обзор лучших нейросетей для презентаций в 2026 году: русские аналоги западных сервисов Gamma, Tome, Canva, полный гайд по выбору ИИ для создания качественных презентаций под ключ. Советы по генерации осмысленного текста и слайдов.

Проблема ценообразования на ИТ-услуги и, в частности, вопрос об определении оптимальных ставок на работы по T&M напрямую влияет на бизнес многих ИТ-компаний. Тут есть множество интересных нюансов. Предлагаю рассмотреть их в данной статье. Возможно, это поможет осознанно выбирать лучшие варианты, когда придется принимать очередное решение на эту тему.   

В Яндекс Практикуме мы постоянно следим за изменениями на рынке и обновляем учебные программы в соответствии с новыми требованиями. Чтобы актуализировать курс «Фронтенд-разработчик», в конце 2025 мы опросили нанимающих менеджеров из Сбера, «МегаФона», VK, «Северстали» и компаний среднего и малого бизнеса. 

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

Семь лет в Angular. Позиция lead frontend-разработчика на проекте. Архитектура, оптимизация, legacy-код и Node.js для серверной логики. И при этом — «Гдэ ваши доказатэльства?». Знакомая ситуация? Я прошёл через это и понял, где кроется фундаментальная ошибка.

Это история о том, почему ваш опыт ничего не значит, если вы не умеете его транслировать. Дело не в банальном умении «себя подать» (продать). Дело в том, что нужно сделать это доказательно и желательно быстро, а в GitHub за 7 лет лежит толстый слой пыли. Что показать работодателям, если все это время ты работал? Да, надо было думать раньше, но — «как на охоту, так собак кормить».

Но начнем, конечно, сначала.

Проблема: Пропасть между реальным опытом и его восприятием.

Осознаем простой факт: в современном найме на работу ваш опыт оценивают три разные группы людей, и только одна из них — технические специалисты.

Когда ты в n-й раз получаешь шаблонный отказ от HR-специалиста, ты злишься: «Они ничего не понимают в коде!». И будешь прав, но ошибёшься в другом — ты ожидаешь, что они должны понимать. Их задача иная: отсеять 95% кандидатов по косвенным признакам, чтобы техлидам остались только релевантные.
Что видит HR за 30 секунд просмотра резюме:
Несоответствие уровня и зарплаты. Например, Senior/Lead, указывающий желаемые 2000$ — сумму для Middle-разработчика. Это мгновенно создаёт подозрение в неадекватности или заниженной самооценке.
Размытое описание проектов. Фразы типа «разрабатывал архитектуру» без конкретики масштаба (MAU, количество модулей, команда) звучат пусто.
Отсутствие публичного следа. И это самая большая засада - GitHub с парой заброшенных репозиториев или без него вовсе. Это красный флаг для любого рекрутера в 2026 году.

Продолжаем наш рассказ о концептуальных отличиях цифровой фотографии и тех новшествах, что принесли нам изобретения компании Kodak во второй половине XX века. Заодно и сам Kodak вспомним.

В марте в Москве пройдет INFOSTART TEAM EVENT 2026, и организаторы уже подтвердили и одобрили доклады потока «ИТ-анализ, управление требованиями, проектирование систем». Это тот самый трек, который обычно интересует не “ради вдохновения”, а ради ответа на практические вопросы: как формулировать требования так, чтобы они выполнялись в реальных условиях, как проектировать сложные взаимодействия между системами и как ускорять изменения без потери управляемости и качества.

Если коротко, в 1С-проектах стало заметно больше “взрослой” сложности. И это не абстрактная “цифровая трансформация”, а конкретика:

Я работаю руководителем в компании НОРБИТ, и с 2005 года веду тренинги, как выступать перед коллегами и клиентами. Часто замечаю, что даже опытные докладчики совершают одну и ту же ошибку – выходят к слушателям без четкой цели: ее либо сложно отследить, либо она уходит с первого плана. И это большая проблема. 

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

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

Распределенные agile-команды стали организационным стандартом во многих отраслях прежде всего благодаря высокой эффективности разработки. При этом данный формат работы заключает в себе ряд рисков, источником которых является как лидер, так и члены команды. Среди них – утрата коллективной идентичности, размывание статуса, квазилидерство, снижение социализации, «тихий уход», работа 24/7 вместо баланса работы-личной жизни, возрастной ценз. Управление данными рисками возможно благодаря интеграции ценностей и достижений предыдущих уровней организационного развития.

Продолжаем разговор про АСУ ТП и устройство котельной, начатый в прошлой статье. Сегодня поговорим про программное обеспечение (ПО), которое ей управляет.

Конец 18-го века. Вы — купец из провинциального городка. Торгуете пшеницей и кожей. Всё хорошо, но, чтобы развернуться по-настоящему, нужны деньги. Желательно в обозримом будущем, а не когда-нибудь там, после продажи товара.

Вы идёте за кредитом, и тут начинается самое интересное.

Дворянину, как правило, выдавали деньги из государственного фонда. Купцу — нет, отправляли      к ростовщикам, те возьмут 10–12%, а то и все 20. При такой ставке значительная часть прибыли уходит на обслуживание долга, а не на развитие бизнеса.

Так выглядела финансовая реальность для большинства торговцев и ремесленников. Формально торговля поощрялась, но доступных кредитов не существовало. Альтернатива появилась не сразу. Её создал парень из семьи государственных крестьян.

Правда, сначала ему пришлось заработать миллионы.

Эрику Барони было 25 лет, когда он начал писать код. Юноша уже год как окончил университет, но степень по информатике никак не помогала ему найти работу — компании не бывают заинтересованы в кандидатах без опыта. Тогда Эрик решил попрактиковаться в программировании на C# и разработать проект для своего портфолио.
 
Оставалось понять, за что бы взяться? А с детства Барони был фанатом игр Harvest Moon (теперь называется Story of Seasons), которые можно описать как «RPG о сельской жизни». У него появилась идея создать свою альтернативу любимой игре, дополнив и улучшив её так, как ему всегда хотелось. Работа над Stardew Valley заняла четыре года (и почти всё это время будущего гения содержала его девушка, которая работала на двух работах, вот так она в него верила!).  

Симулятор жизни на ферме Stardew Valley разошёлся тиражом в миллион копий всего за два месяца после выхода и был номинирован на премию The Game Awards 2016 в категории «Лучшая независимая игра». Игроки полюбили его за особую атмосферу и разнообразие геймплея. Давайте посмотрим, как Барони удалось сделать такой проект в одиночку.