Заметки с тегом «Ненависть»

Будучи разработчиком, я не любил GraphQL с самого его появления — из-за ноды, привязки к Apollo, отсутствия APM (если не покупать подписку у Apollo) и сложного, вложенного языка запросов. В принципе до сих пор ничего изменилось, но в этом посте я хочу отдельно поговорить о своей любимой теме – тестировании.

GraphQL замечательно умеет делать одну вещь: вытаскивать данные с сервера в произвольном формате, удобном в каждый конкретный момент. «Выгрузи мне все книги — название, количество страниц, пару интересных цитат и автора, а у каждого автора покажи ФИО, фотографию и список популярных произведений» — это типичный запрос для GraphQL, с которым он справляется идеально. В REST для такой специфичной выборки пришлось бы писать отдельный эндпоинт, следить за ним и поддерживать. А тут даже кода писать не надо — один раз описал схему данных, и всё работает из коробки.

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

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

Конечно, есть бизнесы, которые выигрывают от умения отдавать по 20 сущностей на один запрос, и делают это своей core-ценностью — к примеру облачные BaaS или высокоуровневые headless CMS вроде Sanity. Но если вам надо просто отдавать на фронт десяток известных сущностей, даже если вы планируете добавить в будущем ещё пару десятков — скорее всего GraphQL обойдётся вам намного дороже чем обычный REST, потому что с самого старта вам придётся тратить намного больше сил на тесты.

У меня недавно случилось озарение — я понял почему мне так знакомо чувство, которое возникает, когда я работаю с модулями nuxt.js. Вот взять модуль gtm, к примеру. Среди кучи других issues у него есть issue, которая так честно и называется — «модуль не работает». И что интересно — модуль и правда не работает.

Так вот, когда-то давно, лет 15 назад, у меня была Нива — это такие жигули-кроссовер. И меняли мне на ней как-то стартер. Там эта операция проводится довольно сложно — стартер расположен крайне неудобно, приходится даже разбирать выхлопную систему. Так вот, купил я стартер, поставили его мне, собрали всё, а машина не заводится: стартер не крутит. Полезли разбираться, и выяснили, что проблема в том, что я купил рязанский стартер (не уверен насчёт города, может белгородский, или тамбовский).

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

В итоге стартер я купил белорусский, машина завелась. Но этот вопрос меня ещё долго не отпускал — ведь у этого завода в Рязани есть директор, главный инженер, руководитель ОТК, и ещё куча людей. Зачем все они делают стартеры, которые не работают?

Вот так же и с модулями накста. Ну вот реально чуваки постоянно что-то релизят, последний релиз в ноябре был. Какие-то фичи там даже добавили. Но вот зачем они делают релизы, которые не работают, а?

Я не знаю ни одного человека, который был бы доволен тачбаром на новых макбуках.

Основная моя претензия к тачбару — зависимость от контекста. Тачбар отвлекает всегда — в бразуере, в редакторе кода, в почте. Особенно злит, когда работаешь с текстом, думаешь о смысле, а у тебя перед глазами мельтешат варианты замены слов или кнопки с ненужными действиями. Я гораздо быстрее нажму хоткей или наберу слово до конца, чем перенесу руки с клавиатуры на тачбар. Хоткеи и набор — действия автоматические. А к тачбару привыкнуть невозможно — он всегда разный.

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

В общем, тачбар — зло. Без которого, однако, не купить новый макбук, только если урезанную версию. Так что, если вы обладатель макбука с тачбаром, почитайте мой рецепт борьбы с ним.

Сделать сразу: отключить зависимость от контекста

Заходим в настройки клавиатуры: Apple → System Preferences → Keyboard, и выбираем в селекторе «Expanded Control Strip»:

В таком случае вы получаете обычный набор сенсорных клавиш, который всегда перед глазами. И больше ничего не прыгает!

Посерьезнее: избавиться от случайных нажатий

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

У меня получилось так:

Слева и справа пустые места — сюда я чаще всего нажимал случайно.

Совсем для гиков: извлечь пользу

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

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

При нажатии Option появляются элементы управления яркостью и громкостью:

Клево, что тачбар в роли дополнительного дисплея позволил сэкономить место в трее, там теперь так:

BetterTouchTool — типичная гиковская программа с огромными возможностями, но с корявым интерфейсом, так что придется с ней поразбираться. Чтобы отключить тачбар, нужно перейти на вкладу TouchBar и нажать на кнопку слева:

и снять вот эту галочку:

Дальше — просто, можно выводить любые данные и добавлять любые виджеты. Или вообще ничего не выводить, оставив пустую полосу — тоже неплохо.

Как вывести трек — написано здесь. Если не разберетесь — пишите, дополню статью.

Дисклеймер: лонгрид Вастрика я читал.

Бесят предисловия в русских бизнес-книгах. Обычное предисловие — это 5 страниц без смысла за авторством какого-нибудь вице-президента Пупкин-Диджитал-Консалтинг по девелопменту.

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

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

Я предлагаю указывать авторов в начале предисловия, а не в конце. Так авторам приятнее, а читатель сможет сразу решать, стоит ли ему читать лишние 5 страниц.