-
Синглтон (1)
Казалось бы, сложно придумать паттерн хуже, чем синглтон. Но нет: на его примере объясняют, как хорошо иметь единственное подключение к базе данных. Специально проверил в Википедии и образовательных статьях.
Делать подключение синглтоном — это примерно как подвесить больного человека вверх ногами и привязать к шее кирпич, думая, что ему станет легче. То есть двигаться в худшую сторону по градиенту — вектору, когда величина нарастает максимально быстро.
Подключение к базе — и вообще любое сетевое подключение — никогда не должно быть синглтоном, и вот почему.
Если подключение не потокобезопасно, то обращение к нему из разных потоков вызовет “рассинхрон”. Например, поток А отправил сообщение, а поток В прочел ответ. В лучшем случае конечный автомат выкинет ошибку, а в худшем — получим неопределенное поведение.
Если же подключение потокобезопасно, то каждый запрос будет блокировать другие потоки: они будут ждать, пока соединение отпустит. В результате 4, 8 или 16 потоков будут работать как один.
Конечно, если у нас скрипт на PHP для заказа пиццы, можно писать в таком ключе: объявить подключение на старте и ссылаться глобально. Для чего-то посложнее так лучше не делать.
Вместо подключения должен быть пул соединений. Каждый раз из него занимают подключение, работают с ним и кладут обратно. Чтобы гарантировать возврат, процесс займа оборачивают в макрос или контекстный менеджер (with в Питоне, try with resource в Джаве).
Но и пул соединений не должен быть синглтоном! Должна быть система компонентов с зависимостями. Пул — один из компонентов, а другие компоненты зависят от него. Специальный код строит граф зависимостей, включает компоненты в нужном порядке и передает им рабочие зависимости.
Другими словами, функция для работы с базой и очередью задач не должна порождать эти компоненты. Она либо принимает их, либо является компонентом, который инициализируется с ними.
Даже если какая-то сущность глобальна по причине легаси, не следуйте плохим практикам. Передавайте ее обычным аргументом. Быть может, ее получится убрать из глобального скоупа, и не придется рефакторить код.
Это в точности мой случай. У нас пул объектов является глобальным — и все равно я ссылаюсь на него лишь однажды, а затем пробрасываю параметром. Верю, что этот промах получится исправить.
Синглтон — это прекрасно для собеса, но никогда не берите его в проект. Включайте, но не пользуйтесь. Пользуйтесь, но не включайте. Не считая этой мелочи, с ним все хорошо.
-
Новый интерфейс Ютуба
Пишут, что Ютуб готовит новый интерфейс плеера. Разумеется, он более “воздушный”: кнопки обтянуты капсулами, вокруг которых пустота. Новые кнопки отнимают еще больше места от видео.
Наверное, в десятый раз повторю тезис: современных фронтендеров (ну или веб-дизайнеров) нужно не учить, а лечить. Когда дизайнер отхватывает десятую часть экрана под кнопки и не видит в этом проблемы, ему нужна помощь специалистов. Что он делает в профессии, я не знаю.
Разумеется, кнопки не должны наползать на видео, их место в отдельной панели снизу. Сюда же относится пауза: когда я нажал ее, не должно появляться затемнений, выпадашек с рекомендациями, блямбы с двумя палками и так далее.
Все это бесконечно просто для понимания и бесконечно сложно для дизайнеров.
-
Mastercard нанимает
Я подписан на кложурные вакансии в Linked In. Не планирую менять работу, просто чтобы иметь представление, кто нанимает. В числе прочих увидел Mastercard (SDET Backend API’s):
We are the Platform & API Team which is responsible for the customer facing APIs to our products and are looking for a Sr Software Engineer for our Seattle or Vancouver Canada offices. As a Sr Software Engineer, we are looking for someone who thrives on designing, coding and maintaining high performance data processing applications in functional programming on the JVM platform (which is primarily in Clоjure), running on AWS. Our ideal candidate would have deep experience building internal and external latency sensitive APIs with functional programming using the most fitting tools and having the passion to champion new and exciting technologies to solve our unique and challenging problems.
Так что вот! Источник: https://www.linkedin.com/jobs/view/4174329635/
-
Кэширование
Небольшая заметка о кэшировании. Для начала тезис:
Кэш — это лекарство, которое подчас опасней болезни. Пользоваться им нужно аккуратно, а еще лучше — не попадать в ситуацию, когда он нужен.
Добавление кэша в проект несет много проблем. Например, на сколько его устанавливать? Если данные обновились, как его сбросить? Кажется, что ответить просто: давай на час, плюс добавим хук в ORM, чтобы после сохранения модели сбрасывался такой-то ключ.
На практике все сложнее. Данные могут поступать не только через ORM, но и пакетным импортом или вставкой в таблицу из скрипта. Легко прозевать сброс ключа, и клиент увидит старые данные. Можно оказаться в ситуации, когда кэши будут зависимы: один строится на другом, и какой сбрасывать — не ясно.
Помню, когда программировал на Python и Django, считалось нормой обмазываться кэшами на каждый чих. Фреймворк всячески поощрял это: были различные бэкенды кэша, декораторы, которые навесил на функцию — и готово. У кэшей даже были версии, представляете? С ними отстрелить ногу было еще проще.
По наивности разработчики думают, что если запрос к базе медленный, то его нужно кэшировать. Это крайне наивно. База данных для того и создана, чтобы выполнять запросы. Современные базы могут выполнять одновременно много, очень много запросов. Например, в текущем проекте база, к которой я изрядно приложил руку, держит 300 транзакций в секунду — а внутри огромные JSON-документы.
Вот что можно предположить, если база отвечает медленно:
- не используется пул соединений
- на каждый запрос открывается новое соединение
- запрос делает полное сканирование таблицы (нет индекса)
- индекс есть, но из-за кривого where он не работает
- разработчик делает 100500 get-by-id в цикле
- в запрос передают 65К параметров вместо массива или json
- неотимальная вставка, например insert в цикле вместо copy from
Ни один из этих пунктов не рассосется, если добавить кэш. Поэтому сначала нужно разобраться, что идет не так. А когда разобрались, проще исправить на месте, чем добавлять кэш.
Разумеется, бывают очень сложные запросы, которые нельзя выполнить быстро в силу их природы. Но погодите со своим кэшем: такой запрос легко материализовать в таблицу и время от времени обновлять. На таблицу можно повесить индекс и выбирать из нее. Выходит, кэш легко организовать в базе.
В широком смысле сетевой кэш — это вторая база данных. Если вы не справились с одной базой, с чего вы решили, что с двумя будет проще?
Какие еще проблемы кэширования можно назвать? Да хотя бы следующие.
Сериализация. Когда вы пишете данные в Memcache, как они сериализируется? Если это json, вы теряете даты и типы коллекций, например, множество становится списком. Если у вас словарь с целыми числами в ключах, это тоже станет проблемой: обратно вы получите строки. Хорошо, когда есть библиотека для бинарной сериализации. Но если один и тот же кэш читают в разных языках, это станет проблемой: вряд ли такая библиотека есть под все языки (кроме protobuf).
Прогрев. Пока кэш актуален, все хорошо. Но когда тысячи клиентов начнут обновлять его, кэш-серверу станет плохо. Нужен фоновый процесс, который обновит кэш в фоне за несколько минут до того, как он протух. Кто будет следить за этим процессом?
Транзакционность. В одном проекте мы так увлеклись кэшами, что словили глюк, когда несколько клиентов обновляли один и тот же ключ. Чтобы это разрулить, ведущий разработчик написал джанговский Cache с подобием транзакции. Когда кто-то хотел прочитать ключ
foo_bar, код проверял, есть ли ключfoo_bar__lock. Если да, это значило, что в этот момент кто-то обновляет ключfoo_bar, и в доступе отказывали. Это был костыль поверх костыля, но мы очень гордились.Полнота. Другой пример, о котором писал в комментариях. Когда-то в Wargaming мы выкатили новый проект. Главная страница была тяжелой, потому что собирала данные из десяти сервисов, плюс было несколько языков. Всю страницу завернули в кэш, но не учли, что в ключе не было текущей локали. Вышло так, что первым посетителем был кто-то из Чехии. Декоратор посчитал страницу для чешского языка и положил в кэш. В течение часа посетители видели страницу на чешском. Кнопку для экстренного сброса кэша никто не предусмотрел. И кстати — такая кнопка нужна, и она тоже требует затрат.
Резюмируя: лучший кэш — это его отсутствие. Если у вас нет кэшей в проекте — искренне поздравляю. Это сильно лучше той ситуации, когда кто-то его затянет.
-
Альтернатива для Германии
Немного политики. Пишут, что партия “Альтернатива для Германии” признана экстремистской — в смысле не в России, а в самой Германии.
Не имею понятия, что это за ребята, но — что-то мне это напоминает. Как только некая партия угрожает режиму, она объявляется экстремистской, то есть зашкварной. Нельзя не только быть в партии, но и репостить ее или поддерживать — это преследуется транзитивно.
Каждый европеец твердо знает: свобода и демократия есть только в Европе. И вот парни, которые чего-то достигли и мелькали в новостях, признаны экстремистами. Как-то не сходится: если они и правда клоуны, пусть наберут свои 0.1 процента и рассосутся. А если их поддерживает четверть Германии, это говорит о запросах общества, игнорировать которые — значит оттягивать неизбежное.
Но все режимы одинаковы. Главное — заткнуть рот несогласным и протянуть еще лет пять, а там видно будет.
UPD: в комментариях объяснили: этот тег дает право на прослушку и обыск без решения суда. Тоже ничего хорошего, кстати. Нужно только затем, чтобы создать базу для ареста.
-
Горький урок ABBYY
Этим утром попалась интересная статья: “Горький урок ABBYY: как лингвисты проиграли последнюю битву за NLP”.
Это история ABBYY: начало, быстрый рост, зенит, поражение на рынке с Гуглом, переезд и массовые увольнения. Разумеется, таких статей полно на Хабре, так что зачем еще одна?
Дело даже не в том, что написано в статье, а как. Автор работал в ABBYY, и у него лингвистические образование. Поэтому текст грамотный, последовательный, без тупых мемов и нейро-картинок для привлечения внимания. Нет слов-паразитов и штампов; нет воды, налитой чатом-гпт. Читать такой текст сегодня — удовольствие на уровне физического.
Содержание тоже не уступает: подробно рассказано, чем занимался ABBYY и какую Вавилонскую башню пытался построить. Интересны выводы, почему ABBYY с его ноу-хау и сотней лингвистов проиграл программистам из Гугла.
Мне показалось, выводы справедливы и в других областях, например программировании. Но об этом, возможно, в другой раз.
-
Три состояния
Упрощая, можно сказать, что человек бывает в трех состояниях: когда он один, когда с кем-то наедине и когда вокруг двое и более людей. В последнем случае неважно, сколько именно: два, три или сотня. Разница есть, но несущественная. Поэтому рассматриваю только варианты 0, 1 и 2+.
В каждом из состояний человек ведет себя по-разному. Фактически это три роли, между которыми мы часто переключаемся.
Понимание этих переключений помогает в жизни. Если человек хочет побыть один, не лезь с разговорами. Чтение книги и просмотр фильма относятся сюда же, потому что оба – про уход в себя.
Если человек в компании, не начинай важный разговор. При свидетелях человек думает прежде всего о том, как прикрыть свой зад и не опозориться перед другими. Здравый смысл отодвигается на второй план: репутация важнее.
Все сводится к тому, что любой разговор можно завалить, если начать его с человеком в неподходящем состоянии. С другой стороны – почти любой разговор можно завершить успехом, если собеседник в правильном состоянии. Осталось понять: где, когда и с кем, а остальное просто.
-
Про Обсидиан
Это заметка про Обсидиан, которая не понравится никому. Тем не менее…
В программе Обсидиан ничего плохого нет. Наоборот, это хорошая программа: у нее даже есть признаки адекватности. С ней можно начать без облачной учетки, хотя другая программа потребовала бы ее на старте и напоминала бы каждые пять минут: дорогой, ты не авторизован! Данные пропадут, скорей оформи подписку.
Меня смущает не программа Обсидиан, а ее пользователи. Здесь прямая аналогия с механическими клавиатурами. В них нет ничего плохого, но есть пользователи, которые годами крафтят кастомные клавиатуры и годами их обсуждают. Точно так же пользователи Обсидиана придают много внимание тому, что этого не стоит.
Обсидиан и аналоги создали некую моду: все толковые ребята ведут цифровые заметки, аналог Цеттелькассена. Если ты ведешь Обсидиан, ты профессионально растешь, ты крут, свой чувак. А если нет – фу-фу.
Эта мода сквозит в различных сообществах и Телеграм-каналах; об этом говорят в комментариях ко всем статьям на тему заметок. Пишут статьи о том, как из набора сервисов собрать свой “чемодан заметок”. В первом же комментарии упоминают Обсидиан, и начинается срач.
Обсидиан вывел в тренд некрасивую привычку: показывать всем свой граф знаний. Подобно владельцу айфона, который только что его купил и открывает без надобности, пользователь Обсидиана без конца смотрит на граф заметок. Искусственно наращивает его, добавляет лишние связи, потому что теория “чемодана” учит, что заметок без связей быть не должно. Стоит ли говорить, что этот граф – всего лишь ментальный онанизм.
Я не верю, что заметки и граф связей как-то помогают в обучении. Человек на полном серьезе пишет, что благодаря Обсидиану “выучил” Питон. То есть он прослушал лекции и для каждого урока составил заметки и связал их. Разумеется, попади он в первый проект на Питоне, эти заметки пойдут лесом. Важно не составлять заметки, а практиковать знания и закреплять их практикой. Скажем, прослушал урок про списки в Питоне – открываешь учебник по Турбо-Паскалю и прорешиваешь 20 задач, заменяя слово “массив” на “список”. От этого есть польза, а от цифровой заметки – нет.
То же самое пишет Барбара Оакли в книге “Думай как математик”, а также ее колеги-преподы. Все они утверждают, что конспектирование – это хорошо, но гораздо важнее вспоминать и пересказывать материал самому себе, а также скорее закрепить его практикой. Без этого конспектирование дает лишь видимость изучения и уподобляется подчеркиванию в книгах.
Я с трудом представляю, для чего люди ведут заметки в Обсидиане. Изучаешь ты, например, Питон, пишешь заметки к видеокурсу. Так заведи публичный канал в Телеграме и пиши туда! – пусть другие тоже видят, комментируют, поправляют. Всем польза. Для списка ссылок Обсидиан явно избыточен, подойдет файлик или скрытый канал в Телеграме. Для списка дел и дневника подходит обычный блокнот. Зачем брать какую-то программу?..
О том, что при работе с бумагой и ручкой мозг работает по-другому, я писал сотню раз и не буду повторять. Просто попробуйте.
В книге Make Time один из авторов приводит хороший пример. Он подсел на программу заметок, и после обновления операционки она отвалилась. Автор к тому времени забил и обновление не выпустил. Вряд ли это случится с Обсидианом, но тем не менее: не нужно становиться заложником софта.
Верный признак того, что Обсидиан избыточен – это обилие инструментов к нему. Фирма, которая его пишет, вынуждена тащить все подряд, чтобы удовлетворить всех. Помните, это как вкладки в браузере? Кому-то вертикальные, кому-то горизонтальные, по кругу, с предпросмотром, с попапом с данными о потребленной памяти, с закрытием по таймеру и так далее.
Не за горами час, когда вы обновите свой Обсидиан и обнаружите, что он стал медленным и появились интеграции с Твиттером, Покетом и бог знает чем – все потому, что об этом попросили упоротые клиенты, а менеджмент пошел на поводу. Если вам это ни о чем не говорит, погуглите историю сервиса Evernote.
Еще напомню про Агату Кристи, которая написала 50 томов без Обсидиана. Стивен Кинг пользовался блокнотом: первая электронная печатная машинка (даже не компьютер) появилась у него в зрелом возрасте. Чтобы дать что-то миру, вам не нужна программа электронных заметок. Все уже здесь.
Обсидиан сегодня – это мода. Это забавная программа вроде Майнкрафта, в которую не зазорно играть взрослым. Строишь свой мирок, наблюдаешь прогресс, делишься успехом с друзьями. Не возводите его в культ. Не будьте чуваком с картинки ниже. Это пройдет.
-
Программисты и бизнес
Иные говорящие головы двигают такой тезис: хороший программист по мере развития все больше приобщается к бизнесу. Думает, как улучшить продукт, повысить конверсии-воронки и все такое… ходит на совещания с владельцами бизнеса.
Ну… не знаю. Пытался играть в эти игры, но не смог. Мне не интересен бизнес. Не интересно, сколько пользователей привлекли, сколько уников зашло и так далее. Не мое это, хоть убейте.
Мне интересен код. Люблю делать задачу максимально просто: поменьше библиотек, меньше сервисов, без ОРМ. Пишу тесты, добиваюсь, чтобы все случаи покрывались локально, без облака. В общем-то и все. За это прошу лишь минимальную свободу и право выбора технологий.
И знаете, кажется, это то, чего от меня ждут. Заказчик хочет, чтобы задача была сделана быстро и качественно, и чтобы в будущем можно было легко поправить. Это я и делаю. Не имею понятия, кто и как пользуется моей работой, и бывает, узнаю об этом через год.
Я совершенно не сочувствую бизнесу, когда дела идут плохо. Это не мое дело. Я работал в настолько абсурдных стартапах, что искренне недоумевал, что в них кто-то верит. Их судьба предопределена, единственный вопрос — сколько раундов инвестиций они протянут. И еще: сколько опыта я унесу с собой после ухода.
Поэтому рассказы про лояльность бизнесу на меня не действуют. Я пишу качественный код и получаю деньги. Если код не принес прибыли — извините, тут помочь не могу.
Вряд ли я достойный пример для подражания, но рассказы про бизнес нужно воспринимать с прохладой. Это лапша.
-
Вертикальная полоса
Как-то сижу, быдлокодю понемножку и замечаю, что в редакторе включена вертикальная полоса – ограничитель 80 символов. Думаю: странно, не помню, что ее включал. Я таким не пользуюсь – переношу код согласно внутреннему чутью. Но пусть будет, тем более что лень искать, как выключить.
А через месяц я подвинул окно и обнаружил, что это не ограничитель, а вертикальный ряд битых пикселей. Представьте, он не двигается за редактором и искажает цвет в любой программе.
Может быть, в прошлом я бы устроил внутреннюю истерику: как так, 4к-монитор, 144 герц, и вдруг сдох целый ряд. Но потом я подвинул редактор на место и продолжил быдлокодить. С тех пор притворяюсь, что это ограничитель.
Чем меньше истерик – как внешних, так и внутренних – тем лучше для психики. Мне кажется, это правило продлевает жизнь, хоть и доказывать еще рано.
Writing on programming, education, books and negotiations.