Стой под стрелой

2022-06-15 14:35:10 Интересна психология эпигонства (подражания то есть) в айтишечке.

Например, недавно кто-то показал скриншот Аутлука, и у него там точно такая же настройка внешнего вида, как и у Гмейла — Default, Comfortable, Compact. Как будто успех Гмейла сделал его дефакто стандартом в почтостроении и представить себе почту без этой фичи невозможно. Хотя, конечно, любой сколь-нибудь видевший мир человек легко может себе почту без этой настройки представить, и любому понятно, что она не ключевая для успеха продукта, а более-менее произвольная и вообще связана скорее с историей Гмейла, чем с доменом доставки емейлов.

Roam Research тоже когда выстрелил породил волну клонов. Самое интересное, что они копировали и интерфейс, и реализацию — как и Roam, и Athens Research, и Logseq тоже были написаны на Clojure и использовали DataScript. Хотя казалось бы, как технологии влияют на успех продукта? Правильно, никак — лучший язык тот, который ты уже знаешь. Учить Clojure только ради того, что ее использует твой конкурент? Ну такое. А Athens Research вообще даже структуру названия скопировали. Ну и граф узлов, который никому в здравом уме не нужен, все PKM себе пихают, потому что он в Роме был.

Что я хочу всем этим сказать? Бездумное копирование передает некомпетентность — принимающие решения люди просто расписываются в том, что понятия не имеют, что именно сработало в оригинале и почему. Не будьте такими же, экспериментируйте, меняйте и делайте лучше. Ну или нет, я блогер в конце концов, а не закон. Открыть/Комментировать

2022-06-14 17:17:31 Работа со временем, часть 3/3

Тут уже будет про всякие курьезы. Во-первых, сильно не завидую составителям tz database, потому что им приходится иметь дело со сложностью человеческого мира и неточностью «обыденных» определений. Скажем, были города, в которых половина жила по одному времени, а половина — по другому. Какие-то города, например, Берлин, находились вообще в двух странах.

Другая штука — путешествие в прошлое. Как вы видели, Unix timestamp начинается с 1970-го, но можно ли продолжить его в прошлое? Немножко можно, насколько позволяет tz database, но там уже начинается неполнота данных о часовых поясах и прочий разброд. Если совсем сильно продолжать, то начинаются вопросы, скажем, переход между Юлианским календарем и Грегорианским был довольно долгим и хаотичным географически и зафиксирован не очень точно.

Сколько дней в феврале? 28-29, да? Часов в сутках? 23-25, как мы определили выше. А вот сколько секунд в часе? 3600, да? Не всегда Про високосный год все знают, а как вам високосная секунда?

Но давайте по порядку. В 1972 запустили атомные часы, которые без остановки и прочего булшита отсчитывали по одной секунде каждую секунду Их время называется International Atomic Time (TAI) и является, наверное, самой базовой величиной которая у нас есть (да, я говорил, что unix timestamp, но нет). С момента запуска они обогнали UTC на 37 секунд.

Далее есть UT1. Это время, основанное на вращении Земли, в предположении, что каждый новый год наступает ровно в 00:00:00 по UT1. Но! Штука в том, что вращение Земли, во-первых, замедляется, а во-вторых неравномерно и непредсказуемо (!! да, блин! Потому что по ней всякий хлам типа морей, магмы и материков болтается) и в итоге каждый год (по астрономическим наблюдениям вращения Земли) имеет слегка разную продолжительность в секундах.

UTC это компромисс для удобства обычных людей: это тот же TAI (т.е. атомные стабильные секунды), к которому иногда добавляют или отнимают по одной секунде в год, чтобы Новый год наступал как можно ближе к 00:00:00 по UT1 (астономическому).

Пока секунды только добавляли, обычно это делают как 23:59:60 31 декабря или 30 июня. Это происходит нерегулярно, основано на астрономических измерениях и никто заранее не может сказать, когда и сколько их в будущем будет добавлено. Последнюю добавляли в 2016-м.

Как это все переносится на Unix time? А никак В Unix time такое понятие не заложено. Если число делится на 3600000, значит это граница часа. Удобно — но также и слегка неправда.

Что же делают компьютеры? Вариантов немного — можно либо повторить 23:59:59 два раза (перевести на секунду назад), либо заморозить часы, либо размазывать эту секунду тонким слоем на целые сутки (вроде Гугл этим хвастался, но не подскажу где).

Именно поэтому Unix time это очень удобная точка отсчета в практическом смысле, но немножко неправда до самого конца. Но на деле — скорее всего, о високосной секунде вам париться не придется. Правда в JVM был какой-то баг на эту тему (скорее всего, что-то про немонотонность часов), и я лично вроде как в 2012-м что-то там из-за этого у нас перезапускал.

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

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

2022-06-14 17:17:25 Работа со временем, часть 2/3

Вся информация об исторических переменах собирается в tz database. Это такой public domain файлик, где для каждого города написано, какой у него UTC offset, как и когда он переходит на летнее время и как это менялось с 1970-го года. Он используется для всех преобразований между wall clock и unix time.

Написано в нем примерно следущее:


# From Paul Eggert (2016-03-18):
# Asia/Novosibirsk covers:
# 54 RU-NVS Novosibirsk Oblast

# From Stepan Golosunov (2016-05-30):
# http://asozd2.duma.gov.ru/main.nsf/(Spravka)?OpenAgent&RN=1085784-6
# moves Novosibirsk oblast from UTC+6 to UTC+7.
# From Stepan Golosunov (2016-07-04):
# The law was signed yesterday and published today on
# http://publication.pravo.gov.ru/Document/View/0001201607040064

Zone Asia/Novosibirsk 5:31:40 - LMT 1919 Dec 14 6:00
6:00 - +06 1930 Jun 21
7:00 Russia +07/+08 1991 Mar 31 2:00s
6:00 Russia +06/+07 1992 Jan 19 2:00s
7:00 Russia +07/+08 1993 May 23 # say Shanks & P.
6:00 Russia +06/+07 2011 Mar 27 2:00s
7:00 - +07 2014 Oct 26 2:00s
6:00 - +06 2016 Jul 24 2:00s
7:00 - +07


TZ database изначально собирается волонтерами (да, блин!), затем компилируется и поставляется операционными системами и некоторыми платформами (в JDK, например, есть копия). Помню, как несколько лет страдал со своим Андроидом, на который не выходили обновления, а Новосибирск поменял часовой пояс и Asia/Novosibirsk показывало неправильное местное время.

Теперь про сложности. Главная сложность заключается в том, что время идет по Unix time и работать с ним легче тоже в Unix time, но люди хотят иметь дело с Wall clock time. И вот тут, ну, нужно быть внимательным, и все будет хорошо.

Пример — скольчо часов в сутках? 24, правильно? Кроме дней перевода часов, тогда там будет или 23, или 25, потому что для человека сутки — это интервал между 9 утра на часах сегодня и 9 утра на часах завтра, а сколько на самом деле времени прошло — не так уж важно. Важно, во сколько вставать на работу.

Или другая ситуация — я поставил будильник на завтра на 9 утра. И потом перелетел из Берлина в Москву. Во сколько должен зазвонить будильник? В 9 утра, но уже по Москве, да? То есть Unix timestamp будильника должен поменяться в момент смены часового пояса.

А вот для календаря это уже неверно — событие на 9 утра по Берлину должно превратиться в 10 утра по Москве, где бы я ни находился.

Из-за всего этого возникает концепция «местного», или «символического» времени. Скажем, вам надо посчитать, какое число будет через пять дней после 5 июня. Можно взять 5 июня, какой-то часовой пояс (например, текущий), перевести в Unix timestamp, прибавить 5 * 24 * 3600 * 1000, и перевести обратно в wall clock той же таймзоной и посмотреть на дату.

Но это бред — как мы видели, не в каждых сутках 24 часа, таймзону приходится брать с потолка, и вообще вопрос не об этом был. Как люди мы понимаем, что через пять дней после 5 июня будет 10 июня, где бы мы ни находились и сколько бы между ними реально часов не прошло. Поэтому такие вычисления лучше делать без Unix time вообще, а чисто на символическом календаре, в котором 5 и 10 июня не соответствуют какому-то конкретному моменту времени.

Но на этом сложности более-менее заканчиваются. Если хорошо понимать, о чем каждый раз идет речь — о конкретном _физическом_ моменте времени (unix time), о времени на часах в комнате (wall clock) или о символических вычислениях (даты, обычно, но и время тоже) — то почти всегда достаточно легко сделать то что нужно и получить правильный ответ. Главное не спутать одно с другим, потому что на словах все это — время, часы, а смысл сильно разный. Открыть/Комментировать

2022-06-14 17:17:20 Давайте я вас таймзонам научу? А то бытует мнение, что это что-то сложное, но на самом деле там все просто, если разобраться.

Самое простое, что нужно понять — Unix timestamp. Формально это количество миллисекунд, которые прошли с момента, когда 1 января 1970-го года в Гринвиче часы показывали 00:00:00. Узнать его можно, например, так:


>>> new Date().getTime()
1655208767805


Кайф в том, что unix time одинаково по всей земле. То есть любой человек где угодно на планете, если запустит эту вот строчку кода одновременно со мной (в ту же миллисекунду) получит то же самое число. Где бы он ни находился.

И это очень удобно. Unix time не зависит от часового пояса, летнего времени и прочей чепухи. Каждую секунду он увеличивается на 1000 по всей Земле одновременно. Любое число это какой-то момент времени, и любому моменту времени соответствует какое-то число, без пропусков.

Да, когда мы полетим на Марс, станет сложнее (из-за релятивистских эффектов), но пока это очень удобная точка, от которой можно плясать.

Дальше. Понятно, что считать время таким образом не очень удобно. Люди привыкли общаться в терминах «четыре утра» или «семь тридцать вечера». Это называется Wall clock time, то есть время, которое будут показывать часы на стене в данном месте в этот конкретный момент времени.

В чем подвох? В один и тот же момент времени в разных точках земли часы на стенах показывают разное время. У меня 14:19, в Москве 15:19, а в Нью-Йорке 8:19. Это называется «часовые пояса».

То есть чтобы получить wall clock time, надо знать Unix timestamp и место. Это преобразование тотально (то есть работает всегда) — в любой unix timestamp в любом месте часы будут показывать _что-то_.

Обратное преобразование тоже возможно, но уже не всегда определено. Связано это с летним временем — когда часы переводят вперед, возникают цифры, которые часы не показывают никогда. Скажем, если часы перевели с 2 ночи на 3 ночи, ни в какой момент времени они не покажут 2:30. То есть перевести 2:30 в Unix timestamp не получится — в этом нет смысла.

Хуже того, если часы переводят назад (с 3 часов на 2), то 2:30 возникнет на них дважды в день, то есть из 2:30 можно получить аж два разных (с интервалом в 3600000 мс) Unix timestamp-а — преобразование неоднозначно.

Именно из-за этих неопределенностей Unix timestamp первичен, а wall clock time вторичен. Если вы храните Wall clock time (даже с часовым поясом), вы теряете информацию.

Теперь про часовые пояса. В простейшем случае это просто число минут, на которое время отличается от UTC — скажем, у меня сейчас UTC+0200, то есть на два часа больше, чем UTC. UTC это типа wall clock в Лондоне без летнего времени (на самом деле, атомные часы, но про это позже). Есть вроде таймзоны, отличающиеся кратно на 30 и на 15 минут, но более идиотских нет (хотя раньше были).

Однако простого UTC+0200 недостаточно, потому что есть еще два фактора — летнее время и история. Летнее время это собственно два раза в год переход от одного UTC-смещения к другому и обратно. Скажем, у меня в Германии летом UTC+2 (CEST), а зимой UTC+1 (CET). Поэтому когда вы выбираете часовой пояс, вы выбираете Europe/Berlin, а не UTC+2 — смещение плавает.

Плавает оно и из-за исторических прецедентов. Скажем, мой родной Новосибирск несколько раз только на моей памяти менял часовой пояс между UTC+6 и UTC+7. Это никак, разумеется, нельзя предсказать или предвидеть — правительства разных стран могут менять эти вещи произвольно, иногда объявляя об этом за пару недель и только в местных газетах.

Это была часть 1/3, продолжение ниже! Открыть/Комментировать

2022-06-13 17:35:56 Лет десять назад, когда интернет еще был медленный, а браузеры не до конца дружили с SVG, кому-то пришла в голову идея засунуть иконки в шрифт.

Ну а что — шрифт это векторный формат для миллиона разных картинок в одном файле, как раз то что нужно для иконок. Гитхаб, кажется, очень этим гордился, Font Awesome тогда появился, короче, трендовая тема. С цветами правда была проблема, но ее быстро замяли, сказав, что «такой дизайн» и вообще цвета в иконках отвлекают.

На волне хайпа решил и я сделать также. Засунул, значит, свои иконки в шрифт, поставил на сайт, открываю — говно какое-то. Что такое? Что случилось?

Оказалось, поскольку это теперь шрифт, то Винда начала его аггресивно «оптимизировать» под пиксельную сетку — вершины подвигала, Clear Type сверху наложила и получился какой-то уродец.

Короче, плюнул я на это, сделал обычные то ли PNG, то ли SVG, все сразу заработало, ну я так и оставил. Мир тоже с этой идее соскочил как-то.

Потом уже появились Emoji, которые вообще непонятно какими правдами и неправдами рендерятся, но над которыми у тебя нет контроля — бери те, что есть, и выглядеть они будут «как-то» (как и буквы, впрочем — кто его знает, каким шрифтом их увидит пользователь).

И тут проснулся Эпл, самая прогрессивная и передовая компания на планете, и решила эту технологию возродить. Зачем, почему — никто не знает. Да, у них нет проблемы с Clear Type и хинтингом (потому что его нет на Эпл-устройствах в принципе), но все равно ощущение что сову натягивают на глобус осталось.

Нигде кроме Маков эти символы не увидишь, с цветами проблемы, размер точно хрен подгадаешь, да еще и в пиксели не попадают примерно никогда. А самое главное — шрифт зависит от версии ОС. Извините, вы не можете скачать это приложение, потому что иконка листа появилась только в нашей последней ОС.

Короче, по-моему это тупиковая ветвь. Чем SVG не угодил (или PDF, который так любят в Эпле), я так и не понял. Есть вариативность, но зачем она нужна я, если честно, хз. Часто вы вес своим иконкам меняете? Открыть/Комментировать

2022-06-11 13:54:15 Слушал сегодня The Talk Show live from WWDC, там интервьюруют управляющих Эпл на сцене типа. Предполагается что будут критиковать, но на самом деле довольно беззубая штука.

Ну и там кто-то из них (не различаю по голосу, сорян) говорит в защиту Catalyst (это такая технология, чтобы iOS приложения под Мак адаптировать и запускать) что мол вот мы выкатили редактирование сообщений в Messages в этом году, и если бы не Catalyst, то на Мак оно бы еще ехало год или два. А так, типа, одновременно.

В связи с чем у меня вопрос: а сколько вообше людей нужно, чтобы писать этот самый Messages, допустим, нативно под Мак? Неужели нельзя посадить одного человека, ну двух-трех ради бас фактора, чтобы они за год сделали редактирование сообщений? Одну-единственную фичу? Причем фронтенд только, бэкенд явно общий с айосом.

Просто вот эта вот логика больших компаний, что чем больше у них людей, тем меньше ресурсов на что угодно как будто. У нас пятьдесят тысяч программистов, поэтому ну никак невозможно найти одного, который бы портировал приложение под Мак. Как, почему? В чем проблема? Чем остальные таким важным заняты? Почему нового не нанять, деньги же есть? Открыть/Комментировать

2022-06-10 23:32:12 Чего я никак не могу понять так это почему я достаточно регулярно вижу картинки с неправильными пропорциями сторон (aspect ratio). Казалось бы, вот картинка, у нее написано, сколько она по ширине и сколько по высоте. Недвусмысленно написано, в цифрах. Как можно их проигнорировать и нарисовать с какими-то другими?

Я понимаю, что это от невнимательности происходит и от недосмотра, но чего я не понимаю так почему возможность испортить пропорции вообще существует? В жизни нет ни одной ситуации, когда картинку было бы нужно растянуть/сжать только по одному направлению, не изменив так же и другое. Вот ни одной.

Кто написал этот код, который позволяет тянуть/жать картинки только по одному направлению? И почему он так легко доступен? Открыть/Комментировать

2022-06-09 16:43:46 Всегда интересно, как в больших компаниях принимают решения. Типа, почему фильм такой тупой, хотя у них было 200 миллионов — неужели нельзя было нанять сценариста хотя бы за миллион, чтобы он указал на идиотизмы?

Или смотришь на дизайн нового macOS — ну наверняка каждый экран десятки людей видели и утверждали, и что, никто не сказал ни в какой момент «говно, переделывайте»?

Причем не по спорным каким-то вещам, не по вкусовщине, а по базовым: affordances, контраст, производительность. Пока в вебе идут бои за контрастность 7:1, в Эпле делают группировку контрастом 1,03:1 (не шучу).

Никогда не думал, что прогресс может идти вспять, но мы это вовсю наблюдаем. Интересно, на самом деле, что там внутри происходит — если даже всем в интернете понятны проблемы, неужели внутри Эпла совсем не осталось людей, которые понимают базовые вещи про экранные интерфейсы? Которые могут сказать, что Welcome Screen или там Security Popups это анти-паттерны? (которые Эпл сам же раньше и высмеивал в рекламе). Наверняка же остались, но почему их не слушают?

И если «делать хорошо» не основной императив, то какой основной? Менять что-нибудь каждый год, неважно что? Хочется просто понять логику, чтобы знать, чего ждать. Кто знает? Есть идеи? Открыть/Комментировать

2022-06-07 15:06:53 Ничто так сильно не расстраивает меня в компьютерах, как ресайз окна. Да, когда берешь его за уголок и таскаешь туда-сюда.

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

Потом компьютеры стали побыстрее и появился «живой» ресайз — окно перерисовывалось прям по ходу перетаскивания.

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

Потом на маке сделали «нативный» фулскрин. Понятно, что при переходе из обычного состояния в полный экран окну надо увеличиться — но анимацию этого увеличения почему-то сделали тупым растягиванием текстуры. Если вы откроете, скажем, терминал на четверть экрана, а потом нажмете на зеленую кнопку в светофоре, вы сначала увидите как все буквы вырастают в четыре раза, а потом фейдятся обратно в свой нормальный размер. Очевидно, опять где-то кому-то не хватило производительности.

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

И вот наконец вчера анонсировали, что в новой АйпадОС можно управлять окнами! И что бы вы думали? Ресайз там выглядит максимально позорно! Содержимое окна скейлится прям в процессе, буквы прыгают, по бокам появляются черные полосы на месте предыдущего размера. Я кстати не понял, как они умудрились сделать и то, и то одновременно. По идее, ты ЛИБО скейлишь и растягиваешь текстуру (и тогда размеры фиксированных элементов скачут), ЛИБО закрашиваешь пустое место черным. Как можно получить оба эффекта одновременно — загадка. Но для Эпла нет ничего невозможного.

Что меня тут расстраивает так это тривиальность задачи. Мы 100% знаем, что компьютер МОЖЕТ ресайзить окно со скоростью 1000 fps. Скажем, если я напишу программу, которая будет эмулировать оконный менеджер внутри своего окна, там все будет гладко, быстро и надежно. Почему на уровне ОС нельзя также? Даже на самом мощном и свежем железе и софте программисты не могут заставить ОС делать это.

И ладно бы Мак — там, понятно, стопицот слоев совместимости и костылей, как в истории с моргающим Емаксом, — это хотя бы как-то можно понять (хотя все равно обидно).

Но Айпад-то свеженький и там можно было сделать нормально? На маломощность тоже уже списать не получится — там сейчас точно такой же процессор, как и в десктопных маках, и он побыстрее многих ноутбуков.

И это я уже не говорю про то, как это выглядит для программиста. На уровне API (причем как мака, так и винды) создать окно, которое плавно ресайзится — нетривиальная задача, решаемая комбинаторно и такое ощущение что по чистой случайности. Почитайте The smooth resize test Рафа Левина, если не верите.

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

2022-06-04 13:21:18 Есть такое поверье, что статическая типизация очевидно помогает писать код лучше — меньше ошибок и быстрее. Потому что компьютер помогает, типы сами все проверяют, тесты не нужн и т.д.

Казалось бы — логично? Легко можно предствить, как это работает.

Моя проблема в этом утверждении только со словом «очевидно». Смотрите — если бы это действительно было так очевидно, мы были бы завалены примерами как статическая типизация нарезает круги вокруг динамической, да? Я даже не говорю про исследования (хотя и они, наверное, были бы), но просто примеры из жизни. Раз вещь очевидная, значит она подтверждается направо и налево, по многу раз на дню?

И что? Где эти примеры? Где подтверждения? Где статистически значимые проценты компаний, которые завоевали рынок за счет выбора статически типизированного языка? Где те самые супер-надежно работающие на статических языках программы? Где статические программисты, работающие по полтора часа в день, потому что это настолько легче чем у конкурентов?

А нет их. Может быть, не так уж это и «очевидно»? Открыть/Комментировать