А вообще, если вы, как и я, вляпались зачем-то в Java экосистему, особенно энтерпрайзную, и начинаете все больше и больше испытывать отвращение к программированию, все острее чувствовать абсурдность происходящего и бояться за свой рассудок, помните:
С вами все в порядке. Вы молодец и все делаете правильно. Проблема в консерватории, ее уже не починить.
Также помните, что рядом тоже полно нормальных, адекватных людей, которые создают куда более приятные экосистемы. Такие, в которых люди не соревнуются в том, кто кого переусложнит и у кого Hello World займет больше строчек, сервисов и ресурсов. В которых проекты измеряются не миллионами строк кода, а десятками тысяч, и ни в чем не уступают по функционалу. Проекты, которые зарабатывают миллионы долларов и меняют мир, ничуть не менее «серьезные», вопреки мнению тех самых энтерпрайзных джавистов.
И туда всегда можно перейти, найти свое счастье и душевное спокойствие. Я в свое время сбежал на Питон, потом на Erlang, и в конце концов на Clojure.
В любом случае, бежать к адекватным людям и здравому смыслу было лучшим решением в моей жизни. Рекомендую.
На этом неделя Java в канале официально объявляется закрытой, и мой гештальт тоже. Надеюсь, в следующий раз услышу о ней не раньше чем через еще 10 лет.
P.S. Если вам нормально — ну и классно, просто проигнорируйте этот пост
P.P.S. JVM все еще нежно люблю, пост исключительно о java как экосистеме
P.P.P.S. Убрал языки, про которые я знаю только понаслышке. Там тоже может быть хорошо, но обещать не могу
С вами все в порядке. Вы молодец и все делаете правильно. Проблема в консерватории, ее уже не починить.
Также помните, что рядом тоже полно нормальных, адекватных людей, которые создают куда более приятные экосистемы. Такие, в которых люди не соревнуются в том, кто кого переусложнит и у кого Hello World займет больше строчек, сервисов и ресурсов. В которых проекты измеряются не миллионами строк кода, а десятками тысяч, и ни в чем не уступают по функционалу. Проекты, которые зарабатывают миллионы долларов и меняют мир, ничуть не менее «серьезные», вопреки мнению тех самых энтерпрайзных джавистов.
И туда всегда можно перейти, найти свое счастье и душевное спокойствие. Я в свое время сбежал на Питон, потом на Erlang, и в конце концов на Clojure.
В любом случае, бежать к адекватным людям и здравому смыслу было лучшим решением в моей жизни. Рекомендую.
На этом неделя Java в канале официально объявляется закрытой, и мой гештальт тоже. Надеюсь, в следующий раз услышу о ней не раньше чем через еще 10 лет.
P.S. Если вам нормально — ну и классно, просто проигнорируйте этот пост
P.P.S. JVM все еще нежно люблю, пост исключительно о java как экосистеме
P.P.P.S. Убрал языки, про которые я знаю только понаслышке. Там тоже может быть хорошо, но обещать не могу
Перестаем ныть и переходим к конструктиву. В комментах к прошлому посту спрашивали, как же починить проблему логирования, когда есть 15 разных библиотек?
Действительно, логирование штука очень неудобная, в первую очередь потому что библиотеки. Каждая библиотека выбирает свой фреймворк, вы выбираете 15 библиотек (это еще по-божески) и привет, у вас в приложении 15 разных логгеров. Вот что с этим делать?
Давайте применим дизайнерское мышление и проанализируем ситуацию. Сторонние библиотеки не работают, потому что кто-то нет-нет да и напишет новую, а какой-нибудь глупец соблазнится на сиюминутные преимущества и заиспользует ее, проигнорировав общую картину. То есть сразу нет.
Методом исключения получаем, что логирование должно быть в стандартной библиотеке языка. Иначе никак.
Кстати, в Java логирование _есть_ в стандартной библиотеке, но проблема осталась. Почему так? Почему никто не переехал на
Первая — потому что мало сделать новый логгер, надо еще перестать использовать старый. В программировании вообще недооценен процесс возвращения и переделывания того, что было сделано, а зря. Дописывание — да, за милую душу, а вот переписывание не любят. Хотя я, например, обожаю переделывать и переписывать, потому что перфекционист и с первого (и даже со второго) раза нормально сделать не могу (нормально по моим меркам, по меркам индустрии у меня и с первого раза очень неплохо получается).
Вторая версия — что
И тут я выскажу радикальное мнение: по мне, так логгинг должен быть максимально куцым. Тот же log4j может: срать в несколько файлов, обкусывать файлы, менять файлы в зависимости от дня недели, фильтровать записи, форматировать записи, грузить конфиги, перезагружать конфиги, варить кофе^W^W. Это полноценный фреймворк, на настройку которого можно потратить не один день.
Что же в этом плохого? Опять же, давайте посмотрим на общую картину (дизайн мышление, помните?). Если логгер умеет делать так много, это значит что он будет делать так много, то есть, все эти настройки будут гвоздями прибиты к вашему приложению.
А это не задача вашего приложения — решать, где я хочу видеть логи, сколько и как часто. Генерить логи — да, пожалуйста, но фильтрация, хранение, организация — это явно другой уровень и решаться должно снаружи. Когда это делается изнутри, это негибко, это лишний функционал и плохая интеграция. Будете в следующий раз пить аспирин после настройки log4j — задумайтесь об этом. 12 factor apps всем, пацаны!
Так что же, как в итоге должен выглядеть идеальный логгер? Идеальный логгер — это
Действительно, логирование штука очень неудобная, в первую очередь потому что библиотеки. Каждая библиотека выбирает свой фреймворк, вы выбираете 15 библиотек (это еще по-божески) и привет, у вас в приложении 15 разных логгеров. Вот что с этим делать?
Давайте применим дизайнерское мышление и проанализируем ситуацию. Сторонние библиотеки не работают, потому что кто-то нет-нет да и напишет новую, а какой-нибудь глупец соблазнится на сиюминутные преимущества и заиспользует ее, проигнорировав общую картину. То есть сразу нет.
Методом исключения получаем, что логирование должно быть в стандартной библиотеке языка. Иначе никак.
Кстати, в Java логирование _есть_ в стандартной библиотеке, но проблема осталась. Почему так? Почему никто не переехал на
java.util.logging? У меня две версии, и подозреваю, они сыграли обе.Первая — потому что мало сделать новый логгер, надо еще перестать использовать старый. В программировании вообще недооценен процесс возвращения и переделывания того, что было сделано, а зря. Дописывание — да, за милую душу, а вот переписывание не любят. Хотя я, например, обожаю переделывать и переписывать, потому что перфекционист и с первого (и даже со второго) раза нормально сделать не могу (нормально по моим меркам, по меркам индустрии у меня и с первого раза очень неплохо получается).
Вторая версия — что
java.util.logging вышел куцым по функциональности в сравнении с «настоящими» логгерами. Мне-то как раз это нравится, а вот Java-программистам, подозреваю, не зашло.И тут я выскажу радикальное мнение: по мне, так логгинг должен быть максимально куцым. Тот же log4j может: срать в несколько файлов, обкусывать файлы, менять файлы в зависимости от дня недели, фильтровать записи, форматировать записи, грузить конфиги, перезагружать конфиги, варить кофе^W^W. Это полноценный фреймворк, на настройку которого можно потратить не один день.
Что же в этом плохого? Опять же, давайте посмотрим на общую картину (дизайн мышление, помните?). Если логгер умеет делать так много, это значит что он будет делать так много, то есть, все эти настройки будут гвоздями прибиты к вашему приложению.
А это не задача вашего приложения — решать, где я хочу видеть логи, сколько и как часто. Генерить логи — да, пожалуйста, но фильтрация, хранение, организация — это явно другой уровень и решаться должно снаружи. Когда это делается изнутри, это негибко, это лишний функционал и плохая интеграция. Будете в следующий раз пить аспирин после настройки log4j — задумайтесь об этом. 12 factor apps всем, пацаны!
Так что же, как в итоге должен выглядеть идеальный логгер? Идеальный логгер — это
println.Джон Блоу (да-да, тот самый, который Preventing the Collapse of the Civilization) высказывает (ну как высказывает, высказывал, в январе еще) интересную мысль в подкасте On The Metal.
Во-первых, насколько обидно, что мы наконец более-менее унифицировали процессоры, убрали барьер железной совместимости, зато понаставили новых — в этот раз операционных систем. Обидно, что единственное, что мешает взять файл, скомпиленный у меня на компьютере, и запустить ровно этот же файл у тебя на компьютере это какие-то глупые, мелочные детали, эхо войны вендоров ОС и их полная неспособность дружить и договариваться. Хотя процессору, вообще говоря, все равно, и делать он будет в конечном итоге одно и то же.
Во-вторых, по его мнению, появление динамических языков — это своего рода ответ на вот эту вот потребность «взять файл, который работал у меня, и запустить ровно этот же файл у кого-то еще». Понятно, что есть еще аспект «высокоуровневости», но про файл тоже интересно.
Ну и в третьих он считает, что в принципе программы в компьютере плохо дружат. Есть, типа, shell, в котором программы обмениваются строками через пайп, и это стыд, конечно. И есть, причем очень давно, нормальный способ переиспользовать чужой код — C calling conventions и, соответственно, динамические/статические библиотеки.
В общем-то, проблема всех остальных языков, которые не C, в том, что они сделали этот вариант сотрудничества максимально неудобным, и вместо того чтобы дружить с уже существующим кодом стали строить весь мир с нуля. Ну и они не только с С не дружат, но и между собой тоже, так что каждый из них это такой Walled Garden без каких-либо планов на стать чем-то большим.
Такая вот перспектива, издалека. Даже какой-то смысл в WASM появляется, даже не для браузеров, а для обычных десктопных утилит и программ
Во-первых, насколько обидно, что мы наконец более-менее унифицировали процессоры, убрали барьер железной совместимости, зато понаставили новых — в этот раз операционных систем. Обидно, что единственное, что мешает взять файл, скомпиленный у меня на компьютере, и запустить ровно этот же файл у тебя на компьютере это какие-то глупые, мелочные детали, эхо войны вендоров ОС и их полная неспособность дружить и договариваться. Хотя процессору, вообще говоря, все равно, и делать он будет в конечном итоге одно и то же.
Во-вторых, по его мнению, появление динамических языков — это своего рода ответ на вот эту вот потребность «взять файл, который работал у меня, и запустить ровно этот же файл у кого-то еще». Понятно, что есть еще аспект «высокоуровневости», но про файл тоже интересно.
Ну и в третьих он считает, что в принципе программы в компьютере плохо дружат. Есть, типа, shell, в котором программы обмениваются строками через пайп, и это стыд, конечно. И есть, причем очень давно, нормальный способ переиспользовать чужой код — C calling conventions и, соответственно, динамические/статические библиотеки.
В общем-то, проблема всех остальных языков, которые не C, в том, что они сделали этот вариант сотрудничества максимально неудобным, и вместо того чтобы дружить с уже существующим кодом стали строить весь мир с нуля. Ну и они не только с С не дружат, но и между собой тоже, так что каждый из них это такой Walled Garden без каких-либо планов на стать чем-то большим.
Такая вот перспектива, издалека. Даже какой-то смысл в WASM появляется, даже не для браузеров, а для обычных десктопных утилит и программ
👍2
Главное правило хорошей программы — код должен работать. Любой код, который не запускается регулярно, протухает и ломается. Да, даже если его не трогать. Особенно, если его не трогать. Прям как продукты, хоть и сделан из чистой информации.
Например, в Grumpy Website есть авторизация, которая сбрасывается раз в две недели. Почему? Да потому что это гарантия, что она будет работать. Если бы она жила вечно, то прошло бы полгода-год, кому-то понадобилось бы зайти с нового компа и мы все бы узнали, что авторизация, оказывается, давно сломана. А так она тестируется регулярно и всегда в форме.
Отсюда следствие: общих механизмов должно быть как можно больше, а специальных — как можно меньше. Например, попробовать отправить письмо сразу, а если не получилось — положить в очередь и попробовать позже — мина отложенного действия. Большинство писем будет уходить сразу и даже если очередь сломана, вы сможете долго этого не замечать. Правильно — складывать в очередь всегда и разгребать ее на общих основаниях, без каких-либо «оптимизаций».
Да, анекдот про вылить воду из чайника и перейти к шагу 1 (налить воду) совсем не анекдот, а очень хороший совет. А вы что думали, шутки про программистов — это шутки?
Например, в Grumpy Website есть авторизация, которая сбрасывается раз в две недели. Почему? Да потому что это гарантия, что она будет работать. Если бы она жила вечно, то прошло бы полгода-год, кому-то понадобилось бы зайти с нового компа и мы все бы узнали, что авторизация, оказывается, давно сломана. А так она тестируется регулярно и всегда в форме.
Отсюда следствие: общих механизмов должно быть как можно больше, а специальных — как можно меньше. Например, попробовать отправить письмо сразу, а если не получилось — положить в очередь и попробовать позже — мина отложенного действия. Большинство писем будет уходить сразу и даже если очередь сломана, вы сможете долго этого не замечать. Правильно — складывать в очередь всегда и разгребать ее на общих основаниях, без каких-либо «оптимизаций».
Да, анекдот про вылить воду из чайника и перейти к шагу 1 (налить воду) совсем не анекдот, а очень хороший совет. А вы что думали, шутки про программистов — это шутки?
❤1👍1
Давайте расскажу вам про главное правило пет-проектов. Главное правило пет-проектов: придумать, как ничего не делать.
Многие программисты могут подумать, что ничего не делать — это что-то автоматизировать. Нет, наоборот, автоматизирование добавляет головной боли, а мы хотим ее избежать. Например, мне в прошлом посте про «пассивный код — мертвый код» порекомендовали не мучать пользователя постоянными разлогинами, а завести тестового юзера и автоматизировать:
«Скрипты. Планировщик в CI запускает тесты, оформленные в pytest/junit/whatever, рисует красивые картинки, срёт уведомлениями, если что-то пошло не так. Надо только определиться, кто отвечает за реакцию на уведомления.»
Это, конечно, путь для нормальных систем, где программистам платят зарплату, чтобы они не дергались и делали то, что сами добровольно никогда бы делать не захотели.
Но в пет-проектах, к сожалению, зарплату не платят, поэтому приходится адаптироваться. Что не так с этим предложением?
Во-первых, очень много работы. Скрипты надо написать, всю эту машинерию — настроить. Во-вторых, очень много мейнтенанса — за CI надо следить, на уведомления реагировать. В-третьих, это все будет ломаться, это надо обслуживать, что явно будет лень делать, т.к. ломается оно всегда не вовремя, а проектом не каждую неделю есть время заниматься.
Трюк с пет-проектами в том, чтобы обмануть себя и успеть сделать что-то, что можно показать людям до того, как ты устанешь и тебе надоест. А тебе устанет и надоест, trust me. Поэтому количество нерелевантной работы надо резать жестко и беспощадно. И поэтому я так доволен решением с авторизацией: работы нет, а тестирование выполняется.
Классическая иллюстрация этого принципа это «не пишите движок блога». Потому что устанете быстрее, чем напишете первый пост. Люди, которые хостятся на Github Pages с готовым шаблоном или на Wordpress — те, которым интересно решить проблему; люди, которые пишут движок — те, которым интересно попрокрастинировать. Поэтому вы читаете этот текст в Телеграмме, а не на каком-то самописном сайте с собственным компилятором — я бы этот компилятор до сих пор писал.
Другой пример из недавнего — Roam Research. Чуваки лет то ли пять, то ли семь сидят без сервера вообще, тупо складывают все в Firebase и ничего, работают, денег подняли. Во всей инфраструктуре нет ни одного сервера. Потом пришел создатель Athens Research, решил склонировать Roam, но еще больше не заморачиваться, и не стал делать даже Firebase. Просто сделал локального клиента, так еще и без авторизации обошелся. И все равно 2 ляма поднял. Легенда.
Все это иллюстрирует один принцип: чем меньше работы вы себе придумаете, тем выше шансы все это закончить. И наоборот, будете делать «по-нормальному», «правильно» — и не закончите никогда. Потому что лето, пиво, дети, диван, друзья или плейстейшн побеждают «отдых программированием» в 100% случаев. Да вообще все что угодно его побеждает. И это нормально, с этим ничего не сделаешь, надо просто придумать, как в таких условиях работать.
Многие программисты могут подумать, что ничего не делать — это что-то автоматизировать. Нет, наоборот, автоматизирование добавляет головной боли, а мы хотим ее избежать. Например, мне в прошлом посте про «пассивный код — мертвый код» порекомендовали не мучать пользователя постоянными разлогинами, а завести тестового юзера и автоматизировать:
«Скрипты. Планировщик в CI запускает тесты, оформленные в pytest/junit/whatever, рисует красивые картинки, срёт уведомлениями, если что-то пошло не так. Надо только определиться, кто отвечает за реакцию на уведомления.»
Это, конечно, путь для нормальных систем, где программистам платят зарплату, чтобы они не дергались и делали то, что сами добровольно никогда бы делать не захотели.
Но в пет-проектах, к сожалению, зарплату не платят, поэтому приходится адаптироваться. Что не так с этим предложением?
Во-первых, очень много работы. Скрипты надо написать, всю эту машинерию — настроить. Во-вторых, очень много мейнтенанса — за CI надо следить, на уведомления реагировать. В-третьих, это все будет ломаться, это надо обслуживать, что явно будет лень делать, т.к. ломается оно всегда не вовремя, а проектом не каждую неделю есть время заниматься.
Трюк с пет-проектами в том, чтобы обмануть себя и успеть сделать что-то, что можно показать людям до того, как ты устанешь и тебе надоест. А тебе устанет и надоест, trust me. Поэтому количество нерелевантной работы надо резать жестко и беспощадно. И поэтому я так доволен решением с авторизацией: работы нет, а тестирование выполняется.
Классическая иллюстрация этого принципа это «не пишите движок блога». Потому что устанете быстрее, чем напишете первый пост. Люди, которые хостятся на Github Pages с готовым шаблоном или на Wordpress — те, которым интересно решить проблему; люди, которые пишут движок — те, которым интересно попрокрастинировать. Поэтому вы читаете этот текст в Телеграмме, а не на каком-то самописном сайте с собственным компилятором — я бы этот компилятор до сих пор писал.
Другой пример из недавнего — Roam Research. Чуваки лет то ли пять, то ли семь сидят без сервера вообще, тупо складывают все в Firebase и ничего, работают, денег подняли. Во всей инфраструктуре нет ни одного сервера. Потом пришел создатель Athens Research, решил склонировать Roam, но еще больше не заморачиваться, и не стал делать даже Firebase. Просто сделал локального клиента, так еще и без авторизации обошелся. И все равно 2 ляма поднял. Легенда.
Все это иллюстрирует один принцип: чем меньше работы вы себе придумаете, тем выше шансы все это закончить. И наоборот, будете делать «по-нормальному», «правильно» — и не закончите никогда. Потому что лето, пиво, дети, диван, друзья или плейстейшн побеждают «отдых программированием» в 100% случаев. Да вообще все что угодно его побеждает. И это нормально, с этим ничего не сделаешь, надо просто придумать, как в таких условиях работать.
👍4❤🔥1
Иногда я говорю, что не понимаю чего-то, но на самом деле конечно понимаю, просто несогласен. Но есть вещи, которые я сколько умом ни пытался понять, так и не смог.
Одна из таких — поведение
И вот тут вопрос: ПОЧЕМУ БЛЯДЬ???
Это классический foot gun же: ты думал, что
Это столько всего ломает и столько неудобств создает, что словами не передать. Про это надо в каждой дырке помнить, обкладываться if-ми и OR-ами, ну или надеяться, что никогда их не увидишь. Как будто без этого в программировании разочарований не хватает.
Одна из таких — поведение
NaN в IEEE 754 и NULL в SQL. Как вы знаете, NaN != NaN, а NULL <> NULL.И вот тут вопрос: ПОЧЕМУ БЛЯДЬ???
Это классический foot gun же: ты думал, что
a == a, и оно почти всегда да, кроме случаев, когда нет. Хочешь проверить, что функции вернули одно и то же? == будет недостаточно. Хочешь тест написать? == не хватит. В мапу положил, а потом найти не можешь? Смотря как ищещь. Передал по сети и сравниваешь JSON с эталонным? Не сравнится, потому что в глубине где-то есть NaN. Про SQL я вообще молчу.Это столько всего ломает и столько неудобств создает, что словами не передать. Про это надо в каждой дырке помнить, обкладываться if-ми и OR-ами, ну или надеяться, что никогда их не увидишь. Как будто без этого в программировании разочарований не хватает.
👍6
Вашему внимаю представляется список сложнейших, практически неразрешимых задач в IT:
- Инвалидация кэша
- Придумывание названий
- Off-by-one ошибки
- Кнопка «Назад»
- Плавный скролл
- Запомнить позицию скролла
- Плавные веб-анимации
- Звук на видеоконференциях
- Верстка имейлов
- Выравнивание текста и иконки
- Файловые пути с пробелами
- Запоминание «Запомнить меня»
- Не писать еще один пакетный менеджер (ой, написал)
- Логгирование в Джаве
- Юнит тесты в Джаве
- Сборка проекта в Джаве
- Выделение текста в PDF
- Оценка оставшегося времени в прогресс-барах
- Кража фокуса
- Запись в файл (надежная)
- Парсинг XML (надежный)
- Переключение режимов монитора в Windows
- Поиск пути, куда установлена Visual Studio
- Запоминание, на каком мониторе открывать окно
- Плавное изменение размера окна
- Подключение Bluetooth-наушников
- Цветовые пространства
- Ввод текста
- Вывод текста
- Часовые пояса
UPD (из комментов):
- Синхронизация файлов в iCloud
- Принтеры
- Выход из vi
- Счетчик непрочитанных
- Настройка фронтенд-проекта
- Инвалидация кэша
- Придумывание названий
- Off-by-one ошибки
- Кнопка «Назад»
- Плавный скролл
- Запомнить позицию скролла
- Плавные веб-анимации
- Звук на видеоконференциях
- Верстка имейлов
- Выравнивание текста и иконки
- Файловые пути с пробелами
- Запоминание «Запомнить меня»
- Не писать еще один пакетный менеджер (ой, написал)
- Логгирование в Джаве
- Юнит тесты в Джаве
- Сборка проекта в Джаве
- Выделение текста в PDF
- Оценка оставшегося времени в прогресс-барах
- Кража фокуса
- Запись в файл (надежная)
- Парсинг XML (надежный)
- Переключение режимов монитора в Windows
- Поиск пути, куда установлена Visual Studio
- Запоминание, на каком мониторе открывать окно
- Плавное изменение размера окна
- Подключение Bluetooth-наушников
- Цветовые пространства
- Ввод текста
- Вывод текста
- Часовые пояса
UPD (из комментов):
- Синхронизация файлов в iCloud
- Принтеры
- Выход из vi
- Счетчик непрочитанных
- Настройка фронтенд-проекта
❤1👍1😁1
Ох как я ненавижу логины и аккаунты.
Сегодня пытался залогиниться в посудомоечную машину. Почему, зачем? Ну она мне шлет нотификации, мол, пора меня чистить. Я бы и кнопками почистил, но там же иконки, а не подписи — пойди угадай, какая что значит.
Короче, сначала пытался понять, какое приложение вообще ей управляет. Машина — Siemens, поиск по Siemens или там Dishwasher конечно ничего не дал. В итоге листал тупо список всех вообще приложений на телефоне в поисках незнакомого. Home Connect называется.
Ладно, захожу. Оно говорит — нет устройств! Как нет-то, ты же, падла, нотификации мне шлешь.
Ну окей, давайте добавим. Жму добавить — оно говорит: сначала залогинься. Ну епт. А что это за приложение — я в душе не помню, но видимо когда-то его настраивал, раз нотификации приходят.
А раз настраивал — должен был аккаунт создать? Но почему тогда он слетел? Телефон я не менял, приложение не переустанавливал. Жму логин — 1Password — нет аккаунта.
Ну ладно, нет так нет, может раньше не требовался? Жму создать, заполняю блядскую форму на восемьнадцать полей, придумываю, конечно, пароль, ввожу два раза, и емейл, конечно, тоже два раза. И конечно, посудомоечной машине нужно знать где я живу и какой у меня телефон, чтобы полоскать мои чашки. ВСЮ ФОРМУ ДО КОНЦА ЗАПОЛНЯЮ! Все с телефона, то есть максимально неудобно, в квадратике 2 на 2 сантиметра. Жму: создавай.
Создала, говорит. Иди в емейл. Иду в емейл. А там — есть такой аккаунт уже. Попробуй залогиниться, лузер. И все, даже ссылки обратно, сука, нет. А СРАЗУ НЕЛЬЗЯ СКАЗАТЬ БЫЛО???
Иду логиниться. Пароля, конечно, взять неоткуда. Жму восстановить. Иди опять в почту. Иду в почту. Вот ваш временный пароль. О, думаю, зашибись. Его-то и оставлю. Ввожу емейл и копирую пароль. Зашибись, говорит! Но пароль-то временный. Давай новый придумывай. Ну ё-маё, ну что опять началось...
Ладно, придумываю. Соглашается. Пускает. Добавляю, наконец, машину в апп. Безболезненно достаточно, кстати — потому что Я ОДИН РАЗ ЭТО УЖЕ ДЕЛАЛ КУДА ОНА ПОДЕВАЛАСЬ? А? А?
Зашибись, думаю. Теперь-то запущу чистку. Нахожу режим в приложении. Подношу палец к кнопке. ЗАПУСК ИЗ ПРИЛОЖЕНИЯ ЗАПРЕЩЕН. ИДИ ПАСИСЬ.
(Ну или если хочешь можешь еще час в ютубе гуглить, как remote start разрешить, но у меня уже сил не было, честно).
Короче, я просто спалил, какая иконка у режима чистки в приложении.
А потом подошел к машинке ногами И НАЖАЛ ТОЧНО ТАКУЮ ЖЕ КНОПКУ. Просто подошел и просто нажал. Все. Одно действие. НИКАКИХ, БЛЯДЬ, ЛОГИНОВ. ПОЧЕМУ В ТЕЛЕФОНЕ НЕЛЬЗЯ ТАКЖЕ???
Вы удивляетесь, почему «умный дом» никто так не любит? Ну вот поэтому.
Ну и про проблему логинов и того, что их пихают везде, где нужно и где не нужно.
Во-первых, идите со своими логинами нахуй.
Во-вторых, идите-идите, я не шутил.
Во-третьих, если уж вас укушенный маркетологом менеджер заставил их делать, как насчет того, чтобы эти логины не терять? В идеале я хочу вводить логин один раз в жизни. Ну может один раз за время жизни компьютера. КАК ЛОГИН МОЖЕТ ПОТЕРЯТЬСЯ???
В-четвертых, одного поля «email» достаточно ДЛЯ ВСЕГО. Просто email — письмо со ссылкой — нажал — ты внутри. Логин, регистрация, восстановление — все одинаково. В вашей форме БУКВАЛЬНО не должно быть НИ ОДНО поля, кроме email. БУКВАЛЬНО.
В-пятых, на тему логинов обязательно посмотрите «Jonathan Blow tries Razer BlackWidow TE Chroma v2 keyboard» на Ютубе. Руководство к действию.
В-шестых, идите нахуй.
Сегодня пытался залогиниться в посудомоечную машину. Почему, зачем? Ну она мне шлет нотификации, мол, пора меня чистить. Я бы и кнопками почистил, но там же иконки, а не подписи — пойди угадай, какая что значит.
Короче, сначала пытался понять, какое приложение вообще ей управляет. Машина — Siemens, поиск по Siemens или там Dishwasher конечно ничего не дал. В итоге листал тупо список всех вообще приложений на телефоне в поисках незнакомого. Home Connect называется.
Ладно, захожу. Оно говорит — нет устройств! Как нет-то, ты же, падла, нотификации мне шлешь.
Ну окей, давайте добавим. Жму добавить — оно говорит: сначала залогинься. Ну епт. А что это за приложение — я в душе не помню, но видимо когда-то его настраивал, раз нотификации приходят.
А раз настраивал — должен был аккаунт создать? Но почему тогда он слетел? Телефон я не менял, приложение не переустанавливал. Жму логин — 1Password — нет аккаунта.
Ну ладно, нет так нет, может раньше не требовался? Жму создать, заполняю блядскую форму на восемьнадцать полей, придумываю, конечно, пароль, ввожу два раза, и емейл, конечно, тоже два раза. И конечно, посудомоечной машине нужно знать где я живу и какой у меня телефон, чтобы полоскать мои чашки. ВСЮ ФОРМУ ДО КОНЦА ЗАПОЛНЯЮ! Все с телефона, то есть максимально неудобно, в квадратике 2 на 2 сантиметра. Жму: создавай.
Создала, говорит. Иди в емейл. Иду в емейл. А там — есть такой аккаунт уже. Попробуй залогиниться, лузер. И все, даже ссылки обратно, сука, нет. А СРАЗУ НЕЛЬЗЯ СКАЗАТЬ БЫЛО???
Иду логиниться. Пароля, конечно, взять неоткуда. Жму восстановить. Иди опять в почту. Иду в почту. Вот ваш временный пароль. О, думаю, зашибись. Его-то и оставлю. Ввожу емейл и копирую пароль. Зашибись, говорит! Но пароль-то временный. Давай новый придумывай. Ну ё-маё, ну что опять началось...
Ладно, придумываю. Соглашается. Пускает. Добавляю, наконец, машину в апп. Безболезненно достаточно, кстати — потому что Я ОДИН РАЗ ЭТО УЖЕ ДЕЛАЛ КУДА ОНА ПОДЕВАЛАСЬ? А? А?
Зашибись, думаю. Теперь-то запущу чистку. Нахожу режим в приложении. Подношу палец к кнопке. ЗАПУСК ИЗ ПРИЛОЖЕНИЯ ЗАПРЕЩЕН. ИДИ ПАСИСЬ.
(Ну или если хочешь можешь еще час в ютубе гуглить, как remote start разрешить, но у меня уже сил не было, честно).
Короче, я просто спалил, какая иконка у режима чистки в приложении.
А потом подошел к машинке ногами И НАЖАЛ ТОЧНО ТАКУЮ ЖЕ КНОПКУ. Просто подошел и просто нажал. Все. Одно действие. НИКАКИХ, БЛЯДЬ, ЛОГИНОВ. ПОЧЕМУ В ТЕЛЕФОНЕ НЕЛЬЗЯ ТАКЖЕ???
Вы удивляетесь, почему «умный дом» никто так не любит? Ну вот поэтому.
Ну и про проблему логинов и того, что их пихают везде, где нужно и где не нужно.
Во-первых, идите со своими логинами нахуй.
Во-вторых, идите-идите, я не шутил.
Во-третьих, если уж вас укушенный маркетологом менеджер заставил их делать, как насчет того, чтобы эти логины не терять? В идеале я хочу вводить логин один раз в жизни. Ну может один раз за время жизни компьютера. КАК ЛОГИН МОЖЕТ ПОТЕРЯТЬСЯ???
В-четвертых, одного поля «email» достаточно ДЛЯ ВСЕГО. Просто email — письмо со ссылкой — нажал — ты внутри. Логин, регистрация, восстановление — все одинаково. В вашей форме БУКВАЛЬНО не должно быть НИ ОДНО поля, кроме email. БУКВАЛЬНО.
В-пятых, на тему логинов обязательно посмотрите «Jonathan Blow tries Razer BlackWidow TE Chroma v2 keyboard» на Ютубе. Руководство к действию.
В-шестых, идите нахуй.
Нанять классных программистов — не проблема. Они сами к тебе бегут, на самом деле. Говорю из опыта.
Вот предложить им что-то интересное, чтобы побежали — вот это проблема.
Так что в следующий раз, когда у вас будут проблемы с наймом, задумайтесь: а тем ли вы в жизни занимаетесь? Хотели бы вы сами у себя работать? А то, может, потому и не бегут.
Вот предложить им что-то интересное, чтобы побежали — вот это проблема.
Так что в следующий раз, когда у вас будут проблемы с наймом, задумайтесь: а тем ли вы в жизни занимаетесь? Хотели бы вы сами у себя работать? А то, может, потому и не бегут.
Если к программам относиться слишком серьезно, можно заподозрить себя в шизофрении. Потому что программы сплошь и рядом говорят одно, а делают другое.
Например, сейчас вот нажал pull в Идее, а она пошла и переформатировала какие-то свои iml файлы, а потом говорит: не могу пуллиться, У ТЕБЯ изменения. Хотя изменения, конечно, не у меня.
Или на грампи был недавно пример: комп перезагрузился, репортер предлагает репортить об ошибке, а собиратель ничего не собрал. В итоге репортить нечего, что делать юзеру — неясно. И зачем было его беспокоить тоже.
Или одна часть системы говорит: сегодня ночью поставлю апдейты! А вторая не ставит их уже неделю, потому что... не знаю почему! Что-то где-то пошло не так, видимо.
Говорят, при Стиве Джобсе было хорошо: программисты делали, что они обычно делали, а он потом приходил, запускал программу ЛИЧНО и на весь бред пальцем показывал: вы че, ребят, ну так нельзя же.
А Билл Гейтс, говорят, как-то раз не смог Паинт с сайта своей же компании скачать, так там было все запутано. Но исправлять не стал, пригрустил просто.
Такая вот разница между Эпплом и Майкрософтом. Была. Сейчас-то они сравнялись, конечно: Эппл отстал, Майки подтянулись. Только вот нормальному человеку идти стало совсем некуда.
Например, сейчас вот нажал pull в Идее, а она пошла и переформатировала какие-то свои iml файлы, а потом говорит: не могу пуллиться, У ТЕБЯ изменения. Хотя изменения, конечно, не у меня.
Или на грампи был недавно пример: комп перезагрузился, репортер предлагает репортить об ошибке, а собиратель ничего не собрал. В итоге репортить нечего, что делать юзеру — неясно. И зачем было его беспокоить тоже.
Или одна часть системы говорит: сегодня ночью поставлю апдейты! А вторая не ставит их уже неделю, потому что... не знаю почему! Что-то где-то пошло не так, видимо.
Говорят, при Стиве Джобсе было хорошо: программисты делали, что они обычно делали, а он потом приходил, запускал программу ЛИЧНО и на весь бред пальцем показывал: вы че, ребят, ну так нельзя же.
А Билл Гейтс, говорят, как-то раз не смог Паинт с сайта своей же компании скачать, так там было все запутано. Но исправлять не стал, пригрустил просто.
Такая вот разница между Эпплом и Майкрософтом. Была. Сейчас-то они сравнялись, конечно: Эппл отстал, Майки подтянулись. Только вот нормальному человеку идти стало совсем некуда.
👍2
Окей, рил толк. Сегодня я вас научу главному правилу хорошего кода, про которое никто не говорит и про которое знают только принципал инженеры. Вот оно:
«Названия переменных и функций должны содержать ровно одно слово.»
Не два, не три, не полтора. Без сокращений (сокращения — отстой), но и без растекания мыслью по вээскоду.
Вот, например, типичный код из публичного собеседования с канала Хекслет:
Все классно, к алгоритму вопросов нет, классов не наплодили, что тут улучшишь?
Опытные программисты заметят сразу: глаз вязнет, потому что в каждой переменной по два слова! Очень неудобно читать, потому что вроде бы сущность одна, название ты ее прочитал и морально уже готов посмотреть, что там с ней делать будут, а тут на тебе: читай еще одно слово. Неудобненько.
А вот действительно звенящий идеал кода:
Чувствуете, как полегчало, да? Как будто из болота на шоссе выехали и свежим ветерком подуло. Так что будете в следующий раз программировать — задумайтесь. И друзьям расскажите.
«Названия переменных и функций должны содержать ровно одно слово.»
Не два, не три, не полтора. Без сокращений (сокращения — отстой), но и без растекания мыслью по вээскоду.
Вот, например, типичный код из публичного собеседования с канала Хекслет:
export const get = (keySequence, nestedObject) => {
const keyArr = keySequence.split('.');
let tempObj = nestedObject;
for (let i = 0; tempObj && i < keyArr.length; i++)
tempObj = tempObj[keyArr[i]];
return tempObj;
};
Все классно, к алгоритму вопросов нет, классов не наплодили, что тут улучшишь?
Опытные программисты заметят сразу: глаз вязнет, потому что в каждой переменной по два слова! Очень неудобно читать, потому что вроде бы сущность одна, название ты ее прочитал и морально уже готов посмотреть, что там с ней делать будут, а тут на тебе: читай еще одно слово. Неудобненько.
А вот действительно звенящий идеал кода:
export const get = (path, obj) => {
const keys = path.split('.');
let temp = obj;
for (let i = 0; temp && i < keys.length; i++)
temp = temp[keys[i]];
return temp;
};
Чувствуете, как полегчало, да? Как будто из болота на шоссе выехали и свежим ветерком подуло. Так что будете в следующий раз программировать — задумайтесь. И друзьям расскажите.
👎3🤔2👍1
Вот что я решительно не перевариваю — это needy программы. То есть такие, которые не работают на тебя, а которые ты должен обслуживать.
Возьмем Idea как пример (просто потому что под рукой). Создание файла. Казалось бы — простейшая операция, что может быть тривиальнее? Ну так вот, если нажать Cmd+Shift+N в Idea, она... не создаст новый файл! Она начнет допекать тебя вопросами: а как назвать? А какой тип? А какая версия? А в файле будет класс лежать или интерфейс? И только продравшись через все эти дебри, ты получишь наконец возможность что-то написать. Хотя к этому моменту, наверное, уже и забыл, что.
Но она ведь помогает? Не. Это не помощь. Точнее, помощь, конечно, но предложенная неудобно и не вовремя. Такая, что заколебет больше, чем сохранит сил.
При работе с программой может быть два режима: а) ты отдаешь команды — программа действует, или б) программа что-то от тебя хочет. Первый — абсолютный кайф, позволяет поймать поток и чувствовать себя творцом-демиургом, полностью подчинившим себе инструмент.
Второй — полная противоположность, беспомощный «помощник», который сам ничего не может и дергает тебя по пустякам. В сущности ты, вместо того, чтобы решать свои проблемы и воплощать свои замыслы, переключаешься на нужды программы и делаешь то, что ей в данный момент зачем-то нужно. Ей, а не тебе.
Но ведь это обязательные параметры? Как без них? Да легко! Я нажал «создать файл» — вот тебе пустой файл. Не нравится формат? Нажму и поменяю. Имя неправильное? Переименую. Разница в том, что это происходит, когда мне это нужно, когда у меня возникает эта проблема. У меня, а не у программы.
Другой яркий пример такого абьюзивного поведения: нотификации. Самое страшное, что произошло с ИДЕ, с момента изобретения ИДЕ. Нотификации — это проблемы программы, которые она считает нужным сделать моими проблемами. Часто нотификации даже близко не имеют отношения к тому, что я делаю. Плагин, например, обновился. Или сломалось что-то внутри. Или «псс, парень, не хочешь подсветку синтаксиса поискать»? Ну блин, если бы хотел, я бы пошел и поискал, епта. Или «смотри, смотри, я поняла кажется что тут написано, вот тебе пяток иконок по этому поводу!»
Еще один — настройка проекта. «Сначала все настрой, потом я начну работать» это программный эквивалет вотерфолла, методология, которая, как известно, никогда толком не работала. Я не хочу ничего настраивать кроме того, что мне прямо сейчас нужно, я хочу работать, а не обслуживанием софта заниматься.
Ну и апдейты, конечно. Ну вот любят программисты в момент обновления переделать/передумать/переизобрести какие-то внутренности, а потом гордо мне сообщить, что теперь у меня формат конфига неправильный, или нужно файлы какие-то закоммитить, или просто что больше ничего работать не будет. Но я-то тут причем, зачем вы меня этим мучаете?
Короче, программы, не спрашивайте у пользователя ничего. Дайте ему команды и возможность их дергать. Когда ему понадобится (ему, а не вам!), он придет и сам вас позовет. А до тех пор, ради бога, оставьте его в покое. И не блокируйте работу.
Возьмем Idea как пример (просто потому что под рукой). Создание файла. Казалось бы — простейшая операция, что может быть тривиальнее? Ну так вот, если нажать Cmd+Shift+N в Idea, она... не создаст новый файл! Она начнет допекать тебя вопросами: а как назвать? А какой тип? А какая версия? А в файле будет класс лежать или интерфейс? И только продравшись через все эти дебри, ты получишь наконец возможность что-то написать. Хотя к этому моменту, наверное, уже и забыл, что.
Но она ведь помогает? Не. Это не помощь. Точнее, помощь, конечно, но предложенная неудобно и не вовремя. Такая, что заколебет больше, чем сохранит сил.
При работе с программой может быть два режима: а) ты отдаешь команды — программа действует, или б) программа что-то от тебя хочет. Первый — абсолютный кайф, позволяет поймать поток и чувствовать себя творцом-демиургом, полностью подчинившим себе инструмент.
Второй — полная противоположность, беспомощный «помощник», который сам ничего не может и дергает тебя по пустякам. В сущности ты, вместо того, чтобы решать свои проблемы и воплощать свои замыслы, переключаешься на нужды программы и делаешь то, что ей в данный момент зачем-то нужно. Ей, а не тебе.
Но ведь это обязательные параметры? Как без них? Да легко! Я нажал «создать файл» — вот тебе пустой файл. Не нравится формат? Нажму и поменяю. Имя неправильное? Переименую. Разница в том, что это происходит, когда мне это нужно, когда у меня возникает эта проблема. У меня, а не у программы.
Другой яркий пример такого абьюзивного поведения: нотификации. Самое страшное, что произошло с ИДЕ, с момента изобретения ИДЕ. Нотификации — это проблемы программы, которые она считает нужным сделать моими проблемами. Часто нотификации даже близко не имеют отношения к тому, что я делаю. Плагин, например, обновился. Или сломалось что-то внутри. Или «псс, парень, не хочешь подсветку синтаксиса поискать»? Ну блин, если бы хотел, я бы пошел и поискал, епта. Или «смотри, смотри, я поняла кажется что тут написано, вот тебе пяток иконок по этому поводу!»
Еще один — настройка проекта. «Сначала все настрой, потом я начну работать» это программный эквивалет вотерфолла, методология, которая, как известно, никогда толком не работала. Я не хочу ничего настраивать кроме того, что мне прямо сейчас нужно, я хочу работать, а не обслуживанием софта заниматься.
Ну и апдейты, конечно. Ну вот любят программисты в момент обновления переделать/передумать/переизобрести какие-то внутренности, а потом гордо мне сообщить, что теперь у меня формат конфига неправильный, или нужно файлы какие-то закоммитить, или просто что больше ничего работать не будет. Но я-то тут причем, зачем вы меня этим мучаете?
Короче, программы, не спрашивайте у пользователя ничего. Дайте ему команды и возможность их дергать. Когда ему понадобится (ему, а не вам!), он придет и сам вас позовет. А до тех пор, ради бога, оставьте его в покое. И не блокируйте работу.
👍1🍌1
Какой программист не мечтает написать свой блог-движок? Я тоже неспеша в эту сторону думаю, потому что у меня типа есть блог. Но только я не хочу никуда дергаться, пока не пойму не только как сделать «не хуже», а как сделать именно существенно лучше. Пока мысли такие:
Блог в первую очередь про формат. В Телеграм, например, пишется легко и свободно в основном потому, что тут минимум оформления и максимум содержания. Шрифт не выберешь, заголовки не расставишь, картинку не приложишь. Этот аскетизм помогает и писателю (не отвлекаешься от мысли — некуда), и читателю: не надо привыкать к очередному дизайну перед поглощением информации, у всех всё одинаковое.
В Грампи у нас был такой же принцип: одна картинка и минимум текста, без заголовков, категорий, тегов, комментов, вообще без ничего. Я готов объявить эксперимент успешным: за три года писать в него так и не стало обузой. Да, иногда хочется добавить еще одну картинку, или сослаться куда-то, или процитировать, но знаете что? Чем дальше, тем больше ценишь, что возможности ограничены.
Вторая важная вещь для блога — коммьюнити. В Телеграме с этим вышло очень удачно: комменты зашли просто идеально. Я списываю этот успех на простоту комментирования: ты уже залогинен, отправлять сообщения уже умеешь, как будет выглядеть представляешь по прошлому опыту, интерфейс вылизанный и минималистичный. В каком-то смысле канал в Телеграме это не блог, это коммьюнити. Но главное — это весело! Примерно как ранний ЖЖ.
Тут, конечно, возникает вопрос: а как такие вайбы перенести в веб, в персональный блог? Непонятно. Заставлять создавать акк, чтобы комментить — порог великоват. У Бирмана, например, в канале десятки комментариев, а в блоге — единицы. То есть buzzkill примерно десятикратный. Встраивать Disqus? Он очень страшный. Сделать нормальный Disqus? Ну а кто им будет пользоваться? Выносить обсуждение на HN/Reddit/Twitter? Пока самый реальный вариант: да, там есть жизнь, но она как-то отдельно как будто. Плюс HN еще туда-сюда, а вот в Reddit и Twitter сложные ветвистые обсуждения вести мучительно.
Третья мысль — hosted или self-hosted? Хостинг «у дяди» я люблю за простоту, конечно. Но также и не люблю за, понятно, «а что если закроется», а также «а что если я вот такое хочу, а его нет», ну и за «плати нологи^W денюжку».
Хостинг у себя я не люблю тоже, потому что, как я уже говорил, я хочу писать, а не администрировать виртуалки. Даже с one-click deploy (какой-нибудь, допустим, докер) это как будто сложновато звучит, да? Ну и возможностей кастомизации как будто нет, а гемор с виртуалками есть.
Ну а если не one-click, а собирать из исходников, то вот ты его докрутишь под себя, а как потом обновляться? Дизайн я тоже, как правило, хочу свой, а придумать такую платформу, на которую можно было бы спокойно натягивать дизайны (по-настоящему разные, с разными функционально блоками, лайаутами, страницами, не просто темы, короче), не переделывая вообще всего — та еще задача.
Короче, ситуация патовая, я это понимаю, но все равно люблю перебирать в голове эти три варианта, прислушиваться, что из этого действительно кажется важным, а с чем можно смириться. Ну и сталкиваю мысленно друг с другом в попытка придумать какой-то фьюжн.
Последняя проблема, над которой я пассивно ломаю голову (знаю, утомил, потерпите еще чуть-чуть) это как сделать дизайн интересным. На самом деле, когда я слышу «standalone blog», у меня уже непроизвольно скулы сводит от скуки. А если там еще и «черный текст на белом фоне», то просто пиши пропало, они же все одинаковые, как под копирку. Куда самовыражение вставлять?
Но и придумать что-то лучше черного текста на белом фоне сложновато, будем честны. Поэтому вопросик подвешен. И не надо мне писать про желтый фон моего сайта, это не то решение, которое я на самом деле предлагаю. Оно есть, но по другим причинам, и я тоже не до конца с ним счастлив.
Короче, ничего не знаю, предложить нечего, делитесь своими мыслями, спасибо что прочитали!
Блог в первую очередь про формат. В Телеграм, например, пишется легко и свободно в основном потому, что тут минимум оформления и максимум содержания. Шрифт не выберешь, заголовки не расставишь, картинку не приложишь. Этот аскетизм помогает и писателю (не отвлекаешься от мысли — некуда), и читателю: не надо привыкать к очередному дизайну перед поглощением информации, у всех всё одинаковое.
В Грампи у нас был такой же принцип: одна картинка и минимум текста, без заголовков, категорий, тегов, комментов, вообще без ничего. Я готов объявить эксперимент успешным: за три года писать в него так и не стало обузой. Да, иногда хочется добавить еще одну картинку, или сослаться куда-то, или процитировать, но знаете что? Чем дальше, тем больше ценишь, что возможности ограничены.
Вторая важная вещь для блога — коммьюнити. В Телеграме с этим вышло очень удачно: комменты зашли просто идеально. Я списываю этот успех на простоту комментирования: ты уже залогинен, отправлять сообщения уже умеешь, как будет выглядеть представляешь по прошлому опыту, интерфейс вылизанный и минималистичный. В каком-то смысле канал в Телеграме это не блог, это коммьюнити. Но главное — это весело! Примерно как ранний ЖЖ.
Тут, конечно, возникает вопрос: а как такие вайбы перенести в веб, в персональный блог? Непонятно. Заставлять создавать акк, чтобы комментить — порог великоват. У Бирмана, например, в канале десятки комментариев, а в блоге — единицы. То есть buzzkill примерно десятикратный. Встраивать Disqus? Он очень страшный. Сделать нормальный Disqus? Ну а кто им будет пользоваться? Выносить обсуждение на HN/Reddit/Twitter? Пока самый реальный вариант: да, там есть жизнь, но она как-то отдельно как будто. Плюс HN еще туда-сюда, а вот в Reddit и Twitter сложные ветвистые обсуждения вести мучительно.
Третья мысль — hosted или self-hosted? Хостинг «у дяди» я люблю за простоту, конечно. Но также и не люблю за, понятно, «а что если закроется», а также «а что если я вот такое хочу, а его нет», ну и за «плати нологи^W денюжку».
Хостинг у себя я не люблю тоже, потому что, как я уже говорил, я хочу писать, а не администрировать виртуалки. Даже с one-click deploy (какой-нибудь, допустим, докер) это как будто сложновато звучит, да? Ну и возможностей кастомизации как будто нет, а гемор с виртуалками есть.
Ну а если не one-click, а собирать из исходников, то вот ты его докрутишь под себя, а как потом обновляться? Дизайн я тоже, как правило, хочу свой, а придумать такую платформу, на которую можно было бы спокойно натягивать дизайны (по-настоящему разные, с разными функционально блоками, лайаутами, страницами, не просто темы, короче), не переделывая вообще всего — та еще задача.
Короче, ситуация патовая, я это понимаю, но все равно люблю перебирать в голове эти три варианта, прислушиваться, что из этого действительно кажется важным, а с чем можно смириться. Ну и сталкиваю мысленно друг с другом в попытка придумать какой-то фьюжн.
Последняя проблема, над которой я пассивно ломаю голову (знаю, утомил, потерпите еще чуть-чуть) это как сделать дизайн интересным. На самом деле, когда я слышу «standalone blog», у меня уже непроизвольно скулы сводит от скуки. А если там еще и «черный текст на белом фоне», то просто пиши пропало, они же все одинаковые, как под копирку. Куда самовыражение вставлять?
Но и придумать что-то лучше черного текста на белом фоне сложновато, будем честны. Поэтому вопросик подвешен. И не надо мне писать про желтый фон моего сайта, это не то решение, которое я на самом деле предлагаю. Оно есть, но по другим причинам, и я тоже не до конца с ним счастлив.
Короче, ничего не знаю, предложить нечего, делитесь своими мыслями, спасибо что прочитали!
Реалити чек! У StackOverflow вышел Developer Survey 2021, и я решил собрать тут факты, которые меня больше всего удивили.
Языки:
- JavaScript самый популярный язык (68%)
- Rust и Clojure два самых любимых языка (87% и 81% loved)
- Objective-C – один из самых устрашающих (27% loved), в одной лиге с VBA, Cobol, Groovy, Perl и Assembly
- За Clojure платят в больше всего ($95k), на $15k больше, чем ближайшим конкурентам (F#/Elixir/Erlang/Perl (?)/Ruby, все по $80k). Есть гипотеза, что это потому, что к Clojure приходишь, когда уже набрался опыта и надоела вся эта суета
ОС:
- Мне всегда навскидку казалось, что все разработчкии сидят с макбуками, но это, видимо, мой круг общения. На самом деле 41% на Винде, только 30% на Маке, и еще 25% на Линуксе
БД:
- NoSQL эра прошла, самая популярная NoSQL база — MongoDB — на 28%
- MongoDB хоть и не пользуются, но любят (60%). Это к вопросу о маркетинге и DX
Веб:
- React наконец обогнал jQuery (41% против 34%, еще в прошлом году было 37% против 43%)
- Самый прибыльный веб-фреймворк — RoR ($77k)
Cloud:
- Несмотря на весь шум, Kubernetes пока всего на 20%
Аналитика:
- Оказывается, четверть (!) всех разработчиков сидят на некоей Pandas, про которую я не слышал даже названия (!!). Стареем-с.
IDE:
- VS Code занимает 71%. Микрософту респект — смогли! Главное теперь не превратить то хорошее, что у них есть, в Visual Studio
- Ближайший конкурент VS Code — IntelliJ — всего 30%. Серьезный повод для беспокойства
- Самые богатые программисты сидят в Textmate (?) – $80k
Mobile:
- Developer, mobile получает меньше вообще всех ($41k). Это меньше сисадмина, тестировщика, аналитика, дизайнера, ученого. Странно, мне казалось, мобильщики наоборот, гребут деньги лопатой.
Кидайте вашу зарплату и любимый редактор в комменты, будем строить корреляции!
Языки:
- JavaScript самый популярный язык (68%)
- Rust и Clojure два самых любимых языка (87% и 81% loved)
- Objective-C – один из самых устрашающих (27% loved), в одной лиге с VBA, Cobol, Groovy, Perl и Assembly
- За Clojure платят в больше всего ($95k), на $15k больше, чем ближайшим конкурентам (F#/Elixir/Erlang/Perl (?)/Ruby, все по $80k). Есть гипотеза, что это потому, что к Clojure приходишь, когда уже набрался опыта и надоела вся эта суета
ОС:
- Мне всегда навскидку казалось, что все разработчкии сидят с макбуками, но это, видимо, мой круг общения. На самом деле 41% на Винде, только 30% на Маке, и еще 25% на Линуксе
БД:
- NoSQL эра прошла, самая популярная NoSQL база — MongoDB — на 28%
- MongoDB хоть и не пользуются, но любят (60%). Это к вопросу о маркетинге и DX
Веб:
- React наконец обогнал jQuery (41% против 34%, еще в прошлом году было 37% против 43%)
- Самый прибыльный веб-фреймворк — RoR ($77k)
Cloud:
- Несмотря на весь шум, Kubernetes пока всего на 20%
Аналитика:
- Оказывается, четверть (!) всех разработчиков сидят на некоей Pandas, про которую я не слышал даже названия (!!). Стареем-с.
IDE:
- VS Code занимает 71%. Микрософту респект — смогли! Главное теперь не превратить то хорошее, что у них есть, в Visual Studio
- Ближайший конкурент VS Code — IntelliJ — всего 30%. Серьезный повод для беспокойства
- Самые богатые программисты сидят в Textmate (?) – $80k
Mobile:
- Developer, mobile получает меньше вообще всех ($41k). Это меньше сисадмина, тестировщика, аналитика, дизайнера, ученого. Странно, мне казалось, мобильщики наоборот, гребут деньги лопатой.
Кидайте вашу зарплату и любимый редактор в комменты, будем строить корреляции!
👍2
Сел я, значит, Fira Code попрограммировать. Дай, думаю, соберу — у меня там и скрипты наготове. Работавшие!
Нажимаю, а оно: pip устарел. Это еще скажите спасибо, что у меня pip вообще был установлен. Как я его ставил это отдельная история.
Обновить, говорит? Ну давай. Введите, говорит,
Почему не просто
Обновился. Но все равно ругается. Че там? Да вот, говорит:
Ну идем читать. А там написано:
Спасибо что предупредили, как говорится. А также спасибо за ворнинг, от которого нельзя избавиться, но который ничего от меня не требует. Но, типа, хотя бы не блокер.
Ладно. Пойдем этот ваш Pip использовать. Тут надо сказать, что компиляция шрифтов — то еще сборище костылей и подпорок. Оно работает (если вообще работает) не благодаря, а вопреки. Например, у меня в скрипте сборки ставится шесть (!) разных тулз от разных разработчиков, через разные пакетные менеджеры, просто чтобы собрать один шрифт. А еще там есть такие, например, строки:
Почему именно такие? Да хрен его знает, с другими не работало. Что они делают? Да тоже хрен его знает. Такой вот парадокс — шрифты нужны всем, а тулинг разрабатывается тремя энтузиастами в свободное время.
Ну ладно, жму
Не могу, говорит. Почему? Да вот ttfautohint-py не нашла. Как не нашла-то? Никак не нашла.
Иду гуглить. Нахожу issue, в котором какие-то случайно проходившие мимо люди обсуждают, как они какими-то правдами и неправдами, но умудрялись собрать эту ttfautohint-py для M1. Мейнтейнер, к слову, поскольку эта библиотека на 19 звездочек, в дискуссии участвует исключительно с общими ни к чему не обязывающими комментариями типа «проблема нашей ситуации в том, что...», а никак не патчами.
То есть библиотека с 19 (!) звездочками идет как hard requirement для гуглового gftools, на котором весь Google Fonts ездит. То есть понимаете масштаб «серьезности» и «основательности», да? Еще и названия у них там, типа, Pillow Wheel Builder. Че за подушка? Че за колеса? Детский сад, ей богу.
Самое обидное, что ttfautohint, библиотека очень важная и популярная, у меня прекрасно ставится через brew. А вот питонья обертка — ни в какую.
В общем, я остался без скриптов, а вы — без Fira Code. Я, кстати, не пожаловался, что текущий пайплайн собирает (ну, собирал раньше) шрифт за 50 секунд? ПЯТЬДЕСЯТ, карл! За это время на луну можно слетать на стрекозе и обратно, а не двухмегабайтный файл обработать.
Короче, питоний менеджмент пакетов надо сжечь, тут уже ничего не спасти. Я немножко в шоке, это второй по популярности язык в мире, и настолько помойка.
А после того, как сожжем, переписать все, что касается шрифтов, на Rust. Оно будет собираться из исходников час, промежуточных файлов нагенерит на 50 гигабайт, но главное что никаких, сука, опций. Гугл, выдели миллион-другой, проспонсируй?
Нажимаю, а оно: pip устарел. Это еще скажите спасибо, что у меня pip вообще был установлен. Как я его ставил это отдельная история.
Обновить, говорит? Ну давай. Введите, говорит,
/opt/homebrew/opt/python@3.9/bin/python3.9 -m pip install --upgrade pip
Почему не просто
pip upgrade pip, мы никогда не узнаем, но это уже придирки. И почему upgrade, а не update?Обновился. Но все равно ругается. Че там? Да вот, говорит:
DEPRECATION: Configuring installation scheme with distutils config files is deprecated and will no longer work in the near future. If you are using a Homebrew or Linuxbrew Python, please see discussion at https://github.com/Homebrew/homebrew-core/issues/76621
Ну идем читать. А там написано:
If you have been directed here from a pip warning, you don't need to take any action at this stage. Nothing is currently expected to break until Python 3.12, and a full solution will be implemented well before then.
Спасибо что предупредили, как говорится. А также спасибо за ворнинг, от которого нельзя избавиться, но который ничего от меня не требует. Но, типа, хотя бы не блокер.
Ладно. Пойдем этот ваш Pip использовать. Тут надо сказать, что компиляция шрифтов — то еще сборище костылей и подпорок. Оно работает (если вообще работает) не благодаря, а вопреки. Например, у меня в скрипте сборки ставится шесть (!) разных тулз от разных разработчиков, через разные пакетные менеджеры, просто чтобы собрать один шрифт. А еще там есть такие, например, строки:
pip install -U Pillow==5.4.1 idna==2.8 requests==2.21.0 urllib3==1.24.1
export PKG_CONFIG_PATH="/usr/local/opt/libffi/lib/pkgconfig"
Почему именно такие? Да хрен его знает, с другими не работало. Что они делают? Да тоже хрен его знает. Такой вот парадокс — шрифты нужны всем, а тулинг разрабатывается тремя энтузиастами в свободное время.
Ну ладно, жму
pip install git+https://github.com/googlefonts/gftools
Не могу, говорит. Почему? Да вот ttfautohint-py не нашла. Как не нашла-то? Никак не нашла.
Иду гуглить. Нахожу issue, в котором какие-то случайно проходившие мимо люди обсуждают, как они какими-то правдами и неправдами, но умудрялись собрать эту ttfautohint-py для M1. Мейнтейнер, к слову, поскольку эта библиотека на 19 звездочек, в дискуссии участвует исключительно с общими ни к чему не обязывающими комментариями типа «проблема нашей ситуации в том, что...», а никак не патчами.
То есть библиотека с 19 (!) звездочками идет как hard requirement для гуглового gftools, на котором весь Google Fonts ездит. То есть понимаете масштаб «серьезности» и «основательности», да? Еще и названия у них там, типа, Pillow Wheel Builder. Че за подушка? Че за колеса? Детский сад, ей богу.
Самое обидное, что ttfautohint, библиотека очень важная и популярная, у меня прекрасно ставится через brew. А вот питонья обертка — ни в какую.
В общем, я остался без скриптов, а вы — без Fira Code. Я, кстати, не пожаловался, что текущий пайплайн собирает (ну, собирал раньше) шрифт за 50 секунд? ПЯТЬДЕСЯТ, карл! За это время на луну можно слетать на стрекозе и обратно, а не двухмегабайтный файл обработать.
Короче, питоний менеджмент пакетов надо сжечь, тут уже ничего не спасти. Я немножко в шоке, это второй по популярности язык в мире, и настолько помойка.
А после того, как сожжем, переписать все, что касается шрифтов, на Rust. Оно будет собираться из исходников час, промежуточных файлов нагенерит на 50 гигабайт, но главное что никаких, сука, опций. Гугл, выдели миллион-другой, проспонсируй?
🔥4👍1
Продолжение: поставил Докер. Докер, понятно, тоже в arm64 все собирает, то есть хрен мне, а не ttfautohint-py.
Но! Докер можно принудить запускаться на неродной архитектуре.
Обмануть питон и запуститься через Rosetta 2 тоже, увы, не получилось. То есть шелл-то получилось, но питон где-то внутрях выкупает настоящую архитектуру процессора.
Пробуем собрать ttfautohint-py локально. Читаем:
Опять в PIP что-то сломается. К счастью, не сегодня, сегодня пока еще 21.2 😅
Процесс идет, не хватает bison. Это гнушный парсер-генератор из 90-х. Идет аж в составе XCode. Нужен 2.5+, а в XCode только 2.3 2006 года. Работает — не трогай.
К моему счастью, bison нашелся в brew! Вот только zsh его не подхватил. И из
Окей, пишем ТОТ ЖЕ САМЫЙ
Дальше из ниоткуда выскакивает skia-pathops. Нет, говорит, колеса.
Ну, Skia я знаю, тот еще пепелац на двух тыщ сиплюсплюсных исходников (не преувеличение). А че не собирается? А вот:
То есть, внимание, внутри одного питона запустисля другой питон, причем второй, и он «думает», что где-то не там оказался, а наружний питон его «анализирует». «Not functioning». «It thinks». Thinks, блин!!
Решаю помочь ему, починив pip2 заранее. Это тоже нетривиально, потому что sudo python2 -m easy_install pip падает с
То есть Питон 2 нашел версию для Питон 3 и не осилил синтаксис. Тут, ребята, урок, что совместимость должна быть не только обратная, но и прямая, то есть на будущее.
Гуглим последнюю совместимую версию, ставим. Для меня-то оно заработало, а для skia-pathops нет. Видимо, кто-то внутри дергает python или pip без цифры 2, получает третий питон и пиши пропало. Что тоже намекает, как делать миграцию, да? Молча подменять старое новым — путь к страданиям.
Но зато я нахожу опцию
И... это сработало! Я, конечно, получил полный экран депрекейшн ворнингов, но... это сработало!
Запускаем
Вот так вот я провел почти все воскресенье. Приключения в мире людей, которые не стесняются импортировать чужие библиотеки. Как говорится, хочешь сделать что-то хорошо — делай это сам.
И если у вас еще остались иллюзии, что то что мы тут с вами сегодня пишем, другие люди смогут запустить через 50 лет, то ха! Даже через 10 не смогут.
Но! Докер можно принудить запускаться на неродной архитектуре.
--platform linux/amd64. И это сработало! Только шрифт собрался за 18 минут вместо обычных 60 секунд. ВОСЕМЬНАДЦАТЬ! МИНУТ! Карл. Так что спасибо всем, кто советовал, пойду еще посмотрю.Обмануть питон и запуститься через Rosetta 2 тоже, увы, не получилось. То есть шелл-то получилось, но питон где-то внутрях выкупает настоящую архитектуру процессора.
Пробуем собрать ttfautohint-py локально. Читаем:
DEPRECATION: A future pip version will change local packages to be built in-place without first copying to a temporary directory. We recommend you use --use-feature=in-tree-build to test your packages with this new behavior before it becomes the default.
pip 21.3 will remove support for this functionality. You can find discussion regarding this at https://github.com/pypa/pip/issues/7555.
Опять в PIP что-то сломается. К счастью, не сегодня, сегодня пока еще 21.2 😅
Процесс идет, не хватает bison. Это гнушный парсер-генератор из 90-х. Идет аж в составе XCode. Нужен 2.5+, а в XCode только 2.3 2006 года. Работает — не трогай.
К моему счастью, bison нашелся в brew! Вот только zsh его не подхватил. И из
.zshenv не подхватил. Почему? Потому что у zsh есть еще четыре (!) конфига, которые исполняются после .zshenv. И затирают твои настройки, мда.Окей, пишем ТОТ ЖЕ САМЫЙ
$PATH в ~/.zprofile, вроде работает. Ура! ttfautohint-py наконец собран. Поверить не могу. Что дальше?Дальше из ниоткуда выскакивает skia-pathops. Нет, говорит, колеса.
Ну, Skia я знаю, тот еще пепелац на двух тыщ сиплюсплюсных исходников (не преувеличение). А че не собирается? А вот:
New python executable in .../pip-install-64pexhpq/.../build/temp.macosx-11-arm64-3.9/src/cpp/skia-builder/skia/venv2/bin/python
ERROR: The executable .../pip-install-64pexhpq/.../build/temp.macosx-11-arm64-3.9/src/cpp/skia-builder/skia/venv2/bin/python is not functioning
ERROR: It thinks sys.prefix is '.../pip-install-64pexhpq/...' (should be u'...-pathops_b27a67e8ecbc45de8eb5b7954cb8d084/build/temp/...-arm64-3.9/src/cpp/skia-builder/skia/venv2')
ERROR: virtualenv is not compatible with this system or executable
То есть, внимание, внутри одного питона запустисля другой питон, причем второй, и он «думает», что где-то не там оказался, а наружний питон его «анализирует». «Not functioning». «It thinks». Thinks, блин!!
Решаю помочь ему, починив pip2 заранее. Это тоже нетривиально, потому что sudo python2 -m easy_install pip падает с
Best match: pip 21.2.3
...
def read(rel_path: str) -> str:
^
SyntaxError: invalid syntax
То есть Питон 2 нашел версию для Питон 3 и не осилил синтаксис. Тут, ребята, урок, что совместимость должна быть не только обратная, но и прямая, то есть на будущее.
Гуглим последнюю совместимую версию, ставим. Для меня-то оно заработало, а для skia-pathops нет. Видимо, кто-то внутри дергает python или pip без цифры 2, получает третий питон и пиши пропало. Что тоже намекает, как делать миграцию, да? Молча подменять старое новым — путь к страданиям.
Но зато я нахожу опцию
BUILD_SKIA_FROM_SOURCE=0, которая позволяет подложить уже собранную Skia! И, по совершенно невероятному стечению обстоятельств, такая у меня как раз есть! По работе! Собрать ее заняло не один день, вот бы сейчас я встрял.И... это сработало! Я, конечно, получил полный экран депрекейшн ворнингов, но... это сработало!
Запускаем
time ./script/build и... вуаля! Через каких-то 77 секунд (а не 18 минут) получаем свеженькие ttf.Вот так вот я провел почти все воскресенье. Приключения в мире людей, которые не стесняются импортировать чужие библиотеки. Как говорится, хочешь сделать что-то хорошо — делай это сам.
И если у вас еще остались иллюзии, что то что мы тут с вами сегодня пишем, другие люди смогут запустить через 50 лет, то ха! Даже через 10 не смогут.
❤2👍1
После приключений с Питоном я задумался: а как вообще писать код, чтобы его можно было запустить через 50 лет? Только нормально, без геморроя и черной магии.
Во-первых, людям верить нельзя. Это основополагающий принцип. Работает то, что жестко энфорсится машиной, исключения не работают, соглашения не работают. В Java нельзя использовать private или sun.misc, но если очень хочется, то можно — всё, это сразу часть публичного АПИ. Minor версия в SemVer должна быть совместима по АПИ, но если нет, то коллеги застыдят? Всё, единственный вариант — считать каждую минорную версию уникальной и несовместимой. На маленьких масштабах соглашения работают, на 50 лет — уже нет.
Во-вторых, очевидно, нельзя ничего удалять. Leftpad помните? Слава богу, что бэкапы были. В этом смысле гитхаб как репозиторий меня напрягает — да, git почти иммутабельный. Но почти. При желании можно и удалять ветки, и двигать теги, да и вообще репу удалить. Обычно этого не происходит, но это соглашение, а соглашения что? Правильно, не работают.
В-третьих, менять in place тоже нельзя. То есть нельзя пофиксить багу, бампнуть минорную версию и сказать, что она точно такая же. У меня до сих пор холодок от систем, где можно указывать диапазоны зависимостей. Еще очень люблю, когда системные библиотеки подключаются динамически: давайте возьмем libfreetype.so, авось примерно нам подойдет. Так мило и наивно, ми-ми-ми.
Как же исправлять ошибки и развиваться, если менять код нельзя? Очень просто: у КАЖДОЙ версии должен быть свой уникальный неймспейс. Да, даже у минорных. И они должны уметь сосуществовать в рамках одной программы.
В-четвертых, duck typing. Совместимость должна проверяться по форме, а не по названию. OrderV2 должен подходить туда, где подходит OrderV1, пока у него есть тот же набор полей. А иначе пофиксил микробагу и все, изобретай весь мир заново. Не полетит. Позднее динамическое связывание — единственный способ future proof-а.
В-пятых, все входы программы жестко фиксировать. Это я на C/C++ библиотеки смотрю, которые можно собрать с разными define-ами. И если например подключаешь динамическую библиотеку, тебе мало иметь от нее header, надо еще угадать, какие define-ы были включены. Reproducible builds, причем жестко, до последнего байта.
В-шестых, опции в сборке противопоказаны. Идеальный билд/запуск должен работать как «кинул в котел этот файл, этот, этот и оно само разобралось и все сделало». Если хоть что-то сверх этого, хоть малейшая толика свободы, то все, пиши пропало. Разброд и шатания, которые на масштабе в 50 лет похоронят все что можно. Да, это терпимо для одной программы, но совершенно невыносимо, когда тебе надо собрать десять-сто-тысячу.
В-седьмых, вся вообще инфраструктура должна быть декларативной. Потому что семантика. Если в конфиге написано: исходники в папке src, то понятно, на что компилятор натравливать, но также понятно, например, как приделать linter. А если в билде написано «возьми все файлы из src и натрави на них компилятор», то с этим особо ничего больше не сделать, кроме как непосредственно исполнить. Декларатив выживает, потому что с ним можно работать по-разному, а за 50 лет точно захочется.
В-восьмых, жесткая унификация и автоматизация. Человеческое вмешательноство недопустимо ни на какой стадии сборки/запуска, просто потому что оно а) протухает со временем (человек забил/ушел/умер, экспертиза потерялась) и б) не масштабируется.
В-девятых, про версии языка. Тут либо жесткая, брутальная обратная совместимость, либо несколько версий языка должны уметь сосуществовать. ХЗ, можно ли это устроить.
В-десятых, про хранение. Хранить только в исходниках, иначе протухнет. Потому что за 50 лет может и проц новый выйти, и еще что-то. В общем-то, все предыдущие пункты про вот это, как сделать так, чтобы хранение в исходниках работало на серьезных машстабах. Отсюда, кстати, следует полный опен-сорс: бинарники не сработают, обфускация не сработает.
Такие вот мысли. Пойду дальше мечтать.
Во-первых, людям верить нельзя. Это основополагающий принцип. Работает то, что жестко энфорсится машиной, исключения не работают, соглашения не работают. В Java нельзя использовать private или sun.misc, но если очень хочется, то можно — всё, это сразу часть публичного АПИ. Minor версия в SemVer должна быть совместима по АПИ, но если нет, то коллеги застыдят? Всё, единственный вариант — считать каждую минорную версию уникальной и несовместимой. На маленьких масштабах соглашения работают, на 50 лет — уже нет.
Во-вторых, очевидно, нельзя ничего удалять. Leftpad помните? Слава богу, что бэкапы были. В этом смысле гитхаб как репозиторий меня напрягает — да, git почти иммутабельный. Но почти. При желании можно и удалять ветки, и двигать теги, да и вообще репу удалить. Обычно этого не происходит, но это соглашение, а соглашения что? Правильно, не работают.
В-третьих, менять in place тоже нельзя. То есть нельзя пофиксить багу, бампнуть минорную версию и сказать, что она точно такая же. У меня до сих пор холодок от систем, где можно указывать диапазоны зависимостей. Еще очень люблю, когда системные библиотеки подключаются динамически: давайте возьмем libfreetype.so, авось примерно нам подойдет. Так мило и наивно, ми-ми-ми.
Как же исправлять ошибки и развиваться, если менять код нельзя? Очень просто: у КАЖДОЙ версии должен быть свой уникальный неймспейс. Да, даже у минорных. И они должны уметь сосуществовать в рамках одной программы.
В-четвертых, duck typing. Совместимость должна проверяться по форме, а не по названию. OrderV2 должен подходить туда, где подходит OrderV1, пока у него есть тот же набор полей. А иначе пофиксил микробагу и все, изобретай весь мир заново. Не полетит. Позднее динамическое связывание — единственный способ future proof-а.
В-пятых, все входы программы жестко фиксировать. Это я на C/C++ библиотеки смотрю, которые можно собрать с разными define-ами. И если например подключаешь динамическую библиотеку, тебе мало иметь от нее header, надо еще угадать, какие define-ы были включены. Reproducible builds, причем жестко, до последнего байта.
В-шестых, опции в сборке противопоказаны. Идеальный билд/запуск должен работать как «кинул в котел этот файл, этот, этот и оно само разобралось и все сделало». Если хоть что-то сверх этого, хоть малейшая толика свободы, то все, пиши пропало. Разброд и шатания, которые на масштабе в 50 лет похоронят все что можно. Да, это терпимо для одной программы, но совершенно невыносимо, когда тебе надо собрать десять-сто-тысячу.
В-седьмых, вся вообще инфраструктура должна быть декларативной. Потому что семантика. Если в конфиге написано: исходники в папке src, то понятно, на что компилятор натравливать, но также понятно, например, как приделать linter. А если в билде написано «возьми все файлы из src и натрави на них компилятор», то с этим особо ничего больше не сделать, кроме как непосредственно исполнить. Декларатив выживает, потому что с ним можно работать по-разному, а за 50 лет точно захочется.
В-восьмых, жесткая унификация и автоматизация. Человеческое вмешательноство недопустимо ни на какой стадии сборки/запуска, просто потому что оно а) протухает со временем (человек забил/ушел/умер, экспертиза потерялась) и б) не масштабируется.
В-девятых, про версии языка. Тут либо жесткая, брутальная обратная совместимость, либо несколько версий языка должны уметь сосуществовать. ХЗ, можно ли это устроить.
В-десятых, про хранение. Хранить только в исходниках, иначе протухнет. Потому что за 50 лет может и проц новый выйти, и еще что-то. В общем-то, все предыдущие пункты про вот это, как сделать так, чтобы хранение в исходниках работало на серьезных машстабах. Отсюда, кстати, следует полный опен-сорс: бинарники не сработают, обфускация не сработает.
Такие вот мысли. Пойду дальше мечтать.
👍3
Когда я учился в универе на программиста, лет так 20 назад, у нас был курс ООП. И вот препод читает нам лекцию, что бывает инкапсуляция, полиморфизм, и тут натыкается на какой-то термин, название которого существовало на тот момент только на английском. И произносит такую фразу: «Как это по-русски называть я не знаю, область новая, русский словарь еще не устоялся, __надо будет им как-нибудь заняться__».
И тут у меня мир перевернулся немножечко. Ну то есть процесс обучения so far был такой, что есть некий корпус знаний, а лекторы его нам пересказывают. Типа, мы изучаем статичный мир.
А тут лектор—обычный такой программист, практикующий, своя айти фирма, живет рядом с нами, бесконечно крутой для нас тогда, но тем не менее в пределах достижимого: обедает в тех же столовых, учился когда-то в том же универе, ну может лет на 10 нас старше.
И он, получается, в том числе лично создает тот самый мир, в который нам предстоит влиться. И мир-то не статичный, а меняется прямо сейчас, пока мы скучаем на лекциях.
И эта разница в мировоззрениях преследует меня до сих пор, особенно в дискуссиях в интернете. Одни видят мир программирования как что-то статичное: вот нам дан Ruby on Rails, например, он такой, какой есть, его можно изучать, его можно (и нужно) использовать, и это в общем-то все. Рассуждения про то, чего там не хватает, или как надо было бы правильно его устроить, в рамках такой модели кажутся беспочвенными, примерно как рассуждать, что было бы, если бы не было налогов или существовал магнитный монополь. В лучшем случае можно обсуждать, какие еще библиотеки уже существуют и можно взять прямо сейчас. На месте RoR мог бы оказаться кто угодно, конечно: Нода, или C++, или Хаскель, или даже Win API.
Другой способ смотреть на мир в том, что он создается точно такими же программистами, как и мы, постоянно, прямо сейчас. И он действительно создается, ничего еще не решено, ничего не устаканилось, все меняется, все под вопросом. Есть люди, которые пишут новые библиотеки, есть люди, которые пишут новые фреймворки, новые игровые движки, новые базы данных, новые языки, да даже операционки. Они же не с неба на нас упали. И это ВСЕ в пределах достижимого, и ВЕЗДЕ есть потенциал для улучшения. Лично для меня это самая интересная часть профессии: двигать статус кво дальше, находить проблемы и потенциал для улучшения. По возможности на практике, но чаще даже просто на словах.
А проблема, собственно, что людям из этих двух категорий, как правило, сложно друг друга понять. «Некогда думать, делать надо», «зачем обсуждать то, чего нет» с одной стороны; и «все плохо, никто не умеет программировать, как же так получается, индустрия в жопе» с другой.
Ну, в общем, это моя наивная попытка чуть улучшить ситуацию, объяснив, что происходит. Ну и немножко сформировать ожидания, чтобы было понятно, что мы тут обсуждаем и почему именно так. Продолжайте мечтать!
И тут у меня мир перевернулся немножечко. Ну то есть процесс обучения so far был такой, что есть некий корпус знаний, а лекторы его нам пересказывают. Типа, мы изучаем статичный мир.
А тут лектор—обычный такой программист, практикующий, своя айти фирма, живет рядом с нами, бесконечно крутой для нас тогда, но тем не менее в пределах достижимого: обедает в тех же столовых, учился когда-то в том же универе, ну может лет на 10 нас старше.
И он, получается, в том числе лично создает тот самый мир, в который нам предстоит влиться. И мир-то не статичный, а меняется прямо сейчас, пока мы скучаем на лекциях.
И эта разница в мировоззрениях преследует меня до сих пор, особенно в дискуссиях в интернете. Одни видят мир программирования как что-то статичное: вот нам дан Ruby on Rails, например, он такой, какой есть, его можно изучать, его можно (и нужно) использовать, и это в общем-то все. Рассуждения про то, чего там не хватает, или как надо было бы правильно его устроить, в рамках такой модели кажутся беспочвенными, примерно как рассуждать, что было бы, если бы не было налогов или существовал магнитный монополь. В лучшем случае можно обсуждать, какие еще библиотеки уже существуют и можно взять прямо сейчас. На месте RoR мог бы оказаться кто угодно, конечно: Нода, или C++, или Хаскель, или даже Win API.
Другой способ смотреть на мир в том, что он создается точно такими же программистами, как и мы, постоянно, прямо сейчас. И он действительно создается, ничего еще не решено, ничего не устаканилось, все меняется, все под вопросом. Есть люди, которые пишут новые библиотеки, есть люди, которые пишут новые фреймворки, новые игровые движки, новые базы данных, новые языки, да даже операционки. Они же не с неба на нас упали. И это ВСЕ в пределах достижимого, и ВЕЗДЕ есть потенциал для улучшения. Лично для меня это самая интересная часть профессии: двигать статус кво дальше, находить проблемы и потенциал для улучшения. По возможности на практике, но чаще даже просто на словах.
А проблема, собственно, что людям из этих двух категорий, как правило, сложно друг друга понять. «Некогда думать, делать надо», «зачем обсуждать то, чего нет» с одной стороны; и «все плохо, никто не умеет программировать, как же так получается, индустрия в жопе» с другой.
Ну, в общем, это моя наивная попытка чуть улучшить ситуацию, объяснив, что происходит. Ну и немножко сформировать ожидания, чтобы было понятно, что мы тут обсуждаем и почему именно так. Продолжайте мечтать!
👍1
Главное правило дизайна хорошего API — правда. Мир как-то устроен, и хорошее АПИ не прячет это устройство, не пытается его сгладить, а представляет как есть.
Если не знаете, как сделать АПИ, задайтесь вопросом: а что на самом деле происходит? Не «как сделать удобнее?», а именно «что происходит?». И вокруг этого уже стройте. Это может быть некрасиво/нелогично/неудобно, но зато с этим можно работать.
Например, событие KeyDown. Что произошло в физическом мире? Кто-то нажал на кнопку на клавиатуре. Все, больше ничего не произошло. Значит в событии должна лежать кто? Кнопка.
Однако чего туда только не кладут: например, юникод текст, который этой кнопке соответствует. Маппинг кнопок в символы конечно важная задача, но все-таки не связанная 1 на 1 с нажатием на кнопки (есть кнопки, которые ничего не вводят, как и текст можно ввести, не нажимая на кнопки).
Или, например, какие-то кнопки приходят, а какие-то не приходят, или приходят не всегда, а третьи вообще виртуальные и приходят, когда никто ничего не нажимал.
Короче, хорошее АПИ репортило бы только одну вещь: какая кнопка и когда была нажата. Не пыталось бы помочь, скрыть, обработать или как-то иначе запутать ситуацию. Но только по-правде, когда кто-то реально нажал настоящую кнопку. И всегда, без исключения.
Почему? Да потому что с сырой правдой можно работать так, как тебе нужно, а вот с «умным» АПИ приходится сначала распутывать его логику, «нормализовывать», а потом уже делать свою поверх. Это сложно, это трудно сделать до конца (никогда не знаешь, какие еще «особенности» там могут быть), это бессмысленно. Не надо так.
У кого правда, тот и сильней.
Если не знаете, как сделать АПИ, задайтесь вопросом: а что на самом деле происходит? Не «как сделать удобнее?», а именно «что происходит?». И вокруг этого уже стройте. Это может быть некрасиво/нелогично/неудобно, но зато с этим можно работать.
Например, событие KeyDown. Что произошло в физическом мире? Кто-то нажал на кнопку на клавиатуре. Все, больше ничего не произошло. Значит в событии должна лежать кто? Кнопка.
Однако чего туда только не кладут: например, юникод текст, который этой кнопке соответствует. Маппинг кнопок в символы конечно важная задача, но все-таки не связанная 1 на 1 с нажатием на кнопки (есть кнопки, которые ничего не вводят, как и текст можно ввести, не нажимая на кнопки).
Или, например, какие-то кнопки приходят, а какие-то не приходят, или приходят не всегда, а третьи вообще виртуальные и приходят, когда никто ничего не нажимал.
Короче, хорошее АПИ репортило бы только одну вещь: какая кнопка и когда была нажата. Не пыталось бы помочь, скрыть, обработать или как-то иначе запутать ситуацию. Но только по-правде, когда кто-то реально нажал настоящую кнопку. И всегда, без исключения.
Почему? Да потому что с сырой правдой можно работать так, как тебе нужно, а вот с «умным» АПИ приходится сначала распутывать его логику, «нормализовывать», а потом уже делать свою поверх. Это сложно, это трудно сделать до конца (никогда не знаешь, какие еще «особенности» там могут быть), это бессмысленно. Не надо так.
У кого правда, тот и сильней.
❤3
Функция макОСа «переключать раскладку по Caps Lock» (системная, между прочим) раскладку, конечно, переключает, но иногда (1 раз на 25) включает настоящий Caps Lock. С лампочкой, с БОЛЬШИМИ БУКВАМИ, все как мы любим.
Я пытался из этого вывести какую-то мораль и понял, что в этом баге сошлось буквально все, что не так с компьютерами. Тут и про отношение к макОСу в Эппле (задвинут на задворки), и про уровень тестирования, и про сложность современной разработки, и про состояние рынка, на котором продукт такого качества успешно существует, и про то, что американцы до сих пор по-настоящему не поверили, что остальному миру правда нужно переключать языки, и про инертность в раскладках клавиатур, тянущуюся прямиком от пишущих машинок.
Самое смешное, что у них есть и другая возможность переключить языки — по кнопке Fn. Казалось бы, та же самая функция, НО: включается совсем в другом месте (серьезно), работает по-другому и показывает идиотский попап по центру экрана на полторы секунды. ПОЛТОРЫ, карл. Наверное, в представлении создателей переключение раскладки это такой редкий и такой специальный юз-кейс, что о нем нужно КАК СЛЕДУЕТ уведомить пользователя. Ну а если у вас мышка где-то в районе попапа стояла, то попап не работает: реагирует на мышку вместо выбора следующей раскладки. Нет, я не шучу блин.
А, ну и самый топчик: если очень быстро набирать текст и переключать раскладки, раскладка может НЕ УСПЕТЬ переключиться. То есть абв-капс-xyz превращается во что-то типа абв-капс-чнz. Рейс не на уровне наносекунд и тактов, а на уровне скорости печати человека. Как можно так программировать, скажите пожалуйста?
Не, я не спорю, макОС хорошая система, но как только обычные люди ей пользуются? Пойду доставать Hammerspoon, чтобы сделать нормально.
Я пытался из этого вывести какую-то мораль и понял, что в этом баге сошлось буквально все, что не так с компьютерами. Тут и про отношение к макОСу в Эппле (задвинут на задворки), и про уровень тестирования, и про сложность современной разработки, и про состояние рынка, на котором продукт такого качества успешно существует, и про то, что американцы до сих пор по-настоящему не поверили, что остальному миру правда нужно переключать языки, и про инертность в раскладках клавиатур, тянущуюся прямиком от пишущих машинок.
Самое смешное, что у них есть и другая возможность переключить языки — по кнопке Fn. Казалось бы, та же самая функция, НО: включается совсем в другом месте (серьезно), работает по-другому и показывает идиотский попап по центру экрана на полторы секунды. ПОЛТОРЫ, карл. Наверное, в представлении создателей переключение раскладки это такой редкий и такой специальный юз-кейс, что о нем нужно КАК СЛЕДУЕТ уведомить пользователя. Ну а если у вас мышка где-то в районе попапа стояла, то попап не работает: реагирует на мышку вместо выбора следующей раскладки. Нет, я не шучу блин.
А, ну и самый топчик: если очень быстро набирать текст и переключать раскладки, раскладка может НЕ УСПЕТЬ переключиться. То есть абв-капс-xyz превращается во что-то типа абв-капс-чнz. Рейс не на уровне наносекунд и тактов, а на уровне скорости печати человека. Как можно так программировать, скажите пожалуйста?
Не, я не спорю, макОС хорошая система, но как только обычные люди ей пользуются? Пойду доставать Hammerspoon, чтобы сделать нормально.
👍3
У Куросавы в «Семи самураях» есть момент, где какой-то дерзкий самурай залупался на более опытных и уговорил одного на дуель на деревянных мечах. И даже ее выиграл. Опытный не очень расстроился — че ты радуешься, говорит, ты выиграл только потому, что мы на деревянных мечах дрались, в настоящей драке я бы тебя зарубил. Не, говорит дерзкий, не верю, я круче. Ну давай, говорит, на настоящих. И зарубил дерзкого нахуй.
Это я к чему? Ходил я тут на собеседование, и меня завернули, потому что я код недостаточно абстрагировал и на модули мало поделил. А там кода — три функции, каждая на полэкрана. Нафига их делить? Типа, в настоящей системе такое бы не прошло. А я думаю, что давайте тогда вашу настоящую систему, посмотрим, как у вас там все красиво по модулям разложено и функции на две строчки, и где и как часто у вас программисты кукуху лечат. С деревянным мечом мы все горазды понты кидать. Давайте по-настоящему?
Это я к чему? Ходил я тут на собеседование, и меня завернули, потому что я код недостаточно абстрагировал и на модули мало поделил. А там кода — три функции, каждая на полэкрана. Нафига их делить? Типа, в настоящей системе такое бы не прошло. А я думаю, что давайте тогда вашу настоящую систему, посмотрим, как у вас там все красиво по модулям разложено и функции на две строчки, и где и как часто у вас программисты кукуху лечат. С деревянным мечом мы все горазды понты кидать. Давайте по-настоящему?
👍1