Спасибо большое за статью :) Было интересно прочитать вашу историю :) У меня есть похожие замыслы) Я хотел спросить такой очень практичный вопрос. Из статьи я не понял, а ваша антенна — это спутниковый интеренет или какой-то усилитель сотового сигнала?
На ПХП было бы трудно реализовать валидацию физического смысла на этапе компиляции :) В моей задаче не программисты кодировали вычисления, а юзер вводил выражения. У меня это действительно как калькулятор использовалось. Оттуда же и была необходимость в возможности привести величину к определенному виду (это о футах + дюймах).
Cпасибо за ссылку! Было очень интересно почитать, как оно реализовано в той библиотеке.
У них введено еще понятие системы исчислений, и каждая единица измерений «живет» в своей системе. У меня в калькуляторе этого уровня абстракции нет и получается, что есть лишь 1 одна единственная система. Я еще подсмотрел, как у них реализована конвертация между фаренгейтом-цельсием-кельвином (https://github.com/boostorg/units/blob/develop/include/boost/units/base_units/temperature/conversions.hpp). Тут в другой ветке обсуждают проблему с этой конвертацией, и в Boost библиотеке она тоже не решена и остается на совести того, кто использует код.
Еще одно отличие (и для моей конкретной задачи это было важно) — в той библиотеке нет функционала «сконвертируй 180 см в ___ футов + ___ дюймов». Там это нужно реализовывать в коде собственного приложения.
А почему нельзя? Если мы можем сказать, что объект А теплее чем объект Б. И мы можем сказать, что объект А теплее чем объект Б на 10 градусов Кельвина. То вроде бы у нас есть измеряемая и соотносимая шкала и на такой шкале можно проводить операции умножения.
Я понимаю, что метры из SI и из других стандартов могут отличаться. Но в рамках этого калькулятора я обусловился, что метр он один… будь он из SI или из СГС. А если хочется иметь и тот и другой метр под рукой, то можно ввести дополнительную единицу измерений для этих целей: метр — пускай будет из SI. А метр_СГС — пускай будет «другой метр». Тогда в таблицу декомпозиций добавим информацию о том, как метр_СГС декомпозируется в обыкновенный метр, и дело в шляпе.
А как вы на этих 3х структурах данных посчитаете 10 метров + 3 фута? Ведь вам помимо размерности еще нужно отслежитвать и численно, как метры соотносятся к футам.
Я оставил часть про «искусство» наружу при конвертации результата к какой-то единице измерений. В моей логике существует количество и размерность этого количества. Тогда тот, кто пользуется моим калькулятором сам может сказать к какому виду привести это количество (к В*А или кДж/с, к примеру… или даже кДж/час). Калькулятор в этом плане не накладывает никаких ограничений, а скорее наоборот, оставляет полную свободу тому, кто будет им пользоваться.
Про фаренгейты я вас понял. Но т.к. у нас не просто конвертатор величин, а калькулятор, как тогда быть в следующей ситуации: человек пишет в калькулятор: 10 F * 10 = ?? F. Логично предположить, что он ожидает в ответ 100 F. Но т.к. внутренне калькулятор автоматически приведет температуру к Цельсию, умножит на 10, приведет обратно к Фаренгейтам, то ответ будет другим. И тогда пользователь подумает, что наш калькулятор не работает =) Я не говорю, что такое решение проблемы неправильное. Я пытаюсь показать, какие проблемы оно может повлечь за собой. Хотя решение действительно покрывает большинство сценариев и довольно просто в своей реализации.
Я к сожалению действительно не разбираюсь в этом предмете. Я впервые слышу о варе. Моя логика заключается в том, что если 2 величины имеют одинаковый физический смысл, то они должны иметь одинаковую размерность. И противоположное — если 2 величины имеют разный физический смысл, то их размерности должны отличаться. Иначе в чем смысл размерности? По крайней мере я это так усвоил на уроках школы. И именно на этом строил анализ предметной области.
Про радианы, кажется, это больше похоже на косметический вопрос. Я бы его тогда решал какой-нибудь дополнительной оберткой, которая реализует эту логику «показывать / не показывать» рад.
Ну я уже с треском провалил экзамен по физике судя по вашему предыдущему комментарию, но попробую объяснить свою точку зрения по этим 2 вопросам.
Прежде всего о радианах — цитата из Википедии:
Радиа́н — угол, соответствующий дуге, длина которой равна её радиусу.… Так как величина угла, выраженная в радианах, равна отношению длины дуги окружности (м) к длине её радиуса (м), угол в радианном измерении — величина безразмерная.
Получается, что размерность «рад/с» — это просто 1/с (секунды в минус первой степени). Домножаем на метры и получаем м/с. Получается, что калькулятор это понимает и справится.
По второму пункту. Давайте посчитаем вектор размерности для каждого из 3:
Вт = кг * м2/с3
Вары = Вольт-Ампер (см. ниже) * синус угла (константа) = м2 * кг / с3
Вольт-Ампер = м2 * кг / с3 / A (Вольт) * А = м2 * кг / с3
Размерность у Ватта и Вольт-Ампера одинаковая (и у вара). А почему их нельзя складывать? Если я правильно понимаю суть вопроса, то это как складывать метры и дециметры. Тупо прямой математикой нельзя, т.к. шкалы отличаются, но если их привести к одной шкале, то их можно сложить ведь обе вещи по сути — это дистанция. Калькулятор из этой статьи как раз это и делает — сначала он удостоверится, что размерности не противоречат, а потом посчитает абсолютное кол-во обоих операндов (за счет декомпозиции в базовые измерения) и сложит их. И в этом был смысл создания калькулятора, чтобы он абстрагировал все эти вопросы от человека. В ответе у вас будет 100500 условных мощностей. И потом вы эти 100500 условных мощностей можете сконвертировать обратно либо в Вары либо в Вт либо еще во что-нибудь из разряда мощности.
Таким образом в случае с этим калькулятром вам только нужно объяснить ему как декомпозируются Ватты, Вары и Вольт-Амперы в базовые единицы (кг, м, с). И он уже будет готов для вас посчитать 50 Вт + 10 Вар = ?? Вольт-Ампер
Вот только что проснулся, и в голове как щелкнуло — в этом видео мужик показал куда нагляднее, чем у меня получилось в статье, понятие нескольких вертикальных слоев АПИ (я в статье про это говорил «несколько уровней детализации»).
У него в примере Картахены их было 3 и на его примере было четко видно, что:
каждая из функций, которую он придумал, однозначно относилась к одному из 3х слоев
каждая функция состоит из нескольких строк и активно использует функции на 1 слой ниже.
Спасибо большое за видео! С удовольствием посмотрел.
Я тоже скептически отношусь к многоуровневому наследованию. Интересная логика была описана в видео. Я таким образом еще ни разу не мыслил, но я вижу, что она очень применима, особенно в тех местах, где нет расширяемости за счет дополнительных подключаемых модулей. Ведь с появлением новых дополнительных модулей, они тоже захотят где-то хранить свое состояние. И возможно тогда все состояние уже будет проблематично упаковать в одном единственном месте.
Но идея докладчика мне действительно понравилась :) Спасибо =)
Прежде всего вопросы компетентности программистов и коммуникации внутри команды я оставил за пределами этой статьи.
Полные и абстрактные интерфейсы очень легки в своем понимании. Именно для этого я и привел пример про счетчик использования файла в Линуксе — очень простая для понимания, очень эффективная абстракция. Использовать ее не поназначению будет весьма затруднительным. Большинство правильных (с моей точки зрения) интерфейсов именно так и выглядят — их можно описать 1-2 предложениями и сложно перепутать с каким-то другим интерфейсом, используемым в программе.
Если говорить об этом примере с уведомлениями. То интерфейс большой компоненты будет выглядеть «Уведомить пользователя Х о событии У». Ведь его будет очень сложно спутать с интерфейсом «отправить смс с содержанием Х на номер У». Это 2 очень разные вещи. И мне кажется, что в будущем дополнительно расширять интерфейс что первый что второй уже не будет нужно, они уже полные… т.е. они уже полностью описиывают свою функцию.
Дополнительно, компоненту «отправить смску» можно использовать и для других целей… Допустим, ее можно использовать если что-то упало в инфраструктуре и слать смску сисадмину. Сисадмин не является пользователем системы, поэтому более абстрактная компонента «уведомить пользователя Х о событии У» тут неприменима. Компоненту «отправить имейл с содержанием Х на ящик У» можно еще использовать для отправки каких-то ежедневных отчетов сотрудникам компании.
Я искренне считаю, что эти 2 вещи спутать сложно. И да, их будет проще спутать, когда в каждый из этих интерфейсов еще напихают по полдюжины каких-то флагов/параметров сомнительного смысла и полезности. Для этого я и упомянул в статье, что перегружая интерфейс лишними подробностями мы его делаем менее полными, чем идеально сбалансированный интерфейс.
Хехе, я попытался включить некоторые примеры в статью, она и так получилось слишком длинной, поэтому я не сильно налегал на примеры. Но я могу посоветовать прочитать одну книгу о внутреннем устройстве Юникса. Я ее читал 4 года назад и плакал как ребенок, которому купили вкусную и красивую шоколадку))) Вот эта книга www.amazon.com/Design-UNIX-Operating-System/dp/0132017997
Там именно с архитектурной точки зрения рассматривается устройство ядра. И когда ты читаешь и видишь как сложнейшие задачи, которые должна эффективно и правильно решать ОС, оказывается можно описать и логика предложенных решений выглядит тривиальной, элегантной, то начинаешь восхищаться этой архитектурой. Книга объемистая, и некоторые вещи действительно сложны для понимания, но на меня она произвела неизгладимое впечатление в плане архитектурного мышления. Я бы посоветовал именно эту книгу в качестве примера.
Полностью согласен =) Как раз один проект, который я собственными руками довел до состояния «карточного домика», и завставил меня вообще сесть и почухать репу на тему, как же можно писать сложные системы и при этом сохранять контроль над ситуацией. Ответ получится у меня таким, каким я его описал в этой статье :)
Согласен с вами. Эти «максимизация объектов» и «минимизация связей» не только численно измеряется, но еще и качественно — 4 маленьких интерфейса лучше, чем 2 жирных толстых интерфейса. =)
Про etag согласен. Но как тогда проактивно инвалидировать кеш Nginx'a из Друпала? В схеме, как описано в этой статье, когда какая-то нода изменилась, то Друпал отправит запросы на HTTP proxy о том, что такую-то, такую-то и такую-то страницы (страницы, где эта нода в том или ином виде присутствует), нужно выкинуть из кеша.
Без этой проактивной инвалидации, нам либо сознательно отдавать потенциально устаревший контент либо nginx должен чуть ли не каждый раз перепроверять свой кеш против друпала (сверять etag).
Я посмотрел на вот эту (https://cgit.drupalcode.org/nginx_cache_clear/tree/nginx_cache_clear.module) реализацию под Nginx + Drupal 7, и там довольно топорный метод — удаление файла кеша из файловой системы.
Тестов и графиков нет =) Но у меня не вызывает сомнений, что анонимные страницы будут куда эффективнее обрабатываться Varnish'ом, чем Drupal 8 при включенном кеше анонимных страниц на последнем. Даже если этот кеш в Drupal'е положить в оперативку (Redis,Memcached).
Включение во всю формулу PHP тут же даст свой негативный результат. Concurrency тоже значительно ухудшится, т.к. потребление ОЗУ на 1 обработанный запрос будет значительно выше. У Varnish'а накладные расходы по памяти на обработку 1 запроса минимальные, а у PHP интерпретатора уже будут исчисляться мегабайтами, может быть парой десяток мегабайт памяти на 1 запрос.
Я nginx как прокси кеш еще ни разу не использовал, поэтому практического опыта не имею. В конкретной ситуации, для которой я разбирался с Drupal 8 + Varnish, меня просто попросили посмотреть со словами «вот, что-то сайт тупит» :) И там уже было HAproxy (ssl termination) -> Varnish (proxy caching) -> Apache -> mod_fcgi (php).
Я немног покопался сейчас, и похоже, что по производительности они оба очень похожи. Но на сайте Nginx я нашел следующее (https://www.nginx.com/blog/nginx-caching-guide/):
Does NGINX Support Cache Purging?
NGINX Plus supports selective purging of cached files. This is useful if a file has been updated on the origin server but is still valid in the NGINX Plus cache (the Cache-Control:max-age is still valid and the timeout set by the inactive parameter to the proxy_cache_path directive has not expired). With the cache‑purge feature of NGINX Plus, this file can easily be deleted. For more details, see Purging Content from the Cache.
Получается, что как раз главный конек, на котором построена выборочная инвалидация по кеш тегам, отсутствует в Nginx. Не возмусь со 100% уверенностью сказать, что опен-сорсный nginx дейсвтительно никак не может инвалидировать по заголовкам, но похоже на то.
Я изначально понимал, что пхп предоставляет мало инструментария на эту тему. У меня задача была по-быстрому слепить решение, чтобы ответ моего пхп кода не занимал дольше 1 минуты. Я понимаю, что мое текущее решение обладает большим количеством недочетов, но на данном этапе оно закрывает все мои потребности (ответ получается генерировать приемлимо быстро, по ОЗУ оно масштабируется в рамках приемлимого, и у моего решения нет внешних зависимостей). Вебсайт, на котором это все крутится, находится на этапе прототипа, и я просто не готов был туда писать красивое решение проблемы сразу. Если я в какой-то момент почувствую, что эта часть кода становится узким местом, то я вернусь к нему и тогда уже подойду серьезно к задаче. Хехе, и тогда как раз и последую советам вашим и других людей, которые упоминали технологии и архитектуры (с этой целью я и писал статью — прощупать почву у людей о том, как они бы решали эту проблему).
У них введено еще понятие системы исчислений, и каждая единица измерений «живет» в своей системе. У меня в калькуляторе этого уровня абстракции нет и получается, что есть лишь 1 одна единственная система. Я еще подсмотрел, как у них реализована конвертация между фаренгейтом-цельсием-кельвином (https://github.com/boostorg/units/blob/develop/include/boost/units/base_units/temperature/conversions.hpp). Тут в другой ветке обсуждают проблему с этой конвертацией, и в Boost библиотеке она тоже не решена и остается на совести того, кто использует код.
Еще одно отличие (и для моей конкретной задачи это было важно) — в той библиотеке нет функционала «сконвертируй 180 см в ___ футов + ___ дюймов». Там это нужно реализовывать в коде собственного приложения.
А почему нельзя? Если мы можем сказать, что объект А теплее чем объект Б. И мы можем сказать, что объект А теплее чем объект Б на 10 градусов Кельвина. То вроде бы у нас есть измеряемая и соотносимая шкала и на такой шкале можно проводить операции умножения.
А как вы на этих 3х структурах данных посчитаете 10 метров + 3 фута? Ведь вам помимо размерности еще нужно отслежитвать и численно, как метры соотносятся к футам.
Я оставил часть про «искусство» наружу при конвертации результата к какой-то единице измерений. В моей логике существует количество и размерность этого количества. Тогда тот, кто пользуется моим калькулятором сам может сказать к какому виду привести это количество (к В*А или кДж/с, к примеру… или даже кДж/час). Калькулятор в этом плане не накладывает никаких ограничений, а скорее наоборот, оставляет полную свободу тому, кто будет им пользоваться.
Про фаренгейты я вас понял. Но т.к. у нас не просто конвертатор величин, а калькулятор, как тогда быть в следующей ситуации: человек пишет в калькулятор: 10 F * 10 = ?? F. Логично предположить, что он ожидает в ответ 100 F. Но т.к. внутренне калькулятор автоматически приведет температуру к Цельсию, умножит на 10, приведет обратно к Фаренгейтам, то ответ будет другим. И тогда пользователь подумает, что наш калькулятор не работает =) Я не говорю, что такое решение проблемы неправильное. Я пытаюсь показать, какие проблемы оно может повлечь за собой. Хотя решение действительно покрывает большинство сценариев и довольно просто в своей реализации.
Про радианы, кажется, это больше похоже на косметический вопрос. Я бы его тогда решал какой-нибудь дополнительной оберткой, которая реализует эту логику «показывать / не показывать» рад.
Прежде всего о радианах — цитата из Википедии:
Получается, что размерность «рад/с» — это просто 1/с (секунды в минус первой степени). Домножаем на метры и получаем м/с. Получается, что калькулятор это понимает и справится.
По второму пункту. Давайте посчитаем вектор размерности для каждого из 3:
Вт = кг * м2/с3
Вары = Вольт-Ампер (см. ниже) * синус угла (константа) = м2 * кг / с3
Вольт-Ампер = м2 * кг / с3 / A (Вольт) * А = м2 * кг / с3
Размерность у Ватта и Вольт-Ампера одинаковая (и у вара). А почему их нельзя складывать? Если я правильно понимаю суть вопроса, то это как складывать метры и дециметры. Тупо прямой математикой нельзя, т.к. шкалы отличаются, но если их привести к одной шкале, то их можно сложить ведь обе вещи по сути — это дистанция. Калькулятор из этой статьи как раз это и делает — сначала он удостоверится, что размерности не противоречат, а потом посчитает абсолютное кол-во обоих операндов (за счет декомпозиции в базовые измерения) и сложит их. И в этом был смысл создания калькулятора, чтобы он абстрагировал все эти вопросы от человека. В ответе у вас будет 100500 условных мощностей. И потом вы эти 100500 условных мощностей можете сконвертировать обратно либо в Вары либо в Вт либо еще во что-нибудь из разряда мощности.
Таким образом в случае с этим калькулятром вам только нужно объяснить ему как декомпозируются Ватты, Вары и Вольт-Амперы в базовые единицы (кг, м, с). И он уже будет готов для вас посчитать 50 Вт + 10 Вар = ?? Вольт-Ампер
У него в примере Картахены их было 3 и на его примере было четко видно, что:
Я тоже скептически отношусь к многоуровневому наследованию. Интересная логика была описана в видео. Я таким образом еще ни разу не мыслил, но я вижу, что она очень применима, особенно в тех местах, где нет расширяемости за счет дополнительных подключаемых модулей. Ведь с появлением новых дополнительных модулей, они тоже захотят где-то хранить свое состояние. И возможно тогда все состояние уже будет проблематично упаковать в одном единственном месте.
Но идея докладчика мне действительно понравилась :) Спасибо =)
Прежде всего вопросы компетентности программистов и коммуникации внутри команды я оставил за пределами этой статьи.
Полные и абстрактные интерфейсы очень легки в своем понимании. Именно для этого я и привел пример про счетчик использования файла в Линуксе — очень простая для понимания, очень эффективная абстракция. Использовать ее не поназначению будет весьма затруднительным. Большинство правильных (с моей точки зрения) интерфейсов именно так и выглядят — их можно описать 1-2 предложениями и сложно перепутать с каким-то другим интерфейсом, используемым в программе.
Если говорить об этом примере с уведомлениями. То интерфейс большой компоненты будет выглядеть «Уведомить пользователя Х о событии У». Ведь его будет очень сложно спутать с интерфейсом «отправить смс с содержанием Х на номер У». Это 2 очень разные вещи. И мне кажется, что в будущем дополнительно расширять интерфейс что первый что второй уже не будет нужно, они уже полные… т.е. они уже полностью описиывают свою функцию.
Дополнительно, компоненту «отправить смску» можно использовать и для других целей… Допустим, ее можно использовать если что-то упало в инфраструктуре и слать смску сисадмину. Сисадмин не является пользователем системы, поэтому более абстрактная компонента «уведомить пользователя Х о событии У» тут неприменима. Компоненту «отправить имейл с содержанием Х на ящик У» можно еще использовать для отправки каких-то ежедневных отчетов сотрудникам компании.
Я искренне считаю, что эти 2 вещи спутать сложно. И да, их будет проще спутать, когда в каждый из этих интерфейсов еще напихают по полдюжины каких-то флагов/параметров сомнительного смысла и полезности. Для этого я и упомянул в статье, что перегружая интерфейс лишними подробностями мы его делаем менее полными, чем идеально сбалансированный интерфейс.
Там именно с архитектурной точки зрения рассматривается устройство ядра. И когда ты читаешь и видишь как сложнейшие задачи, которые должна эффективно и правильно решать ОС, оказывается можно описать и логика предложенных решений выглядит тривиальной, элегантной, то начинаешь восхищаться этой архитектурой. Книга объемистая, и некоторые вещи действительно сложны для понимания, но на меня она произвела неизгладимое впечатление в плане архитектурного мышления. Я бы посоветовал именно эту книгу в качестве примера.
Без этой проактивной инвалидации, нам либо сознательно отдавать потенциально устаревший контент либо nginx должен чуть ли не каждый раз перепроверять свой кеш против друпала (сверять etag).
Я посмотрел на вот эту (https://cgit.drupalcode.org/nginx_cache_clear/tree/nginx_cache_clear.module) реализацию под Nginx + Drupal 7, и там довольно топорный метод — удаление файла кеша из файловой системы.
Включение во всю формулу PHP тут же даст свой негативный результат. Concurrency тоже значительно ухудшится, т.к. потребление ОЗУ на 1 обработанный запрос будет значительно выше. У Varnish'а накладные расходы по памяти на обработку 1 запроса минимальные, а у PHP интерпретатора уже будут исчисляться мегабайтами, может быть парой десяток мегабайт памяти на 1 запрос.
Я немног покопался сейчас, и похоже, что по производительности они оба очень похожи. Но на сайте Nginx я нашел следующее (https://www.nginx.com/blog/nginx-caching-guide/):
Получается, что как раз главный конек, на котором построена выборочная инвалидация по кеш тегам, отсутствует в Nginx. Не возмусь со 100% уверенностью сказать, что опен-сорсный nginx дейсвтительно никак не может инвалидировать по заголовкам, но похоже на то.