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

Летом рабочий ритм часто становится спокойнее: часть коллег уходит в отпуск, а запуск новых проектов откладывается до осени. Это подходящее время, чтобы закрыть пробелы в знаниях, освоить новый инструмент или подготовиться к более сложным задачам.

Собрали шесть программ для разработчиков, архитекторов, администраторов и тестировщиков, которые стартуют в июле, августе и начале сентября...

Есть паттерн, который я вижу почти в каждом кластере, куда прихожу: liveness-проба, скопированная из туториала, которая годами тихо делает продакшен хуже. Не «не помогает» — именно делает хуже: превращает локальные замедления в каскадные рестарты и красивые инциденты на ровном месте.

Тезис статьи простой: liveness-проба — это не «проверка здоровья». Это заявление «если этот запрос не ответил — процесс нужно убить». И в большинстве конфигураций, которые я встречал, это заявление ложно.

Еще несколько лет назад цифровая информационная модель воспринималась преимущественно как инструмент проектировщиков и строителей. После ввода объекта в эксплуатацию модель зачастую теряла актуальность и превращалась в архивный материал. Сегодня ситуация постепенно меняется. Все больше собственников и эксплуатирующих организаций рассматривают ЦИМ как основу для управления объектом недвижимости на протяжении всего жизненного цикла.

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

10 новых российских продуктов для совместной работы с данными, автоматизации работы юристов, внедрения ИИ в отделы снабжения, корпоративных коммуникации, отслеживания привычек и многого другого. Битва за «Продукт недели» началась!

Product Radar — здесь каждую неделю публикуются лучшие онлайн-сервисы и железки от русскоязычных команд.

Вторая статья из цикла «Аналитик в чужом процессе»

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

ИИ увеличивает продуктивность разработчиков на 55% — по крайней мере, к такому выводу пришли в этом исследовании.

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

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

Mermaid это текстовый формат описания диаграмм. В строках задаются тип схемы, узлы и связи. На выходе получается SVG. Формат подходит для API и базы данных. Код можно сгенерировать, проверить, сохранить, открыть повторно и отрендерить на клиенте.

В mermind/views.py добавлен 503, если ответ модели не начинается с валидной головы Mermaid. Без этой проверки запрос завершается успешно, ответ от модели приходит, но диаграмма не строится. В ответе остаются fenced-блоки, Markdown, строки с #, служебный текст и фрагменты до первой строки диаграммы.

В проекте собран полный серверный и клиентский контур. Генерация, очистка ответа, проверка, рендер, повторная правка, сохранение и библиотека.

Как извлекать Mermaid-код из ответа модели. Ответ сначала режется до fenced-блока. Потом проверяется первая строка.

Давайте признаем: сегодня (особенно после ухода Джобса) технологические презентации выглядят как тоска смертная. На сцену выходит CEO, показывает несколько слайдов про то, как «ИИ» всех спасет, демонстрирует пару новых функций, обещает революцию — и через неделю все об этом забывают. А вот всего полвека назад будущее не анонсировали на словах — его строили в натуральную величину. 

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

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

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

Большинство способов интеграции самодельных устройств умного дома с Алисой требуют Wi-Fi, облачного сервера или MQTT. Но существует гораздо более простой способ — использовать обучаемый ИК-пульт Яндекса как шлюз между голосовым помощником и собственной сетью устройств. Именно такой вариант я сделал ещё в 2017 году, и он работает до сих пор.

Эта статья изначально была написана как комментарий к переводу от Анатолия Ализара "Ненависть к ИИ", но в какой-то момент я понял, что для комментария информации слишком много, и решил поделиться своим опытом общения с "близняшками" в отдельной статье.

Пока одни ненавидят ИИ в целом и все его проявления в частности, другие начинают его использовать, и не только в работе. Близняшкам можно поручать задачи, упрощающие бумажную работу. Можно попросить преобразовать найденную информацию в тот или иной формат (хочешь – представить в виде таблицы, хочешь – преобразовать в json). Можно попросить сделать тест по теме и протестировать твои знания. Можно… много чего можно, а вот что именно – и, что самое главное, хорошо ли это получится у близняшек, можно узнать, прочитав эту статью.

Попробуем использовать инфраструктуру MAX в качестве халявного фотохостинга. Задача, конечно, учебная; в этот раз освоим приём апдейтов методом long polling и их базовую обработку.

Как устроен KalinkaPlayer: модульный бэкенд, нативный аудиоплеер, пайплайн метаданных и мобильное управление в одном проекте.

На текущий момент можно считать, что не имеется некоммерческих библиотек или компонентов, позволяющих создать качественный gRPC-клиент (автор, конечно же, в курсе про «DelphiGrpc», но в нынешнем виде полагает её малопригодной для практического использования – хотя бы из-за устаревших версий зависимостей); во многом остроту данной проблемы снимают платные решения – давно существующий компонент TipwGRPC, а также относительно недавно появившийся TsgcGRPCClient. В связи с этим, если по каким-то причинам применение коммерческих вариантов невозможно, то потребуется реализовать указанный клиент своими силами, для чего в статье рассмотрен лишь начальный (но довольно-таки важный) этап разработки: а как, собственно говоря, использующий клиент станет вызывать gRPC-методы – посредством каких функций или процедур, какие параметры они будут требовать, и далее в таком духе? В грубом приближении, что должно быть в этом прототипе вместо многоточий?

function CallMethod(...): ...;

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

Также хочется проговорить явно, чтобы читатель не имел ложных надежд, – материал совершенно не содержит ответа на вопрос «как», тут только предложен вариант программного интерфейса к gRPC-клиенту (весьма подробно, однако, расписанный).

Сейчас часто можно услышать мнение, что LLM и AI-агенты способны значительно снизить стоимость разработки. Вместо того чтобы расширять команду, достаточно дать задачу модели, и она выполнит работу за минуты.

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

Мы привыкли считать Солнце символом постоянства, как часть природы, как часть всего, что нас окружает: то, что мы знаем, сколько помним себя — как горы и океаны, как Луну и облака. Мы слишком легко забываем, что у звёзд своя жизнь и своя судьба: они так же рождаются, живут и умирают, как человек. И совсем мало кто знает, что Солнце, которое мы встречаем каждое утро и под лучами которого проживаем очередной день — беглец. Оно родилось в центральном районе Галактики и сбежало оттуда, как дети иногда сбегают из родного дома.

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

Cursor опубликовала результаты эксперимента со вторым поколением своего "роя агентов" — системы, в которой сотни ИИ-агентов параллельно работают над одной кодовой базой. Задача — реализовать на Rust движок базы данных по 835-страничной документации SQLite. Без исходников, без готовых тестов, без бинарника оригинала и без доступа в интернет. Самая дешевая связка моделей уложилась в счет $1339 за четырехчасовой прогон. Главная находка — экономическая: та же задача с теми же моделями в других конфигурациях стоила до $10 565, и всю разницу сделала организация работы.

О странствующих словах я впервые задумался, когда сам странствовал по Индии. Ранним утром в колоритном индийском поезде проснулся от громкого возгласа зашедшего на остановке продавца: «Ча́е!» Разбудило вовсе не то, как он во всё горло рекламировал свой товар характерным проникающим тембром. Спросонья я попросту потерялся в пространстве, услышав знакомое слово. Как у Маршака: «Это что за остановка — Бологое иль Поповка?» Я выглянул с полки и увидел индийца, несущего через вагон огромный бидон чёрного чая. То был первый случай, когда удалось понять услышанное индийское слово без посторонней помощи (и это слово не означало «такси»).

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

Материал будет интересен всем, кто любит языки, историю слов и наглядную визуализацию данных.

Семнадцать лет назад Брэндон Шеффилд собрал на Gamasutra классическую подборку "Dirty Coding Tricks" (http://www.gamasutra.com/view/feature/132500/dirty_coding_tricks.php), перевод на Хабре тут, и "Developers share their most memorable dirty coding tricks"(https://www.gamedeveloper.com/programming/developers-share-their-most-memorable-dirty-coding-tricks) где были камера, повёрнутая на 90 градусов вместо починки рендера, пробел, добавленный в код ради совпадения контрольной суммы, и два мегабайта памяти, спрятанные "на чёрный день", чтобы торжественно достать их за неделю до сдачи.

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

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

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

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

Встретились как-то nRF52840, OLED дисплей, аккумулятор от электронной сигареты, ДР жены и фрезеровщик. Ну и понеслось...