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

Посмотрим на питоновский модуль difflib, который помогал нам сравнивать строки:

• find_longest_match() находит самый длинный совпадающий кусок между двуми последовательностями и возвращает match — объект с совпадением и дополнительной информацией.
• get_matching_blocks() находит все совпадения между двумя последовательностями и возвращает список из match.
• get_close_matches() находит слова, сильнее всего похожие на переданное слово, возвращает список строк.

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

• find_longest_match вовращает объект-match, как и следует из названия; и get_matching_blocks возвращает такие же объекты, хотя название намекает, что должны возвращаться какие-то blocks
• get_close_matches, судя по названию, должен возвращать match, как find_longest_match — но возвращает строки
• одна и та же по сути операция (поиск совпадений) в одном случае называется find, а в двух других — get

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

Уж на уровне одного модуля можно напрячься и сохранить единообразие? Я предложил бы такие имена:

• find_longest_match()
• find_all_matches()
• find_similar_words() или просто find_similar()

Я очень люблю читать авторские телеграм-каналы. Авторские — это вроде блога: когда человек делится личным мнением или, ещё лучше, опытом.

К сожалению, большинство каналов не такие. Они постят ссылки на чьи-то чужие статьи и видосики, в лучшем случае добавляя короткий комментарий от себя. Это так себе.

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

А самые офигенные каналы — это @diysupport Александры Ширяевой (про техсаппорт) и @pmdaily Федора Борщева (про разработку сервисов). Эти ребята прям жгут, если темы вам близкие — очень рекомендую.

Ну и мой @ohmypy про питончик, конечно ツ

Если вы фронтенд-разработчик — пожалуйста, не отчаивайтесь! Это не приговор. Многие мои знакомые фронтендеры сумели отказаться от этой калечащей привычки и вернуться к нормальной жизни.

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

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

Вы ещё можете бросить фронтенд и стать адекватным человеком. Мы не осуждаем вас, мы здесь и готовы помочь. Не сдавайтесь, боритесь. Обратитесь к ближайшему Java, Python или C#-разработчику, чтобы узнать, как сделать первый шаг к отказу от джаваскрипта. Начните менять жизнь к лучшему прямо сейчас!

Есть одна вещь, которая огорчает меня в коллегах по отрасли. Встречается она даже у программистов, что уж говорить о других причастных к производству софта специализациях.

Это безответственное использование выражения «на порядок».

Часто, когда человек хочет сказать «намного больше» — говорит «на порядок». Это, видимо, должно придать словам дополнительный «математический» вес:

Мы добавили на сайт пять всплывающих окон, и конверсия выросла на порядок.

Новая версия нашего мега-продукта работает на порядок быстрее.

Я стал применять технику «помидорок», и эффективность увеличилась на порядки.

По определению, «на порядок» — это отличие как минимум в 10 раз. А «на порядки» — минимум в 100 раз.

• Если конверсия была 2%, а стала 25% — поздравляю, это действительно «на порядок» (хотя больше похоже на то, что кто-то совсем заврался).
• Если мега-продукт заработал в 2 раза быстрее — это «в два раза», а не «на порядок» (если хотите выпендриться — скажите «производительность возросла кратно»).
• Если в прошлом месяце на сайт пришло 1000 человек, а в этом 1500 — это «посещаемость выросла на 50%» (или «в полтора раза»), а не «на порядок».
• Если эффективность вроде бы возросла, но вы никогда её не мерили, и понятия не имеете, насколько — это «по ощущениям стало лучше», а не «на порядок».

Уверен, что у моих читателей всё в порядке с порядками. Просто наболело.

Для проверки строки по шаблону обычно используют регулярные выражения и модуль re. Но иногда хочется что-нибудь попроще, пусть и не такое мощное — вроде like в SQL.

Сравнить строку или список с шаблоном поможет модуль fnmatch:

import fnmatch
journal = [
  "10:00 Начался обычный день в омской ветклинике",
  "10:30 Голубь Френк постучался в стеклянные двери",
  "10:50 Лисица Клер поскреблась в окно",
  "11:10 Попугай Питер проник через вентиляцию",
  "11:11 Клер попыталась сожрать Френка и Питера",
  "11:25 Осьминог Пауль всплыл в мужском туалете",
]

fnmatch.filter(journal, "*Френк*")
[ '10:30 Голубь Френк постучался в стеклянные двери',
  '11:11 Клер попыталась сожрать Френка и Питера' ]

fnmatch.fnmatch("frank", "f???k")
True

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

fnmatch.translate("*Френк*")
'(?s:.*Френк.*)\\Z'

Курлык.

Допустим, запустили вы стартап. В автоматическом режиме собираете самые упоротые новости русскоязычных СМИ, вот такие:

Кот из Новокузнецка признан виновным в потопе

Автоматически же переводите их на английский, вот так:

Cat from Novokuznetsk found guilty in the flood

И ежедневно рассылаете подписчикам по всему миру.

Всё хорошо, но знакомый эксперт из МГИМО подсказывает: в английском принято каждое слово в заголовке начинать с заглавной буквы. А у вас-то не так!

Можно, конечно, бить заголовок по пробелам через .split(), исправлять регистр через .capitalize() и склеивать обратно через .join(). Но есть способ лучше:

import string
header = "Cat from Novokuznetsk found guilty in the flood"
string.capwords(header)

'Cat From Novokuznetsk Found Guilty In The Flood'

Соу мач беттер.

Если любите делать CLI-утилиты, модуль textwrap наверняка вам понравится.

Он умеет перформатировать многострочный текст, чтобы длина строки не превышала N символов:

text = "Около двух месяцев назад породистый голубь по имени Френк постучался в стеклянные двери омской ветеринарной клиники"
formatted = textwrap.fill(text, width=20)
print(formatted)

Около двух месяцев
назад породистый
голубь по имени
Френк постучался в
стеклянные двери

Или добавить отступ, например для цитаты:

import textwrap
inspirational = "Цитаты простых людей:"
quote = "Откройте окно вообще дышать невозможно"
quote = textwrap.indent(quote, prefix="> ")
print(inspirational, quote, sep="\n")

Цитаты простых людей:
> Откройте окно вообще дышать невозможно

Френк одобряет.

Допустим, мы хотим получить превьюшку длинной статьи. Можно обрезать механически:

article = "Около двух месяцев назад породистый голубь по имени Френк постучался в стеклянные двери омской ветеринарной клиники"
article[:30]

'Около двух месяцев назад пород'

Фраза оборвана посреди слова — это неуважение к читателю и к Френку.

А можно воспользоваться функцией textwrap.shorten():

import textwrap
textwrap.shorten(article, 30, placeholder="...")

'Около двух месяцев назад...'

Намного лучше!

Давно хотел подписаться на интересный канал по Питону, но не нашёл такого и решил завести свой ツ Встречайте Oh My Py — канал про тайные возможности стандартной библиотеки Питона.

Тайные не потому, что кто-то их скрывает, конечно. Просто стандартная библиотека огромная! А разработчики часто не копают глубоко и изобретают велосипед вместо того, чтобы использовать готовое.

Заодно обсудим полезные и не самые известные приёмы в работе с языком и структурами данных. А ещё особенности дизайна и говнокод в стандартной библиотеке (да, встречается и такое).

Заметки из канала будут попадать в блог под тегом ohmypy

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

На самом деле, мысль его другая: код должен попадать к тестировщику уже тщательно проверенным. И тут я 100% «за».

Сколько раз наблюдал: программист чего-то там наделал, как-то вроде работает, какие-то даже тесты есть. И перебрасывает в тестирование — проверяйте, мол. QA сразу находит баги, программист чинит, QA снова находит, он снова чинит… В тяжёлых случаях это длится неделями.

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

И это тяжело. Постоянно хочется срезать углы и понадеяться на «авось», когда знаешь, что за тобой кто-то проверит. Давите эти гнилые порывы, проверяйте всё сами — как если после вас сразу на прод ツ

Конечно, тестировщик всё равно найдёт баги — просто потому что мыслит иначе, чем разработчик. Но не будет ни бессмысленного пинг-понга, ни продолбов по срокам, ни костылей в коде.

Терпеть не могу Гугл и его сервисы, но на работе вынужден пользоваться Gmail. С периодичностью несколько раз в неделю Гугл выкидывает меня из почты и говорит:

Если у Гугла есть специальные люди, которые пишут текст для интерфейса, то в средневековой Японии им пришлось бы сделать сеппуку за такую формулировку.

По-своему это даже красиво: одним предложением указать пользователю его место в иерархии «человек-программа». Докажи, что это ты, жалкий червь. Иначе ты недостоин продолжать наслаждаться сервисами Гугла.

А ведь можно было просто написать:

Чтобы продолжить, введите пароль

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

Наткнулся на забавный пример ценообразования. Есть приложение «Труколлер» — оно помогает распознавать телефонных спамеров. В базовом варианте бесплатное, но, разумеется, есть платный тариф (Premium). В нём типовой набор плюшек — нет рекламы, дополнительные приятные возможности, всякое такое. Обычное дело.

Но сегодня я заметил, что у «Труколлера» есть и «золотой» (Gold) тариф — ровно в 10 раз дороже «премиального». Смотрите, чем он отличается:

1. Приоритетная техническая поддержка
2. Почётный золотой значок (sic!)

Переплачивать за быструю техподдержку — стандартная практика в корпоративном сегменте. Всякие Ораклы, IBM и прочие SAP в «базовом» варианте даже бровью не поведут, если у заказчика возникли проблемы с их софтом. Чтобы добиться от них хоть какой-то внятной помощи, крупные компании покупают «золотые» и «платиновые» тарифы с конским ценником. Это оправданно.

Но «Труколлер»? Если с ним возникают проблемы, проще снести приложение и поставить аналог, чем обращаться в поддержку. И уж точно нет смысла платить 10x за приоритетный саппорт.

Почётный золотой значок — это вообще волшебно. Я сразу вспомнил приложение «I am Rich» для айфона, которое стоило $1000 и прожило в апсторе ровно 1 день. Ну там хоть понятно — это был чистый стёб разработчика. Но кто станет платить 7К в год за золотой значок, серьёзно?

Может маркетологи из «Труколлера» тоже так развлекаются, конечно. Тогда я бы им предложил добавить по-настоящему золотую фичу: посмотреть, под каким именем ты записан у других людей в контактах. Ну и переименовать тариф в «платиновый», конечно ツ

Рассылку об интерфейсах я запустил в апреле 2016 года. Сегодня, спустя 2,5 года и 6000 подписчиков, вышел финальный выпуск.

«Интерфейсы без шелухи» были и остаются единственной рассылкой, которая фокусируется на статьях русскоговорящих авторов. Большинство составителей предпочитают компилировать выпуски из переводов и англоязычных статей — так проще. Я же видел ребят, которые интересно пишут на русском и незаслуженно остаются в стороне — и хотел это исправить. Кажется, это вполне получилось.

Рассылка никогда не была объективной — в выпуск попадало только то, что лично я считал дельным. Со временем таких материалов становилось всё меньше. Мне не интересно писать об очередном инструменте прототипирования, дизайн-системах и о чём там ещё сейчас принято в «дизайнерских» кругах.

Я не хочу превратиться в Юру Ветрова, который «уже семь лет я публикую регулярные обзоры свежих статей по теме интерфейсов». Кстати, подписывайтесь на рассылку Юры, если вам такие обзоры интересны ツ

Мне надоела узкая тема дизайна интерфейсов. Теперь меня больше увлекает разработка софта и техническая «начинка» классных продуктов. Но это совсем не формат «интерфейсов без шелухи».

Поэтому рассылка закончена. Если вам интересно читать мои статьи — подписывайтесь на блог через RSS или в телеграме.

А ещё есть архив рассылки со всеми выпусками.

Спасибо всем, кто читал «интерфейсы без шелухи» всё это время! ♥️

В последние недели жизнь тесно познакомила меня с самым популярным фреймворком для быстрой разработки веб-приложений на Питоне — Django. В нём много любопытного, чем я время от времени намерен делиться ツ

Допустим, у вас в приложении есть сущность «Клиент», а у клиента поле «Имя». Клиенты указывают имя при регистрации, но поскольку это не обязательно — многие предпочитают оставлять поле пустым. Как в таких случаях должно имя храниться в базе данных?

Я всегда полагал, что на этот вопрос может быть единственный ответ — использовать специальное значение NULL. Оно ведь ровно для этого и предназначено: показать, что поле не заполнено, его значение неизвестно.

NULL vs пустая строка

Создатели «Джанги», однако, пошли против вековой мудрости разработчиков, и норовят сохранять отсутствующее значение как пустую строку. За это отвечает специальная настройка (null=False). Менять её не рекомендуют — мол, путаница от этого возникнет:

If True, Django will store empty values as NULL in the database. Default is False.

Avoid using null on string-based fields because empty string values will always be stored as empty strings, not as NULL.

If a string-based field has null=True, that means it has two possible values for "no data": NULL, and the empty string. In most cases, it’s redundant to have two possible values for "no data"; the Django convention is to use the empty string, not NULL.

Этот кусок документации заслуживает особой похвалы. Так всё запутать, ничего толком не объяснив — это ещё надо суметь. Следите за руками:

• с одной стороны, «if True, Django will store empty values as NULL»,
• одновременно с этим «empty string values will always be stored as empty strings, not as NULL».

Так вы храните пустые значения как NULL при включённой настройке? Или всегда-всегда как пустую строку (и на кой чёрт тогда настройка)? Определитесь уже!

На самом деле, авторы имели в виду следующее:

• Если null=False, и вы не присвоите полю значение, «Джанга» молча присвоит ему "" и сохранит в базе как пустую строку.
• Если null=True, и вы не присвоите полю значение, «Джанга» молча присвоит ему None и сохранит в базе как NULL.
• Вне зависимости от настройки, если вы явно присвоите полю значение "", «Джанга» сохранит его в базе как пустую строку.
• Вне зависимости от настройки, если вы явно присвоите полю значение None, «Джанга» сохранит его в базе как NULL.

Ох.

NOT NULL на таблице

Но это полбеды. О чём авторы совсем забыли упомянуть в документации — о том, что null=False генерирует такой SQL-код:

ALTER TABLE "tablename"
ADD COLUMN "columnname" varchar (50) DEFAULT '' NOT NULL;

То есть не просто «мы будем записывать неизвестное значение в базу как пустую строку», а «мы вообще запретим этому полю иметь значение NULL».

Это очень, очень творческое дизайнерское решение. Дело в том, что если у вас таблица на 100000 строк, и вы добавляете в неё NOT NULL столбец, то это, мягко говоря, небыстро. И полностью блокирует таблицу на всё время операции.

А если приложение развивается, новые столбцы добавляют регулярно. И с NOT NULL каждый раз при миграции таблица блокируется и полностью перезаписывается. Как вообще можно было додуматься до такого подхода?

Чтобы решить проблему, достаточно игнорировать рекомендации «Джанги» и ставить текстовым полям null=True.

P.S. В PostgreSQL 11 добавили специальную оптимизацию, благодаря которой добавление NOT NULL столбца работает моментально, если у него есть значение по умолчанию. Так что в новом «Постгресе» рекомендуемые настройки «Джанги» наконец-то перестали стрелять в ногу разработчикам.

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

• Ну и что, что человек не может ничего прочитать, пока не подпишется на рассылку в огромном попапе? Так конверсия выше!
• Ну и что, что всех бесит, когда в углу прыгает и требует внимания онлайн-консультант? Зато конверсия растёт!
• Ну и что, что при попытке увести курсор мыши на соседнюю вкладку выскакивает окошко с предложением ОГРОМНОЙ СКИДКИ? Это всё ради конверсии!

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

1. Выручка вместо конверсии

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

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

2. Долговременные последствия

Окей, допустим «продающие» уловки увеличили не только конверсию, но и выручку. Но помимо изменений «в моменте» есть и долговременные:

Что с возвратами? Может быть, привлечённые уловками покупатели намного чаще возвращают товар или отказываются в последний момент.

Что с репутацией? Может быть, людям не слишком нравятся ваши грязные приёмчики, и они согнали магазину рейтинг в Яндекс-маркете.

Что с оттоком и выручкой с клиента? Может быть, ваш новый сайт, полный «тёмных» паттернов, привлекает больше новых пользователей. Но при этом отталкивает существующих — и они меньше покупают или не продлевают подписку.

⌘ ⌘ ⌘

Не замыкайтесь вы на этой конверсии. Смотрите на все показатели бизнеса; и не в моменте, а в перспективе.