фокус в том что любую программу можно рассматривать как автомат. У нее тоже есть состояния, есть переходы межды ними.
Вот только написана она не с использованием автоматного подхода, поэтому возникают неучтённые комбинации параметров и состояний, и всё глючит.
Ну во первых уберите всю эту воду про сдвиговые регистры, экономию тактов и байт памяти. Всё что касается реализации алгоритма уберите из статьи. Я понимаю что это выстраданные долгими ночными часами знания, которыми хочется поделиться. Но в рамках статьи оно все абсолютно неважно и даже вредно.
Во вторых, сам пример для статьи лучше бы взять попроще. Тот который вы рассмотрели конечно удачен в плане того что тут автомат в автомате в автомате и в автомате. Но опять таки… повышать сложность нужно постепенно. Вам может и не заметно, потому что вы уже прекрасно разбираетесь в теме. Но со стороны ты только вроде что-то начинаешь понимать, и тут всё опять усложняется.
Начните с одного автомата. С проектирования его операционной части, затем управляющей.
Потом покажите как этим автоматом может пользоваться другой автомат. И так далее.
При этом сама реализация в коде не нужна. Достаточно будет диаграммы состояний.
А про реализацию в коде отдельную статью сделайте лучше. Где уже разбираются приемы при помощи которых диаграмма воплощается в код.
Очень хорошая и полезная тема в целом. Автору спасибо за труд, НО… большое но…
Я считаю что статью нужно переписать.
Почему?
Вы очень быстро перешли от общего к частному, ко всем этим битовым сдвигам. Честно говоря — от этого голова болит. Вроде как хочешь почитать про FSA, а приходится следить за мыслью, что мы там делаем на битовом уровне.
Это все равно что я буду писать статью про устройство map-reduce системы, но где-то после 1/3 статьи перейду к подробностям оптимизации обмена с диском на некоторых файловых системах с учетом древних косяков API ядра под OpenBSD :) И остальные 2/3 статьи будут об этом, с примерами кода и т.п.
А хотелось бы в целом законченную статью про автоматы. С примером разработки автомата. Структурными схемами, и схемой работы каждого автомата.
Ну и краткое рассмотрение реализации автомата. Какие для этого есть библиотеки, подходы, методы. Хотя наверное это лучше в отдельной статье бы.
Да-да-да… статья «блаблабла». Правильная по сути, но нереальная по применению. Только где-то в идеальном мире, где СХД значит СХД, а не винт на единственном сервачке, а начальник ИТ-отдела реально может что-то возразить руководству возможна ситуация подобная описанной.
Все что здесь описано будет применяться лишь в одной ситуации — если руководство реально распознает нужды ИТ-отдела как собственные нужды предприятия. У меня может не самый широкий опыт работы на разных фирмах, но на тех 5-6 где я успел поработать ИТ-шники были «о… вшими козлами», на финансирование которых сжигаются нереальные бабки… это с точки зрения руководства. Сколько раз мне тыкали тем, что «да зарплаты у вас больше чем у конструкторов, а они хотя бы производят что-то!», или «ваш бюджет больше чем суммарный бюджет бухгалтерии, маркетинга и еще пары отделов».
Руководству не интересно что места нет на СХД — «не е… е мозг, и сделайте чтобы всё работало, иначе завтра будете без премии». И вот админы уже удаляют файло юзеров, которые просто террабайтами засирают общие хранилища музыкой, фотками, фильмами и прочей лабудой", настраивают квоты, и режут права чтобы кто попало куда попало не кидал. Почта ограничивается в объеме, потому что «отправить ролик на 500мбайт по емылу? а что в этом такого?». Ну и что что весь почтовый обмен на час лёг, мне надо!
Каждому из отдела открыть онлайн-трансляцию матча? Ну почему бы и нет… наши ж играют! Да пох что от пропускной способности канала не хватает на работу подключающихся через удаленные терминалы.
Неее… в какой-то другой галактике. Но не у нас. Хоть я в целом и согласен с посылами автора о причинах того, почему нельяз ограничивать юзеров в правах, но выводы неправильные. Сегодня ты мудак у директора потому что юзеры жалуются что все ваши ограничения мешают им работать, а завтра ты мудак, потому что принёс счёт на 6 миллионов на новую СХД-шку.
ЗЫ мы как-то хотели доброе дело сделать, принудительно сменить всем пароли с 1 на более-сложные. настроили политику, всех предупредили, распечатали памятки как подбирать пароли. И что вы думаете? Идея прожила ровно полдня. Потом к нам ворвался директор и обложил всех трёхэтажным матом, мол нахрена вы тут воду мутите и мешаете людям работать, Слышать ничего не хочу, верните все как было.
Какая-то чушь. Автор как будто просто хотел попиариться, типа «а я вот не такой как все. смотрите, у меня всё хорошо в жизни — беговая дорожка, пляж и 4к монитор». Честно говоря, когда у меня на работе появился 2й монитор, то через некоторое время главной мыслью было — Чёрт, как же удобно. Хочу третий! А когда стало три, стал подумывать о 4-рёх. Для сисадминства — очень удобно. Особенно если ты вин-админ, и у тебя куча подключений к терминалам. Да и с моим линух-админством очень даже. Тут статья, там логи бегут, тут ты команды отдаешь. Там сбоку чятик по работе, чтобы не отвлекал.
Может один 4К монитор и может заменить 2 по 1080. Но уж 4-5 он никак не заменит.
У меня в ноуте щас FullHD. И мне неудобно. Слишком мелко. А делать покрупнее шрифт, значки и окна — жаба душит. Размер экрана то небольшой.
Короче моё резюме таково: ставьте 2-3 4К монитора — и будет счастье. Ну и неплохо бы, конечно беговую дорожку, и всё это с видом на океан. Да…
В связи с этой темой (особенно ОГАС), для любителей ностальгии, нельзя не упомянуть техно-оперу Виктора Аргонова «2032: Легенда о несбывшемся грядущем».
Там вами и ОГАС (под именем АСГУ), и кибернетический коммунизм. И грустный финал, как ни странно.
Ну вот я добрался до реализации когда, пришлось городить менеджмент очереди, с проверкой количества попыток, и отложенным запуском.
Имхо это всё же не должно быть в коде задания. Это дело очереди, заниматься его запуском, и всему к этому относящемся. Ну да, возможно придется сделать несколько разных типов очередей, который по разному себя ведут при невыполнении задания. Но все же по моему так логичнее.
Потому что сейчас получается что если я сделаю queue/listen у меня будет запускаться задание по миллиону раз в секунду, и тут же выходить, потому что таймаут очередной попытки его выполнения не прошел ещё.
А если запускать гранулярно через крон и queue/run то сложно будет подобрать интервал запуска, не слишком частый и не слишком редкий.
Разве что делать по собственной очереди на каждый тип заданий.
Я может непонятливый, потому что новайс. Но не понял как у Журавлёва сделать чтобы в случае если задание не отработало нормально, оно не удалилось из очереди. Вот у этого Urbanindo можно явно вернуть false из метода — и всё.
Фуф. Че-то Хром постепенно из браузера для Гиков, богатого на возможности превращается в этакий Сафари — где и настроек то нету толком.
Видимо очередной повод мигрировать на Мозиллу.
Вообще-то тут две разных концепции построения приложения.
На NodeJS приложение постоянно живёт. Единожды загрузившись, инициализировав фреймворк, все коннекты, подгрузив кэши — оно просто перемалывает запросы.
А PHP вынужден на каждый запрос создавать кучу соединений, подгружать кучу ресурсов (ОК, даже если они уже в виде готового кода лежат в кэше, а кэш в памяти — все равно это все инициализируется заново).
«Позвольте оставить здесь свое боа?! Боаааааа!».
Всё что я могу сказать про Битрикс.
Скажем так… писать что-то хорошее, быстрое и безглючное на нём могут лишь опытные и очень грамотные программисты. При этом никаких преимуществ им использование именно Битрикса не даёт. Они на любом другом фреймворке/CMS смогут даже лучше и быстрее.
А вот написать говнокода, который будет тормозить и глючить может любой новичок. И именно Битрикс ему это не то что позволяет, но даже потворствует.
Извольте наше готовое решение в нашей парадигме! Урааа!!! Я сделалъ! Быстро, элегантно, красиво, логично. А потом база товаров разрастается до 10000 позиций, на сайт приходит 1000 посетителей одновременно и вся эта красота и логичность лежит.
И потом начинается выкидывание всего Битриксового, и писание прямых запросов в БД, рендер средствами ПХП и так далее.
Это лучшее, что я читал на хабре за последние полгода :)
Старые добрые разбирательства с Линухом. Как же я за ними скучаю… с момента когда подбирал параметры модлайна для своего безвестного CRT-монитора, и когда пытался заставить работать winmodem… Или скролл у мышки. Эх…
«Привет, Перл» :)
Научите Перл компиляться в JVM и все остальное станет просто не нужно )))
Синтаксического сахара в нём просто целая коробка рафинада )
Подскажите пожалуйста ссылочку, на платку, которая у вас питает макетку.
У меня сейчас это основная головная боль — приделать к макету вменяемое питание.
Он глядел и глядел на эту кривую. Потом, судорожно сжав в руках график и не отрывая от него глаз, вскочил на ноги. Остальные листки полетели на пол.
– Майк! Майк! – Он тряс Донована за плечо. – Он удержал луч!
Донован очнулся.
– Что? Где?
Потом и он, вытаращив глаза, уставился на график.
– Ты удержал его в фокусе! – заикаясь, сказал Пауэлл. – Ты это знаешь?
– В фокусе? А что это такое?
– Луч был все время направлен на приемную станцию с точностью до одной десятитысячной миллисекунды!
– На какую приемную станцию?
– На Земле! Приемную станцию на Земле, – ликовал Пауэлл. – Ты удержал его в фокусе!
Кьюти раздраженно отвернулся.
– С вами нельзя по-хорошему разговаривать. Снова тот же бред! Я просто удержал все стрелки в положении равновесия – такова была воля Господина.
Собрав разбросанные графики, он сердито вышел. Как только дверь за ним закрылась, Донован произнес:
– Вот это да!
Он повернулся к Пауэллу.
– Что же нам теперь делать?
Пауэлл чувствовал одновременно усталость и душевный подъем.
– А ничего. Он доказал, что может блестяще управлять станцией. Я еще не видел, чтобы электронная буря кончилась так благополучно.
– Но ведь ничего не изменилось! Ты слышал, что он сказал о Господине? Мы же не можем…
– Послушай, Майк! Он выполняет волю Господина, которую читает на циферблатах и в графиках. Но ведь и мы делаем то же самое! В конце концов это объясняет и его отказ повиноваться нам. Повиновение – Второй Закон. Первый же – беречь людей от беды. Как он мог спасти людей, сознательно или бессознательно? Конечно, удерживая луч в фокусе! Он знает, что способен сделать это лучше, чем мы. Недаром он настаивает на том, что является высшим существом! И выходит, что он не должен и подпускать нас к рубке. Это неизбежно следует из Законов Роботехники.
– Конечно, но дело не в этом. Нельзя же, чтобы он продолжал нести свою чепуху про Господина.
– А почему бы и нет?
– Потому, что это неслыханно! Как можно доверить ему станцию, если он не верит в существование Земли?
– Он справляется с работой?
– Да, но…
– Так пусть себе верит во что ему вздумается! Пауэлл слабо улыбнулся, развел руками и упал на постель. Он уже спал.
Я конечно извинаюсь. А что потом делать с этим дампом? Как его экстренно вернуть на сервер? Где взять на серваке столько места, чтобы во время отправки дампа, оно не кончилось ни в одном из разделов диска?
ЗЫ самый маленький дамп у меня в хозяйстве сейчас — 36Гбайт. Он только отправляться по почте будет пару часов. При этом ещё и положит исходящий канал.
Короче статья если и подходит кому -то, то скорее для бэкапа своих мелких сайтиков, форумов и бложиков.
Вот только написана она не с использованием автоматного подхода, поэтому возникают неучтённые комбинации параметров и состояний, и всё глючит.
Во вторых, сам пример для статьи лучше бы взять попроще. Тот который вы рассмотрели конечно удачен в плане того что тут автомат в автомате в автомате и в автомате. Но опять таки… повышать сложность нужно постепенно. Вам может и не заметно, потому что вы уже прекрасно разбираетесь в теме. Но со стороны ты только вроде что-то начинаешь понимать, и тут всё опять усложняется.
Начните с одного автомата. С проектирования его операционной части, затем управляющей.
Потом покажите как этим автоматом может пользоваться другой автомат. И так далее.
При этом сама реализация в коде не нужна. Достаточно будет диаграммы состояний.
А про реализацию в коде отдельную статью сделайте лучше. Где уже разбираются приемы при помощи которых диаграмма воплощается в код.
Я считаю что статью нужно переписать.
Почему?
Вы очень быстро перешли от общего к частному, ко всем этим битовым сдвигам. Честно говоря — от этого голова болит. Вроде как хочешь почитать про FSA, а приходится следить за мыслью, что мы там делаем на битовом уровне.
Это все равно что я буду писать статью про устройство map-reduce системы, но где-то после 1/3 статьи перейду к подробностям оптимизации обмена с диском на некоторых файловых системах с учетом древних косяков API ядра под OpenBSD :) И остальные 2/3 статьи будут об этом, с примерами кода и т.п.
А хотелось бы в целом законченную статью про автоматы. С примером разработки автомата. Структурными схемами, и схемой работы каждого автомата.
Ну и краткое рассмотрение реализации автомата. Какие для этого есть библиотеки, подходы, методы. Хотя наверное это лучше в отдельной статье бы.
Все что здесь описано будет применяться лишь в одной ситуации — если руководство реально распознает нужды ИТ-отдела как собственные нужды предприятия. У меня может не самый широкий опыт работы на разных фирмах, но на тех 5-6 где я успел поработать ИТ-шники были «о… вшими козлами», на финансирование которых сжигаются нереальные бабки… это с точки зрения руководства. Сколько раз мне тыкали тем, что «да зарплаты у вас больше чем у конструкторов, а они хотя бы производят что-то!», или «ваш бюджет больше чем суммарный бюджет бухгалтерии, маркетинга и еще пары отделов».
Руководству не интересно что места нет на СХД — «не е… е мозг, и сделайте чтобы всё работало, иначе завтра будете без премии». И вот админы уже удаляют файло юзеров, которые просто террабайтами засирают общие хранилища музыкой, фотками, фильмами и прочей лабудой", настраивают квоты, и режут права чтобы кто попало куда попало не кидал. Почта ограничивается в объеме, потому что «отправить ролик на 500мбайт по емылу? а что в этом такого?». Ну и что что весь почтовый обмен на час лёг, мне надо!
Каждому из отдела открыть онлайн-трансляцию матча? Ну почему бы и нет… наши ж играют! Да пох что от пропускной способности канала не хватает на работу подключающихся через удаленные терминалы.
Неее… в какой-то другой галактике. Но не у нас. Хоть я в целом и согласен с посылами автора о причинах того, почему нельяз ограничивать юзеров в правах, но выводы неправильные. Сегодня ты мудак у директора потому что юзеры жалуются что все ваши ограничения мешают им работать, а завтра ты мудак, потому что принёс счёт на 6 миллионов на новую СХД-шку.
ЗЫ мы как-то хотели доброе дело сделать, принудительно сменить всем пароли с 1 на более-сложные. настроили политику, всех предупредили, распечатали памятки как подбирать пароли. И что вы думаете? Идея прожила ровно полдня. Потом к нам ворвался директор и обложил всех трёхэтажным матом, мол нахрена вы тут воду мутите и мешаете людям работать, Слышать ничего не хочу, верните все как было.
Такие вот дела.
Может один 4К монитор и может заменить 2 по 1080. Но уж 4-5 он никак не заменит.
У меня в ноуте щас FullHD. И мне неудобно. Слишком мелко. А делать покрупнее шрифт, значки и окна — жаба душит. Размер экрана то небольшой.
Короче моё резюме таково: ставьте 2-3 4К монитора — и будет счастье. Ну и неплохо бы, конечно беговую дорожку, и всё это с видом на океан. Да…
Там вами и ОГАС (под именем АСГУ), и кибернетический коммунизм. И грустный финал, как ни странно.
Имхо это всё же не должно быть в коде задания. Это дело очереди, заниматься его запуском, и всему к этому относящемся. Ну да, возможно придется сделать несколько разных типов очередей, который по разному себя ведут при невыполнении задания. Но все же по моему так логичнее.
Потому что сейчас получается что если я сделаю queue/listen у меня будет запускаться задание по миллиону раз в секунду, и тут же выходить, потому что таймаут очередной попытки его выполнения не прошел ещё.
А если запускать гранулярно через крон и queue/run то сложно будет подобрать интервал запуска, не слишком частый и не слишком редкий.
Разве что делать по собственной очереди на каждый тип заданий.
Мне гораздо больше понравилось.
Ещё бы глянуть примеры реальных реализаций где-нибудь.
Видимо очередной повод мигрировать на Мозиллу.
На NodeJS приложение постоянно живёт. Единожды загрузившись, инициализировав фреймворк, все коннекты, подгрузив кэши — оно просто перемалывает запросы.
А PHP вынужден на каждый запрос создавать кучу соединений, подгружать кучу ресурсов (ОК, даже если они уже в виде готового кода лежат в кэше, а кэш в памяти — все равно это все инициализируется заново).
Немного нечестно такое сравнивать в лоб.
Всё что я могу сказать про Битрикс.
Скажем так… писать что-то хорошее, быстрое и безглючное на нём могут лишь опытные и очень грамотные программисты. При этом никаких преимуществ им использование именно Битрикса не даёт. Они на любом другом фреймворке/CMS смогут даже лучше и быстрее.
А вот написать говнокода, который будет тормозить и глючить может любой новичок. И именно Битрикс ему это не то что позволяет, но даже потворствует.
Извольте наше готовое решение в нашей парадигме! Урааа!!! Я сделалъ! Быстро, элегантно, красиво, логично. А потом база товаров разрастается до 10000 позиций, на сайт приходит 1000 посетителей одновременно и вся эта красота и логичность лежит.
И потом начинается выкидывание всего Битриксового, и писание прямых запросов в БД, рендер средствами ПХП и так далее.
«Боаааа!»
Старые добрые разбирательства с Линухом. Как же я за ними скучаю… с момента когда подбирал параметры модлайна для своего безвестного CRT-монитора, и когда пытался заставить работать winmodem… Или скролл у мышки. Эх…
Научите Перл компиляться в JVM и все остальное станет просто не нужно )))
Синтаксического сахара в нём просто целая коробка рафинада )
У меня сейчас это основная головная боль — приделать к макету вменяемое питание.
А. Азимов «Логика»
ЗЫ самый маленький дамп у меня в хозяйстве сейчас — 36Гбайт. Он только отправляться по почте будет пару часов. При этом ещё и положит исходящий канал.
Короче статья если и подходит кому -то, то скорее для бэкапа своих мелких сайтиков, форумов и бложиков.