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

В комментариях к статьям всё чаще всплывает спор: использование LLM — это обман или нормальный инструмент автора?

Кстати, многие из этих авторов начинали писать ещё до появления нейросетей, мессенджеров и соцсетей. Они учились разбираться в теме, писать, редактировать, попадать в тон. Серьёзно ли считать, что использование LLM автоматически означает, будто автор перестал разбираться в теме?

В этой статье я хотел бы рассмотреть микросервисные паттерны под другим углом. Когда я начинал изучение микросервисных паттернов, у меня постоянно был вопрос: Так это же было в другом паттерне. Я решил немного структурировать их: объединить по похожим элементам. Кластеризировать микросервисные паттерны достаточно тяжело так как каждый паттерн по‑своему уникален, однако для запоминания на собеседованиях или для себя это сделать можно. Основной контент статьи — картинка, далее идёт описание, чтобы всё было в одном месте.

Эта статья предназначена для более быстрого запоминания/повторения паттернов микросервисов. Кое‑где я приводил кейсы, которые могут быть непонятны новичкам. Здесь нет подробных кейсов применения каждого паттерна так как иначе статья получилась бы на другую тему. Для удобства я приложил ссылки — чтобы избежать дублей.

Как сделать свой аналог Pinterest, если у вас нет бюджета корпорации, но есть 4 ТБ картинок (17 миллионов штук) и желание искать по ним не просто по тегам, а по визуальному стилю?

В статье — опыт построения распределенной системы поиска из подручных средств. Разбираем архитектуру: — Гибридное хранение: Backblaze B2 (холодное) + Домашний сервер (вычисления). — Сеть: Как ZeroTier объединил разрозненные ноды в одну Mesh-сеть без белых IP. — Векторный поиск: Как уместить 17 миллионов векторов OpenCLIP ViT-H/14 в 32 ГБ RAM с помощью Qdrant и квантизации. — Оптимизация: Почему поиск работает за 5 мс, а загрузка метаданных тормозила до 3 секунд, и как PostgreSQL спас ситуацию.

Полный разбор ETL-пайплайна и экономики домашнего HighLoad-проекта.

В некоторых условиях в целях безопасности нельзя допустить подключение устройств по беспроводной связи. Например, на предприятиях, где высок риск утечки информации. Или чтобы гарантированно погасить следящие маячки типа Airtag вокруг себя. В таких ситуациях по специальному разрешению соответствующих органов используют подавители радиосигналов, в том числе Bluetooth/BLE и Wi-Fi.

В образовательном проекте ESP32-BlueJammer на Github можно ознакомиться с устройством, которое гасит любой полезный сигнал в диапазоне около 2,4 ГГц с помощью генерации шума и бесполезных пакетов (DoS-атака).

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

Микроконтроллеры серии TMS320C28xx (C2000) от Texas Instruments появились достаточно давно, однако до сих пор остаются актуальными в ряде задач.

Эти микроконтроллеры отличаются надёжностью, обладают значительным объёмом оперативной памяти, поддерживают операции с числами с плавающей точкой (float/double) на аппаратном уровне, а также оснащены одними из лучших в своём классе модулями ШИМ (PWM) и АЦП (ADC). При этом их стоимость остаётся весьма демократичной.

В этой статье я расскажу об особенностях работы с данными микроконтроллерами.

Всем привет! Меня зовут Дмитрий Листвин, я занимаюсь аналитическим хранилищем данных в Авито.

В этой статье я собрал наш опыт построения Lakehouse поверх объектного хранилища, как реальная аналитическая нагрузка быстро превращает «обычный S3» в самый капризный элемент всей архитектуры. Будет много про извлечение максимума производительности из Ceph: как добиться высокой пропускной способности HDD, когда поверх данных хочется запускать тяжёлые аналитические запросы.

Это первая статья о том, как идея проходит путь от прототипа до полноценного продукта — с участием архитектуры на каждом шагу. Формат — ADR (Architecture Decision Records): каждое решение зафиксировано по дням, чтобы показать реальную эволюцию проекта. Продукт вымышленный, проблемы — настоящие. Те самые, с которыми сталкиваются архитекторы и команды. Документация и код — в открытом доступе на GitHub.

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

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

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

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

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

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

Информационный парадокс чёрных дыр обычно формулируется как вопрос о том, куда исчезает информация при коллапсе материи и последующем испарении дыры. В этой статье предлагается другой взгляд на проблему: возможно, информация никуда не обязана «возвращаться», потому что она и не покидает внешнюю Вселенную. Рассматривается интерпретационная унитарная модель, в которой структурная информация о падающем объекте формируется в виде распределённого квантового следа во внешней среде ещё до образования горизонта событий, тогда как излучение Хокинга возвращает лишь энергию. Такой подход позволяет по-новому взглянуть на парадокс, не нарушая унитарности и не вводя дополнительных физических сущностей.

IT-специалистам на заводах РФ посвящается. Создаю контраст в противопоставление статьям Сибура про работу в IT на заводах

Эти станции так и не стали лицом Московского метрополитена. Подземка 90-х, лужковское метро – о нём не пишут в путеводителях, по нему не водят экскурсии. И зря! Рождённая на переломе эпох Люблинская линия сполна хлебнула хаоса, безденежья, безнадёги… и настоящего героизма, о котором тоже не вспоминают. А ещё архитектурных и технологических новшеств. Тридцать лет назад, когда о будущем думать было страшно, «салатовая ветка» предвосхитила будущее столичной подземки – частью ставшее её настоящим, а частью, увы, тоже забытое.

Привет, Хабр! Меня зовут Андрей Слесаренко — frontend‑разработчик с опытом работы более 8 лет. Прошёл путь от джуна до тимлида, работал над разными высоко‑нагруженными проектами. В начале этого года начал активно использовать LLM‑агентов в повседневной работе — и за это время набил немало шишек.

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

Когда сервер завис или система не грузится, обычный удалённый доступ уже бесполезен. Нужен способ увидеть, что происходит прямо «на экране» машины, и управлять ею, будто сидишь перед ней с клавиатурой и мышью. Для этого и существует IP-KVM — коробочка, которая передаёт видео и управление компьютером по сети.

Sipeed делает свою версию такого устройства — компактную, открытую и недорогую. Она позволяет подключиться к компьютеру или серверу, даже если тот не загружается в операционную систему, и полностью им управлять, например, войти в BIOS, установить систему или просто перезапустить. По сути, это свой iLO или iDRAC, только без лишнего корпоративного веса и по доступной цене.

Dependency Injection (DI) — это популярный механизм внедрения зависимостей, который идеально соответствует принципам SOLID (Dependency Inversion Principle). В .NET использование DI (Microsoft.Extensions.DependencyInjection) стало стандартом де-факто.

Однако у DI есть важный недостаток: при создании корневого объекта (например, контроллера) контейнер резолвит всё дерево зависимостей, что плохо для памяти и производительности.

Решение - использование DI с Lazy<T> — ленивая инициализация зависимостей.

Проведенные исследования показывают, что во время создания ИТ-продуктов могут материализоваться 105 универсальных рисков. Также было обнаружено, что одним из критериев зрелости ИТ-субъекта является наличие результативных и эффективных мер превентивного воздействия на данные риски. Цель: проведение анализа ранее выявленных универсальных рисков, возникающих во время создания ИТ-продуктов в рамках выполнения спринтов, фаз жизненного цикла ИТ-проектов и (или) контрактов. Методы: теория управления рисками и ИТ-проектами. Анализ универсальных рисков был осуществлен с помощью методов 5W, SWIFT и коэффициентов Харрингтона. Результаты: ИТ-субъект должен заблаговременно, до заключения контракта, проводить экспресс-оценку универсальных рисков и превентивно воздействовать на них, в том числе за счет формализации в тексте контракта действий и (или) бездействий, которые должны выполнять заинтересованные стороны для элиминирования наиболее опасных рисков. Также были разработаны схемы причинно-следственных связей универсальных комплаенс- и проектных рисков, что позволило выявить часто встречаемые и наиболее опасные рисковые события. Благодаря созданным схемам был идентифицирован негативный сценарий, который продемонстрировал наихудший вариант развития событий во время выполнения ИТ-проектов. Данный сценарий дает возможность ИТ-субъектам заблаговременно разрабатывать меры «достойного» принятия рисков, не допуская наступления наиболее радикального исхода.

NAS Колхозника-1Сника на базе Turbo Селерона N150 и под управлением MS Server 2019 в компактном корпусе и с надеждой на надежность.

Последний дайджест в этому году! От неработающей к тестируемой навигации, тепловизор для разработчика, развитие Swift SDK для Android, инженерия уверенности и многое другое. С наступающим и хороших вам приложений! До встречи в новом году!

В начале декабря я публиковал статью про Postgresus 2.0 — инструмент для резервного копирования PostgreSQL. С момента этой статьи пришло много запросов на добавление других баз данных, много положительной обратной связи от пользователей и набралось больше 1000 звёзд на GitHub.

А потом я узнал, что нарушил торговый знак

Раньше в резюме строчка Уверенный пользователь MS Office (Word, Excel) была обязательна, так же как стрессоустойчивость, коммуникабельность, работа в команде.

Думаю, теперь обязательной строкой станет:

«Уверенный пользователь AI. Problem decomposition, structured prompting, critical evaluation of AI outputs, code and workflow automation.»

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

И в будущем это еще сильнее будет бросаться в глаза