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

Всем привет. Я уже около 10 лет занимаюсь разработкой и около 5 лет полностью перешел на продукты JetBrains, и за все это время у меня накопилось около 150 проектов как рабочих, так и своих личных, я их конечно же красиво разложил по папочкам на диске, поставил теги на папки в маке и добавил быстрый доступ.

Я работаю с несколькими клиентами, активных проектов в работе около 25 штук, стандартные средства и функционал IntelliJ IDEA(Recent projects) с таким количеством прекрасно справляется, быстро ввел название сервиса в поиск и так же быстро открыл.
Идеальная жизнь закончилась когда ко мне пришел клиент с еще 25 микросервисами в разных репозиториях и беклогом с багами в 300+ задач(white-label решение), я вздохнул и начал работать с 50 активными проектами и обнаружил что "Recent projects" в IDEA умеет хранить только 30 последних открытых проектов, и если ты открываешь 31 проект, увы первый пропадает как из поиска, так и из списка.

Через пару месяцев этот же клиент отправил меня на помощь одному из своих заказчиков, где те же 25 микросервисов, но со своими фичами, функционалом и так далее. По итогу к декабрю у меня образовалось 75 рабочих проектов и с десяток личных, и работать с этим комфортно я не представлялось возможным. Я начал искать какие то готовые решения на просторах магазина JetBrains - нашел три мертвых плагина с плоским функционалом и по факту тем же подходом как в "Recent projects".

Решение — свой плагин со всем функционалом что я хочу, без ограничений IDEA...

Всем доброго дня! В предыдущей статье Kawai-Focus 2.3: логика приложения на TypeScript:

1. Переписана логика с JS на TS;

2. Разобрана проблема запуска на Arch по issue Сергея (отключена сборка AppImage).

Сегодня я покажу, какие есть адекватные способы собрать приложение под Arch Linux без боли и лишних проблем. Для удобства тестирования и сборки я установил операционную систему Cachy OS, которая базируется на Arch Linux.

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

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

Но есть нюанс - нейросетей стало очень много. Есть универсальные модели, которые умеют всё, но требуют правильных промптов. А есть узконаправленные инструменты - они заточены под конкретные задачи, но стоят денег и не факт, что сделают лучше.

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

Поехали! Приятного прочтения)

Git — это вызов, через который проходит каждый второй новичок в разработке. Ветки называются «asdasd», коммиты — «правки», а pull request пугает своей красной кнопкой. Знакомо?

Меня зовут Сергей Прощаев, я Tech Lead в FinTech и преподаватель на курсах в OTUS. В этой статье разбираем самое главное: как создавать ветки и почему их нельзя называть как попало, что писать в коммитах, как сделать pull request в лучших практиках команд разработки

Как часто вы задумывались о нагрузочном тестировании (НТ), когда на подходе очередной релиз, но времени на дополнительные проверки катастрофически не хватает? В таких условиях НТ обычно выглядит ненужной роскошью, но на деле оно — неотъемлемая часть процесса, которой нельзя пренебрегать. Нагрузочное тестирование помогает избежать множества рисков, особенно в условиях роста количества пользователей и требований к производительности.

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

Признаюсь сразу: я никогда не работала по PMBoK как по инструкции. И подозреваю, что большинство PM‑ов в арт‑аутсорсе — тоже. Слишком много процессов, слишком мало про то, что происходит, когда клиент на третьем ревью говорит «а давайте поменяем концепцию».

Но PMBoK 8 — первое издание, которое я открыла из искреннего любопытства. Разбираю, что изменилось и почему это наконец‑то работает для креативных PM‑ов.

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

Не «ИИ помогает вам автодополнить функцию». Не «ИИ объясняет стек вызовов». Я имею в виду полноценную риторику:

«Нам больше не понадобятся инженеры-программисты».

И я никак не мог сформулировать, что именно меня в этом напрягает — пока в голове не щелкнуло.

Дисклеймер: Эта статья не о том, что «Vibe Coding — это зло». Если вам нужно быстро склепать прототип для презентации инвесторам или сделать лендинг за час — вперед, это легитимный инструмент. Эта статья о том, почему для профессионального роста и долгосрочной устойчивости как инженера важно разделять понятия «погонщик ИИ» и «инженер, использующий ИИ».

Как мозг защищает убеждения вместо поиска истины и почему «давайте подумаем ещё раз» не работает

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

Проблема: когда коммуникации поглощают рабочее время

Исследование: сколько времени уходит на коммуникации?

Практика: три разных мира коммуникаций

Размер имеет значение

План действий: как вернуть время для работы

Как измерить успех?

Обратная сторона медали: когда нельзя сокращать коммуникации

Краткий вывод

При обновлении PostgreSQL с 17-й на 18-ю версию часть пользователей при работе с временными таблицами столкнулась с неожиданной ошибкой no empty local buffer available, в том числе, в типовых конфигурациях 1С. В статье разбираем первопричину: как новый механизм асинхронного prefetch в read stream конкурирует с insert stream за слоты local buffer pool, почему это не проявлялось в PostgreSQL 17, и какие исправления предложила сообществу PostgreSQL команда Tantor.

Здравствуйте, товарищи! Меня зовут Валентин, а на повестке дня у нас карьерные и софтовые вопросы. Разберем основные пути развития: специалист, предприниматель, руководитель - выбор, от которого зависит вся остальная траектория.

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

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

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

Разбор методов детекции, которые работают прямо сейчас. JA3/JA4-отпечатки, поведенческий анализ и архитектура XHTTP, которая закрывает именно эти дыры

Если твой VLESS+Reality сервер лёг в последние месяцы — ты не один. В сообществах фиксируют волны блокировок, которые раньше не достигали хорошо настроенных Reality-серверов. Что конкретно изменилось, как это устроено на уровне алгоритмов — и почему XHTTP сейчас выглядит как правильный следующий шаг.

Хотя бы на десять минут перестаньте теребонькать ChatGPT. Никакая нейросеть вас не спасет. Вообще. Наоборот, она возьмет вас за шкирку и утопит в океане высококачественной, грамматически безупречной посредственности.

Мне нужен был голосовой ввод. Не диктовка в Google Docs, не облачный API — а простая штука: зажал клавишу, сказал, отпустил, текст появился в активном окне. Локально, без отправки аудио куда-либо.

Готовых решений, которые бы устроили, сходу не нашёл. Сделал свое. Может, кому будет полезно.

Коллеги, привет. Если вы когда-нибудь оказывались в ситуации, когда нужно срочно начать мониторить появление слова "CRITICAL" в логах приложения, а возиться с написанием экспортера для Prometheus совсем не хочется — этот пост для вас.

Проблема, которую ощущают многие, но решают немногие.

Вы запускаете Zed, Kiro, Cline, Claude Code или Qwen. Описываете задачу. Агент создаёт код. И вот он перед вами... Иногда качественный. Иногда — беспорядочная смесь чужих стандартов, случайных шаблонов и игнорирование структуры вашего проекта.

Вы поправляете. Объясняете снова. Поправляете. Через час понимаете: вы тратите больше времени на управление агентом, чем на саму задачу.

Компании внедряют ИИ быстрее, чем успевают осознать все последствия, стремясь повысить эффективность и сократить издержки. Но эта гонка за инновациями создает слепую зону для безопасности. По результатам опроса ИБ-компаний, проведенному “Коммерсантом”, в 2026 году до 10% атак на банковские ИТ-инфраструктуры будут связаны с уязвимостями ИИ. На этом фоне растет интерес рынка к решениям и услугам в области тестирования ИИ на устойчивость к атакам. Это создает идеальный момент для интегратора, который может предложить рынку дефицитную компетенцию и закрыть растущую потребность в специализированном тестировании.

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

Поиск работы в IT часто выглядит похожим образом: десятки откликов, постоянные собеседования, новые команды, разные проекты и условия.

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

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

В результате решение об оффере принимается почти вслепую.

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

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

Поделюсь основными из них, надеюсь, что всем будет полезно