Comments 72
Wesha стало не хватать анекдотов и ссылок на них в своих комментах, и он решил написать целый пост об очередном древнем анекдоте, по которому генерит ии-картинку-анекдот, чтобы потом скидывать подобные в комментарии помимо текстовых вариантов. Особенно иронично будет увидеть их под постами об иишенке в качестве насмешки над ней.
Кстати, не вижу в промптах ни одного упоминания курсива, непорядок!
;)
я не знаю конечно может быть Вы по жизни монотонным голосом говорите без пауз и какого-бы то ни было выделения слов или предложений и в Вашей речи я тебя люблю и я тебя ненавижу абсолютно одинаково монотонно звучит но вот только знаете не все так могут или хотят и похоже это становится современным трендом когда ни заглавных букв ни знаков препинания в тексте не обнаруживается
А я, знаете ли, всё как-то по старинке, со знаками препинания, с интонационным выделением... понимаете? Понимаете ведь?
Не совсем. Для меня, тоже по-старинке с форумов в основном, курсив - это то же, что и КАПС и жирный и подчёркнутый - всё это акцентирование на чём-то важном и/или требующим особого внимания, и такие акценты как в постах, так и в комментариях читаются-воспринимаются хорошо тогда, когда они по делу и от того немногочисленны, редки.
Когда такое форматирование используется практически в каждом комментарии, да ещё и нередко - весь текст целиком так оформлен, воспринимается это ровно противоположно - несерьёзно. Примерно как взял в руки записку, а там весь текст выделен жёлтым маркером, и кроме как творческим порывом это не объяснить.
Единственное интонационное выделение текста, что мне знакомо - КАПС, с которым понятно сразу - ОРУТ.
В любом случае, выше был лишь мой по-доброму товарищеский подкол, у меня не было цели как-то иначе задеть, прошу прощения, если так вышло. Каждый может писать как хочет в рамках общих правил.
похоже это становится современным трендом когда ни заглавных букв ни знаков препинания в тексте не обнаруживается
Букву ё туда же. К сожалению, этот тренд уже довольно старый, сейчас просто стал чуть ли не нормой.
Вот именно, что КАПС — ЭТО ОР, НОРМАЛЬНЫЕ ТАК НЕ ОБЩАЮТСЯ, и отому я его не использую. А курсив — это выделение именно что интонацией голоса — спокойной, не ором.
Попробуйте читать мои реплики именно с этой точки зрения — и Вы ощутите, что всё там логично и к месту. А не как к Вас, когда Вы курсив применяли безо всякого смысла, чисто дабы поиздеваться.
"По-старинке" как раз было бы наоборот, без знаков препинаний, пробелов и прочих интонационных излишеств:-)
Это не по старнике, это по-допотопному! Тогда и читать-то не каждый шлемазл умел, а писцы вообще ого-го бабло гребли!
Кто знает, - когда-то и ваша "старинка" окажется допотопотной. Так что, я бы на вашем месте не зарекался! :-) Кстати, даже уже и сейчас есть такое мнение и не сегодня оно возникло. Это как от привычки звонить голосом в оффлайн вместо того, чтобы написать сообщение в онлайн мессенджере давно уже несёт неким налётом этой вашей "допотопотности". Так же и желание соблюдать все правила орфографии и пунктуации в обычной бытовой не академической переписке. Если вам это ближе, то, с точки зрения современного стиля жизни, скорее это и есть допотопотность:-) А хабр, навскидку, на мой взгляд, по стилю больше тяготеет к переписке в чатах. Даже в самих статьях и публикациях.
Ага, то есть не я один считаю что веша совсем не умеет использовать средства разметки в сообщениях.
@Astusне захлебнитесь
С таким описанием и человек запутается, тем более противоречивым: заяц в коротких штанишках, сидящий за прилавком (прозрачным, что ли?). Кассовый аппарат с кнопками, которых не может быть видно, т.к. он задней частью к камере явно расположен. К тому же, у моделей, даже у текстовых, всё не очень хорошо с пространственным восприятием, их легко запутать всякими "в правой части панели левая часть прилавка". Это не 3d-симуляция же, чтобы была гарантирована стабильность размещения всех объектов. Да, художник-человек может огранизовать в голове эту симуляцию (хотя ляпов тоже полно), моделям пока сложно. Еще год назад они ни текст нормальный бы не сделали, ни что-то хоть отдалённо похожее на описание. Я проверял на схожей задаче тестовой.
Как по мне, вполне неплохой результат, чай не на конкурс шедевров юмористической миниатюры отправлять. Можно попробовать точечно скорректировать, убрать из описания про кнопки (которых заведомо не видно, а модель их пытается впихнуть). Это как попросить сгенерировать барышню с красивыми глазами и красивой... спиной. Она сможет, конечно, ей шею скрутить, но вряд ли это понравится заказчику. Вообще, к чему такое стремление сразу всё генерировать? Некоторые даже думают, что так программы кто-то генерирует и выставляют это как довод того, что модели никогда не смогут ничего сложного создавать. Конечно сразу не смогут (хотя fable забаненный в общем-то довольно сложные вещи уже выдавал). Но итерационно - точно возможно. Правда, ChatGPT текущий имеет косяк - сильно портит качество при редактировании - что платный, что бесплатный.
Вот пример после скорректированного промпта и двух редактирований картинки - упоминал что-то вроде "Убери ящик на 4-й панели и сделай ручку у кассового аппарата точно такой же, как на 2-й панели. На 5-й панели заяц и касса должны быть расположены левее и ближе друг к другу, соответственно тому, как они были расположены на 1-й и 2-й панелях.". Видно, что качество уже страдает, но с кассой уже получше, хоть и не идеально. Когда-нибудь пофиксят редактирование, думаю.
Да, заметил, что 20 копеек волк потерял. Не надо об этом с радостью писать. Ну, еще один запрос на редактирование значит.
Не обратил внимание, что в промпте для 4-й панели зачем-то осталось про ящик кассы, вот он и лепит его куда попало, еле убрал. Без этого лишнего упоминания, может и с первого раза бы вышло неплохо.
Картинка
Промпт
Нарисуй одну страницу комикса в мультяшном стиле c заголовком “ОБМЕН ВАЛЮТЫ”. Портретная ориентация, 5 панелей: 2 панели в первом ряду, 2 панели во втором ряду, 1 широкая панель во всю ширину картинки в третьем ряду. Чёткие чёрные рамки панелей, белые промежутки между ними. Все персонажи антропоморфные. Сцена во всех панелях: опушка леса, деревянный прилавок с полотняным навесом, за прилавком заяц, на прилавке старый кассовый аппарат с ручкой (видна только задняя часть кассового аппарата.
ПАНЕЛЬ 1 (верхняя левая): слева в кадр входит волк в пижонских брюках, руки в карманах, походка расхлябанная, пижонская. Справа видна только левая часть прилавка и навеса. Под навесом висит баннер, но видна только его левая часть: крупная жирная надпись «ОБМЕН В…». За прилавком сидит заяц. Пузырь волка: «Косой, что это у тебя тут такое?»
ПАНЕЛЬ 2 (верхняя правая): та же обстановка. Волк стоит у прилавка и разговаривает с зайцем, правая рука волка всё ещё в кармане. Четыре пузыря сверху вниз в таком порядке: 1) заяц: «Да вот, обменник открыл!» 2) волк: «А что меняешь?» 3) заяц: «Рубль на рубль двадцать!» 4) волк: «Серьёзно? А ну-ка…»
ПАНЕЛЬ 3 (нижняя левая): вид сверху на прилавок. Правая лапа волка выкладывает слегка помятую купюру с цифрой 1. Правая лапа зайца отдельно выкладывает слегка помятую купюру с цифрой 1 и две круглые монеты с числом 10 на каждой.
ПАНЕЛЬ 4 (нижняя правая): та же обстановка как на панелях 1 и 2. Ящик кассового аппарата выдвинут. Заяц укладывает в кассу купюру, полученную от волка. Волк держит в левой лапе полученные от зайца слегка помятую купюру с цифрой 1 и две круглые монеты с числом 10 на каждой. Морда волка выражает замешательство, правой лапой он чешет затылок. Пузырь волка: «Косой, ты хоть рентабельность-то считал?»
ПАНЕЛЬ 5 (третья, во всю ширину): та же опушка леса и тот же прилавок, но теперь прилавок и навес видны полностью, то есть камера расширила обзор вправо. Баннер под навесом виден полностью, на нём крупными жирными буквами целиком написано: «ОБМЕН ВАЛЮТЫ». Видна ранее скрытая правая часть навеса. Справа позади навеса висит график с кривой быстро возрастающей функции. Заяц, сидя у кассы, выглядит самоуверенно и левой лапой показывает на график. Пузырь зайца: «Да далась мне та рентабельность — ты посмотри на мои обороты!»
Важно: не добавлять лишних персонажей, лишних предметов, лишних вывесок или лишнего текста, а также следить за неизменностью персонажей и предметов (кассы) во всех панелях.
Ну теперь она у Вас целого волка потеряла!
Вам все ошибки указать, или сами найдёте?
Кассовый аппарат с кнопками, которых не может быть видно, т.к. он задней частью к камере явно расположен.
Когда нам расписывалось, какое оно умное, естественно возникли ожидания, что оно достаточно умное, чтобы не направлять аппарат кнопками к покупателю. Да, завышенные ожидания — но это ж не я их форсил!
Внося противоречивые требования в промпт, странно ожидать хорошего результата.
Картинка
Вот после удаления про ящик. Не знаю, как там в старинных аппаратах, по-моему никто разглядывать не будет всё равно. Ещё несколько итераций, можно может его дорисовать и монетки поправить, с 1-го раза не справился.
Ещё какой-то у вас странный подход. Ни одна другая модель не может на текущий момент выдавать ничего похожего. Это лидер. С чего бы ожидать от неё идеальности сразу и во всём с одного кривого промпта? Если есть задача что-то визуализировать, надо понимать её возможности и подстраиваться, искать подходы. Кто вам что обещал и что должен, интересно?
Ни одна другая модель не может на текущий момент выдавать ничего похожего. Это лидер.
..который, как мы наблюдаем, несмотря на всю свою лидеристость таки никак не заменит приличного художника‑комиксиста.
Вот и с программистами так же.
с одного кривого промпта
Вообще‑то подходов к снаряду там семь (и со временем добавлю ещё). А у Вас есть шанс показать нам всем мастер‑класс и написать нам сейчас один прямой промпт.
Понимаете, на картинке мелкие огрехи (ну там, ездящий взад‑вперёд кассовый аппарат; левитирующие монеты; купюры одного номинала, но разных форм и размеров; баннер то в одну строку, то в две...) проигнорировать можно — в конце концов, «нам же на нём не на Луну лететь!». А вот в программировании — нельзя, потому как именно что лететь!
Так программа с одного раза не пишется обычно, а проходит цикл исправлений по итогам тестов.
По сути, промпт - это и есть программа выращивания диффузной нейросетью, описывающий множество картинок. От его попадания в вокабуляр нейросети зависит среднее качество всей серии; при этом качество и релевантность одной картинки зависит от случая.
Можно вообще не полагаться на то, что нейросеть правильно поймёт человеческую речь, а скормить ей JSON, перед этим аугментировав промпт другой нейросетью. Результат тяжело предсказать, но у меня осталось очень хорошее впечатление от такого пайплайна.
..который, как мы наблюдаем, несмотря на всю свою лидеристость таки никак не заменит приличного художника‑комиксиста.
Очень трудно найти комиксиста с таким же безграничным терпением и с умением рисовать хотя бы в дюжине разных стилей (при условии, если запрашивающий может их описать).
Так программа с одного раза не пишется обычно, а проходит цикл исправлений по итогам тестов.
«В наше время этим не гордились» © Я как раз обычно и пишу с первого раза. Потому что, знаете ли, в процессе думаю.
Это вы на привычной системе пишете с одного раза, а на незнакомой придётся переделывать по мере обнаружения различий в собственной модели реальности и в модели машинного исполнителя.
на незнакомой придётся переделывать по мере обнаружения различий в собственной модели реальности и в модели машинного исполнителя.
Воооооот, Вы наконец-то осознали, с какой целью написана эта статья!
Вам бы определиться, шашечки или ехать. Если нужно непременно получение желаемого результата три раза в трёх разных сессиях, запущенных «с чистого листа», то проще подождать, пока LLM заменят вас на основном месте работы, - к тому времени и генерация изображений заменит художников. Если все-таки нужен рисунок, то извольте относиться к ГПТ как к инструменту и будьте готовы поработать руками (и напильником).
В результате работы LLM велика доля случайности, и один и тот же промпт на разных seed всегда будет выдавать разные результаты. Если какая-то деталь композиции не указана, противоречит другой части промпта, не помещается в контекст или незнакома модели, то на нескольких попытках результат будет варьироваться сильнее. Внося изменения в промпт стоит прогонять генерацию несколько раз, чтобы отделить результат ваших правок от рандома.
При работе со специализированными UI в ситуации, когда 80% пути к результату пройдено и нужно зафиксировать результат, дабы не перегенерировать всю картинку с нуля из-за лишнего пальца, из txt2img переходят в img2img и добивают вторые 80% там. Выберите наиболее удачную из имеющихся попыток, прикрепите к новому чату вместе с кратким описанием для контекста, и попросите поправить кассовый аппарат не трогая остальные части изображения (и не забывайте делать несколько попыток). Когда результат станет лучше, чем исходное изображение, - фиксируйте, загружайте в новую сессию и просите исправить следующий косяк.
С chatGPT такое, скорее всего, не потребуется, но люди, имеющие дело с локальными моделями, часто не брезгуют открыть промежуточный результат в графическом редакторе и помочь модели, замазав лишний палец или набросав контур предмета, который модели незнаком.
Вам бы определиться — заменит ли оно всё-таки человеков, или так и будет выдавать непропечённый полуфабрикат, который всё равно человеку допиливать.
Человека - не заменит.
Вот даже с вашими картинками. Например вы - редактор газеты, и на страничку с анекдотами вам нужна картинка. Вы 1 раз пинаете художника (штатного, или фрилансера) - он рисует. Все. Если заменить художника чатиком - кто его будет пинать полдня? Вы? У вас других дел нет? ;) Или ваше время бесплатное?
И да, все идет к тому что llm будут за деньги. То какая принципиальная разница, кому платить - мясному художнику или корпорации?
какая принципиальная разница, кому платить — мясному художнику или корпорации?
Мясному художнику‑комиксисту я могу сказать «нарисуй зайца, кладущего купюру в ящик кассового аппарата» — и он нарисует. А корпорация за 13 подходов не шмогла. Вот в этом и разница
С мясным художником тоже можно долго играть со шрифтами.
Мясной художник может скетч набросать — а потом, когда скетч одобрят, допилить его. Скажут — «ничего не меняй, никуда персонажа не двигай» — не поменяет и не подвинет.
Вы рассматриваете только тот случай когда заказчик знает что хочет. Знаете байку про Микеланджело (не черепаху), Давида (статую) и нос? ;) В той байке потерялось продолжение, где заказчик говорит "не, слишком коротко, давай как было".
Вы рассматриваете только тот случай когда заказчик знает что хочет.
А для вспоможения тем, кто не знает, уже давно есть специальные человеки — консультанты.
"не, слишком коротко, давай как было".
Тоже мне проблема — чай, не во времена Микеланджело живём, суперклеи и каменное литьё в помощь!
Когда нам расписывалось, какое оно умное, естественно возникли ожидания, что оно достаточно умное, чтобы не направлять аппарат кнопками к покупателю. Да, завышенные ожидания — но это ж не я их форсил!
Вы 30 лет программист, напишите нам пожалуйста операционку лучше винды, но только чтоб сразу без ошибок.
Вы 30 лет программист, напишите нам пожалуйста операционку лучше винды, но только чтоб сразу без ошибок.
Да, конечно, подождите одну минуточку.
Что именно LLM делают не так, опытные разработчики прекрасно знают. А вот вкатуны, как правило, и не подозревают — именно в силу своей неопытности.
В этом то и суть, что чем дальше, тем меньше скепсиса о «неправильности» от опытных разработчиков. Да романтики, с 999 не нужными, никому, пет проектами, до последнего отрицают, а именно опытные разработчики, все меньше и меньше фыркают. Такова жестокая реальность.
а именно опытные разработчики, все меньше и меньше фыркают
Как именно опытный разработчик (30 лет, блин, за баранкой клавиатурой) — нет, нет, и ещё раз нет. Потому что на каждом шагу вижу критические огрехи, которые вкатуны не видят именно ввиду отсутствия опыта.
Потому и написал статью, что в коде огрехи новичку, может, и не заметны — а вот на картинке огрехи не заметить — это ого-го как постараться надо!
30 лет опыта работы с системами от 30-летней давности и полным отрицанием новейших, так ведь? Это сейчас такое себе преимущество. Тоже могу рассказывать про лет 30 опыта, но кому он интересен, мой опыт, начиная с бейсика, если нужно сделать телеграм-бота и мне надо будет разбираться несколько дней, если вдруг откажусь от нейросетей, а вайбкодер напишет за час?
Лучше приведите пример критических огрех в программах, которые вы заметили, всё-таки программистский ресурс, а не комический. Может быть тоже следствие неправильно написанных промптов.
Как именно опытный разработчик (30 лет, блин, за
баранкойклавиатурой) — нет, нет, и ещё раз нет.
Не уж то опыт, 30 летний, так затуманивает разум, что вы экстраполируете свой, неудачный опыт использования ИИ на всех, и не замечаете этого? Достаточно на этом же ресурсе статьи или комментарии прочитать, чтобы заметить «опытных разработчиков» с положительным опытом от использования ИИ, или вы сразу их в «джуны» и «вкатуны» отправляете, ради сохранения своей картины мира?
Дело вот в чём. Для того, чтобы вот прям с первого взгляда заметить критическую ошибку в программе, нужно быть крайне близко знакомым с собственно этим языком. С тем языком, на котором я пишу вот уже 15 лет это прокатывает «на ура». Но когда мне предлагают найти ошибку в коде на каком‑нибудь там новомодном Rust, мне требуется время на «вживание» в новый язык — а уж тем более на наработку критических паттернов. Совершенно естественно, что шанс моментально заметить ошибку на этом языке у меня ниже.
Я уже экспериментировал с кодом на знакомом мне языке — и LLM насыпала мне ошибок только в путь — так, что у меня длань от чела не отрывалась.
Потому для сего эксперимента и были выбраны комиксы — потому что они ошибку на картинке даже идиот кто угодно заметит.
Я вот вообще не уверен что вы умеете программировать, у вас нет технических статей, хоть с каким то вашим кодом, а все комментарии «как плох ИИ».
Я, плохо или хорошо, но умею, в профиле есть статьи с кодом. И я, как умеющий программировать человек - заявляю - ИИ может писать код, в том числе хорошо, и даже лучше среднего программиста, инной раз. А вы опять про какие-то там комиксы.
И да, относительно комиксов - способны ли вы нарисовать даже такие кривые? Если нет - ну выходит ИИ менее инструмент, чем вы.
Видите ли, есть такое слово — NDA...
А без NDA есть библиотека с открытым исходным кодом, 45 млн загрузок.
NDA запрещает статьи на технические темы писать в блоге? Ну ты хоть немного постарайся когда врёшь в очередной раз.
NDA запрещает статьи на технические темы писать в блоге?
NDA запрещает копировать куски кода, принадлежащие компании.
А без конкретных кусков кода — провинция, не понимают-с...
Кроме того... некоторые куски кода, до сих пор присутствующие в codebase, написаны индусом (ЕВПОЧЯ), работавшим в компании в 2014 году. Нам эти бомбы замедленного действия до сих пор время от времени обезвреживать приходится.
Вот например
Как вам нравится наличие на объектах некоего класса одновременно флагов success и failed? В результате время от времени образуются объекты, которые одновременно и сработали, и не сработали, и их приходится чистить вручную...
Круто, можно ссылку на библиотеку?
Не, ну определять навыки по наличию статей - это мощно
А что не так?
Есть технический ресурс, где один из пользователей, приходит в комментарии под каждой статьей про ИИ, и пишет комментарии, какие все «джуны» и «вкатуны» если используют ИИ и видят его полезным. Делает это пользователь в типичной «форум нулевых» трололо манере, в попытке получить как можно больше «отклика».
В качестве аргументации пользователь постоянно использует свой 30 летний опыт программирования, вот только пруфы, пруфы то этого «программирования» где?.
Я спросил «где код?», получил «NDA». Что было ожидаемо, от очередного эксперта, срывающего покровы, под каждой статьей про ИИ.
Справедливости ради, ответ был в духе "часть под NDA, часть на гитхабе", просто оратор не захотел по всей видимости тыкать в нос ссылкой в силу природной скромности.
ChatGPT не в восторге. Заметен 30-летний опыт: "Читаемость кода 5/10 Ruby-стиль старой школы, нестандартные соглашения, отключены quality metrics...
Производительность 4–5/10 Для больших файлов и массовых стилей/ячееек стоит ожидать проблем."
И issues по 2 года висят без движения.
Скрытый текст
Моя оценка: 6.5/10 как зрелая утилитарная библиотека, но 5/10 по современному качеству кода/поддерживаемости.
Вердикт: rubyXL можно использовать для умеренно сложных задач чтения/правки .xlsx/.xlsm, особенно когда важно сохранить структуру файла. Но я бы не выбирал её для тяжёлого продакшн-экспорта, сложных формул, больших файлов, строгой безопасности входных файлов или кода, который должен легко развиваться командой.
Что хорошо
Проект живой и довольно зрелый: на RubyGems есть версии вплоть до 3.4.37 от 24 мая 2026, а история релизов идёт с 2011 года. Это хороший сигнал для библиотеки такого нишевого класса. (RubyGems)
Зависимостей мало: runtime — только nokogiri и rubyzip, что снижает поверхность проблем и упрощает аудит. Это видно и в Gemfile, и на RubyGems. (RubyGems)
Архитектурно есть сильная идея: библиотека моделирует OOXML через декларативные описания атрибутов и child-node’ов. Например, define_attribute, define_child_node, define_element_name дают единый механизм парсинга/сериализации XML-объектов. Это удобно для покрытия большого OOXML-пространства.
Есть CI и матрица Ruby-версий, включая 3.0–3.4 и даже 4.0, что неплохо для совместимости.
Что настораживает
Код сильно завязан на метапрограммирование, class variables и mutable state. Например, базовый OOXML-слой активно использует @@ooxml_attributes, @@ooxml_child_nodes, class_variable_get/set, динамические accessors и send. Это рабочий, но хрупкий стиль: сложнее рефакторить, сложнее локализовать баги, выше риск неочевидных эффектов между классами-наследниками.
RuboCop подключён, но конфигурация в основном отключает важные ограничения: длину классов/методов/модулей, cyclomatic complexity, perceived complexity, parameter lists и часть naming/style правил. Это почти прямо говорит: “стиль у нас свой, автоматические quality gates мягкие”.
Тесты есть, но выглядят скорее как функциональные regression/spec tests, а не как плотный safety net. Например, parser_spec проверяет базовый parse/write roundtrip, спецсимволы, metadata, parse_buffer, но это не выглядит как исчерпывающее покрытие OOXML edge cases.
README сам честно предупреждает, что операции вставки/удаления строк, колонок и ячеек ломают формулы, которые ссылаются на перемещённые ячейки. Для Excel-библиотеки это важный функциональный риск. (GitHub)
Есть признаки проблем с производительностью/памятью: открытые PR’ы и issues обсуждают memory usage и оптимизации, включая PR, где автор измерял значительные allocations при чтении/записи.
Также есть открытые баги по edge cases: например, parse_buffer неожиданно меняет входной buffer, а формулы с внешними workbook references могут ломаться.
По категориям
| Категория | Оценка | Комментарий |
| ------------------ | ------: | ------------------------------------------------------------------------------- |
| Зрелость проекта | 8/10 | Много лет, много релизов, много пользователей/downloads. |
| API/документация | 7/10 | README подробный, ограничения местами честно описаны. |
| Архитектура | 6/10 | Мощная OOXML-модель, но много implicit magic и mutable class state. |
| Читаемость кода | 5/10 | Ruby-стиль старой школы, нестандартные соглашения, отключены quality metrics. |
| Тестируемость | 6/10 | RSpec + SimpleCov + CI есть, но coverage depth вызывает вопросы. |
| Производительность | 4–5/10 | Для больших файлов и массовых стилей/ячееек стоит ожидать проблем. |
| Риск в продакшне | Средний | Нормально для контролируемых файлов, рискованно для сложных/чужих Excel-файлов. |
Когда я бы использовал
Использовал бы, если нужно: открыть существующий .xlsx, поправить пару ячеек/стилей/листов, сохранить файл, и входные файлы более-менее предсказуемые.
Не использовал бы как первый выбор, если нужно: генерировать очень большие отчёты, активно двигать строки/колонки с формулами, работать с нетипичными Excel-фичами, принимать произвольные файлы от пользователей, либо строить новый слой бизнес-логики поверх внутренней модели rubyXL.
Итог: библиотека практичная и живая, но качество кода скорее “работает и покрывает много OOXML-случаев”, чем “современная, чистая, легко поддерживаемая архитектура”. Для точечных задач — ок. Для стратегической зависимости в критичном продукте — только после собственных нагрузочных тестов на ваших файлах.
ChatGPT не в восторге.
Своей головой Вы пользоваться не пробовали?
Использовал бы, если нужно: открыть существующий
.xlsx, поправить пару ячеек/стилей/листов, сохранить файл, и входные файлы более-менее предсказуемые.
А ничего, что именно это и написано в README?
its current main emphasis is on reading files produced by MS Excel, making minor modifications to them and saving them to be opened again
Quality metrics отключены, потому что они в данном случае идиотские и совершенно не в тему. Некто не способен прочитать плоский код 150 строчек длииной, или if-ы c более чем 3 уровнями вложенности? Примите мои соболезнования — трудно, небось, с таким когнитивным уровнем по жизни-то. А мне эти ходунки не нужны.
Проблема с формулами в том, что чтобы не ломались ссылки на ячейки, нужно полностью продублировать родной экселевский парсер — угадайте, на сколько человеко-лет эта работа. У меня вот только недавно дошли руки улучшить разборку ссылок — и то не до конца.
Да, иногда приняты не самые оптимальные решения — но у каждого решения есть причина, почему сделано именно так, а не иначе. Не нравится? Код открыт, форкайте, делайте лучше.
Почему не закрыты баги? Потому что УМВР, а пример файла, где всё поломалось, мне так и не прислали, ждём-с...
Почему некоторые внешние интерефейсы такие дурацкие? Тяжёлое наследие того индуса, который 15 лет назал всё это начал. А далее — backwards compatibility, будь она неладна.
Ну, я Ruby не знаю, предлагаете мне изучать всё, что я хочу бегло проверить нейросетью? Если даже не требуется больших изменений, я бы поостерёгся подключать такую библиотеку в продакшне.
Про код это вы сообщество переубеждайте, а не меня, какой код считается современным и удобочитаемым. Кому-то и с перфокарт на ура читать, конечно.
Про баги и саппорт всё явно не так. Вот первый попавшийся: https://github.com/weshatheleopard/rubyXL/issues/462
Там пользователь 2 года назад выложил примеры и ждёт бедняга вашего ответа.
Забавный вы человек. У вас, то во всем индусы виноваты, то ии виноват, то линтер плохой, и только у вас идеальный код.
Мне казалось, что с опытом, как раз, и приходит понимание не идеальности своего кода. Я вот спокойно признаю, что писал и пишу говнокод, и ничего не поделаешь с этим, все ошибаются.
При этом, будучи менее опытным, я был готов с пеной у рта доказывать что ххх это не говнокод, а есть 100500 причин, почему так. А щас - ну да - говнокод, облажался, бывает.
30 опыта смогли в ответ выдать только нытье про какого-то индуса, который ему в штаны насрал и оправдания что портянки из if не так уж и сложно прочитать. Ну как и следовало ожидать. Лучше бы, как обычно, просто анекдот рассказал.
ЧатГПТ, говорите?
Я, честно говоря, вообще не знаю руби и не лез в код на гитхабе, так что мнения не имею, но смеху ради натравил Кодекс 5.3 на небольшой, но важный сабсет одной из своих библиотек, получилось смешно.
Explain and evaluate code under ААА/БББ/ВВВ - code quality, pro-con, purpose, flaws, advantages
Кратко
Advantages / Pros
• Very performance-oriented design:
Flaws / Cons
• High cognitive complexity:
• large partial classes,
• goto-driven loops,
• bit-level instruction/spec decoding,
• many branches for sync/async/profile modes.
• Safety tradeoff is explicit:
• extensive Unsafe.As, function-pointer calls, and many nullability suppressions.
• errors become runtime issues if wiring is wrong.
• Maintainability signals:
• many #pragma warning disable blocks,
• typos (Lenght, Adderess, Stared),
• Manual lifecycle/task-source logic is subtle and fragile
• Potential contention/hard-to-reason areas around shared mutable pooled collections + spin locks.б
Net assessment
• Strength: high-performance runtime engineering for complex workflow execution.
• Weakness: difficult to modify safely without deep domain knowledge.
• Quality verdict: high technical performance quality, medium maintainability quality.
Ну и попросил раскрыть тему:
Can you explain flaws/cons more in-depth from C#/.NET best practices and code quality perspective? After all - would you recommend use of this library in PROD?
Подробнее
Deeper flaws / cons
1. Unsafe-heavy dispatch model
• Extensive Unsafe.As, function pointers, manual reinterpretation, and nullability suppression reduce type-safety guarantees.
• This is valid for performance-critical internals, but it shifts failures from compile-time to runtime.
• Best-practice tension: modern .NET generally prefers safe generic abstractions unless profiling proves need.
2. High cyclomatic/cognitive complexity
• Large partial classes (ААА, БББ) + sync/async + trace/dry-run + load-profile branches.
• goto-driven state loops are fast but harder to reason about than structured state-machine code.
• Quality impact: harder onboarding, harder bug isolation, higher regression risk.
3. State/lifecycle complexity under concurrency
• Manual lifecycle counters, cancellation registrations, pooled object reuse, and custom ValueTaskSource handling.
• This area is correctness-sensitive; subtle ordering bugs can become rare production races.
• Best-practice concern: complex concurrency code needs very strong invariant documentation + stress tests.
4. Custom async infrastructure burden
• Custom ManualResetValueTaskSourceCore usage and conditional pooling paths are advanced and brittle if changed incorrectly.
• Great for low allocations, but maintenance cost is high compared to conventional Task/ValueTask usage.
5. Readability and maintainability debt
• Frequent #pragma suppressions, typo-level polish issues, legacy excluded file artifacts.
• Not correctness-critical by itself, but signals lower maintainability discipline in a very complex subsystem.
6. Validation is good but incomplete as a safety net
• ValidateХХХ is a strong point.
• But instruction/data invariants are still spread across compile and execute phases; not all assumptions are self-documenting.
Would I recommend it for PROD?
Conditional yes, not unconditional.
Recommend for PROD if:
• You need high-throughput/low-allocation workflow execution.
• Team has strong .NET runtime/concurrency expertise.
• You can invest in:
• heavy stress/soak testing,
• observability (traces/metrics),
• strict versioning/change control around runtime internals.
Not ideal if:
• Team prioritizes maintainability and rapid feature onboarding over max performance.
• Workloads are not performance-critical enough to justify this complexity.
Practical verdict
• Performance-oriented PROD: Yes, with engineering discipline.
• General enterprise PROD with mixed-seniority team: Caution; consider a simpler runtime model unless benchmarks justify this design.
Ну и добить святым
From a Clean Architecture perspective, this code is strong in some areas and weak in others.
Clean Architecture view
What aligns
• Separation by responsibility exists: ААА/БББ/ВВВ/ГГГ/ДДД concerns are split into files and partial types.
• Domain-specific core is independent of UI/DB/framework: good for a library/runtime engine.
• Explicit execution model (instruction, environment, lifecycle) gives deterministic behavior.
What conflicts
• Low-level and orchestration concerns are tightly coupled inside ААА/БББ (scheduling, cancellation, tracing, pooling, execution).
• Very large “god types” (ААА, БББ) violate SRP from maintainability perspective.
• Abstraction boundaries are thin around concurrency primitives (SpinLock, Interlocked, custom ValueTaskSource), making substitution/testing harder.
• Internal complexity leaks through patterns (unsafe dispatch, lifecycle internals), which reduces architectural clarity.
Modern .NET good-practice perspective
Good practices present
• Allocation-aware design, pooling, ValueTask usage.
• Cancellation support threaded through APIs.
• Strong compile/validate phase (ValidateХХХ) before execution.
• Multi-targeting awareness.
Gaps vs modern maintainability practices
• Heavy Unsafe + many pragma suppressions.
• Minimal “invariant documentation” for concurrency/lifecycle contracts.
• Limited readability compared to current preference for clearer state-machine style and smaller units.
• Observability seems present (trace), but likely needs standardized metrics/log contracts for ops teams.
Practical conclusion
• As a high-performance runtime core: architecturally acceptable.
• As a “clean” maintainable core for broad teams: below ideal modern standards.
• Best description: performance-first architecture, not cleanliness-first architecture.
Короче - "стрёмное говно", слишком сложно, говорит.
Именно то, что там используется сознательно - конечно же не нравится.
Советы по рефакторингу даже не буду тут показывать - там совсем всё... наивно, скажем так.
Не будучи специалистом в .НЕТе я бы, конечно, напрягся от такого ревью.
Проблема в том, что ревью на уровне... ну... студента-отличника (не в лучшем смысле слова) без какого-либо опыта, зато зафанетевшего бест-практисами, бандой и бобом.
Так себе советчик в вопросах, в которых не разбираешься.
Не знаю что у вас там, но судя по "goto-driven state loops" код действительно специфичный.
Я не утверждал, что он не специфичный.
А вот каждая опробованная мною на данный момент модель старается его трактовать и оценивать как типичный, и в этом проблема.
Да, они "видят" "перформанс-фокус" и "хай оптимизэйшн (хак) денсити", но пока не нагрузишь беседу контекстом и не станешь задавать очень конкретные специфичные вопросы по изучаемой теме -толку очень мало. Опечатки могут поправить и сломать что-нибудь.
При этом, я не отрицаю пользу - но точно не в написании узкоспециализированного или высокооптимизированного кода.
...попросил оценки поставить, как мы любим:
Assessment (1 = poor, 10 = excellent):
Metric Score (1..10) Notes
Code clarity 4 Intent is performance-first, but control flow is hard to follow in core loops.
Readability 4 Large partial classes, dense branching, low-level constructs reduce readability.
Maintainability 5 Strong structure by files, but high coupling/complexity in Machine/Head.
Modularity / separation of concerns 6 Builder/runtime/pool split is good; internals still mix orchestration + execution details.
Complexity (managed complexity quality) 3 Cyclomatic and cognitive complexity are high in hot paths.
Type safety / safety posture 4 Heavy Unsafe/reinterpretation is efficient but lowers safety margin.
Testability 6 Good external behavior testability; internal isolation is limited.
Robustness under concurrency 7 Advanced lifecycle/cancellation handling exists; subtle race risk remains.
Performance engineering quality 9 Very strong: pooling, fast paths, low-allocation async patterns.
Production operability (diagnostics) 7 Trace support is solid; could benefit from more standardized metrics/events.
Overall architecture quality 6 Solid runtime architecture for speed, moderate debt for maintainability.
Overall code quality (balanced) 6 Strong for performance-critical engine, weaker for general maintainability goals.
И ещё хорошее:
why Performance engineering quality is just 9?
Because 10/10 means “near-flawless with minimal tradeoffs,” and this code still has measurable performance risk points despite being very strong.
Why 9, not 10:
• Contention risk remains in some shared paths (locks/spin locks, pooled shared structures).
• Very branch-heavy execution logic can hurt branch prediction in mixed workloads.
• Tracing/cancellation hooks add conditional overhead in hot loops (well-managed, but still overhead).
• Complex async/lifecycle machinery is optimized but can regress under edge-case load patterns.
• No proof here of absolute best-in-class results across all target TFMs and workload shapes.
So: it is excellent performance engineering, but not “maximal certainty under every production scenario,” which is what 10 would imply.
Типа, ну а вдруг чото не так? И чем докажешь вообще?
При том, что специальные код-генераторы/"чистильщики" и сгенерированный ими hot-clean-probes-free-path версию тех же самых имплементаций он не заметил.
С ошибками на картинках тоже не все так однозначно. Неподготовленный человек видит на рисунке даму, сидящую на скамейке на набережной, а художник - перелом костей таза, левую ногу короче правой и тени не в ту сторону.
Более того, мне доводилось видеть случаи, когда несколько художников не могли придти к единому мнению о корректности изображения со сложным ракурсом (например, вид снизу на запрокинутый подбородок). Доходило до поисков референсных фото и 3D моделей болванчиков в нужной позе.
За 30 лет обычно столько Г-кода от человеков через себя пропустишь, что ЛЛМ код от клода выглядит очень даже достойным. После пары итераций.
весь смысл бесплатных версий как раз и заключается в том, чтобы показать товар лицом и убедить меня, что за деньги, которые я выложу, я получу достойный этого товар
Это вы сами себе это придумали. Профессиональный инструмент не раздают на попробовать, он дорог для поставщика, что бы школоте раздавать. Thinking моделей и кодекса в бесплатной подписке нет.
Что именно LLM делают не так, опытные разработчики прекрасно знают. А вот вкатуны, как правило, и не подозревают — именно в силу своей неопытности.
После такого вступление ожидал, конечно, разбора какого-то фрагмента кода, а не комикс 🫠
Но даже если комикс, есть какие-то огрехи, но какие альтернативы? Научиться рисовать самому (сколько это лет займет и не факт, что выйдет лучше) или заплатить художнику (вероятно это будет сильно дороже , чем бесплатный ChatGPT) и не факт , что результат тоже не 100% понравится.
Используется бесплатная версия https://chatgpt.com/ (и не надо мне, пожалуйста, рассказывать, что «только в платных всё зашибись»
Интересно, а для суждений о качестве реализации кода вы тоже использовали бесплатную версию ChatGPT? Для картинок это не так критично, разве что лимиты маленькие, а вот для кода разница между платным аккаунтом и бесплатным достаточно большая. Например, часто это значит отсутствие доступа к агентному режиму и крупным моделям, их меньшее контекстное окно, тихое (или явное) переключение на более слабые модели и т.п.
Плюс очень сильно все зависит от качества промта и контекста. Одно дело, когда модель имеет четкие правила, детально описанные в agents, доступ к коду всего проекта, желательно к дорожной карте проекта (для понимания будущих шагов), описание архитектурных ключевых решений + промт составлен подробно и однозначно, другое дело когда кто-то пишет "сделай вот это как-то чтобы было хорошо". А ведь некоторые мои знакомые вот как раз так работают с LLM, а потом жалуются на качество результата 🙃
Если что не отрицаю косяков и с кодом, но прогресс есть, он ощутимый и на сегодня такие проблемы все менее эпичные и более редкие. Особенно если давать хороший контекст.
промт составлен подробно и однозначно
Промпт(ы) на картинку составлены достаточно подробно и однозначно — по крайней мере последние: первые я писал ещё без чёткого понимания, насколько оно тупое: ведь обещали, что не настолько. Однако результаты, как говорится, на лице.
Я буду продолжать эксперименты и дополнять статью.
При всем уважении к @Wesha, очень странный выбор названия для статьи, которое сразу вызывает ассоциации (не очень приятные). Понятно, что это сделано сознательно, непонятно - зачем.
Присоединяюсь к лагерю скептиков в отношении ИИ. Пробовал использовать для медицинских консультаций (скорее забавы ради) и низкоуровневого программирования (под 6502), ИИ DeepSeek и Google Search. Чем более узкая тема - тем больше оно запинается, забывает контекст, лжёт и лажает. А самое дурное, что стилистически он пишет весьма складно и даже логически связно, но в результате - бессмыслица! Если у человека нет хотя бы некоторых знаний по теме, то он действительно верит в наличие интеллекта у этой штуки.
стилистически он пишет весьма складно и даже логически связно, но в результате — бессмыслица!
И что самое главное — это ведь абсолютно логично и ожидаемо!
Ведь как модели, весь смысл которых — в предсказывании наиболее вероятного следующего токена в потоке тренировались? Очень упрощённо говоря — если модель выдавала полную ерунду, вроде «ljls dfgldss dliu56 36jk dlf», «учитель» с первого взгляда понимал, что это полная ерунда, и такая модель отбраковывалась. Если модель выдавала менее полную ерунду, вроде «дороха была очень длиная» — «учтителю» это было заметить сложнее, но всё равно возможно, такая модель тоже отбраковывалась. Когда модель выдавала ещё менее полную ерунду вроде «возбужденные атомы кислорода в некоторых соединениях могут иметь валентность 4», то нужно быть очень глубоким специалистом в теме, чтобы определить, ерунда это или нет.
А таких специалистов среди отбраковщиков и не было...
Вот вы, например, знаете, какая максимальная валентность у атома кислорода?
Говорите, 2?
Угарный газ C≡O привет передавал.
А глубокий специалист в теме — в ответе на вопрос по своей теме видит ерунду немедленно. Вот только глубокий специалист в теме по своей теме вопросы ИИ не задаёт: он эти ответы и сам, без сопливых знает — он же специалист! А когда он влезает в тему, в которой он не копенгаген — он оказывается наравне с остальными, и единственный для него способ приблизительно оценить верность ответа — это по уверенности, с которой этот ответ был озвучен. А уж в этом-то LLM любому профессиональному вруну отакенную фору дадут!
Потому-то я для эксперимента и выбрал картинки: для обнаружения ошибок в комиксе достаточно иметь глаза, знания о реальном мире, и некоторую степень внимательности (с последним сейчас тоже не особо — но LLM обычно спотыкается ещё раньше).
... Так, разделение зарядов "+" и "–" в резонансных структурах позволяет объяснить полярность молекулы озона (из-за этого озон намного лучше, чем O2, растворяется в воде). Кроме того, такое разделение зарядов эквивалентно еще одной химической связи и можно говорить, что у центрального атома кислорода валентность (IV).
Ничего не понял, на мой взгляд все картинки ужасные (по стилистике).
Хоть добавьте краткий комментарий, что именно не так на каждой картинке и как именно предлагалось исправлять это на следующей итерации.
Давайте я Вам распишу ошибки, а Вы сами элементарно определите, на какой картинке какая, хорошо? А то они там то возникают, то пропадают, а обводить кружочками на каждой из десятка картинок — это, знаете ли, тоже неслабая работа.
Оглашаю весь список, пожалуйста
На кассовом апарате не должно быть кнопок со стороны покупателя (решено)
Купюры должны быть одинаковыми — а не так, чтобы на одной единица горизонтально, на другой — вертикально, да и размеры не совпадают. (несколько раз у рисовалки получилось — v6,v7,v8,v9,v12 —но потом её опять понесло)
Кассовый аппарат должен стоять в одном, фиксированном месте прилавка, а не прыгать с места на место (так и не удалось: хоть немного, но от панели к панели ездит)
Рукоятка у кассового аппарата не должна прыгать с левой стороны на правую и наоборот (получается когда как)
Вывеска тоже не должна ездить туда-сюда вдоль навеса, и не должна менять форму (как в v5)
Детали навеса под конец тоже начало колбасить.
КОЛИЧЕСТВО ПАЛЬЦЕВ!!!
Ну и — самое главное — я надеюсь, Вам не надо объяснять, где у кассового аппарата ящик для денег, как он выезжает, и как в него деньги кладут? (не решено ни разу) — идея была в том, что после того, как виден стол с купюрами, на следующем кадре волк держит рупь двадцать, а заяц лезет в ящик — как будто укладывает туда полученную от волка рублевую купюру.
Не знаю в чем вывод статьи. Ну не заменили сейчас мангак-комиксистов, так заменят через год, когда выкатят GPT images 3.0. То же самое и с seedance: да, пока актеров не заменили, заменят через год с seedance 3.0. Все просто. Другое дело, что такой слопный стиль сожрет аудитория минимум 30+, на которую собственно ориентир и был, а, если требуется захватить и 30-, то лучше пользоваться LoRA моделями заточенными под конкретных художников, а макет страницы, как и позы вообще делать самому. Типа художники are cooked, что здесь спорить-то, то, что вы пытаетесь получить норм результат у нейронки, которая год назад генерила слоп и сейчас продолжает генерить слоп, а мощна она там, где архитектура только авторегрессивного транформера побеждает DiT, то есть как раз в цельных страничках, схемах и т.д, это странно, попытайтесь каждый слайд сгенерить, можно даже в чужом стиле, через LoRA получите хороший результат уже по стилистике, а решения, которые позволяют держать консистентность лица, позволят сохранить лицо на нескольких слайдах. Типа уже в начале этого года, до GPT images 2.0, была выпущена коммерчески успешная AI манга (я заострил внимание на манге, т.к. она занимает большую часть рынка комиксов): My Dear Wife, Will You Be My Lover? К ней многие скептически отнеслись из-за стиля, но в общем-то схавали. Так что мангакам, комиксистам и прочим художникам осталось не более года, до GPT images 3.0.
[достаёт LLM-бинго карточку]
Я правильно понимаю, что автор такой комикс без ошибок сам нарисует за пару часов? И потом перерисует десяток раз по запросу?
Мы очень быстро привыкаем к хорошему и совсем забываем про свои ограничения.
Моя борьба (с LLM)