-
Слабые фильмы
Уже пятый раз со мной такое. Читаю на условной Медузе про нашумевший фильм, иду, и… фильм оказывается удивительно слабым. Кинокритик разливался соловьем, а фильм затянут, конфликт примитивен, диалоги и сцены натянуты. Выхожу из зала с разочарованием.
Это случается все чаще и чаще. То ли я постарел, то ли ожидаю слишком многого. Я далеко не киноман — появляюсь в кинотеатре раз в три месяца. Мои чувства не притуплены бесконечными сериалами и фильмами. Может, в этом и проблема, как ни парадоксально?
Я вспомнил фильмы, от которых многого ожидал, но в итоге они оказались слабыми.
Магазинные воришки
Фильм про семью бедняков в Японии. Живут в нищите, зато дружно. Родители учат детей воровать в магазинах. Поначалу приятно: японский быт, ужин дошираками в тесном кругу. Семья подбирает девочку, с которой плохо обращаются, и ее принимают как дочь. Но потом слишком затянуто, ноль действия.
-
Плохие проекты
Поговорим о плохих проектах. Как понять, что проект плохой, а команда не профессиональна? Я собрал несколько признаков, которые прямо или косвенно говорят об этом. С каждым из них я борюсь много лет и вот решил написать. Если вы узнали свою команду, на вашем месте я бы встревожился.
Проект не подготовлен к старту
К сожалению, не каждый проект готов к старту после того, как вы скачали его код. И редко когда в проекте есть скрипт или Make-файл, который подготовит все нужное. Хотя технически это возможно.
Например, в условный Makefile можно засунуть установку виртуального окружения, утилит и пакетов, перенос файлов, скачивание ресурсов с сервера… но почти никто этого не делает. Приходится долбить коллег тупыми вопросами. Где взять этот файлик? Почему не ставится эта библиотека?
Причина кроется в лени и неуважении к коллегам. Если ты проделал рутинную подготовку, то почему бы не скопировать команды терминала в файл? Разве не очевидно, что следующий разработчик пойдет по тем же граблям?
В каждом проекте я держу Makefile и наполняю его разными задачами. Это база знаний о том, что можно сделать с проектом. Иногда коллега что-то спрашивает, а я отвечаю с именем Make-задачи, которую нужно запустить.
Если проект стартует только после часовой ручной подготовки, это плохой проект. Плох не код, а команда, которая его поддерживает. У них не принято думать об удобстве коллег, что критично в повседневной работе.
-
Слайды
Я смонтировал около ста выступлений (раз, два, три) и подметил недостаток, про который мало кто говорит.
Вот закончил человек презентацию. Спасибо, вопросы? Кто-то задал, уточняет детали. Выступающий: это же было на третьем слайде! И давай мотать в самое начало с тридцать пятого слайда на третий.
Так делать не надо. Во-первых, если вопрос по существу и зритель следил за мыслью, показывать слайд опять нет смысла. Вы уже показывали его, но что-то осталось непонятно. Скорей всего это вы объяснили плохо. Не нужно держать зрителя за дурака и тыкать ему тот же слайд. Правильно объяснить другими примерами и образами.
Во-вторых, во время перемотки образуется дурацкая пауза. Нажать двадцать раз на кнопку не так просто, и секунд пять-десять зрители ждут. Это мертвая зона, от которой становится неловко. Всех, кто выходит на сцену, учат — пауз быть не должно, особенно технических. Вы со своей презентацией не исключение.
Возьмите на заметку: не мотать слайды из конца в конец.
-
Прослушка
У нас дома телевизор, но мы пользуемся им как панелью. Антенны нет, подключаю ноут по HDMI и телек виден как второй монитор. Недавно обнаружил, что девайс продвинутый, с магазином приложений. Поставил Ютуб, зашел под учеткой и теперь смотрю без ноута.
Вчера включал дочке мульты. На главной Ютуба рекомендованные видео. Обычно это советские мультики вперемешку с тем, что я слушаю на работе. То есть Цветик-Семицветик — Korn — Кошкин дом — Enigma и так далее.
Но то, что я вчера увидел, заставило насторожиться. Ютуб предлагал к просмотру “Самогонщики” Гайдая. Помните, комедийная новелла с забавной троицей? С обложки смотрят Моргунов, Никулин и Вицин с характерными физиономиями.
Я стал ломать голову, с какого перепугу Гугл рекомендует что-то подобное, и не находил ответа. Я не смотрел ничего из советского кинематографа лет пять. Не гуглил биографии актеров. Мои интересы полностью ортогональны “Самогонщикам” и всему творческому пласту того времени.
А потом догадался, и стало не по себе.
Днем раньше я ехал в поезде. Ездили с сыном в деревню к бабушке. Поезд был фирменный, сидели в купе. Над входом в купе висел телевизор, по которому крутили “приключения Шурика”. В поездке я открывал ноут и подключал хот-спот. Интересное совпадение — вчера ты сидел возле телевизора с “Шуриком”, а сегодня Ютуб предлагает “Самогонщиков”.
Если это так, остается одно объяснение. Устройства слушают шум вокруг нас и отправляют в сервисы Гугла. Система распознает музыку, и корректирует веса рекомендаций.
Конечно, это не новость. Все большие компании хоть раз да были замечены в сборе данных без нашего ведома. На месте фирмы я бы тоже их собирал. Это ценная информация, с какой стати отказываться?
Но это первый раз, когда я столкнулся с такой сложной схемой. Передать шум поезда на сервер, распознать “Операцию Ы” и перестроить рекомендации – это все-таки сильно. У меня нет претензий к Гуглу: никто не умер, я сам на все подписался. Только удивление и тема для размышлений.
Кстати, именно поэтому я вырезал в веб-версии Ютуба блоки с рекомендациями. Это делается ад-блоком: навел курсор на регион и добавляешь селектор в черный список. Я не могу жить с этими блоками. Они начисто лишают хоть какой-то приватности, выдают все до последней интимности.
Однажды я посмотрел выступление Петросяна, которое запомнил из детства. Блок наводнился Степаненко, Маменко, бабками из Кривого зеркала и всей этой публикой. Не отмоешься!
Я полагаю, что системы рекомендации чувствительны к резкой смене контента. Возможно, это сделано специально. Может быть, для системы это значит, что за комп сел другой человек. Никто же не переключает учетку на айпаде, которым пользуется вся семья. Если смотрели пять Лунтиков, а потом Петросяна, это значит, что девайс передали другому человеку. И теперь надо рекомендовать не Смешариков, а Степаненко.
А если я не прав, то расскажите кто знает эту кухню.
-
Конфигурация
Содержание
- Постановка проблемы
- Семантика
- Цикл конфигурации
- Ошибки конфигурации
- Практика
- Подробнее о переменных среды
- Переменные среды в Clojure
- Простой менеджер конфигурации
- Чтение среды из конфигурации
- Короткий обзор форматов
- Промышленные решения
- Заключение
В этой главе мы рассмотрим, как сделать Clojure-проект удобным в плане настроек. Мы разберем основные приемы конфигурирования: форматы файлов, переменные среды, несколько библиотек, достоинства и недостатки различных подходов.
-
Не хочу мнений
Я мечтаю о том, чтобы иногда что-то высказать, но не получить обратной связи. Не услышать, что думает собеседник. Не обязательно каждый раз, хотя бы изредка, потому что это роскошь.
Ведь как бывает: скажешь что-нибудь про новую книгу, фильм или программу, и что? Тебе обязательно ответят. Скажут, что книга устарела, в другой написано лучше. Что программа не нужна, когда все уже есть из коробки. Что в фильме плохие актеры и вообще послушай, сейчас я тебе все расскажу.
Так, стоп. Я не просил чужих мнений. Почему-то у людей не укладывается в голове простая вещь. Их мнение никто не спрашивал! Если я сказал про новую книгу, я не прошу чужих оценок. Я просто сказал. Не нравится книга — проигнорируй. Или попроси не разговаривать о книгах, я не обижусь, правда.
Когда мне говорят про новый софт или фильм, я лишь пожимаю плечами или благодарю. Новый редактор? Ну ок, здорово. Понятно, что я его никогда не поставлю, но собеседнику-то какая разница? Он тащится, ему клево. Порадуйся за него, с тебя не убудет.
Не надо сразу пропихивать свое мнение. Оно важно только по требованию. Вот если бы я подошел и спросил, какую книгу почитать в следующей поездке, тогда другое дело. Но я же не подошел.
Несколько лет назад я страдал такой же фигней, пока не нашлось средство. Я тогда увлекся Хаскелом и монадами и приседал на уши там, где меня не просили. Прекрасно понимаю, что я нес ахинею, но люди вокруг были не лучше. Они банально не слушали, что я говорю и несли встречную пургу. Получался как бы спор глухого с немым.
Однажды моим собеседником был очень опытный программист, человек гораздо старше. Он триггернул меня, и я завел ту же песню. Собеседник, внезапно, молчал и слушал с таким вниманием, как никто и никогда не слушал. Я сначала занервничал: почему он не перебивает, не приводит аргументы? Зря что ли я заготовил доводы против?
И в этот момент я услышал сам себя. Понятно, я и раньше слышал, но в этот раз это случилось как будто со стороны. Я осознал, что выгляжу жалко, что не понимаю сути, что повторяю чужие слова. Еще я понял, что собеседник это понял. Поэтому поскорей закончил разговор и больше так не делал.
Понятно, что этого бы не случилось, не будь того собеседника рядом. А ведь он ничего особенного не сделал — просто слушал и смотрел в глаза! Он был даже не собеседник, а слушатель. Благодаря ему я один раз себя услышал, и такая была польза.
С тех пор я хочу, чтобы в моем окружении было больше людей, которые умеют слушать. Не потому, что с моих уст сыплются перлы мудрости. А потому, что я хочу иногда слышать сам себя, а не чужое мнение.
-
Изменяемость в Clojure
Содержание
- Общие проблемы изменяемых данных
- Атомы
- Volatile
- Переходные коллекции
- Подмена переменных. Alter-var-root
- Немного о set!
- Изменения в контексте. Binding
- Локальные переменные в контексте
- Глобальные изменения в контексте
- Все вместе
В этой главе мы поговорим про изменяемость данных. Тем, кто программирует на классических языках, покажется странным, что теме уделено так много внимания. Причина кроется в дизайне языка. Неизменяемые коллекции – одна из центральных идей Clojure.
В классических языках данные по умолчанию изменяются, а стандартная библиотека предлагает ограничения: локи, атомарные изменения, постоянные коллекции. Clojure устроена наоборот: по умолчанию данные не изменяются, а стандартная библиотека включает несколько техник, чтобы изменять данные. Этим техникам и посвящена глава.
Руководства по Clojure учат работать с неизменяемыми данными. Это приводит к тому, что начинающие программисты на Clojure испытывают трудности, когда возникает потребность менять данные. На время этой главы мы займем противоположную позицию: рассмотрим, какими способом хранить и управлять состоянием в программах.
-
Подружиться с исключениями. Видео с митапа
В прошлом месяце ездил в Москву, выступал на кложурном митапе. Выкладываю видос с чистым звуком:
-
Теги и Instant View
Вчера обновил блог. Первое достижение – появились теги. Я и раньше проставлял их, но не было возможности искать по ним. Теперь под заголовком каждого поста указаны его теги. Ссылка по тегу открывает список постов с ним.
Раньше я просто валил посты в кучу, а теперь понял, что надо как-то их структурировать. Поиск от Гугла хорош, но не дает полной картины. Планирую сделать разделы по Кложе и Питону, собрать все видео, словом, навести порядок.
Второй прорыв – сделал для блога Instant View в Телеграме. Это когда пост можно просмотреть прямо в клиенте без перехода на сайт. Это был очень интересный опыт. Еще не успел ничего автоматизировать, эту заметку заброшу вручную в канал. Дальше буду думать. И напишу отдельный пост, как все сделать по шагам.
-
Исключения в Clojure
Это третья глава предполагаемой книги по Кложе на русском языке.
Содержание
- Основы исключений
- Цепочки исключений и контекст
- Переходим к Clojure
- Контекст ошибки
- Когда бросать исключения
- Подробнее о цепочках
- Печать исключения
- Логирование
- Исключения как данные. Сбор исключений
- Переходы
- Finally и контекстный менеджер
- Исключения на предикатах
- Приемы и функции
- Заключение
В этой главе речь пойдет об исключениях. Поговорим о том, как они устроены и в чем их особенность. Когда лучше кидать, а когда ловить исключения. Как записать их так, чтобы расследовать инцидент было легко.
Возможно, читателю покажется странным, что на столь простую тему написано так много. Но исключения не так просты, как принято считать. По мнению автора, другие книги уделяют им возмутительно мало внимания. Считается, что программисту достаточно знать, что исключения бросают, ловят и пишут в лог. Движемся дальше.
Это не так. Технически исключения просты, но несут обширную семантику. Когда их кидать, когда перехватывать? Как извлечь полезную информацию из цепочки исключений? Куда их записывать? Возможно ли ловить исключения предикатами? Трудно вспомнить книгу или руководство, которое отвечает хотя бы на часть этих вопросов.
Начинающие программисты пишут код, следуя только положительному пути. Отчасти поэтому так трудно расследовать ошибки. Сервер вернул статус 500. Почему? Возможны сотни причин, по которым запрос не удался. Но запись в логе слишком скупа, чтобы расследовать инцидент.
Опытный программист внимателен к ошибкам. Приходит понимание, что сэкономив на обработке исключений, разработчик на самом деле не выиграет. В перспективе он потратит время на расследование непонятных ошибок.
Будет правильным считать, что ошибки столько же равноправны, как и нормальное поведение программы. Ошибки типичны в сетевых сервисах, в больших распределенных системах.