Обновить

Бэкенд

Сначала показывать
Порог рейтинга

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

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

Один рассказывает, что взял на бирже проект компьютерного клуба, нужно на их сайте сделать лидерборд для чемпионата. Сказал, что сделал за несколько вечеров, сейчас не может со своего сервера перенести на их сервер. Говорит, на моем запускается, копирую всю папку, на их не работает. Сейчас с ботом разбираются, в чем проблема. Токены, говорит, уходят влёт! Каждый вечер аккаунты меняет. Другой советует, ты им отдай вместе с сервером, себе новый возьмёшь, первый говорит, у меня там ещё 2 проекта. Думаю, огонь - облачные технологии, кубернетис с неймспейсами!


Дочь, к сожалению, качели недолюбливает, трусиха, быстро расхотела качаться, пожелала лазить по забору, тут уж я трусиха, пришлось идти подстраховывать, а эти кореша продолжили свой бэкенд толкс, аж завидно, я б послушал!!!


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


Мм, лепота!

Теги:
+3
Комментарии0

Open-Spec вместо Open-Source

Пытаюсь тут написать сервис полностью по SDD (описываешь спеку и агент генерит по ней код) и такая мысль пришла. Раньше, когда ты хотел показать, что в твоем коде нет закладок или его можно переиспользовать — то выкладывал исходники. А сейчас, по идее, можешь выложить очень подробную спеку и твой сервис по ней пересоберут.

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

Отсюда другая мысль: мы теперь системные аналитики или технические писатели? Ведь по сути анализ (до какой-то границы) можно так же скинуть на агента

Теги:
0
Комментарии1
Биржа заказов Инфостарта: новые задачи по 1С со 23 по 30 сентября
Биржа заказов Инфостарта: новые задачи по 1С со 23 по 30 сентября

На Бирже заказов Инфостарта за неделю с 23 по 30 сентября появились задачи для разработчиков, консультантов и аналитиков 1С.

Заказчикам нужны специалисты по Бухгалтерии, УНФ, УТ, Документообороту, КА, УПП, ERP, мобильной платформе, ККМ, обменам, маркетплейсам и интеграциям.

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

Теги:
+3
Комментарии0

Один мой друг, не я, проходил собеседования на Java Senior. Любопытна статистика результатов. 13 собеседований.

Общие вопросы разработки (теория, кодревью, иногда простой лив-кодинг) были на 12 собесах, в 11 случаях всех все устроило (правда, в одном случае поставили чуть ниже ожиданий, но не заблокировало). Это 11/13, но там где не провели интервью - там посмотрели предыдущие фидбеки (то есть по умолчанию ОКнули). Так что 12/13=92% ОК

Алгоритмическая секция была на 4 интервью, в 1 случае выше ожиданий, в 1 по норме, в 1 чуть ниже ожиданий (по мнению интервьюера) но формально отказ, в 1 прям так себе. Кто не проводил - очевидно для них не очень важна эта составляющая, так что считаем от них ОК и пишем 10/13=75% ОК

Системдизайн был по плану на 3 интервью, хотя внезапно вылез еще на 2 посреди другого этапа :) в 2 случаях ОК, в 3 посчитали что слабовато. По тому же принципу что если не спросили то не важно (но не учитываем те где кандидат не добрался до дизайна а он должен был быть) - (13+2 лишних)-3 отказа=9, а в знаменателе (13+2 - 3 непроведенных но где это важно)=75% OK

Финалки/знакомства были в 5 треках, тут можно смело считать что они предусмотрены везде, поэтому проценты считаем только по тем где провели. Из 6 кейсов 6 отказов (2 оверквалификация, 1 опасение что кандидату не понравится используемый стек, 1 несовместимость с командой по вайбу, в 1 случае на финалках спрашивались специфические важные для данной организации технические подробности - вроде того, как производится handshaking в протоколе TCP. 5 кейсов и 5 отказов = 0% OK.

Почему нахожу эти цифры интересными. По каждому из показателей (кроме финалки) кандидат устроил 75-90% работодателей. И однако по совокупности он устроил 0%. Нетрудно посчитать, что вероятность пройти по 3 этапам-критериям исходя из этой статистики - 92%*75%*75%=50%, кажется что система должна работать и давать разумный шанс. На самом деле примерно столько и вышло, но это без учета финалок, на которых тоже теперь проявляют придирчивость. Разумно ли, что на выходе получился 0?

Впрочем по-хорошему оба кейса оверквалификации и один кейс с хардами в финалках следовало исключить уже на этапе первичного скрининга, чтобы не тратить ничье время. Если вакансия на самом деле не сеньорного уровня или требует специфического hands-on experience, кандидат должен был об этом узнать и вовсе не подаваться. Тогда остается только 2 отказа на финале, оба вполне валидных. Но... тогда надо из общей статистики эти вакансии убрать целиком, и получится что из 10 оставшихся проведено только 2 финалки, 20% уже выглядит как слишком низкая востребованность если большинство интервьюеров довольны каждым критерием в отдельности, нет?

Ну и выглядит забавно (хотя это уже искажение перспективы)

  • если ты можешь пройти все этапы трека, мы подкинем тебе еще обручей (+1 сисдизайн например)

  • если ты и тут не слился, то ты для нас слишком хорош

Теги:
+7
Комментарии0

Сколько вакансий на каждом грейде и сколько за них платят?

Сколько вакансий на каждом грейде и сколько за них платят?
Сколько вакансий на каждом грейде и сколько за них платят?

Новая аналитика по уже более 180.000 IT вакансий с HH, карьерных сайтов, сайтов организаций, job-бордов и телеграмм каналов.

Я построил 12 графиков отвечающих на разные вопросы связанные с IT наймом в 2026 году.

На Хабре буду выкладывать новые графики каждую неделю по средам!

Теги:
-2
Комментарии0

Плановое обслуживание кода

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

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

Эффективность агента

/doctor (Claude Code) — раз в месяц проверяю здоровье агентского окружения: конфигурацию, неиспользуемые скилы и MCP, медленные хуки, проблемы с permissions и другие накопившиеся проблемы. Заодно помогает освобождать память от устаревшего и лишнего.

/fewer-permission-prompts (Claude Code) — анализирует историю работы и предлагает, какие часто используемые безопасные команды стоит добавить в allowlist, чтобы агент меньше отвлекал подтверждениями.

/run-skill-generator (Claude Code) — периодически пересобирает знания агента о том, как поднять и проверить проект, чтобы /run и /verify не опирались на давно устаревшие команды.

/retro (Matt Pocock Skills) — формально не плановая задача. Запускаю после сессии, где агент заметно буксовал, делал лишние шаги или его приходилось несколько раз исправлять. Скил анализирует, что можно поменять в инструкциях, автоматических проверках и окружении, чтобы эта проблема больше не повторялась.

Качество кода

/simplify (Claude Code) — прохожусь по активно меняющимся частям проекта. Ищет дублирование, лишние абстракции, возможность переиспользовать уже существующий код и просто слишком сложные решения. Удобно запускать раз в неделю по нескольким наиболее активно меняющимся каталогам.

/code-review (Claude Code; у Matt Pocock также есть одноимённый skill) — отдельный проход по изменениям за неделю на корректность, качество кода и возможные упрощения. Обычный review конкретного изменения такую накопительную деградацию часто не замечает.

/improve-codebase-architecture (Matt Pocock Skills) — ищет места, где архитектура постепенно поплыла: слишком мелкие модули, неудачные границы, сложные интерфейсы, размазанное по нескольким местам поведение. Можно натравливать прямо на конкретные слои, типа посмотри сервисы

Чтобы не потерять это добро, я включил в его книгу паттернов агентной разработки

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

p.s. Поделитесь своими фишками, что запускаете вы?

Теги:
+3
Комментарии0

Зачем системному программисту знать больше, чем С

C придумали в 1972 году, а системные программисты по-прежнему пишут на нём — несмотря на смену архитектур и языков за прошедшие полвека. Почему так вышло и почему одного знания синтаксиса недостаточно, если не понимаешь, как код компилируется, выполняется процессором и взаимодействует с аппаратурой?

Об этом рассказывают — Денис Довженко, ведущий инженер по разработке ПО для СХД, и Сергей Жмылёв, руководитель отдела низкоуровневого программирования — в лекции журнала «Истовый инженер». На примерах встраиваемых и высокопроизводительных систем они показывают:

  • как устроено системное программирование,

  • какие возможности и ограничения C определяют его применение,

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

➡ Запись лекции смотрите на «Истовом инженере».

Что почитать, чтобы зайти в тему подготовленным:

  • Никита Косырев объяснил, чем системное программирование отличается от прикладного, и подробно рассмотрел, как они работают вместе.

  • Дмитрий Петров в подкасте «Битовые маски» рассказал, как устроена разработка компиляторов и что в ней изменилось за 20 лет.

  • Дмитрий Точанский, Елена Лепилкина и Антон Афанасьев разобрали архитектуру ядра и драйверов Linux и системное программирование для разных процессорных архитектур.

Теги:
+7
Комментарии0

Новый вебинар из серии «Быстрый старт»

Переход на PostgreSQL и отечественные СУБД требует пересмотра привычных подходов к бэкапам. ИТ-специалистам приходится выбирать между нативными утилитами и централизованной системой резервного копирования. На вебинаре разберем, как найти оптимальный баланс, и на примере Postgres Pro покажем сценарии защиты и быстрого восстановления данных с Кибер Бэкапом.

15.10.2026 в 11:00 МСК проведем онлайн вебинар, на котором обсудим следующие темы:

  • Вызовы миграции

    • Почему при переходе на российские СУБД не обойтись старыми методами защиты

  • Эволюция поддержки бэкапа PostgreSQL в Кибер Бэкапе

    • Как мы развивали поддержку от версии к версии

  • Инкрементный бэкап и восстановление

    • Современные сценарии для баз данных

  • Кластерные конфигурации

    • Нюансы защиты распределенных сред

  • Демонстрация

    • Установка и настройка агента для PostgreSQL, инкрементный бэкап и восстановление данных, подходы к решению типовых проблем.

Регистрация

Теги:
+3
Комментарии0

Друзья, приглашаем вас на очередной онлайн Devhands AI Meetup #3!

В этот раз в программе доклады от приглашённых спикеров из бигтеха.

 📅 Когда: 8 октября, начало в 18:30 (Мск)

🔗 Где: онлайн в Zoom, для участия требуется предварительная регистрация на Timepad

Программа:

• «Куда уплывает код», Павел Литвиненко, Технический руководитель по внедрению инноваций в «Звуке»

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

• «Как построить harness, который автономно напишет мобильное приложение», Дмитрий Полищук, руководитель отдела разработки RWB

Дмитрий познакомит с фреймворком xpowers на базе superpowers: соберёт и настроит инфраструктуру, которая автономно пишет мобильное приложение.

• От ТЗ до MR: пайплайн разработки с ИИ-агентом», Никита Федосов, 2ГИС

Как построить процесс, в котором ИИ-агент ведёт задачу от уточнения требований до готового MR. Разберём этапы пайплайна, скиллы и гейты, а также границу между автономной работой агента и моментами, где всё ещё необходим человек.

Регистрируйтесь, приходите сами, приводите друзей.

Теги:
+5
Комментарии0

Как менять значения «на лету», не перечисляя все колонки в SELECT

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

Возьмем все тот же пример: широкую таблицу, в которой 50 или более колонок. Часто бывают ситуации, когда нам нужно модифицировать значения только в одном-двух полях (например, привести email к нижнему регистру, округлить цену или захешировать данные), а все остальные поля вывести как есть.

В классических транзакционных базах, таких как PostgreSQL, мы бы вручную перечисляли в SELECT абсолютно все поля: и те, которые нужно просто вывести, и те, значения в которых нужно как-то изменить.

В ClickHouse это делается проще.

Чтобы не писать десятки колонок руками, можно использовать модификатор REPLACE. Он работает в связке со звездочкой * и позволяет вывести все поля, заменив значения только в конкретных.

Обычно мы пишем так:

SELECT
  id,
  category,
  user_id,
  -- ... перечисляем десятки остальных колонок руками ...
  LOWER(email) AS email
FROM table

С использованием REPLACE запрос становится короче:

SELECT * REPLACE (LOWER(email) AS email)
FROM table

А если нам надо и исключить колонки, и заменить значения, можно писать EXCEPT и REPLACE вместе:

SELECT * 
    EXCEPT (updated_at) 
    REPLACE (LOWER(email) AS email)
FROM table

Несколько нюансов:

  1. Правила замены пишутся в круглых скобках. Синтаксис такой: (выражение AS имя_существующей_колонки).

  2. Можно изменять сразу несколько колонок, перечислив их через запятую: REPLACE (LOWER(email) AS email, price * 0.85 AS price).

  3. Тип данных колонки в итоговой выборке поменяется, если ваше выражение возвращает новый тип (например, вы заменили число на строку).

Про еще один модификатор расскажу в следующем посте.

Ссылка на доку.

Мои статьи по ClickHouse на Хабре.

P.S. Систематизировать знания и получить крепкую базу можно на моем бесплатном курсе «ClickHouse с нуля». А закрепить пройденный материал на его практическом продолжении «ClickHouse с нуля: практика».

Теги:
+4
Комментарии0

Когда точечные интеграции перестают работать: как выбрать ESB и собрать команду

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

29 сентября вместе с EvApps проведем вебинар о двух связанных задачах:

  • когда компании уже нужна ESB, а когда точечных интеграций достаточно;

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

Разберем:

  • место ESB в корпоративной архитектуре и связь с MDM и КХД;

  • российский рынок интеграционных платформ;

  • подрядчика, аутстафф, внутреннюю и смешанную команду;

  • типовые точки, где проект начинает буксовать по ресурсам;

  • что делать с поддержкой после запуска.

Спикеры — Сергей Скирдин, технический директор «Белого Кода», и Альфред Столяров, директор EvApps.

Участники получат обзор российских шин, опросный лист для выбора ESB и чек-лист проверки подрядчика.

29 сентября в 12:00 по МСК

Регистрация на вебинар

Теги:
+3
Комментарии0

Центр управления СУБД Digital Q.DataBase.
Продолжаю делиться выступлениями с первого сезона ДНЯ СУБД 2026.

Я рассказывал, как мы воспроизводим функциональность MS SQL Server в нашей СУБД Digital Q.DataBase (без переписывания бизнес логики), а мой коллега Илья Лебедев - как воспроизводим возможности Oracle.

Теперь - о том, как всем этим управлять.
Сразу говорю: Инструмент бесплатный.
А серверная часть нашей СУБД тоже бесплатная - до 4 ядер.
По секрету: можем легко дать и больше ядер.

Выкладываю полное видео выступления Андрея Акимова, руководителя команды «Центр управления Digital Q.DataBase». Андрей рассказывает и показывает, как объединить мониторинг, администрирование и диагностику баз данных в одном веб-интерфейсе.

В докладе - возможности продукта, поддержка Digital Q.DataBase и практические задачи администратора БД: проверить состояние баз, отследить рост таблиц и разобраться, почему тормозит запрос, с помощью трассировки сессий.

Видео с тайм-кодамина:
VK
Rutube
Dzen
YouTube

Кстати, второй сезон ДНЯ СУБД уже близко - встречаемся 27 октября. Приходите!

🔹 Бесплатное получение дистрибутива: 
https://database.diasoft.ru/?utm_source=andrei
🔹 Документация: доступна внутри дистрибутива
🔹 Telegram-сообщество Digital Q.DataBase: https://t.me/dqdatabase
🔹 MAX: https://max.ru/channel_dqdatabase

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

СУБД, которая понимает диалекты Oracle, MS SQL и PostgreSQL,– без переписывания кода приложений.

Теги:
+10
Комментарии1

3 приёмчика которые повышают эффективность моего рабочего дня

1. Хронометраж рабочего времени

У вас нет тайм-трекинга в компании? Тогда организуйте его себе сами!) У ощутимого количества людей, которые работают головой, есть черта обдумывать что угодно, связанное с работой, не только во время, но и до, между и после неё. Поэтому хотелось бы понимать, сколько в действительности мы тратим времени на «активную» работу.

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

 

2. Отказ от фонового потребления

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

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

 

3. «Рабочий журнал»

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

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

Теги:
+4
Комментарии7

Ближайшие события

Миграция ВМ, бэкапы и DR в едином сервисном слое

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

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

Поэтому мы в «Хайстекс» решили завести миграцию, бэкапы и аварийное восстановление в единый контур, так всё работает в прочной связке. Этот принцип лег в основу свежего релиза «Хайстекс Акура».

В ближайшую среду 30 сентября в 11:00 (МСК) проведем технический стрим и расскажем:

• Как на практике работает концепция управляемой мобильности рабочих нагрузок; 

• Что нового появилось в решении: Backup 2.0, Object Lock, поддержка PostgreSQL, работа с OpenStack без привязки к СХД и DR через Direct2Target; 

• Как сегодня сравнивать enterprise-решения по бэкапу и миграции;

• Покажем дорожную карту «Хайстекс Акура» до конца 2026 года.

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

Регистрация по ссылке 

Теги:
+3
Комментарии0

Как построить РБПО без боли для AppSec и разработчиков? Расскажем на GoCloud Tech 2026

РБПО хотят выстроить все, но на практике процесс быстро упирается в несколько противоречий: AppSec тонет в ручном триаже, разработчики — в шуме находок, а готовые внешние решения не позволяют развивать процесс под потребности компании. Мы прошли этот путь и построили систему, в которой безопасность встроена в разработку по слоям: от локальной проверки до релизного среза, и при этом не тормозит ни одну из сторон. На докладе покажем архитектуру такого процесса и разберем, как умная автоматизация с ИИ-агентами помогает сделать его комфортным для участников, не искажая реальную картину на аудите.

Спикер:
Иван Басенко — Go-разработчик, Cloud.ru.

Трек: Разработка

📅 Когда: 15 октября в 14:30–15:00 мск.

👉 Зарегистрироваться

А пока ждете выступление, можете узнать, как мы готовились к сертификации процессов безопасной разработки: ГОСТ Р 56939-2024 на практике: что мы сделали, чтобы получить сертификат РБПО.

Теги:
+3
Комментарии0

Мысли про DHH, Rails и AI в Ruby

Посмотрел выступление DHH с Rails World 2026. Ниже просто мои мысли по поводу того, что он говорил.

Никто не спорит что DHH гениальный маркетолог. Помню еще по истории когда он пересел с Mac на Linux и начал активно про него рассказывать, потом появились Omakub и Omarchy. В какой-то момент это местами звучало почти как проповедь.

С рельсой у меня сейчас похожее ощущение. DHH рассказывает, что Rails чуть ли не идеально подходит для эпохи AI: convention over configuration, мало кода, агенту проще разобраться в проекте, меньше токенов тратится, в этом есть логика. Но Надо помнить что Ruby является динамическим типизированным языком. Сам DHH статическую типизацию исторически не особо любит и, насколько я знаю, Sorbet или RBS активно не использует. Для человека отсутствие типов вполне может быть плюсом: быстрее пишешь код, не надо делать перегонять данные из одного типа в другой. Но для AI типы — это дополнительная информация. Поэтому мне не очень понятно, почему динамичность Ruby должна быть большим преимуществом именно в эпоху AI.

Но самое интересное не это. В том же выступлении DHH рассказывает, что в 37signals теперь фактически pencils down — код руками стараются почти не писать. И одновременно рассказывает, что HEY переписывают с использованием Rust. Причём, по его словам, получили огромную экономию CPU и памяти.

Сам DHH ещё говорит:

If I look at the past 21 years, over half of my work was Ruby code. This year, about 3%.

что раньше больше половины его кода было на Ruby, а в этом году что-то около 3%.

Получается довольно интересная ситуация, которая вызывает вопросики. Одно из главных преимуществ Ruby всегда было в том, что на нём очень приятно писать человеку. Синтаксис простой, код выразительный, Rails позволяет очень быстро собрать рабочий продукт. Но если код теперь в основном пишет агент, то насколько вообще важно, приятно ли человеку этот код писать?

DHH сам говорит примерно об этом же на примере Rust: смотреть на него ему не нравится, зато результат, который делает AI, нравится. И получается, что AI в каком-то смысле убирает одно из главных преимуществ Ruby. Раньше можно было сказать: да, Rust или Go быстрее, но Ruby позволяет разработчику быстрее получить результат, а теперь агент может довольно быстро написать и Rust, и Go.

При этом у тебя остаются статическая типизация, нормальная работа с многопоточностью и более предсказуемое потребление ресурсов. С Ruby всё сложнее. В MRI всё ещё есть GIL. Для обычного веба это далеко не всегда проблема, но если нужна CPU-параллельность, приходится уже думать про воркеры, дополнительные инстансы и так далее. А инфраструктура тоже стоит денег.

С Hotwire у меня похожее ощущение. Сама идея нормальная и для определённого класса приложений действительно удобная. Но DHH иногда очень хорошо умеет взять подход, который отлично работает в 37signals, и продать его так, будто именно так теперь должен писать весь интернет.

Поэтому DHH я всегда воспринимаю сразу в двух ролях. С одной стороны, это очень сильный инженер, который сделал один из самых крутых фреймворков. С другой, один из лучших маркетологов среди разработчиков. Он умеет взять своё мнение о разработке, превратить его в философию, дать ей красивую обёртку и заставить всех нас потом это обсуждать. Но после этого выступления я так и не понял, почему именно Ruby должен идеально ложиться на эпоху AI. Да, у Rails есть сильные conventions, мало шаблонного кода и агенту действительно может быть проще ориентироваться в проекте. Но при этом часть преимуществ Ruby была важна именно человеку, который этот код пишет. А если код всё чаще пишет агент, то эти преимущества уже не выглядят настолько очевидными.

Теги:
+9
Комментарии5
Биржа заказов Инфостарта: новые задачи по 1С со 16 по 23 сентября
Биржа заказов Инфостарта: новые задачи по 1С со 16 по 23 сентября

На неделе с 16 по 23 сентября на Бирже заказов Инфостарта появились новые предложения – работа с УТ 11, УНФ, ERP и Бухгалтерия 3.0. Есть задачи на разработку по материалам Инфостарта, настройку обменов с Ozon и Wildberries, интеграцию с PayKeeper, исправление дублей банковских документов и создание отчетов.

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

Теги:
+6
Комментарии0

Изолируем зависимости: как создать виртуальное окружение в Python

Когда пишешь код на Python, рано или поздно наступает момент, что один проект начнет ломать другой. Установили новую библиотеку, и вдруг скрипт, который вчера работал, падает с ошибкой. Знакомо? Причина обычно одна — конфликт зависимостей. Все пакеты свалены в один системный Python, версии пересекаются, и что-то обязательно отваливается.

Решение — виртуальное окружение. Это отдельная песочница для проекта: свои библиотеки, свой Python, никакого пересечения с соседями.

Вот с чего стоит начать и что стоит разобрать, если вы только садитесь за такую изоляцию зависимостей:

  • Виртуальное окружение vs виртуальная машина. Первое — это просто отдельная папка с пакетами, второе — целая ОС. Хотя некоторые новички часто путают, и потом удивляются, почему venv весит пару мегабайт.

  • venv, virtualenv, pipenv, poetry, conda. Это пять инструментов, которые решают похожие задачи, но по-разному. Для большинства проектов хватает встроенного venv — он уже есть в Python с версии 3.3, и ничего ставить не надо.

  • Активация. А это самая частая точка спотыкания. Команды различаются для Windows, Linux и macOS, а PowerShell вообще блокирует скрипты по умолчанию. source .venv/bin/activate против .venv\Scripts\activate — и это только начало.

  • requirements.txt. Важно помнить, что папку окружения нельзя копировать между машинами, так как она привязана к ОС и архитектуре. Вместо этого фиксируем список пакетов и разворачиваем его одной командой pip install -r requirements.txt.

  • Git и .gitignore. Виртуальное окружение в репозиторий не кладут — только код и список зависимостей.

Чтобы пройти весь путь по шагам — от создания первой папки до деплоя на сервере через systemd и Gunicorn — читайте подробный гайд на сайте Рег.облака.

Теги:
+8
Комментарии0

Drizzle ORM: типобезопасный SQL без магии тяжёлых ORM

Привет, я Сергей Маркизов, бэкенд-разработчик в веб-продакшне Далее. В своих проектах я часто использую Drizzle ORM — инструмент для TypeScript-разработчиков, которым нужны строгие типы, но не хочется прятать SQL за несколькими слоями абстракций.

Классические ORM избавляют от шаблонного кода, однако на сложных проектах их удобство иногда превращается в ограничение. Появляются скрытое поведение, громоздкий API и сложности с нестандартными запросами. А при переходе на QueryBuilder или raw SQL часть преимуществ ORM может потеряться.

Drizzle предлагает компромисс: запросы остаются похожими на SQL, а TypeScript проверяет их на основе схемы базы данных.

Схема — это TypeScript-код

Например, так можно описать таблицу пользователей:

const activeUsers = await db

  .select({

    id: users.id,

    email: users.email,

  })

  .from(users)

  .where(eq(users.isActive, true))

  .orderBy(desc(users.createdAt))

  .limit(10);

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

type NewUser = typeof users.$inferInsert;

const user: NewUser = {

  email: 'user@example.com',

};

Если передать поле неправильного типа или пропустить обязательное значение, TypeScript сообщит об ошибке ещё до запуска приложения.

Запросы остаются похожими на SQL

Для простых операций можно использовать ORM API, а более сложные запросы собирать через типизированный конструктор:

const activeUsers = await db

  .select({

    id: users.id,

    email: users.email,

  })

  .from(users)

  .where(eq(users.isActive, true))

  .orderBy(desc(users.createdAt))

  .limit(10);

Здесь нет отдельного языка запросов, который нужно мысленно переводить в SQL. select, from, where и orderBy остаются на своих местах, при этом поля и результат запроса типизированы.

Если возможностей конструктора недостаточно, можно перейти к SQL-фрагментам:

const result = await db

  .select({

    total: sql<number>`count(*)`.mapWith(Number),

  })

  .from(users) 

Это удобно для агрегатов, CTE, специфичных для конкретной СУБД функций и других случаев, когда бороться с абстракцией сложнее, чем явно описать запрос.

Когда Drizzle особенно полезен

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

  • пишут на TypeScript и работают с PostgreSQL, MySQL или SQLite;

  • знают SQL и хотят контролировать реальные запросы;

  • сталкиваются с ограничениями Prisma или TypeORM;

  • не хотят дублировать описание таблиц и TypeScript-типы;

  • планируют внедрять ORM постепенно, без перестройки всей архитектуры.

Drizzle не привязан к конкретному фреймворку. Его можно использовать с Next.js, NestJS, Remix и другими TypeScript-решениями.

Но «магии» здесь действительно меньше

Это одновременно преимущество и ограничение Drizzle. ORM не скрывает работу с базой и не берёт на себя всю инфраструктуру.

Миграции нужно отдельно встроить в CI/CD, read/write split для реплик — реализовать на уровне приложения. Drizzle работает только с SQL-базами, а его экосистема пока меньше, чем у более зрелых ORM. Проект активно развивается, поэтому документация иногда не успевает за изменениями API.

Если команда рассчитывает почти не соприкасаться с SQL, такой подход может показаться слишком низкоуровневым.

Drizzle — это не ORM для тех, кто хочет забыть об SQL

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

В полной версии статьи я подробнее разобрал описание связей, миграции, CRUD-операции, CTE, транзакции, оператор sql, расширения и ограничения Drizzle ORM.

Буду рад почитать о вашем опыте работы с Drizzle в комментариях. 

Теги:
+5
Комментарии0

От разработки в конфигураторе до архитектуры: 4 материала для 1С‑разработчиков

Современная разработка на 1С давно требует больше, чем знание встроенного языка и умение создавать формы. В больших проектах приходится выстраивать командную работу, работать с требованиями, проектировать архитектуру и искать причины проблем с производительностью.

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

🔹 «Командная разработка на 1С через EDT и Git: пошаговая настройка проекта»

Статья о том, как перейти от индивидуальной разработки к полноценному командному процессу. Разбираем настройку проекта в EDT, работу с Git и подходы, которые помогают разработчикам эффективно взаимодействовать при изменении конфигурации.

🔹 «Готов ли ты стать функциональным архитектором 1С?»

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

🔹 «Система компоновки данных в 1С»

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

🔹 «Управляемые блокировки в 1С»

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

Бонус: бесплатные уроки по 1С‑разработке

  • 28 сентября, 20:00. «Валидация требований с ИИ в техническом проекте». Записаться.
    Разберем, как использовать ИИ при работе с требованиями и проверять технические решения на этапе проектирования.

  • 29 сентября, 20:00. «Модульные тесты YaxUnit в связке с EDT». Записаться.
    Познакомим с подходом к автоматизированному тестированию 1С‑проектов и разберете работу с YaxUnit в современной среде разработки.

  • 22 октября, 20:00. «Оптимизация запросов 1С». Записаться.
    Разбираем, как находить узкие места в запросах и повышать производительность решений на 1С.

Теги:
+5
Комментарии0
1
23 ...