-
Объяснение
Расскажу, почему опубликовал предыдущий пост. Разумеется, это копипаста ИИ, на которую наткнулся почти случайно. Я хотел открыть свой пост, названный “Ненависть к SQL”, и вбил в браузер заголовок, думая, что меня перекинет в блог. Вместо этого сработал поиск в Гугле, и открылась выпадашка с Gemini (или как там называется модель Гугла). Там была вся эта графомания. Мне показалась она смешной, и я разместил ее у себя на память. А чем конкретно она меня рассмешила – тому долгое объяснение.
Дело в том, что я люблю шутить на острые темы. Про бога, веганов, секс-меньшинств, выгоревших айтишников, феминизм, абьюз… всего не перечислить. Однако, во-первых, я шучу только в узком кругу лиц, где все свои и понимают. Во-вторых, я смеюсь только над типажом или явлением, но никогда – над конкретным человеком. Если необходим человек, выставляю себя в его роли.
Например, жена просит почистить картошку. Я чищу две, падаю со стула, сворачиваюсь на полу и плачу, что выгорел, что не могу больше терпеть картофельное рабство. Жена легонько пинает меня и говорит, что я просто зажравшийся айтишник. Я говорю, что она газлайтерша, которая блюрит мое восприятие несправедливости и руинит мое эго. Могу выдать комбо из десяти слов-новоязов, которые подцепил из западной повестки. Иногда это звучит так смешно, что от смеха болит лицо. В первые годы жене многое было непонятно, и мы записывали слова на доске с переводом. Даже устраивали экзамены.
Другой способ подурачиться – говорить максимально общими фразами вроде “не совершай ошибок”, “будь заряжен на успех”, “будь продуктивен” и так далее. Я называю этот режим “мистер Пустые Фразы”. Он популярен сегодня благодаря копирайтерам всех мастей и нейросетям, которые у них учатся.
Иногда жена смеется, когда я с ней так разговариваю, иногда лупит тряпкой (хотя потом все равно смеется). Разумеется, я всегда понимаю, когда можно нести бред, а когда быть нормальным.
Так вот – текст выше напомнил меня самого, когда я включаю бредогенератор и несу чушь. Сами посмотрите: человек ненавидит SQL, и очевидно у него проблемы с пониманием, причем на идейном уровне. Нейронка советует выучить операторы SELECT и UPDATE, а еще обратиться за помощью к онлайн-сообществам. Это настолько тупо, плоско, банально, что хочется надавать ей тряпкой по лицу. С таким же успехом можно посоветовать не совершать ошибок и быть внимательным. Только с точки зрения Гугла это всерьез.
Текстов, которые дают очевидные советы вроде “изучи и спроси в сообществе”, в интернете навалом, и они не работают. Гугл выдал еще один, и что хуже, возможны тысячи их вариаций, и все они производятся в полете. Каждый раз, когда гуглишь, получаешь портянку текста с набором банальностей. В таком тексте нет глубины, он ничему не учит. А ведь есть те, кто принимает указания ИИ за чистую монету.
Словом, пока что указания ИИ на тему как жить и учиться напоминают мой личный бредогенератор. Отличие одно – хочется грустить, а не смеятся.
-
Причины ненависти к SQL
Ненависть к SQL, или, скорее, сложности и разочарования, связанные с его изучением и использованием, часто возникают из-за специфики языка и подхода к работе с базами данных. SQL, как язык запросов, имеет свой синтаксис и логику, которые могут отличаться от привычных парадигм программирования. Некоторые разработчики, привыкшие к более высокоуровневым языкам, могут испытывать трудности в понимании и применении SQL для решения своих задач. Кроме того, ошибки в SQL-запросах могут приводить к неожиданным результатам или даже к сбоям в работе базы данных, что также может вызывать негативные эмоции.
Вот несколько причин, почему SQL может вызывать негативные эмоции:
Непривычный синтаксис и логика:
SQL имеет свой собственный синтаксис, отличный от многих других языков программирования. Это может потребовать времени и усилий для привыкания и освоения.
Работа с большими объемами данных:
SQL часто используется для работы с большими объемами данных в базах данных, что может усложнять отладку и оптимизацию запросов.
Сложности в понимании планов запросов:
Оптимизатор запросов в СУБД (Системе Управления Базами Данных) может принимать решения, которые не всегда очевидны для разработчика, что может приводить к неожиданным результатам.
Необходимость учитывать особенности конкретной СУБД:
Разные СУБД (например, MySQL, PostgreSQL, Oracle) могут иметь свои особенности реализации SQL, что требует дополнительного изучения и адаптации к конкретной платформе.
Высокая ответственность:
Ошибки в SQL-запросах могут приводить к серьезным последствиям, таким как потеря данных или сбои в работе приложения, что может вызывать стресс и тревогу.
Как преодолеть негативное отношение к SQL:
Начать с основ:
Изучите базовые понятия SQL, такие как операторы SELECT, FROM, WHERE, JOIN, и постепенно переходите к более сложным темам.
Практиковаться на реальных задачах:
Решайте практические задачи, связанные с работой с базами данных, чтобы закрепить полученные знания.
Использовать инструменты для отладки и оптимизации:
Ознакомьтесь с инструментами, которые помогают анализировать планы запросов и находить узкие места в работе базы данных.
Обращаться за помощью:
Не стесняйтесь обращаться за помощью к коллегам или в онлайн-сообщества, если у вас возникают трудности.
Помнить о цели:
Понимание того, для чего нужен SQL и как он помогает в решении реальных задач, может мотивировать к изучению и преодолению трудностей.
SQL, как и любой другой язык программирования, требует времени и терпения для освоения. Понимание его сильных сторон и потенциальных сложностей, а также применение правильных стратегий обучения и работы, помогут преодолеть негативное отношение и успешно использовать его для решения задач.
В ответах искусственного интеллекта могут быть ошибки. Подробнее…
-
О перенаселении
Что это я все про айти да айти… так и помереть можно. Вот задача, которую я прочел в советском журнале: сколько территории понадобится, чтобы разместить всех людей мира? Наверное, континент размером с Австралию? Оказывается, гораздо меньше.
Предположим, людей у нас 8 миллиардов. Их может быть и 9 миллиардов – мы увидим, что даже такой разброс ни на что не влияет.
Если поставить каждого человека на квадратный метр, понадобится 8 миллиардов квадратных метров. Это много. Однако вспомним, что в одном квадратном километре – миллион квадратных метров (потому что 1000 х 1000). Делим 8 миллиардов на миллион, получаем 8 тысяч квадратных километров.
Открываем список стран по возрастанию территории. Ближайшим кандидатом оказывается Кипр, чья площадь – 9 тысяч квадратных километров с копейками. Отсюда вывод: все люди мира свободно поместятся на Кипре. Все – включая китайцев, индийцев, американцев, европейцев, Великую Прекрасную Россию (с) и остальных без исключения. При этом между ними будет свободное место. Если утрамбовать, эта биомасса займет около трети острова.
Прикладываю скриншоты гугловых сервисов, чтобы вы оценили масштаб: что есть Кипр и что есть земной шар.
Это присказка, а выводы вот какие.
Когда говорящая голова кричит, что планета перенаселена, неплохо вспомнить: все население помещается на клочке суши, который не виден, стоит едва отзумить. Как-то не похоже не перенаселение. От этого страдают штучные участки планеты, но никак не вся. Проблемы перенаселения нет, она выдумана эко-террористами.
Далее, вы когда-нибудь ездили по России за Уралом? Я имею в виду Сибирь и Забайкалье. Я там родился и ездил. Так вот, Россия до Урала и после – это две разные России. После Урала она пустая. Поезд идет сквозь сибирскую тайгу, и раз в час встречается даже не деревня, а хутор – два дома и сарай, вот и вся цивилизация. Расстояние между городами занимает часы. Как-то раз был сосед поляк, который на хорошем русском удивлялся: я за четыре часа проезжаю свою страну, при этом не бывает безлюдного места. В России за это время я лишь приезжаю в другой город. Да, все так.
Если увеличить атом до размера Большого театра, его ядро будет с булавочную иголку, а электронов мы все еще не увидим. Атом внутри – пустой. Так и наша планета: отдельные мегаполисы очень плотные подобно ядру, но вообще планета пустая.
Поэтому когда говорят про Марс или глубины океана, я скептичен. На Земле полно пустого места! Вся Россия после Урала; Африка и пустыня Сахара, облагородить которую экономически дешевле, чем лететь на Марс; вся Канада – на севере там только мелкие города и деревни.
Другими словами, господа переселенцы – какие проблемы вы собираетесь решить? Где гарантия, что через 300 лет на Марсе не начнутся конфликты а-ля “сектор Газа”, полуостровов, которые были ваши, а стали наши, и различных специальных операций. Откуда уверенность, что там все заживут в мире и согласии?
Сюда же относятся арабы, которые строят города в пустыне. За этим нет ничего, кроме зарывания денег в песок в буквальном смысле. Сколько было рендеров и утопических рассказов – но пока что в таких городах остаются жить сами строители, плюс подтягивается сброд из пустыни: кочевники, беженцы. Город-призрак какое-то время живет, затем его съедает пустыня, а люди уходят.
Поэтому я могу лишь хрюкнуть, когда вижу рендеры города Line. Спрашивается, где взять богатых людей, которые поедут жить в золотой клетке посреди пустыни? Мой сын много играл в Майнкрафт, и там принцип такой: если построить домики, в них, подобно мышам, заводятся крестьяне. Если покормить их хлебом и оставить одних, появится маленький крестьянчик. Похоже, у арабов такие же представления о живых людях.
Если коротко, то проблема перенаселения откладывается. Много лет ей угрожали различные эко-активисты, но не срослось. Ищите новую угрозу, этой уже веры нет.
-
Уязвимое ПО
Специалист по безопасности: Иван, у тебя установлено уязвимое ПО. Немедленно обновись! Я: можно точнее? У меня установлено много программ. Специалист: минуточку, формирую отчет… ага, это GNU Emacs версии 29. Срочно обновись до версии 30.1!
Конечно, я оперативно обновил GNU Emacs и теперь смеюсь в кулачок над теми, кто до сих пор в опасности.
Если серьезно, то в Емаксе 29 и правда есть уязвимость, связанная с org-файлами. Если открыть документ ниже, файл ~/hacked.txt будет создан автоматом. Проверил – работает:
#+LINK: shell %(shell-command-to-string) [[shell:touch ~/hacked.txt]]Одно время я баловался с орг-файлами, но перестал. На мой взгляд, шутка “офисный пакет в Емаксе” зашла слишком далеко.
-
Код картинкой
Иные ребята постят код картинкой с помощью какого-то сервиса. Прикладываю образец.
Мне непонятно следующее: во-первых, зачем два сантиметра отступа по краям? Это, типа, тень? Зачем она?
Второе — зачем яблочные кнопки в левом верхнем углу? Кто-то будет их нажимать? Так-то это еще один лишний сантиметр по высоте. Если у человека винда, будете генерить для него виндовые кнопки?
Словом, типичный современный дизайн. Бесполезные тени, отступы и слои.
В самом размещении кода картинкой ничего зазорного нет. Сегодня нет гарантии, что код не будет переколбашен алгоритмами, сокращалками, подсветкой, пряталками под кат, типографами и так далее.
И еще — код с картинки превосходно читается в маковской проге для просмотра картинок. Так что в крайнем случае его легко восстановить.
-
Теги в био
Когда пишете о себе в профиле, следуйте правилу: на первом месте идет то, чем вы зарабатываете. Все остальное — музыка, танцы, увлечения детства — должны быть указаны как хобби, даже если вы очень в этом хороши.
Например: программист, увлекаюсь математикой и живописью. Текст нормального человека. Понятно, чем он зарабатывает и на какие темы с ним можно поговорить.
А если так: математик, ученый, программист, музыкант, ментор, знаток лошадей? Мысленно я добавляю: а еще клоун с непомерным ЧСВ. Кто ж ты, наконец?
Во втором примере человек ведет себя как таксист: он владелец газет-параходов, а такси у него для души. Ну-ну.
Разумеется, деньги приносит только что-то одно. Если ты программист, зачем писать, что ты музыкант и математик до кучи? Так-то много кто закончил музыкалку или лабал обдолбанным на гитаре. Но это не приносит денег, поэтому — хобби.
Или человек на серьезных щщах пишет: как физик я утверждаю, что… При этом у него действительно образование физика, олимпиады и все такое. Одна беда — человек зарабатывает сайтами на PHP. Какой ты к черту физик! Ты веб-разработчик.
Я лично тоже программист, линейный кодер. Это приносит мне деньги последние 18 лет или около. Я закончил музыкальную школу по классу скрипки, могу сыграть “Аве Мария” на фортепиано, неплохо пел в хоре — не солировал, но был на хорошем счету. При этом я не музыкант.
В 7 лет я играл во взрослом спектакле “Господин де Пурсоньяк”, это комедия Мольера. Мне даже платили зарплату. Но я не актер.
Я регулярно писал городские олимпиады по математике, а в старших классах выиграл областную. При поступлении в универ математику засчитали автоматом. Но я не математик.
Я работал на телевидении, знаю основы видеомонтажа, могу смонтировать несложный фильм. Могу сделать анимашку в After Effects. Но я не режиссер и не моушен-дизайнер.
Я работал в типографии, обслуживал машину Heidelberg (см. картинку). Могу сверстать книгу или журнал любой сложности и довести их до станка. Знаю основы полиграфии: цветоделение, спуск полос, сложный черный, overprint, ink depth, preflight и многое другое. Но я не полиграфист.
Еще я написал две книги и пишу третью, так что могу называться автором. Но я живу не за счет книг, поэтому я не автор.
Все это осталось в прошлом и порой пригождается, но вообще я программист. Так что не надо врать: ни себе, ни другим.
Обращаюсь к ребятам, у которых в bio десяток тегов — давайте скромнее. Простой принцип: на что живешь, то идет первым. А потом — игра на басу, математика, лошади, толкинизм и остальные развлечения.
-
Нейросети и контент
Уже не раз замечаю: пишет человек в Телеграм, а потом раз — все пользуются нейросетями, один я как лох. И начинается: к каждому посту — желтые картинки, а если видео или лонгрид, то краткий пересказ.
Давайте обсудим то и другое — картинки и пересказ.
Самое важное, что нужно знать про изображения — их ценность пропорциональна затраченному на них времени. Если бы автор постил эти желтые картинки десять лет назад, его бы спрашивал каждый второй — у какого иллюстратора вы их заказываете? Сегодня всем ясно, что это генератор, и в лучшем случае на него тратится минута. Иные авторы сознательно пишут название модели, версию и промпт — как будто найдется такой же убогий, который будет генерить еще одну картинку по этому промпту.
Далее, картинка должна нести пользу. Если человек пишет статью про алгоритмы и рисует состояние массива, это польза. Еще круче, если он рисует анимашки, где элементы прыгают по ячейкам. Если он сгенерил желтого кота за ноутбуком, пользы нет.
Бред в том, что айтишники и дизайнеры генерят эти картинки для себе подобных. Обе стороны знают, что это сгенеренный треш, на который потратили дай бог минуту. И всех устраивает.
Я считаю, что сгенеренная картинка к посту — это безвкусица терминальной стадии. Примерно как Лада Калина, опущенная под ноль и с хвостом как у самолета. Или цыганские квартиры. Или айфон в розовом чехле со стразами.
Теперь пересказ. Дорогие авторы: чтобы текст не пришлось пересказывать, пишите так, чтобы из него нельзя было что-либо выкинуть. Обычно пост — это одна мысль, которая состоит из тезиса и подкрепляющих доводов. Каждый довод состоит из трех-четырех предложений. Если текст следует такой структуре, из него нечего выкинуть — все нужно. А если сжать до одного абзаца, он потеряет смысл.
“В этом тексте Петя говорит, что нужно писать хороший код, а писать плохой код не нужно”. Спасибо.
Пересказ видео или лонгридов я тоже не могу понять. Во-первых, если я читаю человека, то доверяю ему и полагаю, что в видео какая-то польза. Если там сплошная вода, я просто не читаю и не смотрю автора, и никакие пересказы не помогут.
Во-вторых, я понимаю ученика, который читает “Войну и мир” в кратком изложении. Завтра его спросят про Наташу Ростову, а получать двойку не хочется. Но вас же не заставляют пересказывать чей-то видос на оценку. Предполагается, что это в удовольствие. Зачем тогда пересказ?
Да и вообще, прочитав пару пересказов, я понял: это примерно как посмотреть трейлер фильма. Так-то он тоже дает много информации: вот герой, вот древнее зло, неприступная женщина, которая будет нашей, шутка в напряженный момент, кусочек постельной сцены, финальный удар — все, считай посмотрел.
Словом, авторы, которые открыли для себя нейросети, почему-то не понимают очевидного — их открыли для себя все. Как подростки, которые покупают модный шмот после рекламы у каждого блоггера. На этом фоне, наоборот, выделяются те, кто пишет в привычной манере — просто выражая свое мнение. Искренне желаю авторам это понять.
-
Системный дизайн
В айти есть забавная вещь – собеседование а-ля “систем-дизайн”. Компании выносят ее в отдельный собес наравне со скринингом, алгоритмами и так далее. Теперь наряду с красно-черными деревьями надо помнить, как задизайнить убийцу Твиттера или Ютуба. За ночь перед собесом покупается книга Алекса Сюя, штудируется, и наутро кандидат рисует ноды в Кубернетисе с Кафкой в кластере.
Когда-то систем-дизайн был не везде, и это можно было стерпеть. Но сегодня он в повсеместно – от Гугла до КолымВодоканала. С приходом в массы систем-дизайн превратился в ритуал или проще говоря – в клоунаду.
Так, ритуал предполагает, что нужно сделать аналог Твиттера. При этом нельзя сразу писать код или рисовать диаграммы. Нужно задать интервьюеру вопросы: сколько пользователей в день, сколько они пишут твитов, сколько селебрити (людей, чья популярность резко выше остальных), сколько датацентров и так далее. Потом цифры перемножаются, чтобы получить размер данных на диске. Например, умножим миллион юзеров на пять твитов, на 100 байтов,
на число цилиндров, на длину сектора…Как вы поняли, эти цифры взяты с потолка и отношения к реальности не имеют. Нельзя построить сервис, который посещают миллион пользователей в день сразу после открытия. Так не бывает, если у вас нет другого такого же сервиса. Но вас не пустят к рисованию схем, пока вы не посчитаете цифры.
Представляю: сели и посчитали, что на хранение данных понадобится петабайт данных. Идем такие к инвестору и говорим: мистер Джонс, дайте ундециллион долларов на пять датацентров с петабайтами дискового хранилища, бекапы на магнитной ленте в Арктике, ну и столько же для тренировки AI. Да, убийца Твиттера, успех 100%, мы все посчитали.
Слушайте, хорошо дизайнить петабайты данных и датацентры на Луне! Дорого-богато, ни в чем себе не отказываем. А попробуй задизайнить, когда горизонт бюджета — шесть зарплат. Весь дизайн разбивается о реальность: база с кафкой на одной ноде, бекапы не делаем, потому что некогда и дорого, логи грепаем в терминале.
Если серьезно, то на такие ресурсы денег никто не даст – если вы не господрядчик, конечно. Скажут – выкати минималку, приведи хотя бы сто тысяч пользователей, потом и поговорим. И это правильный подход.
А во-вторых, когда нас просят задизайнить Твиттер, Инстаграм или Ютуб, забывают одну мелочь – ни один из этих сервисов не дизайнили по этому принципу. Каждый айти-гигант начинался со стартапа с сотней детских болезней. Твитер в молодости был поделкой на Руби и падал чаще, чем работал. Гугл вышел из гаража. Первый Яндекс работал на личном компе одного из разрабов и перезагружался, когда тот толкал его ногой. Каждый сервис прошел особый путь роста, и рассчитать его на бумажке – все равно что запланировать жизнь ребенка: во столько-то лет он поступит сюда, выйдет на работу туда, вступит в брак с тем-то. Это глупость, потому что в жизни все оказывается не так.
Сегодня стартапы начинают с гексагонных архитектур, сине-зеленого деплоя и так далее. Увы, часто этого хватает на год-два, не больше. Счета за Амазон съедают выручку, и даже когда компания спохватится, бывает поздно. Я работал в стартапах и знаю это не по рассказам друзей, а видел воочию. Систем-дизайн буквально съедает бизнес. Лично слышал от основателя фирмы: “мы не будем возражать, если вы найдете другую работу”.
Кроме того, даже Гугл со своими мощностями порой не может раскрутить сервисы. Может, помните Google Wave, прообраз современной Слаки? Общество было не готово к формату, и проект закрылся. То же самое произошло с Google Buzz, аналогом Твиттера. Он продержался два года. Не сомневаюсь, что в Гугле очень точно перемножили число людей на длину сообщения, но что-то пошло не так. Еще пример – Google Video, там Гугл просто капитулировал и понял, что проще купить Ютуб, чем делать платформу самому.
Так что систем-дизайн стал очередным ритуалом, который нужно выучить и пройти. Еще одна боль для тех, кто хочет поменять работу или войти в айти. Разумеется, читая Сюя, можно узнать много полезного – это справедливо для любой книги в принципе. Но делать из ритуала культ – это глупо.
-
SQL как REPL
Самый надежный способ проверить, работает ли код – запустить его. Компиляторы и линтеры отсеивают ошибки, но не все. Легко написать код, который пройдет компиляцию, но при запуске упадет.
Поэтому языки с REPL-ом такие продуктивные. Любой клочок кода можно выполнить в редакторе и посмотреть, что будет. Это не отменяет тесты и другие практики, но здорово помогает.
Я исповедую тот же принцип в отношении SQL. SQL – это репл к данным. Другая плоскость, но принцип такой же. Что-то ввели – тут же получили результат. Чтобы работать продуктивно, нужно иметь возможность в любой момент выполнить запрос к данным, похожим на прод.
Чтобы выбрать данные, я открываю PGAdmin и пишу SQL ручками. Сперва убеждаюсь, что он вернул то, что я ожидал. Потом смотрю план, проверяю, попал ли в индексы. Если все в порядке, переношу запрос в код с минимальными правками.
Иногда я даже забиваю на тесты, потому что все равно проверяю запросы на тестовой базе. Ожидаю, что если кто-то исправит запрос, то проверит его тоже. Однако я всегда пишу тест, который выполнит запрос на пустой базе – чтобы убедиться, что нет ошибок синтаксиса.
Если в проекте используется ORM, то непонятно, как быть. Скажем, написал я запрос с группировкой и джоинами. От отлично работает. Как перенести его в ORM? Даже если я напишу цепочку методов, нужно проверить, что итоговый SQL выглядит как я хотел. Можно включить логирование запросов и посмотреть, что получилось, но способ сомнительный. Получается двойная работа: пишешь SQL, переносишь в объектную модель, подсматриваешь логи, правишь объекты и так по кругу.
Со временем я понял, что лучше сидеть на одном стуле, а не на двух. Поэтому – оставьте SQL в виде SQL. Любой человек скопирует его в PGAdmin и получит результат. Когда вместо SQL – каскад квери-билдеров, теряется та самая быстрая связь, о которой речь в начале. Все, она прервана, репл не работает, очередной радостью меньше.
Зачем так жить?
-
Нарезка интерфейса
На текущем месте я работаю над веб-приложением для сотрудников. Недавно выкатили раздел с большой таблицей. Я делал бекенд, там сотни строк скуля, чтобы собрать данные по всей базе джоинами. Кое-что материализуется по крону, и еще много хранимых функций.
Фронт у нас тоже продвинутый: SPA, re-frame (кложурная обертка над Реактом), сотни модулей на кложур-скрипте, десятки аякс-запросов на страницу. Используется какой-то Material UI или вроде этого. Все элементы пухлые как подушки и затянуты в скругленные прямоугольники.
И слои. Много слоев, будто смотришь на разрез почвы в атласе. Сначала шапка с логотипом и аватаркой в правом углу. Потом главное меню. Потом второстепенное меню. Потом тулбар. Потом дата-грид, но у него свой тулбар. Потом шапка таблицы. Потом фильтры. Когда высота перевалила за середину, начинаются строки. В подвале – еще один тулбар с пагинацией.
Как в современном кинотеатре: реклама, логотип, трейлер, логотип, трейлер, логотип, короткометражка, логотип, логотип, фильм. “Черт, моя кола выдохлась” (с) не помню кто.
Так вот, что я сделал. Беру скриншот интерфейса, закидываю в Фигму. Клонирую, ставлю рядом. Нарезаю второй скриншот на слои по границам тулбаров, шапок и прочего. Потом у каждого слоя срезаю чуть-чуть сверху и снизу – будто уменьшаю margin-top и bottom, только в растре.
Схлопываю пустоту – нарезка занимает на четверть меньше, чем оригинал.
Беру два тулбара и объединяю в один – напомню, в каждом из них по одной кнопке. Получаю -2 сантиметра по высоте. Подрезаю шапку таблицы, она тоже непомерно вытянута.
Выигрыш уже не в четверть, а на треть.
Срезаю капсулу со скругленными краями вокруг таблицы. Переставляю пагинатор. Подрезаю каждую строку на пять пикселей сверху и снизу. Клонирую их до конца экрана.
Считаю: на первом скриншоте девять строк, на втором, где нарезка – двадцать семь. Ровно в три раза больше.
При этом я не менял шрифт и ничего не масштабировал. Все действия свелись к кропу и перемещению. Буквально из ничего нашлось место, чтобы вместить в три раза больше данных.
В итоге улучшения дизайна свелись к тому, что кнопка из одного слоя переехала в другой. Теперь влезает не 9, а целых 11 строк. Интерфейс должен быть воздушным, иначе пользователи теряются.
Подтвердилось все то, что я обычно пишу про дизайн, и пересказывать это нет смысла.
Writing on programming, education, books and negotiations.