Все потоки

Привет! На связи Кнышенко Марина, системный аналитик Рунити. В этой статье мы попробуем сделать из UML универсальное средство общения, чтобы диаграммы помогали наладить диалог между командой и не лежали в архиве в качестве средства устрашения. Статья будет интересна системным аналитикам, которые ищут универсальные инструменты для работы и хотят настроить коннект с командой. 

UML — унифицированный язык моделирования… На втором слове коллеги заснули. На практике из академического определения можно запомнить, что UML — это язык. Язык необходим для передачи мыслей от одного человека к другому. Точно также на языке UML можно составить синтаксически верное описание системы, пустив в дело весь доступный арсенал «стрелочек» и «квадратов», но эти многоэтажные диаграммы так никто и не поймет.

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

Чтобы избежать рисков, лучше самостоятельно контролировать свою компьютерную инфраструктуру. Вот почему сейчас особенно актуален софт для «личного облака»: серверы веб-приложений на своём хостинге, полностью под контролем владельца. Одно из самых известных решений такого рода — Sandstorm, в каком-то роде аналог Google Apps, но на своём сервере.

IT менторы говорят своим ученикам подделывать документы: Паспорта РФ, выписки об опыте работы с госуслуг СТД-Р, договоры ГПХ и так далее (пруфы и скрины в статье!). Каждый 3-й крутит опыт, чтобы пройти через фильтры HR на hh.ru. Но далеко не каждый подделывает документы, что является УГОЛОВНО наказуемым...

Появилась статья, представляющая новый метод обнаружения предвзятости в алгоритмах искусственного интеллекта. Этот метод не только выявляет потенциальные 偏见 (biases), но и делает это прозрачно, используя структурированные дебаты, основанные на количественных биполярных аргументационных фреймах (QBAF). В мире, где ИИ всё глубже проникает в такие области, как здравоохранение, финансы и юстиция, борьба с предвзятостью становится критически важной задачей. Давайте разберёмся, как работает этот подход, почему он важен и как он превосходит существующие решения.

Сколько лет уже кто-то говорит: «А можно, чтобы оно работало без интернета и ставилось на домашний экран?» И каждый раз после этой фразы начинается медленный спуск в персональный ад — ты лезешь в документацию по PWA, где всё разваливается на ровном месте, service worker живёт своей жизнью, кеш то работает, то ломается, App Router рушит весь твой кастомный пайплайн, а пользователи сидят на старых версиях, потому что вручную обновлять им, конечно, влом.

Словом, если ты когда-то пробовал прикрутить оффлайн-режим к Next.js-проекту, ты наверняка вспоминал всех, кто придумал этот стек. Я — точно. Поэтому, как человек, у которого было слишком много кофе и слишком мало терпения, я сделал единственное разумное: написал свою обёртку.

Так и появился next-pwa-pack — дроп-ин пакет, который превращает любой Next.js-проект в полноценное PWA, буквально одной строкой. Да, даже с App Router. Просто заворачиваешь свой layout в PWAProvider, и всё: приложение можно установить, оно кэширует страницы, работает оффлайн, синхронизирует вкладки и даже показывает отладочную панель, чтобы не гадать, сработало ли что-нибудь. Воткнул — и живи дальше.

А то:

Сервис-воркер? Напиши вручную.
Кешировать HTML? Сам придумай как.
Синхронизация вкладок? Ну это уже магия, удачи.
Обновление кеша после деплоя? Ну ты ж senior, сам справишься. 🤡

И ты сидишь, как идиот, с 300 вкладками про Workbox, cache-first, network-only, костылями из Stack Overflow 2019 года, и потеешь.

Если раньше каждый запрос «сделай оффлайн» вызывал у меня флэшбэк на тему next-pwa, неподдерживаемых версий, кривого кеша и плясок с бубном вокруг обновлений — теперь всё это ушло. Я хотел простой setup, который просто работает: предзагрузка, нормальные TTL, понятное обновление и синхронизация. Без фокусов, без багов, без “подожди, сейчас DevTools открою”.

Привет, Хабр! Я тимлид группы разработки на BPMSoft. Не так давно мы с командой завершили четвертую профильную стажировку, и в этой статье хочется поделиться своими инструментами, наработками и полученными шишками. Возможно, она будет полезна молодым тимлидам и руководителям групп, чтобы запустить свою первую стажировку или найти новые точки роста в той, что уже организовывали.

Как создать загрузочный образ RDP-клиента для запуска USB-флешки.
Часть 1. Подготовка загрузочного образа.

Установка и настройка базовых пакетов. Настройка сетевого интерфейса, grub для работы на USB-накопителе.

Привет! Я — Александр Дудукало, автор базового курса по JavaScript. Если вы читаете эту статью, значит, вероятно, уже знакомы с одной из основных логических конструкций в JavaScript — if-else. Если нет, рекомендую сначала прочитать предыдущий материал, где я подробно разобрал эту тему.

В этой же статье мы поговорим о других способах управления логикой в коде — тернарном операторе и конструкции switch. Да, звучит сложно и, возможно, пугающе. Но я уверяю, все очень просто. В итоге вы узнаете, когда их стоит использовать и чем они могут быть полезнее привычного if-else. Поехали?

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

Это как вырваться вперёд в командной гонке: ты едешь впереди, а ветер и рассинхронизация тормозят и путают остальных. В итоге — твой отрыв не помогает, а сбивает темп всей команды.

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

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

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

Я сделал простейшую утилиту для регистрации в контейнере по атрибутам на интерфейсе\реализации. Добавил тесты а так же поддержку IServiceCollection.

Привет, Хабр! Меня зовут Назар Гельдыев, и я руковожу направлением технологического развития в телеком-блоке МТС.

В 2000-е мобильная сеть росла достаточно просто. Мы искали большой кусок незанятой территории и ставили там сплошным рядом вышки — такое «ковровое строительство» позволяло создать покрытие раньше конкурентов. Тогда каждая базовая станция окупалась почти сразу.

За последний год провёл более 60 конкурсов с помощью разных инструментов: бота с кнопкой «Участвовать», классического рандомайзера и внутреннего премиум-giveaway. На своём опыте рассказываю, как провести розыгрыш в Телеграм, что реально повышает активность и что поможет увеличить вовлечённость в несколько раз.

Кажется, что большие языковые модели просто созданы для того, чтобы работать в клиентском сервисе. Они умеют анализировать запрос, генерировать короткие и подробные ответы, структурировать и объяснять. Но в большинстве случаев мы все равно недовольны ответами чат-ботов и просим быстрее «перевести на оператора». Почему?

Я — Максим Михайлов из Cloud.ru. В серии статей попробую ответить на этот вопрос. А еще расскажу, как мы внедряем AI в клиентский сервис так, чтобы сотрудники и технологии работали в симбиозе, ответы сохраняли дружелюбие, клиенты максимально эффективно решали свои задачи и уровень удовлетворенности услугами и сервисами только возрастал.

Образовательные программы компьютерных наук и информатики обязательно включают курс алгоритмов, это элегантные решения сложных проблем. Например, одна из самых интересных проблем комбинаторной оптимизации — задача коммивояжёра (TSP, travelling salesman problem). Суть в поиске самого выгодного маршрута, проходящего через указанные точки ровно по одному разу. Сложность задачи при точном решении брутфорсом составляет O(n!). И для неё тоже придумано несколько элегантных алгоритмов. Хотя поиск самого эффективного продолжается до сих пор.

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

В предыдущей статье я разбирал некоторые нюансы Postgres, касающиеся индексов и параллельных воркеров. Текст этот вызвал достаточно оживленное обсуждение и один из комментаторов предложил значительно более эффективный индекс, нежели были рассмотрены в статье. Сравнение эксплейнов не позволяло сразу понять причины его превосходства и потребовалось дополнительное расследование

Крупные компании ежедневно генерируют, обрабатывают и хранят колоссальные объемы информации. По данным исследования IDC, корпоративный цифровой контент удваивается каждые 18–24 месяца (ссылка), а средний сотрудник тратит до 20% рабочего времени ежедневно на поиск нужной информации или коллеги, который сможет ему помочь. При этом он еще и отвлекает коллегу на решение своего вопроса. Казалось бы, в эпоху цифровизации найти нужный документ или ответ должно быть проще, чем когда-либо. Однако реальность оказывается совершенно иной.

Многие разработчики при обсуждении основ Clean Code называют одни и те же принципы — чаще всего упоминаются DRY, KISS и YAGNI. Эти концепции прочно закрепились в профессиональном сообществе и воспринимаются как обязательная часть хорошего кода.

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

Сегодня я хочу поговорить о принципе RUG и о том, какие рекомендации он даёт по написанию программного обеспечения.

RUG (Repeat Until Good) — это принцип, который говорит: можно повторять один и тот же код, пока это разумно.

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

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

Я буду использовать TypeScript, так как этот язык знаком большинству разработчиков. 😁

Рынок IT меняется с такой скоростью, что за ним иногда трудно угнаться: новые технологии, методологии, роли — всё постоянно меняется. Из-за этого границы между профессиями часто становятся размазанными. Если разработчики чётко знают свой стек, задачи и техдолг, то у дизайнеров и аналитиков всё гораздо более гибко, потому что их работа опирается на коммуникацию, логику и потребности людей. Часто дизайнеры и аналитики начинают работать вместе еще на самых ранних стадиях проекта — именно там, где чаще всего царит хаос.

И вот здесь начинается путаница. Часто не совсем ясно, кто за что отвечает. В одной команде UX-дизайнер делает всё: от сбора требований до создания прототипов, а в другой — он ждет четкого ТЗ от аналитика. И тогда возникает вопрос: где заканчивается аналитика и начинается дизайн? Давайте разберемся.

Эра искусственного интеллекта уже наступила — и люди, мягко говоря, в панике.

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

Для начала короткое описание того, что такое AI: это применение математики и программного кода для обучения компьютеров понимать, синтезировать и генерировать знания примерно так же, как это делают люди. AI — это программа, как и любая другая: она запускается, принимает входные данные, обрабатывает их и выдаёт результат. Причём output AI полезен в самых разных областях — от программирования до медицины, юриспруденции и искусства. Её владеют и контролируют люди, как и любой другой технологией.

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

И еще короче о том, чем AI может стать: способом сделать лучше всё, что нам действительно важно.