Разработка

Знаю, знаю... Прочитав заголовок, хочется голосом волка из мультфильма «Жил был пёс» сказать — «Шо, опять?». Ведь битва этих подходов давно закончилась и разработчики Spring уже поставили точку.

Но недавняя публикация в одном довольно крупном Telegram‑канале заставила меня вернуться к этому вопросу. В качестве главных аргументов против field injection там приводились лишь сложность изоляции в тестах и неудобство создания экземпляров для unit‑тестов.

И хотя с этими пунктами не поспоришь, у многих разработчиков и не только начинающих, остаются вопросы: каковы реальные последствия для самого объекта? Можно ли считать его полноценным сразу после создания new? И почему все современные рекомендации так настаивают на конструкторах?

Поиск ответов показал мне, что аргумент о тестах лишь верхушка айсберга. В глубине, куда я Вас сегодня приглашаю заглянуть, скрываются куда более фундаментальные вопросы принципов объектно‑ориентированного дизайна, гарантий Java Memory Model и уважения к жизненному циклу объекта.

Сегодня мы поговорим про такую, казалось бы, простую и привычную штуку, как функция drop в языке Rust. Что может быть банальнее?

Создали переменную, и в конце области видимости она сама очистится. RAII за нас делает всю работу, а мы просто выдыхаем и не боимся утечек памяти. Но не все так радужно!

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

Меня зовут Виталий и я пишу уже который год самую большую книгу по математике для 4–11 классов, а так же автор поста (рекомендую почитать) о ней. Пишу я ее в LaTeX и считаю, что современный учебник не должен быть черно-белым, а так же должен быть удобен для использования и учеником и учителем. Здесь я собрал базовые фишки, которые я использую (что-то чаще, что-то реже). Надеюсь, вы найдете что-нибудь полезное для себя :-)

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

Кстати, в следующем посте будут еще <<круче>> функции.

Base64 — это схема кодирования двоичных значений в текст, преобразующая произвольные двоичные данные (например, изображения, файлы или любые байтовые последовательности) в безопасную печатную ASCII-строку, состоящую из 64-символьного алфавита (A–Z, a–z, 0–9, +, /). Браузеры применяют эту схему в JavaScript для встраивания двоичных данных непосредственно в код/HTML или для передачи двоичных данных в виде текста.

Недавно в браузерах появились удобные и безопасные функции для обработки Base64: Uint8Array.toBase64() и Uint8Array.fromBase64(). Хоть у них и есть множество параметров, смысл их сводится к кодированию и декодированию.

При кодировании они берут 24 бита из входных данных и разделяют их на четыре сегмента по 6 бит, и каждое 6-битное значение (в интервале от 0 до 63) соотносится с конкретным символом из алфавита Base64: первые 26 символов — это буквы A-Z в верхнем регистре, следующие 26 — a-z в нижнем, затем идут цифры 0-9 и, наконец, символы «+» и «/» в качестве 62-го и 63-го символов. Если длина входных данных не кратна трём байтам, то в качестве заполнителя используется знак «=».

Насколько же быстро могут работать эти функции?

Как работает чистый код?

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

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

За 5 лет работы в B2B и B2C сегментах у телеком-провайдеров я столкнулся с одной из проблем: абоненты годами сидят на архивных дорогих тарифах или пользуются услугами операторов, которые не идут на уступки, не снижают цены на тарифы, пользователи просто не знают, что в их же доме есть альтернативные провайдеры с тарифами более выгодными для них.

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

Сейчас я работаю аналитиком БД, параллельно изучаю архитектуру, построение данных. Решил начать проект с проектирования структуру на PostgreSQL по схеме "Звезда". Таблицей фактов у меня будет таблица со связью города с провайдером, таблицы измерений – таблица с информацией о тарифах, городами и провайдерами.

С инженерной точки зрения поиск работы — это процесс с низкой энтропией. Есть входящий поток данных (JSON с вакансиями) и есть необходимость отправить ответный сигнал (POST-запрос с откликом). Задача кажется тривиальной для автоматизации: написал парсер, настроил cron, пошел пить кофе.

Однако, если вы попробуете автоматизировать отклики на крупных job-board платформах (особенно на hh.ru) в 2026 году, вы столкнетесь с серьезным противодействием. WAF (Web Application Firewall), анализ TLS-отпечатков, поведенческая биометрия и теневые баны — это реальность, которая убивает скрипты на requests за пару часов.

В этой статье разберем архитектуру решения, которое позволяет автоматизировать процесс отклика, используя подходы RPA (Robotic Process Automation), мимикрию под поведение пользователя (Human Mimicry) и LLM для обхода смысловых фильтров.

(Дисклеймер: Статья носит исследовательский характер. Мы не призываем нарушать правила площадок, а разбираем технические методы эмуляции браузера).

Разработка с ИИ-ассистентами часто напоминает поездку с талантливым, но забывчивым штурманом. Он отлично знает карту (код), но постоянно забывает пункт назначения (бизнес-задачу) и пройденный маршрут (контекст).

Мы привыкли работать в режиме "Prompt & Pray": написали длинный промпт, получили код, внесли правки. Но на дистанции сложной фичи контекст размывается. Агент начинает галлюцинировать, терять детали или переписывать одно и то же. Проблема не в модели, а в отсутствии долгосрочной памяти и четкого контракта.

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

OpenSpec - чтобы зафиксировать "что и зачем мы делаем" (Spec-Driven Development).

Beads - чтобы управлять тем, "как и в каком порядке" это выполнять (граф задач).

Cursor - как среду, которая связывает их воедино.

Если вы устали от того, что ИИ теряет нить повествования на середине рефакторинга, этот подход для вас.

Практическое руководство по построению сервиса перехвата медленных запросов в StarRocks: правила kill и пороги (full table scan, scan rows/bytes), анализ execution plan, интеграции с Grafana и Feishu, SQL-схемы и YAML-конфигурация для продакшена.

Всё началось с вопроса коллеги: «А GigaChat вообще можно к n8n прикрутить?»

Мы посмотрели в список встроенных интеграций n8n. OpenAI — есть. Anthropic — есть. Mistral, Groq, Ollama — пожалуйста. GigaChat — а вот и нет.

«Ну значит нельзя», — сказал бы нормальный человек и пошёл дальше...

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

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

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

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

Привет! Меня зовут Дима, я продуктовый дизайнер. Мой путь в IT оказался связан с постоянной гонкой за релизами фичей. Я успел поработать в разных проектах—от небольших агентств и стартапов до бигтеха (и, как итог, сильно выгорел). В какой-то момент я решил попробовать себя в создании настольной игры. 

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

В «Release любой ценой» ты становишься релиз-менеджером и собираешь релиз из Backend, Frontend и Database. Твоя цель — зарелизить первым “любой ценой”: саботировать соперников багами и защищать свой релиз. Конечно, в игре есть AI — куда же без него в наше время—в виде дополнительной колоды случайных событий.  Если тебе кажется, что у тебя все под контролем, всегда можно вытащить из колоды Error 503, который выбьет тебя из игры. Победи, собрав все карты релиза, или останься последним выжившим.

PnP выложил на GitHub.

Всем привет!

Статья на 15-20 минут осознанного чтения. Будет интересна начинающим и, надеюсь, продолжающим увлекательное путешествие людям во вселенной python. Рассмотрен один из великого множества подходов к написанию web приложения с API + автоматизированной документацией на OpenAPI (в недалеком прошлом Swagger).

Автомобильные блоки управления полны компонентов, промаркированных нестандартно. Например, встречались микросхемы, на которых выбито "Toyota", хотя ежу понятно, что Toyota никаких процессоров не производит. Но в мире электроники при больших партиях производители чипов имеют возможность выбить на чипе ваш логотип, или маркировку, и разработчики ЭБУ этим активно пользуются, хотя цели их не совсем ясны.

Но нестандартная маркировка - это еще цветочки! Существует огромный пласт кастомных компонентов, выполненных "под заказ" для конкретного производителя ЭБУ. Такие проприетарные компоненты зачастую не только не имеют открытой документации, но и отсутствуют в линейке производителя.

Не так давно мы разбирались с процессором TMS470R1A256, очень популярный в блоках SRS 2007-2010 г.в.. На нём выбивают маркировки: TMS470R1VF3482 или TMS470AVF3482, однако достаточно подключиться к этому процессору посредством отладчика чтобы понять, что это процессор TMS470R1A256. Дело в том, что согласно datasheet на эти процессоры, в каждом процессоре есть device identification code register, прочитав который, вы сможете узнать part number данного процессора, который уже можно отыскать в datasheet.
Например, для TMS470R1A256: `The assigned device-specific part number for the A256 device is 0001010` что при переводе в hex = 0x0A. Много разработчиков написало программы для чтения данных процессоров, но почему-то блоки с процессорами, записанными этими программами, не выходили на связь. Пришлось разбираться с этим вопросом самостоятельно, результатом чего стала версия программы JLinkZReader, в которой проблема чтения и записи данных CPU была решена.

Опишу пример, демонстрирующий, насколько важна декларативность в вопросах управления поведением «аппки» (за этим стоят вопросы сохранения высокого уровня абстракции и, как следствие, масштабируемости приложения). Задача - сделать управление мутациями DOM более декларативным и, как заявлено в заголовке, использовать реактивность на примере управления состоянием.

Tor — это не только браузер. Его можно использовать как транспортный уровень анонимности для всей домашней сети, проксируя HTTP и SOCKS5-трафик через Tor.

Это альтернатива использованию VPN для доступа к заблокированным зарубежным ресурсам.

Tor в связке с Privoxy это позволяет:

Рассказываю, как я делала приложение: «AI тамагочи» с помощью разных ИИ (ChatGPT, Claude, Perplexity и Cursor).

Привет, Хабр! Меня зовут Евгений Мичурин, я senior BI-разработчик в Авито.

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

Мы решили навести порядок и создали фреймворк автосертификации BI‑отчётов. В этой статье рассказываю, как он работает, какие критерии мы выбрали и как мотивировали команды участвовать в процессе.