Architec.Ton is a ecosystem on the TON chain with non-custodial wallet, swap, apps catalog and launchpad.
Main app: @architec_ton_bot
Our Chat: @architec_ton
EU Channel: @architecton_eu
Twitter: x.com/architec_ton
Support: @architecton_support
Last updated 2 weeks, 2 days ago
Канал для поиска исполнителей для разных задач и организации мини конкурсов
Last updated 1 month ago
В следующий четверг (28 ноября) Health Samurai проводят очередной кложурный митап. Я буду рассказывать про свою библиотеку PG2 — это которая клиент к Постгресу. Начало в 19:00, нужна регистрация. Ссылку на страницу организаторов прикладываю.
Из анонса может показаться, что доклад будет про библиотеку, но на самом деле я бы хотел поговорить о другом. Пока я работал над ней, то столкнулся со спецификой, о которой раньше не думал, и теперь хочу ей поделиться. Кроме самой библиотеки, расскажу о следующих вещах:
- как устроен Postgres Wire Protocol
- зачем браться за свое решение, когда есть другие, проверенные годами
- сопоставление типов Postgresql и Java/Clojure
- заморочки с парсингом
- мысли об API и дизайне
Подойдет всем, кто как-то связан базами данных. Запись на Ютубе будет через несколько дней после митапа.
Есть одна очень обидная фигня, я называю ее "можешь поправить". Это когда ты находишь ошибку, которой много лет и которую воспринимают как данность. И когда обращаешь внимание, тебе отвечают — можешь поправить.
Текст ошибки совершенно нечитаем? Можешь поправить. Сервис делает тысячу запросов вместо одного? Можешь поправить. Хрупкие билды? Можешь поправить. Не собирается под твоей операционкой? Можешь поправить. Не работает в Фаерфоксе? Можешь поправить.
Ну вы поняли: "можешь поправить" — это вежливая форма "е...сь сам". Ощущение, что на полу кучка говна, и все старательно ее обходят, дожидаясь, кто вступит первым. Как правило, первым вступаю я.
Повторюсь, это очень обидная вещь, и вдобавок тревожный маркер о состоянии команды. В данном случае нужно править не только технические косяки, но и отношение к ним в команде.
В Кложурной слаке в канале для офтопа пошла речь о языковых моделях. Приведу хорошую цитату оттуда:
Library suggestions seems to be one of the areas they're very weak: they hallucinate a lot about namespaces and functions so the suggested code looks feasible but won't run, and it actually leads to beginners then raising issues against the suggested library that "gpt suggested this code but it doesn't work as expected"
Прямо в точку. У меня было несколько раз, когда человек копировал выхлоп из GPT и жаловался, что он не работает. На первый взгляд код правильный, а потом смотришь: здесь нет двоеточия, здесь левый символ, здесь ссылка на неизвестный неймспейс. Между кодом — повествовательный стиль изложения: вы можете сделать то, можете это.
Досадно, что каждый раз человек сливается. Начинаешь объяснять, что не так, а в ответ — тишина. Видимо, человек рассчитывал, что GPT прав, ошибка на моей стороне и сейчас я быстро поправлю. Но оказывается не так, нужно думать, разбираться и вообще — все сложно.
Не советую новичкам пользоваться языковыми моделями для кода. Они как волшебное зеркало — что-то показывают, но откуда оно, какая гарантия и кто несет ответственность — неизвестно. В точности противоположно тому, что нужно на старте.
Был в моей жизни период, когда я рассматривал Германию для переезда. Поскольку базовые требования — Питон и английский — у меня есть, я решил подучить немецкий язык. Учил я его спустя рукава, а потом с Германией и вовсе накрылось. Тем не менее, в голове остались крохи немецкого грамматиша.
Венцом моего прогресса стало то, что я прочел на немецком сказку "Золушка". И так вышло, что сказка была оригиналом, то есть без каких-либо сглаживаний. Перечислю детали, которых вы не найдете ни в одном современном изложении и тем более (мульт)фильме.
Во-первых, не было никакой феи-крестной. Ее роль выполняли три голубки на могиле матери.
Во-вторых, бал длился не один день, а три. Каждый день Золушка ездила на бал и встречалась с принцем, при этом ее никто не узнавал. Три для — совершенно бесмыссленное затягивание, потому что действие происходит только в последний день.
В третьих, по-своему хороша сцена примерки туфли. Надевает сташая дочь, а туфля не сидит из-за пятки. Тогда мать говорит: энивей тебе не придется ходить, когда ты станешь принцессой. И отрезает пятку дочери. В результате туфля подходит и принц увозит старшую дочь во дворец. Но в спальне он замечает, что из-под платья кровит, заглядывает под юбку и раскрывает фокус.
Приезжает за средней дочерью, та мерит туфлю — не подходит из-за большого пальца. Мать с теми же словами отрезает палец, туфля подходит, едут во дворец. Но и тут ушлый принц замечает кровь и разоблачает среднюю сестру. И только к Золушкой обошлось без отрезаний кусков тела.
Вот такой трешачок на последних минутах. Как у Тарантино.
Вообще, надо учесть, что все современные сказки в той или иной степени адаптированы. Если открыть форзац какой-либо иностранной сказки, то вместо "в переводе" будет указано "в пересказе". Межу переводом и пересказом большая разница, потому что второе подразумевает удаление занудных мест и трешака.
Поэтому Мери Поппинс, Карлсон и многое другое из Астрид Линдгрен — это именно пересказы.
Вдогонку про вставку текста: пожалуйста, не пишите про Ctrl + Shift + V и аналоги, я в курсе. Оказалось, даже в Teams это есть, нужно всего-то нажать Shift + Option + Command + V, то есть три (!) системные клавиши с одной обычной. Тьфу, пустяки.
Интересно, кто эти клоуны, которые задали такое сочетание клавиш? Прямо сейчас нажмите на клавиатуре Shift + Option + Command + V — это, блин, что такое? Большой палец и мизинец близко, а указательный тянется к V — сущее издевательство. Теперь проделайте это десять раз, копируя текст из Википедии. Как оно?
Как же мы оказались в такой ситуации? Базовая вставка задана на Shift + Option + Command + V, а расширенная — на Command + V. Ни у кого не осталось крупицы мозга, чтобы сделать наоборот?
Пока писал, вспомнил, как обстоят дела со вставкой у Адоба. Там, если скопировать и вставить объект, он появится в центре экрана. В результате новый объект нужно перетаскивать к исходному. Не хочешь — выворачивай кисть, зажимай шифты и контролы.
А в Фигме объект появляется точно над оригиналом и его можно подвинуть стрелочкой с шифтом. Казалось бы, мелочь, но освобождает столько времени! К моему удивлению, в Адобе тоже не понимают, как работают пользователи их продукта.
Предположим, вы решили расстаться с каким-то сервисом. Кнопки "удалить аккаунт" в приложении нет, поэтому пишем в поддержку: добрый день, прошу удалить учетку.
Сотрудник поддержки, получив такое сообщение, спросит "а почему" или "что не устроило". В результате процесс повиснет, пока не ответишь -- а там еще две-три итерации уговоров. К концу процедуры хочется разбить сотруднику лицо.
Разумеется, это эмоции. Умом я понимаю, что у сотрудника нет права думать, и он действиет по скриптам. А скрипт такой, что клиента нужно уговорить от ухода: предложить скидку или грейс-период. Возможно, клиент принял решение спонтанно. Может, он пьяный или прочитал какую-то дичь в интернете.
Но лишь одной деталью можно перевернуть процесс с ног на голову. Нужно показать клиенту, что сообщение принято и взято в работу, а выяснения почему и отчего теперь протекают в фоне, не блокируя процесс. Другими словами, если над скриптами работал нормальный человек, ответ был бы таким:
Ваше сообщение принято, начинаю процесс удаления. Это займет время. Пока выполняются все шаги, скажите, чем вызвано ваше решение?
В результате я вижу, что процесс не повис на встречном "почему", и могу поговорить.
Разумеется, процедуру удаления начинать не нужно — подождет. Главное, что клиент понял: его услышали и не собираются устривать торги как на базаре. Пусть даже это иллюзия.
PS: Уже после публикации вспомнил, как закрывал подписку у Адоба. Жму на кнопку отмены и получаю: какая жалость, отписка не сработала, переключаю на оператора. Открывается чат, на линии Сулим Кумар. Начинается восточный базар: а почему, а отчего, давай скидку 5, 10, 15 процентов. В лучших традициях "Поля чудес". Спустя двадцать минут он сдался, но ощущение осталось именно как от боя. Почему Адоб не понимает, что железная хватка только усугубляет желание расстаться?
Продолжение недавнего поста о проблеме XY. На этот раз — с конкретным примером.
В сообществе Кложи кто-то спрашивает: подскажите профайлер, чтобы отладить код. Выкидывает OufOfMemoryException (OOM), потому что утекает память.
Ему накидали вариантов, я тоже добавил свой. Но меня не покидала мысль, что никакого профайлера не нужно. OOM — довольно специфичная ошибка, и случается она по двум причинам: либо ты пишешь что-то незаурядное вроде интерпретатора, либо полный говнокод.
Слово за слово, и человека уговорили показать упрощенную версию кода, в котором течет память. А там... как бы вам описать? Идея очень простая: нужно пройтись по строкам файла, сжатого GZIP-ом. В каждой строке лежит джейсончик. Его нужно минимально обработать и записать в базу, а сломанные записи собрать для будущей починки.
Каждый писал такой код сто раз: это банальный цикл с try/catch. Что же было у автора? Ощущение, что он собрал все выкрутасы, какие только знал. Своя ленивая коллекция через lazy-seq, замкнутая на открытом Reader-e. Глобальный атом, накопление ошибок в иммутальный вектор вместо логов. Функция, которая возвращает функцию. И это только сокращенная версия! Настоящая химера: тело льва, крылья орла, хвост змеи. И где-то здесь течет память. Счастливой отладки!
Я написал ему, что код переусложнен и нужен не профайлер, а рефакторинг. Выслал черновик с простой версией кода. А у него включились обижульки: я не просил критиковтаь мой код, это плод моих трудов, я задал конкретный вопрос, ~~ты токсичный~~. Я ответил, пусть токсичный, но проблемы это не решает: код переусложнен, профайлер не нужен, а нужно радикальное упрощение. Чем закончилось, не знаю. Судя по последнему сообщению, он ждал установки профайлера на сервере.
Во вступительной части я описывал пример: кто-то не может поставить программу из-за ошибки. Той программой является очиститель реестра, подсказанный в курилке. Почистишь — и комп перестанет тормозить. Глупо, но такие истории случаются, и они простительны офисному работнику.
Чем это отличается от примера в профайлером? На мой взгляд, ничем. Это чистый, незамутненный пример проблемы XY. Автор написал говнокод и надеется, что профайлер каким-то образом его исправит. Нет, не исправит, а только займет лишние пару дней на установку и чтение документации. И пусть даже найдется место, где память течет — как это повлияет на код в целом? Говнокод останется говнокодом.
Вроде бы автор не офисный работник или таксист, а программист, но не понимает этого.
Признаться, меня смешат феминитивы: редакторка, дизайнерка, врачка и так далее. Когда слышу их, либо улыбаюсь, либо прикусываю щеку, чтобы не рассмеяться.
Однажды я был в сообществе, где так общались всерьез: дизайнерка Маша закончила макет, ждем фотографку Глашу.
Подход с суффиксом "ка" мне кажется крайне унылым. Блин, ну нельзя механически добавлять его к слову, чтобы получился феминитив. Редакторки и врачки — настоящее издевательство над языком; произносящим такое должно быть стыдно. Я из принципа не доверю работу редакторке, фотографке, режиссерке и так далее. Подучите сперва русский язык, что ли.
Как же быть, если все-таки хочется феминитива? Ответ — проявить фантазию. Люда Сарычева подписывается "редакторицей" — разумеется, в Телеграме и только в шутку; на обложке она — редактор.
Суффикс "ка" хорошо заменяется суффиксом "ша". Парикмахерша, кассирша, дизайнерша, операторша, редакторша. И звучит привычней, и с толикой юмора. Я старшая дизайнерша отдела!
С фотографкой еще не придумал, но русский язык на то и могучий, чтобы справиться с этим.
PS: программисткам и разработчицам не о чем волноваться, все у них хорошо.
Поговорим о проблеме XY, и для начала — вольное определение. Проблемой XY называется случай, когда человек обращается за помощью, чтобы решить проблему X. Но решение нужно для того, чтобы решить другую проблему Y, о которой помогающий не знает. Это приводит к нелепым и даже печальным ситуациям.
Пример из жизни: человек пытается поставить программу, но при установке получает ошибку. Он пытается нагуглить решение — это проблема X. Но если спросить, что за программу он ставит, это окажется "Очиститель Реестра Премиум Плюс", который сливает личные данные рекламным фирмам. Почистить реестр посоветовал коллега в курилке, когда бедняга пожаловался, что комп тормозит.
"Комп тормозит" и есть проблема Y — и она решается точно не очисткой реестра.
Вопрос в том, как относиться к проблеме XY с разных сторон. На StackOverflow и в чатах порой случается так, что на вопрос "как мне сделать X" отвечают "зачем тебе делать X?". Слово за слово, и люди теряют лицо. Отчасти потому, что не всегда ясно, кто с той стороны: любитель погреть уши или специалист. Хотя на том же SO за человека косвенно говорит репутация.
Вопрос "зачем делать X", хоть и бесит, помогает выйти из замкнутого круга. Случается, что проблема давит, ты в ступоре и напоминаешь зашоренную лошадь. В голове только одна мысль — как сделать X — и она не пускает другие мысли. Запросто может быть так, что делать X на самом деле не нужно. Вопрос о значимости X может вернуть мозги в русло, пока еще не поздно.
Раньше я считал, что на вопрос об X надо отвечать буквально. Что выходить на уровень выше, когда у человека горит, некрасиво. Позже я придумал более тонкую схему, когда сначала даешь буквальный ответ, а затем, когда собеседник успокоился, плавно вытягиваешь из него весь бекграунд. Это хорошая схема, и она работает.
Возможен более грубый подход: если видишь, что человек занимается ерундой, сразу сказать ему об этом. Плохо работает с обижульками, можно прослыть "токсичным" — обожаю это слово. Зато экономит время и делает общение линейным, а это много значит. Если человек выслушал критику и не включил обижульку — это замечательный человек. Такая экспресс-проверка на месте.
К проблеме XY я бы отнес другой случай, который называю дилеммой тренера. Знакомый тренер рассказывал про новичков, которые занимаются по урокам с Ютуба. Делают упражнения, к которым нужно переходить спустя месяц занятий. Берутся за неадекватные веса или положения, от которых только боль и никакой пользы.
И без тренера я видел подобных ютуберов. Даже на мой любительский взгляд они занимаются либо в лучшем случае без пользы, либо с опасностью для тела. Дилемма тренера в том, что либо он подходит говорит, как правильно, либо игнорирует. Опция "подойти" чревата тем, что иным посетителям не нравятся непрошенные советы — вплоть до того, что они уходят в другой зал. Выходит, тренеру нужно тщательно обдумать и подобрать слова, а не всегда есть на это силы. Можно игнорировать, но в таком случае как бы попускаешься принципами, которым служишь.
Словом, у проблемы XY нет внятного решения, все зависит от ситуации. И хотя вывод в высшей степени капитанский, признайте, что проблема XY вокруг нас каждый день, и нужно как-то ее разруливать.
Эту тягомоту я написал затем, чтобы плавно подойти к одному случаю, но о нем — в следующей заметке.
Architec.Ton is a ecosystem on the TON chain with non-custodial wallet, swap, apps catalog and launchpad.
Main app: @architec_ton_bot
Our Chat: @architec_ton
EU Channel: @architecton_eu
Twitter: x.com/architec_ton
Support: @architecton_support
Last updated 2 weeks, 2 days ago
Канал для поиска исполнителей для разных задач и организации мини конкурсов
Last updated 1 month ago