Limitless

Выступление с BeerJSSummit 2019 ¹

Привет. Меня зовут Максим. Я живу в Гомеле и пишу всякий код и я расскажу вам о том, как полезно отсутсвие ограничений. Не зря же я пишу многотомники о жизни с высоты своих годов

Игры

За эти годы я практически не играл в видеоигры

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

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

Слайды

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

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

Иначе, без текста, как помнить о чём говорить дальше?

Иначе, без текста, как донести мысль слушателям?

Скриншотами из закулисья?

Видео про точки-с-запятой?

Сеансом медитации?

Не смешите

Код

Или как мне написать приложение без электрона? А то приходится спорить с олдфагами, для которых сотня мегабайт — это “слишком много” во времена терабайтных SSD. Что такое сотня мегабайт в сравнении с неделями на изучение Котлина, Свифта или чего там сегодня у них?..

Тем более, мне интересно написать что-то на знакомом инструментарии для незнакомого окружения. С окошками, с иконками в статусбаре, со страничкой в магазине приложений — это статусно

А так как я знаком с npm’ом, то быстро найду модули, которые сделают из незнакомого окружения что-то более JSовое

Модули вообще шикарные. Допустим, что проблемы — это машины, а модули — это дороги. Когда машин становится слишком много, то они мешают проезду (решению) друг друга

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

Возникла проблема — поставил модуль. У модуля сложное API — поставил для него wrapper. Лень набирать run для запуска скриптов — поставил yarn

Если какое-то решение “забросили” и редко им пользуемся, то его всегда можно удалить

Да и даже если нельзя его удалить, то что страшного может произойти из-за уже-не-нужного кода?..

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

Breakdown

Нет, чёрт, я так не могу продолжать. Всё равно зря всё это

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

А кто не согласен, тех не переубедить словами. Ну ведь правда же: легче ж добавить ещё один инструмент, чем справиться имеющимися

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

Остальные скажут, что “надо всегда пробовать и учиться чему-то новому”. Но ведь не обязательно учиться в продакшене. Кому-то же придётся поддерживать ваши черновики (особенно если результаты этих черновиков понравились юзерам)

Или скажут, что “нам не до хорошего, нам бы релизнуть что уже есть”. Ну да, жизнь-боль, клиенту надо на вчера, бизнес-требования, бла-бла-бла. Мне на это тяжело как-то возразить

Так если тяжело возразить, может, вместо этого развлечь, спрятав суть про ограничения под слоями иронии и постмодернизма?

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

Правда, может оказаться, что трюк “спорить с самим собой” уже кто-то делал, но что ж…