Никто не знает будущее.
Я уже писал про это по-отдельности, но тут сформулировал в виде бюрошного принципа, который легко запомнить.
В общем, никто не знает будущее. Офигеть откровение, да? Но почему-то я постоянно сталкиваюсь с примерами, где будущее почему-то совершенно конкретными способами влияет на их решения и они не видят в этом ничего странного.
Например, выложил на Грампи скриншот какого-то стандартного мастера установки, который спрашивает: установить для всех пользователей комьпютера или только для меня. Меня этот вопрос всегда выбивал из колеи: кто эти другие пользователи, они с нами сейчас в одной комнате? Я тут вообще-то один сижу. Почему меня заставляют принять это решение, если оно а) не необходимо и б) оба варианта приводят к абсолютно идентичному результату?
Так вот, возражение было такое: а что если пользователь сейчас один, а завтра появится второй? Вот тогда-то разница и проявится.
Звучит логично? Нет! Я не знаю, вы не знаете, никто не знает, когда и при каких обстоятельствах появится второй пользователь. То, что вы переложили это решение на меня, не значит, что я могу его как-то лучше принять. Нет, я тоже не знаю будущего.
Другой пример услышал буквально на днях в подкасте. Чувак рассказывал про язык Roc и как они делали управление зависимостями. И вот он говорит: сначала мы сделали version ranges. Что-то типа: моя библиотека требует зависимость json версии начиная с 1.2.0 и до, допустим, 2.0.0 не включительно. И дальше он буквально своим же ртом говорит: «да, 2.0.0 еще не вышла, но мы предполагаем, что там будут какие-то серьезные изменения, а до 1.99.99 все изменения будут менее серьезные, и хотя они тоже еще не вышли, давайте делать вид, что мы сможем с ними работать».
Звучит как булшит, да? Что это за «предполагаем»? Никто этого не знает! Никто этого не гарантирует! И не может, даже в теории. Так почему мы должны принимать это решение сейчас, когда _по определению_ мы не можем его принять???
(К счастью, ребята из Roc одумались и сделали нормальное версионирование, без диапазонов. Но вроде есть языки, которые диапазоны умеют?)
Ну и третье это программирование на будущее. Интерфейсы с одной реализацией (а вдруг потом понадобится вторая?). Геттеры, которые просто возвращают значение поля (а вдруг потом захотим логику добавить?). Использование ОРМ, потому что «а вдруг мы захотим поменять базу?». Интересно, что этим любят заниматься именно джависты, у которых при этом «лучший инструментарий для работы с кодом в мире» и любое из этих изменений в теории должно делаться тривиальным нажатием кнопки в ИДЕ.
Так зачем делать это сейчас, когда ты не знаешь, появится вторая реализация или логика в геттере, если ты можешь это сделать когда они действительно понадобятся, и с той позиции скорее всего сделаешь это лучше? Зачем гадать сейчас и рисковать не угадать, если можно вообще ничего не делать и принять решение тогда, когда информации будет достаточно?
Потому что люди почему-то думают, что могут предсказывать будущее.
А они не могут. Такие дела.
Я уже писал про это по-отдельности, но тут сформулировал в виде бюрошного принципа, который легко запомнить.
В общем, никто не знает будущее. Офигеть откровение, да? Но почему-то я постоянно сталкиваюсь с примерами, где будущее почему-то совершенно конкретными способами влияет на их решения и они не видят в этом ничего странного.
Например, выложил на Грампи скриншот какого-то стандартного мастера установки, который спрашивает: установить для всех пользователей комьпютера или только для меня. Меня этот вопрос всегда выбивал из колеи: кто эти другие пользователи, они с нами сейчас в одной комнате? Я тут вообще-то один сижу. Почему меня заставляют принять это решение, если оно а) не необходимо и б) оба варианта приводят к абсолютно идентичному результату?
Так вот, возражение было такое: а что если пользователь сейчас один, а завтра появится второй? Вот тогда-то разница и проявится.
Звучит логично? Нет! Я не знаю, вы не знаете, никто не знает, когда и при каких обстоятельствах появится второй пользователь. То, что вы переложили это решение на меня, не значит, что я могу его как-то лучше принять. Нет, я тоже не знаю будущего.
Другой пример услышал буквально на днях в подкасте. Чувак рассказывал про язык Roc и как они делали управление зависимостями. И вот он говорит: сначала мы сделали version ranges. Что-то типа: моя библиотека требует зависимость json версии начиная с 1.2.0 и до, допустим, 2.0.0 не включительно. И дальше он буквально своим же ртом говорит: «да, 2.0.0 еще не вышла, но мы предполагаем, что там будут какие-то серьезные изменения, а до 1.99.99 все изменения будут менее серьезные, и хотя они тоже еще не вышли, давайте делать вид, что мы сможем с ними работать».
Звучит как булшит, да? Что это за «предполагаем»? Никто этого не знает! Никто этого не гарантирует! И не может, даже в теории. Так почему мы должны принимать это решение сейчас, когда _по определению_ мы не можем его принять???
(К счастью, ребята из Roc одумались и сделали нормальное версионирование, без диапазонов. Но вроде есть языки, которые диапазоны умеют?)
Ну и третье это программирование на будущее. Интерфейсы с одной реализацией (а вдруг потом понадобится вторая?). Геттеры, которые просто возвращают значение поля (а вдруг потом захотим логику добавить?). Использование ОРМ, потому что «а вдруг мы захотим поменять базу?». Интересно, что этим любят заниматься именно джависты, у которых при этом «лучший инструментарий для работы с кодом в мире» и любое из этих изменений в теории должно делаться тривиальным нажатием кнопки в ИДЕ.
Так зачем делать это сейчас, когда ты не знаешь, появится вторая реализация или логика в геттере, если ты можешь это сделать когда они действительно понадобятся, и с той позиции скорее всего сделаешь это лучше? Зачем гадать сейчас и рисковать не угадать, если можно вообще ничего не делать и принять решение тогда, когда информации будет достаточно?
Потому что люди почему-то думают, что могут предсказывать будущее.
А они не могут. Такие дела.
👍223🤡36👎17🤔12❤10💯5👏2💩2❤🔥1🦄1
Давайте расскажу про модерацию.
Канал постоянно спамят. Чтобы это побороть, я написал бота. Бот очень тупой: он сидит и смотрит кто что пишет.
Если человек пишет свое самое первое сообщение в канале и в нем есть картинка или ссылка — удаляется только это сообщение, к человеку никаких мер, может постить дальше.
Как только человек написал хотя бы один текстовый коммент, он попадает в белый список и дальше может постить все что угодно.
Этих простых мер достаточно, чтобы отсечь 99% процентов спама.
Все это коммуницируется через временные сообщения с меншном, т.е. если ты совершил ошибку, тебе об этом скажут и объяснят, что делать.
Второй критерий подозрительного сообщения — микс латиницы с кириллицей. Причем надо до четырех раз в одном слове, т.е. всякие dockerконтейнер не стриггерят, надо прям WЖSФ хотя бы. На это нормальные люди не должны попадаться вообще.
Баны раздаются только вручную и только когда человек переходит на личные оскорбления, меня или других комментаторов. Мнения можно высказывать свободно.
В оооооочень редких случаях бывают баны за неконструктив, но это надо неделями его постить в огромных количествах.
Happy shitposting!
Канал постоянно спамят. Чтобы это побороть, я написал бота. Бот очень тупой: он сидит и смотрит кто что пишет.
Если человек пишет свое самое первое сообщение в канале и в нем есть картинка или ссылка — удаляется только это сообщение, к человеку никаких мер, может постить дальше.
Как только человек написал хотя бы один текстовый коммент, он попадает в белый список и дальше может постить все что угодно.
Этих простых мер достаточно, чтобы отсечь 99% процентов спама.
Все это коммуницируется через временные сообщения с меншном, т.е. если ты совершил ошибку, тебе об этом скажут и объяснят, что делать.
Второй критерий подозрительного сообщения — микс латиницы с кириллицей. Причем надо до четырех раз в одном слове, т.е. всякие dockerконтейнер не стриггерят, надо прям WЖSФ хотя бы. На это нормальные люди не должны попадаться вообще.
Баны раздаются только вручную и только когда человек переходит на личные оскорбления, меня или других комментаторов. Мнения можно высказывать свободно.
В оооооочень редких случаях бывают баны за неконструктив, но это надо неделями его постить в огромных количествах.
Happy shitposting!
❤175👍75🔥20💩6🤓2🎅2😁1🤔1🤯1🖕1👀1
Кстати, еще один выпуск подкаста вышел, с пылу с жару
Search → Канал Ильи Бирмана → Думаем дальше № 3 — «Ощущается как ненастоящие ёлочные игрушки» с Никитой Прокоповым
Про то, как американцы не могут больше полететь на Луну, а Эплы — делать нормальные интерфейсы. Рассказываю немножко про Huumble UI!
Search → Канал Ильи Бирмана → Думаем дальше № 3 — «Ощущается как ненастоящие ёлочные игрушки» с Никитой Прокоповым
Про то, как американцы не могут больше полететь на Луну, а Эплы — делать нормальные интерфейсы. Рассказываю немножко про Huumble UI!
🤡63🔥30👍10🤬7👎3🥱3❤🔥2👏1😁1😐1🗿1
Тут же анонсировали Hey Calendar, рекомендую сходить посмотреть видео — оно сделано ровно так, как я недавно рассказывал: чувак открывает свое приложение и 20 минут тыкает во все подряд. Без всяких слайдов.
Они придумали там много прикольных фич, довольно толковых, но на что я обратил внимание, так это что некоторые из них технически можно было сделать и в текущих календарях. Но никто не делал.
Например, maybe события. То есть когда что-то запланировано, но еще не подтверждено. Формально можно просто еще один календарь завести, на практике же удобно, когда создатели заранее об этом подумали и тебе не надо это изобретать самому.
То же самое с хайлатами — события, более важные, чем другие — это мог бы быть отдельный календарь, а стала специальная фича. Даже названия дней формально можно было бы делать как all-day event, но это противоестественно как-то.
Так что вот, сделать гибкую ортогональную систему это еще полдела. Второая половина это придумать, как этим пользоваться на самом деле, и научить этому пользователя.
Я, например, вдохновился их почтой и сделал себе что-то похожее в Fastmail (папки Inbox/Feed/Paper Trail). Мог ли я это сделать раньше? Конечно мог. Но сделал, только когда увидел у них.
Ну а про то что Календарь надо бы по-хорошему с туду-листом объединить я уже давно говорю.
Они придумали там много прикольных фич, довольно толковых, но на что я обратил внимание, так это что некоторые из них технически можно было сделать и в текущих календарях. Но никто не делал.
Например, maybe события. То есть когда что-то запланировано, но еще не подтверждено. Формально можно просто еще один календарь завести, на практике же удобно, когда создатели заранее об этом подумали и тебе не надо это изобретать самому.
То же самое с хайлатами — события, более важные, чем другие — это мог бы быть отдельный календарь, а стала специальная фича. Даже названия дней формально можно было бы делать как all-day event, но это противоестественно как-то.
Так что вот, сделать гибкую ортогональную систему это еще полдела. Второая половина это придумать, как этим пользоваться на самом деле, и научить этому пользователя.
Я, например, вдохновился их почтой и сделал себе что-то похожее в Fastmail (папки Inbox/Feed/Paper Trail). Мог ли я это сделать раньше? Конечно мог. Но сделал, только когда увидел у них.
Ну а про то что Календарь надо бы по-хорошему с туду-листом объединить я уже давно говорю.
👍100❤19🤔10🥱6❤🔥1😁1😭1
Запостил тут ссылку на Awesome Cold Showers Хиллеля Вейна. Типа, какие есть хайповые поверья и что на самом деле говорят исследования. Да, про статическую типизацию в том числе. Почитайте, она короткая и хорошая.
Есть там и «разоблачение» формальной верификации. В реплаи к твиту пришел чел со словами «но ведь эти разоблачения сводятся к „баги были только в неверифицированной части“, какие могут быть вопросы?».
На что я могу сказать, что он, конечно, по-своему прав. Есть такой анекдот:
Летят чуваки на воздушном шаре. Потерялись. Пролетают мужика.
— Мужик, где мы находимся?
— Вы находитесь на воздушном шаре!
— О, математик! Абсолютно точный и абсолютно бесполезный ответ.
Конечно, если вы верифицировали часть системы, вы можете гарантировать отсутствие багов только в верифицированной части.
Проблема в том, что людям не нужна «верифицированная часть». Им нужно приложение, все, целиком, от начала и до конца. И тот факт, что вы не смогли верифицировать какие-то части и в них нашли баги снимает с вас ответственность перед коллегами-академиками, но никак не перед пользователями.
Или можно так сформулировать: если вы сделали систему, которая верифицирует _что-то_, имеет значение не только то, что она верифицирует хорошо, но и _что именно_ она верифицирует. Иначе это опять ключи под фонарем искать.
Grow up already.
Есть там и «разоблачение» формальной верификации. В реплаи к твиту пришел чел со словами «но ведь эти разоблачения сводятся к „баги были только в неверифицированной части“, какие могут быть вопросы?».
На что я могу сказать, что он, конечно, по-своему прав. Есть такой анекдот:
Летят чуваки на воздушном шаре. Потерялись. Пролетают мужика.
— Мужик, где мы находимся?
— Вы находитесь на воздушном шаре!
— О, математик! Абсолютно точный и абсолютно бесполезный ответ.
Конечно, если вы верифицировали часть системы, вы можете гарантировать отсутствие багов только в верифицированной части.
Проблема в том, что людям не нужна «верифицированная часть». Им нужно приложение, все, целиком, от начала и до конца. И тот факт, что вы не смогли верифицировать какие-то части и в них нашли баги снимает с вас ответственность перед коллегами-академиками, но никак не перед пользователями.
Или можно так сформулировать: если вы сделали систему, которая верифицирует _что-то_, имеет значение не только то, что она верифицирует хорошо, но и _что именно_ она верифицирует. Иначе это опять ключи под фонарем искать.
Grow up already.
🤡116👍33❤26👎7🥱4🤔3😁1💩1
Ладно, внезапно ситуация, в которой без ссылки не обойдешься. Впервые на этом канале.
Я тут написал черновик поста. Он философско-провокационный, поэтому нужен фидбек. Много фидбека.
Ну а поскольку это черновик, то придется дать прямую ссылку, других способов нет.
Почитайте, плиз, напишите, что думаете?
Ссылка:
http://localhost:8080/drafts/2024-01-05.html
Я тут написал черновик поста. Он философско-провокационный, поэтому нужен фидбек. Много фидбека.
Ну а поскольку это черновик, то придется дать прямую ссылку, других способов нет.
Почитайте, плиз, напишите, что думаете?
Ссылка:
http://localhost:8080/drafts/2024-01-05.html
🤡397😁110💊26🖕12🥴11💩9💯6🗿5🔥3👍1🆒1
Есть такая традиция — писать в футере сайта текущий год. Типа, © 2024.
Символ © это, понятно, оберег от юристов и нейросетей. Когда нейросети видят его, они сразу перестают на контенте этого сайта обучаться, а юристы разбегаются в ужасе. Но в остальном это маленький и безобидный карго-культик, даже лень его дальше высмеивать.
Так вот, год.
Начнем с самой очевидной гипотезы — год в футере нужен, чтобы посетитель узнал, какой сейчас год. Теоретически может пригодится какому-нибудь залетному путешественнику во времени, но вообще это довольно ненадежный источник, и календарь справится с этой задачей лучше. В крайнем случае можно попробовать газету купить.
Вторая гипотеза — год показывает дату последнего обновления сайта. Ну допустим. Только, опять же, скорее всего ненадежно — он либо меняется где-то в совсем другом месте, чем собственно публикуется контент, либо просто забит динамически и всегда показывает текущий год, т.е. выполняет первую функцию, обслуживает путешественников во времени и людей, вышедших из многолетней комы.
Но давайте предположим, что год таки реализован правильно, т.е. действительно показывает, когда последний раз обновлялся сайт. Какой у этого потенциально может быть юз-кейс? Посетитель может узнать, что автор сайта жив. Вот, пожалуй, и все. Зачем ему это информация? Что он будет с ней делать?
Например, у меня есть проблема, я гуглю решение, перехожу на сайт, читаю статью, дохожу до конца, а там в футере 2022, и я такой — блин, ну и нафига я это читал, автор-то похоже умер. И тут же закрываю сайт и все забываю. Так что ли? Или как? Объясните.
Может показаться, что год как-то отражает релевантность контента, что конечно неправда. Год обычно делается один для всего сайта, а у отдельных статей есть свои точные даты. Так что это аргумент летит в ведро.
Иногда пишут диапазон, 2020–2024, и в этом хоть какой-то смысл есть — можно узнать год основания. Не супер-важно, но хотя бы любопытный факт, потому что годы основания у разных сайтов РАЗНЫЕ. А текущий год везде один, и он, блин, написан на каждом сайте зачем-то.
Ну так что, зачем вы пишете год в футере? Обновили на 2024 уже?
Символ © это, понятно, оберег от юристов и нейросетей. Когда нейросети видят его, они сразу перестают на контенте этого сайта обучаться, а юристы разбегаются в ужасе. Но в остальном это маленький и безобидный карго-культик, даже лень его дальше высмеивать.
Так вот, год.
Начнем с самой очевидной гипотезы — год в футере нужен, чтобы посетитель узнал, какой сейчас год. Теоретически может пригодится какому-нибудь залетному путешественнику во времени, но вообще это довольно ненадежный источник, и календарь справится с этой задачей лучше. В крайнем случае можно попробовать газету купить.
Вторая гипотеза — год показывает дату последнего обновления сайта. Ну допустим. Только, опять же, скорее всего ненадежно — он либо меняется где-то в совсем другом месте, чем собственно публикуется контент, либо просто забит динамически и всегда показывает текущий год, т.е. выполняет первую функцию, обслуживает путешественников во времени и людей, вышедших из многолетней комы.
Но давайте предположим, что год таки реализован правильно, т.е. действительно показывает, когда последний раз обновлялся сайт. Какой у этого потенциально может быть юз-кейс? Посетитель может узнать, что автор сайта жив. Вот, пожалуй, и все. Зачем ему это информация? Что он будет с ней делать?
Например, у меня есть проблема, я гуглю решение, перехожу на сайт, читаю статью, дохожу до конца, а там в футере 2022, и я такой — блин, ну и нафига я это читал, автор-то похоже умер. И тут же закрываю сайт и все забываю. Так что ли? Или как? Объясните.
Может показаться, что год как-то отражает релевантность контента, что конечно неправда. Год обычно делается один для всего сайта, а у отдельных статей есть свои точные даты. Так что это аргумент летит в ведро.
Иногда пишут диапазон, 2020–2024, и в этом хоть какой-то смысл есть — можно узнать год основания. Не супер-важно, но хотя бы любопытный факт, потому что годы основания у разных сайтов РАЗНЫЕ. А текущий год везде один, и он, блин, написан на каждом сайте зачем-то.
Ну так что, зачем вы пишете год в футере? Обновили на 2024 уже?
👏99🤡49👍43😁10❤6🌭4⚡1
Вот допустим у вас в интерфейсе есть кнопка. Пользователь наводит на нее указатель типа мышь. Надо ли менять курсор со стрелки на руку Микки Мауса (как у ссылок)?
Люди, которые ничего кроме веба в своей жизни не видели, хором отвечают: да. Еще и цвет поменяй, и побольше сделать, и теней прибавь. Ну, чтобы было совсем уж очевидно, что она нажимается.
Однако если мы обратим свое внимание на весь остальной компьютинг, то внезапно станет понятно, что никто кроме веба-то так и не делает. Все операционные системы начиная с Windows 3.11 и до сегодняшних macOS Sonoma/Win 11 не делают ничего специально, когда ты пролетаешь над кнопкой.
Потому что — шумит же. Может ты и не собирался ничего нажимать, а просто пролетал мимо. Зачем мне посреди пути вдруг менять курсор, отвлекаться на него?
Те же люди из браузера скажут: но чел, как же тогда понять, что кнопка нажимается???
И опять обратимся к истории. 30 лет люди как-то понимали это без курсора и hover state, а теперь вдруг резко потеряли такую способность? А на мобиле как, как люди определяют, что нажимается? Там курсора вообще нет.
Ответ прост: внешний вид. Кнопка и так уже выглядит как кнопка. Нафига ей еще какая-то дополнительная индикация? У вас есть глаза? Есть. Прямоугольник можете найти? Можете. Ну вот, вы достаточно квалифицированы, чтобы находить кнопки без смены курсора.
Но что если кнопка выглядит как хуй знает что, только не кнопка? Это тоже чисто вебовское изобретение, кстати. Мем с велосипедистом, который вставляет палку сам себе в колесо. Сделал хуевую кнопку — нужен hover state — пользователи не могут ее найти. Я предпочту визуально понятную кнопку без курсора визуально непонятной кнопке с курсором в ста случаев из ста. Hover state — это не разрешение делать кнопки, которые приходится искать.
И еще раз, на всякий случай, если захотите возразить. 30 лет. 30 гребаных лет. Все интерфейсы вообще, кроме сайтов. Без курсора. И все живы. Это не теория даже, это практика, 30 лет практики. Статус кво практически — не подсвечивать кнопки и не менять курсор. Факты.
А у вас какие аргументы?
Люди, которые ничего кроме веба в своей жизни не видели, хором отвечают: да. Еще и цвет поменяй, и побольше сделать, и теней прибавь. Ну, чтобы было совсем уж очевидно, что она нажимается.
Однако если мы обратим свое внимание на весь остальной компьютинг, то внезапно станет понятно, что никто кроме веба-то так и не делает. Все операционные системы начиная с Windows 3.11 и до сегодняшних macOS Sonoma/Win 11 не делают ничего специально, когда ты пролетаешь над кнопкой.
Потому что — шумит же. Может ты и не собирался ничего нажимать, а просто пролетал мимо. Зачем мне посреди пути вдруг менять курсор, отвлекаться на него?
Те же люди из браузера скажут: но чел, как же тогда понять, что кнопка нажимается???
И опять обратимся к истории. 30 лет люди как-то понимали это без курсора и hover state, а теперь вдруг резко потеряли такую способность? А на мобиле как, как люди определяют, что нажимается? Там курсора вообще нет.
Ответ прост: внешний вид. Кнопка и так уже выглядит как кнопка. Нафига ей еще какая-то дополнительная индикация? У вас есть глаза? Есть. Прямоугольник можете найти? Можете. Ну вот, вы достаточно квалифицированы, чтобы находить кнопки без смены курсора.
Но что если кнопка выглядит как хуй знает что, только не кнопка? Это тоже чисто вебовское изобретение, кстати. Мем с велосипедистом, который вставляет палку сам себе в колесо. Сделал хуевую кнопку — нужен hover state — пользователи не могут ее найти. Я предпочту визуально понятную кнопку без курсора визуально непонятной кнопке с курсором в ста случаев из ста. Hover state — это не разрешение делать кнопки, которые приходится искать.
И еще раз, на всякий случай, если захотите возразить. 30 лет. 30 гребаных лет. Все интерфейсы вообще, кроме сайтов. Без курсора. И все живы. Это не теория даже, это практика, 30 лет практики. Статус кво практически — не подсвечивать кнопки и не менять курсор. Факты.
А у вас какие аргументы?
👍219👎30🤡24❤23🤔12💯11🔥8😁4🤣2💅2❤🔥1
Для разнообразия история с хэппи-эндом. Понадобилось мне срочно ответить мемом, который я нарисовал сколько-то лет назад. Мем я помню, а файла давно нет.
Что делать? Исходники я, конечно, не храню. Зато я постил его в твиттер.
К счастью, в папке Backups у меня лежит архив всех моих твитов за три года (Почему только за три? Потому что ебучий Элон Маск, три года поноса ему шлю). Они все в одной здоровенной json-ине, чтобы тебе было удобно искать, и картинки рядом в отдельной папке.
Полазил я по ним, потыкал в рандомные места — нет нужного мема. Картинок там, чтобы вы осознавали масштаб, 9999 (натурально, я сам сначала подумал, что Finder сломался, но нет, так совпало, реально 9999).
Расстроился. Запил.
А потом пришла в голову гениальная идея — а что если поискать по тексту на картике? Ну а что, Эпл же позволяет текст с картинок выделять теперь. Может он и индексирует его тоже?
И да. Все нашлось моментально. И я ничего для этого не делал. Даже по-русски ищет, прикиньте?
Настоящий Эпл момент. Я снова люблю компьютеры (это чувство продержалось минут 20).
Что делать? Исходники я, конечно, не храню. Зато я постил его в твиттер.
К счастью, в папке Backups у меня лежит архив всех моих твитов за три года (Почему только за три? Потому что ебучий Элон Маск, три года поноса ему шлю). Они все в одной здоровенной json-ине, чтобы тебе было удобно искать, и картинки рядом в отдельной папке.
Полазил я по ним, потыкал в рандомные места — нет нужного мема. Картинок там, чтобы вы осознавали масштаб, 9999 (натурально, я сам сначала подумал, что Finder сломался, но нет, так совпало, реально 9999).
Расстроился. Запил.
А потом пришла в голову гениальная идея — а что если поискать по тексту на картике? Ну а что, Эпл же позволяет текст с картинок выделять теперь. Может он и индексирует его тоже?
И да. Все нашлось моментально. И я ничего для этого не делал. Даже по-русски ищет, прикиньте?
Настоящий Эпл момент. Я снова люблю компьютеры (это чувство продержалось минут 20).
❤283😁97👍35🔥20🤡8💊5🦄3🤯2🤮2
Не отвлекайтесь сильно, я просто мимо проходил.
Бесит, что в Телеграме скачать что-то можно только тогда, когда он сам это скачает. Есть например аудиофайл, думаешь: о! скачаю. Нажимаешь правой кнопкой, а там ничего. Зато если включить его послушать и какое-то время подождать, он куда-то там во внутренности телеграма скачается и появится пункт меню «Скачать». Но это уже никакой не «Скачать» получается. И с видосами, и с картинками так же.
Второе, что бесит, это что нет поиска по Cmd + F.
Казалось бы, обе концепции уже сто лет как отработаны примерно везде. Казалось бы. Но нет.
Все, извините, если разбудил. Владимиру WDeath привет.
UPD: Сегодня поиск по Cmd + F работает! А вчера еще не работал. Думаю завести новую рубрику, будет называться «Недетерменированные компьютеры». Тогда вот вам на подумать: Cmd + Shift + F ведет в поле, подписанное как ⌘K, а ⌘K в это поле не ведет
UPD2: У меня Esc переключает между списком чатов и списком контактов. Это наверное самое странное использование Esc, которое я видел
Бесит, что в Телеграме скачать что-то можно только тогда, когда он сам это скачает. Есть например аудиофайл, думаешь: о! скачаю. Нажимаешь правой кнопкой, а там ничего. Зато если включить его послушать и какое-то время подождать, он куда-то там во внутренности телеграма скачается и появится пункт меню «Скачать». Но это уже никакой не «Скачать» получается. И с видосами, и с картинками так же.
Второе, что бесит, это что нет поиска по Cmd + F.
Казалось бы, обе концепции уже сто лет как отработаны примерно везде. Казалось бы. Но нет.
Все, извините, если разбудил. Владимиру WDeath привет.
UPD: Сегодня поиск по Cmd + F работает! А вчера еще не работал. Думаю завести новую рубрику, будет называться «Недетерменированные компьютеры». Тогда вот вам на подумать: Cmd + Shift + F ведет в поле, подписанное как ⌘K, а ⌘K в это поле не ведет
UPD2: У меня Esc переключает между списком чатов и списком контактов. Это наверное самое странное использование Esc, которое я видел
😁61👍33🤔7💊6👎4💯4😐2❤1
Мой любимый момент, где Unix-модель дала трещину:
Типа, команда называется допустим shutdown. Но иногда надо делать перезагрузку. Делать отдельный бинарник странно (потому что код наполовину тот же). Залинковать, видимо, нельзя (команда не знает, через какой линк ее вызвали?). Вот и получается монстр: вроде говоришь выключи, а флагом это поведение отменяешь.
Но это еще можно объяснить. А вот такое уже сложнее:
Тут уже явно можно было отдельный update сделать.
Ну и мое любимое:
UPD из комментов:
UPD2: С пипом еще смешнее, правильный ключ upgrade, но сообщение об этом все равно пишет update:
UPD3: Команды знают, через какой алиас из вызвали. То есть
shutdown --reboot
Типа, команда называется допустим shutdown. Но иногда надо делать перезагрузку. Делать отдельный бинарник странно (потому что код наполовину тот же). Залинковать, видимо, нельзя (команда не знает, через какой линк ее вызвали?). Вот и получается монстр: вроде говоришь выключи, а флагом это поведение отменяешь.
Но это еще можно объяснить. А вот такое уже сложнее:
pip install --update
Тут уже явно можно было отдельный update сделать.
Ну и мое любимое:
apt add-repository --remove
UPD из комментов:
helm upgrade --install
UPD2: С пипом еще смешнее, правильный ключ upgrade, но сообщение об этом все равно пишет update:
[notice] A new release of pip is available: 23.2.1 -> 23.3.2
[notice] To update, run: python3.11 -m pip install --upgrade pip
UPD3: Команды знают, через какой алиас из вызвали. То есть
shutdown —reboot это чисто стилистический выбор😁148🤡51👍9🥱9👎5❤4🔥4🤔3😐3🗿2
Чего я не понимаю, так это концепции лок-файлов.
Смотрите. Я пишу приложение. Хочу взять версии пакетов A 1.0, B 1.1 и C 2.0. Ну окей. У этих пакетов есть транзитивные зависимости. То есть если мы пойдем и скачаем A версии 1.0, у него будет написано: хочу X версии 7.7 и Y версии 8.8. Окей. Это все еще конкретные версии. Можно продолжить транзитивно.
Может получиться, что один пакет встречается несколько раз с разными версиями. Например, кто-то хочет C версии 1.0, а кто-то 2.0. Ну ок, берем какую-то (самую большую, или самую близкую к корню), или еще как-то ДЕТЕРМЕНИРОВАНО.
Теперь внимание. Весь этот алгоритм абсолютно детерменирован. Ни в какой момент времени мы не бросали кости, не зависели от чего-то, что может поменяться (мы считаем, что версию нельзя перезалить, да же?), не полагались на какие-то абсурдные метрики вроде «кто первый скачается» и не выбирали «последнее на данный момент». В любой момент времени, если мы запустим этот алгоритм, в любой точке вселенной, мы всегда получим один и тот же список абсолютно идентичных версий всего транзитивного дерева зависимостей.
А теперь внимание вопрос. Нафига тогда нужны лок-файлы?
UPD. Многие пишут: потому что range. Очевидно. Но нафига нужны ренжи? Смотри, ты написал range версий. Запустил билд. Он обновил лок-файл. В нем написана конкретная версия. В итоге мы пришли к тому же, с чего начинали: версия все равно конкретная, она все равно зафиксирована (не обновляется с выходом новых версий, например), только with extra steps
Смотрите. Я пишу приложение. Хочу взять версии пакетов A 1.0, B 1.1 и C 2.0. Ну окей. У этих пакетов есть транзитивные зависимости. То есть если мы пойдем и скачаем A версии 1.0, у него будет написано: хочу X версии 7.7 и Y версии 8.8. Окей. Это все еще конкретные версии. Можно продолжить транзитивно.
Может получиться, что один пакет встречается несколько раз с разными версиями. Например, кто-то хочет C версии 1.0, а кто-то 2.0. Ну ок, берем какую-то (самую большую, или самую близкую к корню), или еще как-то ДЕТЕРМЕНИРОВАНО.
Теперь внимание. Весь этот алгоритм абсолютно детерменирован. Ни в какой момент времени мы не бросали кости, не зависели от чего-то, что может поменяться (мы считаем, что версию нельзя перезалить, да же?), не полагались на какие-то абсурдные метрики вроде «кто первый скачается» и не выбирали «последнее на данный момент». В любой момент времени, если мы запустим этот алгоритм, в любой точке вселенной, мы всегда получим один и тот же список абсолютно идентичных версий всего транзитивного дерева зависимостей.
А теперь внимание вопрос. Нафига тогда нужны лок-файлы?
UPD. Многие пишут: потому что range. Очевидно. Но нафига нужны ренжи? Смотри, ты написал range версий. Запустил билд. Он обновил лок-файл. В нем написана конкретная версия. В итоге мы пришли к тому же, с чего начинали: версия все равно конкретная, она все равно зафиксирована (не обновляется с выходом новых версий, например), только with extra steps
🤡148👍41👎11💯6❤5💊5💩3🥱2
Пипец, package-lock.json это новые табы против пробелов. 500 комментов насрали, я, кажется, раз пять одно и то же по кругу объяснил, пока не сдался.
Главное, это не теория какая-то, говоришь людям — вот есть Java, есть Go, они именно так и работают, никаких лок-файлов, оба успешные проекты. Не верят! То есть буквально говорят: нет, не может такого быть, не будет это работать.
Я даже теряюсь в таких случаях. По-моему доказательство примером это самое сильное, что вообще может быть. А на тебя смотрят, как будто ты им не кошку обыкновенную показываешь, которых в каждом дворе пяток, а дракона какого-то или единорога.
Говоришь: вот так вот можно все то же самое делать. А тебе — конечно нельзя, или конечно не то же самое. Ведь если я меняю версии в лок-файле, то они качественные, хорошие, звучат хорошо, на новый год радуют, критические уязвимости закрывают. А если ты в своем pom.xml версии меняешь, то это убогие, плохие версии, там обязательно кто-нибудь аргументы в функциях местами переставит, все развалится, сгниет, урожая три года не будет и волосы выпадут. Хотя казалось бы.
Но главное — люди, кажется, во все это верят. И что хеши от злоумышленников защищают. И что ренжи авторы как-то осмысленно пишут. И что на диффы лок-файлов кто-то смотрит. И что билд с лок-файлом надежнее получается, бинарник более крепкий выходит. И что наличие лок-файла помогает апгрейдить версии, и даже лучше соблюдать semver. В смысле серьезно, без иронии, услышали где-то и повторяют, как будто это правда. Если компютеры на чем-то еще и работают, так это на вере, что все так, как оно должно быть.
Удивительная, конечно, индустрия. Другой такой нет. Всех люблю.
Главное, это не теория какая-то, говоришь людям — вот есть Java, есть Go, они именно так и работают, никаких лок-файлов, оба успешные проекты. Не верят! То есть буквально говорят: нет, не может такого быть, не будет это работать.
Я даже теряюсь в таких случаях. По-моему доказательство примером это самое сильное, что вообще может быть. А на тебя смотрят, как будто ты им не кошку обыкновенную показываешь, которых в каждом дворе пяток, а дракона какого-то или единорога.
Говоришь: вот так вот можно все то же самое делать. А тебе — конечно нельзя, или конечно не то же самое. Ведь если я меняю версии в лок-файле, то они качественные, хорошие, звучат хорошо, на новый год радуют, критические уязвимости закрывают. А если ты в своем pom.xml версии меняешь, то это убогие, плохие версии, там обязательно кто-нибудь аргументы в функциях местами переставит, все развалится, сгниет, урожая три года не будет и волосы выпадут. Хотя казалось бы.
Но главное — люди, кажется, во все это верят. И что хеши от злоумышленников защищают. И что ренжи авторы как-то осмысленно пишут. И что на диффы лок-файлов кто-то смотрит. И что билд с лок-файлом надежнее получается, бинарник более крепкий выходит. И что наличие лок-файла помогает апгрейдить версии, и даже лучше соблюдать semver. В смысле серьезно, без иронии, услышали где-то и повторяют, как будто это правда. Если компютеры на чем-то еще и работают, так это на вере, что все так, как оно должно быть.
Удивительная, конечно, индустрия. Другой такой нет. Всех люблю.
❤179🤡65👍40😁38🤣10👎3🥱3💯3🔥2💊1
Мы какое-то время назад зарубались здесь на тему Vim-а, и звучали аргументы, мол, терминальные приложения быстрые.
И вот это заблуждение меня расстраивает. Да, _кажется_, что терминальные приложения быстрее. Но на самом деле никаких объективных причин им быть быстрыми нет.
Интерфейс быстрее рисовать? Ну может маргинально. Дело в том, что то количество текста, которое есть в современном редакторе, шейпится не знаю, за миллисекунду? В худшем случае. Копейки, короче. Всякие градиенты с тенюшками, если что, вообще вашему GPU ничего не стоят. А терминалу еще escape-сиквенсы парсить. Так что я бы сказал что силы равны.
А все остально абсолютно идентично. Оба (условный терминальный редактор и условный графический) исполняют один и тот же код, оба написаны на примерно одном и том же языке, обоим нужно проделать одинаковое количество работы, чтобы получить одинаковый результат. Терминальные редакторы не получают каких-то бонусов от процессора и не исполняются быстрее из-за того, что не инициализируют графику.
То есть когда у вас тормозит какое-то графическое приложение, то это не потому что оно графическое, а потому что его авторы не смогли. Или не захотели. Или оно стало настолько популярным, что в него понапихали всего чего можно и все несчатны.
В общем, терминальные приложение не быстрее графических. На каждый Vim и Emacs у нас есть 10x и Sublime Text.
Почему же тогда _кажется_, что терминальные приложения быстрее?
Да потому что у вас нет больших тормозящих приложений. И опять же, не потому что они там невозможны, а просто потому, что не нашлось сумасшедших, чтобы их сделать. Хотя, скажем, какой-нибудь пайплайн сборки современного фронтенда вполне себе тормозит, в худших традициях кнопок Rebuild из каких-нибудь Visual Studio или Idea.
И вот это заблуждение меня расстраивает. Да, _кажется_, что терминальные приложения быстрее. Но на самом деле никаких объективных причин им быть быстрыми нет.
Интерфейс быстрее рисовать? Ну может маргинально. Дело в том, что то количество текста, которое есть в современном редакторе, шейпится не знаю, за миллисекунду? В худшем случае. Копейки, короче. Всякие градиенты с тенюшками, если что, вообще вашему GPU ничего не стоят. А терминалу еще escape-сиквенсы парсить. Так что я бы сказал что силы равны.
А все остально абсолютно идентично. Оба (условный терминальный редактор и условный графический) исполняют один и тот же код, оба написаны на примерно одном и том же языке, обоим нужно проделать одинаковое количество работы, чтобы получить одинаковый результат. Терминальные редакторы не получают каких-то бонусов от процессора и не исполняются быстрее из-за того, что не инициализируют графику.
То есть когда у вас тормозит какое-то графическое приложение, то это не потому что оно графическое, а потому что его авторы не смогли. Или не захотели. Или оно стало настолько популярным, что в него понапихали всего чего можно и все несчатны.
В общем, терминальные приложение не быстрее графических. На каждый Vim и Emacs у нас есть 10x и Sublime Text.
Почему же тогда _кажется_, что терминальные приложения быстрее?
Да потому что у вас нет больших тормозящих приложений. И опять же, не потому что они там невозможны, а просто потому, что не нашлось сумасшедших, чтобы их сделать. Хотя, скажем, какой-нибудь пайплайн сборки современного фронтенда вполне себе тормозит, в худших традициях кнопок Rebuild из каких-нибудь Visual Studio или Idea.
👍102🤡20👾14🤔5🔥4💯4👨💻3❤2👎2🥴2
По моему микроблогу может показаться, что я периодически жалуюсь на всякие штуки, и значит они со мной периодически происходят. Но не очень ясен масштаб. А масштаб такой: ~два десятка косяков в день.
Чтобы не быть голословным, я периодически записываю их. Вот список за один (!) никак специально не выбранный день:
Preview:
- Вместо проматывания страницы скролл переключает на следующую
- Там же, скролл в конце страницы перелистывает на конец следующей (а не начало)
Apple Notes:
- Показал Welcome screen
- Автокорректор заменяет слова на похожие
- Не удаляются маркеры списка
- Показал белый экран после запуска
- Курсор может уйти за границы окна
Software Update:
- Окошко пароля не говорит зачем пароль (просто введи, жалко что ли?)
- Вопрос «Когда обновлять» появился через день (!) после ввода пароля для обновления
- Окошко с вопросом «обновить сейчас или ночью» без кнопок
- Обновить ночью традиционно не работает
- Нотификация на System Settings пропала, хотя апдейт не поставился
Apple Photos:
- Кроп рандомно прыгает
- Элементы управления исчезают во время кропа, но не освобождают место
- Экспорт в разные форматы в зависимости от способа перетаскивания
iPhone:
- телефон завис на минуту и не реагировал
- менял громкость и повернул телефон и верстку попердолило
- когда кладешь заблокированный (!) телефон в карман, нажимается какая-то кнопка. Например, может включиться следующий подкаст или набраться буква Z или Ф в заметку
Overcast:
- не нашел и не показал подкаст, потому что я раньше уже слушал другие выпуски
- проебал play position
YouTube:
- Пробел стал работать еще реже
- Темная тема не включается, когда меняешь системную
- Кнопка watch later может исчезнуть, если перейти по ссылке внутри Ютуба
- Проебывает позицию воспроизведения (КАК???)
Разное:
- Apple Music открывается сам когда снимаю наушники
- Микрофон в Google Meet начинает шуметь через 10 минут после начала звонка
- Твит отправился со второго раза
- Два скроллбара в твиттере
- Эйртег рандомно забыл кто он и определился как чужой
- Телеграм скопировал только половину выделенного o_O
Еще раз, это не список, который я год собирал. Это один случайный день! Один!
И так каждый день, только косяки все время разные. Да, каждый по-отдельности незначителен, но все вместе они создают некую картину развала и упадка цивилизации, конечно. А вы спрашиваете, чего я такой злой. Да потому что оно все вот такое!
Молодые, наверное, подумают — дед ворчит. Ну а как тут не ворчать? Когда каждая программа практически разваливается под тобой каждый день. Думаете, это нормально? Нет, не нормально! Думаете, лучше нельзя? Да можно, легко! Нужно только хоть чуть-чуть этого хотеть.
Я конечно тут в пустоту кричу, но если хотя бы помогу нормализовать понимание, что так быть не должно, то уже свою задачу выполню.
А дальше сами. Делайте нормально, все в ваших руках.
Чтобы не быть голословным, я периодически записываю их. Вот список за один (!) никак специально не выбранный день:
Preview:
- Вместо проматывания страницы скролл переключает на следующую
- Там же, скролл в конце страницы перелистывает на конец следующей (а не начало)
Apple Notes:
- Показал Welcome screen
- Автокорректор заменяет слова на похожие
- Не удаляются маркеры списка
- Показал белый экран после запуска
- Курсор может уйти за границы окна
Software Update:
- Окошко пароля не говорит зачем пароль (просто введи, жалко что ли?)
- Вопрос «Когда обновлять» появился через день (!) после ввода пароля для обновления
- Окошко с вопросом «обновить сейчас или ночью» без кнопок
- Обновить ночью традиционно не работает
- Нотификация на System Settings пропала, хотя апдейт не поставился
Apple Photos:
- Кроп рандомно прыгает
- Элементы управления исчезают во время кропа, но не освобождают место
- Экспорт в разные форматы в зависимости от способа перетаскивания
iPhone:
- телефон завис на минуту и не реагировал
- менял громкость и повернул телефон и верстку попердолило
- когда кладешь заблокированный (!) телефон в карман, нажимается какая-то кнопка. Например, может включиться следующий подкаст или набраться буква Z или Ф в заметку
Overcast:
- не нашел и не показал подкаст, потому что я раньше уже слушал другие выпуски
- проебал play position
YouTube:
- Пробел стал работать еще реже
- Темная тема не включается, когда меняешь системную
- Кнопка watch later может исчезнуть, если перейти по ссылке внутри Ютуба
- Проебывает позицию воспроизведения (КАК???)
Разное:
- Apple Music открывается сам когда снимаю наушники
- Микрофон в Google Meet начинает шуметь через 10 минут после начала звонка
- Твит отправился со второго раза
- Два скроллбара в твиттере
- Эйртег рандомно забыл кто он и определился как чужой
- Телеграм скопировал только половину выделенного o_O
Еще раз, это не список, который я год собирал. Это один случайный день! Один!
И так каждый день, только косяки все время разные. Да, каждый по-отдельности незначителен, но все вместе они создают некую картину развала и упадка цивилизации, конечно. А вы спрашиваете, чего я такой злой. Да потому что оно все вот такое!
Молодые, наверное, подумают — дед ворчит. Ну а как тут не ворчать? Когда каждая программа практически разваливается под тобой каждый день. Думаете, это нормально? Нет, не нормально! Думаете, лучше нельзя? Да можно, легко! Нужно только хоть чуть-чуть этого хотеть.
Я конечно тут в пустоту кричу, но если хотя бы помогу нормализовать понимание, что так быть не должно, то уже свою задачу выполню.
А дальше сами. Делайте нормально, все в ваших руках.
💯223👍82🤣32🤡23🔥12🗿7🦄5🐳3💩2🎅2🙏1
В комментах запостили картинку, как Айфон, прекрасно работавший с Карплеем несколько месяцев, вдруг в один день ни с того ни с сего перестал подключаться. Ну и показывает окошко, мол, можешь попробовать снова, только САМ.
И тут я подумал: а представляете как круто бы было, если бы в компьютере была такая функция, чтобы одну операцию попробовать несколько раз? Назовем, это, например, ЦИКЛ. И был способ считать попытки, чтобы не зациклиться навечно, скажем, попробовать 10 раз. Назовем это ПЕРЕМЕННАЯ. Ну круто было бы, а? Жалко компьютеры так не умеют :(
Казалось бы, ну блин. Компьютеры _созданы_, чтобы запоминать информацию. Просто это основная их цель. Но при этом они ежедневно умудряются проебывать: куки, сессии, логины, позицию воспроизведения, открытые файлы, позицию скролла, данные из форм, идентификаторы устройств, позиции окон.
У меня был период, когда ноут забывал монитор, к которому я его подключал каждый день, и каждый день как новый: о! Давай-ка я тебе все сброшу, что ты настраивал. Или у меня есть аиртег, который иногда _забывает_, что он мой, и определяется как чужой. Ну вот КАК? Причем речь не о гиганстких количествах информации, в большинстве случаев речь идет о трехзначных цифрах^WW одном-двух числах, десятке байт.
Печально, насколько компьютеры приучили нас к тому, что они могут сломаться просто так, на ровном месте, и ничем кроме фазы луны и плохой кармы это не объяснить.
Вдвойне печально, что они также приучили нас к тому, что они сами с этим сделать ничего не могут. Мне там в комментах отвечали, что мол если телефон начнет пытаться починить коннект, то что-нибудь уже работающее может сломаться.
Казалось бы, с какой стати? Компьютер может вполне две вещи держать в памяти, два коннекшна открытыми, работать в двух потоках. Это давно решенные проблемы, их любой ребенок, изучающий программирование, учится делать на третьем уроке в языке Лого. Однако почему-то, когда речь заходит о «серьезных системах» и «взрослых проблемах», доступные ребенку вещи вдруг становятся невозможными.
Хотя компьютер вроде бы один и тот же.
И тут я подумал: а представляете как круто бы было, если бы в компьютере была такая функция, чтобы одну операцию попробовать несколько раз? Назовем, это, например, ЦИКЛ. И был способ считать попытки, чтобы не зациклиться навечно, скажем, попробовать 10 раз. Назовем это ПЕРЕМЕННАЯ. Ну круто было бы, а? Жалко компьютеры так не умеют :(
Казалось бы, ну блин. Компьютеры _созданы_, чтобы запоминать информацию. Просто это основная их цель. Но при этом они ежедневно умудряются проебывать: куки, сессии, логины, позицию воспроизведения, открытые файлы, позицию скролла, данные из форм, идентификаторы устройств, позиции окон.
У меня был период, когда ноут забывал монитор, к которому я его подключал каждый день, и каждый день как новый: о! Давай-ка я тебе все сброшу, что ты настраивал. Или у меня есть аиртег, который иногда _забывает_, что он мой, и определяется как чужой. Ну вот КАК? Причем речь не о гиганстких количествах информации, в большинстве случаев речь идет о трехзначных цифрах^WW одном-двух числах, десятке байт.
Печально, насколько компьютеры приучили нас к тому, что они могут сломаться просто так, на ровном месте, и ничем кроме фазы луны и плохой кармы это не объяснить.
Вдвойне печально, что они также приучили нас к тому, что они сами с этим сделать ничего не могут. Мне там в комментах отвечали, что мол если телефон начнет пытаться починить коннект, то что-нибудь уже работающее может сломаться.
Казалось бы, с какой стати? Компьютер может вполне две вещи держать в памяти, два коннекшна открытыми, работать в двух потоках. Это давно решенные проблемы, их любой ребенок, изучающий программирование, учится делать на третьем уроке в языке Лого. Однако почему-то, когда речь заходит о «серьезных системах» и «взрослых проблемах», доступные ребенку вещи вдруг становятся невозможными.
Хотя компьютер вроде бы один и тот же.
💯157👍26🤡15❤12🥱8❤🔥5😁3🐳2🤝2💔1
Мысль может быть неочевидная, но вещи со временем необязательно становятся лучше.
Слушал подкаст Software Unscripted и там чуваки вспоминали Visual Basic дебаггер, мол, современные ему в подметки не годятся. Ничего не могу сказать, но верю.
Мой собственный пример — фронтенд стек. Раньше ты просто писал js-файл и все работало. Сейчас же народ понапридумывал компиляции какой-то, минификации, и в итоге ты сидишь ждешь как дурак после каждого сохранения непонятно чего, а потом ошибка, а весь стек минифицирован. И чего? Кому лучше стало?
(inb4: но современный фронтенд решает гораздо больше задач, например uNiCoDe)
Или взять печальный пример Ruby on Rails. Когда он появился, он был противовесом большим и сложным стекам, которые надо было полдня сетапить, чтобы Hello world получить. Казалось бы — вот пруф, сейчас его все украдут и сделают так же. И что? Никто не укралн, не сделал, так и сидим, днями настраиваем hello world и ждем компиляции.
Или то, как интернет коллективно разучился различать чекбоксы и радиокнопки. Казалось бы, их специально придумали максимально разными: чекбоксы квадратные и с галочкой, радиокнопки круглые. И чего? Сегодня чего только не встретишь: и круглые чекбоксы бывают, и квадратные радиокнопки, и радиокнопки с галочками. Была последовательность, да пропала.
Или то, как в первых айфонах приложения умели восстанавливать свое состояние после перезапуска, а теперь не умеют.
Или то, как телефоны проебали кнопку Анду, хотя десятилетия компьютеров научили нас ее важности.
Или то, что раньше на сайт можно было зайти и начать сразу читать, а теперь надо с десяток попапов закрыть.
Короче, некоторые вещи конечно становятся лучше. Но некоторые хуже. Раз на раз не приходится. И подразумевать, что все что новее обязательно лучше — курам на смех.
Слушал подкаст Software Unscripted и там чуваки вспоминали Visual Basic дебаггер, мол, современные ему в подметки не годятся. Ничего не могу сказать, но верю.
Мой собственный пример — фронтенд стек. Раньше ты просто писал js-файл и все работало. Сейчас же народ понапридумывал компиляции какой-то, минификации, и в итоге ты сидишь ждешь как дурак после каждого сохранения непонятно чего, а потом ошибка, а весь стек минифицирован. И чего? Кому лучше стало?
(inb4: но современный фронтенд решает гораздо больше задач, например uNiCoDe)
Или взять печальный пример Ruby on Rails. Когда он появился, он был противовесом большим и сложным стекам, которые надо было полдня сетапить, чтобы Hello world получить. Казалось бы — вот пруф, сейчас его все украдут и сделают так же. И что? Никто не укралн, не сделал, так и сидим, днями настраиваем hello world и ждем компиляции.
Или то, как интернет коллективно разучился различать чекбоксы и радиокнопки. Казалось бы, их специально придумали максимально разными: чекбоксы квадратные и с галочкой, радиокнопки круглые. И чего? Сегодня чего только не встретишь: и круглые чекбоксы бывают, и квадратные радиокнопки, и радиокнопки с галочками. Была последовательность, да пропала.
Или то, как в первых айфонах приложения умели восстанавливать свое состояние после перезапуска, а теперь не умеют.
Или то, как телефоны проебали кнопку Анду, хотя десятилетия компьютеров научили нас ее важности.
Или то, что раньше на сайт можно было зайти и начать сразу читать, а теперь надо с десяток попапов закрыть.
Короче, некоторые вещи конечно становятся лучше. Но некоторые хуже. Раз на раз не приходится. И подразумевать, что все что новее обязательно лучше — курам на смех.
👍170😢27💯23🥱13❤🔥6🤡6❤4🔥3💔3🗿3
Вчера видел самый «переусложненный без какой-либо необходимости» код в своей жизни:
Когда достаточно было бы:
Отсюда правило: если что-то можно написать руками, а не вычислить програмно, надо писать руками.
Понятно, что программисты любят программировать, но надо себя сдерживать.
(def ns-clause-head-names
#{"use" "require" "require-macros"})
(def ns-clause-heads
(set
(mapcat
(fn [name]
(list
(keyword name)
(symbol name)))
ns-clause-head-names)))
Когда достаточно было бы:
(def ns-clause-heads
#{'use 'require 'require-macros
:use :require :require-macros})
Отсюда правило: если что-то можно написать руками, а не вычислить програмно, надо писать руками.
Понятно, что программисты любят программировать, но надо себя сдерживать.
🗿100🤨25👍19😁15🏆5🤡4❤2🔥2🦄1
Ребята, у меня теперь есть теоретическая база! Слово Эдсгеру Доувичу Дейкстре:
“We should do our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program and the process as trivial as possible.”
То есть что? В коде написано одно, а в рантайме другое. И чем больше расхождение, тем больше в голове держать.
Пример из прошлого поста ровно про это: он создает итоговый список в рантайме, а можно было его захардкодить, и тогда его сразу видно было бы.
Поэтому же я так не люблю всякие функции второго порядка и каррирования: мой паттерн-матчинг ломается и приходится абстрактное мышление включать. Ну что это такое, как это читать?
Дейкстра великий. И ведь у него даже Реакта не было!
“We should do our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program and the process as trivial as possible.”
То есть что? В коде написано одно, а в рантайме другое. И чем больше расхождение, тем больше в голове держать.
Пример из прошлого поста ровно про это: он создает итоговый список в рантайме, а можно было его захардкодить, и тогда его сразу видно было бы.
Поэтому же я так не люблю всякие функции второго порядка и каррирования: мой паттерн-матчинг ломается и приходится абстрактное мышление включать. Ну что это такое, как это читать?
(mapcat (comp (partial map str) vals val) exposes)
Дейкстра великий. И ведь у него даже Реакта не было!
🔥70😁18🤡13❤4💩4🤔1😎1
Непопулярное мнение: JavaScript единственный язык, который сделал правильные числа. 64 бита, которые одновременно и целое до 53-х бит, и с плавающей точкой если больше.
Ну просто подумайте: в какой жизненной ситуации вам нужны целые больше 53-х бит? Это 9*10^15, девять ебучих квадриллионов, девять тыщ триллионов то есть. Чтобы представлять что? Вокруг нас просто нет предметов в таком количестве (кроме размера node_modules). Девять тыщ терабайт, если в байтах.
То есть 53 бита достаточно каждому. Даже в указателях только 48 используется (хаха, а вы что, думали 64? Щас).
Ну а иметь один числовой тип вместо двух как будто тоже гениально? Все в выигрыше, никто не пострадал.
Почему же тогда подход JS не нравится «настоящим программистам»? Да потому что все остальные наловчились в 64 бита рассовывать разное, нужно им это или не нужно.
То есть по сути единственная причина, почему это неудобно, это другие языки, которые пришли раньше и у которых конвенция другая. Они может все 64 бита и не используют, но _потенциально_ могут, и в итоге приходится под них подстраиваться.
А нужно наоборот, чтобы все подстраивались под JavaScript (который на самом деле IEEE 754 double-precision float, если вам так больше нравится).
Но как же битовые операции, скажете вы? Как мне всякие там сдвиги считать? Ну чувак, битовые операции на числах это страшный хак, раз уж мы о типах заговорили. Они должны на байтах делаться, а не на числах.
А всякие int64/uint64 это от лукавого. Должен быть только number64.
Ну просто подумайте: в какой жизненной ситуации вам нужны целые больше 53-х бит? Это 9*10^15, девять ебучих квадриллионов, девять тыщ триллионов то есть. Чтобы представлять что? Вокруг нас просто нет предметов в таком количестве (кроме размера node_modules). Девять тыщ терабайт, если в байтах.
То есть 53 бита достаточно каждому. Даже в указателях только 48 используется (хаха, а вы что, думали 64? Щас).
Ну а иметь один числовой тип вместо двух как будто тоже гениально? Все в выигрыше, никто не пострадал.
Почему же тогда подход JS не нравится «настоящим программистам»? Да потому что все остальные наловчились в 64 бита рассовывать разное, нужно им это или не нужно.
То есть по сути единственная причина, почему это неудобно, это другие языки, которые пришли раньше и у которых конвенция другая. Они может все 64 бита и не используют, но _потенциально_ могут, и в итоге приходится под них подстраиваться.
А нужно наоборот, чтобы все подстраивались под JavaScript (который на самом деле IEEE 754 double-precision float, если вам так больше нравится).
Но как же битовые операции, скажете вы? Как мне всякие там сдвиги считать? Ну чувак, битовые операции на числах это страшный хак, раз уж мы о типах заговорили. Они должны на байтах делаться, а не на числах.
А всякие int64/uint64 это от лукавого. Должен быть только number64.
💩130👍112🤡72❤22🤔14👎7🗿7🖕6🐳3🌭3🦄3
Некоторые вещи меня в принципе устраивают, но хочется допилить в них одну-две фичи, чтобы стало совсем хорошо. Вот неполный список, в случайном порядке:
- Браузер, который на стороне пользователя. Запрещает всякие темные паттерны вроде «прозрачный оверлей, чтобы нельзя было скопировать картинку», «нельзя выделить текст», «при копировании добавляется копирайт», «попапы на выделение текста», «перехватывать поиск», «кастомное меню по правой кнопке», «откывать окна джаваскриптом». Ну и адблок встроенный, ага.
UPD: вспомнил еще: возможность отключить сервис-воркера! И не проебывать куки (сейчас вроде пошла мода проебывать и это вроде как частично из-за бразуера?)
- Телеграм-клиент, у которого есть табы, сплит-вью и чаты в отдельные окна можно оторвать (UPD: в Telegram Desktop можно оторвать). А то бывает читаешь какую-то длинную ветку комментов, или канал интересный нашел и назад далеко отскроллил, и тут тебе пишут что-то и вроде как надо посмотреть/ответить, но терять позицию не хочется.
- Гитхаб-фронтенд, который отвечает быстро. Да, это всего одна хотелка :) Ну ладно, вторая это чтобы lines of code показывал, хотя это уже больше к бэкенду вопросики.
- Твиттер-клиент. Просто чтобы был оффлайновый, сохранял твои твиты и группировал пользователей по каналам, как в Телеграме. Хорошая идея или нет, не знаю, но попробовать хочется. Ну и мусора всякого подчистить из интерфейса. Кнопка Ретвит чтобы выпадающее меню не показывала, например.
UPD: И чтобы не кропал картинки!!!
UPD: И не показывал Read more для постов короче 280 символов!!!!!!111
- Youtube-клиент НОРМАЛЬНЫЙ. Чтобы качество ставил какое мне нужно. Чтобы позицию не терял. Чтобы по истории искал. Чтобы грузился быстрее 10 секунд. Чтобы идиотские картинки не показывал пока видео еще не закончилось. И чтобы когда закончилось тоже не показывал. И чтобы UI не перекрывал контент. И ЧТОБЫ ПРОБЕЛ РАБОТАЛ СУКА
Есть и пара идей с нуля, у которых есть шанс быть написанными:
- Оконный менеджер для большого монитора. Rectangle и аналоги поставляются со странными действиями «разверни окно на полэкрана/две трети/одну треть слева», но на очень большом мониторе это бессмысленно: слишком высокое окно получается. Есть всякие действия типа «top right quarter»/«top right sixth», но у них какие-то пропорции неудобные. У make larger/make smaller просто идиотски маленький инкремент. Короче я не знаю точно, чего хочу, но как будто как минимум «задать размер» и «переместить окно» должны быть разными действиями? Тайловые не предлагать.
- Переключатель микрофонов. Дефолтный был бы окей, но у Эпла есть идиотская привычка переключать микрофон на Аирподсы когда ты их подключаешь. То есть ты мог настраивать все полчаса, подключить свой дорогущий микрофон, а потом воткнуть Аирподсы _после_ этого и абсолютно незаметно все твои настройки улетят в пизду. Ни писка нигде, ни окошечка, ни иконки даже. А так как ты сам себя не мониторишь (как вы это себе представляете, на аирподсах-то?), то ты об этом никогда и не узнаешь. Вторая фича это показывать текущий микрофон в статус-баре.
- Подкаст-клиент который умеет тырить видосы с Ютуба и превращать в аудио
И есть пара совсем безумных «проектов на сто человеко-лет»:
- Графический редактор с переменными. Чтобы где-то создал x=1, а потом ширину можно было указать как (x*5+7) px. И чтобы шрифты, шрифты можно из него экспортировать было :)
- Текстовый/код редактор с нормальной типографикой. Чтобы вариативные шрифты, все open-type фичи, все это настраивалось на уровне Фигмы хотя бы, а то и больше. Профили разные чтобы под разные языки. Псевдографика не через шрифт чтобы. Базовые вещи.
Проблема в том, что обычно просто так доделать приложение нельзя, а писать с нуля это целый проект. Так что это все мечты на пенсию.
А у вас какие мечты?
- Браузер, который на стороне пользователя. Запрещает всякие темные паттерны вроде «прозрачный оверлей, чтобы нельзя было скопировать картинку», «нельзя выделить текст», «при копировании добавляется копирайт», «попапы на выделение текста», «перехватывать поиск», «кастомное меню по правой кнопке», «откывать окна джаваскриптом». Ну и адблок встроенный, ага.
UPD: вспомнил еще: возможность отключить сервис-воркера! И не проебывать куки (сейчас вроде пошла мода проебывать и это вроде как частично из-за бразуера?)
- Телеграм-клиент, у которого есть табы, сплит-вью и чаты в отдельные окна можно оторвать (UPD: в Telegram Desktop можно оторвать). А то бывает читаешь какую-то длинную ветку комментов, или канал интересный нашел и назад далеко отскроллил, и тут тебе пишут что-то и вроде как надо посмотреть/ответить, но терять позицию не хочется.
- Гитхаб-фронтенд, который отвечает быстро. Да, это всего одна хотелка :) Ну ладно, вторая это чтобы lines of code показывал, хотя это уже больше к бэкенду вопросики.
- Твиттер-клиент. Просто чтобы был оффлайновый, сохранял твои твиты и группировал пользователей по каналам, как в Телеграме. Хорошая идея или нет, не знаю, но попробовать хочется. Ну и мусора всякого подчистить из интерфейса. Кнопка Ретвит чтобы выпадающее меню не показывала, например.
UPD: И чтобы не кропал картинки!!!
UPD: И не показывал Read more для постов короче 280 символов!!!!!!111
- Youtube-клиент НОРМАЛЬНЫЙ. Чтобы качество ставил какое мне нужно. Чтобы позицию не терял. Чтобы по истории искал. Чтобы грузился быстрее 10 секунд. Чтобы идиотские картинки не показывал пока видео еще не закончилось. И чтобы когда закончилось тоже не показывал. И чтобы UI не перекрывал контент. И ЧТОБЫ ПРОБЕЛ РАБОТАЛ СУКА
Есть и пара идей с нуля, у которых есть шанс быть написанными:
- Оконный менеджер для большого монитора. Rectangle и аналоги поставляются со странными действиями «разверни окно на полэкрана/две трети/одну треть слева», но на очень большом мониторе это бессмысленно: слишком высокое окно получается. Есть всякие действия типа «top right quarter»/«top right sixth», но у них какие-то пропорции неудобные. У make larger/make smaller просто идиотски маленький инкремент. Короче я не знаю точно, чего хочу, но как будто как минимум «задать размер» и «переместить окно» должны быть разными действиями? Тайловые не предлагать.
- Переключатель микрофонов. Дефолтный был бы окей, но у Эпла есть идиотская привычка переключать микрофон на Аирподсы когда ты их подключаешь. То есть ты мог настраивать все полчаса, подключить свой дорогущий микрофон, а потом воткнуть Аирподсы _после_ этого и абсолютно незаметно все твои настройки улетят в пизду. Ни писка нигде, ни окошечка, ни иконки даже. А так как ты сам себя не мониторишь (как вы это себе представляете, на аирподсах-то?), то ты об этом никогда и не узнаешь. Вторая фича это показывать текущий микрофон в статус-баре.
- Подкаст-клиент который умеет тырить видосы с Ютуба и превращать в аудио
И есть пара совсем безумных «проектов на сто человеко-лет»:
- Графический редактор с переменными. Чтобы где-то создал x=1, а потом ширину можно было указать как (x*5+7) px. И чтобы шрифты, шрифты можно из него экспортировать было :)
- Текстовый/код редактор с нормальной типографикой. Чтобы вариативные шрифты, все open-type фичи, все это настраивалось на уровне Фигмы хотя бы, а то и больше. Профили разные чтобы под разные языки. Псевдографика не через шрифт чтобы. Базовые вещи.
Проблема в том, что обычно просто так доделать приложение нельзя, а писать с нуля это целый проект. Так что это все мечты на пенсию.
А у вас какие мечты?
❤84👍27💯7🏆5❤🔥1😢1🤡1