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

Одна из самых частых и болезненных проблем в IT-командах — коммуникация с внутренними заказчиками. Со стороны разработки заказчики выглядят как генераторы сырых ТЗ, вечных правок и нереалистичных сроков. Со стороны бизнеса IT-специалисты кажутся «черным ящиком», который работает медленно, негибко и допускает ошибки.

До аналитики я три года руководил клиентским сервисом, где сформировал методологию работы с клиентами. Этот опыт помог мне найти ключ к гармонии: работать с заказчиками как с клиентами. Разница в том, что клиента мы стремимся не потерять, а значит, ведем себя более ответственно и проактивно.

В этой статье я собрал 11 принципов, которые помогут выстроить такую коммуникацию.

В любой более менее большой компании разработчиков вы найдете и человека на "окошках", и трушного линуксоида, и любителя лавандового рафа на альтернативном с яблоком на крышке ноутбука. И если человек с windows с большей вероятностью будет пользоваться WLS (подсистему linux), то вот человек с macOS попробует запустить проект у себя нативно, и это может привести к проблемам с совместимостями некоторых библиотек. Также, учитывая что с высокой долей вероятности ваше приложение будет крутиться в docker контейнере на сервере, не плохо было бы понимать то, как оно работает конкретно в нем. Поэтому зачастую решением которое подойдет всем для корректной разработки приложения без проблем с совместимостью, это запуск и отладка приложения на компьютере разработчики в независимости от установленной ОС прямо в docker. И так я описал мотивацию, перейдем же к настройке вышесказанного.

Для начала необходимо добавить установку библиотеки debugpy для работы отладчика в наше приложение. вы пожете добавить ее в общий фаил requirements.txt или добавить команду DockerFile.

Писать надо только тогда, когда не можешь не писать (С) Л.Н. Толстой

Задача, которая заняла бы 2 - 3 месяца классической разработки, была решена за 2 дня с помощью Claude и n8n. Автоматизировал валидацию конфигураций шкафов управления освещением, делегировав написание проверок самим инженерам через промпт-инжиниринг. Кейс про то, как AI меняет не только код, но и процессы.

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

Эта статья не против ИИ. Она про зрелость, ответственность и честный разговор о том, где ИИ действительно помогает бизнесу, а где делает больнее.

Когда я был разработчиком я задавался вопросами: как разделить код на классы? какие модули выделить?

Когда я стал архитектором я задавался вопросами: зачем же мы наплодили 200 микросервисов? стоит ли выделять новый или пора объединять?

Когда я стал руководителем я задавался вопросами: как разделить людей на команды разработки? стоит ли создавать новый отдел или расширить ответственность старого?

И всё это хотелось сделать оптимальным эффективным образом.

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

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

Быстрота изменений UX/UI дизайна, функциональности, влияния запусков конкурентов, предоставляющих аналогичный продукт, внешние факторы – все это отражается на метриках удержания и сроке пользования продуктом, а значит и на тех деньгах, которые продукт зарабатывает по P&L.

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

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

Это несоответствие между интуицией и наукой не ново.

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

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

Недели через полторы-две, когда случай уже забылся, Алексей приехал для продолжения работы над статьёй, профессор вошел в комнату и спросил:
— Зачем вы повесили сюда ковёр? Где вы его взяли?
— Какой ковёр?
— Ну, вот же, на стене висит.
— Тут нет ковра...
— Чего вы дурачите меня, вот же ковёр!

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

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

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

Привет, Хабр! Я Senior Angular Developer. И я хочу рассказать вам о своём недавнем опыте, который похож на сцену из киберпанк-триллера, но разворачивается в обычном интерфейсе hh.ru. Открываешь отклик на вакансию, а вместо формы для ввода текста — диалог с ИИ-ассистентом рекрутера. Он задаёт вопросы по стеку, проектам, архитектуре. И вместо того, чтобы в сотый раз пересказывать своё резюме, я сделал логичное, на мой взгляд, действие: поручил ответы своему ИИ-ассистенту.

Так началось интервью, где вопросы генерировала одна нейросеть, а ответы — другая. Моя роль свелась к модерации: «Да, это ок. Нет, исправь». Что из этого вышло, почему это одновременно эффективно и тревожно, и не пора ли нам всем смириться, что первый этап отбора теперь — это «Тьюринг-тест на максималках»? Разбираемся под катом.

Технологический сюрреализм: ATS умер, да здравствует AI-Screening?

Помните эпоху ATS (Applicant Tracking Systems), когда мы оптимизировали резюме под ключевые слова? Каменный век. Теперь системы эволюционировали: они не просто сканируют, они ведут диалог. «А использовали ли вы NgRx в продакшене?», «Опишите опыт реализации micro-frontend архитектуры» — вопросы генерируются на лету LLM, проанализировавшей описание вакансии.

Абсурд и ирония ситуации в её чистоте: две нейросети пытаются найти «мэтч» между двумя текстовыми файлами — вакансией и резюме. Человек-рекрутер и человек-соискатель вынесены за скобки первичного акта коммуникации. Мы наблюдаем рождение нового протокола взаимодействия на рынке труда: machine-to-machine screening.

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

Еще одна библиотека строк для Python? Легко - если у вас есть ИИ-помощник.

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

Есть несколько практик в разработке ПО, которые, с одной стороны, являются практически неотъемлемой частью пейзажа, а с другой - довольно уродливы, если вдуматься, и сильно вредят всем (некоторые вредят AI Code-ассистентам). В этом посте я хочу поныть про автоматические тесты - священную корову разработки ПО последних как минимум 10 лет. И особенно поныть про unit-тесты.

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

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

Любой, кто пытался прикрутить LLM к реальному продакшену в узком домене (медицина, право, инженерия), проходил стадию отрицания: "Да ладно, сейчас промпт подкручу, RAG прикручу — и полетит".

Не полетит.

В embedded-проектах с батарейным питанием управление энергопотреблением часто сводят к нескольким вызовам sleep() и проверке кнопки включения. Пока устройство простое — этого хватает. Но как только появляется аккумулятор, зарядка, дисплей, кнопка питания и требования к пользовательскому поведению, такой подход начинает разваливаться.

Типичные ситуации, с которыми сталкиваются на практике:

● устройство выключено, но подключили зарядку — что должно происходить?

● зарядка идёт, пользователь нажал кнопку — включаться или нет?

● батарея критически разряжена — как корректно отказать во включении?

● устройство долго не используется — когда и как его выключать?

● контроллер питания подал питание сам по себе — это включение или ошибка?

устройство вышло из Deep Sleep — это пробуждение или «холодный старт»?

Хватит воевать с Makefile: как я написал свой таск-раннер на Rust

Устали от табов, .PHONY и bash-лапши? Я тоже. Поэтому написал Nest — декларативный таск-раннер с иерархией, типами и понятным синтаксисом. Рассказываю, как это было и почему вам стоит попробовать.

Сэм Альтман — безусловно, главная звезда ИИ-бума, начавшегося после запуска ChatGPT в 2022 году. Генеральный директор OpenAI стал лицом всей индустрии, и у него есть своя профессиональная страсть: он просто обожает законы масштабирования.

Именно эти эмпирические правила связывают масштаб модели с ее возможностями. Они же объясняют ту лихорадку, что охватила индустрию: в погоне за мощностью компании сметают с рынка чипы, возводят дата-центры и ради энергии готовы даже перезапускать закрытые АЭС.

В своем блоге Альтман сформулировал это так: «интеллект» модели примерно равен логарифму ресурсов, ушедших на ее обучение. Рецепт успеха звучит просто, хоть и дорого: можно бесконечно повышать производительность, если экспоненциально «скармливать» системе все больше данных и вычислительных мощностей…

Это первая статья из цикла о построении CDC-пайплайна в домашней лаборатории.
Полный путь: Telegram → PostgreSQL → Debezium → Kafka → HDFS → DWH.
Но любой пайплайн начинается с данных — и эта статья про их получение.

Будучи достаточно древним поклонником серии Minecraft (именно серии, потому что версии 1.5, 1.7 и 1.9 — совершенно разные поколения игр), я давненько загорелся желанием рассказать, что же такого интересного хранит это незамысловатое название. Как сложилась судьба ее разработчика, Маркуса Перссона, какими идеями он пренебрег, когда наступил его успех, и как он к нему шёл, как развивался этот самобытный мир, и что заставило создателя отказаться от своего творения?

История будет разбита на три (или более) статьи, в каждой из которых будет разобран огромный кусок информации. Будьте готовы к лонгридам.

Также в статье будет инструкция, как сделать своей сервер.