Парсеры на регулярках будут работать безумно (по нашим понятиям) долго.
Это если все целиком засасывать. А если сначала добраться до полей простым парсингом хорошо структурированного XML, а потом, на основе предварительно собранной (у вас же богатая ретроспектива?) статистики значений именно этого поля, причем, возможно даже в разных списках/источниках продумать регулярки и нормализаторы (ну, банально, мусор, пробелы убрать, регистр подправить,...), то выцеплять данные быстро должно. А если еще словари какие-то прицепить, ну, типа эээ... "радужных таблиц" для быстрого сопоставления данных чему-то уже ранее нормализованному, то должно быстро работать.
Впрочем, тут надо полностью контекст решения задачи и состав данных знать, может в вашей задаче это вообще не подходит.
У меня на сотнях неструктурированных таблиц до полумиллиарда записей - нормально работает. :)))
Мда, это адский ад. Странно, что, вроде бы, "официальные источники" не нормируют свои списки.
Похожую задачу я делал с использованием MongoDB, не настолько мудрено, чтобы там сохранять логи и историю (нет нужды просто). А для внесения и считывания данных у меня реализованы парсеры, которые на основе регулярных выражений определяют заполненность полей и всякие там ненормальности.
В некоторых случаях, это эффективнее работает, чем нормирование исходных данных перед загрузкой.
Это когда заказчик не выкатывает сразу большую логику, раздробить которую при всем желании не получится.
Эх, а я вот как раз этим 10+ лет занимаюсь... Картинки (мне) помогают. Собственно и статья то была отчасти про это. Про способы наглядно представить нечто труднодробимое. Ну да ладно, спасибо за комментарии!
В понятийном аппарате PMI, документу BRD соответствует Паспорт проекта. Он логичный, содержательный, но... опять таки - сложноватый и весьма формальный.
На подобные документы, такова жизнь, забивают болт... Особенно в цейтноте.
Ну, тут есть отличие в том, что речь идет не только о программном коде. И акцент идет, действительно, в большей степени на "администрацию". Для исполнителя, если речь вести только о программном коде, конечно есть другие варианты представления требований.
Можно и просто их оформить, сформулировать, и сложно. Use Case, User Stories, просто постановка задач на разработку функций "на вход то-то, на выходе то-то". Разные варианты.
По графическому представлению - Use Case (опять таки по мне) - рулит!
Ну, во первых, не хотелось отказываться от встроенного по умолчанию в систему идентификатора. Во-вторых - понимание приходит с опытом, изначально не было задачи осуществлять подобные выборки и накопилось большое количество баз. Переиндексировать их - можно, конечно, но мне показалось, что поиск алгоритма - хорошее решение, которое потребует меньше затрат ресурсов.
По поводу альтернатив - у меня было желание, чтобы СУБД была совместима с системой аналитики Knime. А в Knime, кроме Mongo - мало альтернатив... PostgreSQL - ну, она, как бы реляционная, не совсем подходит для слабоструктурированных данных.
"When the Access-Challenge packet sent by the RADIUS server contains EAP information longer than 1200 bytes, the terminal may fail to receive the EAP Request/Challenge packet. In this case, you can run this command to set attribute-name to Framed-Mtu and reduce the value of the Frame-Mtu attribute in the authentication request packet sent by the device to the RADIUS server. The default value of the Frame-Mtu attribute is 1500. You can change it to 1000."
В принципе, строгая форма КД мне периодически сама по себе кажется устаревшей. Правила должны быть, но более компактные.
В свое время, давно, работал с финскими документами - это было аж в 2000 году при строительстве Ледового дворца спорта. И у них тоже есть шапки всякие, форматы, надписи - но как то они существенно проще.
А если учесть, что по существу большая часть полей форм не используется, а правила досконально знают только "зубры" нормоконтроля - то все эти штуки становятся просто гирей, которые отнимают время...
С компасом работал. Я даже писал об этом, кажется, в предыдущей статье. Но в нем задача формирования КД строго прошита. Симпатично прошита, но строго - ни шагу в сторону (по крайней мере так было в тех версиях, где я работал).
Здесь же я описываю подход к автоматизации комплекса офисных документов (любых) где есть VBA. Который очень удобен для выполнения связки их между собой без необходимости привлечения квалифицированных программистов.
А Компас - да, хорош. Он мне больше, чем Автокад нравится.
Что железные контроллеры отмирают и решения по централизованному управлению начинают интегрироваться в сами точки или виртуализироваться.
С учетом этого, правильнее (на мой взгляд) говорить об актуальности централизованно управляемых сетей, или о самоорганизующихся сетях (типа MESH) - но не о сетях на базе контроллеров. Контроллеры - это баян и неадекватно дорогой баян. :))))
Я в свое время делал сеть на основе миниконтроллеров Cisco (кстати, прекрасно работала и, наверное, до сих пор работает - не знаю). Так вот эти контроллеры уже тогда (где то в 2014 году) стали EoL. А аналоги - это что-то интегрируемое в шасси Cisco или решение на очень большое количество точек, корпоративное до невозможности.
По моему опыту, RACI полезен при составлении должностных инструкций.
Без привязки к проектам - можно наглядно изобразить кто и за что в принципе отвечает в процессе работы, как информация взаимно передается. Особенно это актуально для случаев, когда отделы никак на словах не могут договориться или регулярно спорят кто кому что должен. К сожалению, такое часто встречается.
Кстати, для перфекционистов есть еще такой вариант, как матрица "РАЗУ" (разделения административных задач управления). Там вообще гипертрофированное разделение ответственности между участниками.
PMI - Институт управления проектами, у него до чертиков методологий и PMBoK "Книга знаний по управлению проектами" - это только один сборник.
Есть отдельные книжки у них про сбор требований, про управление рисками, про управление ресурсами, про планирование - я их имел в виду.
Если зарегистрироваться на сайте у них, там взнос какой-то был, и иметь действующую сертификацию PMP - то там большая библиотека будет доступна.
Но это все не тема данной статьи...
Уникальны - это значит никакой другой тип нейронной сети не может обрабатывать перечисленные типы данных. Очевидно, что это не так.
А для сверточных сетей контекст неважен и они так себе, посредственные? Свертка то на контексте вообще основана, разве нет?
Ну и т.п. Очень много натяжек...
Весьма грамотный подход, надо бы мне тоже в своей системе попробовать распараллеливание.
Жесть, согласен. :)
Это если все целиком засасывать. А если сначала добраться до полей простым парсингом хорошо структурированного XML, а потом, на основе предварительно собранной (у вас же богатая ретроспектива?) статистики значений именно этого поля, причем, возможно даже в разных списках/источниках продумать регулярки и нормализаторы (ну, банально, мусор, пробелы убрать, регистр подправить,...), то выцеплять данные быстро должно. А если еще словари какие-то прицепить, ну, типа эээ... "радужных таблиц" для быстрого сопоставления данных чему-то уже ранее нормализованному, то должно быстро работать.
Впрочем, тут надо полностью контекст решения задачи и состав данных знать, может в вашей задаче это вообще не подходит.
У меня на сотнях неструктурированных таблиц до полумиллиарда записей - нормально работает. :)))
Мда, это адский ад. Странно, что, вроде бы, "официальные источники" не нормируют свои списки.
Похожую задачу я делал с использованием MongoDB, не настолько мудрено, чтобы там сохранять логи и историю (нет нужды просто). А для внесения и считывания данных у меня реализованы парсеры, которые на основе регулярных выражений определяют заполненность полей и всякие там ненормальности.
В некоторых случаях, это эффективнее работает, чем нормирование исходных данных перед загрузкой.
И это на пять списков? Ничего себе...
PostgreSQL используете?
Эх, а я вот как раз этим 10+ лет занимаюсь... Картинки (мне) помогают. Собственно и статья то была отчасти про это. Про способы наглядно представить нечто труднодробимое. Ну да ладно, спасибо за комментарии!
Паспорт - комплексный документ, там есть и стейкхолдеры, и риски, и цели, и ключевые бизнес требования. Естественно, он не точно соответствует BRD.
Мне кажется, это классический коммент теоретика, который не сталкивался с реальной реализацией сложных проектов, но книжки читал!
С этим согласен - на разных уровнях - разные представления.
Да, ок.
В понятийном аппарате PMI, документу BRD соответствует Паспорт проекта. Он логичный, содержательный, но... опять таки - сложноватый и весьма формальный.
На подобные документы, такова жизнь, забивают болт... Особенно в цейтноте.
Как говорил один серьезный Заказчик, "Для того, чтобы что-то упростить - надо сначала это усложнить!"
Именно, и тот, который он ожидал. При этом важно понять даже невнятное изложение требований - мои рассуждения в статье больше о том, как понять такие.
Ну, тут есть отличие в том, что речь идет не только о программном коде. И акцент идет, действительно, в большей степени на "администрацию". Для исполнителя, если речь вести только о программном коде, конечно есть другие варианты представления требований.
Можно и просто их оформить, сформулировать, и сложно. Use Case, User Stories, просто постановка задач на разработку функций "на вход то-то, на выходе то-то". Разные варианты.
По графическому представлению - Use Case (опять таки по мне) - рулит!
Ну, во первых, не хотелось отказываться от встроенного по умолчанию в систему идентификатора. Во-вторых - понимание приходит с опытом, изначально не было задачи осуществлять подобные выборки и накопилось большое количество баз. Переиндексировать их - можно, конечно, но мне показалось, что поиск алгоритма - хорошее решение, которое потребует меньше затрат ресурсов.
По поводу альтернатив - у меня было желание, чтобы СУБД была совместима с системой аналитики Knime. А в Knime, кроме Mongo - мало альтернатив... PostgreSQL - ну, она, как бы реляционная, не совсем подходит для слабоструктурированных данных.
Согласно документации на хуавей -
"When the Access-Challenge packet sent by the RADIUS server contains EAP information longer than 1200 bytes, the terminal may fail to receive the EAP Request/Challenge packet. In this case, you can run this command to set attribute-name to Framed-Mtu and reduce the value of the Frame-Mtu attribute in the authentication request packet sent by the device to the RADIUS server. The default value of the Frame-Mtu attribute is 1500. You can change it to 1000."
Т.е. вряд ли проблема в слабом сигнале Wi-Fi.
В принципе, строгая форма КД мне периодически сама по себе кажется устаревшей. Правила должны быть, но более компактные.
В свое время, давно, работал с финскими документами - это было аж в 2000 году при строительстве Ледового дворца спорта. И у них тоже есть шапки всякие, форматы, надписи - но как то они существенно проще.
А если учесть, что по существу большая часть полей форм не используется, а правила досконально знают только "зубры" нормоконтроля - то все эти штуки становятся просто гирей, которые отнимают время...
С компасом работал. Я даже писал об этом, кажется, в предыдущей статье. Но в нем задача формирования КД строго прошита. Симпатично прошита, но строго - ни шагу в сторону (по крайней мере так было в тех версиях, где я работал).
Здесь же я описываю подход к автоматизации комплекса офисных документов (любых) где есть VBA. Который очень удобен для выполнения связки их между собой без необходимости привлечения квалифицированных программистов.
А Компас - да, хорош. Он мне больше, чем Автокад нравится.
А они начинают делать тоже самое из вредности и получается хреновая ситуация...
Насколько я помню, единственный вариант избежать такой ситуации - это авторизация менджмент-фреймов. И тоже, Cisco его продвигала, стандарт 802.11w.
Я это и имел в виду, ага.
Что железные контроллеры отмирают и решения по централизованному управлению начинают интегрироваться в сами точки или виртуализироваться.
С учетом этого, правильнее (на мой взгляд) говорить об актуальности централизованно управляемых сетей, или о самоорганизующихся сетях (типа MESH) - но не о сетях на базе контроллеров. Контроллеры - это баян и неадекватно дорогой баян. :))))
Я в свое время делал сеть на основе миниконтроллеров Cisco (кстати, прекрасно работала и, наверное, до сих пор работает - не знаю). Так вот эти контроллеры уже тогда (где то в 2014 году) стали EoL. А аналоги - это что-то интегрируемое в шасси Cisco или решение на очень большое количество точек, корпоративное до невозможности.
А сейчас часто используются решения на базе WLC контроллеров?
Раньше это была интересная тема, CISCO ее активно продвигала. Но у меня сложилось впечатление, что это направление отмирает.
По моему опыту, RACI полезен при составлении должностных инструкций.
Без привязки к проектам - можно наглядно изобразить кто и за что в принципе отвечает в процессе работы, как информация взаимно передается. Особенно это актуально для случаев, когда отделы никак на словах не могут договориться или регулярно спорят кто кому что должен. К сожалению, такое часто встречается.
Кстати, для перфекционистов есть еще такой вариант, как матрица "РАЗУ" (разделения административных задач управления). Там вообще гипертрофированное разделение ответственности между участниками.