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

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

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

Именно в тот момент у меня возник простой вопрос:

Почему вообще арендатор должен платить посреднику, если владелец квартиры и будущий жилец вполне способны найти друг друга самостоятельно?

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

Если проблема настолько очевидна, почему ее до сих пор никто не решил?

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

Со временем первоначальная эмоция превратилась в гипотезу.

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

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

Нужен ли вообще людям такой продукт?

Именно с поиска ответа на этот вопрос началась история сервиса «Сдаре».

Часто людям вне разработки сложно объяснить, почему иногда мы берём готовый SaaS, иногда пишем своё, иногда начинаем с таблицы, а иногда зовём подрядчика. Я попробовал разложить этот выбор через более бытовую аналогию - транспорт. Пешком, автобус, такси, самокат, своя машина и грузовик неожиданно хорошо объясняют разницу между ручным процессом, no-code, SaaS, подрядчиками, платформами и собственной разработкой.

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

А с чего?

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

В работе с AI‑кодерами постепенно меняется формат задачи. Одного промпта часто недостаточно: агенту нужно не только выполнить разовую команду, но и повторять действия до понятного результата. Например: проверить CI, прочитать лог, внести минимальное исправление, снова запустить тест, остановиться при выполнении условий.

Поводом для этой статьи стала заметка Anthropic «Getting started with loops» про циклы (loops) в Claude Code. Там термин«цикл» описывается как повторяющаяся работа агента до выполнения условия остановки.

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

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

Про ИИ ассистентов уже не раз писали и напишут как с положительно, так и с отрицательной стороны. OpenClaw с его постоянным обращениями к LLM (которая прилично есть токены). Про Claude code в данной статье тоже не будет ничего сказано, поскольку тестировавние проводилось именно на основе продуктов от Open AI.

Итак, если у вас уже есть plus подписка на gpt, то вам сюда.

Как проходила работа над проектами ранее: в отдельном проекте в GPT создавался чат, в котором обсуждался определённый проект, написанный, например, на Python. Если возникали некие ошибки — я сразу писал в чат ошибку и мы вместе с чатом пытались решить эту проблему.

Что же позволят делать Codex:

Он сам смотрит весь проект, запускает код, обнаружив ошибки, сам их исправляет и заново запускает. Это же гениально! Дать нейросети доступ к твоему железу и сказать: хочу чтобы работало так‑то так‑то. И Codex это сделает. Не факт, что за 1 запрос вы сможете создать именно то, что изначально хотели, но в этом и прелесть: Codex держит в контексте файлы проекта, находит то, что нужно исправить и сам исправляет то, что требует пользователь.

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

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

Только вот самой планеты никогда не существовало. Но шестьдесят лет погони за призраком не были ни глупостью, ни массовым помешательством. Это была честная попытка использовать лучший научный метод той эпохи — тот самый, что позволил с триумфом открыть Нептун, просто указав его положение на небе по странностям движения Урана. Метод обещал избавить астрономов от поисков небесных тел наугад, от долгих холодных ночей у окуляра. И кто бы мог ожидать, что тот же метод заставит впустую потратить десятки лет на изнурительные поиски. Вулкан должен был быть, его искали, а он никак не находился. Отдельные наблюдения подтверждения не нашли, ажиотаж спал, в него перестали верить даже фанатичные сторонники. Понемногу история забылась, а имя Вулкан сценаристы «Звёздного пути» подарили родной планете Спока. С Ураном всё объяснилось; его сбивал с пути соседний неучтённый Нептун. С Меркурием тот же фокус не прошёл — соседа искали и не нашли. Меркурий продолжал идти не так, как должен по расчётам. Это раздражало и требовало объяснений.

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

«Бросай эту сеть кофеен и иди к нам. Денег у нас больше.»

Эта статья - ответ на статью про CLA в открытом коде, изначально записанный в виде комментария.

Указанная статья в очередной раз излишне многословно пытается объяснить нам, почему сообщество-разработчиков-энтузиастов СПО должно подарить вам свой вклад и согласиться работать на коммерческое предприятие бесплатно. Это моё мнение.

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

На Хабре я скорей читатель, чем писатель, но вот когда в ленте попалась связка DIY + Lemana + Конкурс, я понял, что не смогу пройти мимо. Я уже давно практикую смену деятельности в свободное время, а наличие своего участка не оставляет больших сомнений в том, чем стоит заниматься «отойдя от компьютера» - стройкой.

Я расскажу, как я спроектировал, построил и, что особенно важно, «Достроил» гостевой дом, дачный дом, флигель – все варианты равноправны. Специально заостряю внимание, что я не профильный строитель и не привлекал никого со стороны, кроме разнорабочих для особо тяжелых работ. Все работы вел или по выходным, или по вечерам, когда был соответствующий настрой. Мне было интересно сделать это самому: от фундамента и кровли до установки розеток и настройки Ноme Assistant + Алиса

Cвойство backdrop-filter: blur() под капотом работает совсем не так, как интуитивно кажется, и это приводит к багам, которые нелегко воспроизвести и довольно сложно объяснить. Потому давайте разбираться.

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

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

Зачем мы это делаем? Кому всё это нужно? Как можно попасть на такую встречу в качестве гостя или спикера? Вопросов к нам стало прилетать немало, и я решила ответить на них, так сказать, оптом. Если ты  корпоративный автор и тебе не хватает опыта, знаний о Хабре, мотивации, поддержки и вдохновения – велкам под кат! Я поведаю историю этого проекта, а также расскажу про наше авторское сообщество, которое появилось как логичное продолжение одной из таких творческих встреч и частью которого ты тоже можешь стать.

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

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

Зачем мы это делаем? Кому всё это нужно? Как можно попасть на такую встречу в качестве гостя или спикера? Вопросов к нам стало прилетать немало, и я решила ответить на них, так сказать, оптом. Если ты  корпоративный автор и тебе не хватает опыта, знаний о Хабре, мотивации, поддержки и вдохновения – велкам под кат! Я поведаю историю этого проекта, а также расскажу про наше авторское сообщество, которое появилось как логичное продолжение одной из таких творческих встреч и частью которого ты тоже можешь стать.

Сессионные вычислители — залог успеха аналитики будущего

Всем привет, меня зовут Николай Голов. azathot Всю свою профессиональную жизнь я строю аналитические платформы. Возможно, вы видели мои статьи про Vertica и Snowflake.

[ Vertica+Anchor Modeling = запусти рост своей грибницы (Avito блог??, перед?? ней HP Vertica, проектирование хранилища данных, больших данных ]

- статья, 27 февраля

наша дискуссия с новой командой начиналась с одного и того же «дня сурка»:

— бизнес: «Аналитики работают слишком медленно!»;
— аналитики: «Нам не дают работать с базой напрямую, заставляют ставить задачи дата-инженерам и ждать неделями!»;
— инженеры: «Да как их пустить в центральное DWH? Вы видели их запросы? Один забытый ON в джойне — и база ложится на бок, блокируя и отчеты для CEO, и критические ETL-процессы».

Этот сюжет я наблюдал везде: в классическом on-premise (Greenplum, Vertica), в модных китайских решениях (StarRocks) и даже в open-source Lakehouse-инсталляциях (Spark). Меня окончательно шокировал кейс одной огромной европейской компании по доставке еды: она сидела на Databricks, имела практически неограниченные ресурсы, но всё равно страдала от взаимных блокировок и конкуренции за ресурсы.

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

Фантастика? Нет, Snowflake первым доказал, что это возможно, внедрив архитектуру Multi-cluster Shared Data:

Пять лет назад завершилась моя работа в одном из самых амбициозных, но не завершившихся IT-проектов в истории пассажирских перевозок. Проект для РЖД, который по масштабу и связности экосистемы должен был встать в один ряд со Сбером и обогнать всё, что существовало у мировых перевозчиков. Его убила не кривая архитектура, а пандемия и тектонические сдвиги подковерной борьбы.

Более 15 лет в b2b-разработке приучили меня держать подобные кейсы за контуром публичности. Но сегодня юридические ограничения сняты, и я готов сорвать покровы.

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

Серия первая: Архитектура маскировки. Жесткий процессуальный хардкор, анатомия схемы взаимодействия и готовая методичка с Карточками компонентов, которые спасали наши задницы от бесконечных правок.

Серия вторая: Продуктовое мясо и хроники интеграционного ада. Детальный разбор самого цифрового космолета, погружение под капот легаси-экосистемы, курьезные истории из жизни нашего «прода» в жанре «пиу-пиу». И в завершение 10 наших железных правил выживания с госами.

Добро пожаловать на борт. Физика процесса изменена, но внешне мы стоим на ногах.

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

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

Серия статей о том, как устроены живые системы с точки зрения вычислений, управления и проектирования.

В этой статье попробуем разобраться, как инженеру воспринимать клетку, ДНК и развитие организма, используя понятные аналогии с микроконтроллерами, нейросетями и клеточными автоматами.

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

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

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

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

В среде ИТ-специалистов сложился устойчивый миф: «Если нужна система управления ИТ-процессами — бери JIRA, она всё потянет». Давайте посмотрим правде в глаза: JIRA — действительно отличный трекер задач. Но только до тех пор, пока вы не пытаетесь построить на её основе CMDB-систему. Здесь и далее под JIRA, с одной стороны, мы понимаем конкретный продукт, а, с другой, объединяем класс подобных развитых ITSM-систем, которые выпустили модули ITAM и на хайпе пытаются автоматизировать процессы управления конфигурациями как в сервис деске.

Под CMDB мы понимаем не просто набор форм и полей, которые администраторы заполняют вручную (если не забудут) или импортируются из других источников, а полноценную CMDB, где каждая конфигурационная единица (CI) имеет актуальные атрибуты, корректные связи и понятное место в ресурсно-сервисной модели. Речь идёт об управлении конфигурациями с правилами поведения объектов — прямыми и косвенными зависимостями, которые система должна отслеживать автоматически. И, наконец, о приоритизации инцидентов, когда сообщение системы мониторинга превращается не в ещё один тикет, а в точное указание: где, что и как сломано и насколько это критично для бизнеса. Перед таким набором требований JIRA как трекер задач пасует: она не просто показывает низкую эффективность — она принципиально не предназначена для этого.

Как только ваш ИТ-ландшафт перешагивает определённую планку сложности, повышаются требования к работе ИТ-специалистов, обеспечивающих оперативное управление ИТ-сервисами, специалистов, которые выполняют задачи администрирования и развития информационных систем. Их деятельность начинает измеряться в количестве изменений, которые они способы реализовать, сроках и качестве таких изменений, скорости реакции и устранения аварий, переход на мероприятия по проактивному предотвращению аварий. И все эти показатели напрямую завязаны на CMDB. Формальное наличие списка серверов никого не устроит. JIRA загрузила из zVirt список виртуалок — это хорошо, осталось понять, что из этого прод и тест, что к какой системе относится и какие сервисы там крутятся. Без этой информации — это просто список виртуалок.