Хакер ньюз, как и Хабр, конечно уникальный сайт. Где еще выпадет возможность заглянуть в разум «среднего айтишника»? Почувствовать настроения эпохи?

Мои статьи периодически попадают туда, и, в целом, обсуждаются с неплохим коэффициентом полезности.

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

2019! 2019, ребят!

Типа, вы чего? Этому посту уже три года! Он воняет! Не тратьте свое время, мол, эти идеи давно протухли! Человек из 2019-го уж явно не мог ничего дельного сказать! Да какой человек, дед! Натурально, дед уже, если в 2019 уже писать умел! Как он вообще в 2019-м это опубликовал? Через факс? На пергаменте? Пером?

Не, ну правда, где еще можно так полно погрузиться в разум «среднего айтишника»? Взглянуть, чем он живет, какими идеалами, какими переживаниями?

Не то что комментарии в этом паблике. Комментарии тут — самые лучшие, а комментаторы — далеко впереди «среднего айтишника». Ну, как по мне. Люблю вас!

Посмотрел несколько часов суда Джонни Деппа и Амбер Херд. Раньше мое представление о судебной системе США ограничивалось фильмами про адвокатов. Ну там знаете, Вердикт, 12 разгневанных мужчин, Сбежавшее жюри, Филадельфия, Адвокад дьявола, Блондинка в законе, Голиаф, Чикагская семерка. А тут — видеозапись, как оно на самом деле.

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

Но весь кайф в конкретике. Например, юрист может показать чью-то запись/документ и попросить автора ее прочитать. Автор может начать пытаться объяснять, что же он имел в виду (свои же слова!), или дать контекст, но ему не дают. И вообще говорить и что-то уточнять не приветствуется. Прям могут сказать: пожалуйста, не уточняйте. Почему что-то неидеально сформулированное в один момент в прошлом имеет какие-то преимущества перед более взвешенным взглядом _того же самого человека_ из сегодня, непоятно.

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

Ну и самое странное — наводящие вопросы. Точнее, я даже не знаю, как это назвать. Вопросы, которые выглядят примерно так (Деппу): «Перед вами газетный заголовок “У Джонни Деппа проблемы с выпивкой”. Я правильно его прочитал?». «Да». «Отлично, следующий вопрос». То есть вопрос в том, правильно ли он прочитал, а что по сути заголовка — отвечать нельзя. И не не хочется, а именно нельзя!

Вот что это было вообще? Какие выводы надо из этого сделать? При всей юркости адвокатов (а они очень, очень не стесняются возражать — objection — по любому поводу) именно этот паттерн почему-то никто не пресекает.

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

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

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

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

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

P.S. Для проигрывания видео используется обычный виндовый VLC :) А еще в какой-то момент все ждут пару минут, пока загрузится винда. Не боги горшки обжигают

Больше всего меня бесят непрозрачные АПИ. Возился в пятницу с Файрбейзом, и у них чтобы авторизоваться, нужен обязательно их клиент, которому нужно подложить какой-то json-файл с креденшлами, который нужно где-то еще сгенерить. Гуд лак сделать запрос из скрипта на CI.

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

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

А у Гугла как? Скачиваешь JSON-файл. Запускаешь гугл-клиента. Он делает за тебя запрос. Получаешь короткоживущий ключ. И вот им уже можно пользоваться (недолго). А файл таскай с собой.

Зачем? Почему? Концепция короткоживущих временных ключей мне как-то слабо понятна, если честно. На клиенте еще можно как-то объяснить тем, что мол враждебная среда, чужой код вокруг, тыры-пыры, но на сервере-то зачем?

Json-файл тоже смешной, например, там внутри куча полных URL-ссылок на гугл же. Видимо это какой-то «самоописывающий» формат, я помню была мода на такие. Типа, делаешь запрос, а тебе в ответе ссылка «на следующие десять записей» полным урлом, с доменом и всей байдой.

Какая-то на редкость бесполезная фигня, как по мне. Тебе все равно надо уметь делать запрос на любую страницу в любой момент, так что ты все это и так и так уже захардкодил, и в ответе тебе просто придет то, что ты и так уже знаешь. Плюс дублирование, скажем, в документации написано делать example.com/page10, а в ответе приходит www.example.com/page-10. И что, кому верить?

Не делайте так, короче. Делайте REST API, которые не требуют клиента, и простые вечноживущие ключи, которые можно послать в header.

Если вам нужна хорошая метафора веб-разработки, то некто leoeelias в твиттере нашел, что чтобы провалидировать email, можно создать невидимый DOM-элемент input type=email, вставить в него значение и позвать checkValidity().

Мало того что это как вызвать бульдозер, чтобы разгладить складку на брюках, так потом еще и выяснилось, что эта самая валидация проверяет наличие символа @ в строке и всё. Как всегда, хочешь сделать хорошо — доверься веб-стандартам ¹ ²

¹ Кроме мобильного Сафари
² Сарказм

Давайте регэкспам научу за один пост?

Регэксп описывает шаблон, который вы хотите найти внутри строки.

Самый простой — буквальный. Что написано, то и ищем:

/abcd/ => ✅ "abcd", ⛔️ все остальное

Какой-то символ может повторяться. Если сколько угодно раз (1 или больше), то плюсик:

/a+/ => ✅ "a", "aa", "aaa"

Если сколько угодно раз или ни разу (0 или больше), то звездочка:

/a*/ => ✅ "", "a", "aa", "aaa"

Если один раз или ни разу, то вопрос:

/a?/ => ✅ "", "a", ⛔️ "aa", "aaa", "aaaaaaa"

Все три применяются только к символу, который идет непосредственно перед:

/https?/ => ✅ "http", "https", ⛔️ "htt", ""

Теперь про сами символы. На одной букве далеко не уедешь, поэтому есть выбор. [abc] значит любой из a, b или c:

/[abc]/ => ✅ "a", "b", "c", ⛔️ "d"

Внутри квадратных скобок можно писать диапазоны:

/[a-z]+/ => ✅ "abc", ⛔️ "123", "ab12"
/[0-9]+/ => ✅ "123", ⛔️ "abc", "ab12"

Но в эпоху юникода использовать a-z не рекомендуется. Вместо этого есть Юникодный класс “Letter”:

/\p{L}+/ => ✅ "abc", "абв", "åbč", ⛔️ "1234"

У квадратных скобок есть еще одна особенность: можно сказать отрицание, то есть «что угодно кроме перечисленного»:

/[^a-z]+/ => ✅ "123", "абв", ⛔️ "a", "abc"

Полезно, например, чтобы делить строку по разделителю. Можно написать «что угодно кроме двоеточия ноль или более раз»:

/[^:]*/ => ✅ "", "123", "абв", ⛔️ "a:b", ":"

Еще один важный класс: пробел. \s включает все возможные варианты пробелов (неразрывные, em/em spaces, табы и т.п.):

/\s*/ => ✅ "", " ", "   ", ⛔️ "abc"

\s* часто используется при парсинге «человекочитаемых форматов», т.к. люди любят пробельчиками отбивать все, или делать вид, что их не видят.

Точка. Точка значит «что угодно вообще»:

/.*/ => ✅ "", "123", "абв"

Крышечка и доллар — начало и конец строки. Обычно регрексп будет искать вам ПОДстроку. Чтобы проверить всю строку целиком, заверните ее:

/^[a-z]+$/ => ✅ "abcd", ⛔️ "abcd1"

Наконец, «или». Когда нужно выбрать из нескольких сильно разных вариантов — скобки и пайп:

/(http|ssh)/ => ✅ "http", "ssh", ⛔️ "htsh"

По использованию. В простейшей версии регэкспом вы просто проверяете, есть ли внутри строки подстрока, соответствующая шаблону:

/[a-z]+/.test("1abc2") => true
/[a-z]+/.test("123") => false

Но иногда строку хочется распарсить. Для этого интересующие вас части заверните в круглые скобки:

"__abc123__".match(/([a-z]+)([0-9]+)/) => ["abc123", "abc", "123"]

Штуки в скобках называются «capturing groups». match вернет вам сматчившуюся подстроку целиком плюс значения всех capturing groups.

Тут проблема, потому что скобки могут быть чисто техническими и использоваться просто для группировки. В этом случае пишут (?:), «non-capturing group». По сути те же скобки, но в результат match-а они не попадут.

"__abc123__".match(/(?:a|b|c)+([0-9]+)/) => ["abc123", "123"]

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

/( abc | def )/ => ⛔️ "abc", "def", ✅ " abc ", " def "

Второе — многие нормальные символы имеют специальное значение и их нужно эскейпить. Это очень трудно читать:

/(\(|\))/ => ✅ "(", ")"

Особенно легко попасть на точке:

/.*.jpg/ => ✅ "abcjpg"
/.*\.jpg/ => ⛔️ "abcjpg"

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

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

Факультативно почитайте про lookahead/lookbehing, quantifier, named groups, greedy/lazy, флаги ignore case, unicode, multiline.

Как-то так.

Вот программисты любят говорить «требования». Реализую требования, спустили требования, код соответствует требованиям.

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

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

Даже если требования это какой-то стандарт, то всегда есть еще решение соответствовать стандарту или нет, расширить его или реализовать неполностью, или вообще договориться о другом стандарте.

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

Напоминаю вам, что если вы не знаете, как расшифровывается

XSS, CORS, CSP, CPS, CSS, SVG, GIF, JPG, JPEG, PNG, APNG, BMP, MIDI, HTML, DHTML, SGML, RTF, RDF, ODF, PDF, OWL, JSON, JSONP, JSONB, RSS, MAML, XAML, YAML, VML, XSL, XSLT, XHR, PHP, APL, ML, ML, WHATWG, W3C, IEC, ISO, OSI, OIS, IOS, OASIS, WS-I, TCP, UDP, IP, HTTP, IMAP, SSH, SCP, FTP, SFTP, DHCP, LDAP, MQTT, NTP, POP, RTSP, SIP, SMTP, TLS, SSL, DSA, RSA, ECDSA, XMPP, SCTP, ICMP, PPP, MPLS, LSP, ID, CPP, BSD, GNU, GPL, LGPL, AFL, APSL, CDDL, EPL, MIT, MPL, WTFPL, OSS, FOSS, FLOSS, PDP, SVR, OSF, CSRG, QNX, AIX, POSIX, SFU, WSL, WSLG, NT, CD, VM, VMS, IPC, CPU, RAM, DMA, RDMA, UDMA, CPP, UB, USB, API, DSL, MBR, CLI, GUI, GUID, UEFI, APM, WOL, SDI, RPC, RFC, I/O, PIO, SoC, SSE, ALU, GPU, MMU, MP, MPI, AMP, SISD, MISD, SIMD, MIMD, SPMD, MPMD, SIMT, SMP, UMA, NUMA, COMA, CORBA, CUDA, GCC, LLVM, GPG, PGP, GPGPU, CRDT, LWW, I2P, P2P, VPN, IPFS, APFS, BFS, FAT, HFS, LFS, NTFS, ZFS, NAS, FUSE, SMB, SSHFS, DHT, LSMT, DAG, DNA, DAO, DOM, SOAP, ICO, NFT, SQL, NoSQL, NewSQL, DDL, DML, DFDL, OQL, CQL, SPARQL, LINQ, ACID, SOLID, CAP, CRUD, JDBC, ODBC, J2EE, JSR, JSP, JSF, EJB, JTA, JPA, PIP, CGI, SSI, FCGI, MSE, SSE, IDL, DI, EAP, GA

то вы ненастоящий программист. Идите доучивайтесь!

UPD: Подписчики добавили

RTFM, OMFG, HATEOAS, WYSIWYG, DDOS, MITM, DNS, LAMP, PKI, GOF, DDD, TDD, BDD, DOD, RTCP, RTC, NvME, KISS, DRY, YAGNI, AJAX, NLP, OLE, OLAP, OLTP, SFINAE, FIFO, LIFO, DBMS, RDBMS, JVM, JRE, JDK, REST, AWS, IAM, EC2, RDS, EBS, SQS, I18N, L10N, A11Y, K8S, MVCC, MVC, MVVM, OOP, FP, ASCII, AVX, CQRS

которые, конечно, тоже стыдно не знать!

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

А у вас как?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Самое простое, что нужно понять — 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, продолжение ниже!

Работа со временем, часть 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) или о символических вычислениях (даты, обычно, но и время тоже) — то почти всегда достаточно легко сделать то что нужно и получить правильный ответ. Главное не спутать одно с другим, потому что на словах все это — время, часы, а смысл сильно разный.

Работа со временем, часть 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-м что-то там из-за этого у нас перезапускал.

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

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

Интересна психология эпигонства (подражания то есть) в айтишечке.

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

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

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

Купил умный телевизор, подключил к нему плейстейшн, чтобы играть в Dead Cells. Захожу в настройки, а там — хотите «умное соединение» (или как-то так)? Допустим, хочу. В плейстейшне то же самое. Допустим тоже хочу.

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

В обратную сторону, кстати, работает получше — включаешь телек, он включает плейстейшн. Правда, если ты хотел например Ютуб посмотреть (там есть свой андроид какой-то) (UPD: не андроид, webos), то все равно сначала проснется приставка, ты этого подождешь и только потом сможешь в меню уже телевизора перейти. А если еще Эпл ТВ подключить вторым устройством, то вообще не угадаешь, кого телек будет будить в первую очередь.

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

Мораль простая. Сложные схемы не работают. Два умных устройства вместе тупее, чем одно. Да, даже в 2022 и даже в топовом ценовом сегменте. Компьютеры были ошибкой, сингулярность наступила и она мне не нравится. Но зато рано или поздно мы все умрем. Хорошего дня!

Не могу с истории с Эплом и Stage Manager на айпаде. Если коротко — Stage Manager это возможность открыть до восьми приложений в трех группах и переключаться между ними. Ну а драма в том, что Эпл сделал эту возможность только для самых новых айпадов на M1, а всех остальных побрил. Да, такие условия, надеемся на понимание.

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

«На всех других айпадах эта фича тормозит» — да, но с чего бы? Айпад и мобилки вообще уже давно не сильно ограниченные компьютеры, мой айфон помощнее многих ноутов будет. «У старых айпадов меньше оперативки» — ну да, ну для этого своп и придумали. «Своп не везде есть» — но все-таки на старых айпадах он есть, а stage менеджера — нет (UPD: третье, пятое поколения и Эйр это все самые последние, оказывается. Драма в том, что на M1 не везде есть своп! Ну и еще в том, что почему он, собственно, не везде есть?) Плюс, ну не каждое же приложение по 4 гига отжирает, может я календарь с почтой хочу рядом запускать? Ну и опять же — если они у вас по 4 гига отжирают, то может их починить надо?

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

Поэтому и вводятся странные «ограничения» — только последний айпад (так и быть, разрешим вам его купить вместо такого же прекрасного и дорогого, но прошлогоднего), только 8 приложений. Откуда эта цифра вообще? Почему 8? Восемь CAD-ов и Фотошопов и восемь чат-клиентов и календарей это две огромные разницы по ресурсам. Если ты можешь восемь CAD-ов, то наверное ты можешь сто приложений погоды?

Это я все к тому, что если вам казалось, что в компьютерах есть какой-то прогресс, что мы все куда-то движемся, то нет, мы изобретаем возможности, которые компьютеры умели 30 лет назад, искуственно ограничиваем их доступность и продаем как «продвинутые» фичи каждый год заново. В железе прогресс да, огромный. А вот в софте какой-то день сурка.

Обожаю, когда в компьютере появляются сообщения со словами «кажется» или «возможно». «Возможно, нужно будет перезагрузиться». «Кажется, что-то пошло не так». «Где-то произошла ошибка».

Это компьютер, алло, на 100% детерменистичная машина. Наверное, можно разобраться и узнать точно, да?

Причем этим грешат не только разработчики, которые вынуждены работать в обход, допустим, кривых или неполных АПИ. Этим грешат и вендоры: Майкрософт, Эпл в собственных операционках, которые они на 100% контролируют. Я установил ваш апдейт с вашего же сайта на вашу же операционку, надо перезагружаться или нет? «Возможно».

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