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

Когда только начинаешь разрабатывать под Android, самые неприятные баги появляются не из-за опечаток, а из-за систематических ошибок. Хардкод строк и цветов, корутины, которые живут сами по себе, попытки писать Compose по старинке, как старые view — всё это превращается в технический долг, который мешает развивать продукт. 

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

Привет, Хабр! Если вы работаете с Python дольше пары недель, вы наверняка сталкивались с конструкцией, начинающейся с символа @. Это декораторы — мощный инструмент, который делает код чище, читабельнее и соответствует принципу DRY (Don't Repeat Yourself). Но за элегантным синтаксисом скрывается несколько ключевых концепций языка, которые важно понимать.

Мультимодальные модели блестяще «понимают» сцены, но промахиваются там, где тестировщику важно точное соответствие: в сравнении двух версий одного экрана. Случайный сдвиг на несколько пикселей ломает пиксельные diff’ы и маскирует реальные проблемы — вроде исчезнувшей кнопки. Разбираем, почему так происходит, как компенсировать искажения многоуровневым сопоставлением и как простая CNN по окнам 9×9 помогает выявлять именно релевантные отличия.

Привет, Хабр! Часто ли Вы сталкиваетесь с необходимостью искать в закладках/заметках "ту самую" важную, но редко необходимую команду? git log, который Вы не использовали полгода или спасительный docker compose с десятком флагов. Нередко подобный поиск превращается в пятиминутный квест.

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

Хотел бы поделиться еще одной историей сборки домашнего сетевого хранилища (NAS). Мысли о сборке в голове крутились последние пару лет, однако останавливало отсутствие знаний, опыта, да и вообще некоторый страх — никогда дел не имел с подобным оборудованием. Поэтому и хочется поделиться опытом для таких как я — ничего страшного в подобной сборке нет.

С подключением, хабровчане! Меня зовут Роман Волков, я Senior DevOps в MТС Web Services. Кроме своей основной деятельности в роли инженера, я провожу собеседования и всегда задаю вопросы кандидатам о том, как они видят пользу, которую их роль приносит бизнесу, как могут оценить свою деятельность, какой у них метод ведения работы. Как многие, я читаю профильные чаты, тематические ресурсы. И... кажется, в ИТ‑сообществе до сих пор бытует мнение, что DevOps и Sre — это следующие этапы развития системного администратора.

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

Ситуацию можно сравнить с подбором стоматолога по навыку работы специалиста с бормашиной. В такой клинике у вас высокий шанс попасть как к ювелиру, так и к мастеру маникюра.

ИИ всё чаще обещает «заменить дизайнеров». Я решила проверить, насколько это правда. Не на красивых лендингах, а на честных B2B‑интерфейсах, где таблицы, фильтры и кнопки, а не эмоции и котики.

Взяла три инструмента Wireframe Designer, UX Pilot и Uizard и дала им одинаковый промт: создать страницу контрактного модуля для выдуманной корпоративной системы. Сравнила, кто из них действительно понимает, что такое интерфейс, а кто просто красиво рисует прямоугольники.

В начале 90-х Всемирная паутина (World Wide Web) вовсе не была единоличным хозяином сети. У неё был серьезный конкурент — протокол Gopher. Как изменилась бы наша цифровая реальность, если бы в конечном счёте он не утратил популярность? В статье расскажу, что такое Gopher, почему он уступил WWW, и каким мог бы стать современный интернет, если бы он развивался на базе этого протокола.

За счет того, что владелец бизнеса часто не разбирается в маркетинге — маркетолог может «играть» с любыми цифрами; показать низкий CPC, рост лайков или «100 тыс. охвата», — и при этом бизнес всё равно будет в минусе. Чтобы не дать себя обмануть, предпринимателю достаточно разбираться в нескольких ключевых показателях и задать 10 коротких вопросов подрядчику, которые дают четкое понимание что считать и как.

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

Привет, Хабр! Сегодня расскажу, как по-разному используют CRM в финтехе на российском рынке и в Юго-Восточной Азии. В статье я разберу четыре основных различия двух рынков и как адаптировать CRM под азиатский рынок.

Можно ли создать гармоничную экосистему взаимодействия внутри проектной команды, когда слова «гармония» и «проект» это разнопланетные категории? Меня зовут Индира, я администратор IT-проектов, и в этой статье хочу поделиться своим опытом, наблюдениями и выводами о том, как найти гармоничный подход к каждому члену в команде.

Думаю, вам начинают надоедать тексты про вайб-кодинг. Но не волнуйтесь, мой интерес не в том, чтобы рассказывать о новых невероятных достижениях, меняющих мир, и бла-бла-бла... Интереснее поискать места, в которых начинается сбой при генерации кода. Это позволит адаптировать работу статических анализаторов для новых задач контроля кода, который создаётся с помощью таких систем.

В статье приведён алгоритм вычисления характеристик вращения Вигнера с использованием кватернионной алгебры.

Недавно я перенёс Intlayer (решение для i18n) — монорепозиторий, состоящий из нескольких приложений (Next.js, Vite, React, design-system и т. д.) — с pnpm на Bun.

Кратко (TL;DR): если бы я знал заранее, я бы, вероятно, не делал этого.
Я думал, что это займёт пару часов. В итоге ушло около 20 часов.

Меня привлекло обещание «всё в одном» и впечатляющие показатели производительности.
Я попробовал, я собрал — всё билдилось молниеносно, круто.
Затем я сделал коммит… и столкнулся с первой проблемой.

Если посмотреть на ведущие промышленные компании — от машиностроения до нефтегаза, — становится ясно: многие из них давно и плотно занимаются разработкой собственных, внутренних стандартов по АСУТП. Это не просто свод общих правил. Речь идет о детальных регламентах, которые покрывают все: от проектирования архитектуры и выбора ПО до конкретных требований к интерфейсам операторов, промышленной безопасности и дальнейшему сопровождению систем.

Главная особенность этих документов в том, что они — не сухая адаптация норм вроде ГОСТ или МЭК. Это, скорее, живые и практические руководства, которые инженеры компаний буквально «выстрадали» на собственном опыте. Они рождаются из реальных проектов, учебы на ошибках и направлены на решение конкретных задач, а не на соответствие абстрактным нормативам.

Что это дает на практике? Эффект от внедрения таких стандартов — вполне измерим. Это не просто «для галочки». Компании получают реальные результаты:

Кажется, что РЖД — это такой «вечный двигатель», вне кризиса и перемен.

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

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

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

- Data Scientist — для создания прототипов моделей машинного обучения, подходящих по задачи вашего проекта;

- ML Engineer — для внедрения в эксплуатацию моделей и сценариев, масштабирования;

- Data Engineer — для создания ETL‑процессов, систематизации сбора и хранения данных;

- DevOps/MLOps — для автоматизации процессов и развития инфраструктуры;

- SRE — для обеспечения мониторинга и надёжности вашей инфраструктуры.

Организовать работу всех направлений с нуля будет задачей не из лёгких. Но как принять этот вызов, если вы не обладаете экспертизой во всех направлениях?

Привет! Меня зовут Тимофей, я продуктовый дизайнер в Альфа-Банке. Бывают ситуации, когда спроектировал сценарий и думаешь, точно ли всё ок, уверен ли я, что пользователи воспринимают дизайн так, как мы задумывали?

В статье пошагово рассмотрим как можно быстро протестировать интерфейс и иначе посмотреть на свои идеальные макеты.

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

Меня всё также зовут Андрей Гринблат, и в первой части я начал рассказывать о такой технологии, как ray marching, и о нормированных пространствах. В этой части начнём с построения простых геометрических фракталов — губки Менгера и тетраэдра Серпинского, затем построим IFS-фракталы, рассмотрим технику орбитальных ловушек, и в завершение построим фрактал «Ящик Мандельброта», или Мандельбокс.

За последние ~5 лет я много раз сталкивался с задачей собирать логи: обычно из маленьких или средних по размеру кодовой базы проектов. Отправлять логи из кода не проблема, у Java и Go для этого есть библиотеки практически из коробки. А вот разворачивать что-то для их сбора — головняк. Понятно, что решаемый (ещё до ChatGPT, а сейчас так тем более), но всё же. Все системы логов, прежде всего, ориентированы на большой-большой enterprise мир и его требования, а не на простых смертных с несколькими палками, клеем и дедлайном "вчера".

Запуск ELK для меня каждый раз испытание: куча настроек, нетривиальный деплой, а при заходе в UI разбегаются глаза от вкладок. С Loki и Graylog — немного проще, но всё равно функций сильно больше, чем мне нужно. При этом разделять логи между проектами, добавлять других пользователей в систему так, чтобы они не видели лишнего — тоже не самый очевидный процесс.

Поэтому примерно год назад я решил, что сделаю свою систему для сбора логов для себя: максимально простую в использовании и запуске. Чтобы разворачивалась на сервере одной командой, вообще без настроек и без лишних вкладок в интерфейсе. Собственно, так появился и теперь вышел в open source Log Bull: система для сбора логов для разработчиков с проектами middle-sized размера.