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

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

Естественно, можно спроектировать базу данных, вообще не заботясь ни о каких правилах. И она даже будет работать! Все будет прекрасно ровно до первого ее реального использования в продакшене. При проектировании «абы-как» возникают три типовые проблемы: избыточность, аномалии обновления, аномалии удаления.

И вот это уже плохо.

Как понять, кого действительно стоит повышать, кого — переставлять, а кого — выводить из системы, не разрушая работу отдела.

Как сделать адаптацию не просто формальностью, а эффективным, комфортным и полезным процессом — для новичка, команды, проекта и всей компании?

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

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

Привет, Хабр! Я Мария Пуха, основательница агентства для ИТ AggreMarketing. В своей практике я часто сталкиваюсь с тем, что партнерский канал для некоторых вендоров — скорее идея, чем работающий источник продаж. Дело не в том, что продукт недостаточно хорош. Сам канал требует отдельной «сборки»: правильная экономика, стратегия и тактика работы с партнерами и заказчиками. В статье разбираю простых пять шагов, которые помогут выстроить рабочую модель канальных продаж.

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

Меня зовут Герман, я 8 лет занимаюсь B2B‑продуктами и сложными производственными системами.

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

Привет, меня зовут Сергей Лавров, я руководитель мобильной разработки. За последние 10 лет довелось примерить много ролей: от Android- и iOS-разработчика до технического руководителя и руководителя команды, от фрилансера и стартапера до бизнесмена, «минус-миллионера» и филантропа. По роду деятельности постоянно приходилось участвовать в созвонах и встречах, фиксировать договоренности или, если никто не записывал, что-то важное забывать.

Недавно коллеги предложили попробовать MWS TeamStream. Я тогда подумал: очередной клон Zoom или простая простая программа записи экрана. Было совершенно непонятно, чем это поможет в работе. Чтобы разобраться, попросил организовать интервью с руководителем продукта и подробнее узнать, что это такое и в чем его ценность. С этой беседы я вышел с одной мыслью: «А что, так можно было?..» Но обо всем по порядку.

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

Результат: говорю агенту «закажи самую сытную пиццу и колу» — и получаю заказ #177 за 534 рубля. Оплата с привязанной карты, самовывоз из ближайшей пиццерии. Пицца готовится, пора идти забирать.

В этой статье хотелось бы начать раскрытие больной для многих пользователей Apache Superset темы — фильтры по дате. Начнем с малого: как суперсет выбирает колонку даты; как выбрать желаемую колонку вместо той, которую он выбирает; каким образом это реализовано; какие баги породили этим решением; почему КОП не доведет до добра.

Хакатон глазами веб-разработчика: лонгстори про Пуффендуй, градиентный ад и смена приоритетов

Как я попал в магическую тематику, где сходу пришлось гадать коллег по переписке и выбивать задачи через квест с патронусами. Главный челлендж — в соло запилить на веб фичу «Топ-10» с неверстабельным свечением из тысячи градиентов и стеклянными цифрами. Спойлер: градиенты победили, но тайм-менеджмент спас ситуацию. Драйвово, местами стрессово, но точно мемно.

TL;DR перевода статьи Boris Tane: SDLC is dead.

SDLC больше нет. AI-агенты не ускорили привычный жизненный цикл разработки, они его схлопнули.

- Agile-ритуалы мертвы. Планирование спринтов, оценки в story points, релизные поезда и многодневные ожидания аппрувов в PR — всё это пережитки прошлого.

- Все этапы слились воедино. Сбор требований, system design, написание кода и тестов происходят одновременно — в реальном времени и в диалоге с агентом.

- Code Review — это новый луддизм. Машина генерирует 500 PR в день, человек физически не может их проверить. Код должен лететь прямо в main под прикрытием автотестов, feature flags и хорошо настроенного observability.

Новый жизненный цикл — это узкая петля: Intent (Намерение) → Build (Создание) → Observe (Наблюдение).

В настоящее время у нас в стране реализуется совсем мало значительных и наукоемких проектов. Не на чем поучиться и подсмотреть практику управления.
Раз нет современных примеров, то обратимся в глубины истории.
В истории нашей страны был период активного роста и развития не благодаря, а вопреки. В стране после сильнейшего потрясения Великой Отечественной Войной героическим трудом наших прадедушек и прабабушек возрождалась промышленность и реализовывались самые смелые проекты. Посмотрим, как они справлялись не имея сертификатов PMBoK.

С чего начинается проект?
Определение бизнес-потребности: Анализ проблемы или возможности, ради которой запускается проект.

В 40-50е годы США разрабатывали ряд проектов по уничтожению СССР ядерным оружием:

Спидкубинг – сборка кубика Рубика и других головоломок на скорость – уже давно перестал быть просто хобби и превратился в глобальное интеллектуальное соревновательное движение. С 2003 года по всему миру проводятся турниры под эгидой Всемирной ассоциации кубика (World Cube Association – WCA), формируя единую систему правил, рейтингов и мировых рекордов. На март 2026 года количество уникальных участников (людей, которые хотя бы один раз выступали на официальных соревнованиях WCA) – более 282 000 человек из более чем 150 стран мира, а количество проведенных официальных соревнований – более 16 600. Причем за последние полгода добавилось порядка 15 000 новых участников и проведено боле 2 500 соревнований.

На этом фоне в среде спидкуберов всё чаще появляются разговоры о признании спидкубинга полноценным видом спорта и даже о его потенциальном включении в олимпийскую программу в будущем. С 2023 года WCA активно адаптирует свои правила под стандарты МОК с целью получения статуса IOC-recognized international sports federation. Делается это для расширения возможностей фандрайзинга, большей легитимности, запуска антидопинговых программ и т.д. Но до включения в программу Олимпиад, все же, еще очень далеко.

Сегодня расскажу об опыте Китая, который пошел по более прагматичному и централизованному пути. Спидкубинг в Поднебесной не только стремительно развивается, но и уже получил официальный статус спортивной дисциплины. Более того, в стране реализуется стратегия развития спидкубинга, предполагающая рост аудитории до 12 миллионов занимающихся к 2028 году.

Как Китай продвигает спидкубинг на государственном уровне, и чем этот опыт может быть интересен России – обсудим далее.

В последнее время слово «инженер» мало употребляется в IT-индустрии. Есть программист, разработчик ПО, техлид, архитектор. Но одно только знание технологий не дает гарантии, что человек хорошо выполнит бизнес-задачу. Инженерное мышление — это особый дар, который позволяет решить сложную, возможно, даже ранее не решенную проблему с использованием существующих технологий.     

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

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

До 2007 года установка двух версий одной библиотеки на одном сервере была невозможной миссией. Появление virtualenv, а затем и нативного venv, изменило ландшафт Python-разработки навсегда. Но как именно работает этот механизм на уровне операционной системы и интерпретатора? Разбираем путь от копирования бинарников до современных симлинков, анализируем роль sys.path и реализуем собственный аналог venv.

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

Сколько FLOPS нужно для генерации одной секунды видео в реальном времени? Можно ли достичь этого на одном GPU? А на телефоне? В этой статье я разбираю задачу realtime видеогенерации «от первых принципов» — начинаю с конкретной архитектуры (Wan2.1-14B), считаю FLOPS по каждому слою, калибрую по реальным замерам и последовательно применяю оптимизации: от FlashAttention и step distillation до квантизации и новых GPU. Спойлер: на серверах realtime уже почти здесь, а вот с мобилками всё сложнее.

После «апокалипсиса SaaS» рынок впал в лихорадку. Инвесторы решили, что программное обеспечение стало практически бесплатным товаром и 90% программистов можно уволить.

Это одно из предсказуемых заблуждений, вызванных непониманием природы разработки ПО. Да, правила игры изменились, и SaaS больше не будет таким, каким был. Но ИИ его не уничтожит и не заменит разработчиков приложений.

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

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

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

Позвольте объяснить.