Статья на тему, “как мне продать неведомую хрень, про которую никто не знает, что это такое и зачем оно ему нужно”.
Если бы у меня был работающий рецепт бессмертия, я взял бы в долю санитара из ближайшего хосписа, и через него распространял бы это снадобье среди больных. За умеренные деньги, хотя бы поначалу, чтобы заработать репутацию.
У каждого компьютера есть внутренние часы, обычно управляемые кварцевым резонатором. При подаче напряжения на эти резонаторы они колеблются на определённой частоте. Для большинства компьютерных часов стандартом выбрана частота 32768 Гц, потому что она является степенью двойки и упрощает подсчёт с точностью до одной секунды.
Это как сказать, что настенные часы обычно управляются маятником, и при заведении пружины этот маятник начинает колебаться.
Глаза режет, извините.
Кварцевый резонатор - это и есть тот самый маятник. Сам по себе он никуда не будет колебаться.
Кварцевый генератор - это схема на основе кварцевого резонатора, которая, как раз, и заставляет его колебаться на его резонансной частоте, выдавая эти колебания в виде электрического сигнала наружу, где с ними можно сделать что-нибудь полезное (например, заставить комбинацию счётчиков и драйверов индикаторных ламп показывать время суток, или превратить в электронную мелодию и т.п.)
Бывают, и нередко, изделия, совмещающие генератор с резонатором в одном корпусе.
Частота 32768 выбрана в древних бытовых электронных часах как компромисс между энергопотреблением от батарейки, которое растёт при увеличении частоты, и физическим размером резонатора, который растёт при уменьшении частоты. В современном компьютере не используется. Даже на IBM PC XT системные часы работали от генератора на 1.193182 MHz
Тут намечается классификация разработчиков по ещё одному признаку
Одни способны придумать архитектуру из головы, а потом описать её в коде. Ну, по крайней мере, они говорят, что так могут. Живьём я такого не видел (чтобы архитектура при этом получилась удачная), но стандартные практики менеджмента считают такой сценарий развития желательным
Другим надо потрогать вещи руками, чтобы мысли стали на место. А без этого как-то не получается.
Часто выход для этих вторых в написании прототипов перед написанием настоящих реализаций.
Я тоже вру иногда, что делаю прототип, чтобы от меня отвязались. Но почему-то в конечном итоге прототип и становится финальной реализацией :)
Сначала появляется базовая реализация чего-то. Потом она постепенно расширяется слоями. Стараюсь придерживаться простой архитектуры, не овердизайнить раньше времени. Если в текущей архитектуре становится тесновато, ну, значит, настало времени её порефакторить
Иногда рефактиринг сводится к тому, чтобы по-другому посмотреть на имеющиеся вещи. В таком случае, изменения в коде минимальны, но могут быть переписаны комментарии или переименованы какие-нибудь штуки - обозначая пересмотренное направление развития, в которое то, что уже есть, более-менее аккуратно укладывается, как частный случай
Наконец, хотя этот предмет не из приятных, я должен упомянуть PL/1, язык программирования, документация которого обладает устрашающими размерами и сложностью. Использование PL/1 больше всего напоминает полет на самолете с 7000 кнопок, переключателей и рычагов в кабине. Я совершенно не представляю себе, как мы можем удерживать растущие программы в голове, когда из-за своей полнейшей вычурности язык программирования — наш основной инструмент, не так ли! — ускользает из-под контроля нашего интеллекта. И если мне понадобится описать влияние, которое PL/1 может оказывать на своих пользователей, ближайшее сравнение, которое приходит мне в голову, — это наркотик. Я помню лекцию в защиту PL/1, прочитанную на симпозиуме по языкам программирования высокого уровня человеком, который представился одним из его преданных пользователей. Но после похвал в адрес PL/1 в течение часа он умудрился попросить добавить к нему около пятидесяти новых “возможностей”, не предполагая, что главный источник его проблем кроется в том, что в нем уже и так слишком уж много “возможностей”. Выступающий продемонстрировал все неутешительные признаки пагубной привычки, сводящейся к тому, что он впал в состояние умственного застоя и может теперь только просить еще, еще, еще. Если FORTRAN называют детским расстройством, то PL/1, с его тенденциями роста подобно опасной опухоли, может оказаться смертельной болезнью.
Вот и выросло поколение программистов, для которых написать корректный код, который не вываливается за границы массива - что-то из области научной фантастики…
Это понятно, да. Но возникают сложности, если, к примеру, подписка меняется динамически.
Делать очередь - тоже такое себе. Или она должна быть конечной, и тогда в какой-то момент она всё равно должна начать терять. Или бесконечной, но тогда она может выжрать всю память. Или блокировать отправителя, но есть риск навсегда его заблокировать.
Есть интересный паттерн, я применял его несколько раз в разных проектах.
Представим себе, что есть некоторое состояние, и смысл потока событий уведомить заинтересованных получателей в изменении этого состояния.
Если допустить, что нам достаточно, чтобы состояние с точки зрения отправителя и с точки зрения получателей достаточно, чтобы было eventually consistent, то на стороне отправителя можно хранить его представление о состоянии получателей и присылать только обновления.
Сложность тут растет пропорционально числу подписчиков и нет очереди, которая может переполниться.
Как частный случай, отправитель может просто уведомлять заинтересованные лица, что состояние изменилось, а они могут перечитывать его целиком. Очередь сообщений тут тоже не нужна, нет разницы, сколько таких уведомлений получит получатель, лишь бы последнее получил.
Статья на тему, “как мне продать неведомую хрень, про которую никто не знает, что это такое и зачем оно ему нужно”.
Если бы у меня был работающий рецепт бессмертия, я взял бы в долю санитара из ближайшего хосписа, и через него распространял бы это снадобье среди больных. За умеренные деньги, хотя бы поначалу, чтобы заработать репутацию.
Поэтому вменяемая реализация синхронизации времени не позволит взять, и разом перенести время на год.
При этом всё же непонятно, каким образом это может сломать антивирусы и позволить выполнить вредоносный код
Я про размер самого кристалла, а не корпуса. Размер же корпуса определяется, скорее, удобством монтажа (разумется, кристалл должен помещаться внутри).
У батареешной RTC, да, вполне возможно. Как раз как тот самый компромисс между экономией батарейки и разумным размером резонатора.
Это как сказать, что настенные часы обычно управляются маятником, и при заведении пружины этот маятник начинает колебаться.
Глаза режет, извините.
Кварцевый резонатор - это и есть тот самый маятник. Сам по себе он никуда не будет колебаться.
Кварцевый генератор - это схема на основе кварцевого резонатора, которая, как раз, и заставляет его колебаться на его резонансной частоте, выдавая эти колебания в виде электрического сигнала наружу, где с ними можно сделать что-нибудь полезное (например, заставить комбинацию счётчиков и драйверов индикаторных ламп показывать время суток, или превратить в электронную мелодию и т.п.)
Бывают, и нередко, изделия, совмещающие генератор с резонатором в одном корпусе.
Частота 32768 выбрана в древних бытовых электронных часах как компромисс между энергопотреблением от батарейки, которое растёт при увеличении частоты, и физическим размером резонатора, который растёт при уменьшении частоты. В современном компьютере не используется. Даже на IBM PC XT системные часы работали от генератора на 1.193182 MHz
Тут намечается классификация разработчиков по ещё одному признаку
Одни способны придумать архитектуру из головы, а потом описать её в коде. Ну, по крайней мере, они говорят, что так могут. Живьём я такого не видел (чтобы архитектура при этом получилась удачная), но стандартные практики менеджмента считают такой сценарий развития желательным
Другим надо потрогать вещи руками, чтобы мысли стали на место. А без этого как-то не получается.
Часто выход для этих вторых в написании прототипов перед написанием настоящих реализаций.
Я тоже вру иногда, что делаю прототип, чтобы от меня отвязались. Но почему-то в конечном итоге прототип и становится финальной реализацией :)
Я, обычно, свой код как деревце выращиваю
Сначала появляется базовая реализация чего-то. Потом она постепенно расширяется слоями. Стараюсь придерживаться простой архитектуры, не овердизайнить раньше времени. Если в текущей архитектуре становится тесновато, ну, значит, настало времени её порефакторить
Иногда рефактиринг сводится к тому, чтобы по-другому посмотреть на имеющиеся вещи. В таком случае, изменения в коде минимальны, но могут быть переписаны комментарии или переименованы какие-нибудь штуки - обозначая пересмотренное направление развития, в которое то, что уже есть, более-менее аккуратно укладывается, как частный случай
Я - явный чистолист, но в целом обхожусь постоянным вялотекущим рефакторингом вместо многократного переписывания. В остальном всё сходится.
Отладчиком иногда пользуюсь в качестве калькулятора :)
Может его там надо включить где-то в меню? За братишками вроде не отмечено, чтобы интерфенсы 7/1/4 в принтере были, да не работали…
А если что-то чуть более серьёзное, то внезапно выясняется, что у него система типов сложнее, чем у C++
Угу. Ещё скажите, что Питон - простой язык.
Заглянул из любопытства в ваш проект на гитхабе.
Вижу, принтер поддерживает IPP over USB, IPP, eSCL. Всё это вместе называется Apple Bonjour Printing, он же Apple AirPrint.
Т.е., по идее он должен работать на маке из коробки и без всяких специфических драйверов.
Очень смешно, если не работает. Прошивку обновлять не пробовали?
Я считаю Go прекрасным языком.
И нет, это не мой первый язык, и я отнюдь не новичок в профессии.
Наконец, хотя этот предмет не из приятных, я должен упомянуть PL/1, язык программирования, документация которого обладает устрашающими размерами и сложностью. Использование PL/1 больше всего напоминает полет на самолете с 7000 кнопок, переключателей и рычагов в кабине. Я совершенно не представляю себе, как мы можем удерживать растущие программы в голове, когда из-за своей полнейшей вычурности язык программирования — наш основной инструмент, не так ли! — ускользает из-под контроля нашего интеллекта. И если мне понадобится описать влияние, которое PL/1 может оказывать на своих пользователей, ближайшее сравнение, которое приходит мне в голову, — это наркотик. Я помню лекцию в защиту PL/1, прочитанную на симпозиуме по языкам программирования высокого уровня человеком, который представился одним из его преданных пользователей. Но после похвал в адрес PL/1 в течение часа он умудрился попросить добавить к нему около пятидесяти новых “возможностей”, не предполагая, что главный источник его проблем кроется в том, что в нем уже и так слишком уж много “возможностей”. Выступающий продемонстрировал все неутешительные признаки пагубной привычки, сводящейся к тому, что он впал в состояние умственного застоя и может теперь только просить еще, еще, еще. Если FORTRAN называют детским расстройством, то PL/1, с его тенденциями роста подобно опасной опухоли, может оказаться смертельной болезнью.
Э.Дейкстра, Смиренный программист, 1972
Как известно, у редактора vi есть всего два режима. В одном он пищит, в другом портит текст.
Зачем же сходу отламывать полезный режим?
Вот и выросло поколение программистов, для которых написать корректный код, который не вываливается за границы массива - что-то из области научной фантастики…
Это понятно, да. Но возникают сложности, если, к примеру, подписка меняется динамически.
Делать очередь - тоже такое себе. Или она должна быть конечной, и тогда в какой-то момент она всё равно должна начать терять. Или бесконечной, но тогда она может выжрать всю память. Или блокировать отправителя, но есть риск навсегда его заблокировать.
Есть интересный паттерн, я применял его несколько раз в разных проектах.
Представим себе, что есть некоторое состояние, и смысл потока событий уведомить заинтересованных получателей в изменении этого состояния.
Если допустить, что нам достаточно, чтобы состояние с точки зрения отправителя и с точки зрения получателей достаточно, чтобы было eventually consistent, то на стороне отправителя можно хранить его представление о состоянии получателей и присылать только обновления.
Сложность тут растет пропорционально числу подписчиков и нет очереди, которая может переполниться.
Как частный случай, отправитель может просто уведомлять заинтересованные лица, что состояние изменилось, а они могут перечитывать его целиком. Очередь сообщений тут тоже не нужна, нет разницы, сколько таких уведомлений получит получатель, лишь бы последнее получил.
А ещё то, что поздноподписавшиеся могут пропустить что-то интересное, что случилось до их прихода
В итоге, такая реализация накладывает определенные ограничения на порядок инициализации, вводя неочевидные зависимости.
В системе с большим количеством компонент это может больно стукнуть в какой-то момент
Да действительно, куда уж им. То ли дела RedHat, представитель высшей цивилизации…
P.S. Содержательно, для меня этот вопрос сводится к тому, отдаёт Астра свои правки в апстрим или не отдаёт.
Я не очень понял, а модель обучалась на этих текстах, которые она так ловко сжимает? Или она обучалась на одних текстах, а сжимает другие?