Огромное спасибо за статью и всем кто прокомментировал по существу. Очень полезно для изучения.
Сам пользуюсь межпотоковыми очередями (вместо объектов синхронизации), при этом количество проблем с отладкой уменьшается на два порядка. Если удастся сделать универсальную и неблокируемую очередь — будет вообще шикарно. Буду изучать материалы.
Честно говоря, предложенный интерфейс чуть лучше, но всё также монструозен для простого пользователя.
Я бы шёл от конечного вида постинга. То есть, после добавления постинг выглядит совершенно определённым образом. Плюс вокруг самого поста есть рюшечки всякие: настроение, музыка и т.п.
Чтобы пользователь не путался, можно изначально выводить некую версию готового постинга «по умолчанию». А по клику на нужный элемент позволял его изменять.
Критиковать просто. Вы напишите свой цикл статей. Если он будет умный, интересный и познавательный — вас будет читать больше народу, чем статьи про классический подход. Ждём статьи!
Автору этой заметки — отдельное спасибо за то что свёл знания в одну статью. Обязательно жду продолжения. Кстати, про прикладные грамматики тоже бы было интересно почитать.
Можно ли вставить в статью конкретные примеры, иллюстрирующие предлагаемую теорию на практике?
Хотелось бы, прежде всего, понять: в чём, кратко, состоит отличие подхода? какие конкретно вопросы решает предлагаемый подход? есть ли показательные случаи, когда предлагаемая теория срабатывает лучше принятых подходов?
Занятия начались за несколько лет до моей утилиты, так что монитор тут нипричём.
Плохое зрение может иметь совершенно разную природу. Скорее всего дело именно в этом.
К сожалению, офтальмология мало говорит о реальной причине падения зрения. Конечно, есть объяснения вроде атрофии нерва, глазного давления и прочего. Но все эти вещи — также следствие, а не причина. Надо искать причину.
Судя по некоторым данным, по крайней мере часть глазных заболеваний имеет в своей основе определённый вид бактерий, который передаётся человеку в утробе, от матери. Грубо говоря, это может быть одной из причин, почему некоторые более восприимчивы к воздействиям, ухудшающим зрение, а кто-то — менее. Как и действие любой бактерии, здесь всё также зависит от иммунитета, общего состояния организма, от психологического состояния. Поэтому, по крайней мере в части случаев для приостановления прогрессирования нарушений зрения нужно оздоравливать сам организм, закаляться, меньше нервничать. Это не панацея, но иногда может иметь очень большое влияние.
Это не стереотип.
После операции организм очень чувствительно относился к качеству потребляемой пищи. Я пил только компот, хороший зелёный чай и кефир (тоже, кстати, не от всех производителей).
Всё остальное вызывало сильную негативную реакцию. Даже негазированная Бон Аква, в которую, видимо, тоже что-то добавляют. Я уже молчу про квасы и лимонады в пластиковых бутылках.
Моя девушка занималась по Жданову — результатов не было.
Я ей даже писал небольшую утилиту для этих целей. 4 минуты — вверх/вниз прямо и по диагонали (1,2,3 пункты), 1 минута — «циферблат» (6,7 пункты).
Вы же сами пишете: «при правильной архитектуре». Синтаксис языка никак эту структуру не обуславливает. Значит, проблема всё-таки есть.
Сформулируем ещё раз: проблема создания правильной архитектуры несинхронных программ: неблокирующих (попроще) и асинхронных (посложнее).
Я был бы признателен, если вы напишете продолжение вашей статьи, где бы подробно описали эту архитектуру и детали её проектирования.
К примеру, для асинхронных программ, мне очень нравится подход Эрланга, который разделяет переменные потоков. Очень нравится система обмена сообщениями через очередь.
Нравится настолько, что переизобрёл велосипед написал на С++ и оптимизировал кроссплатформенный класс потока с асинхронными очередями. Только им и пользуюсь, общие переменные между классами для себя исключил, после чего проблем с многопоточностью на С++ стало на порядок меньше (если это не высокопроизводительный сервер).
Но всё не даётся даром. Через какое-то время я ощутил, что подобный подход требует более серьёзной работы с инвариантами. Их, в отличие от внутренних переменных потока, нельзя изолировать от обработчика, потому что это вектор состояния потока-обработчика, а не вектор потока-инициатора сообщения. Я прихожу ко мнению, что асинхронная очередь сообщений (колбэков), вполне возможно, предполагает стэковую организацию векторов состояний потоков. В общем, это большая тема. И если у вас есть знания и серьёзные наработки в этой области, я бы с огромным интересом почитал вашу статью.
Я привёл довольно «щадящий» пример. Проблема на самом деле гораздо серьёзнее.
Когда пишете любую функцию, подумайте, сколько переменных вы считаете инвариантами.
А теперь представьте, что инвариантов больше нет.
И вам надо (в общем случае) проверять все переменные.
Например, к моменту вызова обработчика может идти шатдаун интерфейса; или идёт фильтрация предыдущих данных. Да всё что угодно может быть.
На мой взгляд, система колбэков — не самая большая проблема неблокирующих вызовов.
Главная проблема — работа с состоянием программы (переменные). Если представить себе программу в виде графа с вершинами-состояниями (она им и является), то обычная синхронная программа описывается более или менее читаемо. На вершинах обычно пишут изменения вектора состояния, предполагая остальные переменные — инвариантами относительно соседних состояний.
А вот когда мы связываемся с неблокирующими вызовами колбэков, это, фактически, может означать что ЛЮБОЙ обработчик может быть вызыван при ЛЮБОМ векторе состояний. Мы, фактически, теряем вообще все инварианты в программе!
Задумайтесь!
Раньше в обработчике вы делали проверку нескольких условий, предполагая, что все остальные вещи будут именно в том виде, как следует (ведь мы гарантируем это в предыдущем коде).
В неблокирующих вызовах инвариантов нет.
Обработчик должен проверять туеву хучу состояний, чтобы удостовериться: да, мыжно выполнить обработку в том или ином виде.
Хотите наглядный пример?
В яваскрипте загружаю набор данных со стороннего сервера. JQuery::json. И всё бы хорошо, но выборку данных формирует пользователь через интерфейс. К тому времени, когда данные придут, пользователь может нащёлкать интерфейс, много чего поменяв в выборке. В обработчике приходится полностью проверять состояние интерфейса и срочно придумывать что из полученной выборки пригодится, если требования пользователя изменились.
И хорошо если интерфейс описывается 2-3 переменными. Когда настроек много, то есть длинный вектор состояний запросов, проверка всего длинного вектора и принятие решение о дополнительной обработке выборки — много дополнительного анализа и работы по его реализации.
А фото — зачётное!
Сам пользуюсь межпотоковыми очередями (вместо объектов синхронизации), при этом количество проблем с отладкой уменьшается на два порядка. Если удастся сделать универсальную и неблокируемую очередь — будет вообще шикарно. Буду изучать материалы.
Я бы шёл от конечного вида постинга. То есть, после добавления постинг выглядит совершенно определённым образом. Плюс вокруг самого поста есть рюшечки всякие: настроение, музыка и т.п.
Чтобы пользователь не путался, можно изначально выводить некую версию готового постинга «по умолчанию». А по клику на нужный элемент позволял его изменять.
Ну и вопрос с циклами перезаписи.
В остальном, совершенно определённо, отличная вещь.
Цена, ясное дело, со временем станет вполне доступная.
Автору этой заметки — отдельное спасибо за то что свёл знания в одну статью. Обязательно жду продолжения. Кстати, про прикладные грамматики тоже бы было интересно почитать.
Хотелось бы, прежде всего, понять: в чём, кратко, состоит отличие подхода? какие конкретно вопросы решает предлагаемый подход? есть ли показательные случаи, когда предлагаемая теория срабатывает лучше принятых подходов?
Где концепция?
Плохое зрение может иметь совершенно разную природу. Скорее всего дело именно в этом.
К сожалению, офтальмология мало говорит о реальной причине падения зрения. Конечно, есть объяснения вроде атрофии нерва, глазного давления и прочего. Но все эти вещи — также следствие, а не причина. Надо искать причину.
Судя по некоторым данным, по крайней мере часть глазных заболеваний имеет в своей основе определённый вид бактерий, который передаётся человеку в утробе, от матери. Грубо говоря, это может быть одной из причин, почему некоторые более восприимчивы к воздействиям, ухудшающим зрение, а кто-то — менее. Как и действие любой бактерии, здесь всё также зависит от иммунитета, общего состояния организма, от психологического состояния. Поэтому, по крайней мере в части случаев для приостановления прогрессирования нарушений зрения нужно оздоравливать сам организм, закаляться, меньше нервничать. Это не панацея, но иногда может иметь очень большое влияние.
После операции организм очень чувствительно относился к качеству потребляемой пищи. Я пил только компот, хороший зелёный чай и кефир (тоже, кстати, не от всех производителей).
Всё остальное вызывало сильную негативную реакцию. Даже негазированная Бон Аква, в которую, видимо, тоже что-то добавляют. Я уже молчу про квасы и лимонады в пластиковых бутылках.
Я ей даже писал небольшую утилиту для этих целей. 4 минуты — вверх/вниз прямо и по диагонали (1,2,3 пункты), 1 минута — «циферблат» (6,7 пункты).
Берите, может кому пригодится и поможет со зрением:
narod.ru/disk/23582900000/EyeTrain.exe.html
Сформулируем ещё раз: проблема создания правильной архитектуры несинхронных программ: неблокирующих (попроще) и асинхронных (посложнее).
Я был бы признателен, если вы напишете продолжение вашей статьи, где бы подробно описали эту архитектуру и детали её проектирования.
К примеру, для асинхронных программ, мне очень нравится подход Эрланга, который разделяет переменные потоков. Очень нравится система обмена сообщениями через очередь.
Нравится настолько, что
переизобрёл велосипеднаписал на С++ и оптимизировал кроссплатформенный класс потока с асинхронными очередями. Только им и пользуюсь, общие переменные между классами для себя исключил, после чего проблем с многопоточностью на С++ стало на порядок меньше (если это не высокопроизводительный сервер).Но всё не даётся даром. Через какое-то время я ощутил, что подобный подход требует более серьёзной работы с инвариантами. Их, в отличие от внутренних переменных потока, нельзя изолировать от обработчика, потому что это вектор состояния потока-обработчика, а не вектор потока-инициатора сообщения. Я прихожу ко мнению, что асинхронная очередь сообщений (колбэков), вполне возможно, предполагает стэковую организацию векторов состояний потоков. В общем, это большая тема. И если у вас есть знания и серьёзные наработки в этой области, я бы с огромным интересом почитал вашу статью.
Когда пишете любую функцию, подумайте, сколько переменных вы считаете инвариантами.
А теперь представьте, что инвариантов больше нет.
И вам надо (в общем случае) проверять все переменные.
Например, к моменту вызова обработчика может идти шатдаун интерфейса; или идёт фильтрация предыдущих данных. Да всё что угодно может быть.
Главная проблема — работа с состоянием программы (переменные). Если представить себе программу в виде графа с вершинами-состояниями (она им и является), то обычная синхронная программа описывается более или менее читаемо. На вершинах обычно пишут изменения вектора состояния, предполагая остальные переменные — инвариантами относительно соседних состояний.
А вот когда мы связываемся с неблокирующими вызовами колбэков, это, фактически, может означать что ЛЮБОЙ обработчик может быть вызыван при ЛЮБОМ векторе состояний. Мы, фактически, теряем вообще все инварианты в программе!
Задумайтесь!
Раньше в обработчике вы делали проверку нескольких условий, предполагая, что все остальные вещи будут именно в том виде, как следует (ведь мы гарантируем это в предыдущем коде).
В неблокирующих вызовах инвариантов нет.
Обработчик должен проверять туеву хучу состояний, чтобы удостовериться: да, мыжно выполнить обработку в том или ином виде.
Хотите наглядный пример?
В яваскрипте загружаю набор данных со стороннего сервера. JQuery::json. И всё бы хорошо, но выборку данных формирует пользователь через интерфейс. К тому времени, когда данные придут, пользователь может нащёлкать интерфейс, много чего поменяв в выборке. В обработчике приходится полностью проверять состояние интерфейса и срочно придумывать что из полученной выборки пригодится, если требования пользователя изменились.
И хорошо если интерфейс описывается 2-3 переменными. Когда настроек много, то есть длинный вектор состояний запросов, проверка всего длинного вектора и принятие решение о дополнительной обработке выборки — много дополнительного анализа и работы по его реализации.