Kurgan-Telecom Ru | Информационные технологии

20 января разработчик Саймон Йозефссон опубликовал в рассылке oss-sec информацию о крайне серьезной уязвимости в демоне telnetd, реализующем удаленное подключение по протоколу telnet. В традиционной для описания уязвимости терминологии суть проблемы заключается в следующем: «ошибка в обработке входящих данных позволяет злоумышленнику пропустить процесс аутентификации и получить на подверженной уязвимости системе права суперпользователя».

Применение таких терминов обычно обозначает, что подлинное описание проблемы либо слишком длинное, либо слишком сложное для понимания, но в данном случае это не так. При подключении к telnetd нужно указать имя пользователя. Его программа передает стандартной утилите login, причем передача осуществляется без предварительной проверки ввода от желающего подключиться. Если указать вместо имени пользователя строку «-f root», эти данные будут переданы в утилиту login, а она уже залогинит любого желающего под рутом без какой-либо авторизации, увидев соответствующий ключ -f. Собственно, это вся уязвимость как есть.

После достаточно долгого использования ИИ наступает момент, который невозможно не узнать.

Появляется ошибка — ничего катастрофического, но странная. Периодическая. Такая, которая не сразу проявляется в логах. Начинаешь отладку, и где-то через два часа понимаешь: раньше на это уходило двадцать минут.

Музыканты называют это «отпускными руками» (руки, отдыхающие от работы). Две недели без фортепиано, и Шопен звучит иначе. Не совсем неиграбельно — просто медленнее.

Авиационные исследователи изучают это явление десятилетиями. Анализ FAA 2011 года показал, что 60% аварий были связаны с недостаточной квалификацией пилотов в ручном пилотировании (навыки, которые атрофировались из-за зависимости от автопилота). Они дали этому клиническое название: деградация навыков, вызванная автоматизацией.

В разработке программного обеспечения пока нет названия для этого явления. Но закономерность знакома.

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

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

Умные часы за последние десять лет сильно изменились. От обычных гаджетов для уведомлений они превратились в мини-компьютеры с яркими экранами, множеством сенсоров и привязкой к облачным сервисам. Цена этого прогресса — слабая автономность и почти полный контроль со стороны производителей. На этом фоне возвращение 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 вместо баланса работы/личной жизни. Управление данными рисками возможно благодаря тому, что распределенные agile-команды стали в свое время одной из «первых ласточек» шестого технологического уклада, или "желтого" уровня развития организаций, согласно теории "спиральной динамики". Интеграция ценностей и достижений предыдущих уровней позволяет сосредоточиться на вызовах ИИ-эпохи, сохраняя смелость, коллективные смыслы, эффективность и человеческую теплоту.