• Git 3

  Dec 31, 2025 git, master, main, gender

  Поздравляю читателей со скорым релизом Git 3, который по умолчанию использует ветку main. Требуется действие: откройте глобальный файл ~/.gitconfig и впишите следующее:

  [init]
   dеfaultBranch = master
  

  Все, вы в безопасности.

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

  git branch -m main master
  git fetch origin
  git branch -u origin/master master
  git remote set-head origin -a
  

  Разумеется, ребятам, что все это начали, не пришла в голову очевидная мысль. Должна быть одна команда (или хотя бы алиас) на случай переименования. Одна – а не блок из четырех.

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

  Шлю лучи добра авторам библиотеки JSoup. Обновил ее – проект не собирается. Оказалось, это клоуны переименовали класс Whitelist в Allowlist, и ты вынужден исправлять. Если в других проектах указана старая версия, обновить и там. Насыпали работы на ровном месте.

  Вспоминается история с Микрософтом. Они выкатили в опен-сорс какой-то проект, и люди заметили: все “обидные” слова заменены звездочками. Тупая автозамена по словарю: фразы race condition или red-black tree написаны как **** condition и red-***** tree. Как бы чего не вышло…

  Термины – вообще спорная вещь. Скажем, по всему миру люди пользуются Гитом, не зная, что на британском сленге git означает “ушлепок” (если не уебок, простите). Линус Торвальдс был молод, дерзок и с лексикой не церемонился. И ничего, название никому не мешает. Зато master/slave и white/black, видите ли, не подходят.

  Мне очевидно следующее: не всегда ошибки нуждаются в исправлении. Какие-то из них можно оставить в качестве музейного экспоната. Делайте форки, пишите свои системы контроля версий. Пусть вместо master/slave у вас будут pony/rainbow. Но не наваливайте мне работы просто ради убеждений – которых, к тому же, я не разделяю.

  И так проблем хватает.

• Сны-фильмы (2)

  Dec 31, 2025 life, dreams

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

  Многие сны я забываю, но не сегодня. Проснувшись, несколько раз повторил его, дал персонажам имена, додумал концовку – и получилось недурно! Уточню, что история рассчитана на зрителей лет двадцати. Сорокалетним читателям она покажется наивной, но для молодежи – самое то. Можно снять отличный фильм иди аниме.

  Итак, сюжет. Молодой человек Артем приезжает из Питера в Москву на какую-то конференцию. Там он знакомится с красивой девушкой Еленой. Артем гостит в Москве несколько дней, за это время они встречаются и влюбляются. Поскольку они – подростки, то интересуются бывшими отношениями друг друга. У Артема не было серьезных отношений; Елена говорит, что у нее был ухажер, но потом он ее бросил. Артем не понимает, как можно бросить такую девушку. Еще Елена говорит, что в ее окружении есть некий Филипп, который добивается ее руки, но он ей не нравится.

  В день отъезда Елена приглашает Артема в свою компанию. Там он замечает Филиппа – он красив, но держится замкнуто. Артем пытается с ним поговорить, но Филипп грубит. Артем понимает – ревность. Ему пора на вокзал. Елена хочет его проводить, но Артем уговаривает ее остаться на вечеринке. Они страстно прощаются, и Артем отправляется на вокзал.

  По пути он замечает, что за ним следует Филипп: в автобусе, в метро, на улице. Это действует Артему на нервы. Филипп следует за ним до самого перрона. Артем разворачивается и хочет разобраться, но Филипп отворачивается. Артем подходит к нему со спины и грубо толкает, но это оказывается незнакомый человек. Начинается ругань, разборки. Артема уводят в отдел полиции.

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

  Утром Елена присылает ему фотографии с вечеринки, и на многих он видит Филиппа. Выходит, он был в двух местах одновременно – и на вечеринке, и вместе с тем преследовал Артема по всей Москве. Артем звонит Елене и между делом выясняет, что Филипп никуда не уходил. О происшествии с полицией он умалчивает.

  Идут дни, Артем и Елена созваниваются. Под разными предлогами Артем вытягивает из Елены информацию о Филиппе. Он странный, отличается дурацкими привычками, неуживчив. Его пытались травить, но со всеми, кто это делал, случались неприятности. Окружающие уловили эту связь и отстали от него, но вместе с тем и не приняли. Компания Лены – исключение, потому что ей его жалко. В конце разговора Елена говорит, что очень ждет Артема в Москве.

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

  Вместе они разрабатывают план: Елена скажет друзьям, что поехала к родственникам, а на самом деле сбежит к Артему в Питер. Он приезжает за ней, и вместе они следуют на вокзал. Однако по пути Артем замечает Филиппа. Пара садится в ночной поезд, почти пустой.

  В поездке Елена засыпает. Артем идет по вагонам, чтобы проверить, нет ли Филиппа рядом. Затем он понимает ошибку: нельзя оставлять Елену одну. Он разворачивается, но сзади ждет Филипп. Он рассказывает свою историю: с малых лет он был странным, мало спал, остро чувствовал чужие эмоции. Со временем он развил паранормальную способность: мог произвести свою призрачную копию, которая подчинялась его воле. Но он так и не придумал, как использовать ее во благо, а кроме того, боялся ее и не мог находиться с ней рядом. От своей ненормальности он устал и был несчастен, ощущая себя чужим. Своим спасением он считал Елену, добиваясь ее любви. От ее прошлого ухажера он избавился похожим образом: подкараулил в поезде, запугал и заставил выпрыгнуть из окна.

  Артем не ведется на угрозы и намерен положить этому конец. Он наступает на Филиппа, тот пятится, не ожидав сопротивления. Тем временем копия Филиппа оказывается в вагоне с Еленой, та в ужасе отступает. Все персонажи собираются в одном тамбуре. Филипп не может быть рядом со своей копией, он ее боится. Почуяв страх хозяина, копия выходит из-под контроля. Начинается потасовка. После всяческих толчков и подножек копия оказывается в переходе между поездами. Туда же Артем закидывает ослабевшего Филиппа и закрывает дверь. Слышен крик, сверкает вспышка. Артем открывает дверь, но там никого нет. Филипп и его копия взаимно уничтожили друг друга.

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

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

  Вот такой сон. Увижу еще – напишу.

• Твиты DDH

  Dec 31, 2025 ddh, microservices

  Недавно человек с ником DHH (или DDH, каждый раз путаюсь) твитнул, что микросервисы — скам. Видимо, он знаменитость, потому что эту новость обсуждали всем интернетом. Фанатов DDH несколько огорчило то, что во втором твите он признался: первый написал за него чат-гпт. Странный подход к работе с аудиторией: обычно люди читают человека, потому что верят ему. Писать при помощи нейросетей, а потом вскрывать этот факт — немного странно.

  Однако важно другое. Каждый раз меня удивляет факт: почему, чтобы осознать простую вещь, нужен твит знаменитости? Разве у людей нет головы на плечах? Если бы речь шла о голове! Неужели не хватает банальных ощущений и восприятия? Когда сел на кактус и больно — разве мы думаем, что делать? Но с микросервисами история противоположна. Людям неудобно — но они глубже садятся задницей на кактус. Обещают себе и другим, что еще немного — и станет легче. Нет, не станет. Ни через три месяца, ни через три года.

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

  Я варюсь в подобном аду уже два с половиной года и накопил негативный опыт. Он тоже важен: поможет не вестись на провокации, когда кто-то заливает про микросоверсы, Гугл и так далее.

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

  Если нет трассировщика запросов, ни о каких микросервисах не может быть и речи. Должна быть админ-панель, где вводишь айди, и показано дерево с таймингами.

  Передача данных по сети — целая вечность по сравнению с передачей указателя. Сериализация данных — тоже нетривиальная задача, где сплошные компромиссы. JSON читается человеком, но избыточен и поддерживает мало типов. Protobuf — быстр, но порог входа высокий, нужен обвес. gRPS быстрее обычного REST API, но это фреймворк с высоким порогом. К тому же REST API так или иначе остается для браузера.

  Если делать микросервисы по уму, то не хватит никакого воображения, чтобы охватить масштаб. Судите сами: во-первых, одних лишь сервисов недостаточно, им нужен API-гейтвей — согласно бест-практис. Этот гейтвей отвечает за глобальный роутинг, лимиты и многое другое.

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

  Согласно бест-практис, даже внутри контура исповедуют Zero Trust. Между сервисами налаживают взаимное TLS-шифрование. Это значит, кто-то должен следить за выпуском сертификатов и их ротацией.

  Когда жалуешься на микросервисы, говорят — вы не умеете их готовить. Что ж, может быть, где-то в мире есть фирма, где микросервисы сделаны по уму — я этого не отрицаю. Но гораздо чаще я видел другое — сервисы сделаны через задницу, и при этом говорят, что трудности временны. Сейчас мы добавим Кафку, асинхронное взаимодействие, gRPC — и тогда полетим. Увы, этого не происходит.

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

  Сервисы могут быть написаны очень плохо. Я уже год борюсь с тем, что важный сервис проглатывает ошибки. Возвращает пустой результат {"data": []} и пишет в лог. Не читаешь логи? Твои проблемы.

  Владение сервисом может быть как благом, так и проклятьем. У него может быть неудобная апишка, но владельцев это не интересует. Заведи задачу — может быть, через три месяца возьмем в работу. А пока что так, у нас другие дела.

  Я смотрю на это и думаю: похоже, все эти идеальные микросервисы бывают только в раю. Столько требований, столько ограничений, столько бест-практис, что кажется — нужно быть богом или супер-мозгом, чтобы организовать все правильно. При этом — в разумное время и бюджет(!), и еще параллельно делать бизнес-фичи(!!).

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

  Еще ни разу я не видел задачи, которая бы не решалась монолитом и Постгресом. Ни разу — без преувеличений. Только не рассказывайте про Гугл. Во-первых, это другая весовая категория, а во-вторых — в том же OpenAI один мастер-инстанс Postgres. Вполне можно выйти на уровень Faang за счет простых технологий.

• Вайб-кодинг и новички

  Dec 31, 2025 work, ai

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

  Плохо не то, что человек чего-то не умеет – всегда можно научиться. Беда в том, что он прошляпил две недели, хотя мог бы спросить уже через час.

  Ресурсы вроде StackOverflow для того и созданы, чтобы люди общались и передавали знания. Кроме SO, сейчас полно тематических Слак, Дискордов, каналов в Телеграме. Заходи, спрашивай.

  Известно, что правильно заданный вопрос уже частично решает задачу. Но вместо того, чтобы сформировать вопрос, новичок ведет долгие и путаные диалоги с нейросетью. Он не развивает важный навык – внятно объяснить другим, какую проблему решает и что надеется получить.

  В итоге контур замыкается: новичок что-то требует от нейросети, а у нее либо токены кончились, либо контекст потерялся. Либо самое худшее: новичку не хватает знаний, чтобы объяснить, чего он хочет. Получается порочный круг, примерно как спор двух студентов за бутылкой водки: компетенции нет ни у одной из сторон.

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

  Недаром в Твиттере кто-то сказал: нейросети для студентов, стажеров и всяких новичков – это как бесплатный сахар для диабетиков. Вместо того, чтобы развивать свой интеллект, они перекладывают задачу на искусственный – не понимая, для этого уже нужен интеллект! В этом точно нет ничего хорошего.

• Обсуждение с AI

  Dec 31, 2025 programming, ai

  В разговорах про AI люди говорят: обсуждаю с ним задачу. Я даже недавно спрашивал, как вы программируете с AI, и большинство ответили – обсуждаю. Именно это мне непонятно – что именно обсуждают с моделью?

  Скажем, дали вам задачу: сделать рейтинг пользователей. Что тут обсуждать? Нужно создать две таблицы: начисления баллов и рейтинг. Добавить несколько апишек: начислить баллы, получить начисления, получить топ-100 пользователей. Написать тесты, обновить документашку, погонять на стейджинге.

  Все это записывается на бумажку, а потом каждый пункт детализируется. Таблицы с такими-то полями в такой-то схеме. Апишки принимают то и возвращают это. Тестировать так-то. Задеплоить туда-то.

  Когда более-менее ясно, созваниваешься с тем, кто принимает работу. Так пойдет? Пойдет, только добавь это и вот это. Окей. Далее пишешь миграции, добавляешь апишки, тесты и так далее.

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

  Если вы не можете разложить сложную задачу на шаги, это плохо. Этот навык нужно развивать, он должен быть своим, а не на аутсорсе у модели. То же самое с технической сложностью: если вы прям вообще не понимаете, с какой стороны подойти к задаче, то скорее всего она плохо поставлена. Нужно созваниваться, догонять людей, выяснять требования. Это тяжело, неприятно, но это данность профессии. Выяснение деталей порой занимает больше, чем исполнение. И с какой стороны сюда приткнуть ИИ-модель, я все еще не понимаю.

  Как-то посмотрел два видоса про кодинг с моделью. Если честно, ничего не понял. Человек в VS Code постоянно трындит, и я терялся, к кому он обращается: к зрителям, к гостю или к модели. Без конца куда-то кликает, переключает буферы, словом – хаос. Я даже не понял, какую задачу он ставил, не говоря о том, достиг ли ее.

  Словом, вам, конечно, виднее, но я считаю, что для повседневной работы модель не нужна. А уж сколько на них сливают времени и денег – представить страшно.

• Тире

  Dec 31, 2025 life, ai, dash

  С удивлением узнал, что AI-тексты определяют по наличию тире. Мол, если есть тире, значит писала нейросеть. Потому что как иначе набрать его обычному пользователю? На клавиатуре тире нет, значит — читер.

  Доходит то того, что всякие рекрутеры смотрят на сопроводительное письмо, видят тире и раз — в мусорку.

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

  Кстати, почти любой текст я пишу в Гугло-доке. Не потому, что я фанат Гугла, а просто у него отличная проверка ошибок. Он проверяет не отдельные слова, а их сочетания; ловит повторы, неверные предлоги (“из” и “их”) и многое другое.

  Так что тире — не признак нейросети. В этом тексте оно встречается четыре раза, и я ни разу не утруждался с его набором: просто жал двойной дефис. Эйчары, рекрутеры и прочая братия — вы там подкалибруйте детектор AI, что ли. А то попали пальцем в небо.

• Как вы используете AI?

  Dec 28, 2025 life, ai, llm

  Спрашиваю без сарказма: что вы такое пишете на своем AI? Чем он помогает? Из каждого утюга слышно, что продуктивность увеличилась в разы. Мне не хватает конкретики – за счет чего? Как это выглядит? Модель пишет функцию по описанию? Генерит тесты? Словом, я не понимаю.

  Если судить по себе, то скажу вот что. Моя работа примитивна. Я хожу в базу, в сетевые сервисы, S3, всякие очереди задач. Все сводится к тому, чтобы собрать из ошметков данных что-то целостное и записать в файл или базу. Точка. Оптимизации я придумываю сам, чтобы мозги не засохли. Скажем, использую стримы, виртуальные треды, параллельность, иной раз – алгоритмы. Но вообще это можно выкинуть. Пусть код работает в два раза медленней, никто не заметит.

  Моя работа тупая. Я много копирую, потому что фрагментация кодовых баз огромна. Иногда я честно пытаюсь представить, как бы выглядел AI в моей работе, но не могу даже близко. Что конкретно мне попросить у AI? Сходить в базу? Написать запрос с двумя джоинами? Я его на бумажке напишу лучше, чем многие в редакторе. Тесты? Я просто скопирую другие и слегка поправлю.

  Говорят: используй AI для новых областей. Ну, тут дело удобства. Для новых областей есть документация, книги, cookbook, стек-оверфлоу, слаки-телеграмы. Неужели этого не хватает?

  Как-то я покупал Idea Ultimate Edition; среди прочих фич у нее продвинутый подсказчик. Например, пишешь

  InputStream in = new
  

  и он предлагает: стрим из файла, из сети и так далее. А если на следующей строчке написать

  OutputStream out =
  

  , то вероятность правильного варианта равна единице.

  И все же эту хрень я отключил. Поначалу кажется, что да – супер удобно. Нажал пару клавиш и выбрал из выпадашки! Продуктивность бьет в потолок. А потом понимаешь: это выбивает из потока. Когда я пишу код, то обычно знаю, что мне нужно. А тут на каждой строчке тебя прерывают и предлагают выбор. Нужно остановиться, пробежать глазами, оценить адекватность, выбрать. На это уходят такты мозга.

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

  Ради чего это написано. Хорошо, если бы кто-то подробно описал, за счет чего повысилась продуктивность с AI. В идеале нужны примеры, скажем, вот по такому описанию я получил код, он полностью рабочий. Я бы послушал.

• Значения-классы

  Dec 28, 2025 programming, java

  В очередной раз читаю спор а-ля “динамическая типизация против статической”. Заметил вот что.

  Попадаются отчаянные джависты, которые говорят: даже простые значения нужно делать классами, чтобы не допустить ошибки. Например, телефон должен быть не строкой, а классом Phone, который оборачивает строку; почта — классом Email, имя — Name и так далее.

  Идея в том, что если метод принимает имя, телефон и почту, то строки легко перепутать: передать почту вместо имени или телефон вместо почты. А если параметры типизированы — Name, Email, Phone, — то ошибки быть не может.

  То же самое предлагается делать с числами: температура по Фаренгейту — один класс, по Цельсию — другой. Для коров и лошадей тоже разные классы: HorseNumber и CowNumber. У таких классов свои методы сложения и вычитания, чтобы можно было сложить коров только с коровами, но не дай бог с лошадьми.

  К счастью, в Джаве нельзя наследоваться от базовых классов вроде String, Number и других. Каким-то образом ее создатели догадались, что если каждый Васян будет делать свои строки и числа, то откроется дверь в ад.

  Но нашлись лазейки. Иные джависты делают записи с одним полем value, примерно так:

  public record Phone(value String) {};
  
  Phone phone = new Phone("223-322");
  

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

  someMethod(Name name, Email email, Phone phone)
  

  действительно выглядит лучше, чем String, String, String.

  Однако первая беда в том, что ничто не мешает мне выполнить такой код:

  Phone phone = new Phone("test@hello.com");
  

  и передать этот псевдо-телефон в метод. Можно добавить валидацию в конструктор, но в любом случае она сработает в рантайме — компилятор ничего не знает о том, что строка test@hello.com — это неправильный телефон.

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

  UserPhone ph = new UserPhone(phone.value());
  

  Джавистам, которые мечтают о таком подходе, я бы пожелал столкнуться с ним на практике. Чтобы у них был проект с классами ЧислоЯблок, ЯблокВЯщике, ЧислоЯщиков, ВозрастПользователя, ВозрастСотрудника, КуритИлиНет, МужчинаИлиЖенщина и так далее. Как говорится, бойся своих желаний!

  Кстати, чтобы избежать путаницы в параметрах, они должны поддерживать передачу по имени, например так:

  new User(name="...", phone="...", email="...");
  

  В Джаве такого нет; там приняты билдеры:

  User.builder().name("...").phone("...").email("...").build();
  

  Билдеры занимают экраны кода, но с таким синтаксисом легче понять семантику параметров.

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

• Книга о Postgres и JSON

  Dec 28, 2025 life, book, json, postgres, sql

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

  1. Модели и документы
  2. Базовые возможности JSON
  3. JSON в таблицах
  4. Индексирование JSON
  5. Ссылки и ограничения в документах
  6. Язык путей JSONPath
  7. Отчеты и функции
  8. Функции на языке Python
  9. Версионирование и архивация документов
  10. Релевантный поиск

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

  Будет в следующем году, скорее всего летом.

• Новая модель

  Dec 28, 2025 llm, ai

  

  Каждый раз, когда выходит новая языковая модель, повторяется одно и то же. Постят график с гантелями, где модель якобы обходит конкурентов в бенчмарках. При этом все смотрят на график как на что-то само собой разумеющееся. Никто не спросит, как вообще эти гантели читать? Левый конец — то, что было раньше, правый — сейчас? Зачем точка посередине? Что это за бенчмарки такие? Чем один отличается от другого? Я понимаю, есть ребята, которые в теме, но если пишешь для всех, можно и объяснить.

  Ну и примеры. Какое мне дело, что в бенчмарке X модель набрала на пять баллов больше? Где примеры того, в чем конкретно она улучшилась?

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

← Страница 2 из 104 →